[Vala] [BUG] Re: Closures and local variables
On Mon, Feb 07, 2011 at 15:03:38 +0100, Sylvain Leroux wrote:
> I'm still having hard time using closures in Vala.
You found a bug in vala.
I suspect it's the same bug as:
https://bugzilla.gnome.org/show_bug.cgi?id=611460
https://bugzilla.gnome.org/show_bug.cgi?id=635194
https://bugzilla.gnome.org/show_bug.cgi?id=599133
and related
https://bugzilla.gnome.org/show_bug.cgi?id=608916
> [...]
> There is no error on compilation. But the result is quite surprising:
> sh$ valac closure.vala
> sh$ ./closure
> 1 2 1
> 1 2 1
It returned '1 0 -1' for me. That's because valac actually generated invalid
C code with undefined behaviour.
The problem, after inspecting the generated C is actually in the Pair
constructor:
> delegate int SomeFunction();
>
> class Pair {
> public SomeFunctionfa;
> public SomeFunctionfb;
>
> public Pair(SomeFunction fa, SomeFunction fb) {
> this.fa = fa;
> this.fb = fb;
^
Here, vala should give an error, because you are assigning the (by default)
unowned argument to the (by default) owned member. That conversion is however
not correct for delegate, because unowned delegate does not carry enough
information to correctly add a reference. In fact even owned delegate can
only be moved, not copied.
Unfortunately Debian does not have valac 0.11.5, so I tested with 0.10.3.
And it gets worse than that:
I modified the above to say:
public Pair(owned SomeFunction fa, owned SomeFunction fb) {
this.fa = fa;
this.fb = fb;
}
and it copied the delegate data, but *without* any attempt at incrementing
their refcounts and than immediately destroyed the ones from arguments, so
wrong code again.
Now that's not the end of it. The correct code should have been:
public Pair(owned SomeFunction fa, owned SomeFunction fb) {
this.fa = (owned)fa;
this.fb = (owned)fb;
}
and valac rejected the code, saying that:
error: Reference transfer not supported for delegates
Now the problem is that reference transfer is what should have been done
here. Except it does not work.
--
Jan 'Bulb' Hudec
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Vala vs Mono performance benchmark project
On Mon, Jan 31, 2011 at 17:35:09 +, Aleksander Wabik wrote: > Hi Pancake, > > I'll play with signals for a moment - will the marshallers be gone when > using g_signal_emit()? I guess that they are generating much overhead... Unfortunately, no, they won't. They are there because C cannot do argument forwarding. The, IMHO somewhat unfortunate, choice of using GValue arrays instead of working with the va_args directly is what is causing the overhead. Note, that with va_args, any language binding could still provide it's own set of marshallers to handle conversion to anything they need. -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Vala for everyone
On Mon, Jan 31, 2011 at 17:40:50 +, Aleksander Wabik wrote: > But if you're targetting BREW or Symbian, it would be probably not working > - Symbian AFAIK disallows global static data in shared libraries I am certain there were glib sources in Symbian SDK (9.2 - S60 3rd edition, IIRC), so glib does work there. -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] benchmarks on Vala?
On Tue, Jan 18, 2011 at 09:18:06 -0300, Erick Pérez Castellanos wrote: > I haven't prove it but theoretically can't be slower since Mono > applications are running on the top of a virtual machine and Vala > applications are native code executed, so kinda hard to think that > Mono is faster than Vala, eh !!! Theoretically, that's not true. Good just-in-timing run core can run virtual machine code at almost the same speed as native code. And a good garbage-collector is faster than malloc/free (it pays some cost for surviving object, but for many short-lived objects, it is a lot faster) and compacts the working set, which improves cache performance. And these days, memory access cost as much as tens of instructions, so cache performance can make huge difference. Of course the cost of using garbage collector is bigger memory consumption, because the objects are not recycled immediately. -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] GObject allocation / referencing... Why is so slow?
On Sun, Jan 16, 2011 at 03:00:06 +, Aleksander Wabik wrote: > But I was not thinking of the speedup at the level of acquiring memory, > but at the level of object construction. Let's say we have an object > that has some fields. Now constructing such object requires allocating > memory and then calling some very general function > (G_type_create_instance), which initializes this memory, that is it > calls proper constructors, and maybe some other things. My idea is: > when the reference count drops to 0, don't delete object, but reference > it in some global list instead, not at the allocator level, but at the > object level. Let's make the constructor private, and let's create > static function for obtaining new instances, that will call the > constructor when the global list is empty, but it will just pop an > object from that global list if it's not empty. Of course some > initialization will have to be done, but still it will take less time. You have to do it at the allocator level, because when you have lots of instances of one type, but the program is now allocating other type, you have to release the instances of the first (when doing it automatically). It's what the slab cache (in kernel or in umem library) do. When you use an object specific cache, you pass in function to initialize each object when a slab is created and another function to finalize it when a slab is released. Jeff Bonwick claims it helped Solaris significantly, because locks are in the initial state when an object is released. Locks are abundant in Solaris, but rare in most userland code and there are not many members with similar properties. Well, in vala, two would have it -- the refcount and the pointer to private part. > I'm attaching two programs doing the same thing: allocate and destroy > object in C++ and in Vala (non-gobject, but typed object). Vala is 3 > times slower. Which clearly means there is some other problem. C++ is initializing the object each time. A big difference is, that the C++ object only has the one member -- no virtual method table, no refcount, no pimpl -- and it's constructor is inlined (you even declared it inline). In vala, the g_type_create_instance can't be inlined and needs to initialize the extra members. > But it probably could be many times faster if only the object was not > created, but taken from some global LIFO and just initialized. Dova could be made to either depend on umem, or the code generator to use it when compiled with appropriate package. -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] GObject allocation / referencing... Why is so slow?
On Sat, Jan 15, 2011 at 22:53:25 +0100, Jiří Zárevúcky wrote: > 2011/1/15 Aleksander Wabik : > >> There are other relevant reasons to choose Vala over > >> C#, but speed is not one of them. :) > > This is... very sad. JIT is cool, because it helps to get rid of > > performance problems introduced by some features of OOP, but if we are > > compiling to C, should we not try to solve these problems on another > > level? > > Maybe, if it is worth the effort. This is not about JIT. JIT can never beat optimizing compilation in advance, because it's just doing the same optimizations, lazily only for the pieces of code where it helps the most. The main difference is the allocator. A good compacting garbage collector has extremely fast allocation and deallocation at expense of higher memory requirement, the collection step and especially need for appropriately instrumeted mutator. The fast allocation and deallocation makes such collectors faster in case of many short-lived objects, but their use is limited to properly cooperating virtual machines like Java VM or CLR. Although Mono actually only got compacting garbage collector in 2.8, so the test was likely with version using Boehm GC, that collector uses something like slab allocator, making it decently fast too. > > [...] > > > > Other thing: why delete objects when refcounting drops to 0? Let's > > maintain a queue of some size (maybe tweakable by a class attribute) of > > objects that will be just re-initialized when operator new is called? > > This is a matter of general design. > > > > This is more interesting, This cannot be done in such simplistic way. You need a proper memory pool with reclamation of long unused instances and such. That is, use a slab allocator. The GLib's slice allocator (g_slice_* functions) is one and I thought vala already used that. Using explicit slab caches might help though. > but then we could simply make it possible to use a garbage collector in > Vala programs to achieve yet better results. That would be nice. On the other hand it is quite complicated. The code itself would get rid of all the bookkeeping and things like strings would be trivially shareable. But the bookkeeping would have to be done when passing pointers to collector-unaware modules and storing them in non-collector-allocated memory, meaning it would need to know which modules were compiled with collector and which ones without. Also to allow use of at least heap-correct allocator to allow some compaction, we'd need to generate some functions or metadata for the collector to handle the marking and pointer adjustment. If there was a good, universalish garbage collector library, that the various runtimes (D (phobos), Go, Mono, open-jvm, python, parrot etc.) used, than this would be easier. But most of them use their own (even when they use Boehm GC, which exists as libgc), making any attempt on combining them in one program mostly futile. It's vala's advantage that it can be combined with any of them. It would loose that advantage by using a garbage collector. > > [...] > > > > Other thing: why access private data through a pointer? Oh, I read > > rationale for this architecture somewhere in glib manual, but on the > > other hand, we can not enforce 'protected' on C level. Maybe private > > can be spared too? General design, although impact on performance > > should not be high. > > > > Dova profile prohibits non-private fields entirely. Let's do the same > in GLib profile (except bindings) and problem solved, we don't have to > care about the distinction. On the other hand, the way Dova profile > accesses object data is even less direct than GObject way. I'd like to > see what the actual performance difference is. The reason is ABI compatibility for libraries. It is advantageous for libraries that you can add private members without changing size of the object, because if object size changes, code inheriting from the object will need to be recompiled to use the new library. And since you never know what code derives it, you'll have to bump the ABI version and all code will need to be recompiled. So I think Dova profile should support it, but it might be on request, since only libraries want it. > > Other thing: signals. Did someone measured their performance? I did > > once, its AWFUL! Why? Well, here we also are using highly reusable, and > > very slow code. Signals are referenced by name (yes, string!), signals > > get complicated marshallers for their parameters... I don't know if it > > can be fixed easily in glib profile, but in such language like vala the > > signal could be implemented as a list of function pointers! I bet that > > any JIT, in C# or in Java (when java will finally support > > events/signals) will beat glib signals easily. A matter of general > > design. > > Changing this in GObject is imo not possible. No, but: 1. It can be done in a simpler fashion in Dova and 2. Even in GLib profile, any non-GObject objects could do it
Re: [Vala] GObject allocation / referencing... Why is so slow?
On Sat, Jan 15, 2011 at 20:56:45 +0100, Jan Hudec wrote: > On Sat, Jan 15, 2011 at 19:58:37 +0100, Marco Trevisan (Treviño) wrote: > > However I don't think that an atomic add or fetch-and-add (or > > call them inc and dec-and-test) correctly used in plain C wouldn't cause > > all this performance gap. > > Nor do I, but I'll try it with the above implementation substituted to your > test code. Hm, they actually show significant difference here. I slightly modified your tests (changed test_object_unref from 'TestObject *test_object_unref(TestObject **)' to 'void test_object_unref(TestObject *)) and ran it with simple increment/decrement and atomic __sync_* functions. And the results are somewhat surprising. For 1 iterations, the - single-threaded variant ran in 8.78s - thread-safe variant ran in about 11.50s (with much bigger fluctuation between runs) This was quite surprising result, given that I only replaced the reference count increment and decrement with thread-safe options and that that only replaces normal increment/decrement with one involving 'lock xaddl' instruction -- no locks, no extra function calls or anything. So I retried with unoptimized code. Well, now they run 16 seconds and the thread-safe variant is at most 0.5s slower and in some runs not slower at all. That seems to indicate that the code itself is taking significant portion of the time (since all versions called the same calloc and free) and that the lock xaddl itself carries minimal performance penalty compared to regular add. So the only difference remaining to explain the large difference in run times of the optimized code is the inability to optimize across the thread-safe increment/decrement (the compiler did significant amount of inlining -- the ref and unref code was copied all over the generated assembly). Now vala uses functions from glib to do the reference-counting. Since they are defined in the library, they cannot be inlined and since most optimizations are not allowed across function call, I expect the performance penalty to be quite significant. On a side-note, I also tried C++ using the shared_ptr (C++0x, supported since gcc 4.4) which ran for 17.0s (optimized). I don't have Dova installed to compare though. -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] GObject allocation / referencing... Why is so slow?
On Sat, Jan 15, 2011 at 19:58:37 +0100, Marco Trevisan (Treviño) wrote:
> Il giorno sab, 15/01/2011 alle 19.09 +0100, Jiří Zárevúcky ha scritto:
> > >
> > > Yes, it's not the same, but it's a similar implementation, using
> > > reference counting (it's not atomic, but if you use an sig_atomic_t ref
> > > variable, instead of the volatile int, you would get atomicity with no
> > > performance loss at all),
> >
> > Not true I believe. sig_atomic_t ensures atomicity on an entirely
> > different level.
> > It has nothing to do with multi-threaded programming.
No, it is not. There is no portable way currently (one is planned for C++0x
and while it includes a plain C variant, I don't know whether there are
currently any plans to adopt it for C), but GCC has it's own extension for
them, that is available for all supported platforms (see
http://gcc.gnu.org/onlinedocs/gcc-4.5.2/gcc/Atomic-Builtins.html)
So one can implement ref and unref as:
typedef struct _Foo Foo;
struct _Foo {
int refcount;
...
};
Foo *foo_ref(Foo *foo)
{
__sync_add_and_fetch(&foo->refcount, 1);
}
void foo_unref(Foo *foo)
{
if(!__sync_sub_and_fetch(&foo->refcount, 1))
foo_destroy(foo);
}
> Mh, ok... So why using these features in Vala also when not using
> threads?
Vala normally simply uses functions provided by the selected runtime and
these functions are written so they work in threaded environment, because the
runtime may be used in such.
> However I don't think that an atomic add or fetch-and-add (or
> call them inc and dec-and-test) correctly used in plain C wouldn't cause
> all this performance gap.
Nor do I, but I'll try it with the above implementation substituted to your
test code.
--
Jan 'Bulb' Hudec
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] vala code generation too constrained?
On Tue, Jan 11, 2011 at 20:55:21 +0100, Jürg Billeter wrote: > On Tue, 2011-01-11 at 11:11 +0100, Xavier Bestel wrote: > > IMHO there should be 2 modes: > > - library mode, where conflicts are clearly and loudly shown by valac. > > - application mode, where conflicts are silently resolved via a suffix > > or whatever clever magic some smart people invent. > > The main reason that speaks against this, in my opinion, is that it > would be really confusing if your code stops working when you move it > from an application to a library, which is not that rare. Also, while C > identifier conflicts due to simple name mangling can lead to unexpected > error messages from the C compiler, they are usually really easy to work > around. It would be nice if vala produced the error itself when a name is emited again for different object rather than waiting for the C compiler to do so. Something like: error: Symbol generated for method 'X.Y.z' conflicts with symbol generated for class 'X.Y.Z'. Rename one of the objects or assign different C names to them via [CCode] attribute. Handling it would be much more complicated and introduce new corner cases with their own strange errors and would generally not be worth it. -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] vala code generation too constrained?
On Mon, Jan 10, 2011 at 12:03:16 +0800, Nor Jaidi Tuah wrote: > Some of the big gotchas in vala is due to the > desire to produce a standardized C code that can > interface nicely with non-vala module. I suspect > this constrain also makes it difficult to implement > some features. Vala is interesting exactly because it generates standardized C code that can be easily used from C therefore every other lanugage out there, because C as the lowest common denominator can be interfaced with any language. Otherwise there are heaps of languages that are more powerful and far less quirky than vala -- just they basically can't be interfaced with each other. > Old timers familiar with C will find the gotchas > natural and can live with it. But I wonder what > the java-educated mass will think when they encounter > vala idiosyncrasies. > > Since not all vala code are intended for libraries > accessible from non-vala, I suggest that the compiler > should be given more freedom with the name mangling > and so on, so that its behaviour is gotcha-free. This is not going to work. The same vala code has to always produce the same C code independently of what other modules get compiled together with it. You know, because somebody might compile them separately and link them together afterwards. > A compiler flag can be added to revert back to the > human-friendly C generation. > > Vala is great already. But I wish it to be even > greater. Just use D, or C#, or Java, or Haskell, or OCaml, or Go, or ... In fact for things that are not library, just use Python, Perl, Ruby or anything dynamic. They are faster to write in and the performance hit just does not matter for end applications. But for the platform components the human-friendly C generation is needed and that's where vala stands out. -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] fuse.vapi help
On Wed, Jan 05, 2011 at 10:36:26 -0500, Matt Harrison wrote:
> Can anyone get me pointed in the right direction on this?
>
> Thanks!
>
> On Wed, Dec 22, 2010 at 3:33 PM, Matt Harrison wrote:
>
> > Hi,
> >
> > I'm trying to just do a basic example of using the fuse.vapi file to learn
> > how it works. I'm basically trying to remake this example
> > http://code.google.com/p/fusepy/source/browse/trunk/memory.py but I'm not
> > really sure how to begin.
> >
> > At the moment I'm trying something simple like this:
> >
> > int main (string[] args)
> > {
> > void* user_data = null;
> > Fuse.Operations oper = Fuse.Operations() {
> > mkdir = (path, mode) => {
It's target-less delegate ([CCode(has_target = false)]), so it won't work
with lambdas nor methods. You have to use static or non-member functions.
You didn't really choose the right function to start with, because before any
such operation, kernel will want to look up the parent node. Briefly looking
at the documentation I believe you need to start with the getattr operation.
> > stdout.printf("mkdir\n");
> > }
> > };
> > Fuse.main(args, oper, user_data);
> > return 0;
> > }
> >
> > But I've no idea what I'm doing. Thanks for any help on how to get started
> > with this.
> >
> > Matt
> >
> ___
> vala-list mailing list
> vala-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/vala-list
--
Jan 'Bulb' Hudec
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Threads with return value... Isn't this a memory leak?
On Tue, Jan 04, 2011 at 16:30:38 +0100, Marco Trevisan (Treviño) wrote:
> Consider this simple vala code, which uses some threads with return
> value... Since int[] can't be a generics, I need to use an int pointer
> for using an integer array as retourn value...
No, but a
class IntArray {
int[] data;
}
can. So unless you are forced to use exactly int* by some external library or
something, just wrap the array in an object and return that. Vala will than
do memory-management for you properly.
> It works as expected, but... If you look at the generated C code, the
> pointer returned by g_thread_join (t) is never free'd.
As you've been already told, pointers are not managed automatically. But
there's the 'delete' statement for that case.
--
Jan 'Bulb' Hudec
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Defininig _GNU_SOURCE...
On Sun, Jan 02, 2011 at 20:44:24 +0100, Marco Trevisan (Treviño) wrote: > Hello, I'm writing a small VAPI file for a GNU hader that requires to be > included as: > > #define _GNU_SOURCE > #include > > Of course I can't do it nor in vala or vapi files, but to compile the > code I have (avoiding the linker errors) I need to define _GNU_SOURCE... > > A solution is running valac as: > > valac myfile.vala -X -D"_GNU_SOURCE" > > but, could be added a better way to perform this? Automatizing such > thing when including a GNU file... If the header can't be used without this define, the library the header is from should define it in it's pkg-config file in CFLAGS. Whenever you give vala the '--pkg mypackage' option, it does two things: - loads mypackage.vapi - AND adds output of 'pkg-config --cflags mypackage' to C compiler command line and output of 'pkg-config --libs mypackage' to linker command line. So the mypackage.pc somewhere on pkg-config's path should contain appropriate definition. So if this comes from 3rd party library, discuss adding the define -- or avoiding the need for it -- with upstream. -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Name clashes in generated C code
On Tue, Dec 28, 2010 at 15:32:07 -0800, Anatol Pomozov wrote: > I am sure using [CCode] is ok for libraries as well if cprefix value > does not change very often. The reason to try to avoid [CCode] for libraries is that users of the library will expect the code to follow some naming convention, which vala does by default. When you resolve a name conflict with [CCode], you make it harder for user to remember which of the objects the original name belongs to and what is the name of that symbol for the other object, thus making it slightly less user friendly. There will be no techincal problems. Of course, changing the attribute will probably break API or ABI compatibility. But there are many changes that will and you need to be careful about all of them when maintaining library. -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Name clashes in generated C code
On Mon, Dec 27, 2010 at 13:46:47 -0800, Anatol Pomozov wrote:
> Hi,
>
> I have a simple Vala program
>
> public struct Struct { string name; }
> public enum Type { STRUCT }
>
> [...]
> The problem here a name clash in generated Vala code - TYPE_STRUCT
> both generated as type of Struct
>
> #define TYPE_STRUCT (struct_get_type ())
>
> and as a enum value
>
> typedef enum {
> TYPE_STRUCT
> } Type;
>
> what is the best way to avoid such clashes?
Well, it depends on whether you are writing a library or an application.
For library the API should be usable from C, so best way is just to avoid
calling the enum 'Type'. For an application the C names don't matter though,
so you can just tell vala to use different one in C.
> Is it possible to change enum names to something else.
Try using the [CCode(cprefix=...)] annotation. You'll find examples in the
.vapi files. It's normally used to tell vala how externally provided things
are called, but it should work for renaming things generated by vala too.
> I can change enum name from Type to something else e.g. RecordType, but
> I would like to know if there is a better solution.
As I say, it depends on whether somebody will be using the API from C or not.
If they will, rename the type. If not, rename the members with cprefix.
--
Jan 'Bulb' Hudec
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Bug in vala
On Fri, Dec 10, 2010 at 15:34:32 +0100, Abderrahim Kitouni wrote:
> Hello,
> في ج، 10-12-2010 عند 00:40 -0300 ، كتب Erick Pérez Castellanos:
> > Is this a bug ???
> >
> > I'm using Glib.Settings API, and specifically this:
> > public bool set_strv (string key, [CCode (array_length = false)]
> > string[] value)
> > from that class and when using as it says passing an string array as second
> > parameters I'm getting a warning from the compiler:
> > spider_window.c: In function ‘spider_window_edit_preferences_callback’:
> > spider_window.c:811:3: warning: passing argument 3 of ‘g_settings_set_strv’
> > from incompatible pointer type
> > /usr/include/glib-2.0/gio/gsettings.h:124:25: note: expected ‘const gchar *
> > const*’ but argument is of type ‘char **’
> >
> > And that shouldn't happen.
>
> "shouldn't happen" may be too strong :-)
> We would like valac generated code to compile without warning, but
> that's not an easy task and it doesn't bring much.
>
> And btw, I don't see what problem there could be when passing char** to
> a "const gchar* const*", maybe your compiler is a bit too paranoid? (and
> maybe there is a complicated corner case I don't see).
Well, you can't cast 'char **' to 'const char **' safely (applies to any
type, not just char, of course). Consider:
void get_message(const char **msg)
{
*msg = "All is wrong!";
}
...
char *msg;
get_message(&msg);
msg[0] = 'B'; /* OOPS! You modified the static buffer! */
The danger does NOT apply to 'char **' -> 'char const * const *', since than
nothing of the structure may be modified, but gcc may not be smart enough to
avoid the warning in this case.
--
Jan 'Bulb' Hudec
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] GINT_TO_POINTER
On Thu, Dec 09, 2010 at 11:40:02 -0600, W. Michael Petullo wrote: > Is there a GINT_TO_POINTER-like capability in Vala? Or, if I need > something like this does it mean I am not trying to solve a problem in > a Vala way? In C, I often use this macro to place integers into GLib > datatypes like GHashTable. Vala uses it automatically with generics. When you have a structure, that stores a gpointer in C, in vala it's declared as generic. This tells vala what type you are actually store in the structure. It also provides the type ID, ref/copy and unref/delete functions to the structure if it needs them to manipulate the stored data. If you pass 'int' for the generic parameter, it will be stored using GINT_TO_POINTER. Any other type must be a reference type; primitive types larger than int can be boxed by adding '?' to them. -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] file globbing?
On Tue, Dec 07, 2010 at 21:59:42 +0200, Jani Monoses wrote: > is there an easy way of getting a list of files matching a pattern > in a directory (like Python's glob.glob() ) short of > enumerate_children() and checking each returned name explicitly > using regexps? POSIX has a function glob to do exactly that. Unfortunately I don't see it bound in posix.vapi, so you would have to provide appropriate extern declaration yourself. -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Interfaces - why do they must have prerequisites?
On Sun, Dec 05, 2010 at 17:32:17 +0100, Aleksander Wabik wrote: > I'm having class Foo, that is _NOT_ inheriting Object, but it's still > a typed class, and it's implementing interface IFoo. This is (or used to > be) legal. No, it is not and never was legal. Interfaces depend on runtime support provided by GObject and therefore only classes derived from GLib.Object may implement interfaces. -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Cannot have field and method with the same name
On Fri, Dec 03, 2010 at 15:38:38 -0800, Anatol Pomozov wrote:
> I have a class that contains a field and method with the same name,
> and Valac does not like it. What is the reason? Other languages
> (C#/Java) allow it.
Pardon me. C# does NOT allow that:
test.cs(3,17): error CS0102: The type `Foo' already contains a definition for
`stop'
Java allows it, but Java is one of very few languages where method isn't an
object (it is an object -- function pointer -- even in C and C++).
> You have to use () for method so you know whether
> you access method or field.
No, you don't. If there was just the method, this.stop would return
a delegate calling it, so when there's also field stop, the statement would
not be defined.
> public class Foo {
> public boolean stop = true;
>
> public boolean stop() {
> return true;
> }
> }
--
Jan 'Bulb' Hudec
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Dbus, connecting a signal to an async method...
On Sat, Dec 04, 2010 at 12:35:26 +0100, Marco Trevisan (Treviño) wrote: > Il giorno ven, 03/12/2010 alle 17.18 +0100, Abderrahim Kitouni ha > scritto: > > > session_proxy.name_acquired.connect (this.name_acquired); > > What I would have done is: > > > > session_proxy.name_acquired.connect ((name) => > > this.name_acquired.begin(name)); > > Ok, cool this works thanks. However in this case the lambda should be > (p, name) => this.nameacquired.begin(p, name); ;-) > > However I guess that this is just a workaround, the related bug should > be fixed! It's not a bug. The 'async' is part of the function signature, so the function signatures don't match and it can't be converted. It might be a missing feature, but I think it's preferable to explicitly require the .begin. > > You can also try to pass the begin method directly (but I'm not sure it > > works). > > No, I tried that, but it didn't work, I got an error since the begin > return value was considered just like a void. Hm, the begin function returns a void, but that's what the signal expects anyway, so it seems like that one should work. That would be a bug than. -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Vala thinks uint32 constant is int64
On Tue, Nov 23, 2010 at 18:36:40 -0800, Evan Nemerson wrote: > On Wed, 2010-11-24 at 02:56 +0100, Jaroslav Šmíd wrote: > > Anyway, any chance that vala will switch to size_t (or at least intptr_t > > or ptrdiff_t (which is standard defined type for pointer difference)) > > from int for array indexing and array sizes? > > It's a long shot. The problem is that Vala isn't building a whole new > ecosystem of software, it is trying to reuse existing libraries. It is > easy to switch to size_t (or ssize_t) if you're creating, say, .NET or > JRE, but most C libraries use int. Standard library uses size_t consistently and so does anything POSIX. GLib does use it's own typedef gsize, but does not do so consistently. The memory functions do, but the rest is a mixture. In any case I would prefer if vala generated size_t in interfaces it *generates* and was able to understand appropriate declarations for .vapis. > > Writing that stuff before each array is very ugly. > > I agree that it is ugly, but unless you can convince all the C libraries > to switch to (s)size_t, I don't see a way around it. You either have to > write something extra when you want to use size_t or when you want to > use int, and I think int is by far the most common case so it makes > sense to optimize for that. There is a way around it -- being able to specify per-namespace default. A single library is usually self-consistent. So specifying the attribute for whole namespace would help. So if you have a library that uses type X consistently, you'd just annotate the top-level namespace declaration in the .vapi with [CCode(array_size_type = "X")] and be done with it. If it's not self-consistent, than obviously individual members and arguments would need to be annotated. > A command line switch would be *horrible*. Agree. Command-line switch would not work. > Also, keep in mind that not everyone is going to agree on size_t. First > of all, it's unsigned, and there are a lot of places where that is a > deal-breaker. Then, what about ssize_t, unsigned int, unsigned long, > long, unsigned short, short, intptr_t, ptrdiff_t, etc.? The precise meaning of size_t, ptrdiff_t and inptr_t are defined by the standard, so there is a clear guideline when to use which (I don't think ssize_t is a standard type). They are: - size_t is the return type of sizeof operator and used as argument of memory allocation functions, so it's appropriate for array and object sizes. - ptrdiff_t is the return type of operator - applied to pointers, so it's appropriate for offsets that need to be signed. - intptr_t (c99 only) is an integeral type large enough to store value of a void*. Note, that size_t or ptrdiff_t don't have to be large enough to store value of a void*. size_t and ptrdiff_t must only be able to store size of any single object, but single objects may be limited to less than whole memory size (e.g. when segments are used). -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] BUFSIZ
On Wed, Nov 24, 2010 at 10:17:37 +0800, Ervin wrote:
> How can i use BUFSIZ from stdio.h?
Just declare it extern somewhere. I believe
namespace Posix {
[CCode(cname = "BUFSIZ", cheader_filename = "stdio.h")]
public extern const int BUFSIZ;
}
should do the trick.
--
Jan 'Bulb' Hudec
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Combining async methods with external processes
On Fri, Nov 19, 2010 at 13:25:11 +0100, pancake wrote:
> you are using coroutines which are not designed to "run stuff in
> background".
>
> coroutines are designed to run collaborative code which hangs if one of the
> parts doesn't pass the token when necessary.
>
> You have to use threads, or an idle task if you have a mainloop.
Async methods are NOT coroutines(*). They ARE transformation of functions to
let them finish in response to an event in the main loop (idle or not).
Oh, and avoid threads as long as you can -- synchronization is a LOT of
trouble. And running another main loop in the other thread to get
spawn_async_with_pipes working there is even more.
> On 11/19/10 08:34, James Moschou wrote:
> >Hello,
> >
> >I want to perform a series of tasks one after the other, but in the
> >background. So I have:
> >
> >async bool perform_tasks () {
> > bool result = yield task1 ();
> > if (result)
> > result = yield task2 ();
> > if (result)
> > result = yield task3 ();
> >
> > Idle.add (perform_tasks.callback)
You can attach the .callback to any event source in the same way. So e.g.
when data arrive from the process or the child terminates etc.
> > yield;
> > return result;
> >}
> >
> >more or less.
> >
> >One of the tasks however spawns a new process, and I'm not sure how
> >the callback from this process is supposed to fit into Vala's way of
> >doing async programming, i.e. Process.spawn_async_with_pipes () isn't
> >actually an "async" method.
But it's easy to wrap it in one. Just spawn_async_with_pipes and arrange the
.callback to be called when results are available and yield.
(*) They are not coroutines, because they are not running in parallel with
the caller. The not yet implemented generator functions would be coroutines.
--
Jan 'Bulb' Hudec
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Define constant at compile time
On Tue, Nov 16, 2010 at 12:28:23 -0800, Anatol Pomozov wrote:
> But what if you want to change the real constant value at the
> compile-time? A classical example is DEBUG vs OPTIMIZED mode. During
> development I want to log of information to stdout, like this:
>
> if (DEBUG) {
> stdout.printf("User ID is: $user");
> }
>
> and I don't want to have this code in the release version. To make it
> happen one can use something like
>
> bool DEBUG=false;
>
> and compile the vala program with -DDEBUG (or its equivalent
> -DDEBUG=true). This compiler flag changes the default value of the
> const.
>
> Type-safety means that vala compile knows that DEBUG is boolean and
> complains if someone tries to use number/string here (-DDEBUG=foo) or
> tries to set value for unexisting constant.
You know, vala DOES support THAT. Simply
#if DEBUG
stdout.printf("USer ID is: $user");
#endif
and than:
valac -DDEBUG ...
It is a flag -- either it's there or not.
--
Jan 'Bulb' Hudec
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] gobject-introspect vs gir
On Tue, Nov 16, 2010 at 12:46:26 -0800, Anatol Pomozov wrote: > http://live.gnome.org/Vala/Bindings page recommends 2-step vapi generation > 1) Generate *.gi file using gen-introspect tool. It works for glib-style > code. > 2) Generate vapi file using vapigen tool > > Both tools are located in Vala repository. Why there are 2 steps here? The first tool does not originate in vala. It comes from separate project called gobject-introspection (http://live.gnome.org/GObjectIntrospection). Format of data it generates has changed since vapigen was written, so vala drags around the old version of the tool until vapigen properly understands the new format. > I also see a gir branch in Vala repository and it makes me believe > that this is the next gen-introspect tool. Gir is the current format of GObjectIntrospection. > Where I can find more info about *.gir format? What is the plan, are you > going to replace gen-introspect with it? Is it vala-specific or it is comes > from glib? It comes from the GObjectIntrospection project. See above. Last time I looked (which was about a year ago), the data format was unfortunately totally undocumented, so I had to infer stuff from examples and code. I don't know how much the state improved since. > I am trying to process Apache Thrift source code with gen-introspect > and I think that there is a bug. Should I try to fix it (or/and report > to bugzilla) or it is better to wait for gir-... stuff? I suppose it would be best to test how far the gir stuff can get and report what is missing there. It does not seem to be getting too much testing, so it won't get finished otherwise. -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Define constant at compile time
On Tue, Nov 16, 2010 at 18:51:12 +0100, Günther Wutz wrote: > It is possible to use cpp as Preprocessor. I'm working on a > wrapper-program to combine cpp and give it valac to compile. The easiest > way i found actually. Sorry. That's an extremely bad idea for most cases. The easiest way is to tell vala to emit the symbols that will then be defined when compiling the generated C code. That way vala will guard you from name conflicts and the code will be more readable. In C, the preprocessor is generally used for two things: - symbolic constants -- but real constants serve the purpose better and - generic constructs -- but vala does have generics, so you don't need those. Even in C++ you usually avoid the preprocessor for most things, because preprocessor symbols cannot be scoped. Which is doubly so applicable to vala. -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Define constant at compile time
On Tue, Nov 16, 2010 at 18:36:07 +0100, Andrea Corbellini wrote: > I want to specify the constant UI_FILE at compile time, but I don't know > how to do that. In C I would write something like that: > > #ifndef UI_FILE > #define UI_FILE "default-path.xml" > #endif > > and then I would call gcc with the option -DUI_FILE="something". I've > tried to use the -D option of the Vala compiler, but it doesn't seem to > work as I expect. Any ideas? There are two ways: 1. Define it as static const string UI_FILE = "@ui_file@" in a .vala file and have it substituted by autoconf (similar mechanizm exists in any other build tool as well). 2. Define it as [CCode(cname="UI_FILE" cheader_filename="defaults.h")] extern const string UI_FILE; in a .vala file (or in a .vapi file in which case it's extern implicitly), put the defines you cited above in this "defaults.h" file and optionally pass the -D option to the C compiler. You can pass options through vala to the C compiler by prefixing them with -X like: vala ... -X -DUI_FILE=\"something\" ... -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Blitzen: A Vala Application Server
On Sun, Nov 14, 2010 at 15:30:29 +0100, pancake wrote: > On Sun, 14 Nov 2010 11:22:37 + (UTC) > Samuel CUELLA wrote: > > For the moment, the repository is not accessible from the internet. I'll > > import > > it into the sourceforge subversion service when I have time. [...] > > Why non use git or hg? svn and sourceforge are imho worst solutions for > developers. Sourceforge now supports all of git, mercurial (hg) and bazaar. They also support trac and mantis as alternate bugtrackers and a handful of other applications. So it's actually usable if you avoid the forge itself and use these "Hosted Apps" (search around their wiki http://sourceforge.net/apps/trac/sourceforge/wiki/, which is itself a trac installed the same way they offer for projects). > I stopped using sourceforge for security reasons (their servers are not really > secure places) and because of their license agreement and service shutdown > times. That obviously does not address security nor obonxious terms of service. It is somewhat less of a problem if you can easily change hosting though (which distributed version control systems make a lot easier). -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Chunking a file in multiple chunks
On Thu, Nov 04, 2010 at 20:24:21 -0500, Guillaume Viguier wrote:
> Hi,
>
> I'm totally new to the Vala language, so there might be something
> obvious I'm missing. I'm trying to chunk a file into different chunks of
> 500 k (in order to send it over the network) and then calculate its
> md5sum (to send the md5sum over the network to a service to allow it to
> verify the file was sent correctly).
Strings in Vala are ANSI C NUL-terminated strings. Their length is not kept
around in any way, but is determined by looking for the first 0 byte. You
are, however, reading binary data that can legally contain 0 bytes. Therefore
you have to use 'uint8[]' type (or the ByteArray type), never 'string' type.
For arrays, vala keeps extra variable with the length.
> Here is the code I've written so far:
>
> var file = File.new_for_path(source_file);
> var file_stream = file.read();
> var data_stream = new DataInputStream(file_stream);
> data_stream.set_byte_order (DataStreamByteOrder.LITTLE_ENDIAN);
Why are you creating a data_stream here? The FileInputStream you got from
file.read() is already an InputStream and that's all you seem to be using
anyway.
> size_t chunk_size = 50;
> size_t bytes_read = 50;
> string[] chunks = new string[0];
> uint8[] chunk = new uint8[chunk_size];
> string photo_data = "";
> var bytes = new ByteArray();
> string original_sum;
> string chunk_string = "";
> do {
> data_stream.read_all(chunk, chunk_size, out bytes_read);
> chunk_string = (string) chunk;
This is wildly incorrect. chunk.lenght is chunk_size, but chunk_string.length
is just the length to the first NUL byte. What you want is bytes_read long
slice of the array, as an array.
> bytes.append(chunk);
This is almost correct. It is not, because bytes_read may still be less than
chunk_size (at end of file). So you need to append a slice (for which I don't
remember the syntax).
> chunks += chunk_string;
>
> debug("bytes read: %Zd", bytes_read);
> debug("string size: %Zd", chunk_string.size());
> }
> while (bytes_read == 50);
I'd compare it to chunk_size when you already have it. Than your code will
still work if you change the size above.
> original_sum = Checksum.compute_for_data(ChecksumType.MD5, bytes.data);
> debug("Original sum: " + original_sum);
>
> The number of bytes read in the first debug call seems fine (the file
> I'm trying to read is 1.9 Mb and I get 4 "bytes read" outputs, which
> correspond to the size of the file). However, the "string size" seems
> wrong (the first chunk gets a size of 4, the second one 25 etc... and
> finally, the original_sum computed is totally wrong as well (does not
> correspond to the md5sum of the file).
Well, where did you tell the string the value of bytes_read that you expect
it to be of correct size?
--
Jan 'Bulb' Hudec
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Do you think that re-use "web-based library" in client side framework?
On Tue, Nov 02, 2010 at 21:48:21 +0900, san hoi wrote:
> I try to use python library in genie, (I choose simply process kick
> aproach...)
> and so I face two problem.
>
> 1. equivarent code in genie that os.poppen("python output_token_value.py")
> 2. definition style infomation in genie (from pygments.styles.colorful
> import ColorfulStyle part)
>
> I'd like to port following code to genie.
> http://snipplr.com/view/40019/pygments-in-pygtk/
Why do you want to do that? You'll need python anyway and GUI code is rarely
performance critical, so you can't really gain much writing the GUI in genie
rather than python. Of course unless you have existing GUI written in C or
vala/genie that you want to integrate with.
The best I can suggest than is to write a python script to generate the pango
markup (already expanded to specity fonts, colors and style rather than
defining them separately as the sample does) and execute that as subprocess
using the GLib.Process.spawn_async_with_pipes method.
--
Jan 'Bulb' Hudec
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Genie syntax for connect
On Wed, Oct 13, 2010 at 11:31:09 +0200, Nicolas wrote: > destroy.connect(Gtk.main_quit) > spin_box.value_changed.connect(spinbox_value) > slider.value_changed.connect (slider_value) > button.clicked.connect(Gtk.main_quit) > > I also update the "[Genie] Synchronizing Widgets" in code.valaide.org That however avoids anonymous functions, which the original question explicitly asked about. -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] g-ir-compiler compatibility with valac generated gir files
On Tue, Oct 12, 2010 at 14:39:39 -0700, Evan Nemerson wrote:
> On Tue, 2010-10-12 at 13:15 -0700, Nigel Griffin wrote:
> > Hi,
> >
> > I'm using the latest g-ir-compiler g-object-introspection's git
> > repositoty. However, even with a gir file generated from a minimal
> > vala class causes g-ir-compiler to crash. Is there a known good
> > version of g-ir-compiler that the gir files generated from valac will
> > work with?
> >
> > I'm also using the latest valac (which was updated recently to work
> > with never g-ir-compiler versions).
> >
> > The vala code for the test class is very basic:
> >
> > public class TestClass : Object
> > {
> > }
>
> I believe GIR requires you to place your content in a namespace.
Not only that, but it has to be one namespace per file and nesting is not
possible. And the generated .typelib will be named by the namespace. And you
can't have more than one .gir with the same namespace.
I think vala should either:
- Set the namespace from the gir file name.
- If there is more than one namespace to write, the type names should than
include the namespace prefix.
- Or use the namespace name as basename for the gir.
The gir namespaces are really the names of libraries, so I think the first
option would be better.
--
Jan 'Bulb' Hudec
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Two small new features
On Wed, Sep 29, 2010 at 00:42:55 +1000, Fredderic Unpenstein wrote:
> On 28 September 2010 21:19, Julian Andres Klode wrote:
> > On Mo, 2010-09-27 at 02:55 +0200, Frederik Sdun wrote:
> >> This is just for convinience, for the not unusual case of:
> >> if (args.length > 0)
> >> foreach(...)
> >> else
> >> ...
>
> Personally I find myself, in almost every language, wrapping for(each)
> statements in "if (the list has items) ... else ...", which is exactly
> what this feature addresses. And, it's essentially saying exactly
> what such a structure looks like; do this loop, else do this other
> thing if the loop never happened (because there weren't any items).
IMHO confusing and not really needed, because the if above is not that much
more writing.
> > That would be confusing for people with Python background, as 'else' is
> > executed when the loop is exhausted; that is if there was no
> > return/break in the loop body.
>
> That doesn't strike me as particularly useful, or as a particularly
> good definition of "else" for that matter. I'd consider that more of
> a "then" situation, with "else" used because it's already a handy
> reserved keyword that they couldn't think of a better use for.
Except, well, it's not. It is really else for cases when the loop is looking
for something. As in:
for x in cache:
if want(x):
break
else:
cache += new_entry(),
> Lets not punish Vala for Python's lack of good taste, though "then" as
> in "Python's for...else" could be handy too. ;)
In fact I can see more use for the python case. As I said, writing the
if(no-elements) before the loop is easy and makes your intention clear. On
the other hand I've seen lot's of:
for(i = begin; i != end; ++i)
{
if(something(i))
{
found = true;
break;
}
}
if(!found)
something_else();
which is pretty ugly. If you move the variable out of the for initialization,
and provided the condition has no side-effects, be rewritten as:
for(i = begin; i != end; ++i)
if(something(i))
break;
if(i != end)
; // nothing
else // here is our little ELSE
something_else();
I believe that making else shortcut for this with the benefits that
- the else branch is in i's scope even if i is declared in the loop
initialization
- and the end codnition is not evaluated when it does not need to be
is both more obvious and more useful.
On a side note, I do like the else for try/catch. I'd say it's much more
a "than" situation there (because it's executed if the try succeeded), but
else is already being used for that purpose in other languages (python among
other).
--
Jan 'Bulb' Hudec
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Invalid C code in Interfaces
On Mon, Oct 04, 2010 at 12:00:44 +0100, Abderrahim Kitouni wrote:
> Hi,
> في ح، 03-10-2010 عند 19:30 -0400 ، كتب tecywiz121:
> > Hello again!
> >
> > I seem to have run into a case where valac generates incorrect C code.
> > I'm sure what I am doing is wrong, but I assume that valac should emit
> > the error and not gcc.
> Definitely, the rule of thumb is : if valac generates invalid C code
> it's a bug, either in valac or (more likely) in the bindings.
>
> > When I try to compile this snippet,
> >
> > public interface IFace : Object
> > {
> > public G[] foobar()
> > {
> > G[] storage = new G[2];
> > return storage[0:1];
> > }
> > }
> >
> > void main(){}
> >
> > I get this error from gcc:
> >
> > In function ‘iface_foobar’:
> > generic.vala.c:54: error: dereferencing pointer to incomplete type
> >
> > The relevant C code is:
>
> The problem is in self->priv->g_dup_func, interfaces cannot have fields,
> but the codegen is assuming otherwise. If you make your interface an
> abstract class, it works. Maybe this should be replaced with a property
> access (using g_object_get) at least in interfaces.
This is internally generated field for generics. That means that generic
interfaces simply don't work yet.
Generic interfaces need a bit of special treatment. Since you don't
instantiate the interface but rather a class implementing it and the class
specifies for which type it supports the interface. So the dup_func and other
functions for handling generic argument should be for generic interfaces
replaced by autogenerated abstract functions in the interface. The class
implementing the interface would then implement them either by calling
similar generic handler it has or by calling appropriate function for
specific type.
So
public interface IFace : Object
would automatically get
G g_dup_func(G x);
method and
public class Concrete : Object, IFace
would automatically imlpement as (using C for the body)
Object g_dup_func(Object x) { return g_object_ref(x); }
while
public class Generic : Object, IFace
would automatically implement as (using C for the body)
H g_dup_func(H x) { return self->priv->h_dup_func(x); }
--
Jan 'Bulb' Hudec
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Dbus properies notifications
Hello,
On Wed, Sep 22, 2010 at 12:00:40 +0200, tetete wrote:
> Hello
> Is there a possibility to get notifications of changed dbus server
> properties on the client?
> I guess there is some "on board" vala way of doing this.
> serverobject.notify.connect( (s,p)=>{print("%s\n",p.name);});
> is not working.
> The client can read the properties, but without change notifications,
> they are far less useful.
> I'm using GDBus and vala-0.10.0
The DBus specification says that
org.freedesktop.DBus.Properties.PropertiesChanged signal was added in 0.14,
but may not be supported by particular implementations. Either because they
were not yet updated to 0.14 or because they for some reason don't want to.
See
http://dbus.freedesktop.org/doc/dbus-specification.html#standard-interfaces-properties
I can't find when that specification version was released, but believe it's
not more than a year.
So try connecting to the PropertiesChanged signal. If that does not work, try
using the methods of DBus.Proxy directly instead of relying on the laguage
support. It still may not work if your server does not emit it, though.
--
Jan 'Bulb' Hudec
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Genie xmlrpc-c bindings test
On Tue, Sep 14, 2010 at 20:00:58 +1200, Phil Daintree wrote: > Thanks for taking a look Evan > > > If that is the case, then adding > > > > [CCode (ref_function_void = true)] > > > > to the class should do the trick/ > > I see a lot of these sorts of lines in the XML-RPC-C bindings of > pancake's and since there is no class in my genie code, I guess you > mean this code should go in here somewhere? Or do you mean inside > the xml-rpc-c code and recompile the library? > > I fear I am too wet behind the ears to figure out what to do with > that line. I've pasted pancake's xmlrpc.vapi file below - maybe the > line > > [CCode (cprefix="xmlrpc_value_", cname = "xmlrpc_value", > ref_function="xmlrpc_INCREF", unref_function="xmlrpc_DECREF", > free_function="")] > > has something to do with it? It sure does. the ref_function_void=true should just be added to the argument list. So change the line to: [CCode (cprefix="xmlrpc_value_", cname = "xmlrpc_value", ref_function="xmlrpc_INCREF", ref_function_void=true, unref_function="xmlrpc_DECREF", free_function="")] -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] mysql bindings in genie
On Fri, Sep 10, 2010 at 21:03:44 +1200, Phil Daintree wrote:
> # valac --pkg=mysql mysqltest.gs
> /tmp/ccumEU4F.o: In function `_vala_main':
> mysqltest.vala.c:(.text+0xb6): undefined reference to `mysql_init'
> mysqltest.vala.c:(.text+0xca): undefined reference to `mysql_close'
> mysqltest.vala.c:(.text+0x116): undefined reference to `mysql_real_connect'
> mysqltest.vala.c:(.text+0x13e): undefined reference to `mysql_query'
> mysqltest.vala.c:(.text+0x14c): undefined reference to `mysql_use_result'
> mysqltest.vala.c:(.text+0x160): undefined reference to `mysql_free_result'
> mysqltest.vala.c:(.text+0x178): undefined reference to `mysql_eof'
> mysqltest.vala.c:(.text+0x1de): undefined reference to `mysql_fetch_row'
> mysqltest.vala.c:(.text+0x27b): undefined reference to `mysql_close'
> mysqltest.vala.c:(.text+0x293): undefined reference to `mysql_free_result'
> collect2: ld returned 1 exit status
> error: cc exited with status 256
> Compilation failed: 1 error(s), 0 warning(s)
libmysqlclient does not have a pkg-config file, right? So you have to pass
the relevant linker flags yourself. That would be '-X -lmysqlclient' IIRC.
Normally if you specify "--pkg=something" to valac, it will use
"something.vapi", but it will also ask pkg-config for compiler flags needed
to compile against "something" ("pkg-config --cflags --libs something").
Unfortunately mysql client library does not seem to come with appropriate
data file for pkg-config. Instead it seems to have mysql_config script, that
serves similar purpose, but valac is not able to call these custom scripts.
Therefore you have to specify the flags manually via -X. You have the headers
and libraries installed in default path, but you still need to specify at
least the library name.
> The mysql.h file is under /usr/include/mysql together with all the
> other mysql header files.
The header got included fine and the program compiled fine. The library is
what was missing, so the program failed to link.
--
Jan 'Bulb' Hudec
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] xmlrpc-c bindings for vala
On Sun, Sep 05, 2010 at 11:13:36 +1200, Phil Daintree wrote:
> # valac --pkg xmlrpc-c xmlrpc-test.vala
> xmlrpc-test.vala:18.7-18.11: error: The name `ARRAY' does not exist
> in the context of `print_value'
> case ARRAY:
> ^
Vala (like C#) places enum constants in the enum type scope, not like C/C++
in the surrounding scope. So the constants need to be qualified with their
type.
> I can see in your xmlrpc-c.vapi
>
> [CCode (cname="xmlrpc_type", cprefix="XMLRPC_TYPE_")]
> public enum Type {
> INT,
> BOOL,
> DOUBLE,
> DATETIME,
> STRING,
> BASE64,
> ARRAY,
> STRUCT,
> C_PTR,
> NIL,
> I8,
> DEAD
> }
So you need to write:
case Type.ARRAY:
or even
case Xmlrpc.Type.ARRAY:
if the above turns out to be ambiguous (which it easily is, since "Type" is
quite generic, so it may easily end up being imported from more than one
namespace).
Dtto for the other cases, of course.
--
Jan 'Bulb' Hudec
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] About sockets
On Fri, Aug 27, 2010 at 15:47:31 +0200, Leoncio Gil wrote: > I am making a local server that can manage the works without configure the > IP on the clients, thanks to "broadcast". But I have a problem. I have make > a Python test app, but I don't found any equivalence of [setsockopt] to set > SO_BROADCAST in Vala (Gio). Any idea?. I suppose you'll have to ask on the glib mailing list. > If it is imposible, any alternative to [.send_to] without the problem of > "access denied" that gives in the broadcast address. Well, you can use the POSIX api directly, but the correct declaration for setsockopt is still missing from posix.vapi too, so you'd have to add it somewhere. -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [ANNOUNCE] Vala 0.9.6 - Compiler for the GObject type system
On Sat, Aug 21, 2010 at 19:11:28 +0200, JM wrote: > No. Actually I don't have a valac coming with my distribution. > > But, more interestingly, why isn't the path in for the binaries/*.la set > up with the PREFIX chosen by the administrator, who compiles and > installs vala as Ildar said? > > As Jan Hudec mentions so loudly: "...libtool is supposed to generate > appropriate -rpath option to ld based on path it has recorded in the .la > file ..." Well, because you are installing to a prefix that is mentioned in /etc/ld.so.conf. And it is only supposed to set rpath if it wasn't. In the standard library directories, the normal lookup order is to be followed, so the tools don't disturb it by generating rpath. > So, am I getting something wrong here or will it be possible to > automatically setup vala right and working by using the right autotools > command even without calling ldconfig from the makefile? > > I'm no expert with the linking and libtool stuff, I might gotten > something wrong here. You are supposed to call ldconfig after manually installing anything that comes with a library. That's just the way it is. Package managers do it automatically, but automake's default install target does not. -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] _get_type() and G_GNUC_CONST
On Wed, Aug 18, 2010 at 22:43:27 +0200, Aleksander Wabik wrote: > In glib doc for G_GNUC_CONST macro: "A const function doesn't examine > any values except its parameters, and has no effects except its return > value." > > In 10-years-old mail: > http://mail.gnome.org/archives/gtk-devel-list/2001-May/msg00174.html > > "_get_type() functions do have side effects, that of registering > a type upon first invocation." > > So... as far as I can remember get_type() functions still has effect of > registering a type in the type system upon first call? So is > G_GNUC_CONST in vala-generated code valid? Yes, the code is valid. The point is that the function does not have any side-effects for any practical purposes as everything that may depend on the type being allocated either gets it from the function, or at least depends on something else that does. What the annotation means to compiler is that it is free to change the number of calls to the function, reorder it with respect to other calls and memoize it's return value for reuse. All of these optimizations are valid with type getters, so the annotation is correct there. -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [ANNOUNCE] Vala 0.9.6 - Compiler for the GObject type system
On Wed, Aug 18, 2010 at 22:54:35 +0200, Nicolas Joseph wrote: > By default, /usr/local/lib isn't in LD_LIBRARY_PATH: Nothing is in LD_LIBRARY_PATH by default and it better stays that way. You meant /etc/ld.so.conf, didn't you? Now damn sure /usr/local/lib *IS* in /etc/ld.so.conf by default (at least in Debian - there might be some Linux distribution where it is not). > http://code.google.com/p/valide/wiki/FAQ?wl=en#libvalide-0.0.so:_No_such_file_or_directory This FAQ is just plain wrong. It needs to first and foremost mention trying to run ldconfig. If that does not help, users are not supposed to set their LD_LIBRARY_PATH anyway. Never. Ever. For installing to non-standard paths, libtool is supposed to generate appropriate -rpath option to ld based on path it has recorded in the .la file (that's why that file exists!). Failure to do so is a bug in libtool or a bug in it's use by the build system. -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [ANNOUNCE] Vala 0.9.6 - Compiler for the GObject type system
On Wed, Aug 18, 2010 at 23:11:26 +0200, JM wrote: > Is it really the solution to manually set LD_LIBRARY_PATH every time? > This is not recommended from various sources (e.g. > http://linuxmafia.com/faq/Admin/ld-lib-path.html) It's not recommended for a reason. You really shouldn't. > Also this wasn't necessary in the past. So why now? First, did you run ldconfig after installing vala (you have to do that as root)? It might be that you do actually have /usr/local/lib in /etc/ld.so.conf, but the dynamic linker does not list the directories at start-up of every program, relying on having the listing in /etc/ld.so.cache. Since new vala version installed new library, you have to update that file by running ldconfig. I have default /etc/ld.so.conf (in Debian) and it *DOES* contain /usr/local/lib, so running ldconfig might help. If it does not than I suppose autotools stopped generating rpath for some reason. You can force it by adding it to LDFLAGS (at configure time). I am not sure whether you need to pass it as "-rpath=/usr/local/lib" or "-Wl,-rpath=/usr/local/lib" though. It is basically equivalent to defining LD_LIBRARY_PATH, but applies to the binary rather than to a session. -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Access the "klass" parameter of a class_init() function in vala with "static construct"
On Sat, Jul 31, 2010 at 11:30:19 -0700, Evan Nemerson wrote: > On Sat, 2010-07-31 at 17:59 +0200, Sébastien Wilmet wrote: > > Hello! > > > > What I want to do is to implement a GtkAction derived class which sets > > GtkActionClass:toolbar_item_type to GTK_TYPE_MENU_TOOL_BUTTON in its > > class_init function. > > Vala doesn't currently expose *Class structs in the bindings, so AFAIK > what you're talking about can't be done easily. Sure it can. The class_init function can be defined as 'class construct' block. The class can have 'class' variables, which are shared for all instances, but separate for subclasses and 'class' methods, that take the *Class struct as their invocant. GtkActionClass:toolbar_item_type is a case of 'class' variable. -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] error: too many arguments to function
On Wed, July 21, 2010 15:41, Dru Moore wrote: > Hi all, > > Not sure if this is a bug or user error, but I am getting an error > from the c compile stage of my program: > error: too many arguments to function > 'hildon_wizard_dialog_set_forward_page_func' > >>From hildon-1.vapi file > > public void set_forward_page_func (Hildon.WizardDialogPageFunc > page_func, void* data, GLib.DestroyNotify destroy); This is a bug. It should be: public void set_forward_page_func (owned Hildon.WizardDialogPageFunc page_func); The data and destroy arguments are implicit in that. > Form my vala source > > this.set_forward_page_func(forward_page_function, &app_settings, > (GLib.DestroyNotify)destroy_notify); Obviously when the 2 extra arguments go away here, they'll go away in your code too. It will be: set_forward_page_func(this.forward_page_function); Note, that there should be no "data" argument in the Hildon.WizardDialogPageFunc declaration either. The C function has it, but it's used to pass the invocant if passing method or the closure if you pass closure. -- - Jan Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] enum values and scopes
On Tue, Jul 13, 2010 at 11:52:29 +0200, andi wrote:
> Hello list!
> When I have an enum like
>
> enum TrackState {
> PLAYING = 0,
> PAUSED,
> STOPPED
> }
You'd never write this in C++ and less so in C, right? You'd have to write:
enum TrackState {
TRACK_STATE_PLAYING,
TRACK_STATE_PAUSED,
TRACK_STATE_STOPPED,
};
> and do the following
> TrackState state = PLAYING;
> I'll get an error, because valac does not search for possible values in
> the scope of TrackState. Instead I have to write
> TrackState state = TrackState.PLAYING;
>
> To my mind that's not convenient and also not the way c or c++ does it.
It is, however, the way C# and Java do it and they do it for a reason.
The problem is, that when you have more than 2 enums, some of their values
will probably conflict. Because every other enum usually needs NONE, LAST and
similar entries. It's much more readable to have them scoped with the type,
than to have to disambiguate them causing inconsistent naming all over the
place.
> In my real world example TrackState lives in a class called GlobalAccess
> which is in the namespace Xnoise.
>
> So (provided I don't want to import Xnoise into the default namespace) I
> have to write
>
> if (ga.get_track_state() == Xnoise.GlobalAccess.TrackState.PLAYING)
> blabal();
>
> that's really not convenient and the worst part of it isn't even the
> typing but remembering the complete "path" to the final value.
It should be possible to import not only namespaces, but also specific types.
I am not sure importing inner type will work, but that would certainly be
reasonable thing to allow.
> if (ga.get_track_state() == PLAYING)
> would be much more readable, writable and memorizable.
> And when you want to use values from a different scope you can still
> prefix it.
> If I have just requested a feature that has already been discussed a
> thousand times, I'm sorry.
I can imagine a somewhat "dwimmy" feature to support what you want without
actually causing any conflicts, but it would be a bit complicated. The idea
is that when the compiler encounters an unknown symbol and it would know from
the context what type it wants to convert it to (because it's argument to
function or operator of known type), it would look for constant members of
that type. Except, as I say, it's very dwimmy and quite complicated.
--
Jan 'Bulb' Hudec
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Error in GLib.EnumClass binding (Re: Display values of an enum.)
On Sat, Jul 10, 2010 at 19:20:34 +, Peterpaul Klein Haneveld wrote:
> ---
> start of EnumTest.vala:
> enum EnumTest {TEST1, TEST2, TEST3}
>
> void
> main() {
> EnumClass enumClass = (EnumClass) typeof
> (EnumTest).class_ref();
> unowned EnumValue[] falues =
> enumClass.values;
> for (int i = 0; i < falues.length; i++) {
I believe vala supports foreach-style syntax here, but I am not certain
enough of the exact syntax to write it off the top of my head.
> unowned EnumValue falue = falues[i];
> stdout.printf("%s",
> falue.value_name);
> }
> }
> --- end of EnumTest.vala.
>
> $ valac EnumTest.vala
> /home/peterpaul/projects/vala/EnumTest.vala.c:
> In function ‘_vala_main’:
> /home/peterpaul/projects/vala/EnumTest.vala.c:45:
> warning: assignment from incompatible pointer type
> /home/peterpaul/projects/vala/EnumTest.vala.c:45:
> error: ‘GEnumClass’ has no member named ‘values_length1’
> error: cc
> exited with status 256
> Compilation failed: 1 error(s), 0 warning(s)
The warning can be safely ignored I believe (though it is a bug in valac --
it should know to emit correct cast). The error is caused by error in the
bindings.
The GLib.EnumClass.values member in gobject-2.0.vapi needs annotation:
[CCode (array_length_cname = "n_values", array_length_type = "guint")]
(the same annotation is correctly used in other places in the file, e.g. the
ValueArray class).
The Glib.FlagsClass.values member needs the same annotation, too.
--
Jan 'Bulb' Hudec
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] workaround for assignment from incompatible pointer type
On Sat, Jul 10, 2010 at 02:29:16 +, James Moschou wrote:
> Hello,
>
> I'm trying to subclass Clutter.Actor, I have:
>
> public override void allocate (ActorBox box, AllocationFlags flags) {...
>
> which generates:
>
> static void text_view_real_allocate (ClutterActor* base, ClutterActorBox*
> box,
> ClutterAllocationFlags flags) {...
>
> However at the line where this gets assigned to the class pointer, it has the
> error: "warning: assignment from incompatible pointer type".
That would be a bug. When vala accepts to compile something, it should not
generate these warnings.
> I think because the class pointer is expecting a "const" in front of
> "ClutterActorBox *box".
No. Const can be added by assignment without any warnings. It can't be
removed, but the error would be different.
It's more likely the use of pointer to base vs. pointer to derived (since
C does not have inheritance, they are incompatible pointers for C compiler).
Can you please provide a simple test case where the problem appears? Report
a bug in bugzilla and attach the test there, please.
> Is this known?
There appeared many cases where this warning was generated in the past. Some
of them were fixed, some may have not been. Check the bugzilla whether you'll
see similar-looking bug there. If yes, just add your test case, if no, open
new bug.
> Is there a workaround?
You are not supposed to look at anything from the C compiler unless you are
binding C library for vala (writing a .vapi). So as long as it otherwise
works, disable C compiler warnings (you can tell valac to pass appropriate
options with '-X' (so e.g. '-X -w').
--
Jan 'Bulb' Hudec
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] naming issue with abstract async functions
On Thu, Jul 08, 2010 at 18:41:40 +0200, JM wrote:
> Hello
>
> I have the following programm:
>
> public abstract class AbcAbstr : GLib.Object {
> public abstract async void test_async();
> }
>
> public class ABC : AbcAbstr {
> public override async void test_async() {
> print("test2\n");
> }
>
> public static void main() {
> var abc = new ABC();
> abc.test_async();
> new GLib.MainLoop().run();
> }
> }
>
> The compilation leads to the following problem:
>
> /home/me/Desktop/testasync.vala.c: In function
> ‘abc_abstr_test_async_finish’:
> /home/me/Desktop/testasync.vala.c:93: error: ‘AbcAbstrClass’ has no
> member named ‘test_async_finish’
> error: cc exited with status 256
> Compilation failed: 1 error(s), 0 warning(s)
>
>
> If I change the function name from "test_async" to "test_asyn" it
> works.
> Is that a bug or is this something that is coming from a design towards
> the usage with gio's functions?
I believe it is a bug in the name mangling. An async function is really
three functions -- the start function that initiates the operation, finish
function that retrieves the result and the callback that does the real work.
The name of start function is the same non-async function would get and the
finish function has '_finish' appended. However, if the function name ends
with '_async', it is stripped first (to follow GLib convention). It seems
this stripping is not done consistently when overriding abstract or virtual
async methods. It looks like a bug in vala.
--
Jan 'Bulb' Hudec
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] How to abort sorting in Gee.ArrayList?
On Sun, Jun 27, 2010 at 15:25:34 +0200, synkro wrote: > Most sorting algorithms don't like being aborted. Aborting sorting > also means that not perfectly sorted data is acceptable. I suggest > bubble sort, it's not fast but easily aborted. Have you noticed the *millions of entries* statement? Than how can you even think about bubble-sort?!?! Obviously any algorithm would be equally easily cancellable unless it's written as recursive function and even that wouldn't be too hard. Using the vala support for async functions (remember, they are stopped and restarted at the yield and cancelling just means not restarting them...) it should be mostly simple. -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Interfaces and Mixins
On Tue, Jun 15, 2010 at 16:09:06 -0700, Robert Powell wrote: > On Tue, Jun 15, 2010 at 4:00 PM, tecywiz121 wrote: > > Actually in my other interfaces, it works fine. I'm just not sure if > > I'm allowed to override a method declared in Flushable in Entity. > Do your other interfaces derive from another interface? I think that is > where trouble lies, or used to lie. Well, the problem is that interfaces don't derive from each other, they *depend* on each other. They therefore can't override each other's method -- they can only call them. I think the best you can do is to have a helper method in the Entity interface and use it to implement Flushable in the concrete class. -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Unit Testing and Code Coverage
Hello, On Thu, Jun 10, 2010 at 19:19:02 +0200, CaStarCo wrote: > My question is: ¿there's a way to sistematize the unit testing in Vala? I created something half a year ago. Look at http://gitorious.org/valadate Unfortunately I didn't have time to work on it or anything that would really use it, so it's still quite rough around the edges. Or you can use the Glib.Test stuff directly, but it's even more rough. The glib test system does not support continuing after a failed assertion. Unfortunately I based valadate on the glib test system, so it currently exits on first failure too. I thought about forking the test cases to provide proper isolation and allow continuing after failure, but the tool provided by Glib.Test is not very convenient and I didn't get around to getting it to work properly yet. > and.. ¿exists tools to see the code coverage of the tests? Nothing specific to vala as far as I know. gcov should work, but you'll have to match the output back to the vala source manually. gcov probably honors #line annotations, so it should be actually possible to tell it to report back the original lines, but AFIK vala does not emit these annotations. -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Rules for updating generated C files
On Tue, Jun 08, 2010 at 22:58:09 +0200, Jürg Billeter wrote: > On Tue, 2010-06-08 at 13:36 -0700, Robert Powell wrote: > > You snipped the important bit "For this simple system, it would be easy > > enough to update the makefile to watch for this dependency." It was meant > > to illuminate the fact that when systems get larger, trying to maintain > > dependencies becomes terribly complicated. I would never ever consider maintaining the dependencies manually an option even for single source. The techinque using gcc -M is reasonably easy and reliable. > > I suggested a solution for the problem. Unfortunately it was not a solution. If the dependent code is compiled in separate step and the chage does not induce change in content of the .c file, valac wouldn't know to touch the output anyway. > > Does anyone have any better > > suggestions (other than use automake--automake is not an option for our > > projects here) for dealing with larger systems? > > You could use a similar approach and use gcc -M or makedepend to > generate Makefile rules describing header file dependencies. The > Makefiles would certainly get a bit more complicated but it should be > possible and not require manual dependency maintenance. If that's > possible, I'd prefer to keep the simple update logic we currently have > in valac. As far as I can see there is no way to detect dependencies correctly short of full preprocess of the C file. That is IMO outside of scope of valac. On the other hand valac is able to call the C compiler itself and it should make sure the output is rebuilt correctly when it does. It recompiles everything everytime though, no? -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Rules for updating generated C files
On Thu, Jun 03, 2010 at 14:13:01 -0700, Robert Powell wrote: > What is going on here > --- > We have a library BaseClass.vapi that is generated from BaseClass.vala. > This defines the class BaseClass. We also have Derived.vala, which defines > a class that derives from BaseClass. > > If a member variable is added to BaseClass, BaseClass.vapi will change. The > C file that is generated from Derived.vala will be identical, but it needs > to be recompiled because the base class has changed. valac will not > regenerate Derived.c because it hasn't changed. The Makefile in your example is hopelessly broken. Derived.c has not changed, but it certainly includes BaseClass.h which must have had. The makefile fails to see that Derived.o depends on BaseClass.h and the fix should be to make the makefile directly aware of the fact. That way it can detect when not-vala-generated headers change which vala can't, because not every significant change in the header needs to be reflected in the corresponding .vapi (e.g. changing symbolic constants won't). It is different matter for the case where valac itself calls the C compiler. If it fails to do the dependency resolution right (and I expect it would fail), it's a bug. That's not what your example demonstrated, though. Note that automake automatically considers dependency on (directly or indirectly) included headers by asking the preprocessor to generate the additional make rules as side-effect of the compilation and most non-make build systems (like cons, scons, cmake, makepp,...) have special parsers to look for include dependencies. -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Vala GIO sample remark
Hello,
On Thu, May 13, 2010 16:06, Alexander Semenov wrote:
> I'm looking at Vala GIO samples here:
> http://live.gnome.org/Vala/GIOSamples
>
> Don't you think that null-check like
>
> var files = yield e.next_files_async (10, Priority.DEFAULT, null);
> if (files == null) {
> break;
> }
>
> is redundant in "Asynchronous File Listing"
No, because null is how empty list is implemented.
> example since the
> "next_files_async" method signature is:
>
> public virtual async List next_files_async (int num_files, int
> io_priority, Cancellable? cancellable)
Non-nullable GLib.List makes no sense, because that would mean it may
never be empty.
GLib.List is somewhat tricky, because it does not represent the collection
as a whole, but rather an iterator to it and the collection does not have
any representation as a whole at all. So to represent nothing, null is all
that is left.
> ? Actually when --enable-experimental-non-null option is used it will
> not compile - the return value isn't nullable and cannot be compared to
> null.
Than that's a bug in the vapi.
--
- Jan Hudec
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] MySQL access from vala
On Thu, May 06, 2010 at 20:51:07 +0300, Ndubi Abenga wrote: > Field[] fields = result.fetch_fields (); > [...] >mysql_connection.c:179: error: too many arguments to function > ‘mysql_fetch_fields’ > > The offending C code is this right here: > > *179:*fields = (_tmp2_ = mysql_fetch_fields (self->priv->result, * > &_tmp1_*), fields_length1 = _tmp1_, _fields_size_ = fields_length1, _tmp2_); > > and deleting the &_tmp1_ leads to successful compilation. Is this a bug, or > is there something I'm missing? That would be a bug in the bindings. For normal array passing, Vala expects to receive the pointer as return value and the length by reference. If that's not the case (I suppose it returns NULL-terminated array, right?), the return value needs some attributes. It will need [CCode (array_length = false)] like you can see two lines below. If it's indeed NULL-terminated, it will also need "array_null_terminated = true", so together [CCode (array_length = false, array_null_terminated = true)] and I suppose the caller is not responsible for freeing the pointer, so I guess it will also need unowned (like two lines below). Check the documentation, try out and share the results. Regards, Jan -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Singleton and reference count
On Thu, Apr 29, 2010 at 13:53:40 -0400, Sam Wilson wrote: > On Thu, 2010-04-29 at 18:55 +0200, Jan Hudec wrote: > > Hello, > > > > On Wed, April 28, 2010 13:46, Jan Niklas Hasse wrote: > > > On Wed, Apr 28, 2010 at 11:31 AM, pancake wrote: > > >> On Apr 28, 2010, at 10:24 AM, Jan Niklas Hasse wrote: > > > > > > So shouldn't Vala unref namespace scoped variables when leaving their > > > scope? > > > > IMHO there is no reason to do it. The compiler could do it (using the > > atexit mechanism) but than there are many ways the process can terminate > > without calling them anyway (calling _exit, receiving fatal signal, the > > power > > going out etc.). Therefore the program shouldn't rely on them for anything > > important anyway and since system will clean up resources anyway, they are > > not needed for that either. So IMHO supporting them would just promote > > unreliable code and is thus not worth doing. > > > > This is an important feature, and I don't see how it promotes unreliable > code. It is occasionally useful, but I don't really think it's important. I worked on couple of applications already where the normal way of exiting was reset of the device. Most applications for handheld and embedded devices are like that. But during development on desktop, these applications do get shut down "correctly", invoking destructors of all the singletons. Now whenever somebody relies on that, it will seem to work in testing just to get to production to fail there. > In the event that the program terminates normally, libraries and 99.9% of libraries implemented in C never ever bother. > globally defined objects should be destroyed properly. That way they can > flush buffers, For stdout it makes sense. But stderr is another matter (you do want that after abnormal termination, so it needs to be line-buffered) and files need to be closed explicitly anyway. > or terminate network connections cleanly. Either you need to send some closing command -- which you better do explcitly and explicitly wait for reply and process it -- or you just need to close them in which case you don't really need to bother, because the system will do it equally well. > Isn't that the > point of the RAII pattern? No. RAII is for things in dynamic scope to ensure the program does not leak resources while running. It is extremely useful there and vala implements it just fine. But you simply don't need to release resources when you are exiting anyway. > When a program is killed (or otherwise terminates abnormally) it is a > special case, and needn't be handled by the compiler. Well, it can't be. There is simply nothing that can be done if power goes out. One instruction everything is fine and the next one never gets to execute. > I don't see a problem using atexit to implement this feature. I don't see it either. Except it's nontrivial amount of work somebody has to do, for which they'll need motivation and I personally don't see sufficient benefit in it. > IMHO vala should try and be as consistent as possible, and having to > manually destroy global variables is not consistent with the rest of > vala's memory management. Being as consistent is possible is nice. But for destroying the global objects, flushing stdout seems to be the only reason I can seem to find. (Checking for memory leaks excluded, because GLib won't free it's internal buffers anyway). -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Generating bindings for non-GLib/GObject based API
On Sun, Apr 25, 2010 at 11:46:17 +0200, Michael Wild wrote: > On 23. Apr, 2010, at 22:29 , Jan Hudec wrote: > > Actually I believe > > > >[Compact] > >[CCode (cname = "void", ...)] > >class Thing ... > > > > should work. It will give you void * passed around, so it's some kind of > > pointer and C implicitly casts to and from void *, so no errors and no > > warnings. > > I don't think that I'd like that one particularly... I'd rather prefer to > use a Vala wrapper class then. > > > > > You can also just make it > > > >[Compact] > >[CCode (cname = "struct unknown_type", ...)] > >class Thing ... > > > > with the real value for "unknown_type" from the library header. That will > > make the code more type-safe on the C side, but vala will check the types > > enough and it would be relying on something not officially documented. > > Unfortunately that's impossible. The official standard states that there is > a opaque type Thing, but nothing more. Every implementor is free to do as > he pleases... Some even typedef it to an integer handle. The void case would be OK if you knew it is always a pointer. But if it's a handle of any type, than you'll have to make it a "[SimpleType] struct" (SimpleType means it's passed by value). Than you can try whether setting a copy_function and destroy_function on a simple type will do what you need and otherwise you'll just have to wrap it in a normal vala object. -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Singleton and reference count
Hello, On Wed, April 28, 2010 13:46, Jan Niklas Hasse wrote: > On Wed, Apr 28, 2010 at 11:31 AM, pancake wrote: >> On Apr 28, 2010, at 10:24 AM, Jan Niklas Hasse wrote: >> >>> 2010/4/28 Sam Wilson : >>>> >>>> The only questionable part is that vala doesn't unref namespace scoped >>>> variables when the program terminates, so you have to do that >>>> manually. >>> >>> Is Vala using Garbage Collection? >> >> Nope > > So shouldn't Vala unref namespace scoped variables when leaving their > scope? IMHO there is no reason to do it. The compiler could do it (using the atexit mechanism) but than there are many ways the process can terminate without calling them anyway (calling _exit, receiving fatal signal, the power going out etc.). Therefore the program shouldn't rely on them for anything important anyway and since system will clean up resources anyway, they are not needed for that either. So IMHO supporting them would just promote unreliable code and is thus not worth doing. -- - Jan Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] GtkSourceCompletion segfault
On Mon, Apr 26, 2010 at 14:31:35 +0200, Nicolas Joseph wrote:
> Hello,
>
> I test GtkSourceCompletion (include in GtkSourceView 2.10) and I rewrite in
> vala this example:
> http://git.gnome.org/browse/gtksourceview/tree/tests/test-completion.c?id=GTKSOURCEVIEW_2_10_0
>
> I have a bug for add custom proposals (GtkSourceCompletionWords works fine
> except a bug in the binding) as if they were freed, but I don't find problem
> with valac.
>
> The bug make a segfault:
>
> *** glibc detected *** ./main: double free or corruption (fasttop):
> 0x023d5110 ***
>
> Or warning:
>
> Gtk-WARNING **: Failed to set text from markup due to error parsing markup:
> Error on line 1 char 13: Invalid UTF-8 encoded text in name - not valid
> '\xe0F\xd3\u0001'
>
> Have you an idea?
Maybe. It complains about "name" being wrong, right? So let's have a look at
what name is.
> class TestProvider : Gtk.SourceCompletionProvider, Object
> {
> public unowned string get_name ()
> {
> return this.name;
> }
> }
However, the original code says:
static gchar *
test_provider_get_name (GtkSourceCompletionProvider *provider)
{
return g_strdup (((TestProvider *)provider)->name);
}
which clearly implies the caller is going to free the string, so it's owned.
This can be confirmed by reading the documentation.
That seems like Gtk.SourceCompletionProvider binding is incorrect.
I can't find a .vapi binding that class -- where does it come from?
--
Jan 'Bulb' Hudec
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Generating bindings for non-GLib/GObject based API
On Fri, Apr 23, 2010 at 09:36:18 +0200, Michael Wild wrote:
> Another thing where I'm not sure how to best solve it: The basic C-type I'm
> using is a typedef to a pointer whose base-type is implementation dependent
> (i.e. unknown). E.g. like this:
>
> typedef struct unknown_type* Thing;
>
> Now, in my small test cases, I used the following for the binding:
>
> [SimpleType]
> [CCode (cname = "Thing", cheader_filename = "thing.h", free_function =
> "free")]
> struct Thing {
> [CCode (cname = "create_thing")]
> private static int create_imp(Thing* self, int a, int b, double c);
> [CCode (cname = "create_thing_wrapper")]
> public static Thing create(int a, int b, double c) {
> Thing self;
> int stat = create_imp(&self, a, b, c);
> return self;
> }
>
> [CCode (cname = "print_thing")]
> public void print();
> }
>
> This compiles and runs, but Vala now (quite understandably) thinks that
> Thing is a value-type and doesn't call free() on it. AFAIK for this to
> happen I'd need to change Thing to be a of compact class type, but then
> everything else would break because Vala starts passing the object around
> as a pointer (i.e. resulting in unknonw_type**, where unknown_type* is
> expected).
Actually I believe
[Compact]
[CCode (cname = "void", ...)]
class Thing ...
should work. It will give you void * passed around, so it's some kind of
pointer and C implicitly casts to and from void *, so no errors and no
warnings.
You can also just make it
[Compact]
[CCode (cname = "struct unknown_type", ...)]
class Thing ...
with the real value for "unknown_type" from the library header. That will
make the code more type-safe on the C side, but vala will check the types
enough and it would be relying on something not officially documented.
You may also need to set the [CCode(copy_function=...)] or explicitly tell
vala that it can't be copied via [CCode(has_copy_function=false)].
On a side note, structs normally have destroy_function rather than
free_function, but I am not sure there is a difference.
--
Jan 'Bulb' Hudec
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] I need to print Gdk.NativeWindow as an actual value, how do I print it?
On Thu, Apr 22, 2010 at 14:54:19 +0300, Arkadi Viner wrote:
> By the way, in terminal it prints out:
> (valide:3060): Gtk-CRITICAL **: gtk_socket_get_id: assertion
> `GTK_WIDGET_ANCHORED (socket)' failed
> Socket ID=0
The GTK_WIDGET_ANCHORED is checking whether there is a top-level window for
this widget. You apparently forgot to place the scrolled_window to
a top-level Gtk.Window. A widget must be descendant of top-level window to be
'realized', that is have a NativeWindow assigned.
> On Thu, Apr 22, 2010 at 2:31 PM, Arkadi Viner wrote:
>
> > private static Gtk.Socket sock;
> >sock = new Gtk.Socket();
> > sock.show();
> > this.scrolled_window.add_with_viewport(sock);
> > stdout.printf("Socket ID=%ld \n", (long)sock.get_id());
> >
> > it prints - "Socket ID=0"
> >
> > some how in Python, this line prints an actual number on a screen:
> >
> > print "Socket ID=", socket.get_id()
> >
> >
> > How do I properly do it?
> >
> > Thanks in advance.
> >
> ___
> vala-list mailing list
> vala-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/vala-list
--
Jan 'Bulb' Hudec
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Generating bindings for non-GLib/GObject based API
On Thu, Apr 22, 2010 at 11:47:21 +0200, Michael Wild wrote:
> 1) Constructor function: Say I would like to use a C function as the
> constructor for a class (as e.g. newwin is used in curses.vapi). However,
> that C function does not return the allocated and initialized object in the
> return value, but as the first argument. The return value is an error code
> instead. How would I handle this?
I believe you'll have to declare it as a static function and wrap it as
constructor in the .vapi itself.
I suppose you have a function like:
int thing_init(Thing **self, int param);
(allocate+return by reference implies pointer-to-pointer, right?)
Than in the class you first declare the function itself, like
class Thing {
private static init(out Thing self, int param);
Than you need to define the constructor, which is where I am a bit lost.
It does work for normal methods, but constructor is a bit special.
I would guess this might work:
public Thing(int param) throws ThingError {
int status = init(this, param);
if(status != 0)
throw new ThingError.FAILED(
"Thing construction failed with status %d", status);
}
But I am not sure whether you need to initialize this or create normal
variable and return it or employ some other trick. Maybe defining another
static function and than rebinding it as constructor. Something like
public static Thing new(int param) throws ThingError {
Thing self;
int status = init(self, param);
...
return self;
}
public Thing(int param) throws (ThingError);
You'll have to play with it a bit.
Note, that I made it throw an error. I assume if it returns an error code,
you'll want to get it somehow and since the allocated object is the return
value, an exception is the only option.
> 2) Delegates: The C API defines a number of callback functions, most of
> which take some user-defined data as an argument one registers along with
> the callback function. However, the user data is often neither the first
> nor the last argument. How can I wrap this?
Declare a delegate type with the [CCode(instance_pos)] as you've been
already instructed. Vala will auto-generate appropriate wrapper function to
reorder the arguments.
--
Jan 'Bulb' Hudec
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] GObject-introspection and vapi
Hello, On Tue, April 13, 2010 07:51, Arc Riley wrote: >> >> 1) Is the .gir expected to be equivalent to the .vapi, i.e. is it >> supposed >> to >> >contain all information needed to create the .vapi > > > No. One of the biggest feature gaps in .gir is you cannot have nested > namespaces, everything in your .gir must exist inside the same > single-level > namespace. Vala supports many namespaces and nested namespaces. That difference does not imply negative answer to the above question. Ok, I should have said "a .vapi", because there's no need to get it from the .gir exactly, just good enough to work. So if .gir does not have nested namespaces, the resulting vapi either won't have them either or it will demangle the c:prefix of the namespace instead of using the gir name. It's similar with the async functions. Gir is not able to represent those, but you know when you see a function with GCompletion as last argument and another function with _finish suffix, you can replace them with a single async. So to state the question more precisely: Is there any construct, that vala could generate and describe in a .vapi, but given just the .gir there is no way to use it at all? I think that gir is not able to express composite (array and delegate) arguments in non-standard order (as can be done with CCode attribute in vapi), but I can't think of anything when not using CCode attributes. -- - Jan Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] ellipsis forwarding
On Fri, Apr 16, 2010 at 14:27:24 +0200, JM wrote:
> Hello
>
> Is there anybody who made has some experiences with ellipsis?
> I wrote the following code:
>
>
> void add_vals(string first_property_name, ...) {
> var l = va_list();
> print("\n1:\t%s-%s\n\t%s-%s\n\n",first_property_name,
> l.arg(), l.arg(), l.arg());
^^
Unspecified order of evaluation here.
Function arguments may be evaluated in arbitrary order at compiler
discretion. It is that way in C and because of the way vala generates C code,
also in vala. Because of the way arguments are placed on the stack, the
compiler is likely to evaluate them last to first and that's what's happening
to you here. You'd have to write:
var arg1 = l.arg();
var arg2 = l.arg();
var arg3 = l.arg();
and than
print(..., first_property_name, arg1, arg2, arg3);
to enforce the evaluation order.
> add_vals_valist(first_property_name, l);
You are calling add_vals_valist like it was declared:
void add_vals_valist(string first_property_name, va_list args)
> }
>
> void add_vals_valist(string first_property_name, ...) {
> var l = va_list();
Therefore l contains *one* argument of type va_list!
> print("\n2:\t%s-%s\n\t%s-%s\n\n", first_property_name,
>l.arg(), l.arg(), l.arg());
> }
>
> static int main() {
> add_vals(
> "first", "first_val",
> "second", "second_val",
> "3rd", "3rd_val",
> null
Your function, despite being variadic, will always read exactly four string
arguments.
> );
> return 0;
> }
>
>
>
> It leads to the following output:
> $./ellipsis_forwarding
>
> 1:first-second_val
> second-first_val
The compiler did indeed choose to evaluate the arguments last to first.
That's because the last arguments goes deepest in the stack (the other way
arount variable arguments would not be possible). It may decide to do it in
some other order at another time depending on what the optimizer evaluates as
best.
> [Invalid UTF-8]
> 2:first-second
> (null)-\xea\x87\x04\x08\xe2\x87\x04\x08
The last part is result of interpreting the content of the va_args as string.
The rest is just arbitrary stuff from local variables of the calling
function, which happened to be sufficiently valid pointers not to crash the
program. If there was a non-pointer value there, you could have easily got
a segmentation fault.
--
Jan 'Bulb' Hudec
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Compile failed on .gir file
On Wed, Apr 14, 2010 at 22:52:01 +0200, Geert Jordaens wrote: > >On Wed, Apr 14, 2010 at 18:18:33 +0200, Geert Jordaens wrote: > >>Hello, > >> > >> I've tried to compile folowing code : > >> > >>/* > >>valac -o G --pkg Gee-1.0 G.vala > >>*/ > > To fix some of the errors with the gir file I changed the > valagirparser/valagirwriter > Should I create a bug report for it? I'd say yes. > [... patch snipped ...] -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Compile failed on .gir file
On Wed, Apr 14, 2010 at 18:18:33 +0200, Geert Jordaens wrote: > Hello, > > I've tried to compile folowing code : > >/* >valac -o G --pkg Gee-1.0 G.vala >*/ The package is called gee-1.0, NOT Gee-1.0. The error you got with .gir files is somewhat surprising to me, but still the package names are usually lower-case (package name is the name of the corresponding .pc and .vapi files). -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] GObject-introspection and vapi
Hello, Returning the thread to the list, since it might be useful for other people too. On Mon, April 12, 2010 23:24, Marc-André Lureau wrote: > Did you succeed in making a vapi for gobject-introspection? I did, at least for the bits I needed. I've placed it on gitorious: http://gitorious.org/valadate/valadate/blobs/master/vapi/gobject-introspection-1.0.vapi (link to raw data: http://gitorious.org/valadate/valadate/blobs/raw/master/vapi/gobject-introspection-1.0.vapi) Unfortunately I wrote it manually. It seemed less work than >> 1) Is the .gir expected to be equivalent to the .vapi, i.e. is it >> supposed to contain all information needed to create the .vapi >> (if it was correct, which it isn't, but that's another matter >> -- but it would mean I should be fixing the .gir or the annotations >> they use to generate it). Well, it should be (since it's supposed to allow using all functionality of the library), if it was correct. However, many of existing .gir files are not correct and since the format is not properly documented either it's sometimes hard to guess how some of it's constructs should properly translate to .vapi. >> 2) Is the .gir documented somewhere? I tried looking at the >> GObjectIntrospection web, but didn't find it. I only found >> documentation >> of the annotations. Which does not tell me important things like how >> to tell the generator that the structs it sees are actually gobjects >> (there is a bunch of things annotated as that are gobjects >> when I look at the header). Nothing much really. I was eventually able to use the .gir file generated by valac by comparing it to the .vapi file for the same code, which was enough for what I needed at that point. >> 3) I don't think a should be treated as struct, because the >> GLib-2.0.gir from GI repository uses that to annotate all the >> non-gobject classes like IOChannel, which are reference types. >> So what is the correct way to handle them? (guess I can look into >> glib-2.0.vapi, right?) The problem is that many .gir files out there are no good, the one for gobject-introspection itself being the worst offender. This makes it kind of hard to guess what is correct interpretation of some .gir markup. -- - Jan Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] follow up to Houston we have a problem
On Thu, Apr 08, 2010 at 11:50:40 -0700, Karl Zollner wrote: > Ok shoot me. In my rush to be helpful I probably have cause some wasted > time. You do realize that since this is a follow-up, it should have really been one. I.e. created by "Reply All" on your original post. Do you? You know, some people do have threaded mail readers... Regards, Jan -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Houston we have a problem(gtk.builder signals not functioning)
Hello, On Thu, Apr 08, 2010 at 11:30:00 -0700, Karl Zollner wrote: > My first post here, please let me know if there is something wrong with how > this email appears, don't want to be guilty of top-posting or such, so kind > words of advice appreciated. Sorry to say, but there is something wrong. It's too long. Plus the subject is just dumb -- "Problem connecting Gtk.Builder signals" would do much better. Just state your problem in at most couple of sentences with a handful of relevant lines from your code. Also paste the code directly in the mail rather than attaching it. The attachments make it harder to read, especially when your mail client (incorrectly) marked them with application rather than text mime-type. See also http://www.catb.org/~esr/faqs/smart-questions.html > [... 60 more lines of dense text ...] Regards, Jan -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] nullable generic types
On Mon, Apr 05, 2010 at 14:10:23 -0700, Adam Dingle wrote:
> I've noticed that Vala forces generic types to be non-nullable when
> instantiated with a primitive type.
Quite the opposite. Generic types in Vala can only contain reference types or
int, so all other struct types need to be boxed using '?'. Enums and boolean
should behave like int for this purpose, but I am not sure it's currently
handled.
> For example:
>
> public class List {
> public T? abc() { return null; }
>
> public bool def(T? t) { return t == null; }
> }
>
> void main() {
> List list = new List();
> int? i = list.abc(); // i receives the value 0, not null
> bool b = list.def(null); // compiler error: cannot convert from
> null to int
> }
What is going on here is that boxing of the type parameter is not
supported since it has to be boxed. 'int' is a special case, which would need
special-case code and there's none generated.
> Is this behavior by design? I suspect that it is: this allows the
> compiler to generate only one copy of List and use it for all
> instantiations including both reference and primitive types. If
> this is a compromise by design, I think that it's a reasonable one,
> though it would be nice to know whether we can expect this behavior
> to remain the same in the future. :)
There is indeed only one code for List. That is so the generic code can be
placed in a library and used from separate code. In this it's similar to Java
generics and different from C++ templates that need to be fully defined in
headers.
> The above has a practical consequence when using generic collections:
>
> HashMap m = ...;
> int? i = m.get(5);
>
> Now i receives the value 0 (not null) if the element is absent.
It returns T, which is int, NOT int?, so you don't expect it to return null,
do you?
> On a related note, I've noticed that 'valac --vapi' makes generic
> types non-nullable. If I generate a VAPI file for the List class
> above it looks like this:
>
> public class List {
>public List ();
>public T abc ();
>public bool def (T t);
> }
>
> Is this a bug? Conceivably the nullable types are erased in the
> VAPI file as a warning to callers that they will not actually be
> nullable when the class is instantiated with a primitive type, given
> the behavior above. But there doesn't seem to be much point to
> that, since callers must expect this same behavior when nullable
> types are present in a generic class anyway, even one which is not
> defined via a VAPI file. Is there some other reason why the types
> should not be nullable in the VAPI file?
As explained above, T is always reference type, so T? makes no sense.
The generic is compiled with just void * and pointers to correct copy/ref and
destroy/unref functions are passed around. Since it is already pointer, it is
already nullable, so conversion to nullable does nothing. All types are boxed
to be representable by void *. Except int, which is simply cast to void *
(sizeof(int) <= sizeof(void *) on all platforms), but that makes it
non-nullable.
Note though, that you can substitute 'int?' as the template parameter and
than there will be difference between null and 0 (and a huge memory overhead
for allocating the storage).
--
Jan 'Bulb' Hudec
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] How to check what a Gee.List contains
On Sun, Apr 04, 2010 at 10:09:24 -0700, Tristin Celestin wrote:
> Is there a means to figure out what kinds of variables a Gee.List stores?
>
> The following doesn't work because if I call mystery_list.get(0), I get
> the compiler error: has no member named ‘g_destroy_func’.
Hm, that's bad compiler error. It should tell you that Gee.List is generic
and can't be used without the type parameter.
> using Gee;
>
> public bool perform (Gee.List mystery_list) {
> if (! mystery_list.is_empty) {
> Value val = mystery_list.get (0);
> if (val.type().is_value_type) {
> // something something
> }
> }
> }
>
> If I cast mystery_list to Gee.List , my problem is solved (because
> now a destructor is available), but then that means that mystery list
> can only contain items descended from GObject.
The list can't contain types not derived from common base. Simply because it
does not have any per-element type tag. It only has one for the whole list
(the type parameter).
If you really wanted to have a list of mixed non-Object items, you can get it
by creating a list of GLib.Value (it's a struct, so you'll have to box it by
writing Value?). Value can store anything and knows what it stores.
--
Jan 'Bulb' Hudec
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Vala on CentOS?
On Fri, Apr 02, 2010 at 09:44:47 -0700, Joseph Montanez wrote:
> [...]
> ./main: symbol lookup error: ./main: undefined symbol:
> g_compute_checksum_for_string
>
> [...]
> ./main: symbol lookup error: ./main: undefined symbol: g_once_init_enter_impl
Hm, the linker looks up all the symbols at compile (link) time. It didn't,
which suggests it had the symbols and it could only have them from another
version of the shared library in question. That would happen if you had two
versions installed and the compiler and dynamic linker disagreed in the order
of paths.
Also the compiler needed to see declarations of those symbols indicating that
the program was compiled against different (newer -- glib does decent job
with backward compatibility) version than is found at runtime.
> I tried "ldd" on the "main" executable and everything keeps linking to
> /lib64/ rather then /usr/local/lib:
> # ldd main
> libgee.so.2 => /lib64/libgee.so.2 (0x2aabe000)
> libjson-glib-1.0.so.0 => /lib64/libjson-glib-1.0.so.0
> (0x2ad06000)
> libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x003a50c0)
> libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x003a5000)
> libc.so.6 => /lib64/libc.so.6 (0x003a4e00)
> librt.so.1 => /lib64/librt.so.1 (0x003a4f40)
> /lib64/ld-linux-x86-64.so.2 (0x003a4dc0)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x003a4ec0)
First it might just be, that your ld.so.cache is stale. As root, try running
ldconfig
If it does not help, I suggest you check the library install directories of
packages you use, whether the undecorated .so files there point to the same
files as listed by ldd or not. You can find the directories in question by
looking at the -L options produced by
pkg-config --libs all-the-packages-you-use
It's likely they won't. So you have to tell the dynamic linker where to look
for the right files. There are three ways:
1. Set environment variable LD_LIBRARY_PATH to a list (':'-separated) of
directories which need to be searched before the default ones.
2. Record the directories, which need to be searched before the default ones
in your application at link time. To do that, pass '-rpath /path/to/lib'
option to the *linker*. That means getting it through gcc by escaping via
-Wl and through valac by escaping via -X, combining to rather convoluted
-X -Wl,-rpath,/path/to/lib
(once for each directory you need to add)
3. Globally change the settings of ld.so by modifying /etc/ld.so.conf and/or
adding entries to /etc/ld.so.conf.d. Than you have to run the "ldconfig"
command as root to update the cache. Beware, that it might, though
shouldn't if backward compatibility is properly maintained in the
libraries, break some other program.
I suggest you use 1. to try whether using some extra library directories helps
and which ones they should be and than probably just set the rpath (option
2.) to avoid breaking other stuff.
--
Jan 'Bulb' Hudec
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Locking null references
On Tue, March 30, 2010 11:47, "Andrés G. Aragoneses" wrote: >> decided to use different lock statement semantics compared to C#. The >> only other option would have been to not support lock statements at >> all . > > Well, I'm wondering about a 3rd option which would be a compromise: that > vala translate every lock statement with a minimal null-check first, so > if the condition is not met, an exception is raised? What do you think > about this approach? Utterly, absolutely wrong. As long as it locks the field, it should lock it no matter what value it has. It is not guarding against change in the refered object anyway! >[...] >> Yes, it's unfortunate that we can't properly support lock(this) as >> GObject doesn't support it and we can't just add a mutex field to >> instance structs as this would result in issues when using lock(this) in >> subclasses. Otherwise, I'd probably recommend using lock(this) in most >> cases. Since most objects won't ever need to be used with lock() (in any language), it's IMHO bad design to have a universal lock statement working with anything. Personally I am not sure lock() is a reasonable thing to do. IMHO too many (all) things being lockable just make it easier to forget what should be locked when. For me, using() statement working with Mutexes seems sufficient. Alternatively it should be possible to implement Monitor without needing a member in the synchronized object (I would expect CLR to actually do it that way, because the overhead for having mostly unused mutex in every object would be quite high). A simple idea is to have a collection of the currently locked objects with a condvar. A simple implementation would be slow because of the global lock, but a mostly efficient implementation should be doable (though system-specific). -- - Jan Hudec ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Fail to generate C code for following vala code, is this a bug?
On Sat, Mar 27, 2010 at 19:28:30 +0800, PCMan wrote: > Thanks you guys for the help. > I use my own modified version of gio.vapi and remove the *_finish > functions from those interfaces. Then, it works. > Although I don't know why it works. Thank you again. Because they shouldn't be there. The 'async' function is really a pair of functions. The main one, that starts the work and the _finish one, that collects the results. Now before vala got async function support, those two functions were bound separately and used manually just like you'd use them in C. And when the .vapi was updated to use the async feature, the _finish functions were simply forgotten there. -- Jan 'Bulb' Hudec ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Fail to generate C code for following vala code, is this a bug?
On Sat, Mar 27, 2010 at 03:57:26 +0800, PCMan wrote: > > So, the problem is that the function return values are falsely > > marked as unowned in the VAPI. I reported a bug for it at > > https://bugzilla.gnome.org/show_bug.cgi?id=614044 > > > >> However, with Vala, how can I make vala methods return a "newly > >> allocated GList" with all objects in it having increased ref_count? > >> Automatic ref couting management in Vala is handy if you only use it > >> in Vala but I find it difficult to make things right when interfacing > >> with C code. I need to check the generated C code to see if it does > >> what I really want. Any better guide for this? Already read Vala > >> tutorial, but I still haven't get it. > > Just don't mark the list as unowned. > > But in the glib2 vapi, prototype of that API has 'unowned', but in C, > the returned list should be freed by the caller. So how can I override > this method in correct way? The bug in the vapi has to be fixed. -- Jan 'Bulb' Hudec ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Problems with D-Bus and signals, classes and interfaces.
On Mon, Mar 22, 2010 at 14:55:15 +0100, Fabian Deutsch wrote: > Hello, > > during the last two days I tried to figure out how to use signals with > dbus. There were a couple of problems, finally a testcase was created, > showing that signals are woking fine: > http://git.gnome.org/browse/vala/diff/tests/dbus/signals.test > > But this does not work in all cases. The attached testcase shows that > signals do not work, if the client casts the dbus.object to the original > class and not an interface (as in the testcase above). > > Hopefully the testcase is correct and it shows the problem. I don't think that it's supposed to work. The object on the client is *not* of the same class as on server, but rather a *proxy* of type DBus.Object. In fact, I would expect the cast to give a critical warning, return null and the following statements either giving their own critical warnings or blow up. Regards, Jan -- Jan 'Bulb' Hudec ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Binding an OpenGL function with GLchar* parameters
On Sat, Mar 13, 2010 at 12:14:23 -0800, Tristin Celestin wrote: > If I don't include the out specifier, how will glGetActiveAttrib change > the value of name? Whenever you pass an object to some function, without 'out', the function can't give you another object, but it can change the properties of the object. And the same really happens with string. It can't give you different string, but it can change the content of the one you passed in. Which is what this function does. You could make the API nicer from vala by creating a wrapper in the .vapi, that would allocate a string, call the underlying function and return the string via normal out parameter. > > Am 13.03.2010 16:32, Tristin Celestin wrote: > > > I have a OpenGL function with this declaration: > > > > > > GLAPI void APIENTRY glGetActiveAttrib (GLuint program, GLuint index, > > > GLsizei bufSize, GLsizei *length, GLint *size, GLenum *type, GLchar > > > *name); > > > > > > The parameters length, size, type, and name are all outputs of the > > > function. My question is how to deal with the name parameter. A GLchar* > > > is just a char*. > > > > > > Is this the correct way to bind the above function? > > > > > > public static void glGetActiveAttrib (GLuint program, GLuint index, > > > GLsizei bufSize, out GLsizei length, out GLint size, out GLenum type, out > > > string name); > > > > Just 'string', not 'out string', otherwise it woule be 'GLchar **'. -- Jan 'Bulb' Hudec ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Can't compile ValaIde from source...
On Fri, Mar 12, 2010 at 18:24:37 +0200, Arkadi Viner wrote: > When I try to compile ValaIDE from source, It writes me: > ark...@arkadi-laptop:~/Projects/valide-0.6.1$ ./waf configure > Checking for program gcc : ok /usr/bin/gcc > Checking for program cpp : ok /usr/bin/cpp > Checking for program ar : ok /usr/bin/ar > Checking for program ranlib : ok /usr/bin/ranlib > Checking for program valac : ok /usr/bin/valac > Checking for gthread-2.0 : ok > Checking for program version valac >= 0.1.6 : ok 0.7.10 > Checking for program msgfmt : ok /usr/bin/msgfmt > Checking for program intltool-merge : ok /usr/bin/intltool-merge > Checking for header locale.h: ok > Checking for program valadoc: not found > Checking for glib-2.0 >= 2.16.0 : ok > Checking for gio-2.0 >= 2.16.0 : ok > Checking for gobject-2.0 >= 2.16.0 : ok > Checking for gmodule-2.0 >= 2.16.0 : ok > Checking for gtk+-2.0 >= 2.16.0 : ok > Checking for libxml-2.0 >= 2.5.0: ok > Checking for gtksourceview-2.0 >= 2.0.0 : ok > Checking for vala-1.0 >= 0.7.8 : ok > Checking for unique-1.0 >= 1.0.0: fail > 'configure' finished successfully (0.213s) > > What could be wrong ?? Nothing. Call ./waf, too. -- Jan 'Bulb' Hudec ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Newbie Compile Time Errors
On Fri, Mar 12, 2010 at 17:17:25 -0700, Jeff Cave wrote: > > Anyway, I think it's better to install the library. > > One of the problems is that the library is not even at version 0.0.2, that > means its going to change frequently. > > I was actually hoping to use it as a learning tool for building my own > libraries and understanding the compiler. I actually don't want to install > the > library because I want to treat it as part of my overall project (this is as > much about setting up good project environments as anything else). If the library provides a *-uninstalled.pc (libvfcgi-uninstalled.pc), you can pretend it's installed by setting the PKG_CONFIG_PATH (environment variable) to the directory where that file is. Than calling valac with respective --vapidir and --pkg libvfcgi should do the right thing automagically. This is special feature in pkg-config, that it looks for -uninstalled.pc in preference to .pc, provided for exactly this kind of situation. -- Jan 'Bulb' Hudec ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [Genie] emulate a mouse click to trigger widget changes
On Wed, March 10, 2010 01:36, James Parkinson wrote: > > How do you signal another Widget, such as changing a NoteBook Tab when you > select a menu item, especially when the widgets are defined in a glade xml > file ? > > In the example code, when you click the menu item, it calls > on_menu_change_tab() as the action for that menu item. > How can this do the equivalent of nbMain.set_current_page(4) without > causing a Segment fault on windoze ? > [...] > builder.connect_signals (null) > [...] > [CCode (cname="G_MODULE_EXPORT on_menu_change_tab")] > def on_menu_change_tab () There are two problems with your handler: 1) It needs to have 'instance_pos = -1' added to the CCode clause, so it will look like: [CCode (name="G_MODULE_EXPORT on_menu_change_tab", instance_pos = -1)] def on_menu_change_tab () That will change the signature of the method to what Gtk.Builer expects. 2) You need to pass 'this' as argument to builder.connect_signals, so it can get passed to the handler. 3) Than just call nbMain.set_current_page(4) in the handler. -- - Jan Hudec ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] making a running a program as a child inside my program's widget.
On Sat, Mar 06, 2010 at 12:23:26 +0200, Arkadi Viner wrote: > I don't find any example or code for gladeui on the internet for what I need > so I think it's much easier to go with the socket and the plug It would probably be a bit easier, but the result will be bigger bit more ugly. That's because libgladeui allows you to lay out the glade widgets individually to fit the rest of the application, which you can't do with socket/plug. It's mostly obvious you won't find many examples, since there are just two users -- glade itself and anjuta -- but it does not look too complicated. Just create the application, give it the document, get back the widgets and put them somewhere. > On Sat, Mar 6, 2010 at 10:23 AM, Abderrahim Kitouni > wrote: > > > Hi, > > > > 2010/3/5 Arkadi Viner : > > > Does it has bindings for vala ? > > it's just a GObject lybrary, you can easily generate bindings > > automatically [1]. And even if it was some random library, you can > > write bindings as you need them binding only classes/methods you need. > > > > HTH, > > Abderrahim > > > > [1] http://live.gnome.org/Vala/Bindings > > > ___ > Vala-list mailing list > Vala-list@gnome.org > http://mail.gnome.org/mailman/listinfo/vala-list -- Jan 'Bulb' Hudec ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Does vala provide syntactic sugar for "weak" references that know when its peer has been nulled?
On Wed, Mar 03, 2010 at 15:22:59 -0600, Sandino Flores Moreno wrote: > Hello. > Is it possible for a weak ref to know when its peer object has been > deleted (and then assigned to null)? > > Because, suppose you have a weak reference, then the real object is deleted. > So your "weak reference" should be notified, otherwise you might get > segfaults. It is actually supported by GLib.Object. Just create an unowned reference and register it to the object via it's weak_ref method. It will get reset to null when the object is finalized. It will, however, not work in multi-threaded environment where one thread could start destroying the object just as you read the pointer, so you can still get non-null, but the object gets finalied while you use it, causing a segmentation fault. Similar problem may happen if you do something with the reference that might release the object and don't temporarily copy it to an owned one. It would be possible to implement a weak reference object, similar to how it's done in java or python, that would not have these problems, but it is a bit more complicated (a lock is needed etc.). -- Jan 'Bulb' Hudec ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] making a running a program as a child inside my program's widget.
Hello,
On Fri, March 5, 2010 07:18, Arkadi Viner wrote:
> for my class assignment I what to extend ValaIDE so when I click on *.UI
> file it would be opened in Glade,
> but I want glade to be executed inside a new tab (so it will look as part
> of
> the ValaIDE interface...) .
>
> Could some body explain to me how such thing could be done?
Gtk has the Gtk.Socket and Gtk.Plug widgets for this purpose. You create
a Gtk.Socket and the process you want to embed creates a Gtk.Plug. You give
one of the objects the ID of the other and the plug will be inserted into
the socket.
It is possible to tell the Socket to swallow a normal top-level window, too,
but it will not work too smoothly, so you'd really want to make glade create
a plug instead of top-level window. It might already support it if anjuta
already does similar thing (I don't know whether it does).
Note, that Qt has compatible pair of widgets, so you can embed Qt
applications in the same way. However while Gtk supports Socket and Plug
also on Windows, Qt only supports them on X11.
--
- Jan Hudec
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Does vala provide syntactic sugar for "weak" references that know when its peer has been nulled?
On Thu, March 4, 2010 13:23, Phil Housley wrote: > On 3 March 2010 23:17, Jan Hudec wrote: >> On Wed, Mar 03, 2010 at 15:22:59 -0600, Sandino Flores Moreno wrote: >>> Is it possible for a weak ref to know when its peer object has been >>> deleted (and then assigned to null)? > >> By the way, note that Java and C# don't have any weak references at all. >> Unowned references in vala are mostly optimization to avoid some >> reference >> coutning or copying that you have to be careful with and can do without. >> Full >> weak references are obviously useless for that, since setting up the >> back >> link is more expensive than the reference counting in the first place. > > Just for the record, Java does have various reference types, including > weak. > > For a summary: > http://java.sun.com/javase/6/docs/api/java/lang/ref/package-summary.html > For some classes: > http://java.sun.com/javase/6/docs/api/java/lang/ref/Reference.html > > Reference.get() is the safe way to get a referenced object - assigning > the result to something strongly references the object and so it is > safe for as long as you need it. Sorry, I seem to have forgotten how weak references are really intended to work. I mistook the fact it does not have any language-level support for them for not having them at all. Obviously it should be possible to implement weak references for Vala in the same way. No syntactic sugar is needed and it does not even make sense. A Reference class for Vala can be implemented via GLib.Object.weak_ref and GLib.Object.weak_unref. It needs to involve a lock, too and, because how the GLib.Object.unref is implemented it may happen that if you resurrect the object in the last moment (when it's about to be removed), some weak references may already be cleared. -- - Jan Hudec ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Does vala provide syntactic sugar for "weak" references that know when its peer has been nulled?
On Wed, Mar 03, 2010 at 15:22:59 -0600, Sandino Flores Moreno wrote: > Is it possible for a weak ref to know when its peer object has been > deleted (and then assigned to null)? Object is not assigned null. Variable is. Anyway, I believe it still is the plan (and reason why the current kind is called 'unowned' rather than 'weak'), but is not done yet. You might be actually able to set up your unowned references as weak using the GObject.add_weak_pointer and GObject.remove_weak_pointer methods. I should be even possible to get vala do it automatically with some clever wrapper structure, though I am not sure all the needed features of generics are in place. > Because, suppose you have a weak reference, then the real object is deleted. > So your "weak reference" should be notified, otherwise you might get > segfaults. It is actually a bit more complicated than that, because the object may go away between your checking the reference is still valid and using it and I don't actually think that one is the plan. > Something to better write the following code: > [...] > Test **tr = &t; That's a (strong) reference to a reference, not a weak reference. It defeats any useful purpose of weak reference I can imagine. By the way, note that Java and C# don't have any weak references at all. Unowned references in vala are mostly optimization to avoid some reference coutning or copying that you have to be careful with and can do without. Full weak references are obviously useless for that, since setting up the back link is more expensive than the reference counting in the first place. -- Jan 'Bulb' Hudec ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Using OpenGL 3.0 from Vala
On Sun, Feb 21, 2010 at 18:30:31 -0800, Tristin Celestin wrote: > I am trying to use OpenGL 3.0 from Vala, but I notice that only up to > OpenGL 1.3 is defined in the .vapi file. The methods relevant to me are > defined in GL/glext.h. How would I access the functions declared there? > > Is it enough to just write a .vapi file for myself referencing the > necessary functions, or should I modify gl.vapi? glext.h had a lot of > methods, and I am not going to be able to cover all of them myself. There is currently no way to spread class definition across multiple .vapi files. So if you only want to define new classes or new static functions to a namespace, you can put them in a separate .vapi, but if you need to add methods to classes, you need to add them in the .vapi that defines the class. Declaring methods in the .vapi that are than not available in the library is not a problem if those methods are not used. -- Jan 'Bulb' Hudec ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] How to get the size of structure?
On Mon, Feb 15, 2010 at 15:50:37 -0600, Sandino Flores Moreno wrote:
> Hello.
>
> I'm wrapping a non-glib library.
>
> That library makes use of lot of structures,
> and any instance of those structures must be initialized
> with the size of the structure, and the version of the API used.
>
> http://github.com/tigrux/omx-vala/blob/master/libomxil-bellagio.vapi#L197
>
> For example:
>
> Omx.Audio.Param.Mp3 param = {};
> param.size = sizeof (Omx.Audio.Param.Mp3);
> param.version = API_VERSION;
>
> Vala restricts the use of sizeof to types only, so it fails
> to compile when I try:
>
> param.size = sizeof (param);
>
> So, the question is:
>
> How to make Vala automatically assign the size of the structure to the
> field `size`
> of those structures?
Well, not automatically, but you can do it in the bindings. The trick is,
that the .vapi file can contain function definitions. So for each of these
structures you define an init function that assigns the size, maybe the API
version and clears the rest as appropriate. Than it should be possible to set
it as initialization function for the structure via some [CCode(...)]
annotation, but I don't currently know which. Try digging in the existing
.vapis.
> The idea is that something like:
>
> Omx.Audio.Param.Mp3 param = Omx.Audio.Param.Mp3();
>
> is automatically expanded to something like:
>
> OMX_AUDIO_PARAM_MP3 param;
> memset(¶m, 0, sizeof(param));
> param.nSize = sizeof(param);
> param.nVersion = API_VERSION
>
> Thanks in advance.
> ___
> Vala-list mailing list
> Vala-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/vala-list
--
Jan 'Bulb' Hudec
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] sorted keys from a hash
On Sat, Feb 13, 2010 at 21:59:20 +0530, Martin DeMello wrote:
> On Sat, Feb 13, 2010 at 3:39 AM, Jan Hudec wrote:
> > On Sat, Feb 13, 2010 at 02:54:21 +0530, Martin DeMello wrote:
> >> What's the most efficient (in terms of speed) way to iterate over a
> >> hash in sorted order of the keys? The keys are strings.
> >
> > To use a balanced tree.
> >
> > Hash can only ever be iterated in the hash order, which is fixed but
> > pseudo-random.
>
> Well, here's my exact problem: I have a TreeMap that I add (string,
> string) pairs to. The desired output is a sorted list of these pairs.
> Now I'm wondering if it'd be more efficient to use a HashMap instead,
> since I don't really need to maintain the sorted property as the list
> is built up, just have it sorted when I return it. Roughly, I want
It most probably would not.
What should be actually more efficient is to collect the pairs into an
ArrayList, sort it and copy out the values.
> for i in map.keys.sort() {
> retval.append (i, map[i])
> }
>
> return retval
>
> except I've been through the API and I can't find a good way to sort
> the keys, or to push the pairs into a list and sort the list.
There is Gee.AbstractList.sort(CompareFunc?). Collect the pairs into
Gee.ArrayList and use .sort on it.
On a side note, Vala currently does not share strings, but you can move them
with (owned) "cast" to avoid some copying ((owned) transfers ownership and
nulls it's operand).
--
Jan 'Bulb' Hudec
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] sorted keys from a hash
On Sat, Feb 13, 2010 at 02:54:21 +0530, Martin DeMello wrote: > What's the most efficient (in terms of speed) way to iterate over a > hash in sorted order of the keys? The keys are strings. To use a balanced tree. Hash can only ever be iterated in the hash order, which is fixed but pseudo-random. -- Jan 'Bulb' Hudec ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] using libgee from c
Hello, On Sat, Feb 13, 2010 at 01:28:21 +0530, Martin DeMello wrote: > Other than reading gee.h directly, is there any documentation on the C > api to libgee? The conversion between Vala and C api is straightforward. So you can simply look at the documentation at www.valadoc.org and learn to know what corresponding C names are. The names follow the Gtk coding convention. What is slightly tricky is remembering what additional parameters you need to pass to generic methods (the GType, copy (ref) and destroy (unref) functions), but since it's always the same, you'll remember after a while. -- Jan 'Bulb' Hudec ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Problem while creating a vapi file for a typedef'd pointer.
On Fri, Feb 12, 2010 at 17:40:16 +0100, Abderrahim Kitouni wrote:
> Hi,
>
> Geoffrey Blackman wrote:
> >Hi,
> >I'm attempting to create a vapi file for Verilog VPI and have run into a
> >problem with a opaque pointer type.
> >Different implementations of VPI define the type vpiHandle differently. Two
> >examples are
> >
> >typedef void *vpiHandle;
> I don't know if this is bindable in vala (i.e. you may need to use
> >typedef struct __vpiHandle *vpiHandle;
> but this should be something like
> [Compact]
> [CCode (cname="struct __vpiHandle"]
> public class Handle {...}
>
> >I therefor need to define a type in my vapi file which will map to vpiHandle
> >and behave like a pointer.
>
> I'd like to explain some things here.
> >[SimpleType]
> SimpleType means it should be passed by value, it definietly won't
> behave like a pointer.
Well, it will be a pointer, if you bind a pointer as a simple type. With the
one exception -- vala won't want to compare it with null. You could' however,
do something like
[SimpleType]
[CCode (cname="vpiHandle")]
public struct Handle {
[CCode (cname="NULL")]
public static Handle none;
...
}
Than you still can't compare with null, but can compare with Handle.none with
the same effect.
> >[...]
> >Note that the '?' indicating that the iterate method can return null has
> >caused argv to have type 'vpiHandle*' rather than the vpiHandle returned by
> for a struct, '?' means it's boxed (that's the only way for it to be null).
> >vpi_iterate.
> >If I remove the nullable marker I would get the correct type for argv,
> >however I cannot now test it for null.
> because a struct won't behave like a pointer.
>
> Your best bet is a compact class, but this won't work in the void* case.
It will. Vala shouldn't have problem binding void as class...
[Compact]
[CCode (cname="void")]
public class Handle {...}
Since C will implicitly cast between void* and anything*, I actually think
binding void would be a better solution than binding "struct __vpiHandle".
You'll need to set the ref/unref resp. copy/free functions, but you need to
do that anyway.
--
Jan 'Bulb' Hudec
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Generated code, GTK signals and prefixes.
On Wed, Feb 10, 2010 at 23:36:23 -0200, Carlos Eduardo da Fonseca wrote:
> Hello everyone,
>
> is there any way to connect signals from a GtkBuilder XML without writing
> the "Vala generated function name"?
>
> For example:
>
> namespace MyNamespace {
> class MyClass {
> static void my_handler(Widget widget) { ... }
> }
> }
>
> In my GtkBuilder XML I'll have to define:
>
>
>
> Isn't any way to avoid this?
Why, yes. Write your own binder for use with Gtk.Builder.connect_signals_full
that understands Vala names and can mangle the names for you. It can also use
custom marshallers if you want to avoid having to specify the
[CCode(instance_pos = -1)] for non-static methods.
--
Jan 'Bulb' Hudec
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Vala - generates code at runtime
On Tue, Feb 09, 2010 at 23:29:39 +0100, jideel wrote: > It was quite seductive to be able to code as easily as with C#/Java while > having C performance/size. If you have most of the code in a compiled library (that can be written in Vala or C or C++) and just generate a bit of glue to put it together in a custom way, the performance hit will not be significant unless you run it in a tight loop millions of times per second. > The project is about a kind of distributed UUID generator, available > through different interfaces (socket, soap, rest...) , while being > manageable through a web interface, users can define their own > types/classes on-the-fly and link generated UUIDs to their objects so later > they can pick up an UUID from, say, a database and find what kind of object > it's related to, when it was created and so on. It can provide some > tracability to a normally "dumb" identifier. I guess you might want to support multiple languages for thing like that, than and Vala could be one. I'd however start with something fully reflexive like CLR (.net) or Java as you can easily check the object structure there, have ready-made serialization and such. > As it has to be reliable/scalable/... it's probably a java-like job. > > I've investigated Java/C# previously for such a task and it's true it fits > well, but i had a good feeling about Vala, so i thought "why not give it > a try ?" :) > > Vala is perhaps, at least for now, more desktop-oriented. I wouldn't say. Vala's important goal is to allow implementing libraries, that can be used by applications written in wide variety of languages. That's something Java or C# can't do, because they are tied to their runtimes. > Anyway, it doesn't seems that the gmodule-2.0.vapi wraps any unload > functionality, while GModule provides a GModuleUnload function. Is it not > implemented or am i missing something (again) ? The g_module_close function is bound as the destructor for GModule, so it should be unloaded when the GModule object goes out of scope. -- Jan 'Bulb' Hudec ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [RFC] Extension methods (Re: maemo5 hildon input mode)
Hello,
On Wed, February 10, 2010 16:20, Jiří Zárevúcky wrote:
> Jan-Jaap van der Geer píše v St 10. 02. 2010 v 02:34 -0800:
>> Jan Hudec wrote:
>> > This looks like another use-case for extension methods in a day.
>>
>> I'd like to see them as well.
>
> It might be useful, in some cases. It should be noted that extension
> methods can only access class' public members.
Indeed. They are not really in the class, after all. Also since separate
library is supposed to be able to provide them, it does not have access
to the private members at all, since they are not exported.
>> I feel like we should follow C# regarding that. In C# the method must be
>> static and must be placed in a static class as well.
>
> I disagree with that. The C# way feels like an ugly hack to me.
> How about something like this:
>
> public class extension Gtk.Entry {
> public void some_additional_stuff () {
> // do something
> }
> }
>
> or similarly:
>
> public interface extension IComparable {
> public bool less_or_equal (IComparable rhs) {
> return !rhs.less_than (this);
> }
> }
That's what I'd prefer too. Plus it would naturally make the C name the
same as if the method was really in the class, which I think it should.
--
- Jan Hudec
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] [RFC] Extension methods (Re: maemo5 hildon input mode)
Hello,
This looks like another use-case for extension methods in a day.
Extension methods in C# work are static methods defined anywhere, that
can be called like (instance) methods of some particular class or interface.
They would make perfect way for add-on libraries to provide convenience
methods for objects defined elsewhere. In .NET they are mainly used to
provide the "linq" methods to interfaces.
In C# extension methods are defined as static methods of any class, but
that seems to be because they were invented before C# allowed namespace-
scoped functions. So for Vala I'd suggest putting them in the namespace
the class is in or in a special "extend class".
Suppose there is interface Moo.IComparable, that looks like
namespace Moo {
interface IComparable : GLib.Object {
bool less_than(IComparable rhs);
}
}
Having one comparison allows defining the others in terms of the first
one. In Vala (unlike C#) interfaces can have implemented methods, but
suppose the library author forgot to define less_or_equal and you want
to define it and don't have control over the interface. So you'd define
extension method to add it. I propose following options for syntax:
namespace Moo {
bool less_or_equal(IComparable this lhs, IComparable rhs) {
return !rhs.less_than(lhs);
}
}
(the disadvantage here is that it has to be mangled to
moo_icomparable_less_or_equal, leading to a bit of overloading (another
less_or_equal with different "this" argument would be allowed))
namespace Moo {
bool icomparable_less_or_equal(IComparable this lhs, IComparable rhs) {
return !rhs.less_than(lhs);
}
}
(now the author needs to know the Vala mangling, because it's still supposed
to be called a.less_or_equal(b))
namespace Moo {
[lowercase_cprefix="icomparable_"]
class IComparableExtensions {
bool less_or_equal(IComparable this lhs, IComparable rhs) {
return !rhs.less_than(lhs);
}
}
}
(this is most C#-py, but requires either the c prefix annotation, or special
mangling rules)
namespace Moo {
[Extend]
interface IComparable {
bool less_or_equal(IComparable rhs) {
return !rhs.less_than(this);
}
}
}
(writing [Extend] to avoid new keyword, but that would be an option)
I probably like the last option best, but it's least like C#, so it depends
on how much similarity is desired.
I suppose extension properties should be possible with the limitation, that
they cannot have default implementation.
On Tue, February 9, 2010 22:44, pHilipp Zabel wrote:
>> I would suggest that adding vendor specific modifications to existing
>> classes is way too ugly
>
> Agreed.
Modifications are indeed ugly, but adding a couple of convenience methods
following the normal naming convention of methods for the class is IMHO OK.
>> to be accepted and you should bind it to hildon
>> classes. How can they even add more properties to an already defined
>> class?
>
> They ship a modified GTK+ library. Hildon depends on that.
> I guess we could get away with just binding the hildon_gtk_entry_*
> methods to Hildon.Entry instead of Gtk.Entry. Is there a way of doing
> this via metadata before the vapigen step?
> But there are a few others like hildon_gtk_widget_set_theme_size or
> hildon_gtk_window_set_progress_indicator that can't be mapped to
> Hildon classes, as they are needed to work on Gtk.Button and
> Gtk.Dialog, for example.
That's where extension methods would be useful. The hildon package would
just do
[cprefix="hildon_gtk"]
namespace Gtk {
[Extend] class Widget { ... set_theme_size(...); }
[Extend] class Widnow { ... set_progress_indicator(...); }
}
and
--
- Jan Hudec
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Vala - generates code at runtime
On Tue, Feb 09, 2010 at 15:36:56 +0100, jideel wrote: > I'm wondering what would be the "right" way to generates code/classes at > runtime, and reload it into the running program. Well, is Vala the right tool than? It's a completely static language which needs to be compiled with C compiler and that linked and the C compiler and linker are a pretty big beast. Something more dynamic would handle the job easily. Either fully dynamic like python (or perl or ruby or lua or javascript (using libseed)), that have no compilation at all, or partially dynamic like CLR (Mono/.NET) or Java, which both carry their bytecode compiler in the runtime. You can still use vala for the static part and export necessary API to the dynamic part. > I thought to use the modules/plugin approach > (http://live.gnome.org/Vala/TypeModules) the following way : > - generate code than can be reloaded (plugin code, [ModuleInit]) using some > kind of StringBuilder > - flush it to a file I would not compose to StringBuilder (which is just string and will reallocate all the time as you extend it), but write to a file directly. It would be more efficient and you really get similar functionality. > - compile this file either by forking a valac compiler or perhaps using > directly libvala (possible ?) Both are possible. Forking is probably easier, since while most of vala compiler does live in libvala, the driver is not too trivial. Might depend on the conditions. I found the code reasonably easy to follow, so just take a look. > - reload the resulting plugin binary into the app It should work. You need to unload the old version, so you need to shut it down and than reload. Mostly applies to CLR and Java too; fully dynamic languages should be able to upgrade. > There's probably a better way to accomplish this kind of task. > > Any idea / suggestion ? It really depends on *why* you want to do it. -- Jan 'Bulb' Hudec ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Generating bindings for classes defined over multiple packages
On Mon, Feb 08, 2010 at 17:13:43 -0500, Gabe Gorelick-Feldman wrote: > Thanks, but at that point it's easier just to do the binding by hand. I was > trying to come up with a process that could integrate well with the build > system, that way the library can be built and bindings can be > auto-generated, but I guess that's not possible. You have bigger problem than that. IIRC Vala does not yet support either partial classes or extension methods. Thus it's not possible to have two .vapi files contributing to one class, manually-written or generated. So you'll have to generate two alternate .vapi files, one with and one without Gtk and that should be possible to auto-generate. Extension methods (C# has them as specially declared static methods anywhere, but Vala could have other syntax) would be nice in Vala (since in C they are just functions following the class' naming convention) but until they are there, you'll have to do alternative packages. > Are there any plans to make the vala tools less package-oriented? It would > be nice if you could just give them some header files and the shared > libraries they map to instead of having to package everything. A "package" just means to write the .pc (pkg-config) file listing version, compiler and linker flags and dependencies for the library. Just look up the pkg-config manual; the format is really simple. The main advantage of .pc files for vala is, that they provide necessary options for compiler and linker, so you just tell valac the packages you need and it can just give you compiled application. And since each normally describes just one library, so it's not like you'd need any better granularity. For example GLib is one "package" for distribution, but installs glib-2.0.pc, gobject-2.0.pc and gio-2.0.pc corresponding to libglib-2.0.so, libgobject-2.0.so and libgio-2.0.so respectively and similarly for Gtk, which additionally installs "virtual" gdk-2.0 and gtk+-2.0 packages that simply depend on the others. Now you don't need to install the .pc file anywhere. Just export appropriate variable (PKG_CONFIG_PATH) with the directory where to find the .pc files when running the tools. On the other hand the shared libraries probably are or will be installed (otherwise it wouldn't make sense to make them shared, no?), so providing .pc files will benefit anybody who wants to use them. -- Jan 'Bulb' Hudec ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] maemo5 hildon input mode
On Mon, February 8, 2010 18:35, Martin DeMello wrote:
> Thanks, that worked beautifully. For anyone googling this up, the exact
> code is:
>
> var input = new Hildon.Entry (Hildon.SizeType.AUTO);
> input.set("hildon-input-mode", Hildon.GtkInputMode.FULL);
> // refer to hildon-1.vapi for the full enum
While this is indeed correct workaround, the Hildon binding should
probably be updated (so you get type-checking from the compiler).
--
- Jan Hudec
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
