Re: [Vala] Gtk+ bindings update

[Jim Nelson]

On Sat, Aug 23, 2014 at 8:12 AM, Michael Catanzaro 
 wrote:

Non-GNOME programs certainly will not care one way or
the other whether they are broken by vala 0.26 or by vala 0.28. And 
the
changes are certainly bugfixes, not features or UI changes that would 
be

affected by the current freeze.


This is slightly off-topic, but I'd like to address it while it's on 
the table.


Yorba's applications were considered non-GNOME for nearly five years 
and are still not part of GNOME core (although we're now hosted on the 
infrastructure).  We *definitely* care when we we're broken between 
releases of Vala.  It's worse when those changes are introduced at the 
last minute in the cycle -- less time to prepare -- and even worse, 
when they're introduced in a dot-release.


Things have stabilized with Vala over the past few releases, so good 
times.  I hope that track record continues.


-- Jim
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Gtk+ bindings update

[Jim Nelson]

I will probably patch the set_default_icon_list() bug today using 
Evan's suggested patch just because it looks like a time-bomb waiting 
to go off.  It turns out Shotwell has same problem, although that code 
has been in place since 2010, so the time-bomb has a slow-burning fuse.


Shotwell has another compiler issue (no private members in structs) 
which is not a big deal.  I'll probably patch that today too just to 
get it off my plate.


-- Jim

On Thu, Aug 21, 2014 at 1:09 PM, Luca Bruno  
wrote:

Right sorry that's due to the GIR.

Some things seem wrong. For example Gtk.get_default_language return 
should

be unowned. Why is it owned now?
I guess the same goes for all other static methods.


On Thu, Aug 21, 2014 at 9:58 PM, Evan Nemerson  
wrote:



 On Thu, 2014-08-21 at 21:39 +0200, Luca Bruno wrote:
 > Certainly that kind of splitting is unfeasible. I understand 
there are a
 > bunch of fixes, however applications work somehow and I wouldn't 
like to
 > break them. Also, even if Vala is hosted at GNOME, I remind you 
there's
 > plenty of projects relying on Vala. Other applications are as 
important

 as
 > GNOME applications.

 Of course, but if they're not GNOME projects they probably don't 
really

 care about the freeze.

 > However, in the case of other applications, those may as well 
keep using
 > Vala 0.24. After all, distributions ship with multiple versions 
and Vala

 is
 > parallel-installable exactly for this reason.
 >
 > In reality, my main concern is about the concrete accessors bug. 
How much

 > stuff does that bug affect? Would it be possible to just drop in a
 > custom.vala for those until the bug gets fixed?

 (For those of you who don't know what he is talking about, bug 
#730744)


 Rico, correct me if I'm wrong, but the concrete accessor bug doesn't
 affect Rico's patches.

 Are you suggesting we just do the switch to GIR now instead of 
this?  It
 should be possible to just copy the old stuff from the VAPI and 
dump it

 in a custom.vala for now, yes.  Of course, it would end up being a
 pretty big custom.vala, and a big chunk of metadata to skip all the
 relevant symbols, but certainly possible.  If memory serves it just
 switching to the GIR version without copying over that stuff would 
break

 a *lot* of stuff and I don't think that's an option.  I'm okay with
 that, but I'm not sure I will have time soon enough.

 From the VAPI's perspective switching to GIR but overriding the 
concrete
 accessor stuff should be roughly equivalent to accepting Rico's 
patch.
 AFAIK all he did was go through the diff to the GIR version and add 
the

 GIDL equivalent.





--
www.debian.org - The Universal Operating System
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Gtk+ bindings update

[Jim Nelson]

It's not a requirement.  Rico mentioned that these changes affected 
Geary.  Since it sounds like these changes will either in be 0.26 or 
0.28, I was hoping to see what the problems are now rather than be hit 
with them later.  That's all.


-- Jim

On Thu, Aug 21, 2014 at 12:01 PM, Luca Bruno  
wrote:

Why is it a requirement? For which applications?


On Thu, Aug 21, 2014 at 8:57 PM, Jim Nelson  wrote:
Is this on a branch somewhere?  I'd like to know how this affects 
Geary (and Yorba's other projects).


-- Jim

On Thu, Aug 21, 2014 at 11:41 AM, Luca Bruno  
wrote:
Thanks for your hard work. Is this change a requirement for the new 
stable
release? Blocking some software? Can it be merged instead in vala 
0.27?



On Thu, Aug 21, 2014 at 7:28 PM, Rico Tzschichholz 


wrote:


 Hi,

 I had a small discussion on IRC with Evan about still pushing a 
greater

 Gtk+ bindings update for the current cycle. [1]

 Those updates are fixing a lot problems like unusable symbols and 
a

 bunch of memory-leaks. While the GIR transition for building the
 gtk+-3.0 binding is delayed for quite some time it is pretty 
necessary

 to finally get starting to those issues.

 I really like to push the staging changes to master despite being 
in the
 GNOME freeze. There was also no vala release yet which other 
projects
 could rely on. Official GNOME applications which are using Vala 
will be
 fixed as fast a possible. Currently known are gitg and geary 
which needs

 minor patching.

 Regards,
 Rico

 [1] https://git.gnome.org/browse/vala/log/?h=staging






--
www.debian.org - The Universal Operating System
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list




--
www.debian.org - The Universal Operating System

___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Gtk+ bindings update

[Jim Nelson]

Is this on a branch somewhere?  I'd like to know how this affects Geary 
(and Yorba's other projects).


-- Jim

On Thu, Aug 21, 2014 at 11:41 AM, Luca Bruno  
wrote:
Thanks for your hard work. Is this change a requirement for the new 
stable
release? Blocking some software? Can it be merged instead in vala 
0.27?



On Thu, Aug 21, 2014 at 7:28 PM, Rico Tzschichholz 


wrote:


 Hi,

 I had a small discussion on IRC with Evan about still pushing a 
greater

 Gtk+ bindings update for the current cycle. [1]

 Those updates are fixing a lot problems like unusable symbols and a
 bunch of memory-leaks. While the GIR transition for building the
 gtk+-3.0 binding is delayed for quite some time it is pretty 
necessary

 to finally get starting to those issues.

 I really like to push the staging changes to master despite being 
in the
 GNOME freeze. There was also no vala release yet which other 
projects
 could rely on. Official GNOME applications which are using Vala 
will be
 fixed as fast a possible. Currently known are gitg and geary which 
needs

 minor patching.

 Regards,
 Rico

 [1] https://git.gnome.org/browse/vala/log/?h=staging






--
www.debian.org - The Universal Operating System
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Thread Support

[Jim Nelson]

Adding some more descriptions like add " and valac's 
--target-glib=2.32 flag"text to replacement attribute, in order to 
help developer how to proceed. Is this description correct? developer 
must use --target-glib in order to enable new features?


--target-glib is simply telling Vala which minimum version of GLib will 
be required by the application.  Since new features are added to GLib 
over time (and some are deprecated), this is just a way to pick a 
baseline of functionality for your application.


-- Jim
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Thread Support

[Jim Nelson]

On Wed, Aug 13, 2014 at 1:13 PM, Daniel Espinosa  
wrote:

read_async.begin();


For the comment above, I think this form must be deprecated to add 
clear meaning in Vala code for async functions, even the compiler 
must rise an error when yield is used in unasync function.


It's not about readability, they are different ways of invoking the 
same method.  The first (with "yield") can only be used within an async 
method.  It means what it looks like, the caller will yield control to 
read_async() until the call returns.  The second (with ".begin") can be 
called from any method.  It initiates read_async() but returns 
immediately; you might think of it as scheduling the call in the 
background and not waiting for it to complete.  (You can pass a 
completion callback with .begin that is called when finished.)



Then this is a bug in glib-2.0.vapi, because it seds:

[Deprecated (since = "2.32", replacement = "new Thread ()")]
[CCode (simple_generics = true)]
public static unowned Thread create (ThreadFunc func, bool 
joinable) throws ThreadError;


I'm not sure what you're seeing there.  If you're using Vala 0.20, I 
would recommend upgrading to at least the latest stable version (0.24).


Warning from compiler must suggest to use this instead to just warn 
about use implicit .begin is deprecated. Message could be:


"async functions should use attribute .begin or 'yield' modifier when 
it is called"


You might try filing a ticket or, better yet, a patch.

-- Jim
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Thread Support

[Jim Nelson]

On Wed, Aug 13, 2014 at 10:55 AM, Daniel Espinosa  
wrote:
I have an async function called directly in my code. When compiles I 
get

this:

XXX: warning: implicit .begin is deprecated


That means you called the async method with neither a yield keyword nor 
with the begin modifier.  You need to do either this:


yield read_async();

or this:

read_async.begin();

Vala used to support:

read_async()

as being equivalent to using .begin(), but that form was deprecated, 
hence the message you're seeing.



Thread th = new Thread.try ("loading scl", () => {
async_function (); /*Asinc function */
return null;
  });
th.join ();

Error message is:

X: error: The name `try' does not exist in the context of 
`GLib.Thread'


I've checked glib-2.0.vapi, for both vala-0.20 and 0.22, that 
function is
present just for GLIB_2_32, checking my installed version I have a 
2.40 on

a GNOME Ubuntu 14.04 box.


Add this flag to valac:

--target-glib=2.40

or:

--target-glib=2.32

Be aware by doing this you're making your app incompatible with earlier 
versions of glib.


Regarding your code itself, there's a few more problems.  First, you 
can't use  as a type parameter, you must give an actual type that 
represents storage.  "void *" is probably the best way to go if you 
truly have nothing to pass to your threads.


Second, you're calling an async method within the background thread.  
There's nothing technically wrong with this, but I suspect that's not 
what you really want.  The usual pattern of use is to call the async 
method from your main ("foreground") thread.  The async call might use 
background threads as an implementation strategy (to do the work 
without blocking the foreground thread).


-- Jim
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Planet Vala

[Jim Nelson]

I tag all my Vala blog posts with a "vala" keyword.  Can Planet Vala 
pull from a particular tag feed?


-- Jim

On Fri, Mar 21, 2014 at 12:21 AM, Evan Nemerson  
wrote:

I've gone ahead and launched a blog aggregator for Vala at
 (thanks to Jürg for letting me use 
the

subdomain), as discussed here a few days ago.

Currently there are only a few blogs included, but I would really like
to add more soon, especially (though not exclusively) of people who
aren't already on planet.gnome.org.  The content doesn't have to be
completely, or even mostly, about Vala.

I've put the Venus configuration information on GitHub
(), so please feel free to file
issues or pull requests for whatever you would like to see.


-Evan
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Planet Vala? (was: Re: [Genie] Re: Vala on Android)

[Jim Nelson]

I'm very interested.

As far as blogs to add, I can't name any dedicated active Vala blogs 
(although I haven't looked recently).  What I like about your proposal 
is that it would encourage more blog activity about Vala.


-- Jim

On Mon, Mar 17, 2014 at 7:48 PM, Evan Nemerson  
wrote:

Does anyone have an opinion on whether we should put together a blog
aggregator for Vala/Genie?

If there is any interest Jürg might be willing to let us use
planet.vala-project.org, I can probably host a Planet Planet
installation on my dreamhost account, and Florian may be willing to 
let

us steal the valadoc.org theme.

Please let me know if you are interested, as well as any suggestions 
you

might have about blogs to add.


-Evan


On Tue, 2014-03-18 at 01:42 +, Al Thomas wrote:

 Great stuff Gontzal!
 
 Does this mean Vala/Genie programs can be compiled for non-rooted

 Android devices?
 
 I have created a new Genie wiki page:
 
 https://wiki.gnome.org/Projects/Genie/TutorialsBlogsExamples
 
 and included links to some of your projects and tutorials. I have 
also

 included a link to
 https://github.com/avalanche-games/avalanche/wiki/Getting-Started-%
 28for-Linux-users%29 to help get people interested in this. What do
 you think?
 
 Al
 
 
 
 >

 > From: gontzal 
 >To: vala-list@gnome.org 
 >Sent: Saturday, 15 March 2014, 0:01

 >Subject: [Vala] Vala on Android
 > 
 >

 >Hi Folks!!
 >
 >Genie is already runing on Android using SDL 2.0.
 >See an educational app in android playstore named "Katamotz 
Hitzak" .

 >How to compile a genie/vala + SDL 2.0 game-application?
 >http://manualgenie.blogspot.com.es/
 >https://github.com/avalanche-games/avalanche/wiki/_pages
 >
 >thanks... i love Genie. Maintain it please
 >___
 >vala-list mailing list
 >vala-list@gnome.org
 >https://mail.gnome.org/mailman/listinfo/vala-list
 >
 >
 >
 ___
 vala-list mailing list
 vala-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/vala-list


___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

[Vala] Change in 0.23.1 for array ownership and .length parameter

[Jim Nelson]

Just wanted to give everyone a head's-up about a change that appeared 
in Vala 0.23.  Previously you could do this in Vala:


uint8[] ar = new uint8[10];
// ... fill ar with interesting bytes ...
process((owned) ar, ar.length);

... where process() takes an array and a length field (sometimes 
because an array might have a "filled" count versus it's allocated 
length).  Before 0.23 the above worked, but now ar.length will be 
zeroed out before it's passed to process():


https://bugzilla.gnome.org/show_bug.cgi?id=721001

I found a few instances of this pattern in our code and thought others 
might want to be alerted about it as well.


-- Jim
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] .gir and .metadata file warnings and errors

[Jim Nelson]

On Thu, Dec 12, 2013 at 12:29 AM, Evan Nemerson  
wrote:
You can still do this step as part of your build process—you don't 
need

to include the generated VAPI in your repository.  If you're worried
about the user updating WebKit between Geary compilations while there 
is

a VAPI in the build directory, that shouldn't really be an issue since
build systems don't usually detect changes in C header files, so 
people

already know to make clean in those situations.



I'm not worried about that.  Last time I checked vapigen was an 
optional component when configuring the Vala build, so my thought was 
not to require it be installed to build our tarball.  I suspect most 
distros enable it, and if the user is installing Vala from tarball or 
git, it's not so much to ask them to go back and install it if they 
haven't already.



Of course, in a perfect world WebKit would ship a VAPI themselves, but
I'm through tilting at that particular windmill.



I hear you.


Or you could do what I suggested and just generate a VAPI, and ignore
(or disable) warnings during vapigen.  Your compilation times will
usually be lower and you will have a nice easy-to-read definition of 
the

API you're trying to use.

Let me look into this and get back to you (rather, the list) if I hit 
another snag.  If this truly works around the problem, then that's the 
best result I could ask for.


-- Jim
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] .gir and .metadata file warnings and errors

[Jim Nelson]

On Wed, Dec 11, 2013 at 3:47 PM, Evan Nemerson  
wrote:

Don't use the GIR directly.  GIRs take forever to parse anyways, why
parse it every time you run valac?  Use vapigen (without fatal 
warnings

enabled) to parse the GIR to a VAPI, then use the VAPI.



... which means we're compiling against the bindings for a particular 
version of the library.  That's not always desirable or practical.



I would love to configure different errors/warnings to do different
things (like you can with -ffoo, -fno-foo, -ffatal-foo for gcc).  This
wouldn't be particularly difficult to do with valac/libvala, it just
needs a bit of light refactoring and some easy (but time-consuming)
effort to enumerate, name, and maybe categorize every possible error.



I'd like this too.  My motivation for describing this problem is to 
suggest one large categorization of errors and warnings: how bindings 
and metadata files are being processed.


Another possibility would be for each error and warning to have a code 
or number printed with it.  A generic enable/disable flag could accept 
that code.  This gives fine-grained control without having to enumerate 
all classes of warnings or errors ahead of time.



By default the problem that vala really can't deal with
intelligently (conflicting symbol) is an error, and the one it can 
deal
with (unused metadata) is a warning, which seems quite reasonable to 
me.




With the first situation, it happens to be a symbol that valac doesn't 
have to generate code for.  From a user perspective, valac is acting as 
a kind of .gir validator here, which I'm questioning.


With the second, I would normally agree, but because bindings are 
always in flux, symbols may be added and removed with each release.  We 
now have to maintain multiple .metadata files in order to build on 
various distros.  That's why I would like to be able to disable the 
metadata warnings (which I'm not saying should be removed).


-- Jim
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

[Vala] .gir and .metadata file warnings and errors

[Jim Nelson]

We've had a lot of trouble recently with building Geary due to some 
flux with the WebKitGTK bindings and headers. Depending on the version 
of WebKitGTK we're compiling against, we get errors like this:


WebKit-3.0.gir:27733.7-27735.16: error: overriding method 
`WebKit.DOM.TextTrackCue.dispatch_event' is incompatible with base 
method `WebKit.DOM.EventTarget.dispatch_event': incompatible return 
type.


Which appears to be a problem with the WebKitGTK .gir, but causes valac 
to issue an error and exit. (Note that our code doesn't use the 
TextTrackCue class.)


We use .metadata files to get around this problem:

DOMTextTrackCue.dispatch_event type="void"

However, if the symbol is unavailable in the .gir file (this particular 
symbol was not available in earlier versions of WebKitGTK) valac issues 
this warning:


WebKit-3.0.metadata:16.1-16.16: warning: metadata never used

... which is treated as an error because we have fatal warnings enabled.

There's multiple issues here, and not all of them Vala's, but I bring 
them up because I think there may be one or two things Vala can do to 
make life easier.  I'm hoping to hear what others think before filing a 
ticket.


First, it seems that detecting an error in a .gir file shouldn't 
necessarily cause a compiler error.  The broader problem (in my mind) 
is that the .gir file was generated in the first place, but so be it.  
I think Vala should issue a warning in this situation, not an error.  
But more specifically, I would prefer Vala not issue either a warning 
or an error unless the faulty binding was causing a code generation 
problem, i.e. the symbol was actually used by the .vala code.


Second, is there any way Vala can ignore the .metadata problem, or at 
least offer a command-line switch to enable/disable the warning?  I 
would really prefer not to have to disable fatal warnings to get around 
this problem.


I think the general problem is that there should be validation tools 
that are stringent about checking (and producing) bindings and binding 
metadata, but compilers should be looser about checking unless the 
error or ambiguity is a problem for generating code.


-- Jim
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

[Vala] A suggestion for future releases

[Jim Nelson]

Geary 0.4.1 (released a little over a week ago) fails to compile with 
Vala 0.22.1. This is due to two changes in Vala:


* The libnotify binding change
* Vala 0.22.1 catches binding errors in WebKitGTK's .gir file that were 
not caught in 0.22.0.


These are documented at http://redmine.yorba.org/issues/7695 and 
http://redmine.yorba.org/issues/7694


These two issues forced us to release 0.4.2 for no other reason than to 
ensure we compile with the latest stable Vala. We had to include the 
libnotify VAPI in our tarball in order to compile with older versions.


I'd like to request that in the future changes in stable dot releases 
be more conservative in nature. Neither of the above changes seem truly 
critical to me (although perhaps they are to other projects; I'd like 
to hear why, though). The libnotify change was particularly troublesome 
because, while it fixes a memory leak, I'd be amazed if it was a real 
issue for any application. Geary calls Notify.get_server_caps() once, 
stores the result, and never calls it again.


My broad point is, dot releases for stable versions of Vala can cause 
large changes downstream. In the future, could these changes be more 
geared toward critical fixes?


-- Jim


___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Bug with cleared Gee.ArrayList

[Jim Nelson]

My bet is that it's a bounds error, i.e. you called ArrayList.get() 
with index < 0 or index >= ArrayList.size.  (Note that the [] operator 
is actually a call to the .get() method.)


-- Jim

On Mon, Nov 11, 2013 at 11:15 AM, Daniel Brendle 
 wrote:

Hi, fellow vala-people.

My project "nostril" is growing well. But again i ran into a bug that 
i

don't know how to fix.
I offer an "clear list"-feature. Which empties an ArrayList as in [0]
If i already selected an entry in the list for viewing it in detail, 
the

program crashes with an error like this:

ERROR:arraylist.c:518:gee_array_list_real_get: assertion failed: 
(_tmp1_

< _tmp2_)
Using a search-engine on that errormessage was not very effective.

My first thought was, that it happens because something that should be
rendered hits an empty or invalid reference. But according to my
debugging output the error happens _after_ the GUI-renderfunction 
passed

through.

More Strange: The User can also delete a selection of list-entries my
multi-selection. The function that does that takes a list of Entry-IDs
and processes them as in [1]. This works.

I already tried to delete every entry on its own like in [1] instead 
of
using the clear()-Method of the ArrayList. In this case the error 
still

occurs.

The full code can still be cloned an seen here [2]
I use valac-0.22

Hope someone can bring some light into the darkness here.


Thanks in advance,
Grindhold


[0] http://pastebin.com/LH8T4z30
[1] http://pastebin.com/2sFAdFX4
[2] https://github.com/grindhold/nostril


___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list


___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Tryout adding simple support for extension methods to valac

[Jim Nelson]

On Mon, Oct 14, 2013 at 12:57 PM, Luca Bruno  
wrote:

Generics are private and can't be accessed from the extern.

I'm not sure what this means.  Do you mean that the generic type is 
private and can't be accessed?


What I'd like to know is if something like this would work:

extend class Gee.ArrayList {
 public G get_center_item() {}
}

If not, that's unfortunate.

-- Jim
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Tryout adding simple support for extension methods to valac

[Jim Nelson]

I'd like to jump in and say I think this is a great proposal and hope 
this comes to fruition.


One question (for now): will this work for generic classes as well?

-- Jim

On Mon, Oct 14, 2013 at 2:09 PM, Luca Bruno  
wrote:
On Mon, Oct 14, 2013 at 7:31 PM, Philip Van Hoof 
wrote:



 Luca Bruno schreef op 14/10/2013 18:17:

  Thanks for your contribution :-)



 np. Right now it's just an experiment of course. My yearly "trying 
to

 understand vala's code" project ;)


  A couple of points:
 1) Patches/feature requests go to bugzilla, unless you want them 
to be
 forgotten and eaten by the darkness :) IIRC there's already a bug 
about

 that.


 I agree. The patch is so unfinished, however, that I don't think 
it's

 ready for official proposal yet.



Doesn't matter, a bug is still more appropriate.


 About namespacing I guess the idea would be to let the code writer 
add the

 namespace to the API, and generate C code that way?


It should resemble the original class namespacing in general, 
namespace to

namespace, class to class.




 ie.

 namespace Test {
 extend Class Object {
 public void method() {
 }
 }
 }

 Would result in a C API like:

 void test_object_method ();

 Instead of

 void object_method(); which could more easily name-clash.

 I wonder if the namespace of Object should be added?



ie. void test_g_object_method(); instead of test_object_method() ?


 For that I guess I should create a 'Object' Vala.Class in the (new)
 namespace 'Test' instead of finding GLib.Object in context.root?

 For finding what to generate during code writing, I'm guessing 
something
 similar to how subclassing works needs to be added for extended 
classes ...
 (instead of just cl.add_method and let crazy magic do its work, 
which is
 what I did now and which of course doesn't work for classes that 
aren't in

 the same .vala file).



If one wants to tweak the namespace at C level to avoid clashes, 
there are

CCode attributes for that.

For what concerns Vala AST, the method should be theoretically added 
to the

original class, as it semantically adds the method to the class from
another file. That is: class.add_method (foo). Adding a
Method.extends_class flag is enough to discriminate.
Then you get everything for free.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list


___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] shared access to sqlite database

[Jim Nelson]

To chime in some agreement, we attempted many strategies to parallelize 
transactions and work around SQLite's locking issues in Geary before 
finally waving the white flag.  Evan's correct, SQLite's built-in busy 
handler is what you want to use.  In fact, we use a single background 
thread to service all calls, as the busy handler isn't entirely fair 
when multiple threads contend for the lock.


-- Jim

On Wed, Aug 7, 2013 at 12:33 AM, Evan Nemerson  
wrote:

On Wed, 2013-08-07 at 08:16 +0200, David López González wrote:

 Hi everyone,
 
 I need to access to a single data base with diferent processes, and 
 eventually, I  always get an access error "Error: 5, database is 
locked".

 A simplified code which reproduce the problem it's presented below.

Take a look at [1].  I know unlock notify isn't what you're after 
(since

you have multiple processes, not multiple threads), but IIRC it should
give you a pretty good feel for sqlite does.

Really, the only option is to just retry the operation.  You can do 
this

automatically using sqlite3_busy_timeout ([2]).  It is bound as
Sqlite.Database.busy_timeout.

There is also sqlite3_busy_handler ([3])...  I don't think it's bound 
in

Vala at the moment, but it would be trivial to add it to the bindings
(or just use the extern keyword).  Theoretically you could use it to
iterate through the main loop or something while you wait, but it's a
lot simpler to just use busy_timeout and interact with sqlite in a
thread if you really need to.


-E

[1] https://sqlite.org/unlock_notify.html
[2] https://sqlite.org/c3ref/busy_timeout.html
[3] https://sqlite.org/c3ref/busy_handler.html

___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list


___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] memory management with structs

[Jim Nelson]

If you're using structs in Vala, be aware of this issue:

https://bugzilla.gnome.org/show_bug.cgi?id=661041

-- Jim

On Sat, May 18, 2013 at 2:41 AM, rastersoft  
wrote:

Hi all:

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


The real questions are:

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


Thanks.

--
Nos leemos
 RASTER(Linux user #228804)
ras...@rastersoft.com  http://www.rastersoft.com

___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] GSOC Idea: LLVM Backend?

[Jim Nelson]

On Tue, Apr 30, 2013 at 12:16 AM, Luca Bruno  
wrote:

Il 30/04/2013 02:15, Jim Nelson ha scritto:

https://bugzilla.gnome.org/show_bug.cgi?id=684742




‘2’

My mistake, I meant this ternary bug:
https://bugzilla.gnome.org/show_bug.cgi?id=599349

https://bugzilla.gnome.org/show_bug.cgi?id=543189


This is not going to be fixed anytime soon due to the nature of C.



Then I advocate two approaches:

(a) Let someone else investigate this problem and see if some fresh 
thinking can come up with a reasonable solution.
(b) Modify the compiler to issue an error when the compiler cannot 
generate the proper or expected code.


Maybe this can't be "fixed" in the meaning of "make it work", but that 
doesn't mean there isn't a problem.  Yorba has been burned on this bug 
numerous times.


The third one may be fixed, but when compiling Vala programs there's 
still an unacceptable number of C warnings generated by gcc.  I know, 
I know, most of these are due to const issues and can't be fixed, but I 
honestly believe that a goal of Vala should be zero-warning C code 
generator.  If GSoC student could come in and reduce the warning count 
by 10%, that's a win for the community.


As a hint, don't look toward long standing bugs with lots of 
comments, probably those are hard bugs to be fixed due to the nature 
of C.


My advice is to *gravitate* toward those bugs, as that indicates they 
are affecting a lot of projects and change would have the greatest 
impact.  As with the bug discussed above, if there truly is no way to 
solve the bug due to C, then I vote for valac emitting some kind of 
warning rather than just let the code slide through and cause bugs in 
the resulting program.


-- Jim
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] GSOC Idea: LLVM Backend?

[Jim Nelson]

Kenny,

I'm not on the Vala team, so take the following only as the opinion of 
a long-term Vala coder.


I don't find a LLVM code generator for valac to be very exciting. 
 Even if you could complete an LLVM generator this summer, I'd be 
highly hesitant to move a project like Shotwell or Geary to it until it 
had had a lot of time to mature.


I have to echo a comment pancake makes elsewhere about Vala's stability 
compared to its age.  My complaints about the compiler are not about 
the way it generates code, but rather the problems it has trying to do 
it.  For example:


https://bugzilla.gnome.org/show_bug.cgi?id=684742
https://bugzilla.gnome.org/show_bug.cgi?id=543189

and this one, which could be a GSoC project unto itself: 
https://bugzilla.gnome.org/show_bug.cgi?id=609901


I would love it if you spent a little time examining the Vala Bugzilla 
list and came up with a list of tickets you'd like to attack.  As GSoC 
would like for this to be a project of some kind, I suggest framing it 
as improving the Vala compiler.  Not only does this have high value 
for the community today, but taking this approach means your 
improvements can be submitted in chunks and are therefore more likely 
to land in master.


-- Jim

On Sun, Apr 28, 2013 at 9:13 PM, Kenny Micklas  
wrote:

Hi all,

I am a student at Brown University interested in participating in 
Google
Summer of Code. I am a Vala enthusiast and I have always been 
interested in

the idea of writing an LLVM code generator for valac. The principle
benefits of this would be decoupling Vala from C, increased 
flexibility in
the generated code, vastly better compile times, and potentially 
better

runtime performance too.

I know this is not one of the suggested GSOC ideas for GNOME, but I 
was
wondering if the Vala team would think this is a good project, and 
whether
or not there would be an appropriate mentor. If so, I will write up a 
full

proposal for GSOC.

Thanks,
Ken Micklas
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list


___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] How track memory leaks ?

[Jim Nelson]

This is a problem we faced in Geary.  We went several directions 
before adding this, which helped immensely:


http://redmine.yorba.org/projects/geary/repository/revisions/master/entry/src/engine/api/geary-base-object.vala

Note that this approach is of limited utility, as it requires *all* 
your project's classes to inherit from it in order to get reference 
tracking.  However, it did help us track down a couple of memory leaks 
that would've been a bear to find otherwise.


May not be right for you, but perhaps it gives you ideas as well.

-- Jim

On Mon, Mar 18, 2013 at 7:32 AM, r...@no-log.org wrote:

Hello,

I wondered if it 's possible to recover memory information or memory 
leaks

 other than "mem_set_vtable(mem_profiler_table);" and without using a
third party software like valgrind ?

Thanks

Raum


___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list


___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Call default mail app (like evolution) from a Vala/Gtk+ app

[Jim Nelson]

I would think Gtk.show_uri() or AppInfo.launch_default_for_uri() would 
do the trick.


-- Jim

On Wed, Feb 27, 2013 at 5:39 PM, jezra  wrote:
Hello, 
I do not have a default email program, but the following code may 
work 
for you. It calls a command line tool to launch email. 



public static void main() { 

string subject = "Hello World"; 
string body = "Greetings World, it is nice to meet you"; 
string address = "exam...@example.com"; 
//build a command from the data 
string command = @"xdg-email --subject '$subject' --body '$body' 
$address"; 
stdout.printf(@"$command\n"); 
//run the command 
try { 
Process.spawn_command_line_async( command ); 
} catch(SpawnError err) { 
stdout.printf(err.message+"\n"); 
} 
} 



On Wed, 27 Feb 2013 22:07:44 -0300 
Andres Fernandez wrote: 

> Hello, I'm trying to find how to call the window to write a mail of 
> the default mail app, with a predefined subject and a predefined 
text 
> in the body of the mail. 
> 
> Is it possible? 
> 
> My English is quite limited do I don't know if it is clear. 
> 
> Thanks! 
> 
> __ 

_ 
> vala-list mailing list 
> vala-list@gnome.org 
> https://mail.gnome.org/mailman/listinfo/vala-list 

___ 
vala-list mailing list 
vala-list@gnome.org 
https://mail.gnome.org/mailman/listinfo/vala-list 


___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] [Announce] Repository for third-party Vala bindings

[Jim Nelson]

Hi Evan,

Is there any thought that this repo might be a staging ground for migrating 
VAPIs into Vala distribution?

Also, will there be packaging efforts to get these out into the distros?

-- Jim

On Fri, Feb 22, 2013 at 3:41 AM, Evan Nemerson  wrote:
I've created a repository on GitHub ("vala-extra-vapis" [1]) to house 
our external VAPIs. 

This repository has a very low barrier for entry. Unlike the bindings 
distributed with valac, I don't plan to provide much review or 
oversight. Basically, the only requirement for getting bindings into 
the repository is an open source license (preferable MIT or a similarly 
permissive license). 

vala-extra-vapis is designed to be used as a git submodule, and it will 
only contain *.vapi and *.deps files (as well as the README). All 
tests, examples, documentation, and other supplemental information will 
go in a second repository, "vala-extra-vapis-supplemental" [2] (yes, I'm 
aware the name seems both repetitive and redundant). I'm still working 
on getting the infrastructure in place to automatically run the tests 
and generate documentation, but that should happen soon. 

If you have created bindings for libraries which are not being 
distributed with the library they bind (or with valac), I hope you'll 
consider submitting them for inclusion in vala-extra-vapis through the 
issue tracker on GitHub. 

Just to be clear, I still prefer that bindings be distributed with the 
library they bind when possible (see [3]). However, I hope this will 
provide an easier alternative to trying to get them distributed with 
valac. 


-Evan 

[1] https://github.com/nemequ/vala-extra-vapis 
[2] https://github.com/nemequ/vala-extra-vapis-supplemental 
[3] http://live.gnome.org/Vala/UpstreamGuide 
___ 
vala-list mailing list 
vala-list@gnome.org 
https://mail.gnome.org/mailman/listinfo/vala-list 
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] delegates in vala

[Jim Nelson]

Although the compiler messages have changed, there is a long-standing bug with 
delegates and the ternary operator: 
https://bugzilla.gnome.org/show_bug.cgi?id=599349

-- Jim

On Wed, Feb 13, 2013 at 11:48 AM, Albert Hopkins  wrote:


On Wed, Feb 13, 2013, at 01:49 PM, Albert Hopkins wrote: 
[...] 
> MyDel del; 
> ... 
> del = randValue > 50 ? program.PrintLow : program.PrintHigh; 
> 
> However this gives me a compile error: 
> 
> delegate.vala:21.32-21.47: error: Assignment: Cannot convert from 
> `Program.PrintLow' to `Program.PrintLow' 
> del = randValue < 50 ? program.PrintLow : program.PrintHigh; 
>  
> delegate.vala:21.51-21.67: error: Assignment: Cannot convert from 
> `Program.PrintHigh' to `Program.PrintHigh' 
> del = randValue < 50 ? program.PrintLow : program.PrintHigh; 
> ^ 
> delegate.vala:21.15-21.28: error: Incompatible expressions 
> del = randValue < 50 ? program.PrintLow : program.PrintHigh; 
> ^^ 
> Compilation failed: 3 error(s), 0 warning(s) 

This works: 

(randValue < 50)? del = Program.PrintLow: del = Program.PrintHigh; 

Although I would like to understand better why the former does not. 

-a 
___ 
vala-list mailing list 
vala-list@gnome.org 
https://mail.gnome.org/mailman/listinfo/vala-list 

___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Bug in async methods?

[Jim Nelson]

I think you would need to work with the Vala team to get something like this 
landed.  Part of the solution might be to look at the other back-ends that Vala 
supports (i.e. Posix), although I think those are kept in a separate branch and 
not supported in the main distribution.

However, I suspect you're trying to do something specific for your project, and 
it's best if you built a custom system for doing these async operations.  You 
might be able to package it up into a separate library, if it's generic enough.

-- Jim

On Mon, Oct 22, 2012 at 4:15 PM, rastersoft  wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I've been watching the source code generated by Vala and the key is here:

    _data_->result = 1;
    if (_data_->_state_ == 0) {
    g_simple_async_result_complete_in_idle (_data_->_async_result);
    } else {
    g_simple_async_result_complete (_data_->_async_result);
    }

What do you think about a decorator or something similar to allow to use async 
functions without main loop, just using always g_simple_async_result_complete() 
in those cases?

I ask this because I'm using Vala to do simulations, using an architecture 
similar to SimPy (this is, based on async methods) and it would be much more 
convenient to be able to work that way in those cases.

El 23/10/12 00:22, Jim Nelson escribió:
> It would take me a bit of time
  to explain async (I've thought about blogging about it), but the
  short answer is: Vala's async and yield keywords are designed to
  use MainLoop to schedule code execution.

  >

  > You don't *have* to use them to do asynchronous work, but
  they are certainly convenient.

  >

  > -- Jim

  >

  > On Mon, Oct 22, 2012 at 3:19 PM, rastersoft
   wrote:

  >

  > Yes, you are right: I created a main loop, called run(), and
  the callback got called.

  >

  > Anyway, I don't understand why is not possible to ensure that
  the end callback gets called even without a main loop :?

  >

  > Thanks!

  >

  > El 23/10/12 00:03, Jim Nelson escribió:

  > > For async to work properly, you

  > must run the GLib MainLoop. MainLoop is where your async
  closure

  > for test_function.begin() is called. It's where all callbacks
  are

  > scheduled, actually.

  >

  >

  >

  > > The only reason this works is that in the case of
  DO_YIELD

  > you stash the test_function.callback and then call it back.
  That's

  > why you're seeing "End callback called 1".

  >

  >

  >

  > > A better way to do this is to (a) get rid of
  ext_callback and

  > (b) call "new GLib.MainLoop().run()" right before the "return
  0"

  > in main(). Without actually modifying the code (i.e. I'm
  doing

  > this off the top of my head), that should work.

  >

  >

  >

  > > -- Jim

  >

  >

  >

  > > On Mon, Oct 22, 2012 at 2:47 PM, rastersoft

  >  wrote:

  >

  >

  >

  > > Hi all:

  >

  >

  >

  > > I was working with async methods, and found something
  odd: if

  > I call an

  >

  > > async method, but, for whatever reason, I never call
  YIELD

  > inside, the

  >

  > > end callback function is never called.

  >

  >

  >

  > > I attach an example: by compiling it with

  >

  >

  >

  > > valac -D DO_YIELD -o test_async test_async.vala
  --pkg=gio-2.0

  >

  >

  >

  > > will do a YIELD inside the async function. But when
  compiled

  > with

  >

  >

  >

  > > valac -o test_async test_async.vala --pkg=gio-2.0

  >

  >

  >

  > > will not. In the former case you can see how "End
  callback

  > called 1" is

  >

  > > printed, because the callback for the end is called; but
  in

  > the later,

  >

  > > it's not printed.

  >

  >

  >

  > > Is that a bug? If not, why does it work that way?

  >

  >

  >

  > > Thanks.

  >

  >

  >

  >

  >

  >

  >

  >

  >

  >

  >

  >

- -- 
Nos leemos
 RASTER    (Linux user #228804)
ras...@rastersoft.com  http://www.rastersoft.com

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlCF06UACgkQXEZvyfy1ha/LHwCfZyN6VrCTRoBo+qj/F5ueyCM1
9MMAoM/a1bpZviM5ktwhpPRCHJKtSToL
=62sR
-END PGP SIGNATURE-


___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Bug in async methods?

[Jim Nelson]

It would take me a bit of time to explain async (I've thought about blogging 
about it), but the short answer is: Vala's async and yield keywords are 
designed to use MainLoop to schedule code execution.

You don't *have* to use them to do asynchronous work, but they are certainly 
convenient.

-- Jim

On Mon, Oct 22, 2012 at 3:19 PM, rastersoft  wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Yes, you are right: I created a main loop, called run(), and the callback got 
called.

Anyway, I don't understand why is not possible to ensure that the end callback 
gets called even without a main loop :?

Thanks!

El 23/10/12 00:03, Jim Nelson escribió:
> For async to work properly, you
  must run the GLib MainLoop. MainLoop is where your async closure
  for test_function.begin() is called. It's where all callbacks are
  scheduled, actually.

  >

  > The only reason this works is that in the case of DO_YIELD
  you stash the test_function.callback and then call it back. That's
  why you're seeing "End callback called 1".

  >

  > A better way to do this is to (a) get rid of ext_callback and
  (b) call "new GLib.MainLoop().run()" right before the "return 0"
  in main(). Without actually modifying the code (i.e. I'm doing
  this off the top of my head), that should work.

  >

  > -- Jim

  >

  > On Mon, Oct 22, 2012 at 2:47 PM, rastersoft
   wrote:

  >

  > Hi all:

  >

  > I was working with async methods, and found something odd: if
  I call an

  > async method, but, for whatever reason, I never call YIELD
  inside, the

  > end callback function is never called.

  >

  > I attach an example: by compiling it with

  >

  > valac -D DO_YIELD -o test_async test_async.vala --pkg=gio-2.0

  >

  > will do a YIELD inside the async function. But when compiled
  with

  >

  > valac -o test_async test_async.vala --pkg=gio-2.0

  >

  > will not. In the former case you can see how "End callback
  called 1" is

  > printed, because the callback for the end is called; but in
  the later,

  > it's not printed.

  >

  > Is that a bug? If not, why does it work that way?

  >

  > Thanks.

  >

  >

  >

  >

- -- 
Nos leemos
 RASTER    (Linux user #228804)
ras...@rastersoft.com  http://www.rastersoft.com

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlCFxngACgkQXEZvyfy1ha/qbgCdEaOkBSyLpQFLgnldBkpo2v4C
FlIAnRy2zdJBUIgC5IfgXbvKEcGg8wAv
=OnLX
-END PGP SIGNATURE-


___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Bug in async methods?

[Jim Nelson]

For async to work properly, you must run the GLib MainLoop.  MainLoop is where 
your async closure for test_function.begin() is called.  It's where all 
callbacks are scheduled, actually.

The only reason this works is that in the case of DO_YIELD you stash the 
test_function.callback and then call it back.  That's why you're seeing "End 
callback called 1".

A better way to do this is to (a) get rid of ext_callback and (b) call "new 
GLib.MainLoop().run()" right before the "return 0" in main().  Without actually 
modifying the code (i.e. I'm doing this off the top of my head), that should 
work.

-- Jim

On Mon, Oct 22, 2012 at 2:47 PM, rastersoft  wrote:

-BEGIN PGP SIGNED MESSAGE- 
Hash: SHA1 

Hi all: 

I was working with async methods, and found something odd: if I call an 
async method, but, for whatever reason, I never call YIELD inside, the 
end callback function is never called. 

I attach an example: by compiling it with 

valac -D DO_YIELD -o test_async test_async.vala --pkg=gio-2.0 

will do a YIELD inside the async function. But when compiled with 

valac -o test_async test_async.vala --pkg=gio-2.0 

will not. In the former case you can see how "End callback called 1" is 
printed, because the callback for the end is called; but in the later, 
it's not printed. 

Is that a bug? If not, why does it work that way? 

Thanks. 

- -- 
Nos leemos 
RASTER (Linux user #228804) 
ras...@rastersoft.com http://www.rastersoft.com 

-BEGIN PGP SIGNATURE- 
Version: GnuPG v1.4.11 (GNU/Linux) 
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ 

iEYEARECAAYFAlCFvwEACgkQXEZvyfy1ha/m+QCfQzIoKObEBhWIO8mwCPtbjBNI
9I8AoJ2kNDrIRYqRsHFCk4sb6eN/pPyC 
=yUo1 
-END PGP SIGNATURE- 


___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Unit Testing in Vala

[Jim Nelson]

On Fri, Oct 19, 2012 at 12:49 PM, Steven Oliver  wrote:
I am sorry if I made it sound like you guys had done something wrong. That was 
not my intention!

No problem.  No offense was taken.

Is there a reason you're not currently using it, even if you aren't further 
developing it?

Unit testing never became a part of the Yorba methodology.  I know that's 
controversial to some, but with our resources, we've elected to keep them on 
features and bug fixes.  I do think it's something we're going to pursue 
(gradually) in the case of Geary, as it has to interoperate with such a variety 
of mail servers and services, it's important we know we haven't broke something.

-- Jim___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Unit Testing in Vala

[Jim Nelson]

For the record, Yorba attempted to contact the original developer of Valadate 
and received no response.  We had some testing needs awhile back, and so we 
forked.  The work we did was not to add features, but merely to rip things out 
to get it to compile with the then-current version of Vala.

You are correct, we're not currently using or developing Valadate.  We would 
like it if someone stepped up to take over the project.  The code is most 
likely suffering from bit rot and could use some attention.  Unfortunately, we 
have our hands full with other projects and can't spend the time it would take.

-- Jim

On Fri, Oct 19, 2012 at 6:49 AM, Steven Oliver  wrote:
There are a couple of unit testing frameworks out there for Vala. I know 
there a multitude of frameworks people have written themselves for 
themselves that aren't really published as stand alone projects. Given that 
I'd like to start putting some testing in a project I'm working on and I 
had a few questions for the audience. 

It appears to me that Valadate is the most "mature" testing platform out 
there. I've noticed it's "hosted" on Gitorious but it appears that Yorba 
has cloned it on their server and have made updates to it that never made 
it back to Gitorious. It also appears that despite hosting Valadate Yorba 
doesn't actually use it. * puzzled * 

Is there anything else out there worth looking at? Or at lest ones that 
have seen updates in the past 2 years? And finally, what is everyone doing 
for unit testing? It appears to be something a lot of projects don't really 
do anymore. 

Steven N. Oliver 

___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] How to get return values from async methods

[Jim Nelson]

I guess the way I would think of it is, the closure is when you get the results 
from the async method.  The appropriate way to deliver those results to others 
depends on who they are.  The ideas you tossed out all make sense, but which 
one to use is situational.

-- Jim

On Wed, Oct 17, 2012 at 1:45 PM, tomw  wrote:
On Mi, 2012-10-17 at 20:26 -0007, Jim Nelson wrote: 
> Yes, your closure isn't being called until some time after 
> get_results() returns. 
> 
> 
> Remember, async works with the event loop. A good way to think of it 
> is like this: some_async_method.begin() doesn't call the method, 
> rather .begin schedules the method on the event loop for later 
> execution. (This is technically not true, some code in 
> some_async_method() may be executed immediately, but in my experience 
> thinking of it as being scheduled is the safest way to code async in 
> Vala.) 

Thanks, Jim, 
So, the only way to get some return values from async methods would be 
to either issue a signal from within the closure, passing the result or 
to register a callback instead of the closure, right? 

br, 

-- 
tomw 


___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] How to get return values from async methods

[Jim Nelson]

Yes, your closure isn't being called until some time after get_results() 
returns.

Remember, async works with the event loop.  A good way to think of it is like 
this: some_async_method.begin() doesn't call the method, rather .begin 
schedules the method on the event loop for later execution.  (This is 
technically not true, some code in some_async_method() may be executed 
immediately, but in my experience thinking of it as being scheduled is the 
safest way to code async in Vala.)

-- Jim

On Wed, Oct 17, 2012 at 8:17 AM, tomw  wrote:
Hi folks, 

I was struggling a bit with the right approach to get return values from 
async methods if called from a sync method. The approach would be to 
register a callback in a closure like: 

public string [] get_results () { 
string [] results = {}; 
some_async_method.begin (parameters, (obj, res) => { 
results = some_async_method.end (res); 
}); 

return results; 
} 

as obviously some_async_method is not finished yet, I'm getting an empty 
results array. 
How do I make sure that the results are properly returned after the the 
async method has finished? 

thanks, 

-- 
tomw 

___ 
vala-list mailing list 
vala-list@gnome.org 
https://mail.gnome.org/mailman/listinfo/vala-list 

___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] .typelib support in Vala

[Jim Nelson]

On Thu, Aug 30, 2012 at 4:52 PM, Evan Nemerson  wrote:
Assuming you're talking about GLib, GObject, and Gio, Debian/Ubuntu 
already distribute the relevant GIRs. They're in 
libgirepository1.0-dev.

I figured that out five minutes ago.  Thanks.  B-)

Sorry, what I wrote is /really/ misleading. valac still requires the 
GIRs to be present. valac will still /start/ parsing the GIR. Once it 
gets to a element (which tells us what pkg-config package 
corresponds to that GIR) valac will look to see if that package has 
already been provided and, if so, skip the rest of the GIR. 

I see.  That makes sense.

It looks like the package has some other problems (both in its .gir and its 
packaging itself), so I'll work with Ubuntu to sand down the rough edges and 
wrap this up.

Cheers,

-- Jim

___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] .typelib support in Vala

[Jim Nelson]

Thanks for the quick reply, Evan.  To answer some of your questions:

Evan Nemerson  wrote:
Sometimes you may have to install an extra package, but the GIRs should 
be available. 

I'll probably open a ticket with Ubuntu about this.

You should pass the pkg-config names of whatever dependencies you need 
to valac. valac will parse those VAPIs first, and there is an 
annotation which will tell valac what GIR namespace the Vala namespace 
corresponds to.

At first I thought you'd figured it out, but I'm still seeing the problem.  The 
.gir file in question has these annotations inside it:





To see my problem, rename GLib-2.0.gir.  I use a simple Vala program (Vala 
0.17.5 installed):

void main() {
}

If I build like this, no problem:

valac test.vala --pkg=glib-2.0 --pkg=gobject-2.0 --pkg=gio-2.0

If I build like this, I get the error messages I mentioned earlier:

valac test.vala --pkg=glib-2.0 --pkg=gobject-2.0 --pkg=gio-2.0 
--pkg=DBusGLib-1.0

I do see the VAPI annotations in the glib-2.0.vapi file (and the others), but 
it looks like valac isn't properly making the connection you mentioned.

-- Jim___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

[Vala] .typelib support in Vala

[Jim Nelson]

Last year there was some discussion on the list about Vala's .gir support 
(https://mail.gnome.org/archives/vala-list/2011-April/msg3.html).  Jürg 
said that Vala only reads the XML (.gir files) and not the .typelib files.

My question is, how should a developer deal with a situation where a library 
distributes a .gir (usable by valac) but the .gir references a namespace that's 
only available as a .typelib.  Because the .gir naming convention is CamelCase 
and not the same as Vala's lower-and-dashes, valac can't even find the VAPI and 
compilation fails.  In my case, I'm seeing this:

error: Package `GLib-2.0' not found in specified Vala API directories or 
GObject-Introspection GIR directories
error: Package `GObject-2.0' not found in specified Vala API directories or 
GObject-Introspection GIR directories
error: Package `Gio-2.0' not found in specified Vala API directories or 
GObject-Introspection GIR directories

There is a workaround: I can create hard links for the VAPIs (glib-2.0.vapi -> 
GLib-2.0.vapi, etc.), but I can't expect our users to do the same when they 
build our tarball.

-- Jim___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Implement abstract interface method in interface

[Jim Nelson]

The problem you brought up is the one area of interfaces that I didn't 
investigate more thoroughly when I was writing that blog post.  I always wanted 
to go back and figure out what was going on, but never did.

Vala probably could automate some of this, but I'm not sure.  If you think 
about it, that's a big reason for Vala's existence: to automate generating 
GObject code.  Perhaps Jürg or Luca could chime in and discuss the issue.

-- Jim

On Mon, Aug 27, 2012 at 12:13 AM, Thomas Jollans  wrote:
Hi Jim, 

First of all, that looks like a good blog post. I'll have to take the 
time to actually read it later today. 

Giving this some further thought - (judging from Vala-generated C code) 
GObject interfaces are basically just jump tables that are populated in 
interface initialization functions, named 
[class]_[interface]_interface_init() by Valac. There is no built-in 
automatism, at least none that's used by Valac, so it seams to me that 
Valac *could* look for missing methods in other interfaces and 
automatically generate wrapper functions (or simply set the function 
pointers accordingly, assuming the types are right? I'm not sure about this) 

It looks like GObject in principle supports the rather ugly case of a 
class implementing two interfaces with methods of the same name but with 
differing signatures. Vala doesn't handle this case very well as far as 
I can see; it certainly doesn't throw an error or print a warning in the 
face of such ambiguity - there's no way to specify which method is 
supposed to be implemented if it's not obvious, is there? There may be a 
need for some more checks in the compiler, and maybe some additional 
annotations. 

Cheers 
Thomas 

On 27/08/12 04:18, Jim Nelson wrote: 
> Your problem lies here: 
> 
>> interface IBar : IFoo 
>> { 
>> public virtual void bar () 
>> { 
>> } 
>> } 
> 
> Because IBar is an interface, it doesn't inherit from IFoo. Rather, in 
> Vala that syntax means whatever class implements IBar's interface must 
> also implement IFoo (or, IFoo is a prerequisite interface for IBar). 
> For whatever reason, although interfaces may implement code, in Vala an 
> interface cannot implement a prerequisite's methods. 
> 
> I don't know the exact reason why. I suspect it's a limitation of 
> GObject and not Vala. 
> 
> I discuss interfaces on the Yorba blog: 
> http://blog.yorba.org/jim/2011/11/a-few-of-my-favorite-vala-things-interface.html
>  
> 
> -- Jim 


___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Implement abstract interface method in interface

[Jim Nelson]

Your problem lies here:

interface IBar : IFoo 
{ 
public virtual void bar () 
{ 
} 
} 

Because IBar is an interface, it doesn't inherit from IFoo.  Rather, in Vala 
that syntax means whatever class implements IBar's interface must also 
implement IFoo (or, IFoo is a prerequisite interface for IBar).  For whatever 
reason, although interfaces may implement code, in Vala an interface cannot 
implement a prerequisite's methods.

I don't know the exact reason why.  I suspect it's a limitation of GObject and 
not Vala.

I discuss interfaces on the Yorba blog: 
http://blog.yorba.org/jim/2011/11/a-few-of-my-favorite-vala-things-interface.html

-- Jim___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] sqlheavy?

[Jim Nelson]

Let me explain the situation with Geary and SQLHeavy.  The ticket Eric
referred to earlier does not fully describe our issues.  (Warning:
this is *long*.)

First, I have to correct what Eric said earlier.  It's not that
SQLHeavy isn't up-to-date, rather, the features Geary most heavily
relies upon are not as well- or fully-implemented as we need.
Specifically, the Geary engine is a fully asynchronous library
designed to handle multiple requests at once.  Virtually all our
interaction with SQLHeavy is through its asynchronous interfaces.
That was the strongest motivation toward using it rather than coding
directly to SQLite.  However, during development we discovered serious
flaws in SQLHeavy's async implementation.

But Evan's right, as far as using it as a direct replacement for
SQLite, it seems as full-featured as one would want it to be.  Perhaps
the ORM stuff isn't up to snuff, as Evan said, so people wanting to
adopt SQLHeavy should consider that.  I would also examine the bug
database (found at http://code.google.com/p/sqlheavy/issues/list)
before jumping in with both feet.

What's motivating our decision to move away from SQLHeavy are the following:

* Each asynchronous operation creates and destroys a thread:
http://code.google.com/p/sqlheavy/issues/detail?id=11

When I say operation, I don't mean transaction, I mean each
*operation*.  Thus, if your QueryResult has 50 items in its set, 50
threads are created and destroyed while iterating the result.  1000
items, 1000 threads.  This is a major performance hit, especially at
startup, as Geary does a lot of database work while connecting to the
server.  It's painful to run Geary under gdb because of this problem.
Every time I go into Geary to tune or optimize, this problem is in the
mix affecting performance.

I reported this bug a year ago, almost to the day.

* Async transactions aren't asynchronous:
http://code.google.com/p/sqlheavy/issues/detail?id=12

This was almost a showstopper for us.  Without diving in too deep to
the mechanics of this one, Geary uses transactions throughout its
database layer to guarantee atomicity.  SQLHeavy's async transactions
can't make that guarantee.  I didn't discover this until gobs of
database code had already been written.  The only short-term solution
I could find meant, in essence, there's a master lock on Geary's
database that guarantees only one block of async code may perform
operations at a time.  In other words, we're serializing database
access.  It's an ugly hack, but I coded it thinking the problem would
be solved shortly, at which time I could rip it out.

This bug is also almost a year old.

* Cancelling an async operation doesn't cancel the scheduled thread:
http://code.google.com/p/sqlheavy/issues/detail?id=17
* Use IOError.CANCELLED: http://code.google.com/p/sqlheavy/issues/detail?id=18
* QueryResult.finished doesn't respect Cancellable:
http://code.google.com/p/sqlheavy/issues/detail?id=19
* next_async() can segfault if cancelled:
http://code.google.com/p/sqlheavy/issues/detail?id=20

These are related in an oblique way.  The first one hurts performance
because there might be a lot of I/O against the database when the user
switches Folders, causing all of it to be cancelled at once.  Because
the scheduled threads are not cancelled, the fresh, relevant I/O the
user has requested is queued up waiting for all those threads ahead of
it to die.

The second bug is not as serious, but it means that callers to the
Geary engine had to do special-case checking for two different types
of exceptions rather than one (since CANCELLED is ok if the caller
did, indeed, cancel the operation).  I had to work around this to
convert SQLHeavy's INTERRUPTED error to CANCELLED.  This check has to
happen throughout Geary's database code.

The third and fourth required checking Cancellable.is_cancelled()
everywhere in our database code.  Again, a utility method that must be
called from a lot of places.

These three problems required me to go into our database layer and add
a lot of special checking to correct and work around them.  These were
reported 6 to 8 months ago.

* VersionedDatabase upgrade scripts don't run:
http://code.google.com/p/sqlheavy/issues/detail?id=21

This is one of those features I was really excited about, so I was
pretty disappointed when it didn't work.  In Shotwell, we do all our
database upgrades through manual code.  I thought it was a great idea
to handle it all through SQL scripts.  But it looks like an internal
SQLHeavy lock prevents the upgrade scripts from running, causing the
app to hang at startup.

We worked around this by implementing our own upgrade path.

I want to make it clear: Evan is fulfilling a major need in the GNOME
community with SQLHeavy.  The alternative (GNOME-DB) is unpalatable
for an app that needs an in-proc database and knows it's going to use
SQLite.  He's done a ton of work and I think it's a solid foundation
for the future.

I also don't think Evan's "responsible" to 

Re: [Vala] [ANNOUNCE] Vala 0.17.1 - Compiler for the GObject type system

[Jim Nelson]

On Sat, Jun 2, 2012 at 9:46 AM, Jürg Billeter  wrote:
* Add --enable-gobject-tracing commandline option. 


Is there any documentation to explain what GObject tracing is and how to use it?

-- Jim___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] [PATCH] enum: foreach capability

[Jim Nelson]

I too would like to see this.  Maybe Team Vala could take a look at the
patch and comment?

https://bugzilla.gnome.org/show_bug.cgi?id=624691

(Sebastian, I'm assuming the patch you attached to the above ticket is your
latest code.)

-- Jim

On Fri, Mar 23, 2012 at 8:53 PM, Sebastian Reichel  wrote:

> On Fri, Feb 24, 2012 at 05:46:17PM +0100, Sebastian Reichel wrote:
> > Please consider applying the attached patch. It adds support for
> > using foreach with enums like this (and closes #624691):
> >
> > > foreach (Enum e in Enum.all_values) {
> > > stdout.printf ("%s\n", e.to_string ());
> > > }
>
> ping? Is there really no interest in having this in vala? It's quite
> useful to fill e.g. Gtk.Combobox with values from the enum.
>
> -- Sebastian
>
> ___
> 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] Safe call operator

[Jim Nelson]

I was going to mention that as well.  Null handling in Java is not
analogous to Vala's strategy, if for no other reason than there's no NPE.

It looks to me the idea of a future Vala that emphasizes code correctness
is that it will catch things like this:

Xyxxy? x = get_xyzzy();
int result = x.foo();

The compiler will flag that last line as problematic.  I think it will, at
least.  I don't really know.  But it seems to me that if null-checking is
going to be enforced by the compiler, it's not too much to ask the language
to supply good tools for doing that checking.  The nullable operator is one
step in that direction, but I've coded many lines where I needed something
like the Elvis operator (and the associated operators suggested by Project
Coin).

I'll also point out that (according to the Project Coin page) the reason
the null-safety operators were turned down by the Java committee was that
the Checker framework was added to Java and that Groovy, the inspiration
for the proposed syntax, uses dynamic typing, which makes the operators
more flexible.  But the first is not going to happen for Vala (I've not
heard of any such framework) and the second could be made to argue against
the nullable operator, which was, in fact, added to Vala.

I think the Elvis operator (and its cousins) should get real consideration
and not be dismissed merely because Java didn't take them.

-- Jim



On Tue, Jan 31, 2012 at 7:27 AM, Artem Tarasov wrote:

> > As a starter, Java rejected that syntax.
>
> Yeah, but in Java at least a NullPointerException is thrown when null
> dereferencing occurs. In Vala the only option to provide null-safety
> is explicit checking for null after each method call in a chain.
> ___
> 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] Why is my menubar not showing up?

[Jim Nelson]

Weird.  I guess it could be a version problem, but it's not like your code
does anything that's out of the blue.  As I said, I see the File menu and
the Quit item and it works fine.

I'm using Fedora 15.  What distro and you on and what version of GTK?

-- Jim

On Fri, Jul 29, 2011 at 12:43 PM, Fred van Zwieten wrote:

> Could this be a version / library / bnidings problem?
>
> Greetz,
> Fred
>
>
>
> 2011/7/29 Fred van Zwieten :
> > Hi,
> >
> > I am seeing absolutely nothing. A white empty window 600x600. No menu in
> sight.
> >
> > About the gtk issue. Well, there is vala code and gtk code, so i'm not
> > sure what causes it. But great you wanna help out anyways.
> >
> > Greetz,
> > Fred
> >
> >
> >
> > 2011/7/29 Jim Nelson :
> >> I built it that way.  I see the window and the menu bar.
> >>
> >> Maybe you should tell me what you're seeing and how that's different
> than
> >> what you expect to see.
> >>
> >> I should also add that this is technically a GTK problem, not a Vala
> issue,
> >> so I'm answering off-list.
> >>
> >> -- Jim
> >>
> >> On Fri, Jul 29, 2011 at 12:32 PM, Fred van Zwieten  >
> >> wrote:
> >>>
> >>> valac --pkg gtk+-2.0 menusystem.vala
> >>>
> >>> Greetz,
> >>> Fred
> >>>
> >>>
> >>>
> >>> 2011/7/29 Jim Nelson :
> >>> > It works for me.  Are you sure you're building it correctly?
> >>> >
> >>> > -- Jim
> >>> >
> >>> > On Fri, Jul 29, 2011 at 12:26 PM, Fred van Zwieten <
> fvzwie...@gmail.com>
> >>> > wrote:
> >>> >>
> >>> >> Yes,
> >>> >>
> >>> >> Sorry, that was the first try, of course, but that also doesn't
> work.
> >>> >> Code:
> >>> >>
> >>> >> using Gtk;
> >>> >>
> >>> >> class menusystem : Gtk.Window
> >>> >> {
> >>> >>public menusystem ()
> >>> >>{
> >>> >>this.title = "Menu System Demo";
> >>> >>this.destroy.connect (Gtk.main_quit);
> >>> >>set_default_size (600, 600);
> >>> >>
> >>> >>var menubar = new MenuBar();
> >>> >>var file_menu = new Menu();
> >>> >>var quit_item=new MenuItem.with_mnemonic("_Quit");
> >>> >>file_menu.append(quit_item);
> >>> >>quit_item.activate.connect(Gtk.main_quit);
> >>> >>var file_launcher=new MenuItem.with_mnemonic("_File");
> >>> >>file_launcher.set_submenu(file_menu);
> >>> >>menubar.append(file_launcher);
> >>> >>
> >>> >>var vbox = new VBox (false, 0);
> >>> >>vbox.pack_start (menubar,false,false,0);
> >>> >>add (vbox);
> >>> >>}
> >>> >>
> >>> >>static int main (string[] args)
> >>> >>{
> >>> >>Gtk.init (ref args);
> >>> >>
> >>> >>var mymenu = new menusystem ();
> >>> >>mymenu.show_all();
> >>> >>
> >>> >>Gtk.main ();
> >>> >>
> >>> >>return 0;
> >>> >>}
> >>> >> }
> >>> >>
> >>> >>
> >>> >> Greetz,
> >>> >> Fred
> >>> >>
> >>> >>
> >>> >>
> >>> >> 2011/7/29 Iven Hsu :
> >>> >> > I think you should add(vbox), instead of add(menubar).
> >>> >> >
> >>> >> > 2011/7/30 Fred van Zwieten 
> >>> >> >>
> >>> >> >> Hi.
> >>> >> >>
> >>> >> >> I try to make a menubar, taking examples from vala toolbar demo
> and
> >>> >> >> a
> >>> >> >> pygtk tutorial. I have this sample code:
> >>> >> >>
> >>> >> >> using Gtk;
> >>> >> >>
> >>> >> >> class menusy

Re: [Vala] Why is my menubar not showing up?

[Jim Nelson]

It works for me.  Are you sure you're building it correctly?

-- Jim

On Fri, Jul 29, 2011 at 12:26 PM, Fred van Zwieten wrote:

> Yes,
>
> Sorry, that was the first try, of course, but that also doesn't work. Code:
>
> using Gtk;
>
> class menusystem : Gtk.Window
> {
>public menusystem ()
>{
>this.title = "Menu System Demo";
>this.destroy.connect (Gtk.main_quit);
>set_default_size (600, 600);
>
>var menubar = new MenuBar();
>var file_menu = new Menu();
>var quit_item=new MenuItem.with_mnemonic("_Quit");
>file_menu.append(quit_item);
>quit_item.activate.connect(Gtk.main_quit);
>var file_launcher=new MenuItem.with_mnemonic("_File");
>file_launcher.set_submenu(file_menu);
>menubar.append(file_launcher);
>
>var vbox = new VBox (false, 0);
>vbox.pack_start (menubar,false,false,0);
> add (vbox);
> }
>
>static int main (string[] args)
>{
>Gtk.init (ref args);
>
>var mymenu = new menusystem ();
>mymenu.show_all();
>
>Gtk.main ();
>
>return 0;
>}
> }
>
>
> Greetz,
> Fred
>
>
>
> 2011/7/29 Iven Hsu :
> > I think you should add(vbox), instead of add(menubar).
> >
> > 2011/7/30 Fred van Zwieten 
> >>
> >> Hi.
> >>
> >> I try to make a menubar, taking examples from vala toolbar demo and a
> >> pygtk tutorial. I have this sample code:
> >>
> >> using Gtk;
> >>
> >> class menusystem : Gtk.Window
> >> {
> >>public menusystem ()
> >>{
> >>this.title = "Menu System Demo";
> >>this.destroy.connect (Gtk.main_quit);
> >>set_default_size (600, 600);
> >>
> >>var menubar = new MenuBar();
> >>var file_menu = new Menu();
> >>var quit_item=new MenuItem.with_mnemonic("_Quit");
> >>file_menu.append(quit_item);
> >>quit_item.activate.connect(Gtk.main_quit);
> >>var file_launcher=new MenuItem.with_mnemonic("_File");
> >>file_launcher.set_submenu(file_menu);
> >>menubar.append(file_launcher);
> >>
> >>var vbox = new VBox (false, 0);
> >>vbox.pack_start (menubar,false,false,0);
> >>add (menubar);
> >>}
> >>
> >>static int main (string[] args)
> >>{
> >>Gtk.init (ref args);
> >>
> >>var mymenu = new menusystem ();
> >>mymenu.show_all();
> >>
> >>Gtk.main ();
> >>
> >>return 0;
> >>}
> >> }
> >>
> >> The menubar doesn't show up. Why not?
> >>
> >> Greetz,
> >> Fred
> >> ___
> >> 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] VAPI metadata problem

[Jim Nelson]

That wound up working -- kind of.  I had to use lower_case_cprefix="gmime_"
for it to generate the right type conversion macro.  My big fear, as you
mentioned, was then having to go back and patch up every method with the
right cname.  It turns out that vapigen magically saw the problem and
provided the proper cname, saving me a bunch of work.

-- Jim

On Tue, Jul 5, 2011 at 12:03 AM, Luca Bruno  wrote:

> On Mon, Jul 04, 2011 at 08:16:28PM -0700, Jim Nelson wrote:
> > Hello,
> >
> > I'm attempting to build a VAPI for GMime.  (If anyone can point me to a
> > completed version, it would be appreciated!)
> >
> > The problem I'm running into is this:
> >
> > The namespace for the module is GMime.  The class GMimeStream's type
> > conversion macro is GMIME_STREAM but valac auto-generates it as
> > G_MIME_STREAM, leading to compilation errors.  I've been unable to find a
> > way via the .metadata file to coerce valac to use the proper macro.  The
> > type_id field seems to be for the GType of the class (GMIME_TYPE_STREAM)
> and
> > the other fields don't help here either.
> >
> > In C, the problem is when an instance of a subclass of GMimeStream is
> being
> > passed to a function that expects a GMimeStream:
> >
> > g_mime_stream_cat_add_source (stream_cat, G_MIME_STREAM (_tmp14_));
> >
> > I need valac to use GMIME_STREAM instead.
> >
> > I'm sure this is something simple, but it's escaping me right now.
>
> Well that's a weird api unfortunately. I fear the only thing you can do is:
> GMime lower_case_cprefix="gmime"
> But then you have to add cname to all other methods and so on.
>
> --
> http://www.debian.org - The Universal Operating System
>
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

[Vala] VAPI metadata problem

[Jim Nelson]

Hello,

I'm attempting to build a VAPI for GMime.  (If anyone can point me to a
completed version, it would be appreciated!)

The problem I'm running into is this:

The namespace for the module is GMime.  The class GMimeStream's type
conversion macro is GMIME_STREAM but valac auto-generates it as
G_MIME_STREAM, leading to compilation errors.  I've been unable to find a
way via the .metadata file to coerce valac to use the proper macro.  The
type_id field seems to be for the GType of the class (GMIME_TYPE_STREAM) and
the other fields don't help here either.

In C, the problem is when an instance of a subclass of GMimeStream is being
passed to a function that expects a GMimeStream:

g_mime_stream_cat_add_source (stream_cat, G_MIME_STREAM (_tmp14_));

I need valac to use GMIME_STREAM instead.

I'm sure this is something simple, but it's escaping me right now.

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

Re: [Vala] async method and delegate

[Jim Nelson]

On Mon, Jun 20, 2011 at 6:27 PM, Nor Jaidi Tuah wrote:

> On Mon, 2011-06-20 at 17:37 -0700, Jim Nelson wrote:
> > With async, the delegate *is* copied, you just don't see it in the
> > Vala code.  With an async method, when the thread of execution yields,
> > the state of the function at that point is stored (copied or ref'd) in
> > a context structure.  When the thread of execution resumes later, the
> > state is pulled back out and the function resumes.
>
> Has that any bearing on the bug I mentioned in
> my earlier email?
>
>
If you mean the warning about copying delegates being discouraged, then yes
it has bearing -- the delegate is being copied inside the async function.
That's my point, the warning is accurate, it's because async methods have
certain side-effects that are not apparent in the code on the screen.  For
another example of this, see
https://bugzilla.gnome.org/show_bug.cgi?id=639054

The problem regarding the closure I haven't looked into.

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

Re: [Vala] What is the right syntax for defining pointers or references or "aliases" in Vala ?

[Jim Nelson]

Actually, string.strip() (which uses g_strstrip) returns a new string.

However, you're right, string is not immutable.  This works:

void main() {
string a = "abc";
stdout.printf("%s\n", a);

a.data[0] = 'A';
stdout.printf("%s\n", a);
}

-- Jim

On Tue, Jun 21, 2011 at 12:27 AM, Christian Siefkes
wrote:

> On 06/21/2011 01:29 AM, Jonathan Ryan wrote:
> > Also remember that "[t]he data type for strings is string. Vala strings
> are UTF-8 encoded and immutable." [
> http://live.gnome.org/Vala/Tutorial#Strings]
> > If they are to be immutable, assigning strings must yield shallow copies.
>
> Though they are not *completely* immutable, e.g. calling str._strip() will
> modify a string in place (or so I think).
>
> Best regards
>Christian
>
> --
> |--- Dr. Christian Siefkes --- christ...@siefkes.net ---
> | Homepage: http://www.siefkes.net/ | Blog: http://www.keimform.de/
> |Peer Production Everywhere:   http://peerconomy.org/wiki/
> |-- OpenPGP Key ID: 0x346452D8 --
> We act for material gain, but also for psychological well-being and
> gratification, and for social connectedness. There is nothing new or
> earth-shattering about this, except perhaps to some economists.
>-- Yochai Benkler, The Wealth of Networks
>
>
> ___
> 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] async method and delegate

[Jim Nelson]

With async, the delegate *is* copied, you just don't see it in the Vala
code.  With an async method, when the thread of execution yields, the state
of the function at that point is stored (copied or ref'd) in a context
structure.  When the thread of execution resumes later, the state is pulled
back out and the function resumes.

To see this, try examining the C code valac generates (use the --save-temps
argument).  You'll see in the async version of the f2() function an F2Data
struct being allocated and all the arguments being stuffed into it.  That's
where the delegate is being copied.

-- Jim

On Mon, Jun 20, 2011 at 5:26 PM, Nor Jaidi Tuah wrote:

> On Mon, 2011-06-20 at 13:06 -0700, Jim Nelson wrote:
> > Regarding copying delegates, it is intentional.  The Vala Journal has
> > a nice write-up about ways to work around the problem:
> >
> > http://valajournal.blogspot.com/2011/06/vala-0130-released.html
>
> This is not about copying delegates. Consider the
> example in the vala tutorial:
>
>  delegate void DelegateType(int a);
>
>  void f1(int a) {
>  stdout.printf("%d\n", a);
>  }
>
>  void f2(DelegateType d, int a) {
>  d(a);   // Calling a delegate
>  }
>
>  void main() {
>  f2(f1, 5);
>  }
>
> This example compiles with no problem. But if we make
> f2 async, i.e.,
>
>  async void f2(DelegateType d, int a) {
>  d(a);   // Calling a delegate
>  }
>
> the warning appears.
>
> hand
> Nor Jaidi Tuah
>
>
> ___
> 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] async method and delegate

[Jim Nelson]

Regarding copying delegates, it is intentional.  The Vala Journal has a nice
write-up about ways to work around the problem:

http://valajournal.blogspot.com/2011/06/vala-0130-released.html

-- Jim

On Sun, Jun 19, 2011 at 9:20 PM, Nor Jaidi Tuah wrote:

> valac version: 0.13.0
>
> When an async method accepts a delegate as its
> argument, I get the warning "copying delegates is discouraged".
> Is this intended?
>
> I also get segmentation fault trying to pass
> a closure accessing local variables. The closure
> works if it doesn't access local vars.
>
> e.g.,
>  var f = etc;
>  async_func ( () => { fn (f);} );
>
> will crash trying to access f. Apparently
> the closure isn't properly constructed.
>
> Is this a known bug? Any simple workaround?
>
> hand
> Nor Jaidi Tuah
>
>
> ___
> 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] warning: copying delegates is discouraged

[Jim Nelson]

Running valac from master, I'm seeing this warning pop up a lot:

warning: copying delegates is discouraged

Can someone explain the rationale for this?  (I'm guessing it has to do with
references.)

Are there any blessed workarounds (other than not copying delegates)?

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

Re: [Vala] An array of Delegations?

[Jim Nelson]

That's just a missing access modifier.  Add "public" before the "delegate"
keyword on the first line and it should compile.

-- Jim

On Wed, Jun 1, 2011 at 9:23 PM, Joseph Montanez wrote:

> Jim,
>
> I had tried that too and get the hole " is less accessible than field"
>
> On Wed, Jun 1, 2011 at 5:22 PM, Jim Nelson  wrote:
> > Try wrapping the delegates in an object and storing those in Gee or an
> > array.  The class accepting the delegates could use a private class so
> it's
> > not exposed.
> >
> > delegate void UserCallback();
> >
> > public class CallbackManager {
> >   private class DelegateWrapper {
> > public UserCallback cb;
> >   }
> >
> >   private DelegateWrapper[] ar = new DelegateWrapper[0];
> >
> >   public void add_callback(UserCallback cb) {
> > DelegateWrapper wrapper = new DelegateWrapper();
> > wrapper.cb = cb;
> > ar += wrapper;
> >   }
> > }
> >
> > (This is just off the top of my head, I didn't compile this to verify.)
> >
> > -- Jim
> >
> > On Wed, Jun 1, 2011 at 4:20 PM, Joseph Montanez  >
> > wrote:
> >>
> >> I know this is a bit insane, but is there any plan or maybe even a
> >> work around to having working list of delegations? I tried with both
> >> gee and fixed arrays for delegations but I get the error of:
> >>
> >> "Delegates with target are not supported as array element type"
> >>
> >> Right now my only work around is have a number of nullable single
> >> delegates in a class then keeping track of the last assigned index.
> >>
> >> --
> >> Joseph Montanez
> >> Web Developer
> >> Gorilla3D
> >> Design, Develop, Deploy
> >> ___
> >> vala-list mailing list
> >> vala-list@gnome.org
> >> http://mail.gnome.org/mailman/listinfo/vala-list
> >
> >
>
>
>
> --
> Joseph Montanez
> Web Developer
> Gorilla3D
> Design, Develop, Deploy
>
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] An array of Delegations?

[Jim Nelson]

Try wrapping the delegates in an object and storing those in Gee or an
array.  The class accepting the delegates could use a private class so it's
not exposed.

delegate void UserCallback();

public class CallbackManager {
  private class DelegateWrapper {
public UserCallback cb;
  }

  private DelegateWrapper[] ar = new DelegateWrapper[0];

  public void add_callback(UserCallback cb) {
DelegateWrapper wrapper = new DelegateWrapper();
wrapper.cb = cb;
ar += wrapper;
  }
}

(This is just off the top of my head, I didn't compile this to verify.)

-- Jim

On Wed, Jun 1, 2011 at 4:20 PM, Joseph Montanez wrote:

> I know this is a bit insane, but is there any plan or maybe even a
> work around to having working list of delegations? I tried with both
> gee and fixed arrays for delegations but I get the error of:
>
> "Delegates with target are not supported as array element type"
>
> Right now my only work around is have a number of nullable single
> delegates in a class then keeping track of the last assigned index.
>
> --
> Joseph Montanez
> Web Developer
> Gorilla3D
> Design, Develop, Deploy
> ___
> 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] Behavior on null pointers

[Jim Nelson]

On Sat, Jan 15, 2011 at 12:23 PM, Thomas Müller wrote:

> Shouldn't a programming language, that offers exception handling, throw
> some kind of null pointer exception?
>

A lot of languages do, but it's not set in stone.  Vala doesn't for a
variety of reasons.

On top of what's already been written here, know that in Vala there is no
class of exceptions that can be thrown at any time (like Java's Error
exceptions).  If a method can throw an exception, it must be explicitly
declared in the prototype.  For exceptions of the variety of null reference
exceptions, that would mean every method would have to be declared as
throwing an error.  That's not the design of most GObject-based libraries,
including GLib.

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

Re: [Vala] vala code generation too constrained?

[Jim Nelson]

I'll jump in here.

The original poster is asking that Vala relax some of its restrictions that
are in place due to its relationship with C.  The only restriction that's
been named so far (unless I missed something) is overloaded method names.

Although I used overloaded methods a lot in my past work with Java and C++,
I don't miss them at all with Vala.  They worked fine with Java.  Name
mangling in C++ is, in my mind, completely broken, particularly since each
vendor uses a different mangling scheme.  Not only does this impeded with
building libraries, but walking a debugger stack trace is like studying the
garbage a modem terminal program spits out when mom picks up the phone.

Personally, I like being able to peruse valac's C code and understand what
it's doing.  There are certain situations where this is invaluable,
sometimes more valuable than symbolic debugging.

I understand the original poster's concern.  If I'm building a stand-alone
application, it seems restrictive to be constrained by requirements that
only apply to libraries.

But so far the only objection I've heard on this thread is about overloaded
methods.  Can anyone name other constraints that are headaches?

And are overloaded methods really such a got-to-have feature?  Or are they a
nice-to-have you can live without?

-- Jim

On Tue, Jan 11, 2011 at 7:57 AM, pancake  wrote:

> its 111 time :D
>
> On 01/11/11 11:11, Xavier Bestel wrote:
>
>> Typical English expression, AFAIK.
>>
> 1st time I heard it..but teh internets has some references. nice to know :P
>
>  And what's he's talking about, is Vala's way of mangling names to be
 usable in C, which can make some names that are different in Vala
 conflict once translated to C. That behavior is useful when you're
 coding a library (you want your lin usable from C), but not when you're
 building an application.

>>> I didn't read any "mangling" word in his mail, and I don't think this is
>>> a feature for Vala.. but ok, maybe i'm an "old timer".
>>>
 So he's asking for a switch to change name mangling, so that "My.Class"
 and "My_class" have different names in the generated code. I tend to
 agree with him.

>>> I think that enforcing decent name constrains is good, not only for
>>> C compatiblity.. but also to force the developer to look for readable
>>> and coherent names for its code.
>>>
>>> This "feature" will help to new users or people who don't want to know
>>> what C is, or just see Vala as a completely unlinked language to C, which
>>> is not the case.
>>>
>> Say what you want, I see it as a purely technical limitation, which does
>> more harm than good. There can be much head-scratching, trying to
>> understand why there's a bug in the program while it's just a
>> non-obvious mangling problem.
>>
>>  for me it's a aestethic than technical. I never had big problems with
> name
> mangling issues, because when you understand how Vala works you use
> to type decent and legal names for classes and variables.
>
> But if this problem is such a pain for many people.. we should look for a
> solution.
>
>  The 'name mangling' magic you are asking for will force all name symbol
>>> generation to append a random number or prefix everything with the
>>> file name.. this will keep C compatiblity but making readability harder.
>>>
>> That's an implementation detail. You could always use traditional name
>> mangling (so nothing changes), and start adding a suffix/prefix only in
>> case of conflict, so you keep the best of both worlds.
>>
>>  Then you will not be able to compile the same program in the two modes
> which
> is IMHO wrong. (how many times did you write a library from a program's
> library?
>
> If you think in these two modes.
>
>  I don't think that adding language features by breaking C compatiblity
>>> can benefit Vala.. in the mean that if some day this flag appears, i will
>>> prefer to have it only to fix name collision issues, not breaking feature
>>> list between the two modes.
>>>
>> IMHO there should be 2 modes:
>> - library mode, where conflicts are clearly and loudly shown by valac.
>> - application mode, where conflicts are silently resolved via a suffix
>>   or whatever clever magic some smart people invent.
>>
> then people will come asking for support for overloading constructors and
> other
> stuff, that just breaks the basics of the language and the backwards
> compatibility.
>
> What do Jürg thinks about?
>
> --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] this = Object

[Jim Nelson]

If you're trying to use a delegate from C, you need to be aware of the
delegate's target, which is a hidden parameter to Vala code but visible in
C.

If you compile your code with the --save-temps flag enabled, you can see how
a delegate is constructed in C.  For example:

delegate void Callback(int32 i);

Becomes this in the .c:

typedef void (*Callback) (gint32 i, void* user_data);

The user_data is the target (in Vala-parlance).  Your C code should invoke
the callback like this:

Callback _cb = cb;
...
_cb (i, obj);

Rob's right, you can't (or shouldn't) assign to "this" in Vala.  When you
invoke the callback with obj as the user_data, Vala's internal code will use
it as the "this" reference.

A useful reference if you're making a VAPI:
http://live.gnome.org/Vala/Bindings/MetadataFormat

-- Jim

On Tue, Sep 28, 2010 at 5:10 AM, Cyrille Colin  wrote:

> hi,
> i've just update to 0.10 from 0.8.1 and I guess now vala detect one of
> my bad.
> I used a init function to give my object pointer to external function
> that will manage callback :
>
>init(this)
>
> init() is define in a vapi :
> public static void init (ValaObj obj);
>
> and use in External library like this :
>
> static void *ValaObj;
> void init (void *obj) {
>ValaObj = obj;
> }
>
> Then i define in vapi the callback, C -> Vala :
> public delegate uint32 callback ( ValaObj, int value);
>
> and this is my callback in Vala code:
> public uint32 cb (ValaObj obj, int value) {
>this = obj;
> ...
> }
> it works fine with 0.8.1 and throw exception with 0.10 :
> error: unsupported lvalue in assignment
> May someone could help me,
> thanks in advance,
> Cyrille.
>
>
>
>
> ___
> 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] metadata file format

[Jim Nelson]

THANK YOU.  This is invaluable.

I second Frederick, it would be great to get this on a Wiki.

-- Jim

On Sat, Jul 10, 2010 at 8:32 PM, tecywiz121  wrote:

> So, I'm a little sick and tired of not being able to find a reference on
> the metadata file format used when binding a library, so I'm going to
> list what I know about it so far.  Please amend/comment at will :)
>
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Binding a function that return a structure, not a pointer

[Jim Nelson]

Just to add to this, I've created a VAPI for libexif we use in Shotwell.
I've not submitted it because it's incomplete.  You might want to check it
out:

http://trac.yorba.org/browser/shotwell/trunk/vapi/libexif.vapi

-- Jim

On Mon, Apr 12, 2010 at 5:05 AM, Abderrahim Kitouni wrote:

> Hi,
>
> 2010/4/11 Luca Bruno :
> > On Sat, Apr 10, 2010 at 04:58:06PM -0700, Darren Warner wrote:
> >>
> >> I'm creating a vapi for libexif (using vala-gen-introspect) which
> >> includes a function that returns a structure:
> >>
> >> typedef struct {ExifLong numerator; ExifLong denominator; }ExifRational;
> >> ExifRational  exif_get_rational  (const unsigned char *b,
> >> ExifByteOrder order);
> >>
> >> If I don't alter ExifRational in my .metadata, the C compiler
> >> complains about assigning ExifRational to ExifRational * when I try
> >> to use the function.
> >>
> >> If I set ExifRational is_value_type="1", which I believe I should
> >> be, valac is generating an additional parameter (a pointer to a
> >> temporary ExifRational) when calling exif_get_rational() - of course
> >> the compiler complains at this also.
> >>
> >> This seems like a newbie question, but I've been unable to find any
> >> similar examples in the existing bindings, so any help would be
> >> appreciated.
> >
> > I might be wrong but it looks like it's used like a simple type.
> > Try adding [SimpleType] to your struct binding, e.g.:
> or in the metadata file :
>
> ExifRational is_value_type="1" simple_type="1"
>
> HTH,
> Abderrahim
> ___
> 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] Locking null references

[Jim Nelson]

In Vala, I can lock a null reference.  Is this by design or a side-effect?

class Xyzzy {
private File file = null;

public File get_file() {
File f;
lock (file) {
if (file == null)
file = File.new_for_path("/tmp");

f = file;
}

return f;
}
}

void main() {
Xyzzy x = new Xyzzy();
stdout.printf("%s\n", x.get_file().get_path());
stdout.printf("%s\n", x.get_file().get_path());
stdout.printf("%s\n", x.get_file().get_path());
}

I think this is fine and should be the documented behavior.  Because Vala
only allows locking member variables (and not "this"), being unable to lock
a nulled reference would require allocating a dummy object to lock against
or explicitly using a Mutex and forgoing lock().  I find both unappealing.

In other words, I think this is okay because it's locking access to the
reference and not locking the object itself.  This seems right to me -- but
I'd feel better if I knew this won't go away in the future.

-- Jim
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] IDE ?

[Jim Nelson]

There is limited support for autotools.  Valencia can detect your project
root (i.e. the master Makefile) for an autotools project and execute make
when you select the Project -> Build command, but it won't know which
executable you want when you select Project -> Run.  More information can be
found here:

http://trac.yorba.org/wiki/Valencia

I think it's a matter of what's important to you.  One possibility to solve
the Run issue is to open a terminal window in the bottom pane and just run
the program from there.

-- Jim

On Tue, Mar 16, 2010 at 4:10 PM, JM  wrote:

> Can Valencia handle Autotools projects? I thought it only worked with
> simple Makefiles.
> Thats one reason why I use vtg.
> Regards
>
>
> Am Dienstag, den 16.03.2010, 19:12 + schrieb Bob Hazard:
> > gEdit with the Valencia plugin here too
> >
> > On 16 March 2010 13:36, Sam Wilson  wrote:
> > > On Tue, 2010-03-16 at 05:30 -0700, Rob Powell wrote:
> > >> I'm using Valencia with gedit.
> > >
> > > Seconded!
> > >
> > >
> > > ___
> > > 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] Construct exceptions from numeric error codes

[Jim Nelson]

You want to use an errordomain, not instantiate your own GLib.Error.  As you
said earlier, this is a non-GLib library.  It probably shouldn't be throwing
GLib errors.

I've dealt with this when writing code with a non-GLib library (Sqlite),
trapping its error codes, and then throwing exceptions named for it.  Sample
code:

errordomain MyError {
FROTZ,
NITFOL
}

void try_run(int code) throws Error {
switch (code) {
case 0:
return;

case 1:
throw new MyError.FROTZ("Frotz");

default:
throw new MyError.NITFOL("Nitfol");
}
}

int try_success() {
return 0;
}

int try_frotz() {
return 1;
}

int try_nitfol() {
return 2;
}

void try_catch(int code) {
try {
try_run(code);
stdout.printf("Success\n");
} catch (Error err) {
stdout.printf("Failure: %s\n", err.message);
}
}

void main() {
try_catch(try_success());
try_catch(try_frotz());
try_catch(try_nitfol());
}

Note that try_run() throws Error, not MyError.  As I understand it, all
exceptions declared in an errordomain are Errors, which is why this works.
I think of Error as an abstract base class and errordomain declarations as
implementations (but I wouldn't carry the analogy any further than that).

-- Jim

On Thu, Feb 11, 2010 at 12:49 PM, Julian Andres Klode wrote:

> Am Donnerstag, den 11.02.2010, 21:46 +0100 schrieb Julian Andres Klode:
> > Am Donnerstag, den 11.02.2010, 12:49 -0600 schrieb Sandino Flores
> > Moreno:
> > > Hello.
> > >
> > > Is there a way to construct a throwable error instance from an error
> code?
> > >
> > > I want to implement something like this:
> > >
> > >   void try_run(int err_code) throws GLib.Error {
> > >   if (err_code != 0)
> > >   throw new GLib.Error (Quark.from_string ("My Error"),
> > > err_code, err_desc (err_code));
> > >   }
> >
> > Try to assign the error to a variable and you get:
> >
> > a.vala:3.18-3.81: error: Assignment: Cannot convert from `GLib.Error' to
> > `GLib.Error'
> >Error e = new Error (Quark.from_string ("My Error"),
> > err_code, "TEST");
> >
> > 
> >
> > So I think there is a bug in Vala.
> >
> It actually works if you cast it but it looks stupid, i.e.
>
>  throw (Error)new Error (Quark.from_string ("My Error"), err_code, "T");
>
> works.
> --
> Julian Andres Klode  - Debian Developer, Ubuntu Member
>
> See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
>
>
> ___
> 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] Support for method overloading.

[Jim Nelson]

Discussed here:
http://live.gnome.org/Vala/ValaForJavaProgrammers#Method_Overloading

(The whole page is worth reading, in fact.)

-- Jim

On Thu, Jan 7, 2010 at 2:01 PM, Fabzter  wrote:

> Hi. I have been playing with Vala for some months. I find it to be a really
> cool language, thus, I'm thinking in porting an medium sized personal
> project from C# to Vala, but it relies heavyly on method and constructor
> overloading, and having this features in Vala would make my refactoring
> work
> minimal, so I want to know if vala will ever support this features, you
> know, so I can start waiting if they are planned. :)
>
> ___
> 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] Questions about Launchpad PPA

[Jim Nelson]

Hello,

We here at Yorba rely on the Vala PPA for our own PPA.  (Thanks for
maintaining it, by the way!)  I have a couple of questions.

First, are there any plans to make Vala 0.7.9 available for jaunty on the
PPA?

Second, does anyone know when libgee 0.5 will be available for lucid?

Thanks,

-- Jim Nelson
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

[Vala] Vala 0.7.7: unsupported lvalue in postfix expression

[Jim Nelson]

Hello,

When I build with the new 0.7.7 compiler I see these sorts of errors:

error: unsupported lvalue in postfix expression

for these sorts of lines:

a[ctr]++;

where a is (for example):

int[] a = new int[3];

The solution seems to be to replace the postfix with the assignment infix
operator:

a[ctr] += 1;

Is this by design?  I'm curious why this change was made.

Thanks,

-- Jim
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Libgee's Roadmap proposal

[Jim Nelson]

> - Are there some things missing ?

How about remove() for Iterator?

-- Jim
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] [PATCH] Add parenthesis to macro substitutions

[Jim Nelson]

Just FYI, this issue has a few related bugs:

http://bugzilla.gnome.org/show_bug.cgi?id=584228
http://bugzilla.gnome.org/show_bug.cgi?id=539894
http://bugzilla.gnome.org/show_bug.cgi?id=585292

Regarding the last one (which I reported), adding parentheses isn't enough.
Because macros are used, the rvalue is evaluated each time the const is
invoked.

Should this technique be re-examined, where the consts are initialized at
program startup and available as extern's to other source files?

-- Jim
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

[Vala] lock (this) not available?

[Jim Nelson]

I noticed while coding with threads that the statement lock (this) is not
available.  valac returns this error:

error: Expression is either not a member access or does not denote a
lockable member

Is it part of the language spec that only members can be locked and not the
"this" object itself?  I can't find documentation either way.

I've also discovered you cannot lock an object externally, a la:

Obj o = new Obj();
lock (o) {
o.get_value();
}

does not compile, with the same error.  Again, I'm unsure if this is part of
the spec.

Since I'm on the subject, if you are able to lock (this), it would be nice
if you could lock an object throughout a method's execution, a la Java's
synchronized methods:

public lock void atomic_op() {
}

-- Jim
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

[Vala] valac 0.7.1 bug: Delegates are typedef'd before enums in generated C code.

[Jim Nelson]

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] NativeVolumeMonitor binding

[Jim Nelson]

Hello,

I believe I've found two problems, one with gio/gnativevolumemonitor.h and
the other with the gio vapi.  I'll explain them both, although only the
second is a Vala problem.

First, gnativevolumemonitor.h doesn't #define
G_NATIVE_VOLUME_MONITOR_GET_CLASS, which causes problems for the code valac
generates.

However, even when I manually add the #define, valac wants to include an
instance pointer in the call to get_mount_for_mount_path().  This virtual
function doesn't accept an instance pointer as an argument.

It's an odd thing, but is there some way in a vapi to declare no instance
pointer for a method call?  Because this is a virtual method, it can't be
static.

Thanks,

-- Jim Nelson
Yorba
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

[Vala] Gtk.TreeSelection bindings

[Jim Nelson]

I'm having some problems with the set_select_function method and its
delegate, Gtk.TreeSelectionFunc.  A user data void * is available to pass a
target pointer, but it's not being used.  The target pointer is being
inserted anyway by valac, causing compilation errors.

I hand-edited 0.6.1's gtk+-2.0.vapi to get something working.  It looks like
this is more in the ballpark:

4407c4407,4408
< public void set_select_function (Gtk.TreeSelectionFunc func, void*
data, Gtk.DestroyNotify destroy);
---
> [CCode (delegate_target_pos=1.1)]
> public void set_select_function (Gtk.TreeSelectionFunc func,
Gtk.DestroyNotify? destroy);
6725c6726
< [CCode (cheader_filename = "gtk/gtk.h")]
---
> [CCode (cheader_filename = "gtk/gtk.h", delegate_target_pos=3.1)]

This also handles passing null for the destroy function, which is valid,
although with the data pointer being used for the target, I'm not sure its
necessary.

-- Jim Nelson
Yorba
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

[Vala] libexif vapi bindings

[Jim Nelson]

As part of a project I'm working on, I developed a vapi file for libexif (
http://libexif.sourceforge.net/).  This is the first vapi file I've
developed, so no promises on completeness or robustness.

If someone with more vapi experience could look it over and offer
suggestions for improvement, it would be greatly appreciated.

Caveats:

* Many of the functions and exposed data members are still raw pointers.
Would like to change as many of these as I can to references, however, only
if it honors libexif's rules on ref-counting.
* Data.save_data() returns a pointer that *must* be freed with the C
library's free() function.  (Not g_free or other variants.)  libexif has an
installable memory allocator feature, and I would love to have it use GLib's
system.  However, I don't know how to do this purely in vapi.
* A lot of this is untested by me.  Be sure to check the .c output if you
encounter bugs.

The vapi can be found at
http://trac.yorba.org:8000/browser/photo/trunk/libexif.vapi  i've attached
it below as well.
Enjoy,

-- Jim Nelson
Yorba


--


[CCode (
cprefix = "Exif",
lower_case_cprefix="exif_"
)]
namespace Exif {
[CCode (
cname="ExifByteOrder",
cheader_filename="libexif/exif-byte-order.h",
cprefix="EXIF_BYTE_ORDER_"
)]
public enum ByteOrder {
INTEL,
MOTOROLA;

public weak string get_name();
}

[Compact]
[CCode (
cname="ExifContent",
cheader_filename="libexif/exif-content.h",
ref_function="exif_content_ref",
ref_function_void=true,
unref_function="exif_content_unref",
free_function="exif_content_free"
)]
public class Content {
[CCode (cname="exif_content_new")]
public Content();
public void add_entry(Entry entry);
public void remove_entry(Entry entry);
public void dump(uint indent = 4);
public void foreach_entry(ForeachEntryFunc cb, void *user);
public weak Entry get_entry(Tag tag);
public void fix();
public Ifd get_ifd();

public Entry **entries;
public int count;
public Data parent;
}

[CCode (
cheader_filename="libexif/exif-utils.h",
cprefix="exif_",
lower_case_cprefix="exif_"
)]
namespace Convert {
public static uint16 get_short(uchar *buffer, ByteOrder byteOrder);
public static int16 get_sshort(uchar *buffer, ByteOrder byteOrder);
public static uint32 get_long(uchar *buffer, ByteOrder byteOrder);
public static int32 get_slong(uchar *buffer, ByteOrder byteOrder);
public static void set_short(uchar *buffer, ByteOrder byteOrder,
uint16 val);
public static void set_sshort(uchar *buffer, ByteOrder byteOrder,
int16 val);
public static void set_long(uchar *buffer, ByteOrder byteOrder,
uint32 val);
public static void set_slong(uchar *buffer, ByteOrder byteOrder,
int32 val);
}

[CCode (cheader_filename="libexif/exif-content.h")]
public static delegate void ForeachEntryFunc(Entry e, void *user);

[Compact]
[CCode (
cname="ExifData",
cheader_filename="libexif/exif-data.h",
ref_function="exif_data_ref",
ref_function_void=true,
unref_function="exif_data_unref",
free_function="exif_data_free"
)]
public class Data {
[CCode (cname="exif_data_new")]
public Data();
public static Data new_from_file(string path);
public void dump();
public void fix();
public void foreach_content(ForeachContentFunc cb, void *user =
null);
public ByteOrder get_byte_order();
public void set_option(DataOption option);
public void unset_option(DataOption option);
public void save_data(uchar **buffer, uint *size);

public Content[Ifd.COUNT] ifd;
public uchar *data;
public uint size;
}

[CCode (cheader_filename="libexif/exif-data.h")]
public static delegate void ForeachContentFunc(Content c, void *user);

[CCode (
cname="ExifDataOption",
cheader_filename="libexif/exif-data.h",
cprefix="EXIF_DATA_OPTION_"
)]
public enum DataOption {
IGNORE_UNKNOWN_TAGS,
FOLLOW_SPECIFICATION,
DONT_CHANGE_MAKER_NOTE;

public weak string get_name();
public weak string get_description();
}

[Compact]
[CCode (
cname="ExifEntry",
cheader_filename="libexif/exif-entry.h",
ref_function="exif_entry_ref",
ref_function_void=true,
unref_function="exif_entry_unref"
)]