[Vala] connecting/disconnecting a signal to a static member function?
Dear List, Now that += and -= are deprecated syntax for signal handlers, I am trying to update some signal code into the connect/disconnect syntax on Vala 0.11.0. Here is the problem I couldn't get myself out from: 1. the signal connecting / disconnecting is performed in a static member function. 2. the signal handlers are also static member function with no 'instance' pointers. If I blindly replace the '-=' syntax with disconnect I get an error message like this: gtk-widget.vala:110.29-110.45: error: Argument 1: Cannot convert from `Widget.recursive_changed' to `GLib.Object.notify' widget.notify.disconnect(recursive_changed); The signature of widget.recursive_changed is: private static void recursive_changed(Gtk.Widget widget, ParamSpec pspec); I remember there is a way of declaring the handler with has_instance = 0 in the CCode annotations, but it wont work in this case as I am calling disconnect from a static member function and can't access an instance member. How shall I achieve this? The warning messages about -= and += are getting very annoying(too many of them). Regards, Yu ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Leak on arrays?
Dear List, The following line is a ccode from ParamSpec[] specs = klass.list_properties(); ---CCode -- specs = (_tmp5_ = (_tmp4_ = g_object_class_list_properties (klass, &_tmp3_), (_tmp4_ == NULL) ? ((gpointer) _tmp4_) : _vala_array_dup1 (_tmp4_, _tmp3_)), specs_length1 = _tmp3_, _specs_size_ = specs_length1, _tmp5_); - _tmp4_ seems to be a leak, is it? This is in Vala 0.8.0. Is this a bug? Regards, Yu ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] GObject.set_data("data-field", null) ?
Dear list, What is the preferred way of removing a data field on GObject? set_data do not accept a null parameter. Shall I use set_data_full? Regards, Yu ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Vala 0.7.10.262 pre-release
Would you please look at Bug 614494 if it is not yet too late for the new release? Yu On Thu, 2010-03-25 at 11:19 +0100, Jürg Billeter wrote: > A new Vala version will be released shortly. To make sure that we have > not introduced serious regressions, we'd like to invite everyone to test > the following pre-release and report any regressions or other > release-critical issues. > > http://www.vala-project.org/downloads/vala-0.7.10.262-39688.tar.bz2 > > There have been many fixes and also quite a few enhancements since > 0.7.10. The complete list of changes is available in the ChangeLog and a > summary will follow with the announcement of the final release. > > Thanks, > Jürg > > ___ > Vala-list mailing list > Vala-list@gnome.org > http://mail.gnome.org/mailman/listinfo/vala-list ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] How to use the ZLib bindings?
Hi, On Tue, 2009-11-10 at 09:10 +0100, pHilipp Zabel wrote: > Hi Yu, > I still maintain that strm.next_in / strm.next_out cannot be owned > arrays because the call to strm.inflate changes the pointers > themselves. The same program compiles unchanged when I remove the weak > keywords again, but it fails when trying to destroy the buffers: > *** glibc detected *** ./zlibtest: munmap_chunk(): invalid pointer: > 0x0210b500 *** > I didn't know about this behavior. Could you kindly post me a copy of the CCode for zlibtest? I'd like to do some research on it and get this point clear. > The '->' argument doesn't apply here - uchar* vs uchar[], no structs involved. > But I agree that a single weak uchar[] is more Valaish than a uchar* and an > int. > The initial assignment is more compact this way: > strm.next_out = buf_out; > vs > strm.next_out = buf_out; > strm.avail_out = buf_in.length; > And I have to replace strm.avail_out with stream.next_out.length. > Other than that, > it's the same. So should we change that back (to weak uchar[]s)? > I definitely prefer using weak uchar[]s, as the field is an array but a pointer. If keeping the vapi similar to the original API is important, then you may consider add the avail_out field in the struct declaration and write a comment, stating that it is the same as next_out.length, and the mere purpose of that field is to keep the API consistent; or use (no_array_length=true) CCode attribute. PS: To get your patches applied, you have to let vapi maintaine know about your patch. See [http://live.gnome.org/Vala/BindingsStatus]. Yu > Thanks for having a look at this. > > regards > Philipp ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Sharing a trick to use some C macros in VALA
Dear list, I found this trick today, in case it is not already dinosaur.. [CCode (cname="G_STRUCT_OFFSET(MyBaseClassClass, my_function)")] extern const int MyFunctionOffset; basically you can call in this way any c macros that are otherwise not directly bindable to vala, given that the return type of the macro is known. - Yu ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] params string[] foo?
Dear List,
How do I use the params syntax? I see it added in the parser but looks
like the codegen is not dealing with it properly, or maybe I am missing
something.
This naive code fails:
public void va(params string[] foo) {
return;
}
public void call_va() {
va("a", "b", "c");
}
/tmp/t.vala.c: In function ‘call_va’:
/tmp/t.vala.c:21: warning: passing argument 1 of ‘va’ from incompatible pointer
type
/tmp/t.vala.c:15: note: expected ‘const char **’ but argument is of type ‘char
*’
/tmp/t.vala.c:21: warning: passing argument 2 of ‘va’ makes integer from
pointer without a cast
/tmp/t.vala.c:15: note: expected ‘int’ but argument is of type ‘char *’
/tmp/t.vala.c:21: error: too many arguments to function ‘va’
error: cc exited with status 256
Compilation failed: 1 error(s), 0 warning(s)
Yu
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [Async] why use .begin ?
Please someone elaborates on .begin / .end in the tutorial. The async story is missing in it. - Yu On Fri, 2009-09-18 at 20:10 +0200, Jan Hudec wrote: > On Fri, Sep 18, 2009 at 19:52:59 +0200, JM wrote: > > What does .end() do? Are there any examples available? > > It's a syntax for the _finish function. Takes the AsyncResult and return the > real result or throws an error (if the async function does). > > It's called like > > async_function.end(result) > > in the async callback. > ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] A note about weak/unowned struct
Dear List,
Here is some of my observation regarding to weak/unowned struct, which I
would like to share with you.
I am not sure if the feature has landed or not, but currently a
weak/unowned struct is compiled into a bitwise copy of the memory
content of the referred struct. in other words, it is a readonly
'snapshot', although the name doesn't suggest this special feature at
all.
See the following program(compiled with 0.7.5)
-- Program --
struct Struct {
public int i;
public Object o;
}
public void main() {
Struct s = Struct();
s.i = 100;
s.o = new Object();
unowned Struct ws = s;
ws.i = 101;
debug("s.i = %d", s.i);
debug("ws.i = %d", ws.i);
debug("s.o.ref_count = %u", s.o.ref_count);
ws.o = null;
debug("s.o.ref_count = %u", s.o.ref_count);
}
- Program ends -
It gives the result
-- Result
** (process:11743): DEBUG: t.vala:11: s.i = 100
** (process:11743): DEBUG: t.vala:12: ws.i = 101
** (process:11743): DEBUG: t.vala:13: s.o.ref_count = 1
** (process:11743): DEBUG: t.vala:15: s.o.ref_count = 0
(process:11743): GLib-GObject-CRITICAL **: g_object_unref: assertion
`G_IS_OBJECT (object)' failed
-- Result ends -
When ws.i changes s.i is left unaffected. When ws.o is set to null, the
object is unrefered. However, VALA still believe the strong reference
exists in s.o, which ultimately causes the 'critical' on s.o when s is
freed.
The rule of thumb is then never alter the content of a struct that you
don't own.
Yu
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Wrapping Errors
On Thu, 2009-09-03 at 13:38 +0100, Phil Housley wrote:
> 2009/8/22 Jan Hudec :
> > On Thu, Aug 20, 2009 at 22:09:21 -0400, Yu Feng wrote:
> >> GError doesn't support error wrapping as Java does. Is GLib is purposely
> >> avoiding it?
> >> If not, it will become a useful feature as the number of libraries that
> >> uses GError grows, as the feature has already been proved useful in
> >> Java, (indicated in this article):
> >>
> >> http://tutorials.jenkov.com/java-exception-handling/exception-wrapping.html
> >
> > Actually, in my opinion that article nicely explains, why you do *not* need
> > to have the original error information there.
>
> In Java, this feature is actually used a lot, and can be incredibly
> helpful. A common example goes:
>
> void dbaccess() {
> throw new DatabaseError();
> }
>
> void sometransaction() throws FailedToCompleteError {
> if (bad data) throw new FailedToCompleteError();
> try {
> dbaccess();
> } catch(DatabaseError e) {
> // this is still a failure to complete
> throw new FailedToCompleteError(e);
> }
> }
>
> void abusinessfunction() throws FailedToCompleteError {
> try {
> sometransaction();
> } catch(FailedToCompleteError e) {
> // unroll operation or whatever
> throw e;
> }
> }
>
> void main() {
> try {
> usebusinessfunction();
> } catch(FailedToCompleteError e) {
> // hmm, what went wrong, should we give up (database) or try again
> (bad data)
> }
> }
>
> The reason this doesn't map so well onto Vala/GError, is that
> something like DatabaseError would probably be unchecked, and so could
> trickle through the stack without handlers being invoked to do things
> like unrolling transactions. The aim here is to insulate the business
> function from having know that the database even exists, while still
> letting it know whether the transaction was completed. Wrapping the
> error preserves the information for the application, or whatever
> integration layer actually knows how the stack is set up.
>
In vala, to wrap up errors one can always do(because the essence part of
the error in Vala is merely the .message field):
private void dbaccess() throws DBError(e) {
throw new DBError.ACCESS_FAILED("db access failed");
}
public void sometransaction() throws TransactionError {
try {
dbaccess();
} catch(DBError e) {
throw new TransactionError.FAILED_COMPLETE("Failed to complete:
%s",
e.message);
}
}
public void somebusiness() throws BusinessError {
try {
sometransaction();
} catch(TransactionError e) {
throw new BusinessError.FAILED_TRANSACTION("Business Failed:
%s",
e.message);
}
}
I hope I understood what you were trying to say.
Yu
> > article> The main reason one would use exception wrapping is to prevent the
> > article> code further up the call stack from having to know about every
> > article> possible exception in the system.
> >
> > Well, so the code further up the call stack is not going to look at the
> > inner exception anyway except to print it to the operator, right? But for
> > that, it's enough to embed the wrapped error's message into the wrapping
> > error message. The error code is not relevant.
> >
> > By the way, you should be suggesting things like this on the Gtk list, not
> > here.
> >
> > --
> > Jan 'Bulb' Hudec
> >
> > ___
> > Vala-list mailing list
> > Vala-list@gnome.org
> > http://mail.gnome.org/mailman/listinfo/vala-list
> >
>
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Improving the i18n binding in GLib
Dear Maintainers,
The attachment is a patch that adds a few more gettext functions to the
glib-2.0.vapi.
Also in the patch I moved the gettext functions to Intl namespace, while
leaving the _ macros under the GLib namespace.
If it possible I would also suggest using the name I18N as the namespace
for i18n functions, instead of the current name 'Intl'. Because glib
abbrs internationalization to i18n(glib-i18n.h), not intl.
Yu
--- /usr/share/vala/vapi/glib-2.0.vapi 2009-08-14 15:46:01.0 -0400
+++ glib-2.0.vapi 2009-09-01 17:17:13.0 -0400
@@ -3414,8 +3414,8 @@
public static weak string Q_ (string str);
[CCode (cname = "N_", cheader_filename = "glib.h,glib/gi18n-lib.h")]
public static weak string N_ (string str);
- [CCode (cname = "ngettext", cheader_filename = "glib.h,glib/gi18n-lib.h")]
- public static weak string ngettext (string msgid, string msgid_plural, ulong n);
+ [CCode (cname = "NC_", cheader_filename = "glib.h,glib/gi18n-lib.h")]
+ public static weak string NC_ (string context, string str);
[CCode (cname = "int", cprefix = "LC_", cheader_filename = "locale.h", has_type_id = false)]
public enum LocaleCategory {
@@ -3437,6 +3437,13 @@
public static weak string? textdomain (string? domainname);
[CCode (cname = "bind_textdomain_codeset", cheader_filename = "glib/gi18n-lib.h")]
public static weak string? bind_textdomain_codeset (string domainname, string? codeset);
+
+ [CCode (cname = "ngettext", cheader_filename = "glib.h,glib/gi18n-lib.h")]
+ public static weak string ngettext (string msgid, string msgid_plural, ulong n);
+ [CCode (cname = "g_dgettext", cheader_filename = "glib.h,glib/gi18n-lib.h")]
+ public static weak string dgettext (string domain, string msgid);
+ [CCode (cname = "g_dngettext", cheader_filename = "glib.h,glib/gi18n-lib.h")]
+ public static weak string dngettext (string domain, string msgid, string msgid_plural, ulong n);
}
[Compact]
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Bug 591972
Dear Maintainers, Could someone look at Bug 591972? I am depending on this. Some lower-level coding still needs the GTypes of the fundamental types. Most of them are OK, but G_TYPE_BOXED and those who deeply entangle with VALA are not. Since the `typeof' operator doesn't operate on `struct', `class', `enum', and `flag', my proposal is to add they type ids into GObject bindings. Regards, Yu ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Patch for BZ593734
See the attachment.
Without this patch the default signal handler is barely useful, since
'this' is not added to the hidden method's scope. The original test-case
didn't cover this issue. My bad.
Test case ---
public class Test {
public void print_this() {
message("%p", this);
}
public virtual signal void test() {
this.print_this();
print_this();
}
public static void main() {
Test t = new Test();
t.test();
}
}
--Cut ends
Yu
>From af5a0cf9b0e5b5ec4c581aaf4dc0b590eafd6139 Mon Sep 17 00:00:00 2001
From: Yu Feng
Date: Mon, 31 Aug 2009 20:21:45 -0400
Subject: [PATCH] Fix `this` access in def-signal-handlers(bz593734)
A new method, `add_hidden_method` is added into Vala.Class.
This method set up the method's scope and this_parameter,
but adds the method into methods collection.
These methods are hidden and anonymous from the class's point of
view, which is indeed useful for the default signal handlers.
There may also be other useful cases for these hidden methods,
which I couldn't dig out from my head with an empty stomach.
---
vala/valaclass.vala | 30 ++
vala/valasignal.vala |7 ++-
2 files changed, 36 insertions(+), 1 deletions(-)
diff --git a/vala/valaclass.vala b/vala/valaclass.vala
index 63b93e1..9f885c8 100644
--- a/vala/valaclass.vala
+++ b/vala/valaclass.vala
@@ -360,6 +360,36 @@ public class Vala.Class : ObjectTypeSymbol {
}
/**
+ * Adds the specified method as a hidden member to this class,
+ * primarily used for default signal handlers.
+ *
+ * The hidden methods are not part of the `methods` collection.
+ *
+ * There may also be other use cases, eg, convert array.resize() to
+ * this type of method?
+ *
+ * @param m a method
+ */
+ public void add_hidden_method (Method m) {
+ if (m.binding == MemberBinding.INSTANCE) {
+ if (m.this_parameter != null) {
+m.scope.remove (m.this_parameter.name);
+ }
+ m.this_parameter = new FormalParameter ("this", get_this_type ());
+ m.scope.add (m.this_parameter.name, m.this_parameter);
+ }
+ if (!(m.return_type is VoidType) && m.get_postconditions ().size > 0) {
+ if (m.result_var != null) {
+m.scope.remove (m.result_var.name);
+ }
+ m.result_var = new LocalVariable (m.return_type.copy (), "result");
+ m.result_var.is_result = true;
+ }
+
+ scope.add (null, m);
+ }
+
+ /**
* Returns a copy of the list of methods.
*
* @return list of methods
diff --git a/vala/valasignal.vala b/vala/valasignal.vala
index 79ede73..ea4dc95 100644
--- a/vala/valasignal.vala
+++ b/vala/valasignal.vala
@@ -247,6 +247,8 @@ public class Vala.Signal : Member, Lockable {
if (is_virtual) {
default_handler = new Method (name, return_type, source_reference);
+
+ default_handler.owner = owner;
default_handler.access = access;
default_handler.external = external;
default_handler.is_virtual = true;
@@ -254,11 +256,14 @@ public class Vala.Signal : Member, Lockable {
default_handler.signal_reference = this;
default_handler.body = body;
+
foreach (FormalParameter param in parameters) {
default_handler.add_parameter (param);
}
- parent_symbol.scope.add (null, default_handler);
+ var cl = parent_symbol as Class;
+
+ cl.add_hidden_method(default_handler);
default_handler.check (analyzer);
}
return !error;
--
1.6.2.5
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [Bug 590324] Syntax sugar for notifications
On Sun, 2009-08-30 at 19:03 +, Maciej Piechotka wrote: > Frederik writes: > > > The current syntax is: > > > > object.notify["property"] += ... // deprecated > > > > or > > > > object.notify["property"].connect (...) > > > > How is this hard? > > > > Best regards, > > > > Frederik > > > > Point for you. I haven't spotted this sytntax (I bet I searched both vala > documentation and tutorial), > It was indeed missing. I added the syntax to the tutorial (under Properties) a minute ago; Please check if my description was clear. Regards, Yu > Regards > > > ___ > Vala-list mailing list > Vala-list@gnome.org > http://mail.gnome.org/mailman/listinfo/vala-list ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Getting type name for GType based classes?
On Sat, 2009-08-22 at 22:14 -0400, Yu Feng wrote: > Dear List, > > Is it possible to get the type name of GType based classes at runtime ? > > I know it is possible to do this with GObject based classes with > Object.get_type(). But is this function useful with GType based classes? > > This might be relevant to my suggestion on `typeof` operator with type > instances. > > Regards, > > Yu My bad. A workaround is at http://bugzilla.gnome.org/show_bug.cgi?id=573075#c1 > > > ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Getting type name for GType based classes?
Dear List, Is it possible to get the type name of GType based classes at runtime ? I know it is possible to do this with GObject based classes with Object.get_type(). But is this function useful with GType based classes? This might be relevant to my suggestion on `typeof` operator with type instances. Regards, Yu ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Wrapping Errors in the vala way
On Sat, 2009-08-22 at 21:03 +0200, Jan Hudec wrote:
> On Sat, Aug 22, 2009 at 11:52:01 -0400, Yu Feng wrote:
> > On Sat, 2009-08-22 at 09:24 +0200, Jan Hudec wrote:
> > [...]
> > > Well, so the code further up the call stack is not going to look at the
> > > inner exception anyway except to print it to the operator, right? But for
> > > that, it's enough to embed the wrapped error's message into the wrapping
> > > error message. The error code is not relevant.
> > >
> > I buy your point.
> >
> > In an language like Java, the error(Exception) carries more than a
> > message and a code. It also includes a source code reference therefore
> > it make sense to save the cause as an data member.
> >
> > Nevertheless in the GObject case, because the error only carries an
> > code, and a message, there is no need to wrap the low level errors.
> > g_prefix_error would be sufficient as an substitute of 'wrapping'. How
> > can we invoke this function in vala though?
>
> If you are wrapping an error, you don't need that function. Instead you
> create a new error and use the inner error's message as one of the arguments
> for the message format string.
>
> The purpose of g_prefix_error is somewhat different. It's used to add context
> to the error without wrapping it. For example if you are accessing file and
> the function that detects the error only has a stream, the calling function
> might prefix it with the filename to indicate where the error happened.
>
> I think it would make sense to add it to the GError class in glib-2.0.vapi --
> if you find you have good use for it, just add it there and post a patch.
>
> > > By the way, you should be suggesting things like this on the Gtk list, not
> > > here.
> >
> > I thought it was a GObject feature which was highly relevant to Vala.
>
> Important goal of vala is to interoperate well with non-vala gobject code. So
> features like this would need to be added to glib.
>
Thank you! g_prefix_error is not what I want. This is what I want:
-
errordomain Exception {
HOMEWORK_NOT_FOUND
}
errordomain Execuse {
I_WAS_SICK
}
public static void main() {
try {
grade();
} catch(Exception e) {
stdout.printf("Could not grade: %s\n", e.message);
}
}
private void obtain_homework_from_student() throws Execuse {
throw new Execuse.I_WAS_SICK("I was sick");
}
private void grade() throws Exception {
try {
obtain_homework_from_student();
} catch (Execuse execuse) {
throw new Exception.HOMEWORK_NOT_FOUND("Homework not found: %s",
execuse.message);
}
}
Yu
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Why do regular reference types leak null?
On Sat, 2009-08-15 at 00:12 +0200, Jiří Zárevúcky wrote: > On 08/14/2009 10:57 PM, Sam Danielson wrote: > >> Why shouldn't they be null? IMO, it would just add much more trouble. > >> Checking nulls is responsibility of the programmer. That is consistent with > >> every other language I know, including dynamic ones, C#, Java, etc. > >> > > Perhaps I am misunderstanding the purpose of nullable types. The Vala > > tutorial explains, "By default, Vala will make sure that all reference > > point to actual objects." As I understand, the whole point of Foo? is > > so that we can have nulls without infecting Foo with a null variant. > > > > > > That section is wrong. (Who the hell wrote that?) > I've updated the tutorial regarding this. (diff 131) > It only applies to method arguments and return values, not variables. > Any variable of a reference type can be null, regardless of how it is > defined. According to juergbi, it has always been that way, and it will > not change in the near future (the analysis is way too complicated, I > personally don't see the need anyway). > > ___ > Vala-list mailing list > Vala-list@gnome.org > http://mail.gnome.org/mailman/listinfo/vala-list ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Wrapping Errors with g_prefix_error?
On Sat, 2009-08-22 at 09:24 +0200, Jan Hudec wrote: > On Thu, Aug 20, 2009 at 22:09:21 -0400, Yu Feng wrote: > > GError doesn't support error wrapping as Java does. Is GLib is purposely > > avoiding it? > > If not, it will become a useful feature as the number of libraries that > > uses GError grows, as the feature has already been proved useful in > > Java, (indicated in this article): > > > > http://tutorials.jenkov.com/java-exception-handling/exception-wrapping.html > > Actually, in my opinion that article nicely explains, why you do *not* need > to have the original error information there. > > article> The main reason one would use exception wrapping is to prevent the > article> code further up the call stack from having to know about every > article> possible exception in the system. > > Well, so the code further up the call stack is not going to look at the > inner exception anyway except to print it to the operator, right? But for > that, it's enough to embed the wrapped error's message into the wrapping > error message. The error code is not relevant. > I buy your point. In an language like Java, the error(Exception) carries more than a message and a code. It also includes a source code reference therefore it make sense to save the cause as an data member. Nevertheless in the GObject case, because the error only carries an code, and a message, there is no need to wrap the low level errors. g_prefix_error would be sufficient as an substitute of 'wrapping'. How can we invoke this function in vala though? > By the way, you should be suggesting things like this on the Gtk list, not > here. I thought it was a GObject feature which was highly relevant to Vala. Yu > ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Wrapping Errors
Dear List,
GError doesn't support error wrapping as Java does. Is GLib is purposely
avoiding it?
If not, it will become a useful feature as the number of libraries that
uses GError grows, as the feature has already been proved useful in
Java, (indicated in this article):
http://tutorials.jenkov.com/java-exception-handling/exception-wrapping.html
GError will need an extra field for chaining up the causes. gerror.h
doesn't have any preserved bytes for an extra field. However, because
GError is always accessed by pointers and no GLib program is supposed to
statically allocate memory for GError, it should be safe to append an
field to the internal structure of GError while keeping the ABI
compatible.
Two new proposed functions:
GError * g_error_new_with_cause(GQuark domain, gint code, GError ** cause,
const char* format, );
Returns an new GError with `cause' as its cause. `*cause' is set to NULL.
void g_set_error_with_cause(GError ** error, GQuark domain, gint code, GError
** cause, const char * format, ...);
sets *error to an error caused by *cause if error is not NULL. if error is
NULL, free *cause.
g_error_free should be modified so that all the chained up errors are freed.
Example:
my_function(GError ** error) {
GError * tmp_error = NULL;
some_io_function(, &tmp_error);
if(tmp_error != NULL) {
g_set_error_with_cause(error, MY_ERROR, MY_ERROR_NUMBER1, &tmp_error,
"some random error caused by some_io_function");
return;
}
/** do something else **/
}
Regards,
Yu
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Using 'as' for casting?
On Fri, 2009-08-07 at 17:38 +0200, Jiří Zárevúcky wrote:
> On 08/07/2009 05:19 PM, Daniel Svensson wrote:
> > When converting my application to use Gtk.Builder I ended up with a
> > lot of code like this:
> >
> > var lbl = builder.get_object("foo") as Gtk.Label;
> >
> > And this caused me to try the following:
> >
> > var time = Time.gm (unxtime as time_t);
> >
> > as it was more readable than:
> >
> > var time = Time.gm ((time_t) unxtime);
> >
> > This however is not valid syntax, but maybe it should be? On IRC I got
> > the answer that if an 'as' would fail it would return null, and that's
> > why it shouldn't work.
> >
> > I thought it was best to drop a mail to the list and see what people think.
> >
> >
>
> That's right, but it's not just the fact it can return null. You can't
> use 'as' for simple types because there is no way to do run-time type
> check for them, so no way to find out whether cast is valid (until the
> segfault, of course). So there is no way 'as' could work for them.
>
So the difference between 'as' and '(Type)' is that
(1) 'as' is run-time, aka, dynamic
(2) '(Type)' is compile-type, aka, static
For structs doesn't carry sufficient type information for a run-time
casting, '(type)' casting is the only reasonable way for it.
Yu
> ___
> Vala-list mailing list
> Vala-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/vala-list
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] GObject-introspection and vapi
On 3), > > 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?) If they are not subclasses of GType, I guess you can map them into Compact Classes. Yu > > Regards, > Jan > > > ___ > Vala-list mailing list > Vala-list@gnome.org > http://mail.gnome.org/mailman/listinfo/vala-list ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] glib-object.h?
Dear list, gobject-2.0.vapi pulls in . but the GNOME guidelines says the header should not be included. http://live.gnome.org/GnomeGoals/CleanupGTKIncludes [CCode (ref_function = "g_object_ref", unref_function = "g_object_unref", marshaller_type_name = "OBJECT", get_value_function = "g_value_get_object", set_value_function = "g_value_set_object", param_spec_function = "g_param_spec_object", cheader_filename = "glib-object.h")] Is it a problem of ours or a problem of theirs? Devhelp says glib-object.h is the correct header for GObject. Yu ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Errors handling in vala compiler
Dear list, Is there any documents/instructions on how grammar/semantics erros handled by the compiler? I can see there is a 'check' method for each node which recursively checks the children of the node. It returns a false on error, and writes the error message to stderr. But how and why does the compiler exit when the method returns false? Why isn't this part using the throw/catch handling? I am looking into this because I am evaluating the possibility of parsing and constructing the ast in valide with libvala. The IDE won't be happy if libvala reports to stderr and aborts for errors. Regards, Yu ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] GLib.SList as a property
On Tue, 2009-07-07 at 10:50 -0300, Lucas Hermann Negri wrote:
> Just:
>
But how is h_labels defined? unonwed h_labels?
Yu
> public SList labels { get{return h_labels;} set{h_labels = value;} }
>
> On Tue, Jul 7, 2009 at 12:44 AM, Yu Feng wrote:
> >
> > On Mon, 2009-07-06 at 13:08 -0300, Lucas Hermann Negri wrote:
> >> I didn't added anything to the list. Just created and destroyed the
> >> class that had this property, and it leaked.
> >
> > How could it be? Could you post the code? I am confused.
> >
> > Yu
> >>
> >> On Mon, Jul 6, 2009 at 3:28 AM, Yu Feng wrote:
> >> > On Sun, 2009-07-05 at 00:55 -0300, Lucas Hermann Negri wrote:
> >> >> Hello,
> >> >>
> >> >> I have a property of GLib.SList type, defined this way:
> >> >>
> >> >> "
> >> >> public SList labels { get{return h_labels;} set{h_labels =
> >> >> value;} }
> >> >> "
> >> >>
> >> >> But this leaks memory. What's the correct way of doing this?
> >> > I don't think SList itself comes with a leak: the list is
> >> > properly destructed, so are the members. The leak does occur when one
> >> > removes an element from the list -- in other words there won't be a leak
> >> > if you merely use the list to hold the references and never remove
> >> > anything from it.
> >> >
> >> >>
> >> >> Also, how do I create a property of type string[]? I tried this way:
> >> >>
> >> >> "
> >> >> public string[] test { get; set; }
> >> >> "
> >> >>
> >> >> But the generated C code doesn't compiles.
> >> >>
> >> >> Another issue:
> >> >>
> >> >> I'm using a PangoLayout created using
> >> >> Pango.cairo_create_layout(plot.cr), but I need to call unref() by hand
> >> >> in the destructor. This is the correct behavior or just a bug in the
> >> >> binding (other objects are managed automatically) ?
> >> >>
> >> >>
> >> >> Thanks for the attention.
> >> >>
> >> >
> >> >
> >>
> >>
> >>
> >
> >
>
>
>
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] GLib.SList as a property
On Mon, 2009-07-06 at 13:08 -0300, Lucas Hermann Negri wrote:
> I didn't added anything to the list. Just created and destroyed the
> class that had this property, and it leaked.
How could it be? Could you post the code? I am confused.
Yu
>
> On Mon, Jul 6, 2009 at 3:28 AM, Yu Feng wrote:
> > On Sun, 2009-07-05 at 00:55 -0300, Lucas Hermann Negri wrote:
> >> Hello,
> >>
> >> I have a property of GLib.SList type, defined this way:
> >>
> >> "
> >> public SList labels { get{return h_labels;} set{h_labels = value;}
> >> }
> >> "
> >>
> >> But this leaks memory. What's the correct way of doing this?
> > I don't think SList itself comes with a leak: the list is
> > properly destructed, so are the members. The leak does occur when one
> > removes an element from the list -- in other words there won't be a leak
> > if you merely use the list to hold the references and never remove
> > anything from it.
> >
> >>
> >> Also, how do I create a property of type string[]? I tried this way:
> >>
> >> "
> >> public string[] test { get; set; }
> >> "
> >>
> >> But the generated C code doesn't compiles.
> >>
> >> Another issue:
> >>
> >> I'm using a PangoLayout created using
> >> Pango.cairo_create_layout(plot.cr), but I need to call unref() by hand
> >> in the destructor. This is the correct behavior or just a bug in the
> >> binding (other objects are managed automatically) ?
> >>
> >>
> >> Thanks for the attention.
> >>
> >
> >
>
>
>
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] GLib.SList as a property
On Sun, 2009-07-05 at 00:55 -0300, Lucas Hermann Negri wrote:
> Hello,
>
> I have a property of GLib.SList type, defined this way:
>
> "
> public SList labels { get{return h_labels;} set{h_labels = value;} }
> "
>
> But this leaks memory. What's the correct way of doing this?
I don't think SList itself comes with a leak: the list is
properly destructed, so are the members. The leak does occur when one
removes an element from the list -- in other words there won't be a leak
if you merely use the list to hold the references and never remove
anything from it.
>
> Also, how do I create a property of type string[]? I tried this way:
>
> "
> public string[] test { get; set; }
> "
>
> But the generated C code doesn't compiles.
>
> Another issue:
>
> I'm using a PangoLayout created using
> Pango.cairo_create_layout(plot.cr), but I need to call unref() by hand
> in the destructor. This is the correct behavior or just a bug in the
> binding (other objects are managed automatically) ?
>
>
> Thanks for the attention.
>
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Working with GLib.List and memory management
On Wed, 2009-07-01 at 01:24 +0400, Кутейников Дмитрий wrote: > It is some sort of a bug (or a feature). Vala inserts g_object_ref in > generated C-code after myList.prepend(myWidget); but it doesn't > decrease ref_counter after remove. The only way is to use > g_object_unref manually. What you said is right. But that's not the full story. If we look at Adi's code more carefully, myList is not a List it is a List. vala doesn't manage a List's member. The remaining ref adi observed, I bet, is the ref held by myWidget. Gtk.Widget.destroy sends a destroy signal to all ref holders of mywidget asking them to release the reference. The signal was ignored. This reference is released when the variable myWidget leaves its domain. Yu > ___ > Vala-list mailing list > Vala-list@gnome.org > http://mail.gnome.org/mailman/listinfo/vala-list ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Port Tomboy?
On Sat, 2009-06-27 at 14:24 +0200, Jiří Zárevúcky wrote: > 2009/6/27 Yu Feng : > > On Sat, 2009-06-27 at 08:03 +0100, Sam Liddicott wrote: > >> > >> 4. Port Tomboy as a show-case project port > >> > > > > 4 seems to be very fun; how large is the codebase of tomboy? > > > > BTW: What is the largest show-case project driven by VALA, excluding > > vala itself? Here I am not limiting within project ported from mono. > > > > I'm not sure any "show-case port" is a good idea. The differences and > comparison can be written down in a single document. Regardless > the potential advantages of two directly comparable > project, imagine what would it cause in a larger scale. gnote is > already seen as a "good" counterpart to an "evil" project in the eyes > of almost religionistic mono-haters and it is a denial of Tomboy's > actual achievement. Imagine that someone would copy your original cool > project just because he doesn't like the language. I'm sure it would > make you angry. > > If some of the Vala community try to make it some kind of > "replacement" to Mono platform (which itself is a stupid idea) the > earlier noted group would immediately make it to be some kind of > "saviour that shall release us from the hands of all evil (Mono, > Microsoft, Novell)". That could possibly result in a complete > alienation of Vala and Mono communities. > > Vala must by no means accept any role in the "struggle" (more like a > series of irrational personal insults in my opinion) that is taking > place between the Mono community and those who are not willing to > accept their freedom of choice. It would only hurt the project. > > Well, so much for my opinions on this matter. > I agree with you. Porting for the porting's sake is nothing but harmful. Nonetheless I still think if VALA needs bigger, live projects to increase the level awareness which it deserves. At least among the open-source vala projects tracked by ohloh, I don't see any of them a critical application(by critical I mean a real develop team, active development and large codebase). I don't think this situation is healthy for the language's eco-system. I would like to do a survey/study about the situation. How do you think? Regards, Yu > -- Jury ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Port Tomboy?
On Sat, 2009-06-27 at 08:03 +0100, Sam Liddicott wrote: > Raphael Bosshard wrote: > > I'd rather like a possibility to automatically convert (or > > semi-convert, with manual fixes) C# code to Vala. There are some > > C#/Mono libraries out there (like Banshees ListView implementation) > > which provide a real benefit. Right now these libraries are only > > available to Mono applications. In some cases it would make sense to > > have a 'low level' implementation. It would be nice if they were > > available for the whole Gnome eco-system. > I hadn't considered how it would enrich gnome in general, but of > course you are right, and this is one of the advantages of Vala. > > > The "on topic" results of the thread so far are: > > 1. automatic language conversion of C# > The code won't compile but the syntax would be valid. > * Maybe Vala's parser could parse C# into a Vala AST > which it could re-emit as vala code > * Maybe some perl/python tool to fix up or highlight the > various constructs > * Maybe just conversion of the mono project files into > an automake file > 2. vapi/vala re-writes of some common mono dependencies > (This would also improve the gnome eco-system) > If these can be made available to mono again, it would support > a seamless bottom up migration > 3. Improve vala documentation (particularly to be useful for > developers not familiar with gobject) > 4. Port Tomboy as a show-case project port 4 seems to be very fun; how large is the codebase of tomboy? BTW: What is the largest show-case project driven by VALA, excluding vala itself? Here I am not limiting within project ported from mono. -Yu > > Sam > ___ > Vala-list mailing list > Vala-list@gnome.org > http://mail.gnome.org/mailman/listinfo/vala-list ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] enum typing
BTW: if there is a pkgconfig file for oci, please make sure the main vapi file's name (the one that pulls in all dependencies) matches the .pc file's name. Otherwise `valac --pkg oci your-program.vala' won't work. Yu On Fri, 2009-06-26 at 22:39 -0600, Shawn Ferris wrote: > > > > > > Now, in the Vapi, I could do this to type args: (HType being the enum in > > > this case) > > > > > > public int HandleFree ( > > > void* handlp, > > > HType type > > > ); > > > > > > so, I'm not sure what the difference really is? > > > > > looks like you triggered a bug in valac about defualt property values of > > non-native types. > > I wondered if I hadn't.. I'll file a bug report > > > > Also, I was curious about separating api's into multiple vapi.. For > > > instance, the oracle one is huge, if I ever get to the point that the > > > entire thing is impletement (unlikely) but, to make it easy for myself, > > > I created oci_enums.vapi, oci_structs.vapi and oci.vapi for everthing > > > that doesn't fit in structs and enums.. Then I used oci.deps to pull in > > > structs and enums.. is that a good idea, or should the final product be > > > a single concatenated view of the three? > > > > > > > did you consider the possibility splitting the API into files by > > functionality? > > I hadn't considered that actually.. but, the more I thought about it, > it's only used during the compile, so I'm not sure it matters one way or > the other.. but, if I were to install the oci.vapi file into the system > vapi directory, I'm guessing one file would be preferred and that can be > easilly handled through the makefiles. > > Thanks Yu! > > SMF > ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] enum typing
On Fri, 2009-06-26 at 21:40 -0600, Shawn Ferris wrote:
> Hello again,
>
> As you know, I've been working on the Oracle OCI bindings. Now that it's
> funcational, I wanna wrap it into a more friendly, vala style interface.
> I would like more of the options as properties, but I'm not sure if
> there's a special way to define them. EG:
>
> using OCI;
> public class Test : GLib.Object {
> public OCI.Mode mode { get; set; default = OCI.Mode.DEFAULT; }
> }
>
> Vala doesn't seem to think this is a problem, but gcc pukes all over it,
> and I sorta understand why. It's not really a type, it's a group of
> values, but they're all int and I don't want to have to hard code that
> fact if down the road oracle decides it shouldn't be.
>
> Now, in the Vapi, I could do this to type args: (HType being the enum in
> this case)
>
> public int HandleFree (
> void* handlp,
> HType type
> );
>
> so, I'm not sure what the difference really is?
>
looks like you triggered a bug in valac about defualt property values of
non-native types.
> Also, I was curious about separating api's into multiple vapi.. For
> instance, the oracle one is huge, if I ever get to the point that the
> entire thing is impletement (unlikely) but, to make it easy for myself,
> I created oci_enums.vapi, oci_structs.vapi and oci.vapi for everthing
> that doesn't fit in structs and enums.. Then I used oci.deps to pull in
> structs and enums.. is that a good idea, or should the final product be
> a single concatenated view of the three?
>
did you consider the possibility splitting the API into files by
functionality?
> As always, appreciate any advice!
>
> ___
> Vala-list mailing list
> Vala-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/vala-list
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] DBus object at multiple paths
Dear Michael, On Fri, 2009-06-26 at 14:41 +0200, Michael 'Mickey' Lauer wrote: > Dear Yu, > > Am Freitag, den 26.06.2009, 08:52 +0800 schrieb Yu Feng: > > Long time ago before the DBus is rewritten we can use > > Connection.register_object in dbus-glib-1.vapi > > > > Not sure if it is still useful nowadays. > > I spotted this, but calling it more than once seems to have no effect. My bad. Look at this line: http://cgit.freedesktop.org/dbus/dbus-glib/tree/dbus/dbus-gobject.c#n2140 A short glance doesn't tell me why dbus_g_connection_register_g_object avoids duplicated registrations. Especially if the "dbus_glib_object_registration" member is replaced with a GList. Can you see any other reasons? Should we file a bug to dbus-glib? Regards, Yu > > :M: > > ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Patches regarding switch(GType) and more
Dear Jurg,
These patches provide a foundation for non-constant switches. They solve
the GType issue mentioned by you.
The .vala files are tests.
switch-type-ok.vala contains all constant GType labels. It compiles fine
into valid C code.
switch-type-fail.vala contains mixed constant and non-constant labels.
It yields an error 'non-constant case label is not yet supported'.
(0003) We can later support it, or remove the word 'yet'.
In 0003, member function is_constant is added to SwitchLabel; it is true
for the default label(the one without expression). member function
is_all_constant is added to SwitchSection and SwitchStatement.
New CCode attribute type_id_const is introduced(0004, 0005) to indicate
whether the type id is a C constant(Class.type_id_const,
Enum.type_id_const, Struct.type_id_const). The TypeOfExpression is also
a vala constant if the type id is a C constant(0006).
It is perhaps more appropriate to use const type definitions (eg, const
class {} or const struct {}) for this purpose. Because in that way we
don't specifically depend on the GObject/CCode backend. That will be a
grammar change; I dare not do it.
MemberAccess to EnumValue weren't correctly deduced as Vala constant.
Patch 0002 fixes this issue.
0001 is the old patch to gobject-2.0 binding about IntegerType. I
remember some time ago we preferred not to inherit from GBoxed but
directly declare the structs. Why don't we do the same for GType: ulong
this time?
I am not sure if the work worth the effort: literally it only added
support for GType in switch statements. Nevertheless some of subtle
might be useful to improve the internal of the compiler.
Regards,
Yu
>From 3b4ac1cec5b459287e45fc3d681a65f4a539c593 Mon Sep 17 00:00:00 2001
From: Yu Feng
Date: Thu, 25 Jun 2009 16:00:55 +0800
Subject: [PATCH] GType is a IntegerType + SimpleType
Refer to Sam's email on Jun 24th Switch statement on GType.
I can't access mail-archive in china; weird.
---
vapi/gobject-2.0.vapi |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/vapi/gobject-2.0.vapi b/vapi/gobject-2.0.vapi
index 54b53e0..d902452 100644
--- a/vapi/gobject-2.0.vapi
+++ b/vapi/gobject-2.0.vapi
@@ -26,8 +26,10 @@
[CCode (cprefix = "G", lower_case_cprefix = "g_", cheader_filename = "glib.h")]
namespace GLib {
+ [SimpleType]
[CCode (type_id = "G_TYPE_GTYPE", marshaller_type_name = "GTYPE", get_value_function = "g_value_get_gtype", set_value_function = "g_value_set_gtype")]
- public struct Type : ulong {
+ [IntegerType (rank = 9)]
+ public struct Type {
[CCode (cname = "G_TYPE_IS_OBJECT")]
public bool is_object ();
[CCode (cname = "G_TYPE_IS_ABSTRACT")]
--
1.6.0.6
>From 71dc1e9fc3d11dcc26618b2f83feba2748c55b1a Mon Sep 17 00:00:00 2001
From: Yu Feng
Date: Fri, 26 Jun 2009 10:00:47 +0800
Subject: [PATCH] EnumValue is a constant
---
vala/valamemberaccess.vala |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/vala/valamemberaccess.vala b/vala/valamemberaccess.vala
index 2ef15a4..7c01a84 100644
--- a/vala/valamemberaccess.vala
+++ b/vala/valamemberaccess.vala
@@ -187,6 +187,8 @@ public class Vala.MemberAccess : Expression {
public override bool is_constant () {
if (symbol_reference is Constant) {
return true;
+ } else if (symbol_reference is EnumValue) {
+ return true;
} else {
return false;
}
--
1.6.0.6
>From 7b58ecb6c242e6a4b0ba6867117968b2986d6230 Mon Sep 17 00:00:00 2001
From: Yu Feng
Date: Fri, 26 Jun 2009 10:01:29 +0800
Subject: [PATCH] Deduces is_all_constant in switch statements
Currently non-constant case labels are not supported.
---
vala/valaswitchlabel.vala | 10 +-
vala/valaswitchsection.vala | 12
vala/valaswitchstatement.vala | 20
3 files changed, 41 insertions(+), 1 deletions(-)
diff --git a/vala/valaswitchlabel.vala b/vala/valaswitchlabel.vala
index a778ce2..67cb16c 100644
--- a/vala/valaswitchlabel.vala
+++ b/vala/valaswitchlabel.vala
@@ -65,11 +65,19 @@ public class Vala.SwitchLabel : CodeNode {
}
}
+ /* for default label this flag is also true */
+ private bool _is_constant = true;
+
public override bool check (SemanticAnalyzer analyzer) {
if (expression != null) {
expression.check (analyzer);
+ _is_constant = expression.is_constant();
}
-
+
return true;
}
+
+ public bool is_constant () {
+ return _is_constant;
+ }
}
diff --git a/vala/valaswitchsection.vala b/vala/valaswitchsection.vala
index 27c02c2..bacad15 100644
--- a/vala/valaswitchsection.vala
+++ b/vala/valaswitchsection.vala
@@ -67,6 +67,15 @@ public class Vala.SwitchSection : Block {
return false;
}
+ private bool _is_all_constant = true;
+ /**
+ * Return if all labels are constant
+ *
+ * @return if all labels are constant
+ */
+ public bool is_all_constant () {
[Vala] isn't EnumValue a constant?
line 162, valamemberaccess.vala returns true for Constant; however isn't enumvalue also a constant? Yu ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] DBus object at multiple paths
Long time ago before the DBus is rewritten we can use Connection.register_object in dbus-glib-1.vapi Not sure if it is still useful nowadays. Yu On Thu, 2009-06-25 at 23:51 +0200, Michael 'Mickey' Lauer wrote: > Hi, > > DBus allows server objects to be present at multiple paths; apparantly > dbus_connection_register_object_path should be called multiple times for > that, however this part is done in the codegen. > > Any idea how we could access adding an existing object to another path > from Vala? > > Thanks, > > :M: > > ___ > Vala-list mailing list > Vala-list@gnome.org > http://mail.gnome.org/mailman/listinfo/vala-list ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [PATCH] GType is a IntegerType + SimpleType
On Thu, 2009-06-25 at 18:19 +0200, Jürg Billeter wrote: > On Thu, 2009-06-25 at 16:09 +0800, Yu Feng wrote: > > Refer to Sam's email on Jun 24th Switch statement on GType. > > The reason why GType is not supported in switch statements is because > typeof expressions are not considered constant expressions. While there > are a few basic GTypes that are constants in C, this is not true for > types defined outside GLib. > No. The reason why GType is not supported, is because of valaswitchstatement.vala:109, the IntegerType check. No const/non-const check is performed at all. > If we apply your patch, valac will generate invalid C code if you use > typeof expressions that are not constant in C. > Thus a different issue is involved. We can fix the wrong binding then fix the invalid C-code. I assume each symbol already has a flag specifying if it is const or not(correct me if i am wrong) Then the check should be simple. After the check we can steal the 'if-else' chain in visit_string_switch_statement to make a fix. Regards, Yu > Jürg > ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [Patch] Small improvements on gsl bindings
On Thu, 2009-06-25 at 18:31 +0200, Jürg Billeter wrote: > Hi Yu, > > On Thu, 2009-06-25 at 21:53 +0800, Yu Feng wrote: > > Here are a few small improvements on gsl bindings. > > > > Several places the pointers are properly replaced by arrays, and several > > delegates are handled the native vala way. > > Thanks for the patch. It does not apply on master, though. > > patching file vapi/gsl.vapi > Reversed (or previously applied) patch detected! Skipping patch. Sorry, it was a reversed patch. I made a diff with the master and my local version(not on the git). the two file names must be misplaced. patch -R should apply it cleanly. > 6 out of 6 hunks ignored -- saving rejects to file vapi/gsl.vapi.rej > > Jürg > ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] [Patch] Small improvements on gsl bindings
Dear list,
Here are a few small improvements on gsl bindings.
Several places the pointers are properly replaced by arrays, and several
delegates are handled the native vala way.
- Yu
--- vapi/gsl.vapi 2009-06-19 15:45:23.0 +0800
+++ ../vala/vapi/gsl.vapi 2009-06-25 07:06:59.0 +0800
@@ -2978,8 +2978,8 @@
public double* F;
[CCode (cname="gsl_ran_discrete_preproc")]
- public RanDiscrete ([CCode (array_length_pos = 0.9)] double[] P);
- [CCode (cname="gsl_ran_discrete", instance_pos = -1)]
+ public RanDiscrete (size_t K, double* P);
+ [CCode (cname="gsl_ran_discrete")]
public size_t discrete (RNG g);
[CCode (instance_pos=-1)]
public double pdf (size_t k);
@@ -3396,9 +3396,8 @@
DEC
}
- public delegate int OdeivFunction (double t, [CCode (array_length = false)] double[] y, [CCode (array_length = false)] double[] dydt);
- public delegate int OdeivJacobian (double t, [CCode (array_length = false)] double[] y, [CCode (array_length = false)] double[] dfdy, [CCode (array_length = false)] double[] dfdt);
-
+ public static delegate int OdeivFunction (double t, [CCode (array_length = false)] double[] y, [CCode (array_length = false)] double[] dydt, void* params);
+ public static delegate int OdeivJacobian (double t, [CCode (array_length = false)] double[] y, [CCode (array_length = false)] double[] dfdy, [CCode (array_length = false)] double[] dfdt, void* params);
public static delegate void* OdeivStepAlloc (size_t dim);
public static delegate int OdeivStepApply (void* state, size_t dim, double t, double h, [CCode (array_length = false)] double[] y, [CCode (array_length = false)] double[] yerr, [CCode (array_length = false)] double[] dydt_in, [CCode (array_length = false)] double[] dydt_out, OdeivSystem* dydt);
public static delegate int OdeivStepReset (void* state, size_t dim);
@@ -3413,9 +3412,7 @@
[CCode (cname="gsl_odeiv_system", cheader_filename="gsl/gsl_odeiv.h")]
public struct OdeivSystem
{
- [CCode (delegate_target = false)]
public OdeivFunction function;
- [CCode (delegate_target = false)]
public OdeivJacobian jacobian;
public size_t dimension;
public void* params;
@@ -3465,7 +3462,7 @@
public string name ();
public uint order ();
- public int apply (double t, double h, [CCode (array_length = false)] double[] y, [CCode (array_length = false)] double[] yerr, [CCode (array_length = false)] double[]? dydt_in, [CCode (array_length = false)] double[]? dydt_out, OdeivSystem* dydt);
+ public int apply (double t, double h, [CCode (array_length = false)] double[] y, [CCode (array_length = false)] double[] yerr, [CCode (array_length = false)] double[] dydt_in, [CCode (array_length = false)] double[] dydt_out, OdeivSystem* dydt);
}
[SimpleType]
@@ -3517,7 +3514,7 @@
[CCode (cname="gsl_odeiv_evolve_alloc")]
public OdeivEvolve (size_t dim);
- public int apply (OdeivControl con, OdeivStep step, OdeivSystem* dydt, ref double t, double t1, ref double h, [CCode (array_length = false)] double[] y);
+ public int apply (OdeivControl con, OdeivStep step, OdeivSystem* dydt, [CCode (array_length = false)] double[] t, double t1, [CCode (array_length = false)] double[] h, [CCode (array_length = false)] double[] y);
public int reset ();
}
@@ -3989,7 +3986,7 @@
public static delegate int MultirootFdfFree (void* state);
[SimpleType]
- [CCode (cname="gsl_multiroot_function", cheaer_filename="gsl/gsl_multiroots.h")]
+ [CCode (cname="gsl_multiroot_function", cheader_filename="gsl/gsl_multiroots.h")]
public struct MultirootFunction
{
public MultirootF f;
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] [PATCH] Add parenthesis to macro substitutions
Only for expressions. No parenthesis is added to string macros.
A test is attached. Without the patch compiles to a wrong expression.
---
ccode/valaccodemacroreplacement.vala |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/ccode/valaccodemacroreplacement.vala
b/ccode/valaccodemacroreplacement.vala
index 1737c2e..8c00b80 100644
--- a/ccode/valaccodemacroreplacement.vala
+++ b/ccode/valaccodemacroreplacement.vala
@@ -59,7 +59,9 @@ public class Vala.CCodeMacroReplacement : CCodeNode {
if (replacement != null) {
writer.write_string (replacement);
} else {
+ writer.write_string ("(");
replacement_expression.write (writer);
+ writer.write_string (")");
}
writer.write_newline ();
}
--
1.6.0.6
public const double = 1.0 * 3.0;
public const double = 2.0 / ;
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] [PATCH] GType is a IntegerType + SimpleType
Refer to Sam's email on Jun 24th Switch statement on GType.
I can't access mail-archive in china; weird.
---
vapi/gobject-2.0.vapi |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/vapi/gobject-2.0.vapi b/vapi/gobject-2.0.vapi
index 54b53e0..d902452 100644
--- a/vapi/gobject-2.0.vapi
+++ b/vapi/gobject-2.0.vapi
@@ -26,8 +26,10 @@
[CCode (cprefix = "G", lower_case_cprefix = "g_", cheader_filename = "glib.h")]
namespace GLib {
+ [SimpleType]
[CCode (type_id = "G_TYPE_GTYPE", marshaller_type_name = "GTYPE",
get_value_function = "g_value_get_gtype", set_value_function =
"g_value_set_gtype")]
- public struct Type : ulong {
+ [IntegerType (rank = 9)]
+ public struct Type {
[CCode (cname = "G_TYPE_IS_OBJECT")]
public bool is_object ();
[CCode (cname = "G_TYPE_IS_ABSTRACT")]
--
1.6.0.6
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Loop not found?
On Thu, 2009-06-25 at 09:24 +0200, Jürg Billeter wrote:
> On Thu, 2009-06-25 at 07:17 +0800, Yu Feng wrote:
> > I was trying to catch up with recent vala master branch, but I get this
> > error:
> >
> > valacodevisitor.vala:308.34-308.37: error: The type name `Loop' could not
> > be found
> > public virtual void visit_loop (Loop stmt) {
> > [...]
> > Nevertheless git reports the working copy is uptodate and clean.
> > valaloop.vala is in the source file list.
>
> Looks like you've run ./configure without --enable-maintainer-mode.
> Always use ./autogen.sh instead of ./configure when building from git
> and everything should build fine.
>
well the maintainer mode is enabled.
But there is a warning saying automake-1.10 not found -- I guess because
of this automake didn't proceed, and makefile.in wasn't updated. Rerun
autogen.sh solves the problem. Thanks for reminding me.
Was there any changes related to the automake version recently?
I didn't notice autogen was calling autoreconf until today.
Regards,
Yu
> Jürg
>
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] libyaml-glib: YAML and GObject
Dear list(s),
I have been playing around GLib and libyaml with vala for a couple of
months. While I don't see a clear future of the code, I would like to
post a link to my code in case it will be useful to others.
The library is written in VALA, but one can write applications and link
against it in the same way as against other traditional GLib libraries.
This library provides the geometry object builder for a simulation
program I was writing at IU. It includes two parts:
a) a native representation of YAML nodes in GLib data type.
GList <-> Sequence
GHashTable <-> Mapping
gchar * <-> Scalar
However, as the fundamental containers in GLib are type-unaware,
decorators(is it the correct name?) are added to store the
type-information, as well as extra document stream information.
GYAMLNodeSequence <-> Sequence
GYAMLNodeMapping <-> Mapping
GYAMLNodeScalar <-> Scalar
GYAMLNodeAnchor <-> Anchor
The corresponding data structures in libyaml are not used, as they do
not work nicely with vala.
this part is based on the yaml wrapper in gore (gore @ sourceforge)[2];
b) an object builder that builds GObject from YAML,
The builder scans the YAML tree created by GYAMLParser, and builds
GYAMLBuildable objects from the document tree. GYAMLBuildable is
designed in such a way that it is compatible with GtkBuildable unless
the API is XML/YAML specific; nevertheless so far the interface is not
interchangeable with GtkBuildable, because one of the changes needed in
vala 'doen't make sense'.[1]
A short installation guide is at
http://github.com/fengy-research/libyaml-glib
The code can be obtained via
git clone git://github.com/fengy-research/libyaml-glib.git
The draft documentation(compiled by valadoc) is temporarily available at
http://www.does-exist.info/yaml-glib/Documentation/libyaml-glib-1.0/index.htm
More techy details are discussed under GYAMLBuilder, GYAMLBuildable, and
GYAMLDocument.
The attachment is a program that converts the standard invoice example
into GObject objects. After the library is properly installed, compile
with
valac --pkg libyaml-glib-1.0 libyaml-glib-builder.vala -X -export-dynamic
Your feedback is welcomed.
Regards,
Yu
[1] http://bugzilla.gnome.org/show_bug.cgi?id=584400
[2]
http://gore.svn.sourceforge.net/viewvc/gore/trunk/server/yaml_helper.c
http://gore.svn.sourceforge.net/viewvc/gore/trunk/server/libyaml-wrapper.vala
using GLib.YAML;
public class Invoice: GLib.Object, Buildable {
public int invoice {get; set;}
public string date {get; set;}
public Contact bill_to {get; set;}
public Contact ship_to {get; set;}
public double tax {get; set;}
public double total {get; set;}
public string comments {get; set;}
private List products;
public void add_child(Builder builder, GLib.Object child, string? type) throws GLib.Error {
products.prepend((Product)child);
}
public Type get_child_type (Builder builder, string tag) {
if(tag == "product") {
return typeof(Product);
}
return Type.INVALID;
}
public string summary(StringBuilder? sb = null) {
StringBuilder sb_ref = null;
if(sb == null) {
sb_ref = new StringBuilder("");
sb = sb_ref;
}
sb.append_printf("%d\n", invoice);
sb.append_printf("%s\n", date);
sb.append_printf("%g\n", tax);
sb.append_printf("%g\n", total);
sb.append_printf("%s\n", comments);
foreach(var p in products) {
sb.append_printf("%s %d %s %g\n", p.sku, p.quantity, p.description, p.price);
}
sb.append_printf("%s %s \n %s %s %s %s\n",
bill_to.given,
bill_to.family,
bill_to.address.lines,
bill_to.address.city,
bill_to.address.state,
bill_to.address.postal);
sb.append_printf("%s %s \n %s %s %s %s\n",
ship_to.given,
ship_to.family,
ship_to.address.lines,
ship_to.address.city,
ship_to.address.state,
ship_to.address.postal);
return sb.str;
}
}
public class Product : GLib.Object, Buildable {
public string sku {get; set;}
public int quantity {get; set;}
public string description {get; set;}
public double price {get; set;}
}
public class Contact : GLib.Object, Buildable {
public string given {get; set;}
public string family {get; set;}
public Address address {get; set;}
}
public class Address : Object, Buildable {
public string lines {get; set;}
public string city {get; set;}
public string state {get; set;}
public string postal {get; set;}
}
const string buffer =
"""
# This is the YAML 1.1 example. The YAML 1.2 example fails.
--- !Invoice
invoice: 34843
date : 2001-01-23
bill-to: &id001
given : Chris
family : Dumars
address:
lines: |
458 Walkman Dr.
Suite #292
city: Royal Oak
state : MI
postal : 48046
ship-to: *id001
product:
- sku : BL394D
quantity: 4
description : Basketball
price : 450.00
- sku : BL4438H
quantity: 1
description : Super Hoop
price : 2392.00
tax : 251.42
total: 4443.52
comments:
La
[Vala] Loop not found?
Dear list,
I was trying to catch up with recent vala master branch, but I get this
error:
valacodevisitor.vala:308.34-308.37: error: The type name `Loop' could not be
found
public virtual void visit_loop (Loop stmt) {
valacodewriter.vala:1101.35-1101.38: error: The type name `Loop' could not be
found
public override void visit_loop (Loop stmt) {
valaflowanalyzer.vala:658.35-658.38: error: The type name `Loop' could not be
found
public override void visit_loop (Loop stmt) {
valanullchecker.vala:155.35-155.38: error: The type name `Loop' could not be
found
public override void visit_loop (Loop stmt) {
valasymbolresolver.vala:383.35-383.38: error: The type name `Loop' could not be
found
public override void visit_loop (Loop stmt)
Nevertheless git reports the working copy is uptodate and clean.
valaloop.vala is in the source file list.
I was using 0.7.3. Did I miss a release?
Regards,
Yu
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Switch statement on GType.
On Sat, 2009-06-20 at 09:34 -0700, Sam Danielson wrote:
> Under Vala 0.6 the following worked.
>
> switch (tree_store.get_column_type (n)) {
> case typeof(string):
> ...
> break;
> }
>
>
> In Vala 0.7 it does not -- error: Integer or string expression expected.
>
Should it actually be 'error: Integer or string literal expected.'?
> But GLib.Type derives from ulong so this seems to violate the Liskov
> substitution principle. Is this a bug or desired behavior?
>
> -Sam Danielson
> ___
> Vala-list mailing list
> Vala-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/vala-list
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] [Patch] GCC error with markup parser
Hi Jiri,
I think it is a bug in glib-2.0.vapi.
Although it looks irrelevant, this patch solves your problem.
- Yu
On Sun, 2009-06-07 at 02:26 +0200, Jiří Zárevúcky wrote:
> Hi,
>
> I'm trying to use GLib's markup parser, but I'm getting the following
> error. Is that a bug or some mistake on my side?
>
> j...@jury-ubuntu:path$ valac Parser.vala -o Parser
> path/Parser.vala.c: In function ‘test_parser_constructor’:
> path/Parser.vala.c:168: error: ‘GMarkupParserStartElementFunc’
> undeclared (first use in this function)
> path/Parser.vala.c:168: error: (Each undeclared identifier is reported only
> once
> path/Parser.vala.c:168: error: for each function it appears in.)
> path/Parser.vala.c:168: error: expected ‘;’ before ‘_tmp1_’
> path/Parser.vala.c:169: error: ‘GMarkupParserEndElementFunc’
> undeclared (first use in this function)
> path/Parser.vala.c:169: error: expected ‘;’ before ‘_tmp2_’
> path/Parser.vala.c:170: error: ‘GMarkupParserTextFunc’ undeclared
> (first use in this function)
> path/Parser.vala.c:170: error: expected ‘;’ before ‘_tmp3_’
> path/Parser.vala.c:171: error: ‘GMarkupParserErrorFunc’ undeclared
> (first use in this function)
> path/Parser.vala.c:171: error: expected ‘;’ before ‘_tmp4_’
> path/Parser.vala.c:174: error: ‘_tmp1_’ undeclared (first use in this
> function)
> path/Parser.vala.c:174: error: ‘GMarkupParser’ has no member named
> ‘start_element_target’
> path/Parser.vala.c:175: error: ‘_tmp2_’ undeclared (first use in this
> function)
> path/Parser.vala.c:175: error: ‘GMarkupParser’ has no member named
> ‘end_element_target’
> path/Parser.vala.c:176: error: ‘_tmp3_’ undeclared (first use in this
> function)
> path/Parser.vala.c:176: error: ‘GMarkupParser’ has no member named
> ‘text_target’
> path/Parser.vala.c:177: error: ‘_tmp4_’ undeclared (first use in this
> function)
> path/Parser.vala.c:177: error: ‘GMarkupParser’ has no member named
> ‘error_target’
> error: cc exited with status 256
> Compilation failed: 1 error(s), 0 warning(s)
>
>
> Source code is attached...
> ___
> Vala-list mailing list
> Vala-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/vala-list
--- /usr/share/vala/vapi/glib-2.0.vapi 2009-06-03 03:15:17.0 -0400
+++ glib-2.0.vapi 2009-06-07 13:36:20.0 -0400
@@ -2706,10 +2706,15 @@
public delegate void MarkupParserErrorFunc (MarkupParseContext context, Error error);
public struct MarkupParser {
+ [CCode (delegate_target = false)]
public MarkupParserStartElementFunc start_element;
+ [CCode (delegate_target = false)]
public MarkupParserEndElementFunc end_element;
+ [CCode (delegate_target = false)]
public MarkupParserTextFunc text;
+ [CCode (delegate_target = false)]
public MarkupParserPassthroughFunc passthrough;
+ [CCode (delegate_target = false)]
public MarkupParserErrorFunc error;
}
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Problems with virtual extern methods.
On Mon, 2009-06-01 at 18:38 +0200, Jiří Zárevúcky wrote: > Dne 1. červen 2009 11:23 Yu Feng napsal(a): > > If the interface definition is written in VALA to take the advantages of > > Vala > > You lost me at this line. Is VALA something else then Vala? My bad grammars. VALA = vala = Vala. In that line I mean write the interface definitions in vala has advantages. Because vala syntax is shorter, and the header file and vapi files can (each) be integrated as a single whole file. Please feel free to ask clarifies. Best, Yu ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Problems with virtual extern methods.
On Mon, 2009-06-01 at 12:15 +0200, Jürg Billeter wrote: > On Mon, 2009-06-01 at 05:23 -0400, Yu Feng wrote: > > Think about implementing the GtkBuildable interface(the interface > > itself) with VALA. > > > > If the interface definition is written in VALA to take the advantages of > > Vala, several of the accessor functions have to be supplied in C because > > they selectively chain down to derived implementations based on whether > > the instance is a GtkBuildable or not. Manually looking up the vtable is > > too much for VALA. > > Can you point me to the code where GtkBuildable functions accept > instances not implementing GtkBuildable? From a quick glance at the > code, all the virtual method wrappers appear to contain > Well, I think I misread the code. My bad. Thank you for pointing this out. However, I skipped the assertions into the next line immediately following the assertion, because that is the line of my interest: if (iface->set_name) (* iface->set_name) (buildable, name); else g_object_set_data_full (G_OBJECT (buildable), "gtk-builder-name", g_strdup (name), g_free); This one can be rewritten with default interface implementations, with an interface base_init function? But more interestingly, I found the very early implementation of GtkBuildable at http://bugzilla.gnome.org/attachment.cgi?id=66080&action=edit + if (iface->set_name) +(* iface->set_name) (buildable, name); + + g_object_set_data_full (G_OBJECT (buildable), + "gtk-buildable-name", + g_strdup (name), + g_free) (notice the else is not there) I am not saying this code is good. But it is interesting, there is a default behavior done by the accessor. no matter the interface is implemented or not this behavior is performed -- and it's opaque to the derived classes. This is the usefulness For example(again might be a bad example), if the object does not even carry the interface, I can use a set_data for the storage instead of failing with an assertion. Because it sounds multi-inheritance and reverts the chaining order, I don't see it natively fit into VALA. The minimal cost of doing this I can imagine will be to literally define extern virtual members as linking against at least the accessor functions. By clarifying this C-linking issue, we won't risk ruining the language or loss anything; will we? - Yu Yu > g_return_if_fail (GTK_IS_BUILDABLE (buildable)); > > Jürg > ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Problems with virtual extern methods.
Hi Jiri, Why doesn't it make sense? extern is just saying the code is written somewhere else with another language. I guess you were thinking of extern in C++ or something? Think about implementing the GtkBuildable interface(the interface itself) with VALA. If the interface definition is written in VALA to take the advantages of Vala, several of the accessor functions have to be supplied in C because they selectively chain down to derived implementations based on whether the instance is a GtkBuildable or not. Manually looking up the vtable is too much for VALA. If the entire interface is written in C, the extra dangling C header won't blend well into the single header scheme of VALA for the shipped library. On the other hand isn't it too bad if VALA can't even reproduce GtkBuildable under is schema at all? It is really not a very weird interface if you read its source code. Yu On Mon, 2009-06-01 at 11:07 +0200, Jiří Zárevúcky wrote: > I don't really think virtual and extern should be possible to combine. > It doesn't make much sense IMHO. ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] file.copy problem
I guess it is a problem of GIO on Windows.
You can catch the error with
try {
...
} catch(IOError.EXISTS e) {
// trash the old file and copy again.
}
- Yu
On Mon, 2009-06-01 at 10:12 +0200, Joss 4 wrote:
> oops, sorry , I forgot part of the error line...
>
> Hi,
>
> I have got this problem on file.copy function using valide 4.0 on windows.
>
> this is the code :
> . . . .
> test.copy (destBkup, FileCopyFlags.OVERWRITE, null, null); // create
> backup
> . . . .
>
> When I launch the program I got this warning :
>
> Progetti_VALA/PetBeGone/main.vala.c: line 622: uncaught error: Error
> opening file. 'F:/Progetti_VALA\packages\TESTLIST_BAK': File exists
>
> this error stop the execution. I mean the lines below the test.copy are
> not executed.
>
> I think this shouldn't be because I set FileCopyFlags.OVERWRITE. Am I
> wrong ?
>
> ___
> Vala-list mailing list
> Vala-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/vala-list
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] using liststore objects
On Fri, 2009-05-29 at 09:49 +0200, Joss 4 wrote:
> Hi Yu,
>
I believe you forgot to cc the message to me. :)
> Thanks again,
> With your post I began to understand something abou the name convention
> and style settings. Now I try to do some test.
> In order to set GTK properties do you think it always be this way for
> ever? I was asking why one can't set properties directly like code :
> widget.backcolor = clRed;
> widget.Font = new Font( "Arial", 8, style.regular);
>
> It is so simply and natural. Is there some unknown thing under X11 or
> whatever else we don't know ? .
Those style-properties aren't properties. Properties are associated with
object instances, whereas style-properties, when they are invented, are
targeting at classes of widgets. The GTK model is different from our
intuition here. That's why they are so awkward to use. I've never found
any easier way of using them.
> I remember when I learned about objects
> and properties
> and so what is the definition of GTK+ ?.
For regular properties, you can definitely do so. For example,
Gtk.Label label = new Gtk.Label("hola");
label.text = "hello";
> Scuse me , I am a little critic , but I spent 12 days to fight whit GTK
> to make a little form with 2 TreeView-Listview and some buttons.
TreeView is the most difficult widget in GTK. Given the fact you are not
yet familiar with the GLib stuff at all, I would say you were choosing
the steepest cliff. Did you read the GTK tutorial? I would recommend you
translate several examples with Vala to make sure you are familiar
enough with the language and the toolkit first.
http://library.gnome.org/devel/gtk-tutorial/2.17/
> With
> this time with sharpdevelop on windows I realized a whole report
> designer with property editor and browser field.
There is one powerful tool. It is called Glade-3. Then you gonna take a
grab of GtkBuilder and the XML(GMarkup).
> That said, I like vala because I think it is a good bridge from
> windows to linux without any runtime level between. I agree with your
> sentence : "you might have to settle with this situation" , in order to
> vala, but I understend people at scribus that decided to convert all
> from GTK+ to QT.
Freedom is not free... It costs one hour oh five.
If you are prototyping for a company, I would sincerely suggest you
should also take a look at Mono(Sharp on Linux); it is also promising.
MonoDevlop is mono's IDE; not productive yet as I learned from the net.
but I do think they already have auto-completion: it is a must for a
product toward the professionals.
> Okay , I still have to solve :
>
> - ListStore Header column resize
Refer to http://markmail.org/message/xdemlbkhpls6v5u2
it is written in Gtkmm though.
> - ListStore grid visible , thikness and color.
> - ListStore invisible columns
> - ListStore background image or background color
> - Widget border width and color
The trilogy of GtkTreeView GtkTreeModel and GtkTreeStore definitely has
confused you. Refer to
http://en.wikipedia.org/wiki/Model-view-controller
and
http://blog.riff.org/2006_10_15_grokking_phpgtk_gtktreeview_and_friends
gtk-app-list will have the people that can answer you these questions
about TreeView. To me, TreeView is VERY frustrating to work with in
either C or VALA, because of the very complicated nature of visualizing
a multi-column tree.
Looks like you are trying to make a highly decorated GTK app. Most of
the GTK apps I use have no background image, nor customized background
color, nor customized widget border width or color.
> ... and last but not least Code completion and list of available
> packages in valide.
Sorry but I am a vim. There is plenty of valide users here though.
>
> Can you suggest some specific code snippet of people that already did
> it.
>
I did write some simple tree view half a year ago but I did never go
into that deep. I don't know if any other people used TreeView with
VALA. Nautilus, Evolution, RhythmBox, Epiphany all have fancy treeviews.
They are all very well written in C; it shouldn't be difficult to
convert any of their code into vala.
Good luck!
Yu
> Thansk a lot.
>
>
>
>
>
> ___
> Vala-list mailing list
> Vala-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/vala-list
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] List problem in Valide
On Sat, 2009-05-30 at 22:22 +0200, Nicolas Joseph wrote:
> Hello,
>
> Your first problem is due to the '<' character, could you post an
> issue so that I will not forget:
> http://code.google.com/p/valide/issues/list
>
> libgee is now included in libvala-1.0.dll, you just add the vala-1.0 package.
A annotation for Joss
Now it sounds like we have a runtime for VALA. That's not the case.
vala-1.0 package is the vala compiler itself. vala is organized in such
a way that the core compiler is the library vala-1.0 and there is a
small wrapper executable valac on top of it.
You get libgee by linking with vala-1.0 because vala-1.0 has an embedded
libgee.
Best,
Yu
>
> 2009/5/30 Joss 4 :
> > @ Nicolas
> > I have problems with valide 4.0 version in windows env.
> >
> > My example is :
> >
> > using GLib;
> >
> > SList list = new SList ();
> > list.append ("one");
> > list.append ("two");
> > list.append ("three");
> > list.append ("four");
> >
> > now if I write the sort function with first letter in uppercase like
> > list.Sort the compiler doesn't warning any error, simply don't compile.
> > while if manually compile on command line this way, I get the error:
> >
> > main.vala:376.13-376.21: error: The name `Sort' does not exist in the
> > context of `GLib.SList'
> > list.Sort(strcmp);
> > ^
> > also I have problems with indexeder and find functions; If I write code like
> > this:
> >
> > string key = "three";
> > int ix = list.index(key);// In this line I get -1
> >
> > string foundkey = (string)list.find(key);// in this line i get null
> >
> > stdout.printf ("%s %d \n", foundkey, ix );
> > Where I am wrong ? Is there some error in my settings ?.
> >
> > @Nicolas Joseph ,
> > Could you also post a windows version of libgee-1.0.dll ??
> >
> >
> > ___
> > Vala-list mailing list
> > Vala-list@gnome.org
> > http://mail.gnome.org/mailman/listinfo/vala-list
> >
>
>
>
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Problems with virtual extern methods.
Dear List, I don't think virtual extern method is precisely defined in vala; the code produced by 0.7.2 is kinda of weird with an undefined static _real function. I propose for virtual extern method we do the follows: (1) assume both the accessor function and the _real function as extern symbols in the produced ccode; (2) the vtable is initialized in the same way as non-extern methods; the external _real cfunction is used to fill in the table; (3) the accessor function is declared in the public header by valac, as done for non-virtual members. I made a patch for this proposal under http://bugzilla.gnome.org/show_bug.cgi?id=584400 I am wondering if anyone wants to review it. Regards, Yu ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Ownership and strings
On Mon, 2009-06-01 at 04:04 +0200, Jiří Zárevúcky wrote:
> Dne 1. červen 2009 0:51 Yu Feng napsal(a):
> > What aspects about string handling do you want to know though?
> >
> > For the memory management maybe you want to search for the keyword
> > `Compact' in the tutorial about the references and ownership aspect of
> > string and other compact types in vala.
> >
> > http://live.gnome.org/Vala/Tutorial
> >
>
> Oh... for some reason I forgot to read that tutorial :-/ Final exams
> are obviously frying my brain...
>
> > I wrote that paragraph and would like to learn some feedback from you if
> > it is clear or ambiguous.
> >
>
> Quite clear, I understand the concept now. Thanks. :)
Thanks too!
>
> Although there is a case I'm not really sure about...
>
> class StringTest
> {
> public string some_string
> {
> get {
> var s = "fdfdf";
You can't create a initially unowned memory object.
The string constants, like "fdfdf" are statically owned. In other words,
the owner is the program's global heap. As long as the program is in the
memory, they are not destroyed. The semantic analyzer deducts that `var
s' should be a strong reference. Now because string is a compact class,
"fdfdf" is copied with g_strcpy(as specified in glib-2.0.vapi:803) to
associate `var s' with a new object.
You are right member properties, aka member fields with getter and
setters are special. Although they are not declared as weak/unowned, the
reference you get by the implicit invocation of the getter is always
unowned. The reason for this default behavior is to be consistent with
older version and GTK conventions. This(important fact) is not mentioned
anywhere other than the mail-list or the bugzilla, as far as I know.
Now you want to return this strong reference within a method that
returns a weak reference. Because after the function has returned, the
local variable `var s' is out of scope, and the object `var s' pointing
to is destroyed. However the returned weak reference of this destroyed
object is passed out. The innocent caller of this method now receives an
invalid weak reference pointing to an ruined memory area. This is an
undefined behavior; vala compiler avoids this wrong thing at the
compilation stage.
For your example, these three alternatives should work:
class StringTest
{
public string some_string
{
get {
/* A weak reference to a statically owned string */
return "fdfdf";
}
}
}
or
class StringTest
{
private string _some_string;
public string some_string
{
get {
/* plenty of them in vala*/
if(_some_string == null) {
_some_string = "dfdfd";
}
return _some_string;
}
}
}
or, a worst one:
class StringTest
{
public string # some_string
{
get {
/* Declare the method as returning an owned(strong) reference to a string */
var s = "fdfdf";
return s
}
}
}
I hope this explanation clarifies it all.
- Yu
> return s;
> }
> }
> }
>
>
> Now when I try to compile it, it gives me an error.
> "Local variable with strong reference used as return value and method
> return type has not been declared to transfer ownership".
>
> Now it's fairly obvious this is some special property behavior (normal
> method works fine), but I don't really understand why does it differ.
>
> On the other hand, it works when I change the variable to "unowned
> string". Then it compiles, but the string isn't owned by anything. Is
> it even allocated? If so, I guess the ownership is transferred to the
> first strong variable it is assigned to, right? Then, what happens
> when the variable goes out of scope without any strong assignment?
>
> I would really appreciate a paragraph about how initially unowned
> non-reference-counted objects are handled. :) Thanks in advance.
BTW: there is no such initially unowned object in native VALA, no matter
it is compact or reference counted. I bet you heard about the name from
GObject/GTK. Refer to gobject-2.0.vapi:222. If an GLib object is an
instance of InitiallyUnowned, vala will sink it for you, then pass the
ownership to the first reference variable.
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Compact classes in HashTable
On Wed, 2009-05-27 at 02:13 +0200, Michael 'Mickey' Lauer wrote: > I just found the reason why my programs are leaking memory like there's no > tomorrow... > > I have been stuffing compact classes in HashTables, which -- as I know now -- > do > not destroy the things they contain. Fun. > > I read about HashTable<>.full, but this won't help in my case, since I can't > seem to access the respective free function from Vala. > One workaround is to declare the corresponding free function generated by vala as an external static member of the compact class. > What can i do? Is Gee handling this better? > Yes. - Yu > Thanks, > > :M: > > ___ > Vala-list mailing list > Vala-list@gnome.org > http://mail.gnome.org/mailman/listinfo/vala-list ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] How to free delegate callbacks
On Mon, 2009-05-25 at 00:53 +0300, Adi Roiban wrote:
> Hi,
>
> I have this big problem with memory consumption.
>
> Gtk.Entry entry = new Gtk.Entry();
> for (float i=0; i < 100; i++) {
> entry.focus_in_event.connect( () => {});
> }
> Gtk.main();
>
>
> When I run the above code it uses about 40MB. Without the callback its
> only 700KB.
The only way I know to disconnect a signal handler is to explicitly
assign it a name first. eg, declare the handler as a member function,
then feed the function name to signal.disconnect.
Yu
>
> Do you know what can I do to reduce the memory consumption?
>
> Many thanks!
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Nested anonymous struct
Dear list,
Currently the vala compiler (0.7.2) doesn't compiler the following code:
public struct Large {
public struct {
int small;
int verysmall;
} foo;
}
neither does it accept the code in a vapi file.
One year ago Sam expressed the need in a mail[1].
The feature will also be convenient for writing vapi bindings of C
libraries (eg, libyaml) that makes extensive use of anonymous struct.
There doesn't seem to be a feature request on bugzilla yet.
I am curious if there is any intention to implement the anonymous struct
in the future, and if a patch is welcomed, which part of the compiler is
relevant, and what will be the technical obstacles.
Regards,
Yu
[1] http://www.mail-archive.com/vala-list@gnome.org/msg00818.html
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] libyaml binding?
Dear list, I am wondering if anyone has been working on the vala bindings for libyaml? - Yu ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Gtk.CheckMenuItem activate signal is useless (maybe)
On Sat, 2009-05-09 at 14:40 +0400, Харин Роман wrote:
> so, its litttle code example:
>
> class MyApp : Window {
>
> private Image main_img;
>
> public MyApp() {
> ...
> item_viewbg = new CheckMenuItem.with_label("Показывать фон");
> item_viewbg.active = true;
> item_viewbg.activate.connect(onMenuBackImage);
>...
> }
>
> void onMenuBackImage(MenuItem menu) {
> main_img.visible = menu.active;
> ^^
main_img.visible = (menu as CheckMenuItem).active;
Did you try the old signal connection syntax (using +=)?
- Yu
> }
> ...
> }
>
> MenuItem has no "active" property, but CheckMenuItem has one.
> And i would like to write:
>
> void onMenuBackImage(CheckMenuItem menu) {
> main_img.visible = menu.active;
> }
>
> but: Cannot convert from `MainWindow.onMenuBackImage' to
> `Gtk.MenuItem.activate'
>
> ---
> Харин Роман,
> jabber:// har...@jabber.ru
>
> ___
> Vala-list mailing list
> Vala-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/vala-list
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] valac 0.7.1 bug: Delegates are typedef'd before enums in generated C code.
Hi Jim,
Refer to http://bugzilla.gnome.org/show_bug.cgi?id=578191
Yu
On Mon, 2009-04-27 at 15:14 -0700, Jim Nelson wrote:
> I've entered a bug in the database
> (http://bugzilla.gnome.org/show_bug.cgi?id=580513) but am posting here
> because this problem blocks me from transitioning to Vala 0.7, which I
> would like to do.
>
> In my code, a delegate returns an enum. In valac's generated C code,
> the delegate is typedef'd before the enum, which the compiler
> obviously doesn't like.
>
> There's a twist to all of this. It will only compile under 0.6.1 if
> the enum is in a different file as the delegate declaration (because
> the enum is declared in a separate, guarded .h file). Even separating
> the two, this code will not compile in 0.7.1.
>
> If anyone can suggest a workaround until this is fixed, it would be
> greatly appreciated.
>
> Here's the vala code:
>
> enum TestEnum {
> foo,
> bar,
> xyzzy,
> }
>
> delegate void tdelegate(TestEnum te);
>
> void main() {
> }
>
> which 0.7.1 transforms into this C code:
>
> #include
> #include
>
>
> #define TYPE_TEST_ENUM (test_enum_get_type ())
> // *** Next line generates error: "error: expected ‘)’ before ‘te’"
> typedef void (*tdelegate) (TestEnum te, void* user_data);
>
> typedef enum {
> TEST_ENUM_foo,
> TEST_ENUM_bar,
> TEST_ENUM_xyzzy
> } TestEnum;
>
>
>
> GType test_enum_get_type (void);
> void _main (void);
>
>
>
>
> GType test_enum_get_type (void) {
> static GType test_enum_type_id = 0;
> if (G_UNLIKELY (test_enum_type_id == 0)) {
> static const GEnumValue values[] = {{TEST_ENUM_foo,
> "TEST_ENUM_foo", "foo"}, {TEST_ENUM_bar, "TEST_ENUM_bar", "bar"},
> {TEST_ENUM_xyzzy, "TEST_ENUM_xyzzy", "xyzzy"}, {0, NULL, NULL}};
> test_enum_type_id = g_enum_register_static ("TestEnum",
> values);
> }
> return test_enum_type_id;
> }
>
>
> void _main (void) {
> }
>
>
> int main (int argc, char ** argv) {
> g_type_init ();
> _main ();
> return 0;
> }
>
>
>
> Thanks,
>
> -- Jim Nelson
> Yorba
>
> ___
> Vala-list mailing list
> Vala-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/vala-list
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] M4 Macros for vala+valadoc when automake integration is unavailable
On Sun, 2009-04-26 at 10:09 +0200, Ali Sabil wrote: > Hi, > > That looks great. But you probably want to check how I autotooled > libcore[1]. The implementation I have is based on the vala-support[2] > script by Mathias Hasselmann, and doesn't have the limitation you > have. Good! I am looking to move to your solution. Does the script work with maintainer-mode though? Regards, Yu > > [1] bzr branch lp:libcore > [2] http://taschenorakel.de/mathias/2007/08/27/automake-support-vala/ > > -- > Ali > > On Sun, Apr 26, 2009 at 5:34 AM, Yu Feng wrote: > > Dear List, > > > > I would like to share these m4 macros for vala/valadoc with you. They > > helped me to keep the 'Makefile.am's neat and clean. The approach is > > copied from intltool, by substituting rules with @@ substitutions in > > Makefile.am. > > > > vala.m4 provides helpers for invoking valac. This file is modified from > > Mathias's original vala.m4. > > > > valadoc.m4 provides helpers for invoking valadoc and adds a > > --enable-valadoc parameter to the configure script. > > > > Drop them into a toplevel sub-directory in your project > > (namely ./autotools) > > > > Add three lines to configure.ac > > AC_CONFIG_MACRO_DIR([autotools]) > > AC_CONFIG_AUX_DIR([autotools]) > > AC_SUBST(ACLOCAL_AMFLAGS, "-I autotools") > > # also modify aclocal in autogen.sh if applicable > > > > Then > > VALA_PROG_VALAC(0.6.0) > > VALA_PROG_VALADOC > > > > More information are in the m4 files. An example for using both together > > is given in valadoc.m4. > > > > The limitation is that only one 'ultimate' target(ie, one .la file) per > > source code directory can be built with the rules. > > > > Regards, > > > > Yu > > > > ___ > > Vala-list mailing list > > Vala-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/vala-list > > > > ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Vala support for automake
On Sun, 2009-04-26 at 09:50 +0200, Ralf Wildenhues wrote: > * Yu Feng wrote on Sun, Apr 26, 2009 at 03:51:50AM CEST: > > Is it possible to also add valadoc support in automake together with > > vala support? > > What does valadoc do, where is it documented, what kind of rules do you > use instead of automake support, what pitfalls are there? > Valadoc is a documentation tool for vala. The role is similar to gtk-doc/javadoc. It accepts almost the same compiler flags as vala does, but produces documentation into the given subdirectory instead of the ccode as an output. For more details please kindly refer to http://live.gnome.org/Valadoc and valadoc --help I've posted the rules I am using in the previous mail http://www.mail-archive.com/vala-list@gnome.org/msg02596.html http://www.mail-archive.com/vala-list@gnome.org/msg02596/valadoc.m4 It is not the very best one though. Regards, Yu > Thanks, > Ralf ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] M4 Macros for vala+valadoc when automake integration is unavailable
Dear List, I would like to share these m4 macros for vala/valadoc with you. They helped me to keep the 'Makefile.am's neat and clean. The approach is copied from intltool, by substituting rules with @@ substitutions in Makefile.am. vala.m4 provides helpers for invoking valac. This file is modified from Mathias's original vala.m4. valadoc.m4 provides helpers for invoking valadoc and adds a --enable-valadoc parameter to the configure script. Drop them into a toplevel sub-directory in your project (namely ./autotools) Add three lines to configure.ac AC_CONFIG_MACRO_DIR([autotools]) AC_CONFIG_AUX_DIR([autotools]) AC_SUBST(ACLOCAL_AMFLAGS, "-I autotools") # also modify aclocal in autogen.sh if applicable Then VALA_PROG_VALAC(0.6.0) VALA_PROG_VALADOC More information are in the m4 files. An example for using both together is given in valadoc.m4. The limitation is that only one 'ultimate' target(ie, one .la file) per source code directory can be built with the rules. Regards, Yu vala.m4 Description: application/m4 valadoc.m4 Description: application/m4 ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Vala support for automake
Is it possible to also add valadoc support in automake together with vala support? Yu On Thu, 2009-04-16 at 21:19 +0200, Jürg Billeter wrote: > On Thu, 2009-04-16 at 21:09 +0200, Ralf Wildenhues wrote: > > * Jürg Billeter wrote on Thu, Apr 16, 2009 at 09:02:30PM CEST: > > > On Thu, 2009-04-16 at 20:49 +0200, Ralf Wildenhues wrote: > > > > bin_PROGRAMS = foo > > > > foo_SOURCES = foo1.vala foo2.vala > > > > foo_LDADD = libbar.a > > > > noinst_LIBRARIES = libbar.a > > > > libbar_a_SOURCES = bar1.vala bar2.vala > > > > > > > > How would valac cope with the necessarily separate invocations for > > > > foo*.vala and bar*.vala? And what happens if you try to put vala > > > > code into shared libraries, and use them from other vala code? > > > > > > In this case you instruct valac to generate a bar.vapi and a bar.h file > > > and use those files in the program by specifying > > > > > > libbar_a_VALAFLAGS = --library bar -H bar.h > > > foo_VALAFLAGS = bar.vapi > > > > > > A .vapi file contains declarations for Vala libraries, similar to a .h > > > file for C libraries. > > > > How is the semantic relationship between the .vapi name and its library? > > s/^lib//; s/\.a$//; s/$/.vapi/? > > > > What about shared libraries, do they have .vapi's, too? > > Yes, shared libraries have .vapi files, too. They are installed > into /usr/share/vala/vapi/ by default. > > The .so name and the .vapi name do not need to match in any way, the > convention for shared libraries is to use the pkg-config name, if > applicable. When writing the .vapi file, the compiler just uses the > argument of the --library option and appends .vapi. > > > What if I want to build one big shared (or static) library from a set of > > convenience archives (uninstalled .a libraries with PIC code)? Do you > > have means to generate a .vapi for the big library from the .vapi's of > > the several small ones (plus maybe a couple of loose objects, too)? > > That's where it starts getting a bit tricky. While generating the > big .vapi file is as simple as concatenating the .vapi files of the > convenience libraries, I don't know how we can avoid a manual `cat' rule > without making it a lot more complex. > > Thanks, > Jürg > > ___ > Vala-list mailing list > Vala-list@gnome.org > http://mail.gnome.org/mailman/listinfo/vala-list ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Coroutine examples?
Dear list, Are there any example/productive code written in VALA for co-routines? I am getting interested into it but have very little idea about how to take it in to real world usage. Regards, Yu ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Starting with Vala, problems with strings
On Sun, 2009-04-19 at 23:33 +0200, Frederik wrote: > Diego Jacobi wrote: > > Why isnt string = GString ? > > Also i am courius why is it called StringBuilder? It sound like "not a > > GString". > > In order to resemble C# and Java which both have [s|S]tring and > StringBuilder. > > string = char *(immutable) > StringBuilder = GString(mutable) > ...Although there are a few special functions on string that modify the string in-place. Also GString is not intended for text manipulation. It doesn't know more about utf8 other than append_unichar. > > Regards, > > Frederik > ___ > Vala-list mailing list > Vala-list@gnome.org > http://mail.gnome.org/mailman/listinfo/vala-list ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Starting with Vala, problems with strings
Hi Diego,
private static int my_string_handler(string str)/*no '*'*/ {
}
If possible use unichar, string.next_char, string.get_char, to
manipulate string is better than directly access the char by its
location because all strings are utf8 encoded.
StringBuilder sb = new StringBuilder("");
for(weak string s = str; s.get_char()!=0; s = s.next_char()) {
unichar c = s.get_char();
if(c != '+') sb.append_unichar(c);
else {
break;
}
}
Yu
On Sun, 2009-04-19 at 20:39 +0200, Diego Jacobi wrote:
> Hi.
> This may be a too much newbie question, but:
> How do you access a character in a string?
>
> private static int my_string_handler(string *str)
> {
> string s;
> for (x = 0 ; x < str->len() ; x++)
> {
> if (str[x]=='+')
> {
> s = str->substring(0,x);
> stdout.printf("plus finded at = %d, left string ist %s\n", x,
> s);
> return 0;
> }
> }
> return -1;
> }
>
> This prints an error saying that str is not an array.
> I cant find anything on the docs an example on how to manipulate
> strings char by char.
>
> Cheers.
> Diego
> ___
> Vala-list mailing list
> Vala-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/vala-list
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [ANNOUNCE] Vala 0.7.0 - Compiler for the GObject type system
On Tue, 2009-04-07 at 17:53 +0200, Jürg Billeter wrote: > On Tue, 2009-04-07 at 01:50 -0400, Yu Feng wrote: > > Vala 0.7.0 is affected by Bug 578191 which may interfere with many > > programs written in VALA. > > Would you please take a look at the patch before the next major/minor > > release? The master branch is self-compilable with the patch applied. > > This should already be fixed in master for two days as commented on the > bug. Indeed. And it was a better fix! > Let me know if there are still issues. > > Jürg > ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] empty List is null - bug or feature?
Filed under Bug #578198 with a patch.
On Tue, 2009-04-07 at 00:27 +0200, Jan Spurny wrote:
> Hi Yu,
>
> thanks for reply - that's exactly what I did in order to get it working now.
> I know empty list is null in glib, but I'm still a bit troubled by the fact
> that (as some Java programmer may think):
>
> 1) I've created new object by "var list = new List;"
> 2) I can call methods on this new object: "var len = list.length();" - which
> work as anyone would expect
> 3) but when I pass it to some other function it fails (CRITICAL-y!)
>
> Let me explain this - I've "discovered" vala few weeks ago when I was looking
> something up in gobject documentation and I thought it can be a great tool
> for our company's libraries (which are then used from Java and maybe Python)
> as it can dramatically (I still hope..) increase development (and
> maintenance, I hope..) of some components - the fact is that we have many
> Java programmers but only few C programmers - so it could allow these Java
> people to help me in developing these libraries..
> But there are some things, like this empty null glist, a bit complicated
> (from java/c# programmer's point of view) object construction and "memory
> management" which requires much deeper knowledge of C and GLib/GType/GObject
> - don't get me wrong - I do not say that vala is bad language - even if no
> java programmer will be able to help me soon, it's still a great help for me
> and my colleagues
>
> BTW: you haven't seen my c programs :) - but I'm definitelly not the best
> programmer in the world, so can you explain to me if the fact that you havent
> seen that is because it's not a good programming practice (why?), or it's
> just that you've never seen it :) ?
>
> Jan Spurny
>
> On Mon, 06 Apr 2009 23:05:16 +0200 (CEST)
> Yu Feng wrote:
>
> > Try List? list
> >
> > In Glib an empty list is by definition null.
> >
> > BTW: I have never seen any of c program passing a GList around.
> >
> > -Yu
> > On Mon, 2009-04-06 at 19:05 +0200, Jan Spurny wrote:
> > > Hi,
> > >
> > > I'd like to know if this is considered to be a bug or feature:
> > > when I pass an empty list to some function/method, it generates critical
> > > error - but to any Java/C#/C++/Whatever programmer this would be very
> > > confusing..
> > > I know the reason for this as I've been working with glib for some time,
> > > but those without any previous glib experience may be severely confused..
> > >
> > > In case of this being classified as a bug I humbly suggest removing
> > > "g_return_if_fail (list != NULL);" in generated code as NULL is valid
> > > (empty) GLib.List
> > >
> > > here is an example of what I mean:
> > > ---
> > > using GLib;
> > > void print_list(List list) {
> > > foreach (int x in list)
> > > stdout.printf("%d\n", x);
> > > }
> > > int main (string[] args) {
> > > var xy = new List();
> > > print_list(xy);
> > > return 0;
> > > }
> > >
> > > valac -o list list.vala
> > > ./list
> > >
> > > ** (process:6750): CRITICAL **: print_list: assertion `list != NULL'
> > > failed
> > >
> > >
> > > Thanks in advance for any reply.
> > >
> > > Jan Spurny
> > > ___
> > > Vala-list mailing list
> > > Vala-list@gnome.org
> > > http://mail.gnome.org/mailman/listinfo/vala-list
> >
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [ANNOUNCE] Vala 0.7.0 - Compiler for the GObject type system
Hi Jurg, Vala 0.7.0 is affected by Bug 578191 which may interfere with many programs written in VALA. Would you please take a look at the patch before the next major/minor release? The master branch is self-compilable with the patch applied. Regards, Yu 05 at 17:54 +0200, Jürg Billeter wrote: > We are pleased to announce version 0.7.0 of Vala, a compiler for the > GObject type system. > > Vala 0.7.0 is now available for download at: >http://download.gnome.org/sources/vala/0.7/ > > Changes since 0.6.0 > * Do not generate header files unless requested by the -H commandline >option. This requires changes in the build system of Vala projects. > * Support conditional compilation. > > Vala is a new programming language that aims to bring modern programming > language features to GNOME developers without imposing any additional > runtime requirements and without using a different ABI compared to > applications and libraries written in C. > > valac, the Vala compiler, is a self-hosting compiler that translates > Vala source code into C source and header files. It uses the GObject > type system to create classes and interfaces declared in the Vala source > code. > > The syntax of Vala is similar to C#, modified to better fit the GObject > type system. Vala supports modern language features as the following: > > * Interfaces > * Properties > * Signals > * Foreach > * Lambda expressions > * Type inference for local variables > * Generics > * Non-null types > * Assisted memory management > * Exception handling > > Vala is designed to allow access to existing C libraries, especially > GObject-based libraries, without the need for runtime bindings. All that > is needed to use a library with Vala is an API file, containing the class > and method declarations in Vala syntax. Vala currently comes with > bindings for GLib and GTK+. It's planned to provide generated bindings for > the full GNOME Platform at a later stage. > > Using classes and methods written in Vala from an application written in > C is not difficult. The Vala library only has to install the generated > header files and C applications may then access the GObject-based API of > the Vala library as usual. It should also be easily possible to write a > bindings generator for access to Vala libraries from applications > written in e.g. C# as the Vala parser is written as a library, so that > all compile-time information is available when generating a binding. > > More information about Vala is available at > > http://live.gnome.org/Vala > > > The Vala Team > > Jürg Billeter and Raffaele Sandrini > > > ___ > Vala-list mailing list > Vala-list@gnome.org > http://mail.gnome.org/mailman/listinfo/vala-list ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] private extern class methods.
The generated (problematic) ccode, declares a static prototype for an
extern symbol, which I believe is the cause of the problem. After
replacing the declaration with extern keyword, the library is no longer
a SE trouble maker.
The library was built with a DISABLE_STATIC libtool with
-Wl,--as-needed. I believe -fPIC are always automatically added when
real shared-libraries are built on applicable platforms.
I am totally confused with what was happening inside the linker world.
I had same issues when I forgot declaring the prototypes of extern
symbols in the source files for building shared libraries though.
Yu
On Mon, 2009-04-06 at 19:38 +0200, pancake wrote:
> The same bug should appear with Solaris and the Sun Studio (aka Forte
> compiler)
>
> you should build everything with -fPIC, can you provide more information
> about your
> build ? console output?
>
> SElinux doesnt allows symbol relocation because it can be dangerous (can
> be used
> for in-memory patching using the linux loader) which is permitted, on
> normal linux,
> but forbidden in selinux for obvious reasons.
>
> This also happens when you link a blob compiled without -fPIC against a
> static library
> that isnot compiled with relocatable code (no -fPIC) the reason is taht
> the non-relocatable
> code is compiled to live at a certain offset, and pic code generates
> some stubs to know
> where is and how to reach all the data from their position (like
> oldschool viruses did),
> you cannot mix pic-nonpic code in an application. well.. default linux
> allows you to do this,
> but its a bit ugly workaround ;)
>
> Yu Feng wrote:
> > Dear list,
> >
> > I encountered a very hidden problem with private extern class methods,
> > which I would like to share with you.
> >
> > The scenario is like this. It compiles, links. everything seems fine
> > until the library is installed: the produced .so file will have a wrong
> > reloc symbol which doesn't work with SELinux!):
> >
> > A member function of a class is externally written in C.
> >
> > # Class.vala
> > public class Class {
> > private extern static void func();
> > }
> > # Class-ccode.c
> > void class_func() {
> > // Do stuff
> > }
> >
> > The generated ccode:
> > # Class.c
> > ...
> > ...
> > static void func();
> > ...
> > ...
> >
> > This seems to be a bug in valac.
> > The private extern method actually should be declared without the static
> > keyword but with an extern instead.
> >
> > Regards,
> >
> > Yu
> >
> > ___
> > Vala-list mailing list
> > Vala-list@gnome.org
> > http://mail.gnome.org/mailman/listinfo/vala-list
> >
> >
> ___
> Vala-list mailing list
> Vala-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/vala-list
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] private extern class methods.
Dear list,
I encountered a very hidden problem with private extern class methods,
which I would like to share with you.
The scenario is like this. It compiles, links. everything seems fine
until the library is installed: the produced .so file will have a wrong
reloc symbol which doesn't work with SELinux!):
A member function of a class is externally written in C.
# Class.vala
public class Class {
private extern static void func();
}
# Class-ccode.c
void class_func() {
// Do stuff
}
The generated ccode:
# Class.c
...
...
static void func();
...
...
This seems to be a bug in valac.
The private extern method actually should be declared without the static
keyword but with an extern instead.
Regards,
Yu
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [ANNOUNCE] Vala 0.7.0 - Compiler for the GObject type system
Hi Jürg, On Sun, 2009-04-05 at 17:54 +0200, Jürg Billeter wrote: > We are pleased to announce version 0.7.0 of Vala, a compiler for the > GObject type system. > > Vala 0.7.0 is now available for download at: >http://download.gnome.org/sources/vala/0.7/ > > Changes since 0.6.0 > * Do not generate header files unless requested by the -H commandline >option. This requires changes in the build system of Vala projects. Are there any references on how to port a project to the new header schema? > * Support conditional compilation. > and the usage of the conditional compilation? > Vala is a new programming language that aims to bring modern programming > language features to GNOME developers without imposing any additional > runtime requirements and without using a different ABI compared to > applications and libraries written in C. > > valac, the Vala compiler, is a self-hosting compiler that translates > Vala source code into C source and header files. It uses the GObject > type system to create classes and interfaces declared in the Vala source > code. > > The syntax of Vala is similar to C#, modified to better fit the GObject > type system. Vala supports modern language features as the following: > > * Interfaces > * Properties > * Signals > * Foreach > * Lambda expressions > * Type inference for local variables > * Generics > * Non-null types > * Assisted memory management > * Exception handling > > Vala is designed to allow access to existing C libraries, especially > GObject-based libraries, without the need for runtime bindings. All that > is needed to use a library with Vala is an API file, containing the class > and method declarations in Vala syntax. Vala currently comes with > bindings for GLib and GTK+. It's planned to provide generated bindings for > the full GNOME Platform at a later stage. > > Using classes and methods written in Vala from an application written in > C is not difficult. The Vala library only has to install the generated > header files and C applications may then access the GObject-based API of > the Vala library as usual. It should also be easily possible to write a > bindings generator for access to Vala libraries from applications > written in e.g. C# as the Vala parser is written as a library, so that > all compile-time information is available when generating a binding. > > More information about Vala is available at > > http://live.gnome.org/Vala > > > The Vala Team > > Jürg Billeter and Raffaele Sandrini > > > ___ > Vala-list mailing list > Vala-list@gnome.org > http://mail.gnome.org/mailman/listinfo/vala-list ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Action signals
Hi,
I was working on a related patch
http://bugzilla.gnome.org/show_bug.cgi?id=571685
Although 'action' keyword is not included in the patch.
What's the difference between an action signal and other signals?
Yu
On Sun, 2009-04-05 at 20:15 +0200, gege2061 wrote:
> This doesn't work.
>
> I have tested with the action keyword, but I have a syntax error and
> the CCode attribute seems to not work.
>
> My code:
>
> public class Test
> {
> [CCode (action_signal = true)]
> public action void test_action ();
> }
>
>
> 2009/1/6 Yu Feng
> Based on my understanding of valac before the recent
> refactoring, it
> should be a few line patch around 'signal binding' related
> code;
> get a new CCode attribute such as 'action_signal = true' and
> change the
> type of the signal to ACTION if so.
>
>
> Yu
>
> On Mon, 2009-01-05 at 20:04 +0100, gege2061 wrote:
> > Hello,
> >
> > Have you fixed this problem:
> >
> http://mail.gnome.org/archives/vala-list/2008-April/msg00076.html ?
> >
> > --
> > Nicolas Joseph
> >
> > Responsable de la rubrique GTK+ de developpez.com /
> > In charge of the GTK+ section on developpez.com
> >
> > http://nicolasj.developpez.com
>
> > ___
> > Vala-list mailing list
> > Vala-list@gnome.org
> > http://mail.gnome.org/mailman/listinfo/vala-list
>
>
>
>
> --
> Nicolas Joseph
>
> Responsable des rubriques C et GTK+ de developpez.com /
> In charge of the C and GTK+ sections on developpez.com
>
> http://nicolasj.developpez.com
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Multidimensional arrays - help with using them.
On Fri, 2009-04-03 at 23:54 +0200, Leonti Bielski wrote:
> For me tt works only for accessing elements.
> For example:
>
> int[,] some_array = new [2,2];
>
> Makes 2x2 array of ints.
>
> int something = some_array[0,0];
> But I still cannot resize it :(
No you can't. array.resize only works for 1d array. It produces wrong
ccode for multidimension array.
I would suggest write your own resizable 2d array.
struct Array2D {
/*read-only*/
public int NX;
public int NY;
private int[] storage;
public Array2D(int NX, int NY);
public int get(int x, int y);
public set(int x, int y, int value);
public void resize(int NNX, int NNY);
}
Yu
>
> Leonti
>
> On Fri, Apr 3, 2009 at 11:46 PM, Yu Feng wrote:
> > I remember back in some versions
> >
> > array[1, 2] works
> >
> > Yu
> > On Fri, 2009-04-03 at 21:05 +0200, Leonti Bielski wrote:
> >> It's gotta be a way to do it :(
> >> Maybe by using lists or something similar?
> >>
> >> Leonti
> >>
> >> On Fri, Apr 3, 2009 at 8:01 PM, lariamat wrote:
> >> > Hello
> >> > I guess, it is a bug.
> >> > There are several issues with multidimensional arrays:
> >> > http://bugzilla.gnome.org/show_bug.cgi?id=548428
> >> > http://bugzilla.gnome.org/show_bug.cgi?id=548429
> >> > http://bugzilla.gnome.org/show_bug.cgi?id=576611
> >> > Also using arrays by reference is not working.
> >> > Regards,
> >> > lariamat
> >> >
> >> >
> >> > Am Freitag, den 03.04.2009, 18:48 +0200 schrieb Leonti Bielski:
> >> >> Hello!
> >> >> I need to use multidimensional array of ints, so this is what I do:
> >> >>
> >> >> int[][] some_array = {}; //declaring an array of int[]
> >> >> int[] some = {1,2,3}; // declaring array of ints
> >> >> some_array += some; // adding this array to 2D array - this works
> >> >>
> >> >> some_array[0] = some; // this doesn't work
> >> >> some_array[0] += 2; //this doesn't work
> >> >>
> >> >> Why those last 2 examples don't work?
> >> >>
> >> >> What I need to do is to add some values to existing inner array of
> >> >> multidimensional one (as in second non-working example).
> >> >> How do I do that?
> >> >>
> >> >> Leonti
> >> >> ___
> >> >> Vala-list mailing list
> >> >> Vala-list@gnome.org
> >> >> http://mail.gnome.org/mailman/listinfo/vala-list
> >> >
> >> >
> >> ___
> >> Vala-list mailing list
> >> Vala-list@gnome.org
> >> http://mail.gnome.org/mailman/listinfo/vala-list
> >
> >
> ___
> Vala-list mailing list
> Vala-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/vala-list
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Multidimensional arrays - help with using them.
I remember back in some versions
array[1, 2] works
Yu
On Fri, 2009-04-03 at 21:05 +0200, Leonti Bielski wrote:
> It's gotta be a way to do it :(
> Maybe by using lists or something similar?
>
> Leonti
>
> On Fri, Apr 3, 2009 at 8:01 PM, lariamat wrote:
> > Hello
> > I guess, it is a bug.
> > There are several issues with multidimensional arrays:
> > http://bugzilla.gnome.org/show_bug.cgi?id=548428
> > http://bugzilla.gnome.org/show_bug.cgi?id=548429
> > http://bugzilla.gnome.org/show_bug.cgi?id=576611
> > Also using arrays by reference is not working.
> > Regards,
> > lariamat
> >
> >
> > Am Freitag, den 03.04.2009, 18:48 +0200 schrieb Leonti Bielski:
> >> Hello!
> >> I need to use multidimensional array of ints, so this is what I do:
> >>
> >> int[][] some_array = {}; //declaring an array of int[]
> >> int[] some = {1,2,3}; // declaring array of ints
> >> some_array += some; // adding this array to 2D array - this works
> >>
> >> some_array[0] = some; // this doesn't work
> >> some_array[0] += 2; //this doesn't work
> >>
> >> Why those last 2 examples don't work?
> >>
> >> What I need to do is to add some values to existing inner array of
> >> multidimensional one (as in second non-working example).
> >> How do I do that?
> >>
> >> Leonti
> >> ___
> >> Vala-list mailing list
> >> Vala-list@gnome.org
> >> http://mail.gnome.org/mailman/listinfo/vala-list
> >
> >
> ___
> Vala-list mailing list
> Vala-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/vala-list
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Vala support for automake
Dear Jurg, I have two questions: If a VALA package depends on the features provided in the patch, will the distributed tarball(make dist) be compilable on a system with a unpatched automake? Is VALA itself going to make use of the features once the they are accepted in the automake upstream? If so, when? There might be problems, since some distributions doesn't updated their automakes timely. (eg RHEL5 didn't even update automake to 1.10.x) Regards, Yu On Tue, 2009-03-31 at 13:11 +0200, Jürg Billeter wrote: > I've updated the Vala support patches initially written by Mathias > Hasselmann to fix a few issues and to conform to the reworked header > file generation in Vala 0.7. It appears to work well with a simple test > project including correct distcheck and maintainer-clean functionality. > I didn't get around yet to test it with larger projects, but I'm not > aware of outstanding issues in the patch. > > The Vala support is intended to be used with the upcoming Vala 0.7 > release series (git master) and all later versions. Earlier versions may > work with some limitations (e.g., only recursive make). Vala 0.7.0 is > expected to be released this week. > > Regards, > Jürg > ___ > Vala-list mailing list > Vala-list@gnome.org > http://mail.gnome.org/mailman/listinfo/vala-list ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Is there a typedef?
I don't think VALA has a typedef. The keyword doesn't exist in VALA's parser. Yu On Tue, 2009-03-31 at 19:51 -0700, Charles Hixson wrote: > Does Vala have a typedef? If so, what's its syntax. > (Also, should this have gone to a different list?) > ___ > Vala-list mailing list > Vala-list@gnome.org > http://mail.gnome.org/mailman/listinfo/vala-list ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Dynamic arrays in Vala - example for newbie
I bet it is a bug.
Yu
On Tue, 2009-03-31 at 00:14 +0200, Leonti Bielski wrote:
> Ok, thanks for the advise then.
>
> Now I have different problem. If I do the code below inside a
> function, it works:
>
> /---
> string[] a;
> a= {};
> a += "sometext";
> /-
>
> But if I do initialization outside the scope to make array global:
>
> string[] a;
>
> And then inside the function:
> /---
> a= {};
> a += "sometext";
>
> I get following error:
> error: ‘a_size’ undeclared (first use in this function)
>
> How do I declare global array properly?
>
> Leonti
>
>
>
>
> On Mon, Mar 30, 2009 at 11:06 PM, Feng Yu wrote:
> > Use string[] instead of GLib.Array
> > The rule of thumb is to avoid GLib.Array, if possible.
> >
> > vala array implements a resize method.
> >
> >
> > On Mon, Mar 30, 2009 at 2:46 PM, Leonti Bielski wrote:
> >> Hello!
> >> I'm writing an application and I've come to the point where I need to
> >> use dynamic arrays.
> >> I tried Garray:
> >>
> >> GLib.Array test_calls; // it's declared from the start to be global
> >>
> >> test_calls = new GLib.Array(false, false, (uint)sizeof(string));
> >> test_calls.append_val("some string");
> >> debug("%s", test_calls.index(0));
> >>
> >> It gives me segmentation fault.
> >> How do I do this properly?
> >>
> >> I've been searching the whole day for example in Vala and couldn't find
> >> one :(
> >> Thanks. Leonti
> >> ___
> >> Vala-list mailing list
> >> Vala-list@gnome.org
> >> http://mail.gnome.org/mailman/listinfo/vala-list
> >>
> >
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Quaternions
If I remember correctly, the inverse of a quaternion (w, x, y, z) is then defined as (w, x, y, z)^-1 = (w, -x, -y, -z) With the inverse defined, the quotient is defined as q/p = q * p^(-1) In that sense (0, 0, 0, 1)/(0, 1, 0, 0) = (0, 0, 0, 1) * (0, -1, 0, 0) which is well-defined. Yu On Thu, 2009-03-26 at 23:24 +, Maciej Piechotka wrote: > William Swanson wrote: > > > --- Quaternions --- > > Quaternions are complex numbers generalized into four dimensions. As > > with complex numbers, all four basic operators (+ - * /) are > > well-defined. Quaternions are used to represent rotations in 3D, among > > other things. > > Nearly. Quaternions doesn't have defined division as: > > i * j = k > -j * i = k > > k/i = j or -j? > > Regards ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Array and Matrix types (SOC idea)
Hi, Adding a module may not be as easy as it seems. It is not infeasible to add a vala module compiling array and matrix operations into function calls. The issue is where we put the implementation of these functions. The dependency on an library other than GLib is definitely not intended by VALA. but if we put these calls as static functions in the c code files(as _vala_array_xxx), there will be plenty of replicas across the entire generated ccode project. Therefore I tend to retract my proposal on writing these vala compiler modules. It might be more feasible to do the follows: 1 Implement in C a runtime library implementing all array and matrix operations, with vapi files. 2 Patch VALA, allowing compiling arithmetic expressions to function calls. 3 Patch VALA, allow the mapping between functions and arithmetic operators in vapi bindings. 4 Modify the vapi files, map operator functions to operators, with the grammar suggested by a friend in the previous mails. The library also need to be standardized in a formal way so that people won't re-implement it again and again. Regards, Yu On Thu, 2009-03-26 at 09:34 -0700, Conrad Steenberg wrote: > Hi Michael, > > Thanks for the response. > > I've used Python + numerical/numpy in various guises since 1996, and > it's great for many things, especially compared to the sluggishness of > Matlab. > > A lot of our code needs a little (OK a lot) more speed in the "glue" > parts that usually gets handled by Python, so I end up having to write > Python extensions in C or Pyrex to speed things up. I guess that you > could say that the "organizational" parts of the code is becoming the > bottleneck. > > So the get this back on-topic: having support for arrays/matrices with > easy to read operators would allow the use of only one language that is > both fast and productive, especially using the Genie syntax. > > Anybody wants to add array and matrix types to Vala as a Google Summer > of Code project? :-) > > Cheers, > Conrad > > > On Wed, 2009-03-25 at 17:40 -0600, Michael Torrie wrote: > > Conrad Steenberg wrote: > > > FWIW I would really like to see this implemented as I write scientific > > > code every day and would love to use Vala/Genie instead of C++ :-) > > > > This is OT, but most of the scientists around here (at my university) > > have all switched away from Fortran and C++ to Python. They use fast > > numeric libraries like scipy, numpy, matlibplot, and other tools. In > > fact a few have replaced MatLab with Python with great success. Python > > may be more appropriate for your use than Vala, in this specific case, > > if you feel inclined. > > > > I personally see Vala as a tool to develop and enhance GTK and other > > Gnome-based libraries mainly. In fact I could see future versions of > > GTK being written mostly in Vala. I know that several folks on this > > list are using Vala as a main language, though. > > > > I wonder how easy it would be to write python extension modules using > > Vala. > > ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Operator overloading
Would it be reasonable to write some Vala compiler modules that implements these types internally? The implementations can then be shared across the entire vala user base. Yet these modules can be release under different packages, eg, vala-ccode-currency, vala-ccode-vector, vala-ccode-complex ... Also with these backend modules, one can have far more optimizations(assembly, sse, implicit parallism..) than those achievable within vala itself. Yu On Tue, 2009-03-24 at 16:22 -0700, William Swanson wrote: > It seems useful to catalog the use-cases for operator overloading at > this point, since folks are missing the big picture by focusing on > only one or two: > > --- Non-standard number representations --- > * Arbitrary-sized large integers > * Fractional (int/int) number represtations > * Base-10 floats for rounding issues > * Arbitrary-precision floating-point numbers > * 16-bit floats for OpenGL textures > These types would implement the four basic operators (+ - * /) as well > as modulo (%) for the integer types. Xavier Bestel says, "Math > operators should be limited to > purely math operations, on integers and reals." Well, Xavier, these > *are* integers and reals, and they want operator overloading. > > --- Complex numbers --- > Like the real numbers, these numbers have well-defined versions of the > four basic operators (+ - * /). There is no ambiguity or lack of > clarity when someone says "complex1 + complex2" or "complex1 / > complex2". Many programming languages even have complex numbers as a > built-in type, including C99. > > --- Quaternions --- > Quaternions are complex numbers generalized into four dimensions. As > with complex numbers, all four basic operators (+ - * /) are > well-defined. Quaternions are used to represent rotations in 3D, among > other things. > > --- Vectors --- > Vectors can come in fixed sizes like to , or they > may be arbitrarily sized. Depending on the application, vectors can be > represented with integers, floats, or doubles. In every case, the + > and - operators perform member-wise addition, and the * and / > operators perform scaling. Vectors also support other operations like > the dot product and cross product, but those should be implemented as > named functions as Frederik says earlier. > > --- Matrices --- > Like vectors, matrices come in all sizes and types. Like vectors, the > + and - operators operate member-wise, while the * and / operators > perform scalar multiplication. In addition, matrices define a * > operator that works on any two properly-sized matrices. The other > matrix operations like transpose and inverse would be named functions. > --- > > These are the applications I can think of, and I am sure there are > others. Each of these use-cases is a mathematical object, and the > operators that apply to these objects are well-established by > mathematical convention. Any programmer using these entities already > has the mathematical background to know how the operators should > behave. If not, they can always read the documentation. Named > functions, on the other hand, make reading documentation mandatory. Is > the member-wise addition function called "plus," "add," "add_to," or > what? Which of these functions modifies the original object, and which > does not? With operator overloading, the answer is simply "+" or "+=". > Isn't saving a trip to the documentation the nature of clear, > self-explanatory code? > > I hear a lot of strong terms like "nightmarish" and "horror story" in > relation to operator overloading, but not a lot of concrete examples > to back them up. I agree that using << for IO is ugly, but that is > hardly justification for eliminating the entire feature. I suspect the > problem isn't operator overloading itself, but C++'s excessively > flexible nature. A locked-down implementation that supports only the > basic math operators (+ - * / %), forces those operators to be > "const" to eliminate side effects, and forces the assignment operators > (+= -= *= /= %=) to behave predictably would fully support the use > cases above and would not leave much room for "nightmarish horror > stories". This isn't C++, where you can overload the [] or -> > operators to shoot yourself in the foot. > > -William Swanson > ___ > Vala-list mailing list > Vala-list@gnome.org > http://mail.gnome.org/mailman/listinfo/vala-list ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Operator overloading
On Sun, 2009-03-22 at 15:27 +, pancake wrote:
> Are there any plans to implement operator overloading in Vala?
>
> I will find them really useful because it is a really nice addition feature
> for the language. Using it will allow us to wrap all the arithmetic access
> to use APIs like GMP for big number operations.
>
> Bignum b = new Bignum(3); // Bignum b = 3; (should be an alias)
> b *= 999;
> stdout.printf("%lld\n", b);
>
> We can also use the operator overloading to wrap access to optimize
> paralelized operations to be done in a while by using external APIs
> like OpemMPI or any liboil to optimize code with MMX/SSE stuff.
On this point:
Getting parallel is more related to loops than to operators.
A family of [OpenMP (... = ...)] implementing the OpenMP specification
would be sufficient for implicit parallelism.
OpenMPI(and its predecessors - lam/mpich) are not designed for automatic
parallelism; they are for explicit parallelism.
> At the same time, by having operator overloading we can have our
> own implementation for any arithmetic operation over any kind of
> object which will make Vala a more flexible language and this will
> open lot of possibilities in video game programming.
>
> Another nice feature would be to add an 'auto-cast' capability using
> code attributes over the class definitions to simplify the code writing
> when a cast is necessary to be done. for example:
>
>string str = obj.to_string();
>
> This can be simplified and defined as:
>
> .. Object definition (or any other class) ..
> [[CCode (autocast="string")]
> string to_string();
>
> So we can now do:
> Object obj = new Object();
> string str = obj;
This is flexible in writing, but unreadable for the reader. To
understand string str = obj, the reader has to find the definition of
Object, search for all autocast annotations, then guess which is which.
>
> This is a not very complex situation, but we can for example serialize
> data types into xml strings in a simple way with this concepts.
>
The more complex the situation gets, the more difficult for the reader
to understand the code. Verbosity is not always bad, given that our
brains are not compilers.
Does java support operator overriding? Python? C#?
Yu
>
>
> --pancake
> ___
> Vala-list mailing list
> Vala-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/vala-list
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Extension Methods
On Fri, 2009-03-20 at 00:09 +0100, Frederik wrote:
> Feng Yu wrote:
> > What about this:
> >
> > public extend class Gtk.Widget {
> > public bool set_gl_capability (GdkGl.Config glconfig,
> > Gdk.GlContext? share_list, bool direct, int render_type) {
> >
> > // do stuff.
> > }
> > }
> >
> > AKA, when vala encounters the extend keyword, instead of panicing
> > duplicated class declarations, it simply add the decleration to the
> > existing class.
>
> 'extend' could be confused with subclassing (for example Java uses the
> 'extends' keyword for subclassing).
>
> I know this feature from Objective C, where it's called "categories":
> http://en.wikipedia.org/wiki/Objective_c#Categories
>
> These 'categories' are even named, so you can group these additional
> methods thematically. If Vala considers such a feature I would propose
> the following syntax:
>
> public class string category SpellChecking {
> // ...
> }
>
> public class Gtk.Widget category GLFunctionality {
> public bool set_gl_capability (...) {
> // do stuff.
> }
> // ...
> }
>
> These category names would get lost in C code, but they could be nice
> additional information in a Vala object browser.
Yes I'm loving it. Let's file a bugzilla for it.
>
>
> Regards,
>
> Frederik
> ___
> Vala-list mailing list
> Vala-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/vala-list
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] DBus services in shared modules implementing interfaces defined in a shared library
Hi Michael,
The types of internally used libraries are not registered if ModuleInit
is used.
I solved the same issue recently, in a rather convoluted way.
A noinst convenient library libcore.la
Another noinst convenient library libmain.la
Each is built with one call to valac. They are then compiled with gcc,
and linked via libtool into libfoo.la which is an installed shared
library.
In libcore, there is a public static method:
[ModuleInit]
core_init() {}
PluginManager class and PluginModule class are defined in libmain.la,
class PluginManager {
void query(string filename);
void query_static(PluginModule.ModuleInitFunc init_func) {
push new PluginModule.static(init_func) to a owned list.
}
}
class PluginModule: TypeModule {
PluginModule.from_file(string file);
PluginModule.static(ModuleInitFunc init_func);
private ModuleInitFunc init_func;
public override use() {
init_func(this);
}
}
libmain.la implements a public init function (NOT a ModuleInit)
namespace Foo {
public void init() {
manager = new PluginModuleManager();
manager.query_static(core_init);
}
}
In this way I was able to ensure all types added in libcore.la are
automatically initialized, without manifestly peeking them one by one.
The two library scheme is mandatory. If all classes are in the same la
[ModuleInit] will also floats PluginModule, which makes it
uninstantiatable. Then it will be impossible to bootstrap the entire
type system.
Regards,
Yu
On Wed, 2009-03-18 at 21:33 +0100, Michael 'Mickey' Lauer wrote:
> On Monday 16 March 2009 22:31:13 Feng Yu wrote:
> > You have to subclass GTypeModule, and manifestly call the annotated
> > method(declared in the plugin) within the plugin manager code.
>
> Yes, that's clear and I'm doing that, and these types get registered, but
> obviously not some of their bases, which are contained in the shared library
> (not the plugin). How am I supposed to init these? If I add a [ModuleInit] to
> the shared library, then I get the following:
>
> void register_types (GTypeModule* module) {
> g_return_if_fail (module != NULL);
> fso_framework_device_led_register_type (module);
> fso_framework_abstract_logger_register_type (module);
> fso_framework_file_logger_register_type (module);
> fso_framework_syslog_logger_register_type (module);
> fso_framework_base_plugin_register_type (module);
> fso_framework_smart_key_file_register_type (module);
> fso_framework_abstract_subsystem_register_type (module);
> fso_framework_base_subsystem_register_type (module);
> fso_framework_dbus_subsystem_register_type (module);
> g_debug ("zzz.vala:6: init all types ");
> }
>
> where "fso_framework_device_led_register_type" is exactly the dbus interface
> which doesn't work.
>
> So -- although the shared library which contains these types is not loaded
> via
> dlopen (but rather linked to the main executable), I need to create a
> TypeModule for it?
>
> Cheers,
>
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] any workarounds for bug 575475?
Hi buddies, I ran into problems when trying to upgrade global menu into vala 0.5.7. I really appreciate if anyone can come up with a workaround. Thanks! http://bugzilla.gnome.org/show_bug.cgi?id=575475 Rebards, Yu ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Creating executables without glib/gobject
My guess: When VALA receives sufficient amount of interest on kernel and similar critical places, people will start putting pressure on refactoring GLib so that part of it can be linked within these critical applications. Reinventing a little bit of glib will be the very beginning of this hard and slow process. Yu On Sat, 2009-03-14 at 19:58 +, Sam Liddicott wrote: > > -Original Message- > From: JustFillBug > Sent: 14 March 2009 06:00 > To: vala-list@gnome.org > Subject: Re: [Vala] Creating executables without glib/gobject > > >This is crazy. If go down this path, people will eventually reinvent > >glib at the end. > > Maybe. But glib wil never get linked into the kernel. Or grub. And no-one > will recreate glib - but maybe many people will create bits of it as they > need... > > Sam > > ___ > Vala-list mailing list > Vala-list@gnome.org > http://mail.gnome.org/mailman/listinfo/vala-list ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Friend class?
On Tue, 2009-03-10 at 08:07 +0100, Jürg Billeter wrote: > On Mon, 2009-03-09 at 20:36 -0400, Yu Feng wrote: > > Dear list, > > > > Are friend classes available in VALA? If not, are there any particular > > reason against it, and are there any alternatives for friend classes? > > There is no plan to support friend classes in Vala. The `internal' > modifier is as close as it gets, it restricts access to the class/member > to the current library/application. If this is not fine-grained enough, > maybe you should consider moving some code into a separate library (can > also be a libtool convenience library in case you're using autotools). > Can a property setting be internal? I tried to added to a setter and apparently nothing happened. Regards, Yu > Jürg > ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] GSL binding problem: OdeivEvolve::apply
On Mon, 2009-03-09 at 20:52 -0200, Matías De la Puente wrote: > Hi Yu, > > You are right they should be ref doubles not arrays. > Here's the patch > > diff --git a/vapi/gsl.vapi b/vapi/gsl.vapi > index 3ad9979..883c861 100644 > --- a/vapi/gsl.vapi > +++ b/vapi/gsl.vapi > @@ -3514,7 +3514,7 @@ namespace Gsl > > [CCode (cname="gsl_odeiv_evolve_alloc")] > public OdeivEvolve (size_t dim); > -public int apply (OdeivControl con, OdeivStep step, > OdeivSystem* dydt, [CCode (array_length = false)] double[] t, double > t1, [CCode (array_length = false)] double[] h, [CCode (array_length = > false)] double[] y); > +public int apply (OdeivControl con, OdeivStep step, > OdeivSystem* dydt, ref double t, double t1, ref double h, [CCode > (array_length = false)] double[] y); > public int reset (); > } > Thank you! Yu > Matias ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Friend class?
On Tue, 2009-03-10 at 08:25 +0700, Hans Baier wrote: > 2009/3/10 Yu Feng : > > Dear list, > > > > Are friend classes available in VALA? If not, are there any particular > > reason against it, and are there any alternatives for friend classes? > > > > Regards, > > > > Yu > > If you need friend classes, you should probably redesign the code. > Yes. This is what I guessed for the reason why friend classes are not popular. Would you give me some advices? > What do you need them for? I have a class (Track) that calls Gsl for solving ODEs. Gsl requires several callbacks which don't look vala. Keeping them in the same source file makes the Track class clumsy. Therefore I am leaning to move those callbacks to another class, which is privately called and internally used by Track. The issue arises here. The moved code modifies some obviously private members of Track. I remember friend classes is invented for doing this. An alternative would be declaring the new class as a private child-class inside Track. However that doesn't help cleaning up the source code file since the child-class has to reside in the same file. Best, Yu > > Hans ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Friend class?
Dear list, Are friend classes available in VALA? If not, are there any particular reason against it, and are there any alternatives for friend classes? Regards, Yu ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Added kill and pid_t to posix.vapi
Curious: What does rank mean? Yu On Wed, 2009-03-04 at 14:15 +0100, Jürg Billeter wrote: > On Wed, 2009-03-04 at 13:50 +0100, pancake wrote: > > mmh, pid_t is not a struct, is an 'int', in which whay do you get > > the (int) value of this empty struct? I would rather prefer to do > > it in another way to allow vala use the 'int' nature of the pid_t type > > for conversions between numbers, strings and process-id's. > > The IntegerType attribute should help us here: > > [IntegerType (rank = 6)] > > Jürg > > ___ > Vala-list mailing list > Vala-list@gnome.org > http://mail.gnome.org/mailman/listinfo/vala-list ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Ellipsis syntax (Was: Ellipsis as an argument..)
Hi,
On Tue, 2009-02-24 at 22:43 +0100, Didier "Ptitjes" wrote:
> I asked the same to Jürg on the channel, and it appears there is only
> for now a syntax for typed ellipsis. The following is an example of the
> syntax :
>
> public static void foo(params string[] args) {
> // ...
> }
>
> So if your arguments can be subclasses of GObject, you could use "params
> Object[] args".
>
> It appears that there isn't yet any syntax to query about an untyped
> ellipsis content. I think this is the best occasion to make proposals.
>
> I have none to propose as the only I know of is the one of Java, and it
> is typed as Java supports auto-boxing.
>
> I would be glad to implement it and propose a patch if something gets
> consensus. Any ideas ?
>
What about picking up the old and dirty va_args?
Example:
public static void foo(string fmt, params va_args valist) {
vprintf(fmt, valist);
}
public static void foo2(string fmt, params va_args valist) {
int i = valist.next_int();
void* p = valist.next_pointer();
}
Compiled CCode:
void foo(const char * fmt, ...) {
va_list valist;
va_start(fmt, valist);
foo_valist(fmt, valist);
va_end(fmt);
}
void foo_valist (const char * fmt, va_list valist) {
vprintf(fmt, valist);
}
void foo2(const char * fmt, ...) {
va_list valist;
va_start(fmt, valist);
foo2_valist(fmt, valist);
va_end(fmt);
}
void foo2_valist (const char * fmt, va_list valist) {
int i = va_arg(valist, int);
void* p = va_arg(valist, void*);
}
This can give us the most C compatibility. But va_args has to be a
special type handled by the compiler.
Best,
Yu
> > Thanks
> > Shawn
>
> Best regards, Didier.
>
> ___
> Vala-list mailing list
> Vala-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/vala-list
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Generics: constraints and 'new T ()' on type parameters?
Hi Sam,
On Thu, 2009-02-26 at 19:52 -0500, Sam Danielson wrote:
> I'm writing some ORM where a database view is wrapped in a factory
> object that produces records. Ideally I would think a Factory
> should be able to return new T's but I can't figure out how to do
> this. The work around is to return the Record base class and then
> upcast, or put virtual upcasting functions in all of the
> derived Factory classes. Yuck.
>
> Is there a fundamental reason why this cant work?
>
> class Foo {}
> class Factory {
> public static T make () {
> return new T ();
> }
> }
>
Suppose Foo is the root of all the products from your factory, I suggest
using this instead of those ugly generics.
class Foo:Object {
}
class Foo1:Foo {
}
class Factory {
public static Foo make(Type type) {
return Object.new (type) as Foo;
}
}
The types can be obtained with typeof(Foo1). The constraints can be done
at run-time with Type.is_a() or =.
BTW: shouldn't a factory has one method for making each type of objects?
Yu
> And is there a plan to implement type parameter constraints? Something like...
>
> class Factory { ... }
>
> The compiler may then prove that it is okay to 'new T ()'
>
> PS. I can slip the following by the type system without a complaint. Should I
> file a bug?
>
> class Foo {}
> class Factory {
> public static T make () {
> return new Foo ();
> }
> }
>
> LLAP,
> Sam Danielson
> ___
> Vala-list mailing list
> Vala-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/vala-list
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Confused with valagenieparser & valaparser
I am working on a patch to allow typeof(expr) [bug 583075]. The two parsers in vala/, namely genieparser & parser confuse me a lot. What is the difference between them? Which file should I patch? Regards, Yu ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Binding questions
[SimpleType] ?
On Sun, 2009-02-15 at 20:41 -0500, Michael B. Trausch wrote:
> I am trying to create a small Xlib binding for Vala, with a little bit
> of difficulty. I think I just don't understand what it is that I am
> doing fully.
>
> Starting with what Frederik gave as an initial set of code, I have so
> far come up with:
>
> [CCode(cprefix = "X", cheader_filename = "X11/Xlib.h")]
> namespace XLib {
> [Compact]
> [CCode(cname = "Display", free_function = "XCloseDisplay")]
> public class Display {
> [CCode(cname = "XOpenDisplay")]
> public Display(string? display_name = null);
>
> [CCode(cname = "XDefaultScreen")]
> public int get_default_screen();
>
> [CCode(cname = "XBlackPixel")]
> public long get_black_pixel(int screen_number);
>
> [CCode(cname = "XWhitePixel")]
> public long get_white_pixel(int screen_number);
>
> [CCode(cname = "XConnectionNumber")]
> public int get_connection_number();
>
> [CCode(cname = "XDefaultColormap")]
> public ColorMap get_default_colormap(int screen_number);
>
> [CCode(cname = "XAllPlanes")]
> public static long get_all_planes();
> }
> }
>
> Now, the problem is the return value for XDefaultColormap. This is
> really a typedef to XID, which itself is a typedef to CARD32, which is
> in turn a typedef to "unsigned long". I could just declare it to be an
> ulong, but it'd seem that there should be some way to do this in a
> type-safe manner. Is there something simple that I am just not getting?
>
> Also, in the above example, there is the public class Display. Now, it
> has fields, though they are for the purpose of this implementation and
> the Xlib manual private fields. However, assuming for a second that
> they weren't, and they were expected to be exposed to the user, how
> would that be done whilst preserving the order of the items in the C
> struct?
>
> --- Mike
>
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [Having fun with Vala] Multiboot kernel using Vala!
Hi Matias, I am curious about how GLib was staticly linked to your kernel. I didn't see any flags on this in your makefile. Yu On Mon, 2009-02-09 at 12:45 -0200, Matías De la Puente wrote: > Hello all!, > > I was playing with vala to see if it's posible to write a minimal > kernel using vala. > Based in the multiboot sample > (http://www.gnu.org/software/grub/manual/multiboot/html_node/Example-OS-code.html), > I was able to wrote a minimal multiboot kernel in vala. ;) > I wrote a multiboot binding and a video binding for displaying the > information.. > In the attachment there's the code and a iso file to use with an > emulator, I use: qemu -m 8 -cdrom cdrom.iso > For compiling the code you need nasm, gcc, vala and genisoimage. Use > make cdrom.iso to build the image of the iso > You can download the code from here: > http://sites.google.com/site/mfpuentear/Home/multiboot-vala.tar.bz2?attredirects=0 > > Have fun ;) > Matias > ___ > Vala-list mailing list > Vala-list@gnome.org > http://mail.gnome.org/mailman/listinfo/vala-list ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] reading and writing binary data
Not sure if helpful, but apparently uchar[] stands for byte arrays, string stands for utf8 string. I believe a patch to glib-2.0.vapi should be made to include the ->data member in class ByteArray. - Yu On Mon, 2009-01-26 at 18:52 -0800, jezra lickter wrote: > Hello, > I am using GNet to read data from a file over http and then write the > data to a local file. Everything works fine when I am reading a text > file but when I read some sort of binary file the data gets corrupted. > > I believe the problem is caused by Vala converting the data > that I read into a UTF8 string. One way to fix this problem is to read > the data as a GLib.ByteArray but I couldn't find a way to iterate over > ByteArray and extract a single byte. It may also be possible to pull > the raw string data from the Vala string. Unfortunately I don't know > how to do this. Any advice regarding reading and writing binary data > would be greatly appreciated. > > jezra > ___ > Vala-list mailing list > Vala-list@gnome.org > http://mail.gnome.org/mailman/listinfo/vala-list ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Inverse of control in VALA?
On Mon, 2009-01-26 at 14:24 -0800, Christian Hergert wrote: > On Mon, Jan 26, 2009 at 12:26 PM, Pawel Cesar Sanjuan Szklarz > wrote: > > Hi. > > > > Is it planed any feature to support inverse of control on VALA?? > > > > In java I found that this can be really helpfull. A good library for > > this on java is guice: > > > > http://code.google.com/p/google-guice/ > > > > > > Pawel Szklarz. > > Implementing a factory to create items and read from an external file > or whatever seems pretty easy with GObject. What looks like a pain is > making sure all the types are registered simply so you can have access > to the GType by name. > > I guess the other option could be to convert a "SomeTypeName" to > some_type_name_get_type and look for the symbol and execute it to make > sure the type gets registered. Yes. This is almost what GtkBuilder does. For vala gtype_instance classes, you may want to convert to either some_type_name_new or some_type_name_construct, since you can't create these objects with g_object_new. BTW: wouldn't it be nice if VALA automatically register all vala defined types in either g_module_check_load or main? Best, Yu > > -- Christian > ___ > Vala-list mailing list > Vala-list@gnome.org > http://mail.gnome.org/mailman/listinfo/vala-list ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Vala generated .gir file incompatible with g-ir.
And a patch in http://bugzilla.gnome.org/show_bug.cgi?id=568951 to fix most issues I met. Yu On Fri, 2009-01-23 at 23:59 -0500, Yu Feng wrote: > Hi Jurge, > > I was trying to run g-ir-compiler with a vala generated .gir file. > > Apparently there are two issues: > > 1. the default file name generated by vala differ from the namespace > name, and g-ir-compiler complains about this. > > 2. g-ir-compiler expects a value for the members of enumerations fields > (or core dump), but vala doesn't explicitly set these values. > > Should I file a bug to g-ir about (2) or should we patch vala? > > Regards, > > Yu > ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
