[Vala] Leaving the project

[Luca Bruno]

Hi,
it's been a long time I haven't worked on Vala. Until now, I always thought
I could have some spare time to work on it, but things changed so much in
my life that it's no more the case.

I've started using Vala several years ago. The first time I saw the
language I was impressed and delighted. I felt the need to contribute to
it. At the time Jurg was very active and reviewed many of my patches, so I
could learn more of the Vala internals and eventually become maintainer of
the project.

I feel bad, but it's necessary today that I make a choice for the good of
the project, so that people do not rely on me for code changes. I've been
inactive for almost a year. I realize that also Jurg is not able to review
patches nowadays.

Time passes, and old people don't have the same energy and time as before.
The project needs new people.

So I encourage everyone who has a GNOME git account and is interested in
Vala to push the project on. Patch looks good? Push it. Patch is complex
and hasn't been reviewed in ages? Push it.

If something breaks then revert. Nowadays most distros ship Vala with
multiple versions, and software depends exactly on a Vala version.

Thank you everyone, big thanks to Flo, Evan and Rico. They have always been
solid to Vala contribution and being helpful to the whole community.

I will keep contributing to free software in general. It's been some time
I've been maintaining several packages on NixOS. It's less time consuming,
as packaging software is quite mechanical. So it fits better my little time
and I can still be active in the FOSS world.

That's all I can say. It's been a pleasure for me to work on this project
and in this awesome community. I hope people relying on Vala will take over
the project, one step at time.

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

Re: [Vala] getting started with vala and glade

[Luca Bruno]

It does, it's reference counting. The main there is freeing the Thelma
object right after run method is called.

Il lunedì 27 giugno 2016, Ben Iofel  ha scritto:

> Vala does not have garbage collection, and the main() in the code example
> is fine
>
>

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

Re: [Vala] getting started with vala and glade

[Luca Bruno]

Il venerdì 27 maggio 2016, Chris Bare  ha scritto:

> I have a very simple vala program that is trying to load a glade ui file.
> The window appears briefly, but then the program exits without error.
> What am I missing?


Save the new Thelma() to a variable, otherwise it gets garbaeg collected.


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

Re: [Vala] request to add another example to Projects/Vala/ListExample

[Luca Bruno]

Hi,
thanks a lot for your contribution. The wiki is open, you can register and
edit it freely! :)

Also pay attention to the comment about "how" and "how". In C, they are
equivalent because those are const strings and have the same address. But
with List they get copied. However with List they
would be equal. It would be better if you could reword that comment about
pointing to the ownership of the List elements

On Fri, Mar 18, 2016 at 8:26 PM, MohanR  wrote:

> Hi,
>
> I'm a beginner in vala. I would like to add the following example to
> this wiki link to make other beginners understand important thing about
> List.
>
> https://wiki.gnome.org/Projects/Vala/ListSample
>
> int main(string[] args) {
> List mylist = new List();
> mylist.append("hi");
> mylist.append("how");
> mylist.append("are");
> mylist.append("you");
>
> /* prints length: 4 */
> stdout.printf("length: %u\n", mylist.length());
>
> /* following wont work as expected because in
>  * C universe, "how" and "how" is not equal
>  */
> mylist.remove("how");
>
> /* still prints length: 4 */
> stdout.printf("length: %u\n", mylist.length());
>
> /* works because "how" and "how" is equal
>  * according to strcmp()
>  */
> mylist.remove_link(mylist.find_custom("how", strcmp));
>
> /* prints length: 3 */
> stdout.printf("length: %u\n", mylist.length());
>
> return 0;
> }
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>



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

Re: [Vala] request to add another example to Projects/Vala/ListExample

[Luca Bruno]

Oh wow, just realized I cannot edit it either... will talk to some gnome
admins on Monday. Thanks.

On Fri, Mar 18, 2016 at 10:27 PM, MohanR  wrote:

> HI,
>
> I screwed-up that comment. sorry for that. I tried to upload a new version
> of that page, but wiki says I'm not allowed. Please help to update that
> page.
>
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] wip/transform branch

[Luca Bruno]

On 16/02/2016 02:23, Aaron Andersen wrote:
> Hello,
>
> What ever happened to the wip/transform branch?
>
> http://valajournal.blogspot.ca/2014/02/what-to-expect-from-wiptransform-branch.html?m=1
I had less time for that branch, it had some issues with dbus code
generation, and other priorities came up with vala development.

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

Re: [Vala] interaction of parentheses and string template interpolation via the @ sign

[Luca Bruno]

I believe this is an issue with the lexer. Template strings are parsed at
syntax level, not parser level, hence it may not support nested parenthesis.

On Fri, Dec 25, 2015 at 8:17 PM, Dan Hitt  wrote:

> If you do string interpolation via
> string s = @"some text $some_variable";
> it produces a string like
> some text 5
> if 5 were the value of some_variable.
>
> But if you put parentheses in, this gets defeated:
> @("some text $some_variable")
> just becomes
> some text $some_variable
> with no interpolation of the value of some_variable into the string.
>
> Is this intentional?
>
> This is with vala 0.28.1 on ubuntu 15.10.
>
> (And of course it is a very tiny issue, if it is an issue at all.  The
> reason it
> came up in the first place was i had something more complicated,
>@("a: $a\n" +
> "b: $b\n" +
> "c: $c\n")
> and i was very surprised that this did not work.  It can be fixed by the
> slightly lengthier form
> @"a: $a\n" +
> @"b: $b\n" +
> @"c: $c\n"
> but i do wonder why grouping with parentheses has such a drastic effect.
> And it also makes me wonder just what @ does and what it sees: clearly
> it has greater visibility into its surroundings than just some function.)
>
> Thanks in advance for any info.
>
> dan
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>



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

Re: [Vala] error messages from valac have some kind of extra formatting that confuses emacs compilation mode

[Luca Bruno]

valac --no-color

On Thu, Dec 24, 2015 at 6:44 PM, Dan Hitt  wrote:

> When i compile something with valac, like
>  valac --pkg gio-2.0 some_program.vala
> the error messages apparently include some extra formatting characters.
>
> So, instead of getting only
>some_program:48.33-48.33: blah blah blah blah,
> in addition some leading characters like "ESCAPE [001m" are emitted.
>
> These presumably make the output red or bold face or something.
>
> But they confuse the compilation mode in emacs, so that it doesn't
> know where to jump to
> in order to walk through the errors in the source tree.
>
> I looked at the man page for valac, and did not see any way to turn
> off the extra formatting.
>
> I presume there must be, because after all these years i can hardly be
> first to have this problem.
>
> Thanks in advance for any clues, even RTFM if you point me to the
> right fine manual to read!
>
> dan
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>



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

Re: [Vala] error messages from valac have some kind of extra formatting that confuses emacs compilation mode

[Luca Bruno]

It's in valac --help, indeed it's missing in the manpage.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] idea for vala performance optimization

[Luca Bruno]

Where do you read that vala copies data for the closure? The closure data
is created to be used both for the lambda and for the method containing the
lambda. The closure data is shared, not copied.

On Sat, Nov 21, 2015 at 3:13 PM, Michele Dionisio <
michele.dioni...@gmail.com> wrote:

> Sorry, I was thinking too much but only write too short email.
>
> It is true the gcc nested function does not manage any reference counting
> to the object or manage any garbege collector. but thinks about this quite
> common scenario:
>
> async function1() {
> int a=1;
>
> yield function2();
>
> yield function3();
>
> }
>
> when function1 is converted in C we can split functio1 in more than one
> neasted function that all can access to the local variable 'a';
>
> something like:
>
> function1() {
>  int a=1;
>
> void function1_2() {
> }
>
>  void function1_1() {
>function1_2();
>  }
>
> function2( function1_1() );
> }
>
> now 'a' is visible to all. So the continuation can be implemented without
> problem because function1 is not terminated before calling function1_1 and
> function1_2 and there is no copy of memory.
>
> I think that gcc is quite efficient to manage that because it access
> directly to the stack allocated object of function1 from function1_1 and
> function 1_2. It can be done because of:
> "If you try to call the nested function through its address after the
> containing function has exited, all hell will break loose. If you try to
> call it after a containing scope level has exited, and if it refers to some
> of the variables that are no longer in scope, you may be lucky, but it's
> not wise to take the risk. If, however, the nested function does not refer
> to anything that has gone out of scope, you should be safe."
>
> but yes it is true it is quite difficult to be implemented and I don't know
> from where start and if this can really introduce notable
> performance benefit.
>
> regards
>
> 2015-11-21 13:44 GMT+01:00 Al Thomas :
>
> > > From: Michele Dionisio 
> >
> > > Sent: Saturday, 21 November 2015, 9:37
> > > Subject: [Vala] idea for vala performance optimization
> > >
> > > Ok, this is the only way because the C standard does not support
> closures
> > > by itself. But gcc support closure in not standard "nested functions".
> > >
> > > https://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html
> > >
> > > so it is teorically possible to avoid to make a lot of copy.
> >
> > >
> >
> >
> > From the document you reference:
> >
> > "If you try to call the nested function through its address after the
> > containing function has exited, all hell will break loose. If you try to
> > call it after a containing scope level has exited, and if it refers to
> some
> > of the variables that are no longer in scope, you may be lucky, but it's
> > not wise to take the risk. If, however, the nested function does not
> refer
> > to anything that has gone out of scope, you should be safe."
> >
> > GCC nested functions are not closures.
> >
> > > do you think that it can be convenient to try to develop a special
> "vala
> > to
> > > c converter" for gcc to test the real speed benefit?
> >
> >
> > Unfortunately not a good idea. GCC nested functions are not closures.
> Even
> > if they were it would
> > tie Vala to a specific C compiler which I find a valid objection. Finally
> > a pointer to the
> > context data is passed in a closure, not the data itself. Why are you so
> > sure the C compiler
> > handles this in an inefficient manner?
> >
> >
> > Al
> > ___
> > 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
>



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

Re: [Vala] Sign with RSA

[Luca Bruno]

On 10/09/2015 12:08, rastersoft wrote:
>
> Hi all:
>
> Is it possible to use a RSA private key (created with ssh-keygen) to
> sign something from Vala? This is, not only if there is a library for
> that, but also if there is a VAPI for it.
>
> Thanks.
>
There's the gnutls vapi, not sure how friendly it is.

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

Re: [Vala] bug in glib vapi ????

[Luca Bruno]

On 25/08/2015 20:11, Michele Dionisio wrote:
 Hi,

 I think that the following function:

 [CCode (cname = g_list_find_custom, simple_generics = true)]
 public unowned ListG searchT (T data, SearchFuncT,G func);

 in glib vapi is wrong because the g_list_find_custom documentation says?

 Finds an element in a GList, using a supplied function to find the desired
 element. It iterates over the list, calling the given function which should
 return 0 when the desired element is found. The function takes two
 gconstpointer arguments, *the GList element's data as the first argument *and
 the given user data.


 so the function has to be:
 [CCode (cname = g_list_find_custom, simple_generics = true)]
 public unowned ListG searchT (T data, SearchFuncG,T func);

 is it true?
From the documentation it seems like you say. Would you please report a
bug? I can work on it.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Having a problem understanding Vala or Gee HashMap

[Luca Bruno]

On 06/08/2015 10:52, Jason Martin wrote:
 I am porting some Java software to Vala but I cannot understand why the
 following code will not work like I think it should.

 Vala 0.26.2, libgee-0.8 on Xubuntu 15.04

 Thanks in advance. I have used many variations and casts but I cannot get
 @get or has_key for Gee.HashMap to work. (website samples work fine for me)

 I placed notes in the comments.
You must provide the necessary functions to the HashMap constructor:
http://valadoc.org/#!api=gee-0.10/Gee.HashMap.HashMap
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] About composite templates and its constructors

[Luca Bruno]

On 06/08/2015 16:01, Andres Fernandez wrote:
 Hi folks!

 I've been playing for a while with composite templates on
 vala, and made a lot of progress to reach what I expected of
 my work on it. It's just great!

 Well, anyway, I had a problem and didn't get any clue on the
 web. I have two composite templates there is a MyWindow
 class and a MyTreeView class. the .ui file of MyWindow
 template has an object of MyTreeView class. At this point
 everything works great.

 But, MyTreeView class assign it a model of mine on its
 constructor function. But, as MyTreeView is get as a
 [GtkChild], in MyWindow composite template class, its
 constructor function never runs, so that MyTreeView object
 has no model assigned. I can assign one to it on MyWindow
 class, but I wanted to avoid that.

 Is there any way to execute the constructor code of a
 composite template that is a [GtkChild] of another composite
 template class?

 Thanks in advance!
Try writing constructors with construct { }, which is the gobject
construction.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] vapi for libpng

[Luca Bruno]

On 23/06/2015 08:18, Nor Jaidi Tuah wrote:
 Are there any vapi for libpng (hidden somehow
 from google)?
Not that I know. You cannot use gdkpixbuf?
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Bindings wiki pages, was Re: libserialport binding

[Luca Bruno]

That's very nice, indeed. Thanks.

On Sat, Jun 20, 2015 at 2:42 PM, Steven Oliver oliver.ste...@gmail.com
wrote:

 I love the bar. We should have put that there along time ago.









 —
 Sent from Mailbox

 On Sat, Jun 20, 2015 at 8:23 AM, Al Thomas astav...@yahoo.co.uk wrote:

  From: Evan Nemerson e...@coeus-group.com
  Sent: Friday, 19 June 2015, 19:47
  Subject: Re: [Vala] libserialport binding
 
  On Fri, 2015-06-19 at 19:18 +0200, Daniel Brendle wrote:
   On 06/19/2015 05:52 AM, ?? wrote:
   https://github.com/nemequ/vala-extra-vapis
 
   This is the place where many people look for bindings first.
 
  Or adding them to the External Bindings page on the wiki, which *should
  be* the first place people look (it includes bindings from vala-extra
  -vapis as well as many others):
 
  https://wiki.gnome.org/Projects/Vala/ExternalBindings
  There appear to be four pages on the wiki relating to bindings.
  I have added a navigation bar to the top the ExternalBindings page
  to make these pages easier to find.
  If there are no other relevant pages and the wording I have used
  makes sense then I will copy the navigation bar to the other three
  pages to make a suite of relevant pages.
  I hope that's useful,
  Al
  ___
  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




-- 
NixOS Linux http://nixos.org
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Use of vala in a production environment

[Luca Bruno]

On 18/06/2015 10:31, Luc Chante wrote:
 Hi everyone,

 I'm looking for a language to start a new project.
 This project consists of a server (a REST API server using JSON), and
 clients (nothing really new :-p).

 I am wondering if vala (or a particular version of vala) is stable and
 mature enough to be the base for developing the server part.
 Or maybe a particular realse of glib, libsoup, libgee, ...

 Putting aside my own code mistakes, is there any issues of memory leaks,
 long term execution trouble, ...

 And what about cross compilation for windows (I already successfully
 cross-compiled some little code to test GTK+3.0 under windows) ?

 I am not fixed yet, but python could be my next choice.

 Thank you.

 PS : If someone have a professional use/experience in vala, what trouble
 did he have to face with ?
Nowadays for this kind of job I'd suggest you to look at Go, neither
Python nor Vala.
Vala is better suited for dbus, gtk, and gnomeish stuff in general.

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

Re: [Vala] Wrong glib-2.0 vapi

[Luca Bruno]

On 16/06/2015 05:21, yannick inizan wrote:
 Hi.

 I've a problem with glib-2.0 vapi and OptionContext :

 [Compact]
 #if GLIB_2_44
 [CCode (ref_function = g_option_context_ref, unref_function =
 g_option_context_unref, type_id = G_TYPE_OPTION_GROUP)]
 #else
 [CCode (free_function = g_option_context_free)]
 #endif
 public class OptionContext {

 g_option_context_unref doesn't exist, but free_function exists.
 I've to copy vapi and remove this condition

It's been reverted in e6b24a2e5f00ba73dd06b8e57cc1ab8ccddf38ee
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Flowgraphs for Gtk in Vala

[Luca Bruno]

cmake is a hassle for packaging in many ways. And autotools are not that
hard, really. It takes few minutes to get a project running.

On Thu, May 21, 2015 at 8:13 PM, Daniel Brendle grindh...@skarphed.org
wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 05/21/2015 07:19 PM, Daniel Espinosa wrote:
  Thanks to be open for other build systems.
 
  I've ported GXml [1] from CMake to Autotools and used the last in
  all my Vala projects, then I think I can do the job :-)
 
  I'll fork your repository and make a pull request for it.
 

 Awesome. I am thrilled to see the results.

 But, as this is loosely related to Vala in general i'll ask right here:

 Where do you see the benefits of autotools over cmake in a
 vala-project? I know that the GNOME project requires its official
 sub-projects to use autotools als buildsystem and i know that debian
 packages is most simple when the source tarball uses autotools because
 one can leave the debian/rules-file as is. But does this really
 compensate for the time-costs of learning and using the (in my
 personal view) highly unintuitive autotools? Is there any technical
 aspect i am missing here?

 Yours, Grindhold.
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2

 iQIcBAEBCAAGBQJVXiBlAAoJEBuqgJs6izSEP1QP/32Ouzg6o2BmvkvMPrXYoXkL
 cigGLBkTse1OyYTBTLN3Tl6UhoMDhhpIP0/NCtE/rQaT/Fjx/kxF+qL5owOwgEfs
 DJh9h6z6MFrsROn3LNeyDx6pZJn7WZcQXzgdEn0IVrYuN0BwjZ/slI1Tv3Ei84fR
 msTrGudAMWyAmvy40c44eopVF2LxX4FIB/aGD0ymm3xhsTW0Vflh8HVv4mjGZFqL
 da5bUNGzgPVSaZgfuFpVYbsdO/UqUBrQlQVbiCw7IyNwj1tR9rUpKuiAT/wFUGC6
 si83r//aloKVwxcmXFDuHYyngpoOfB3pny/m9oad9QuR+H/V1tXmuNPe/wHAYx47
 MNbH9uH3M2AwGsu6lxGv5lCX/IDJt34JkZSU1NU8cjCRKtV8uyobfryGJBUJpPvP
 +MSxYEzj0UxQnK2TqNQniuIv8A+8DlIeTwJ4ozCX/aHWprOkbYp0PxPts4RKACex
 Oa7Uq2Wzmpf8TJ8cjDbu1sTyZpFXjhPSbUGvSTw1FNe8a4xz4zPQMLqWowBsqhy9
 9NQs5BAz7QfapqiWOT5V5kwaJrSB7rTAkLKdLeUfdYGbUrCZurfUglUzkGuDU9O2
 ePXj6fgP58b6qpw9qdBbWeq06pF2EwjDHlR0AesaDOeVt/i0a4QE5vBUlpauwsmh
 kg8zrRv6cRySRV+gumo9
 =pmM3
 -END PGP SIGNATURE-
 ___
 vala-list mailing list
 vala-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/vala-list




-- 
NixOS Linux http://nixos.org
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Strings and template comparison

[Luca Bruno]

On 07/05/2015 14:41, Craig wrote:
 Hello,

 Why are strings not compared by value when they're passed into template
 functions? Consider this gist:
 https://gist.github.com/weberc2/4131654ff068d27f9cde

 Is there anything I can do to get value comparison back in templates?
Because generics don't enclose an equality function. Check whether the
type is a string, then cast to string.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] How does IOError.from_errno works?

[Luca Bruno]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/03/2015 09:45, Guillaume Poirier-Morency wrote:
 I would like to convert errors coming from some bindings to appropriate
 IOError using errno codes.

 http://valadoc.org/#!api=gio-2.0/GLib.IOError.from_errno

 I have tried the following:

 throw IOError.from_errno (this.err.get_error ());

 But I get the following complication error:

 src/vsgi/fastcgi.c:1170:10: erreur: incompatible types when
 assigning to type ?struct GError *? from type ?GIOErrorEnum?
_tmp7_ = g_io_error_from_errno (_tmp6_);

 Is it a bug?

 Thanks in advance!
Broken bindings, see https://bugzilla.gnome.org/show_bug.cgi?id=710085
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJU9XY/AAoJEETrFmfSwntrfr8QAJQe1/ot5uTWOUFCvWWnf1+M
ufNaVn2MRU/9495PvPG/nxFgLqDhsA646ITyUUhe/sHIHmULJGchLFmfHzAKcDbH
gnQZOVX9gze3DI8ydZKCcUGsq2aMv9BT1JDNnIWPIsA76du2Rvn/pfOP4wd4Tv/U
tlEn/aD/IzoxEyb3bETgll3/t4gdtPudCfnKBO2pNoKrDpSZyFwEqTCahnQqsQcd
bl23sLDgKYKhll/6Ix9xK1yk6uwMQuz0nSD7ymbJiD63Oyfn43pz5ISU96EdhM0Z
T5Y5OG1IB2Qj99jCuJtsM2gOuLRg+hC2oaTTJnBTz+iFCJ7mRU3QCf01R8tBmQq8
WWnBE6XbpwM6d8b+Tc5+2c6i5PGQ9TZzK4m3JA+dHpQiOXIPRAugjPO/ReyxV9jX
53EOR62LlIGWtdV5vIkOZfAbtra+HHIY8REnDwkhAjujSjS9XUSwevShB4orvr9e
eUotQaDoTjG/qFifh7YnY7/MUPy4ATXyiU+f5GDpQwa5Rvz58oSna7Qq8Auho0jw
dZmJyPFc5whzDr+W7CAIBqrw7HyaT05Zblk9SMHuVf8QHqthPYB3woD/6MQ6m5H8
J/qBGqfdk5/PqkxtRkMSj3OwhCEMiWQVVS9/Juw6BWHuk5VwAtBxA7tN4rwPLQXu
eE/I1RW45YcLMQgcuyds
=oyeQ
-END PGP SIGNATURE-

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

Re: [Vala] Named argument expected

[Luca Bruno]

Only for Object()

On Sat, Feb 14, 2015 at 2:22 AM, Nor Jaidi Tuah norjaidi.t...@ubd.edu.bn
wrote:

 Vala allows fn(name:value). Is it possible
 to have a compile-time enforcement for this?

 For example, the code

 object(xx)

 will produce Named argument expected compile
 error. Is this compile-time check a special
 case or generally available to any function
 appropriately declared?


 Nice day
 Nor Jaidi Tuah




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




-- 
NixOS Linux http://nixos.org
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] DBus generated code: Missing error Field

[Luca Bruno]

Add throws Error to the method.

On Sat, Jan 3, 2015 at 10:35 PM, Daniel Brendle grindh...@skarphed.org
wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1


 Hi, Vala-Guys

 I tried to fiddle around with some DBus stuff and some strange
 behaviour hit me right in my face when i executed make.

 I have an interface like this:

 [DBus (name = de.grindhold.alaia)]
 interface AlaiaMessenger : Object {
 public abstract bool needs_direct_input ();
 }

 And the Vala-Compiler (0.26.1) creates the following function when
 translating to C:

 http://pastie.org/private/vgctn74omjldgey0scpbvq

 As you can see, somewhere in the declaration section there should be
 an GError* error=NULL; somewhere, but it isn't there.
 If i edit the C-code manually and put in the line, it compiles through
 as nothing would've been wrong.

 Is this a known bug? Am i missing something?

 Thanks in advance,
 Grindhold
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQIcBAEBAgAGBQJUqGCfAAoJEBuqgJs6izSEdEoP/3Rweru/Pcs/nU+NcfHZenvD
 7fNtfAdEygpH4GX35qo00Yjg6QPrLwqS4c6RZakSNhs24zHIUGj8HMf3kcPPRbpm
 tPqyabVxwFDf0Z8sek92UDSOmEsTawZTkHWkJyCptiYpPnrJGxG2bSXo0Cr5lGvy
 0prAOj71iKP+Na45Qe/dfF59AV9Ydc1m7LmHE+kHAzKuYYgd1gxjwas9CLjaQ5S3
 AQuTsd78o/PLaposFdyGETj2XyfKHHxq221cOzaFwb9swgVEpyzooRYcVSVaqNv1
 uH7WTSoLexggxLLQnYKiqlt+G/CFvf9VdkYc4+y6YViE26vWiwnVhPWsVvJqog7h
 YE+suQGbwMAbCdGfHr1eLR2ictO7K7faji45OQEQPMAEmnlkfFSTG3co8XKhLNnP
 +76ms+1JoGV5O8EEIeHdXzPWsnxCLZyiATruha+ETaKlj3T/7ZqR7ezqUwFzCtWE
 yBG6q7agNIcZmzQefj88/E+Gh11urwfDqpUMuzNsHxVhWQU0wJnN96aSeZhEU7h5
 BOzgqP+5YTCcn2pq6kOLLq6wRaorHbbicfrA0qeHS3dN/iMvEmoM/K2jv6JOmXOr
 Sixdhs1VlWScYl2DkNXcL0UJJ+x/hyB9IwveNdD4zPkyYEq7gBw/ncsfARwEECk0
 hvbi6ZZ7B7jf7xa5em9Q
 =oY6E
 -END PGP SIGNATURE-
 ___
 vala-list mailing list
 vala-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/vala-list




-- 
NixOS Linux http://nixos.org
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Implicit array size for function allocating an array

[Luca Bruno]

On 16/12/2014 10:52, Nicolas CARRIER wrote:
 Hello,

 I'm trying to bind a C function which has the following prototype:

 int sos_addresses_to_string(const struct sos_address *addresses,
 char ***string_addresses, int nb);

 It's job is to convert an array of addresses, into an array of their
 string representation. So both the addresses array (in input) and the
 string_addresses array will have the same size which is nb. So in
 output, string_addresses will point to an allocated array of allocated
 char buffers.

 I tried to bind it this way:

 namespace Sos {
 public struct Address {
 ...
 public static int array_to_string([CCode (array_length_pos =
 3)] Address addresses[], [CCode (array_length = false] out string[]
 string_addresses);
 }
 }

 and to use it with the following minimal code example:

 public static int main(string[] args)
 {
 string[] strings;
 Sos.Address[] addrs;
 // the following call just populates the initial addrs array
 Sos.Server.get_server_addresses(mambo, out addrs);
 Sos.Address.array_to_string(addrs, out strings);
 stdout.printf(@str_addr: $(strings[0])\n);
 return Posix.EXIT_SUCCESS;
 }

 This approach works, but valgrind complains that the pointed string,
 in the returned array, isn't freed. In fact, in the generated code,
 _vala_array_free is called with an array length of -1, so only the
 array is freed, not the pointed addresses.

 I tried to add array_length_cexpr = addresses.length but it didn't
 do anything, unless I remove 'array_length = false', but in this case,
 an extra parameter is added and the code doesn't compile any-more.


 What would be the best solution to this issue in your opinion ?
After the array_to_string call, do strings.length = addrs.length;
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Cairo matrix multiply vapi question

[Luca Bruno]

On 16/12/2014 10:58, Donn wrote:
 Hi,
 Not sure if I've found a bug or am simply thick. I'm going with the
 latter :D

 At: https://git.gnome.org/browse/vala/plain/vapi/cairo.vapi
 Down near the end, under the public struct Matrix, look for:

 public void multiply (Matrix a, Matrix b);

 In the Cairo C docs, it looks like this:
 void cairo_matrix_multiply (
 cairo_matrix_t *result,
 const cairo_matrix_t *a,
 const cairo_matrix_t *b);

 So, there's an initial arg that is a ref in which to receive the new
 matrix. Is the vapi missing something?

.multiply() is a method of Mmatrix. Therefore you call multiply on an
instance of Matrix which is the one that will get modified.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] unused variable warning in generated C code

[Luca Bruno]

On 12/12/2014 14:18, Nicolas CARRIER wrote:

 The problem is that when I compile vala code with the warning
 compilations flags our build system enables, I have a lot of warnings.
 This one is only one amongst others.
 The risk is high to miss a real one in the mass...
If it's the case that a warning is a bug in the generated code, then
it's a bug in vala.

 Is it planned to cleanup this aspect of the generated C code ?

Yes, not a priority as those warnings can be ignored. But I accept patches.
 Concerning the other warnings I have, do you think it's worth it to
 submit them to the mailing list ? Or will the answers be of the same
 kind ?
This is the mailing list, you meant bugzilla?
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] error: Non-constant field initializers, but the initializer seems constant

[Luca Bruno]

On 12/12/2014 15:31, Nicolas CARRIER wrote:
 namespace Plop {
 int my_int = -1;
 static void check_my_int_is_initialized() {
 if (my_int  0)
 my_int = 42;
 }
 public static int main(string[] args) {
 check_my_int_is_initialized();
 stdout.printf(@my_int is $my_int\n);
 return 0;
 }
 } 
That's an interesting bug. I think vala threats that -1 as unary
operator of negation. Should be trivial to fix. Feel free to report a bug.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] error: Non-constant field initializers, but the initializer seems constant

[Luca Bruno]

On 12/12/2014 15:57, yannick inizan wrote:

 Declaration are allowed outside classe/struct or fonction ?

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

Re: [Vala] error: Non-constant field initializers, but the initializer seems constant

[Luca Bruno]

On 12/12/2014 15:57, Nicolas CARRIER wrote:

 That's an interesting bug. I think vala threats that -1 as unary
 operator of negation. Should be trivial to fix. Feel free to report a
 bug.

 ---

 Ok ! Thank for the explanation.

 I haven't used bugzilla yet. I will try to submit my first bug ASAP.

No need to, fixed in master. Nice catch, thanks.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] unused variable warning in generated C code

[Luca Bruno]

On 12/12/2014 16:06, Nicolas CARRIER wrote:

 Generally speaking, shall I ignore all C warnings if valac issues no
 warning in the vala code himself ?
Yes.

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

[Vala] About vala, glib 2.42 and deadlocks

[Luca Bruno]

Since glib 2.41.2, the mutex/cond implementation on Linux has changed. The
code compiled with Vala  0.26 which targets at least glib 2.32 with
--target-glib 2.32 will suffer from deadlocks.

Your options are either:
- Do not --target-glib 2.32
- Update Vala to at least 0.25.2
- Downgrade glib

-- 
NixOS Linux http://nixos.org
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] enum access modifiers

[Luca Bruno]

Nested classes or whatelse type is always static from a Java view point.
So you access those enum values with test.a.TEST. There's no way those
types can be tied to a particular instance of the parent class.

I could not understand the rest of the mail, sorry.

On Sat, Dec 6, 2014 at 3:21 PM, Al Thomas astav...@yahoo.co.uk wrote:

 The Vala manual states that an enum takes an access modifier, from
 https://wiki.gnome.org/Projects/Vala/Manual/Enumerated%20types%20%28Enums%29
 :enum-declaration:
  [ access-modifier ] enum qualified-enum-name { [ enum-members ] }
 The following compiles and runs with Vala 0.26.0.33:

 void main(){
 var aa = new test();
 print( aa.a.TEST.to_string ());
 }

 class test: Object {
 private enum a {
 TEST
 }
 }

 and only gives a compilation warning about static
 members:private_enum.vala:3.9-3.12: warning: Access to static member
 `test.a' with an instance reference
 print( aa.a.TEST.to_string ());
 So it would appear the current implementation for enums is that they are
 public and static. So is this an implementation bug because the access
 modifier is ignored or a documentation bug because access modifiers for
 enums aren't that useful?
 What has brought this on is a patch adding the 'protected' access modifier
 to the Genie parser - https://bugzilla.gnome.org/show_bug.cgi?id=690848
 Generally I would say the 'public', 'private' and 'protected' access
 modifiers allow a public interface for using and extending a class to be
 defined a bit more clearly. So implementation details can be hidden with
 'private', but also allowed to be extended with 'protected'. While 'public'
 provides the accessible API. In that sense enum, as well as struct and
 delegate, can be implementation details where access can be restricted.
 Enum, struct and delegate are all type definitions so probably should not
 be modifiable by a class sub-type, but readable so they can be accessed for
 creating a variable of the right type. The patch has also highlighted that
 'interface' has an access modifier. Surely an interface should always be
 public? Although a method within an interface could possibly be protected
 as a mixin for implementation only?
 Any thoughts?
 Al Thomas


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




-- 
NixOS Linux http://nixos.org
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] enum access modifiers

[Luca Bruno]

Good point, in general private inside nested classes or namespaces is a
no-op in the same project.
The only thing that makes a difference is the internal modifier (which is
also the behavior of private) when creating libraries: the resulting vapi
and header files will not have that symbol.

On Sat, Dec 6, 2014 at 3:51 PM, Al Thomas astav...@yahoo.co.uk wrote:


   --
  *From:* Luca Bruno lethalma...@gmail.com
 *Sent:* Saturday, 6 December 2014, 14:27
 *Subject:* Re: [Vala] enum access modifiers

 Nested classes or whatelse type is always static from a Java view point.
 So you access those enum values with test.a.TEST. There's no way those
 types can be tied to a particular instance of the parent class.


 Thanks for the reply. It was more the use of the 'private' keyword and by
 extension the 'protected' keyword that I was trying to understand. For
 example:

 void main(){
 //var aa = new test();
 print( test.a.TEST.to_string ());
 }

 class test: Object {
 private enum a {
 TEST
 }
 }
 will compile and run without any errors. But Vala allows an access
 modifier for the enum, so should the use of 'private' above, instead
 produce a compile time error such as Access to private member `test.a'
 denied?




 I could not understand the rest of the mail, sorry.



 On Sat, Dec 6, 2014 at 3:21 PM, Al Thomas astav...@yahoo.co.uk wrote:

 The Vala manual states that an enum takes an access modifier, from
 https://wiki.gnome.org/Projects/Vala/Manual/Enumerated%20types%20%28Enums%29
 :enum-declaration:
  [ access-modifier ] enum qualified-enum-name { [ enum-members ] }
 The following compiles and runs with Vala 0.26.0.33:

 void main(){
 var aa = new test();
 print( aa.a.TEST.to_string ());
 }

 class test: Object {
 private enum a {
 TEST
 }
 }

 and only gives a compilation warning about static
 members:private_enum.vala:3.9-3.12: warning: Access to static member
 `test.a' with an instance reference
 print( aa.a.TEST.to_string ());
 So it would appear the current implementation for enums is that they are
 public and static. So is this an implementation bug because the access
 modifier is ignored or a documentation bug because access modifiers for
 enums aren't that useful?
 What has brought this on is a patch adding the 'protected' access modifier
 to the Genie parser - https://bugzilla.gnome.org/show_bug.cgi?id=690848
 Generally I would say the 'public', 'private' and 'protected' access
 modifiers allow a public interface for using and extending a class to be
 defined a bit more clearly. So implementation details can be hidden with
 'private', but also allowed to be extended with 'protected'. While 'public'
 provides the accessible API. In that sense enum, as well as struct and
 delegate, can be implementation details where access can be restricted.
 Enum, struct and delegate are all type definitions so probably should not
 be modifiable by a class sub-type, but readable so they can be accessed for
 creating a variable of the right type. The patch has also highlighted that
 'interface' has an access modifier. Surely an interface should always be
 public? Although a method within an interface could possibly be protected
 as a mixin for implementation only?
 Any thoughts?
 Al Thomas


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




 --
 NixOS Linux http://nixos.org/





-- 
NixOS Linux http://nixos.org
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] How to check if GLib.List is empty?

[Luca Bruno]

On 02/12/2014 16:34, Виталий Кирсанов wrote:
 Hm, indeed. The following piece of code works fine:

 int main(string[] argv)
 {
 Liststring list = new Liststring();
 assert( list == null );
 return 0;
 }


 So this seems to be the answer to my question. But still there are two
 weird things in my opinion:

- Why I need to call operator new if the result value is still null?
Can't I simply declare a reference Liststring list; and then call e.g.
append()?
Yes, you can. new List() is just null.
- I thought that only references appended with question mark sign (e.g.
Liststring?) can be null, cant' they?
There are several exceptions due to historical reasons. Null is quite
weak in Vala by default in several places.
There's an experimental non-null flag for valac, but that's not much
worked on.

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

Re: [Vala] How to check if GLib.List is empty?

[Luca Bruno]

On 02/12/2014 16:51, Dmitry Golovin wrote:
 Liststring list = new List();
 Would diamond operator be implemented in the future? Anyone needs it?
var list = new Liststring();

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

Re: [Vala] Testing out parameters

[Luca Bruno]

On 21/11/2014 14:38, Andy Lees wrote:
 Is there a way to test if an out parameter has been provided, assuming I
 default it to null?  In the case I want to avoid an expensive calculation
 if it's not required?
In the old days you could check if if (param == null), not sure if
still works.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Tokenize_and_fold bug?

[Luca Bruno]

On 17/11/2014 05:15, Andy Lees wrote:
 Hi,

 Not sure if I'm doing this wrong, but if I do something like:

 public static int main(string [] argv) {
   string[] x;
   var a = 1,2, 345.tokenize_and_fold (en_GB, out x);
   stdout.printf(Len: %d\n, a.length);
   foreach (var s in a) {
 stdout.printf(tok: %s, s);
   }
   return 0;
 }

 I get a C compiler error:
 /home/andrewl/Vala/VTest1/prop.vala.c: In function ‘_vala_main’:
 /home/andrewl/Vala/VTest1/prop.vala.c:41:2: error: too many arguments to
 function ‘g_str_tokenize_and_fold’
   _tmp3_ = _tmp2_ = g_str_tokenize_and_fold (1,2, 345, en_GB, _tmp0_,
 _tmp1_);
   ^

 As does any variation of two arguments.  Fewer than 2 args results in a
 vala compiler error.
The bindings for this function are broken. Can you please report a bug?
https://bugzilla.gnome.org/enter_bug.cgi?product=vala

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

Re: [Vala] VAPI bindings for external lib

[Luca Bruno]

On 17/11/2014 14:28, Gonzalo Aguilar Delgado wrote:
 Hello,

 I'm modifiying babobab to support a ceph cluster. And want to do add
 several tools to position files on OSDs, show fragemntation of
 underlaying filesystems, etc. Maybe this will generate other tool, but
 for now just modifying.

 The problem is that I cannot access directly to librados, libcephfs
 libraries from vala. Ehem, I can do it by just linking but figuring
 out what's the best way to do it.

 I suppose that creating a binding is the best. I saw some tutorials
 but all require that library already uses GObject system that's not
 the case.

 So, should I create a wrapping object lib, and then generate bindings
 from there?

 Or should I do another way? I'm thinking about just adding dep and
 call it from vala like c. But don't know what's the best way to proceed.

If those libs are C, just write the .vapi by hand. Use compact classes
and structs, unless they have reference-counted objects.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] VAPI bindings for external lib

[Luca Bruno]

On 17/11/2014 17:46, Gonzalo Aguilar Delgado wrote:
 Hi,

 perfect! Thank you for fast response.

 Just one question. Is there any vapi repos to upload resulting vapi.
 It would be nice to have something like nexus for maven but in this
 case for vapis.

This is the official unofficial list of extra vapis :)
https://github.com/nemequ/vala-extra-vapis . It's unofficial in the
sense that it's not maintained in the vala tree, it's official in the
sense that as Vala developers we suggest using it. Should be the perfect
place for sharing your vapi.

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

Re: [Vala] Interfacing various languages

[Luca Bruno]

There's no need for a plan to make the compiler more generic. Anyway,
there's a c++ branch in vala created by me, and I had hard time mapping
vala to c++ for two reasons:
1) Classes can be used as structs, even Qt does that fir Lists for example.
2) Templates cannot be easily mapped from vala generics to c++ templates,
unless you specialize the class. E.g. ListT to Liststring and call that
StringList in vala.

The second point can be reworked to make vala a complete rewrite of c++
somehow, but wasn't my intention in the branch. However the fist point is a
real problem.

If any of you has a project that maps vala to another language, and you
feel the need for a more generic interface of a particular component of
vala, I'm willing to help with that.

On Sun, Nov 9, 2014 at 6:23 PM, pancake panc...@youterm.com wrote:

 i think that before accepting patches we need a plan. We have to decide
 if we want a subset of Vala, or just to define an interoperability API to
 call other languages like C++, Java or ObjC.

 if the plan is to use it just with bindings one can use Valabind, which can
 create JNA/JNI or C++ bindings from Vala code (still wip) and then just use
 that api from Java or C++ code.

 But I would prefer to be able to call OBJC/C++ code from Vala. The
 emscripten
 solution to that problem is quite elegant, so maybe we can use it as a way
 to create formatted strings at compile time for the generated code. For
 example:


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

Re: [Vala] Interfacing various languages

[Luca Bruno]

Talking in general here. I would accept patches in the vala compiler for
multiple targets only if they are generic enough.
It's a long iteration, but I don't want after N months of inactivity of a
target to revert it because nobody maintain it.

For this reason, I accept small patches, step by step, to generalize the
current vala compiler and codegen to allow more pluggability.
I'm not willing to merge big stuff at once especially if those are invasive
and do not permit a generic reuse of the compiler.

You have my support for merging the stuff in Vala, but really it must be
generic so that maintainability is not a problem in the future.

On Sat, Nov 8, 2014 at 1:10 PM, Marek Gibek gib...@gmail.com wrote:

 Hi!

 I'm thinking of doing the same thing - use Vala to target Android,
 iOS, Windows Phone but also Windows and Linux at the same time!

 But I do not think that compiling to Java on Android or to objective c
 on iOS is required. We can simply create a native library from
 application code with standard vala-c-bin compilation process. And
 then write specific wrapper/library loader in Java/objective-c only if
 it's not possible to do it in C.

 That would require to port glib and gobject to every platform. Thanks
 for info about posixvala - this can be useful.

 I would go even further and I want to prepare the same API wrapper for
 all platforms. That would allow me to write code once and recompile
 for every platform. Abstraction of UI library will be more time
 consuming. Probably creating new one in OpenGL is an option here. As a
 bonus you can run the same app from the same code everywhere.

 I updated Vala plugin for MonoDevelop that runs fine on both Windows and
 Linux:
 https://github.com/marek-g/ValaBinding

 Now I'm working on more complex solution based on IntelliJ - the best
 IDE I am aware of. But it is not open-source for now.

 Actually it requires great amount of work. My dream is to find a
 sponsor or company that could hire me full-time and give me a small
 team to lead to create complete product. If someone is interested,
 this is my linked-in profile:

 http://pl.linkedin.com/in/marekgibek

 I think there is strong need on the market for such product!

 /Marek
 ___
 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] backwards compatibility

[Luca Bruno]

On 27/10/2014 09:08, Patrick Welche wrote:
 I'm new to vala and am wondering what compatibility between versions is
 like, e.g., should I expect to be able to use a recent 0.26.1 compiler
 to compile code from the days of 0.12?
You must expect every new stable release to be incompatible with the
previous. Either because of a compiler change, or because of bindings
breakage. That said, it's not that we break at every new stable release,
only when we feel it's best to break instead of keeping old obsolete things.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Posix profile

[Luca Bruno]

Note that we dropped the posix-backend support a while ago. Not to say we
wouldn't readd it, but we should think twice before adding it and removing
it back.

On Sun, Oct 26, 2014 at 3:27 PM, Johan Mattsson johan.mattsso...@gmail.com
wrote:

 I forked the master branch at github. Is there a development branch
 somewhere? I would like to follow it.
 /Johan
 ___
 vala-devel-list mailing list
 vala-devel-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/vala-devel-list




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

Re: [Vala] thread examples

[Luca Bruno]

On 24/10/2014 13:39, pancake wrote:
 I’ve been trying to update a program of me.. and noticed the threading api 
 has changed but all the
 examples in this page are deprecated:

 https://wiki.gnome.org/Projects/Vala/ThreadingSamples 
 https://wiki.gnome.org/Projects/Vala/ThreadingSamples

 What should be the way to go in the deprecating process for 
 documentation/examples?
I think just adding another example to that page with --target-glib 2.32
should be enough.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Const #defs after use: is this a known problem?

[Luca Bruno]

On 21/10/2014 02:14, Andy Lees wrote:
 If I have the following structure:

 public class Main : Object
 {
 
   static const int max_chans = 64;
 
   static int out_chans[max_chans];

 The compilation fails because the #defines for the const declarations are
 made after the declarations of the non-const arrays.  Is there a reason for
 this, or is it just a compiler error?
Known bug: https://bugzilla.gnome.org/show_bug.cgi?id=727667
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Help about write vapi file with c libray

[Luca Bruno]

On 26/09/2014 16:09, Matrix wrote:
 Hi:

 I'm try using Vala to write a GUI serialport tool with libserialport.

 I have already have a demo with pure c implenmention.

 I'm still working with write vapi file to this lib follow the tutorial
 at https://wiki.gnome.org/Projects/Vala/LegacyBindings

 but the c struct is init by this form:

 enum sp_return sp_get_port_by_name(const char *portname, struct
 sp_port **port_ptr);

 how do i to write for such form ?
class Port {
  [CCode (cname = sp_get_port_by_name)]
  static Return get_port_by_name (string portname, out Port);
}

Then:

Port port;
Port.get_port_by_name (foo, out port);
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Help about write vapi file with c libray

[Luca Bruno]

On 26/09/2014 16:44, Matrix wrote:
 在 2014/9/26 22:19, Luca Bruno 写道:
 On 26/09/2014 16:09, Matrix wrote:
 Hi:

 I'm try using Vala to write a GUI serialport tool with libserialport.

 I have already have a demo with pure c implenmention.

 I'm still working with write vapi file to this lib follow the tutorial
 at https://wiki.gnome.org/Projects/Vala/LegacyBindings

 but the c struct is init by this form:

 enum sp_return sp_get_port_by_name(const char *portname, struct
 sp_port **port_ptr);

 how do i to write for such form ?
 class Port {
[CCode (cname = sp_get_port_by_name)]
static Return get_port_by_name (string portname, out Port);
 }

 Then:

 Port port;
 Port.get_port_by_name (foo, out port);
 ___
 vala-list mailing list
 vala-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/vala-list

 Thank you, Luca Bruno!

 I follow your help, but have error

 there is my vapi file snippet:

 /*
 using GLib;

 namespace SerialPort {
 [CCode (cname = int, cprefix = SP_, has_type_id = false)]
 public enum Return {
 OK,
 ERR_ARG,
 ERR_FAIL,
 ERR_MEM,
 ERR_SUPP
 }

 [CCode (cname = struct sp_port, has_type_id = false)]
 public class Port {
 [CCode (cname = sp_get_port_by_name, has_type_id = false)]
 static Return get_port_by_name(string name, out Port);
 }
 }
 /***

 $ valac -C auto_test.vala --pkg libserialport
 Compilation failed: 1 error(s), 0 warning(s)
 libserialport.vapi:16.61-16.61: error: syntax error, expected identifier
 static Return open_get_by_name(string name, out Port);

Of course, out Port port :)
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] vala cross-compiling

[Luca Bruno]

On 15/09/2014 14:50, Michele Dionisio wrote:
 It is not possible any more to cross-compile vala after commit

 797a15747b7c0cb43ea7e13687f1af34f6e14ddf build: Avoid using .. for
 referencing paths and reorganize valac-calls
 7a4f0befbd58286a69367ba78d16187da25724f7build: Make building vapigen
 non-optional

 because the builded vala is used during compilation. But If I'm
 crosscomplling I cannot use the builded vala because I'n not on the target
 machine.
About the vapigen thing, you can still disable it from the configure.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

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

[Luca Bruno]

Is the process of creating win32 binaries available somewhere? We can set
up an auto builder.

On Mon, Sep 15, 2014 at 9:30 PM, Himanshu Goel hgoel0...@gmail.com wrote:

 Done. Vala 0.25.4 Windows builds are available at
 https://github.com/hgoel0974/ValaOnWindows-Binaries/releases/tag/0.25.4

 On Mon, Sep 15, 2014 at 2:12 PM, Himanshu Goel hgoel0...@gmail.com
 wrote:

  And I had just uploaded the 0.25.3 windows builds a few hours ago 
 Well,
  I'll have windows builds for this one in an hour
  On Sep 15, 2014 12:53 PM, Jürg Billeter j...@bitron.ch wrote:
 
  We are pleased to announce version 0.25.4 of Vala, a compiler for the
  GObject type system.
 
  Vala 0.25.4 is now available for download at:
 http://download.gnome.org/sources/vala/0.25/
 
  Changes since 0.25.3
   * Add option --vapi-comments.
   * Bug fixes and binding updates.
 
  Vala is a programming language that aims to bring modern programming
  language features to GNOME developers without imposing any additional
  runtime requirements and without using a different ABI compared to
  applications and libraries written in C.
 
  valac, the Vala compiler, is a self-hosting compiler that translates
  Vala source code into C source and header files. It uses the GObject
  type system to create classes and interfaces declared in the Vala source
  code.
 
  More information about Vala is available at
 
  http://www.vala-project.org/
 
 
  The Vala Team
 
  ---
  Evan Nemerson (1):
gtk+-2.0, gtk+-3.0: add missing GObject interface prerequisite
 
  Florian Brosch (2):
GirWriter: do not generate errordomain elements
xcb: re-add GetPropertyReply.format
 
  Jürg Billeter (1):
Release 0.25.4
 
  Luca Bruno (4):
Fix regression when assigning owned expressions to unowned
  variables.
Fix critical on method varargs introduced by 7b6ee1be
Resolve symbols in named arguments
girwriter: Write accessor methods for interface properties
 
  Richard Wiedenhöft (1):
Added option --vapi-comments to include comments in vapi-files
 
  Rico Tzschichholz (3):
bindings: Update GIR-based bindings
bindings: Update GIR-based bindings
gtk+-3.0: Update to 3.13.9~
 
  ___
  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




-- 
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] Type parameter not stored as expected

[Luca Bruno]

On 12/09/2014 02:31, Andy Lees wrote:
 Greetings,

 I have a data type used to store parser state declared as:
   class ReaderState {
 public Object obj;
 public bool in_array;
 public Type type;
 public TypeClass kl;

 public ReaderState (Object o, bool a, Type t, TypeClass k) {
   this.obj = o;
   this.in_array = a;
   this.type = t;
   this.klass = k;
 }
   }

Can you please provide a self-contained test case with a main() that I
can compile and run?
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] [ANNOUNCE] Portable Windows version (MonoDevelop 5.1.4, vala 0.25.1, mingw64 4.9.1)

[Luca Bruno]

Awesome thanks! Some other work had been done before:
http://www.tarnyko.net/en/?q=node/42


On Sat, Aug 30, 2014 at 11:36 AM, Marek Gibek gib...@gmail.com wrote:

 Hi All!

 I saw that many Windows users think that Vala is usable only under
 Linux. This is of course not true. I think it has enormous
 multiplatform potential. For me it lacks OpenGL based, MVVM (like WPF)
 mutliplatform UI framework, but that can be done...

 To make Vala more popular on Windows platform I created portable
 bundle ready to play with the language. It is based on
 MonoDevelop/XamarinStudio 5.1.4.

 You can download it there:
 
 https://sites.google.com/site/gibekm/programming/vala/windowsportable

 Screenshot:
 

 https://sites.google.com/site/gibekm/_/rsrc/1406733880544/programming/vala/windowsportable/screenshot.png


 My changes:
 

 There was obsolete MonoDovelop plugin for Vala. I updated it to
 version 5. I also rewritten code that handles project references.

 It behaves more like in C# and Visual Studio now:
 - paths to other projects in solution are now relative (so you can
 easily move solution folder)
 - output from referenced projects/libraries is copied to application
 output folder (it is much easier to deploy final application) -  it
 takes this info from .pc files (copy_to_output variable)
 - project references are pointing to .mdproj not output binary and are
 configuration (release/debug) aware now
 - fixed: compiler flags can be specified per configuration now

 It lacks code completion and debugger support. This can be added later
 (code completion was a part of previous version - the code needs to be
 converter to newer one).

 I haven't tested it under Linux, but it should be easy to port (if
 required) Vala plugin there, too.

 Regards,
 Marek Gibek
 ___
 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] Pass params through threads_add_idle()

[Luca Bruno]

Use Idle.add.


On Wed, Aug 27, 2014 at 8:11 PM, Gilzad Hamuni gil...@gmx.net wrote:

 Hi all,
 I'm trying to pass a parameter to a function that I call through
 threads_add_idle().
 But threads_add_idle() obviously accepts only a SourceFunc.
 I can't pick up the data from a global variable. So I tried using closures
 from where I'd pass the needed parameter:

 private void ThreadedFunc(uint 8 byte)
 {
   Gdk.threads_add_idle(()=
   {
 GuiWorker(byte);
 return false;
   });
 }

 But then the class of GuiWorker is not instantiated, so I get an assertion
 during runtime (self != null). If I don't try to pass the parameter and
 just pass 'GuiWorker' to threads_add_idle() directly (given 'GuiWorker'
 doesn't take any params then), then the instance does exist.

 Before that, when I used the deprecated methods Gdk.threads_enter() and
 Gdk.threads_leave(), I could help myself by doing whatever I wanted in
 between. But how can I work with threads_add_idle() now? The vala bindings
 omit its second parameter 'data', so I'd be glad if you could tell me how
 do it 'the right way'.

 Thanks a bunch.

 gilzad
 ___
 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] DBus and memory leaks?

[Luca Bruno]

Try with a (very) recent valac, possibly git master. We fixed a memory leak
about hashtables with variant values. It might be that.


On Fri, Jun 20, 2014 at 11:03 PM, Eugenio 'g7' Paolantonio m...@medesimo.eu
wrote:

 Hello!

 I'm writing a notification daemon using vala and GTK+.
 This of course uses DBus (and the org.freedesktop.Notifications domain,
 following the spec at https://developer.gnome.org/notification-spec/).

 While everything works so far, I have a strange problem: when an
 application sends a notification with the 'image-data' (or the
 deprecated 'icon_data') hint (which is a raw image data structure, see
 https://developer.gnome.org/notification-spec/#images) the notification
 daemon grows up in RAM usage.

 For example, when spotify sends a notification, the RAM usage of the
 daemon grows to 42 MB (from 2 MB).
 When another notification goes in, the usage doubles... and I get 81 MB
 of RAM usage.
 This happens too with other music player such as exaile.

 No problems instead for conventional notifications.

 A stripped-out version of the notification daemon is here:
 http://pastebin.com/jPeSB0Nb

 It's really simple, no GTK+ at all, and the Notify() method is empty.
 Unfortunately also this version has the same memory leak problem. :(

 I'm running Debian sid with valac 0.24 (but I've tried also with 0.22
 and 0.20 with no luck).

 Any pointers are appreciated: this has been driving me mad for the last
 two days! :)

 Thank you in advance,
 Eugenio

 --
 Eugenio Paolantonio
 http://me.medesimo.eu - @eugenio_g7

 .:: Is this too good to be true? http://semplice-linux.org ::.
 ___
 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

[Luca Bruno]

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 ric...@t-online.de
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

Re: [Vala] Gtk+ bindings update

[Luca Bruno]

Why is it a requirement? For which applications?


On Thu, Aug 21, 2014 at 8:57 PM, Jim Nelson j...@yorba.org 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 lethalma...@gmail.com
 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 ric...@t-online.de
 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

[Luca Bruno]

Sorry the question was for Rico.


On Thu, Aug 21, 2014 at 9:04 PM, Jim Nelson j...@yorba.org wrote:

 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 lethalma...@gmail.com
 wrote:

 Why is it a requirement? For which applications?


 On Thu, Aug 21, 2014 at 8:57 PM, Jim Nelson j...@yorba.org 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 lethalma...@gmail.com
 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 
 ric...@t-online.de 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




-- 
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

[Luca Bruno]

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.

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?


On Thu, Aug 21, 2014 at 9:31 PM, Evan Nemerson e...@coeus-group.com wrote:

 They're in the staging branch.  For Geary, the relevant error is at

 http://paldo.org:8010/builders/vala-staging/builds/44/steps/geary/logs/stdio

 This is due to the binding for Gtk.Window.set_default_icon_list's
 argument becoming owned.  The change is correct according to the
 annotations in GTK+.

 Currently, Vala will free the list after passing it to
 set_default_icon_list, which could result in a use-after-free inside of
 GTK+, potentially causing Geary to crash.  In this case, it looks like
 the best thing to do would be simply change line
 src/client/components/main-window.vala:62-64 to

 GLib.Listunowned Gdk.Pixbuf pixbuf_list = new
 GLib.Listunowned Gdk.Pixbuf();
 pixbuf_list.append(IconFactory.instance.application_icon);
 set_default_icon_list((owned) pixbuf_list);

 Now that they know about the potential crash, I suppose it's up to Jim
 whether or not it's a requirement, but I would think so.

 There should be quite a few other changes like this which would be great
 to have this cycle, as well as lots of changes to make currently useless
 API (i.e., stuff which generates invalid C) usable which we don't have
 to worry about the API for as they obviously weren't in use.
 Unfortunately, there are also a lot of things which break API for less
 urgent reasons (like fixing memory leaks) mixed in, which could wait for
 next cycle.  However, Rico has already put a lot of work in to this, I'm
 not sure it's fair to ask him to split those out as it would require
 quite a bit of additional effort.

 -E


 On Thu, 2014-08-21 at 12:04 -0700, Jim Nelson wrote:
  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 lethalma...@gmail.com
  wrote:
   Why is it a requirement? For which applications?
  
  
   On Thu, Aug 21, 2014 at 8:57 PM, Jim Nelson j...@yorba.org 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 lethalma...@gmail.com
   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
   ric...@t-online.de
   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


 ___
 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

[Luca Bruno]

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 e...@coeus-group.com 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

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

[Luca Bruno]

On 23/07/2014 12:03, Jürg Billeter wrote:
 Changes since 0.24.0
  * Support explicit interface method implementation.
  * Support (unowned type)[] syntax.
  * Support non-literal length in fixed-size arrays.
  * Mark regular expression literals as stable.
  * GIR parser updates.
  * Add webkit2gtk-3.0 bindings.
  * Add gstreamer-allocators-1.0 and gstreamer-riff-1.0 bindings.
  * Bug fixes and binding updates.
About the new features I suggest  reading
http://valajournal.blogspot.it/2014/07/vala-0251-released.html .
We explain how to use the new explicit interface method implementation
and give some good advice.

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

Re: [Vala] box array does not work

[Luca Bruno]

On 18/07/2014 11:51, Michele Dionisio wrote:
 Hi all,

 I try to defive an object like:

 Gee.TreeMap uint8[] ?, FileInformation 

 where FileInformation is class.

 I have boxed uint8[] with ?

 but I receive fro valac 0.24 the following error

 error: `uint8[]?' is not a supported generic type argument, use `?' to box
 value types

 I think that it is a valac bug. Is it true?
Not a bug, it's a valac error because you cannot box an array. Just what
the messages says.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] box array does not work

[Luca Bruno]

On 18/07/2014 12:22, Michele Dionisio wrote:
 but the message sya that I have to box it.
The message is wrong.

 Can you explain me why I cannot box an array?
Because arrays in vala carry a length. Use a pointer and manage the
memory manually, like TreeMapuint8*, FileInformation.
Or wrap your uint8[] array in a class.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] cairo binding bug?

[Luca Bruno]

On 26/06/2014 03:24, Nor Jaidi Tuah wrote:
 According to http://www.cairographics.org/manual/cairo-Paths.html,

The path may be either the return value from one of cairo_copy_path()
or cairo_copy_path_flat() or it may be constructed manually.

 But, trying to construct a path manually, i.e.,

   var path = new Cairo.Path ();

 gives a compiler error:

   error: `Cairo.Path' does not have a default constructor

 Am I doing this the wrong way, or is this a binding bug?
See http://valadoc.org/#!api=cairo/Cairo.Context.new_path
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Vala SFML

[Luca Bruno]

On 26/06/2014 12:05, Raphael Isemann wrote:
 Hey everybody,

 i played around with SFML some time ago and i thought i just dump the
 results here on the Mailing List ;)

 # Example Game

 I made a example-game here: https://bitbucket.org/Teemperor/maans and
 here is a old video about it: http://teemperor.de/video4.ogv (warning:
 40MB ogv)
 It only depends on csfml-2.0 (so the sfml2 C-bindings) and a recent
 glib/gio version.
 To build it simply run cmake in a external build-directory like:

 $ mkdir build  cd build  cmake . ..  make  ./maans

 NOTE: the SFML2 C-Headers need to be a t SFML/Graphics.h to work,
 otherwise adjust the top of the vapi-files accordingly.

 All source for the game (if not otherwise specified in the header) is
 released as Public Domain.

 # Crosscompile to Windows

 As everybody is curious about how to cross-compile that to windows i
 posted the enviroment i use for my daily windows-builds here:
 http://teemperor.de/dl/dist.zip

 For those who want to run untrusted code from the internet (that you
 downloaded over HTTP), here are the Windows-Nightlies:
 http://teemperor.de/dl/maans/maans-win.zip

 Just unzip it and look at the included shell-file (where you need to
 adjust a path to point to the right directory). Thanks to tarnyko for
 the gtk3-win32 bundle which containes all libraries needed for
 cross-compiling and his tutorial for that
 (http://www.tarnyko.net/en/?q=node/45).
 Obvious note: You need gcc-msvc for cross-compiling.

 # VAPIs

 I used the bindings from hohoo
 (https://bitbucket.org/hohoo/vala-sfml/src) at the beginning, but i
 rewrote them from scratch for the biggest part that they now use
 properties and don't throw compile-errors. I released them under
 Public Domain (i think i rewrote enough from scratch that i can do
 that, IANAL).

 I also release all Typos in this mail as Public Domain, so feel free
 to reuse them.

 Anyway, have fun with that, just reply if you have a question about
 the code or compile-errors.
Nice job. You could ask for inclusion in
https://github.com/nemequ/vala-extra-vapis
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] wip/transform branch in git

[Luca Bruno]

On 25/06/2014 11:31, Tadeusz Szczyrba wrote:
 Hello,


 Several questions:

 1) when could I expect ( if should I ) the wip/transform branch to be
 merged with master?
When it's ready :)
 2) where should I report bugs (regressions) in wip/transform branch - to
 regular vala bugzilla?
Since it's a wip branch there's no real place for reporting bugs. But
maybe we can open a single bug for all the wip/transform bugs.
Feel free to open it and list all your concerns there.
 The idea of separate transformation from check() seems to be very
 attractive - it opens the possibility for vala library to be foundation
 of code refactoring tools / IDEs.

 Besides keeping out transformation from semantic analysis maybe would be
 reasonable to implement keeping in AST original representations of
 terminals  non-terminals to be able to provide 100% reliable dump of
 parserd  analyzed source
 code - this way implementing more advanced IDEs with refactoring
 capabilities with libvala should be much simpler,
The transormations are a runtime thing, that has nothing to do with IDE
refactoring, which is already doable with libvala.

Best regards,

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

Re: [Vala] wip/transform branch in git

[Luca Bruno]

On 25/06/2014 14:20, Tadeusz Szczyrba wrote:
 So I will answer from another side: what is the indicator, that wip is
 or is not ready?


 So today's evening I'll open bug for WIP/Transform bugs in vala bugzilla.

 And maybe should I ask next question: when one prepares patch for
 particular bug where should it be sent to? Or maybe send git pull
 requests?
 In Vala hacking I haven't found clear answer for that question above.

Simply attach a patch to bugzilla. wip/transform is of course not ready,
otherwise it would have been merged :)
It's already working for most things, the last bug I hit was with dbus
(e.g. try compiling rygel with wip/transform and you'll able to
reproduce that).
In other words, everything is set, many bugs have already been fixed, so
it's only about fixing the remaining bugs that have been of course
introduced by the massive refactoring.
 How is it possible directly when the parser, lexer and semantical
 analysis loose information ( white-spaces, comments, '@' operator,
 loops shape etc.) ? wip branch now also doesn't solve all of these, but
 anyway
 it seems to be the step in right direction.
wip/transform has nothing to do with that. It avoids losing information
in the ast analysis - codegen step.
It brings codegen stuff at the ast level AND moves ast transformations
after the control flow analysis to avoid losing information
in the control flow step.
You can read a detailed overview here:
http://valajournal.blogspot.com/2014/02/what-to-expect-from-wiptransform-branch.html
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] generated c code and properties

[Luca Bruno]

Sorry I've read your post several times, but I don't understand what Vala
generated code is missing. Can you please provide vala code and say what
the generated C code is missing?


On Fri, Jun 6, 2014 at 6:19 PM, Brian thebutterkn...@gmail.com wrote:

 Hi all,
 I've searched high and low for some information, but have been unable to
 find
 any on this particular situation.

 Hand coding GObjects in C allows for one get and one set function that take
 property id as an input. For example:

 object_set_property (GObject * object, guint property_id, Gvalue,
 GParamSpec);

 And then a switch case statement inside the set function uses the
 property_id
 to decide which property to set. the property_id values are defined with an
 enum.

 When coding GObjects in vala, however, each property is given its own get
 and
 set function in the C code.  The funny thing is I still see a property
 value
 enum (that does not get filled out), as well as the generic get and set
 functions with empty (default only) switch case statements.

 I already have gobject bindings that use the generic get/set functions. I'd
 rather not have to edit the vala-generated C code to use them.

 My question is, is there a way to get vala to automatically generate the
 enums, and switch case statements? If not, is there a recommended approach?

 I love the idea of not having to write all the GObject boilerplate and
 writing
 in vala rather than C. I really hope that I'm just missing something. Any
 help
 or ideas are much appreciated.

 Brian

 ___
 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] generated c code and properties

[Luca Bruno]

Sorry, where did you read that in the documentation?


On Mon, Jun 9, 2014 at 9:06 PM, Brian Grooman thebutterkn...@gmail.com
wrote:

 I just figured out the problem a few hours ago.

 The documentation recommends declaring properties in two parts, the value
 and the getter/setter block.  so, for example:

 int _myvalue;

 public int myvalue{get; set;}

 The leading underscore on the int is there to prevent a naming conflict.

 I'm using vala to rewrite existing C code with gobjects.  I did not want
 to rename the variables, so I instead put the underscore in front of the
 getter/setter block, as so:

 int myvalue;

 public int _myvalue{get; set;}

 I guess valac didn't like that.  It would skip generating much of the
 code.  Anyway, i found that you don't need to declare the variable at all:

 public int myvalue{get; set;}

 works just fine by itself.  A stupid mistake on my part.



 On Mon, Jun 9, 2014 at 2:49 PM, Luca Bruno lethalma...@gmail.com wrote:

 Sorry I've read your post several times, but I don't understand what Vala
 generated code is missing. Can you please provide vala code and say what
 the generated C code is missing?


 On Fri, Jun 6, 2014 at 6:19 PM, Brian thebutterkn...@gmail.com wrote:

 Hi all,
 I've searched high and low for some information, but have been unable to
 find
 any on this particular situation.

 Hand coding GObjects in C allows for one get and one set function that
 take
 property id as an input. For example:

 object_set_property (GObject * object, guint property_id, Gvalue,
 GParamSpec);

 And then a switch case statement inside the set function uses the
 property_id
 to decide which property to set. the property_id values are defined with
 an
 enum.

 When coding GObjects in vala, however, each property is given its own
 get and
 set function in the C code.  The funny thing is I still see a property
 value
 enum (that does not get filled out), as well as the generic get and set
 functions with empty (default only) switch case statements.

 I already have gobject bindings that use the generic get/set functions.
 I'd
 rather not have to edit the vala-generated C code to use them.

 My question is, is there a way to get vala to automatically generate the
 enums, and switch case statements? If not, is there a recommended
 approach?

 I love the idea of not having to write all the GObject boilerplate and
 writing
 in vala rather than C. I really hope that I'm just missing something.
 Any help
 or ideas are much appreciated.

 Brian

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




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





-- 
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] set relief style in a toolbutton

[Luca Bruno]

Toolbutton is a Bin. Check whether its direct child is a button.


On Tue, Jun 3, 2014 at 1:20 PM, rastersoft ras...@rastersoft.com wrote:

 Hi all:

 I'm using a toolbar with some toolbuttons and menutoolbuttons, and I'm
 unable of setting the relief style for them. I want them to look like a
 button, not just flat.

 I revised the whole API available in Valadoc but I'm unable to find how to
 do it. For classic buttons there is set_relief, but can't find the
 equivalent for toolbuttons.

 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




-- 
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] Parallel programming in Vala?

[Luca Bruno]

On 27/05/2014 14:12, Costas Smaragdakis wrote:
 Hello,

 I am currently a PhD student at University of Crete (Dept. of Applied
 Mathematics).

 So far, I have been developing my code mainly in Matlab and sometimes in
 C.
 However, I would like to get rid of the licenses and use only free
 software.

 My first thought was to develop exclusively in C (I love it) but it
 would be a step backward for my productivity.

 Then, I considered the Python language as a good alternative but
 I don't like its syntax and I would prefer to avoid scripting languages.

 I am a big fan of Gnome 3, so I thought that using of the Vala
 programming language for my research programming would be a good idea. I
 looked up in the vala documentation and really I love the features of
 Vala. 

 Nevertheless, I wonder if I could use Vala for parallel computations
 using a parallel toolbox like mpich, openmpi or CUDA.This is significant
 for me because I am going to run my code using the facilities of
 University. Does someone use Vala for scientific calculations? I already
 have found out that there is a gsl port to Vala!  
There's no such thing in Vala and I wouldn't suggest you to use Vala for
this kind of job.
Look for c++, fortran, java and such.
The best you can do in Vala is spawning processes or threads.

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

Re: [Vala] Memory safety

[Luca Bruno]

On 15/05/2014 10:18, Florian Weimer wrote:

Hi,

am I correct in assuming that Vala is supposed to inherit the lack of 
memory safety from C?  Or put differently: If there is Vala code that 
does not guard callers from memory safety violations but it could do 
so, this is not a problem because callers are generally expected to 
fulfill such (implicit) preconditions.


Vala inherits the problem of C, yes. You could certainly do some evil 
casts like in C. Vala however is certainly safer than C in many aspects, 
in other aspects however you have to know what you are doing and how 
Vala compiles down to C in certain cases.

For example:
1. func1(): create a local array
2. Call async func2(array) without waiting the function to finish
3. Return from func1
4. func2 runs with a dangling pointer to the array

Vala is not free of rough edges, it makes your life easier. But since a 
Vala array is a standard C array, it can't be referenced counted and 
that's why you get the above (unwanted from a newbie perspective) behavior.


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

Re: [Vala] About method overloading, constructor overloading and extension methods

[Luca Bruno]

Also method overloading is the worst mistake a language could do. It's
tricky, it does not always work as the user expects, it has weird
semantics. Even if we didn't care about C naming, I would never implement
method overloading in a sane language.


On Thu, May 15, 2014 at 8:22 PM, Evan Nemerson e...@coeus-group.com wrote:

 On Thu, 2014-05-15 at 14:48 -0300, geovanisouz...@gmail.com wrote:
  Hello guys,
 
  I'm thinking about the reasons behind the pseudo constructor overload,
  method naming convensions and C# entension methods.
 
  I don't look deep in Vala compiler implementation, but can suggested
  something to resolve this issue, based in what I see in generated C
 code: a
  name binder.
 
  Some kind of naming engine to rule 'em all, where the compiler can
 register
  all found method names (with types, the complete signature), and from the
  code writer can peek the C method names. For example, in the code:
 
  int add(int a, int b)
  {
  return a + b;
  }
 
  int main(string[] args)
  {
  var result = add(2, 3);
  print(Result: %d\n.printf(result));
  return 0;
  }
 
 
  All works fine, and the resulting C code:
 
  gint add (gint a, gint b) {
   gint result = 0;
  gint _tmp0_ = 0;
   gint _tmp1_ = 0;
  _tmp0_ = a;
   _tmp1_ = b;
  result = _tmp0_ + _tmp1_;
   return result;
  }
 
 
  gint _vala_main (gchar** args, int args_length1) {
  gint result = 0;
   gint _result_ = 0;
  gint _tmp0_ = 0;
   gchar* _tmp1_ = NULL;
  gchar* _tmp2_ = NULL;
   _tmp0_ = add (2, 3);
  _result_ = _tmp0_;
   _tmp1_ = g_strdup_printf (Result: %d\n, _result_);
  _tmp2_ = _tmp1_;
   g_print (%s, _tmp2_);
  _g_free0 (_tmp2_);
   result = 0;
  return result;
  }
 
 
  int main (int argc, char ** argv) {
  #if !GLIB_CHECK_VERSION (2,35,0)
  g_type_init ();
  #endif
  return _vala_main (argv, argc);
  }
 
 
  Well, fine. But if I declare another method, like:
 
  float add(float a, float b)
  {
  return a + b;
  }
 
 
  The compiler forbid me.
 
  I know that the recomended way to solve this is use diferent names for
  methods:
 
  float add_float(float a, float b)
  {
  return a + b;
  }
 
  int add_int(int a, int b)
  {
  return a + b;
  }
 
 
  And again, all works.
 
  But, if this is the recommended way to make it work, why the compiler
  itself doesn't do this for me? I would that this naming binder can
 expand:

 It is called mangling.  See https://en.wikipedia.org/wiki/Name_mangling

 We don't do it because we care about the C API—libraries written in Vala
 are meant to be usable from other languages, which means providing a
 *good* C API.  This simply can't be done automatically—the only way
 would be to force the user to choose the mangled names themselves, so
 you would end up with something like

 [CCode (cname = add_float)]
 public float add (float a, float b);
 [CCode (cname = add_int)]
 public int add (int a, int b);

 If you still have to provide the names yourself, the only benefit is
 that in Vala you can just use add (instead of add_float and add_int).
 The drawbacks include the Vala API being different from other languages
 and the code being more difficult to read and reason about.

 
  float add(float a, float b)
  int add(int a, int b)
 
 
  To something like this:
 
  gint add__int__int (gint a, gint b)
  gfloat add__float__float (gfloat a, gfloat b)
 
 
  Anyway, if the C compiler support overloading, why Vala does not?

 It doesn't.  Vala targets C89, and C doesn't support overloading (well,
 generic selection) until C11.  MSVC still doesn't support C99, let alone
 C11, and GCC doesn't support _Generic until 4.9 (which was just released
 about 3 weeks ago).

  In case of extension methods, it can be expanded too, and only gain
 context
  when included and used in source files. In C the
  pseudo-object-oriented-programming is made passing the this (or in Vala
  self) variable to each function, thing made transparently by
  compilers/runtimes of other languages.
 
  Extension methods is basically like C functions (receiving a self
  reference) and mapped/validated by compiler when
  object.extension_method() is used.
 
  So, which effort is necessary to make Vala compiler accept this feature?
 I
  think that a centralized naming logic can help in these cases.

 Extension methods are tricky, but we could conceivably support them (see
 https://bugzilla.gnome.org/show_bug.cgi?id=681097).  That said, there
 isn't any need for additional name mangling logic.  The name can (and
 should) be generated based on the location of the extension method, not
 the object being extended.


 -Evan

 ___
 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] About method overloading, constructor overloading and extension methods

[Luca Bruno]

I'm all for extension methods, as long as they don't require too much
syntax, it's simple, there's as little magic as possible, don't break
things and are not invasive in the compiler.
Basically, we haven't decided the syntax yet.
In my opinion it should be as simple as this:

extend SomeClassName {
  public void foo () { }
}



On Thu, May 15, 2014 at 8:37 PM, geovanisouz...@gmail.com 
geovanisouz...@gmail.com wrote:

 Thank yout Evan, Luca and Aaron for explanation. I didn't see the archives
 for the historical debates. I agree with you.

 At all, with my experience with Python, the Zen says explicit is better
 than implicit. The overload is a features that facilitate the programmer's
 life, but not the life of compiler maintainers...

 What about extensions methods? Already discussed or not implemented yet?
 The .NET Linq was brought to life based on it. Without EM (and generics, of
 course) Linq wouldn't possible.

 I imagine that Gee guys can help this discussion too.
 ​
 ___
 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] location of generated vala source under autotools

[Luca Bruno]

On 30/04/2014 16:39, Andy Tai wrote:

Hi, when using Vala with GNU autotools, if building from somewhere outside
the source directory, as commonly with something like

(from the top of source tree)
cd ../
mkdir build
cd build
../src/configure  make

the intermediate C sources generated from Vala are placed in the source
tree instead of the build tree.  This seems to work, but is it the correct
behavior in terms of the build behavior?


Vala is known to not be able to build out of tree. There's a bug which 
should fix this: https://bugzilla.gnome.org/show_bug.cgi?id=725497 .

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

Re: [Vala] gtk init args

[Luca Bruno]

Simply parse args afterwards like you would do without the gtk init.


On Wed, Apr 30, 2014 at 8:31 PM, Max maxim.sur...@campus.tu-berlin.dewrote:

 Hi.

 I've often seen following code in examples:

 void main(string[] args) {
 ...
   Gtk.init(ref args);
 ...
   new MainLoop().run();
 }

 Could you clarify - why does gtk init requires program arguments? And how
 can we
 combine this with parsing regular command-line arguments like --version
 --out-file=lol.log etc.?

 cheers,
 Max.

 ___
 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] Recommended way for combined C with Vala/Genie project?

[Luca Bruno]

On Mon, Apr 28, 2014 at 8:52 PM, Al Thomas astav...@yahoo.co.uk wrote:

 I've just got this error that made me wonder about valac's hidden
 capabilities:

 error: test.g is not a supported source file type. Only .vala, .vapi, .gs,
 and .c files are supported.

 I assume a .c file is passed straight through to the C compiler along with
 the generated C files from .vala and .gs files. Is this a recommended way
 of creating a combined C with Vala/Genie project?


First create vala/gs - C files, then also specify other C files, and
finally compile all C files with gcc. Autotools does all that for you.


 I note XFCE decided to combine C with Vala. From a couple of blog post
 [1][2] it looks as though they use automake to create C files from Vala and
 then distribute and compile those files for the whole project. The argument
 being different versions of valac can produce different C files so it is
 more stable for a distributed version to build from the generated C files.


It's true that it's more stable to compile directly the C files, but #if
conditions in vala won't get evaluated then. That is, once you have
compiled vala down to C, the #if conditions *in vala* can't be re-evaluated
anymore. That's a huge tradeoff you should care about.
I don't suggest to compile directly the distributed C files, rather compile
Vala. You can conditionate your code to run, e.g., with vala 0.22, 0.24...
to fix incompatibilities.



 I also found the Parallel Builds [3] page. This is an interesting approach
 with, as I understand it, an intermediate object file for each vala file.
 These could be linked with object files from C or C++.


No the intermediate file is a special vapi file, those are not object files
understood by gcc.



 Then there is the --compile option of valac to produce object files.


Use valac only to generate C, not as a build tool.



 So at the moment I'm thinking for large, mixed language projects, it is
 better to create object files and link outside of valac.

 I am writing some documentation for Genie and was about to finish the
 attached diagram with arrows when I stumbled upon valac accepting .c files.
 At present I'm thinking this feature isn't too useful and it is better to
 create object files and link using another tool. This is also useful for
 GIR and using Vala/Genie binaries in Python, node.js, PHP, etc. So it is
 probably better for documentation to introduce the more general process.


Drop the idea to create a large project by using valac as build tool. Use
autotools. There's plenty of projecs out there to look at, first of all the
sample vala project: https://github.com/tadeboro/Sampala
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] How to implement the get_type method of Gst.URIHandler interface in vala?

[Luca Bruno]

On 18/03/2014 23:25, Lei Miao wrote:

That worked! Thank you so much for the help!

I still have a related question though:

In the following function in the generated c code,

static gchar**my_streaming_source_real_get_protocols (GstURIHandler* 
base, GType type, int* result_length1) {

MyStreamingSource * self;
gchar** result = NULL;
gchar** _tmp0_ = NULL;
gint _tmp0__length1 = 0;
self = (MyStreamingSource*) base;
_tmp0_ = MY_STREAMING_SOURCE_protocols;
_tmp0__length1 = G_N_ELEMENTS (MY_STREAMING_SOURCE_protocols);
if (result_length1) {
*result_length1 = _tmp0__length1;
}
result = _tmp0_;
return result;
}

the last argument int* result_length1 somehow is causing seg faults. 
If I remove this argument manually, then the problem goes away.


I was wondering why this argument is added, since in the vapi, I only 
have:


[CCode (array_length = false, array_null_terminated = true)]
public abstract unowned string[] get_protocols (GLib.Type type);

and in the vala code, I have

public unowned string[] get_protocols(Type type) { return protocols; 
} where protocols is a string array.


Is there a way to remove this argument in the generated c code?
Try putting [CCode (array_length = false, array_null_terminated = true)] 
on your method as well.
Also if you can, please report a bug. That CCode should have been 
inherited automatically by vala.

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

Re: [Vala] How to implement the get_type method of Gst.URIHandler interface in vala?

[Luca Bruno]

On 17/03/2014 20:29, Lei Miao wrote:

Thanks for pointing out the typo.

Unfortunately, it doesn't resolve the problem.

Below is what I have right now in gstreamer-1.0.vapi:

[CCode (cheader_filename = gst/gst.h, type_cname = 
GstURIHandlerInterface, type_id = gst_uri_handler_get_type ())]

public interface URIHandler : GLib.Object {
[CCode (array_length = false, array_null_terminated = true)]
public abstract unowned string[] get_protocols (GLib.Type type);
public abstract string get_uri ();
[CCode (vfunc_name = get_type)]
public abstract Gst.URIType get_uri_type (GLib.Type type);
public abstract bool set_uri (string uri) throws GLib.Error;
}

In the generated c file, I have:

iface-get_protocols = (gchar** (*)(GstURIHandler*, GType)) ...
iface-get_uri_type = (GstURIType (*)(GstURIHandler*, GType)) ...
iface-get_uri = (gchar* (*)(GstURIHandler*)) ...
iface-set_uri = (gboolean (*)(GstURIHandler*, const gchar*, 
GError**)) ...


It won't compile due to the following error:
error: 'GstURIHandlerInterface' has no member named 'get_uri_type'

If I manually change iface-get_uri_type to iface-get_type, then 
it compiles.

Mh ok. Try putting vfunc_name also when implementing the method.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] [Genie] Re: Vala on Android

[Luca Bruno]

On 18/03/2014 02: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?

Awesome thanks. Genie indeed needs some love from its users.
___
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)

[Luca Bruno]

http://valajournal.blogspot.it/


On Tue, Mar 18, 2014 at 7:06 PM, Jim Nelson j...@yorba.org wrote:

 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 e...@coeus-group.com
 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 txasato...@gmail.com
  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




-- 
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] How to implement the get_type method of Gst.URIHandler interface in vala?

[Luca Bruno]

On 16/03/2014 22:33, Lei Miao wrote:

Yes, I tried it, but it has no effect.

I have the following in my vala code:
...
[CCode (vfunc = get_type)]
public URIType get_uri_type (Type type) { return URIType.SRC; }
...

Is it what you recommended?

Basically, the problem is that iface-get_type =... is missing in 
...gst_uri_handler_interface_init() function in the generated c file.


Regards,
Sorry, vfunc_name: 
https://git.gnome.org/browse/vala/tree/vapi/gio-2.0.vapi#n1365


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

Re: [Vala] How to implement the get_type method of Gst.URIHandler interface in vala?

[Luca Bruno]

I don't understand what you mean by gstreamer uses get_type, can you point
to the specific C method?


On Sat, Mar 15, 2014 at 4:05 PM, Lei Miao leimia...@gmail.com wrote:

 Thank you for the response.

 I could implement get_uri_type, but the problem is that gstreamer uses
 get_type.

 If I can implement get_type in vala, then I don't have to modify gstreamer
 code.

 Regards,

 LM
 On Mar 14, 2014 5:30 PM, Luca Bruno lethalma...@gmail.com wrote:

 I don't understand why you are using get_type. Implement get_uri_type.


 On Fri, Mar 14, 2014 at 10:21 PM, Lei Miao leimia...@gmail.com wrote:

 Hi,

 I am trying to write a gstreamer 1.0 plugin using vala. However, I am
 having trouble to implement the get_type() method of the Gst.URIHandler
 interface defined here:

 http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gstreamer-GstUriHandler.html#GstURIHandlerInterface
 .

 In particular, my class inherits Gst.bin and implements Gst.URIHandler
 interface:

  public class StreamingSource: Gst.Bin, Gst.URIHandler {

 ...

 public URIType get_type (Type type) { return URIType.SRC; }

 ...
 }

 When I compile the vala code to c code, I get the following error:

 StreamingSource.get_type hides inherited method `GLib.Object.get_type'.
 Use
 the `new' keyword if hiding was intentional
 public URIType get_type (Type type) { return
 URIType.SRC; }

 The problem seems to be that GLib.Object also has a method called
 get_type. So in this case, does anybody know how I can implement the
 get_type method of Gst.URIHandler?

 It's worth noting that according to this link:
 http://references.valadoc.org/#!api=gstreamer-1.0/Gst.URIHandler , the
 method is called get_uri_type() instead. This is inconsistent with the
 gstreamer 1.0 reference manual. In fact, Gstreamer code has both methods
 defined, but it uses get_type() for element registration.

 Regards,

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




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




-- 
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] How to implement the get_type method of Gst.URIHandler interface in vala?

[Luca Bruno]

Try [CCode (vfunc = get_type)] or such, see gio vapi for some examples
about read_fn.


On Sun, Mar 16, 2014 at 10:05 AM, Abderrahim Kitouni a.kito...@gmail.comwrote:

 Hi,

 I've looked at thé gst docs and the vfunc for get_uri_type is called
 get_type.

 HTH,

 On March 16, 2014 9:19:34 AM CET, Luca Bruno lethalma...@gmail.com
 wrote:

 I don't understand what you mean by gstreamer uses get_type, can you point
 to the specific C method?


 On Sat, Mar 15, 2014 at 4:05 PM, Lei Miao leimia...@gmail.com wrote:

  Thank you for the response.

  I could implement get_uri_type, but the problem is that gstreamer uses
  get_type.

  If I can implement get_type in vala, then I don't have to modify gstreamer
  code.

  Regards,

  LM
  On Mar 14, 2014 5:30 PM, Luca Bruno lethalma...@gmail.com wrote:

  I don't understand why you are using get_type. Implement get_uri_type.


  On Fri, Mar 14, 2014 at 10:21 PM, Lei Miao leimia...@gmail.com wrote:

  Hi,

  I am trying to write a gstreamer 1.0 plugin using vala. However, I am
  having trouble to implement the get_type() method of the Gst.URIHandler
  interface defined here:

  
 http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gstreamer-GstUriHandler.html#GstURIHandlerInterface
  .

  In particular, my class inherits Gst.bin and implements Gst.URIHandler
  interface:

   public class StreamingSource: Gst.Bin, Gst.URIHandler {

  ...

  public URIType get_type (Type type) { return URIType.SRC; }

  ...
  }

  When I compile the vala code to c code, I get the following error:


 StreamingSource.get_type hides inherited method `GLib.Object.get_type'.
  Use
  the `new' keyword if hiding was intentional
  public URIType get_type (Type type) { return
  URIType.SRC; }

  The problem seems to be that GLib.Object also has a method called
  get_type. So in this case, does anybody know how I can implement the
  get_type method of Gst.URIHandler?

  It's worth noting that according to this link:
  http://references.valadoc.org/#!api=gstreamer-1.0/Gst.URIHandler , the
  method is called get_uri_type() instead. This is inconsistent with the
  gstreamer 1.0 reference manual. In fact, Gstreamer code has both methods
  defined, but it uses get_type() for element registration.

  Regards,

  LM
 --

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





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





 --
 Sent from my Android device with K-9 Mail. Please excuse my brevity.




-- 
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] How to implement the get_type method of Gst.URIHandler interface in vala?

[Luca Bruno]

I don't understand why you are using get_type. Implement get_uri_type.


On Fri, Mar 14, 2014 at 10:21 PM, Lei Miao leimia...@gmail.com wrote:

 Hi,

 I am trying to write a gstreamer 1.0 plugin using vala. However, I am
 having trouble to implement the get_type() method of the Gst.URIHandler
 interface defined here:

 http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gstreamer-GstUriHandler.html#GstURIHandlerInterface
 .

 In particular, my class inherits Gst.bin and implements Gst.URIHandler
 interface:

  public class StreamingSource: Gst.Bin, Gst.URIHandler {

 ...

 public URIType get_type (Type type) { return URIType.SRC; }

 ...
 }

 When I compile the vala code to c code, I get the following error:

 StreamingSource.get_type hides inherited method `GLib.Object.get_type'. Use
 the `new' keyword if hiding was intentional
 public URIType get_type (Type type) { return URIType.SRC; }

 The problem seems to be that GLib.Object also has a method called
 get_type. So in this case, does anybody know how I can implement the
 get_type method of Gst.URIHandler?

 It's worth noting that according to this link:
 http://references.valadoc.org/#!api=gstreamer-1.0/Gst.URIHandler , the
 method is called get_uri_type() instead. This is inconsistent with the
 gstreamer 1.0 reference manual. In fact, Gstreamer code has both methods
 defined, but it uses get_type() for element registration.

 Regards,

 LM
 ___
 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] Spawn Command Line more than one line

[Luca Bruno]

On 10/03/2014 07:51, Estu Fardani wrote:

Hi.
Im just try to use spawn_command_line_async*. But how to implement if
command have more than one line?

sample

*cp file file.oriecho Original file | tee file*


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

Re: [Vala] Window used as a Menu in Gtk .

[Luca Bruno]

Hi, please provide more information on how your graphics should look like.
Also, this list is about the vala language, there is also the gtk list
here: https://mail.gnome.org/mailman/listinfo/gtk-list .
You can try looking at the new bleeding edge popover widget (which is still
in gtk unstable though).


On Sat, Mar 8, 2014 at 7:29 AM, Mariano Gaudix marianocordobar...@gmail.com
 wrote:

 Hello people . Sorry for the question .
 I need a window with the properties of a menu .
 When the  pointer  is  clicked  on  the  screen   ,   the  window  popup
  will dissapear.
 I  am   develop  an applet   for  gnome   .

 Also .  How  i  open  a  directory  with a  button  ?

 Thanks  ,   Sorry for the questions

 Best regards  . Mariano .
 ___
 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] question Gtk 3 + gstreamer 1.0

[Luca Bruno]

On 06/03/2014 05:43, Michael Catanzaro wrote:

On Thu, 2014-03-06 at 08:42 +0800, Nor Jaidi Tuah wrote:

/home/flavio/Documentos/JAMediaSuite/UbuntuRadio/vala/UbuntuRadio.vala.c:377:2:
warning: 'g_type_init' is deprecated (declared at
/usr/include/glib-2.0/gobject/gtype.h:669)

[-Wdeprecated-declarations]

   g_type_init ();
   ^

You can avoid this one by passing --target-glib=2.36 (or
--target-glib=2.38) to valac.

But really, trying to fight warnings in the generated C code is a losing
game.  In my projects I always compile the C code with -w.

This warning is fixed in recent vala versions, regardless of --target-glib.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Arrays in generics

[Luca Bruno]

On 05/03/2014 20:36, James Dean Palmer wrote:

Hi, I'm new to Vala and have run into an issue with generics and arrays.
  Consider this example:

public class VectorT {
 internal T[] items;
 
 public Vector.from(T[] source) {
 
 }
}

This allows me to conveniently initialize the vector like this:

new Vectorstring.from({Fred, Daphne, Velma})

But the problem arises that if I do the same thing with integers:

new Vectorint.from({1, 2, 3})

Vala doesn't complain but the c compiler does because the generic is
representing the array as a gpointer* where outside the generic the array
is gint*.  Since the size of the types is different I can't correctly
access an integer array from within a generic nor can I correctly pass a
gpointer* back to a gint*.  So while it compiles, the results are wrong
because when I use the array it is moving across the array at the wrong
stride.  To illustrate my point, this works correctly because the size is
compatible on my system:

new Vectorlong.from({1l, 2l, 3l})

Is there anything I can do to check the type or size of T in the generic to
provide custom type/size specific initialization?  Or is there some other
technique I might employ other than creating non-generic containers
(IntVector, BoolVector, etc..)?

You can check the type like typeof(T) == typeof(int)
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Inheriting from GLib.Action

[Luca Bruno]

On 06/03/2014 06:08, Edward Hennessy wrote:


Thank you for the help. I'm suspicious of the following code snippet in 
valagirparser.vala starting at line 920:

prop.set_attribute (NoAccessorMethod, false);
if (prop.get_accessor != null) {
var m = getter != null ? getter.symbol as Method : null;
// ensure getter vfunc if the property is abstract
if (m != null  (m.is_abstract || m.is_virtual || !prop.is_abstract)) {
getter.process (parser);
if (m.return_type is VoidType || m.get_parameters().size != 0) {
prop.set_attribute (NoAccessorMethod, true);
} else {
if (getter.name == name) {
foreach (var node in colliding) {
if (node.symbol is Method) {
node.merged = true;
}
}
}
prop.get_accessor.value_type.value_owned = 
m.return_type.value_owned;
}
} else {
prop.set_attribute (NoAccessorMethod, true);
}
}

In the if (getter.name == name), it compares a method name to a property name. In my test case, I 
get (get_enabled == enabled). I added test code and set getter.merged to 
true, and the vapi output looks correct - the getter method is removed. Is this the code that is 
supposed to remove the getters from the vapi? If so, the logic does not seem correct to me.

Right above that code, there's other code checking for get_ symbols.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] array memory leak?

[Luca Bruno]

On 06/03/2014 09:59, Ulink wrote:

I don't think this is the case.

If you call Dummy2(20), after returning from this function there are
approximately 60MB of RAM already used until the program ends.
Say LOOPS is 100.000.000 instead of 1.000.000 there are 6GB lost and my
PC starts massive swapping.
Looks like a memory leak, smells like a memory leak, 

Of course the memory leak per loop is small and my test functions are a
little bit academic (LOOPS is very big), but the leak IS 0 and one is
not able to say how big LOOPS is in real life.

Can you please report a bug? Thanks.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Inheriting from GLib.Action

[Luca Bruno]

On 05/03/2014 07:26, Edward Hennessy wrote:

I've edited the gio-2.0.vapi file and got classes implementing the GLib.Action 
interface working. Here is the vapi segment that I think is correct:

public interface Action : GLib.Object {
public abstract void activate (GLib.Variant? parameter);
public abstract void change_state (GLib.Variant value);
public abstract GLib.Variant? get_state_hint ();
public static bool name_is_valid (string action_name);
public static bool parse_detailed_name (string detailed_name, 
out string action_name, out GLib.Variant target_value) throws GLib.Error;
public static string print_detailed_name (string action_name, 
GLib.Variant parameter);
public abstract bool enabled { get; }
public abstract string name { get; }
public abstract GLib.VariantType? parameter_type { get; }
public abstract GLib.Variant? state { owned get; }
public abstract GLib.VariantType? state_type { get; }
}

However, I haven't been able to edit the Gio-2.0.metadata in a way to generate 
the segment above. I'm down to trial-and-error. Vapigen usually gives me 
compile warnings or errors. When it is successful, I get [NoAccessorMethod] 
which results in a SIGSEGV in the application because the interface function 
table isn't populated. Any help getting me to the next step is appreciated.
Thanks for sharing. The girparser has code for detecting such cases and 
discard the get_foo for the foo property. It's not something that should 
go in the metadata. Girparser should checked too understand the reason 
why it doesn't discard get_foo in this case.


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

Re: [Vala] question Gtk 3 + gstreamer 1.0

[Luca Bruno]

Gstreamer fires signals in a different thread than the gui mainloop. Use
something like
Idle.add (() = { this.image_button.set_from_stock(
Gtk.Stock.MEDIA_PLAY, Gtk.IconSize.BUTTON);
  return false; });
to run your code in the gui mainloop.


On Thu, Mar 6, 2014 at 12:28 AM, Flavio Danesse fdane...@gmail.com wrote:

 *Hello, I'm back with questions on the list :) *

 In my application I have gtk3 interface and streamings player gstreamer 1.0
 implemented separately.
 Both work correctly separately and jointly work correctly except in the
 following case:

 The player emits a signal when the bus changes state of reproduction, that
 is, when it comes into play mode, pause, stop, etc.. . .
 That signal is captured by the gtk interface to update the image of the
 play button - stop.

 *The problem is that when this happens, everything freezes gnome.*

 private void update_state(string state){

 if (state == playing){
 this.image_button.set_from_stock(
 Gtk.Stock.MEDIA_STOP, Gtk.IconSize.BUTTON);
 }
 else{
 this.image_button.set_from_stock(
 Gtk.Stock.MEDIA_PLAY, Gtk.IconSize.BUTTON);
 }
 }

 *I would clean the following warning in my application, but not how to do
 it:*


 /home/flavio/Documentos/JAMediaSuite/UbuntuRadio/vala/UbuntuRadio.vala.c:164:2:
 warning: 'gtk_window_set_opacity' is deprecated (declared at
 /usr/include/gtk-3.0/gtk/gtkwindow.h:142): Use 'gtk_widget_set_opacity'
 instead [-Wdeprecated-declarations]
   gtk_window_set_opacity ((GtkWindow*) self, 0.5);
   ^
 /home/flavio/Documentos/JAMediaSuite/UbuntuRadio/vala/UbuntuRadio.vala.c:
 In function 'main':

 /home/flavio/Documentos/JAMediaSuite/UbuntuRadio/vala/UbuntuRadio.vala.c:377:2:
 warning: 'g_type_init' is deprecated (declared at
 /usr/include/glib-2.0/gobject/gtype.h:669) [-Wdeprecated-declarations]
   g_type_init ();
   ^
 ___
 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] More problems with vala-dbus-binding-tool

[Luca Bruno]

Rename parameters to something else in the generated .vala. Indeed vala
should not use such a generic name for the generated code. Feel free to
report a bug.


On Sun, Feb 23, 2014 at 10:37 PM, rastersoft ras...@rastersoft.com wrote:

 Here it is.

 El 23/02/14 14:10, Luca Bruno escribió:

 Paste the generated vapi.


 On Sun, Feb 23, 2014 at 1:16 PM, rastersoft ras...@rastersoft.com
 wrote:

  Hi again:

 I fixed the problem in the last message: I forgot to add --gdbus. Now I
 have a problem with the C code: when I extract the interfaces with for
 org.freedesktop.ConsoleKit /org/freedesktop/ConsoleKit/Manager (using
 org.freedesktop.DBus.Introspectable.Introspect), I compile it with Vala
 and receive this message:

 /home/raster/workspace/autovala/install/src/dbus_
 generated/org.freedesktop.ConsoleKit/org/freedesktop/
 ConsoleKit/Manager/org-freedesktop-consolekit.c:

   In function '_dbus_org_freedesktop_console_kit_manager_sync_open_
 session_with_parameters':
 /home/raster/workspace/autovala/install/src/dbus_
 generated/org.freedesktop.ConsoleKit/org/freedesktop/
 ConsoleKit/Manager/org-freedesktop-consolekit.c:3107:54:
 error: 'parameters' redeclared as different kind of symbol
 orgfreedesktopConsoleKitManagerSyncParameterStruct* parameters = NULL;

 /home/raster/workspace/autovala/install/src/dbus_
 generated/org.freedesktop.ConsoleKit/org/freedesktop/
 ConsoleKit/Manager/org-freedesktop-consolekit.c:3104:143: note: previous
 definition of 'parameters' was here
 static void _dbus_org_freedesktop_console_kit_manager_sync_open_session_
 with_parameters
 (orgfreedesktopConsoleKitManagerSync* self, GVariant* parameters,
 GDBusMethodInvocation* invocation) {

 Any idea?

 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




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




-- 
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] Inheriting from GLib.Action

[Luca Bruno]

On 27/02/2014 17:09, Edward Hennessy wrote:

Hello,

I'm trying to create custom actions by inheriting from GLib.Action, however,
the following code:

public class CloseProjectAction : Object, Action
{
 public bool enabled
 {
 get
 {
 return true;
 }
 }

 public bool get_enabled()
 {
 return true;
 }

 /* more method implementations... */
}


You should define only the property, not the get_enabled() method. If 
get_enabled() is part of the bindings, that has to be removed from the 
interface as it's a bindings bug.

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

Re: [Vala] More problems with vala-dbus-binding-tool

[Luca Bruno]

Paste the generated vapi.


On Sun, Feb 23, 2014 at 1:16 PM, rastersoft ras...@rastersoft.com wrote:

 Hi again:

 I fixed the problem in the last message: I forgot to add --gdbus. Now I
 have a problem with the C code: when I extract the interfaces with for
 org.freedesktop.ConsoleKit /org/freedesktop/ConsoleKit/Manager (using
 org.freedesktop.DBus.Introspectable.Introspect), I compile it with Vala
 and receive this message:

 /home/raster/workspace/autovala/install/src/dbus_
 generated/org.freedesktop.ConsoleKit/org/freedesktop/
 ConsoleKit/Manager/org-freedesktop-consolekit.c:

  In function 
 '_dbus_org_freedesktop_console_kit_manager_sync_open_session_with_parameters':
 /home/raster/workspace/autovala/install/src/dbus_
 generated/org.freedesktop.ConsoleKit/org/freedesktop/
 ConsoleKit/Manager/org-freedesktop-consolekit.c:3107:54:
 error: 'parameters' redeclared as different kind of symbol
 orgfreedesktopConsoleKitManagerSyncParameterStruct* parameters = NULL;

 /home/raster/workspace/autovala/install/src/dbus_
 generated/org.freedesktop.ConsoleKit/org/freedesktop/
 ConsoleKit/Manager/org-freedesktop-consolekit.c:3104:143: note: previous
 definition of 'parameters' was here
 static void 
 _dbus_org_freedesktop_console_kit_manager_sync_open_session_with_parameters
 (orgfreedesktopConsoleKitManagerSync* self, GVariant* parameters,
 GDBusMethodInvocation* invocation) {

 Any idea?

 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




-- 
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] Debugging the compiler command generated by valac

[Luca Bruno]

On 18/12/2013 02:54, Joe Sapp wrote:

I'm having an issue with the C compiler command generated by valac.
Specifically, an include directory is being included unexpectedly (see
[1]).  Is there any way to figure out what causes this to happen, or
which package or file is at fault?  I can't seem to find any way to
get intermediate information between the `valac` call and the `cc`
call.

valac -v . Also you can avoid using valac to compile by using valac -C 
and then manually compile the generated C with cc.

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

Re: [Vala] methods/properties missing for some integral data types

[Luca Bruno]

On 09/12/2013 19:56, Wolfgang Schlichtner wrote:

The table takes 67 columns in width, this shouldn't be a problem.

I know that the problem originates from GLib, but I think that there
should be guaranteed interface for the basic types of a language. For
the integral types just:
to_string(), clamp(), min(), max(), MIN, MAX
are there for all of them. Why not implement them (at least some) in
Vala regardless of GLib (or in GLib directly of course) ?
A bug has been already fixed regarding this issue by contributing a 
patch: https://bugzilla.gnome.org/show_bug.cgi?id=722067
Patches are always very welcome as you can see. Even better if the 
patches are as much cross platform as possible and are not invasive in 
this particular case, since doing a change now and breaking it 
afterwards (especially given it's not something provided by glib) is not 
nice to users.


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

Re: [Vala] Question about some wiki content

[Luca Bruno]

On 15/01/2014 17:50, Steven Oliver wrote:

I'm looking at
https://wiki.gnome.org/Projects/Vala/ReferenceHandling

In the section titled Memory management for compact classes with reference
counting the custom up function, as expected, increments the reference
count. The custom down function though does not. I would think it should.

It does decrease the ref_count.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] several pkg-config libraries for a single VAPI file

[Luca Bruno]

No, each vapi refers to a single pkg-config. However you can create a .deps
file if a vapi depends on another.


On Tue, Jan 14, 2014 at 11:12 PM, rastersoft ras...@rastersoft.com wrote:

 Hi all:

 I'm working on a vapi file for xcb_render, and I need to put into it one
 function from xcb_renderutils. The problem is that each one needs a
 different library (xcb-render and xcb-renderutils). Is it possible to make
 valac to pass both to pkg-config from a single VAPI file?

 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




-- 
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] How to set Webkit option from vala

[Luca Bruno]

On 10/01/2014 14:04, Estu Fardani wrote:

Hi, i'm beginner vala user.

this time i do something code to run webkit from vala.
there the problem the security restrictions on file://

how to set webkit so it can run with option --allow-file-access-from-files
from vala?
where to put this code.

this my sample code :

public Main ()
 {
 var test = new App();
 load_uri (file:// + Environment.get_current_dir() +
/public/index.html);
 window_object_cleared.connect ((frame, context) = {
 test.setup_js_class ((JSCore.GlobalContext) context);
 });
 }

thank you.
valadoc.org helps: 
http://valadoc.org/#!api=webkit-1.0/WebKit.WebSettings.enable_file_access_from_file_uris 
http://valadoc.org/#%21api=webkit-1.0/WebKit.WebSettings.enable_file_access_from_file_uris

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

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

[Luca Bruno]

That would be a memory leak.


On Thu, Jan 9, 2014 at 7:01 PM, Tal Hadad tal...@hotmail.com wrote:

  What about:
 
  if (foo) {
 bar = (owned) ar;
  }
  // what now
 
  This behavior is confusing.
 It would be unowned, even if in if statement, just like I suggest.

 Tal

  Date: Tue, 7 Jan 2014 09:24:40 +0100
  From: lethalma...@gmail.com
  To: vala-list@gnome.org
  Subject: Re: [Vala] Change in 0.23.1 for array ownership and .length
  parameter
 
  On 07/01/2014 06:46, Tal Hadad wrote:
   This case trigger me a question I wanted to ask before.
   Why transforming ownership is nulling the original variable?
  
   Instead of nulling, maybe just change variable to behave as unowned.
  
   You might say that there is a problem in my solution, like this code:
  
   uint8[] ar = new uint8[10];
   if (some_method() != NULL)
another_method((owned)ar);
   ...
  
   Since after the if case, valac can't determinate if ownership was
 given(at compile time).
  
   Despite of this, nulling ar variable is even worse in my opinion and
 it's error prone.
  
   The user might use ar varible later and it will crush he's
 application.
   If he was lucky enough, he would realize that ar is null.
   It's not easy to find that this line causing it.
  
   I suggest solution for the last problem from valac side - treat ar as
 unowned after the
   (owned) operator, even if this operator was in if block!
  
   That way, ar won't be null, and the user could use it later only as
 unowned.
  
   And for class/struct fields - I do accept that they must be nulled
 when transferring ownership.
 
  What about:
 
  if (foo) {
 bar = (owned) ar;
  }
  // what now
 
  This behavior is confusing.
  ___
  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




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