[Vala] Rules for updating generated C files

Hello,

My understanding of the current rule for generating a C file from a vala
file is, if the contents of the C file has the same hash value, don't
rewrite the file.  When dealing with larger systems using libraries, this
rule may not be sufficient.

I've attached an example program that illustrates the problem I describe
below.  To exhibit the problem:
1. execute make
2. execute ./main.  Note the output.
3. comment out the variable comment_and_uncomment_me in file
BaseClass.vala.  Remember to save.
4. execute make
5. execute ./main.  Note the output is different and wrong.

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.

I propose that if the C file (Derived.c in this instance) that is generated
has the same hash value as the existing C file BUT the corresponding vala
file (Derived.vala) imports anything from a vapi (BaseClass.vapi) that has

Re: [Vala] Rules for updating generated C files

Please do.  "This bug affects me too."

On Thu, Jun 3, 2010 at 5:13 PM, Robert Powell <rob@...> wrote:

> Hello,
>
> My understanding of the current rule for generating a C file from a vala
> file is, if the contents of the C file has the same hash value, don't
> rewrite the file.  When dealing with larger systems using libraries, this
> rule may not be sufficient.
>
> I've attached an example program that illustrates the problem I describe
> below.  To exhibit the problem:
> 1. execute make
> 2. execute ./main.  Note the output.
> 3. comment out the variable comment_and_uncomment_me in file
> BaseClass.vala.  Remember to save.
> 4. execute make
> 5. execute ./main.  Note the output is different and wrong.
>
> 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

[Vala] [Genie] Generic of a Generic, dict hash/eval overrides

What is the intended syntax for something like this:

blobs : list of array of uint8

The best I've found so far is
struct bytes
    value : array of uint8
blobs : list of bytes

Which is less desirable as its more verbose to refer to and generates
less-clean code.  For this specific case it'd be awesome to have an actual
"bytes" type counterpart to the "string" type.

Also, reading http://jamiemcc.livejournal.com/12009.html:

> The big advantage of embedding lists and dicts in the language is that it
> makes it much easier for the developer to make use of them. It also means
> genie can make decisions about which hashing and equal functions to use
> based on the types (Eg for a dict of string,string it would use the glib
> g_str_hash and g_str_equal functions automatically although you could of
> course specify different ones by setting the properties explicitly) whereas
> in vala you would have to type something like :
>
> var map = new Gee.HashMap<string, string>(GLib.str_hash, GLib.str_equal);
>
> There seems to be a problem in that these HashMap properties are read-only:
http://people.gnome.org/~dvillevalois/libgee/doc/gee-1.0/Gee.HashMap.key_hash_func.html<http://people.gnome.org/%7Edvillevalois/libgee/doc/gee-1.0/Gee.HashMap.key_hash_func.html>

The Pythonic way would be for the key type to have a hash and equal
functions and for the dict to use these when present, but it appears

Re: [Vala] Rules for updating generated C files

Same here

Can you open a bug for this?

I would prefer timestamps instead of checksums.

Another idea would be to make vala return 0 or 1 like 'test' do. So it  
would be integrated with Makefiles.

It would be also useful to make vala print out which files has changed:

$ valac --check a.vala b.vala...
a.vala

This method would be easily integrated with makefiles.

--pancake

On Jun 3, 2010, at 11:24 PM, Arc Riley <arcriley@...> wrote:

> Please do.  "This bug affects me too."
>
> On Thu, Jun 3, 2010 at 5:13 PM, Robert Powell <rob@...> wrote:
>
>> Hello,
>>
>> My understanding of the current rule for generating a C file from a  
>> vala
>> file is, if the contents of the C file has the same hash value, don't
>> rewrite the file.  When dealing with larger systems using  

[Vala] Filling structures

I have already opened a bug few weeks ago..with a patch that works fine,
but I'm still waiting for somebody to review it and commit it.. (jurg? :P)

https://bugzilla.gnome.org/show_bug.cgi?id=618856
https://bugzilla.gnome.org/show_bug.cgi?id=618857
https://bugzilla.gnome.org/show_bug.cgi?id=618933

Today I have falled in a stupid bug caused by me, but vala wasnt warning 
or so.

The thing is that actually you can assign less fields than the ones 
existing in
a structure:
----------------------------------------
struct Foo {
     string foo;
     string bar;
     string cow;
}

void main() {
     // should this be allowed??
     Foo foo = { "jej", "jiu" }; //, "jejje" };
}
----------------------------------------

The thing is that by defining such struct in a vapi file and not filling 
all fields I
fall into a segfault inside Valac.

Re: [Vala] [Genie] Generic of a Generic, dict hash/eval overrides

On Fri, 2010-06-04 at 00:08 -0400, Arc Riley wrote:
> What is the intended syntax for something like this:
> 
> blobs : list of array of uint8
> 
> The best I've found so far is
> struct bytes
>     value : array of uint8
> blobs : list of bytes
> 
> Which is less desirable as its more verbose to refer to and generates
> less-clean code.  For this specific case it'd be awesome to have an actual
> "bytes" type counterpart to the "string" type.
> 
> 
> Also, reading http://jamiemcc.livejournal.com/12009.html:
> 
> > The big advantage of embedding lists and dicts in the language is that it
> > makes it much easier for the developer to make use of them. It also means
> > genie can make decisions about which hashing and equal functions to use
> > based on the types (Eg for a dict of string,string it would use the glib
> > g_str_hash and g_str_equal functions automatically although you could of
> > course specify different ones by setting the properties explicitly) whereas
> > in vala you would have to type something like :
> >
> > var map = new Gee.HashMap<string, string>(GLib.str_hash, GLib.str_equal);
> >
> > There seems to be a problem in that these HashMap properties are read-only:
> http://people.gnome.org/~dvillevalois/libgee/doc/gee-1.0/Gee.HashMap.key_hash_func.html<http://people.gnome.org/%7Edvillevalois/libgee/doc/gee-1.0/Gee.HashMap.key_hash_func.html>
> 

[Vala] Incorrect type inference for application of generic types

Is it a known bug that translation of the following program produces
type warnings (during C compilation step) although the program is type
correct?

Thomas

public interface MyInterface<T1> {
	public abstract T1 id (T1 arg);
}

public class MyClass : Object, MyInterface<int?> {
	public int? id (int? a1) {
		return a1;
	}
	static int main (string[] args) {     
		var c = new MyClass ();
		stdout.printf ("result %d\n", c.id (3));
		return 0;
	}
}

Re: [Vala] Incorrect type inference for application of generic types

On Fri, Jun 04, 2010 at 08:02:36PM +0200, Thomas Peikenkamp wrote:
> 
> Is it a known bug that translation of the following program produces
> type warnings (during C compilation step) although the program is type
> correct?

Vala does not support specialization, the problem is that the compiler gives
no error for that.

--

-- 
http://www.debian.org - The Universal Operating System

_______________________________________________
vala-list mailing list
vala-list@...
http://mail.gnome.org/mailman/listinfo/vala-list

[Vala] Problem connecting signals from Glade to my code

Hey guys,

I have a problem connecting my code with GUI that I designed in Glade. The
problem that I keep stumbling upon is that I'm getting Gtk-WARNING **: Could not
find signal handler.

My code:

public class AssistantDirectoryHistory : AssistantOperation {
	[CCode (instance_pos = -1)]
	public void on_restorebutton_clicked(Gtk.Button source) {
		source.label = "clicked restore btn";
	}

	public Gtk.Widget make_listfiles_page() {
			var page = new Gtk.Table(1, 1, false);
			var builder = new Gtk.Builder();
			builder.add_from_file("deja-dup/listfiles.ui");
   			builder.connect_signals(this);
    			var window = builder.get_object("viewport") as Gtk.Widget;
			window.reparent(page);
			return page;
	}

	/* Some other code that adds this Widget to a page in Gtk.Assistant */
}

On a friendly tip from #vala I tried greping the AssistantDirectoryHistory.c for
on_restorebutton_clicked and found that C function for this is:

Re: [Vala] [Genie] Generic of a Generic, dict hash/eval overrides

It's a Genie issue now, since they are private properties but can be
constructed with the hash/equal functions (just like GHashTable).

Can we get support for this added in before the next valac release?
Suboptimally I'm having to use a GLib.HashTable instead of a dict.

On Fri, Jun 4, 2010 at 9:22 AM, Jamie McCracken <jamie.mccrack@...>wrote:

> On Fri, 2010-06-04 at 00:08 -0400, Arc Riley wrote:
> > What is the intended syntax for something like this:
> >
> > blobs : list of array of uint8
> >
> > The best I've found so far is
> > struct bytes
> >     value : array of uint8
> > blobs : list of bytes
> >
> > Which is less desirable as its more verbose to refer to and generates
> > less-clean code.  For this specific case it'd be awesome to have an
> actual
> > "bytes" type counterpart to the "string" type.
> >
> >
> > Also, reading http://jamiemcc.livejournal.com/12009.html:
> >
> > > The big advantage of embedding lists and dicts in the language is that
> it
> > > makes it much easier for the developer to make use of them. It also
> means