Re: [Vala] vala-list Digest, Vol 143, Issue 1

[gavr via vala-list]

Thank you, there are no examples at all for LibDazzle + Vala. When I first
found vala and asked on Reddit

for a widget to display graphs, no one answered anything.
So soon I made a very bad one
.
(I needed it for the laboratory at the University)
In the code of your message for some reason there were no spaces, here is
the corrected version .

пт, 3 янв. 2020 г. в 15:45, :

> Send vala-list mailing list submissions to
> vala-list@gnome.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.gnome.org/mailman/listinfo/vala-list
> or, via email, send a message with subject or body 'help' to
> vala-list-requ...@gnome.org
>
> You can reach the person managing the list at
> vala-list-ow...@gnome.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of vala-list digest..."
>
>
> Today's Topics:
>
>1. Snippet: Dazzle.GraphView hello world (grindhold)
>
>
> --
>
> Message: 1
> Date: Fri, 3 Jan 2020 13:35:59 +0100
> From: grindhold 
> To: vala-list@gnome.org
> Subject: [Vala] Snippet: Dazzle.GraphView hello world
> Message-ID: 
> Content-Type: text/plain; charset="utf-8"
>
> Because i could not find one and i wanted to play around with it, I
> wrote a hello-world-style application that uses libdazzle's graphview
> courtesy to chergert.
>
> I figured this could be useful to other people who want to get started
> with it and prefer not to dig through gnome-usage's source.
>
>
> Compile with: valac --pkg gtk+-3.0 --pkg libdazzle-1.0 
>
>  1. publicstaticintmain(string[]argv){
>  2. Gtk.init(refargv);
>  3. varwin =newGtk.Window();
>  4. vargv =newDazzle.GraphView();
>  5. vargm =newDazzle.GraphModel();
>  6. varb =newGtk.Button.with_label("add datapoint");
>  7. varbox =newGtk.Box(Gtk.Orientation.VERTICAL,10);
>  8. vargc =newDazzle.GraphColumn("The Value",Type.from_name("gdouble"));
>  9. vargr =newDazzle.GraphLineRenderer();
> 10. varl =newGtk.Label("asdf");
> 11. ?
> 12. gm.set_timespan(TimeSpan.MINUTE);
> 13. gm.set_max_samples(30);
> 14. gm.add_column(gc);
> 15. ?
> 16. b.clicked.connect(()=>{
> 17. Dazzle.GraphModelItergi;
> 18. gm.push(outgi ,GLib.get_monotonic_time());
> 19. Dazzle.GraphModel.iter_set_value(gi,0,Random.double_range(0,100));
> 20. message("added");
> 21. });
> 22. gm.changed.connect(()=>{message("changed");});
> 23. box.expand=true;
> 24. gv.expand=true;
> 25. box.pack_start(b,false,false,0);
> 26. Gdk.RGBA linecol =Gdk.RGBA();
> 27. linecol.red =1.0;linecol.green=0.0;linecol.blue=0.0;linecol.alpha=1.0;
> 28. gr.stroke_color_rgba=linecol;
> 29. gr.line_width =1;
> 30. gr.column =0;
> 31. gv.add_renderer(gr);
> 32. box.pack_start(gv,true,true,0);
> 33. box.pack_start(l,false,false,0);
> 34. gv.set_model (gm);
> 35. win.add(box);
> 36. win.show_all();
> 37. win.delete_event.connect(()=>{Gtk.main_quit();returntrue;});
> 38.
> 39. Gtk.main();
> 40. return0;
> 41. }
>
> Enjoy :)
>
> -- next part --
> A non-text attachment was scrubbed...
> Name: pEpkey.asc
> Type: application/pgp-keys
> Size: 35472 bytes
> Desc: not available
> URL: <
> https://mail.gnome.org/archives/vala-list/attachments/20200103/fc81c898/attachment.bin
> >
>
> --
>
> Subject: Digest Footer
>
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
>
> --
>
> End of vala-list Digest, Vol 143, Issue 1
> *
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] vala-list Digest, Vol 142, Issue 5

[gavr via vala-list]

To access Wikipedia editing it needs to be asked in the GNOME chat here, at
least I did and it worked. Yes it would be great if someone updated these
guides. https://riot.im/app/#/room/#_gimpnet_#gnome:gnome.org

I was finishing the translation of vala guides into Russian, but there was
a very unusual editor of articles with previously unknown markup (for
me)(it's not MD, but Rosetta code uses the same) and I just moved
everything to GitBook leaving a link there. One of the Vala users asked me
to transfer the English guide to Gitbook as well.

чт, 19 дек. 2019 г. в 15:00, :

> Send vala-list mailing list submissions to
> vala-list@gnome.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.gnome.org/mailman/listinfo/vala-list
> or, via email, send a message with subject or body 'help' to
> vala-list-requ...@gnome.org
>
> You can reach the person managing the list at
> vala-list-ow...@gnome.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of vala-list digest..."
>
>
> Today's Topics:
>
>1. Re: General Information about this list & Vala (Ken Gilmer)
>
>
> --
>
> Message: 1
> Date: Wed, 18 Dec 2019 17:33:36 -0800
> From: Ken Gilmer 
> To: vala-list@gnome.org
> Subject: Re: [Vala] General Information about this list & Vala
> Message-ID:
> <
> caco+ygss+ngtlhcfga4pkphsbnnh72phg0eq_ehfvqpsdgc...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hello!  I am in the same boat as Giacomo.  I have found some typos and
> confusing language on the Vala wiki and am wondering how I could be able to
> update it.  I created an account but find the wiki pages immutable.  For
> example, https://wiki.gnome.org/Projects/Vala/ValaForJavaProgrammers seems
> to have been written when Java was version 1.6 and some things have
> changed, for example lambda support.  How would I go about updating this
> page?  Also, I have found a lot of the example code to a bit
> underwhelming.  Lastly, I have found the unit-test-driven learning format
> to be a very nice way of learning a new language (ex: Kotlin Koans [1]).
> Would something like this written for Vala be in-scope for the Gnome Vala
> wiki?
>
> 1: https://kotlinlang.org/docs/tutorials/koans.html
>
> Kind regards
> ken
>
>
> On Mon, Dec 16, 2019 at 2:55 PM rastersoft  wrote:
>
> > Hi! Welcome!
> >
> >
> > El 16/12/19 a las 19:01, giacomo alberini via vala-list escribi?:
> > > Hi all, dear Vala coders!
> > >
> > > First of all, I'd like to introduce myself, my name's Giacomo, I'm from
> > > Italy and I'm a passionate developer with a strong focus on open source
> > and
> > > Linux.
> > >
> > > I started to code in Vala because of a project, called Akira, and soon
> > > after I realize that I like the language and the integration with the
> GUI
> > > toolkit, even though I found some issues, quirks and in general
> > > difficulties using it effectively.
> > >
> > > My idea would be to invest some time & resources into learning more
> about
> > > the language itself, maybe create some tooling to improve the overall
> > > developer experience and (this would be super cool) work on the
> > (existing)
> > > vala-language-server project to create an IDE experience with the
> > language
> > > itself.
> > >
> > > My question is: is this the place in which the development of the
> > language
> > > and ecosystem takes place? If not, where should I ask questions or in
> > > general get support for the project?
> > >
> > > Thank you guys for your help and time!
> > >
> > > Best,
> > > Giacomo
> > > ___
> > > 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
> >
> > ___
> > vala-list mailing list
> > vala-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/vala-list
> >
>
>
> --
>
> Subject: Digest Footer
>
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
>
> --
>
> End of vala-list Digest, Vol 142, Issue 5
> *
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Vala syntax file for Midnight Commander editor

[Ulink]

MANY thanks for this!

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

Re: [Vala] vala-list Digest, Vol 133, Issue 6

[Vivien Kraus]

Hi,

Thank you for your answer.  In fact, the_datum is a plain int.  So it cannot be 
NULL (error: Equality operation: `null'
and `int' are incompatible).

However, I found a workaround.  It seems that valac assumes out parameter to 
extern library functions are always
initialized, but not when they are called conditionally.

So, by changing a little the code, I got this to compile:

// Always return true
extern bool lib_initialized ();

// data is always set when work returns true
extern bool lib_work (out int data);

int main(string[] args) {
int the_datum;
if (lib_initialized ()) {
bool has_datum = lib_work (out the_datum);
if (has_datum) {
stdout.printf ("Hello, %d!\n", the_datum);
}
}
return 0;
}

Le samedi 16 février 2019 à 12:52 -0200, Fernando Silva via vala-list a écrit :
> I think checking if (the_datum != null) should do
> 
> Em sáb, 16 de fev de 2019 10:00,  
> > Send vala-list mailing list submissions to
> > vala-list@gnome.org
> > 
> > To subscribe or unsubscribe via the World Wide Web, visit
> > https://mail.gnome.org/mailman/listinfo/vala-list
> > or, via email, send a message with subject or body 'help' to
> > vala-list-requ...@gnome.org
> > 
> > You can reach the person managing the list at
> > vala-list-ow...@gnome.org
> > 
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of vala-list digest..."
> > 
> > 
> > Today's Topics:
> > 
> >1. error: use of possibly unassigned local variable (Vivien Kraus)
> > 
> > 
> > --
> > 
> > Message: 1
> > Date: Fri, 15 Feb 2019 21:28:45 +0100
> > From: Vivien Kraus 
> > To: vala-list@gnome.org
> > Subject: [Vala] error: use of possibly unassigned local variable
> > Message-ID:
> > <40a1141df0d06b59ed0f87f3a6cafac285f45b4a.ca...@planete-kraus.eu>
> > Content-Type: text/plain; charset="UTF-8"
> > 
> > Hello list,
> > 
> > I am facing an inconvenient problem.
> > 
> > Suppose I have a C library, that I want to use from vala:
> > 
> > // Always return true
> > extern bool lib_initialized ();
> > 
> > // data is always set when work returns true
> > extern bool lib_work (out int data);
> > 
> > int main(string[] args) {
> > int the_datum;
> > bool has_datum = (lib_initialized () && lib_work (out the_datum));
> > if (has_datum) {
> > stdout.printf ("Hello, %d!\n", the_datum);
> > }
> > return 0;
> > }
> > 
> > If I am to compile this (0.42.5, -C only, not link), I get an error
> > message:
> > 
> > test.vala:11.3-11.44: error: use of possibly unassigned local variable
> > `the_datum'
> > stdout.printf ("Hello, %d!\n", the_datum);
> > ^^
> > Compilation failed: 1 error(s), 0 warning(s)
> > 
> > The workaround is obvious: initialize the_datum.  However, I like to run
> > my code under valgrind to detect when reading
> > from an uninitialized variable (I make lots of mistakes ^^), and so if
> > there is a bug in lib_work and I initialize
> > the_datum, then I will not be able to notice the problem.
> > 
> > Is it possible to instruct valac that it should not worry?  Or is it
> > possible to change this error to a simple warning?
> > 
> > Best regards
> > 
> > Vivien
> > 
> > 
> > 
> > 
> > --
> > 
> > Subject: Digest Footer
> > 
> > ___
> > vala-list mailing list
> > vala-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/vala-list
> > 
> > 
> > --
> > 
> > End of vala-list Digest, Vol 133, Issue 6
> > *
> > 
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list

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

Re: [Vala] vala-list Digest, Vol 133, Issue 6

[Fernando Silva via vala-list]

I think checking if (the_datum != null) should do

Em sáb, 16 de fev de 2019 10:00,  Send vala-list mailing list submissions to
> vala-list@gnome.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.gnome.org/mailman/listinfo/vala-list
> or, via email, send a message with subject or body 'help' to
> vala-list-requ...@gnome.org
>
> You can reach the person managing the list at
> vala-list-ow...@gnome.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of vala-list digest..."
>
>
> Today's Topics:
>
>1. error: use of possibly unassigned local variable (Vivien Kraus)
>
>
> --
>
> Message: 1
> Date: Fri, 15 Feb 2019 21:28:45 +0100
> From: Vivien Kraus 
> To: vala-list@gnome.org
> Subject: [Vala] error: use of possibly unassigned local variable
> Message-ID:
> <40a1141df0d06b59ed0f87f3a6cafac285f45b4a.ca...@planete-kraus.eu>
> Content-Type: text/plain; charset="UTF-8"
>
> Hello list,
>
> I am facing an inconvenient problem.
>
> Suppose I have a C library, that I want to use from vala:
>
> // Always return true
> extern bool lib_initialized ();
>
> // data is always set when work returns true
> extern bool lib_work (out int data);
>
> int main(string[] args) {
> int the_datum;
> bool has_datum = (lib_initialized () && lib_work (out the_datum));
> if (has_datum) {
> stdout.printf ("Hello, %d!\n", the_datum);
> }
> return 0;
> }
>
> If I am to compile this (0.42.5, -C only, not link), I get an error
> message:
>
> test.vala:11.3-11.44: error: use of possibly unassigned local variable
> `the_datum'
> stdout.printf ("Hello, %d!\n", the_datum);
> ^^
> Compilation failed: 1 error(s), 0 warning(s)
>
> The workaround is obvious: initialize the_datum.  However, I like to run
> my code under valgrind to detect when reading
> from an uninitialized variable (I make lots of mistakes ^^), and so if
> there is a bug in lib_work and I initialize
> the_datum, then I will not be able to notice the problem.
>
> Is it possible to instruct valac that it should not worry?  Or is it
> possible to change this error to a simple warning?
>
> Best regards
>
> Vivien
>
>
>
>
> --
>
> Subject: Digest Footer
>
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
>
> --
>
> End of vala-list Digest, Vol 133, Issue 6
> *
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] [vala] problem with sorting an array

[Ulink]

Hi,

> I don't understand why I can't sort my array... :-/ (glib.array)

seems this is a GLib.Array compare function binding (vapi) error or
something like this.
On C level, the compare objects are putted into your compare function as
pointers to pointers and not as pointers.

For a quick and dirty workaround, change the following two lines:


int sort_by_size(ref FileAndChunks o1, ref FileAndChunks o2) { ... }
list.sort((CompareFunc)sort_by_size);


Note that after vapi fix, your code is broken again so it would be
better to fix the vapi file instead of the above workaround.

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

Re: [Vala] Vala book done (it's been only 10 years…)

[Al Thomas via vala-list]

   > On Tuesday, 19 June 2018, 08:36:19 BST, Dr. Michael Lauer 
 wrote: 
> I don’t know whether you remember me talking about writing an beginner's book 
> to get more people
> on the Vala train – after all, it’s been 10 years ago. 
> The recent activity boost in this community motivated me to pick it up again. 
> So I
> threw the german draft away, rewrote it in english, and finished it. 
> Anyways, here are links:

> e-book: https://leanpub.com/vala 

>printed: amazon.com/dp/1983202347  

This is a useful addition to Vala resources. I found the history in the sample 
chapter very interesting.
I intend to get the book and read the rest of it soon.

Thanks,

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

Re: [Vala] Vala book done (it's been only 10 years…)

[Ulink]

Cool stuff! You absolutely should add a link to the book at

https://en.wikipedia.org/wiki/Vala_(programming_language)
https://de.wikipedia.org/wiki/Vala_(Programmiersprache)




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

Re: [Vala] vala-list Digest, Vol 124, Issue 13

[Al Thomas via vala-list]

> On Wednesday, 28 March 2018, 18:03:44 BST, Fernando Silva 
 wrote:  > I bet this could be decided based on locale 
with gettext

Now, there's a challenge :) 
Gettext is very good with plurals 
(https://www.gnu.org/software/gettext/manual/html_node/Plural-forms.html).I 
didn't find anything on date presentation though.
There is the Posix nl_langinfo:
void main () {    Intl.setlocale ();
    print (Posix.nl_langinfo (Posix.D_FMT) + "\n");
}
but all that does is return the format based on the forward slash separator. 
This can then be used instrftime or GLib.DateTime.format(). For my locale 
(en_GB) I get %d/%m/%y

Al



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

Re: [Vala] vala-list Digest, Vol 124, Issue 13

[Fernando Silva]

I bet this could be decided based on locale with gettext

2018-03-28 9:00 GMT-03:00 :

> Send vala-list mailing list submissions to
> vala-list@gnome.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.gnome.org/mailman/listinfo/vala-list
> or, via email, send a message with subject or body 'help' to
> vala-list-requ...@gnome.org
>
> You can reach the person managing the list at
> vala-list-ow...@gnome.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of vala-list digest..."
>
>
> Today's Topics:
>
>1. Re: Date format (rastersoft)
>2. Re: Date format (Al Thomas)
>
>
> --
>
> Message: 1
> Date: Wed, 28 Mar 2018 12:50:31 +0200
> From: rastersoft 
> To: Al Thomas , vala-list@gnome.org
> Subject: Re: [Vala] Date format
> Message-ID: 
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi:
>
> > > Also, what
> > > I really want is the date in the format "March 5, 2018", not
> > "03/05/18",
> > > but it seems that only %c does that, but adds a lot of extra data
> > that I
> > > don't want like the time zone.
> >
> > As Christian Hergert suggests, DateTime is very useful. This works for
> me:
> >
> > void main () {
> > ??? var date = new DateTime.now_local();
> > ??? print (date.format("%B %e, %Y"));
> > }
> >
> > That prints March 28, 2018 today. There are a whole load of formatting
>
> Yes, but the problem is that, in Spain, we use the opposite format: we
> write first the day's number, then the month's name, and finally the
> year, so I need to know if in my current locale I have to "%B %e, %Y",
> or "%e %B %Y" (without the comma), and so on... That's my problem. Using
> '%c' does that, but adds a lot of extra information that I don't want,
> like the timezone.
>
>
> --
>
> Message: 2
> Date: Wed, 28 Mar 2018 11:53:28 + (UTC)
> From: Al Thomas 
> To: vala-list@gnome.org, rastersoft 
> Subject: Re: [Vala] Date format
> Message-ID: <1758071266.393914.1522238008...@mail.yahoo.com>
> Content-Type: text/plain; charset=UTF-8
>
>   On Wednesday, 28 March 2018, 11:50:33 BST, rastersoft <
> ras...@rastersoft.com> wrote: > Yes, but the problem is that, in Spain,
> we use the opposite format: we write first the day's number, > then the
> month's name, and finally the year, so I need to know if in my current
> locale I have > to "%B %e, %Y", or "%e %B %Y" (without the comma), and so
> on... That's my problem. > Using '%c' does that, but adds a lot of extra
> information that I don't want, like the timezone.
> Aha, I understand now. I don't know the answer. There doesn't appear to be
> a ready madesolution. I would say that here in the UK the format 28 March
> 2018 is often used. The same asin Spain. I know that in the USA a date
> written as 5/3/2018 is the same as 3/5/2018 in the UK(03 May 2018). So
> generally I go for day of the month, followed by word of the month and full
> year.This at least helps makes the date unambiguous for the Gregorian
> calendar. As long as thereader can distinguish the day, month and year.
>
> I do also know that styles can change over time. So often in the UK a
> datewas written 3rd May 2018. Then some years ago it was decided in my
> workplace that this was tooold fashioned and it was changed to 3 May 2018.
> This was for a public service dealing with millions of contacts a year from
> all over the UK. Now I'm often seeing 03 May 2018.
> May be it is just open to too much variation that it has never been coded
> in to a library. Inessence it is better to convey the meaning of the date
> unambiguously rather that meet thestylistic requirements of any locale.
> I'm curious about the ordering of day, month, year for the Gregorian
> calendar in other locales and if there is a library for that.
> Regards,
> Al
>
>
>
> --
>
> Subject: Digest Footer
>
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
>
> --
>
> End of vala-list Digest, Vol 124, Issue 13
> **
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Vala on OpenIndiana Updated

[Al Thomas via vala-list]

> On Wednesday, August 16, 2017, 4:58:59 PM GMT+1, Jason Martin 
>  wrote:

> Maybe a good vala example (someone more qualified than me) of trapping
> signals would be handy?

This is an example of handling some signals, but not an example for SIGSEGV. 
The documentation for GLib.Unix.SignalSource states "In GLib versions before 
2.36, only `SIGHUP`, `SIGINT`, `SIGTERM` can be monitored. In GLib 2.36, 
`SIGUSR1` and `SIGUSR2` were added. In GLib 2.54, `SIGWINCH` was added."
The example is in Genie, so significant leading whitespace and types are 
declared after the identifier with a colon. Save as unix_signal_example.gs and 
compile like any other Vala program:

[indent = 4]
init
var main = new MainLoop()
var handler = new SignalHandler( main )
Unix.signal_add( Posix.SIGINT, handler.quit )
print (@"To end the process use:
kill -2 $((int)Posix.getpid())
or CTRL+C")
main.run()


class SignalHandler
_mainloop:MainLoop

construct( mainloop:MainLoop )
_mainloop = mainloop

def quit():bool
print( @"
Process $((int)Posix.getpid()) has received SIGINT, ending..." )
_mainloop.quit()
return Source.REMOVE
For segmentation faults you may find inspiration from vala-stacktrace: 
https://github.com/PerfectCarl/vala-stacktrace
Thanks for keeping us updated,

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

Re: [Vala] Vala on OpenIndiana Updated

[Ben]

You would probably use Posix.signal ()

On August 16, 2017 11:57:48 AM EDT, Jason Martin  wrote:
>GLib.Math.pow10.vala
>GLib.Math.pow10f.vala
>These functions are missing on some platforms:
>
>Some of the core dumps are truly meant to be core dumps.
>
>Maybe a good vala example (someone more qualified than me) of trapping
>signals would be handy?
>___
>vala-list mailing list
>vala-list@gnome.org
>https://mail.gnome.org/mailman/listinfo/vala-list
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Vala on OpenIndiana Updated

[Jason Martin]

GLib.Math.pow10.vala
GLib.Math.pow10f.vala
These functions are missing on some platforms:

Some of the core dumps are truly meant to be core dumps.

Maybe a good vala example (someone more qualified than me) of trapping
signals would be handy?
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Vala on OpenIndiana or Solaris

[Jason Martin]

Redone with OpenIndiana Hipster's primary build framework oi-userland
https://github.com/OpenIndiana/oi-userland

Still get cores with all my build variations

Example GLib.Array.prepend_vals.vala gdb states:

0xfec96f9b in strlen () from /lib/libc.so.1

Then I installed the Vala 0.29.3 from:
http://sfe.opencsw.org/localhostoih/en/index.shtml
Same result.

Then install Vala 0.20.1 from hipster repo
Same result.

To tired and sick to go any futher for now. Sorry.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Vala++

[Daniel Brendle]

On 04/04/2017 11:47 AM, Mohan R wrote:
> Hi,
>
> A request to gnome+rust language developers, Please keep dbus and glade
> integration as easy as Vala. I enjoy writing GUI and dbus apps with Vala.
> It's just awesome integration which I don't see in other language bindings.
>
> Thanks,
> Mohan R
I second this.

As a matter of fact there are many languages you can use gobject in. But
it doesn't necessarily feel right because you're supposed to follow the
patterns of the language (and naturally also want to do so) but you have
to follow GLibs pattern. About ten years earlier i started programming
against Gtk in python which was one of the more convenient ways to do so
at the time (before i tried coding Gtk in perl and C). Oh boy. It was
such a hazzle until I figured out which of the mechanics belonged to
python and wich ones belonged to glib and even that there is a
difference between python threads and glib threads. Each language brings
their own means (stdlib) of interfacing with system functionality and
GLib brings it's own. This will allways be confusing in any language
that does not follow the same principles as Vala and Genie. I've read
that you can use Rust without a standard library. Maybe this will
actually make it suitable for GObject code. I know i repeat myself, but
i am stoked to see the results.



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

Re: [Vala] Vala++

[Al Thomas via vala-list]

> From: Alessandro Pellizzari <a...@amiran.it>> Sent: Tuesday, 4 April 2017, 
> 13:47
> Subject: Re: [Vala] Vala++

> On 04/04/17 13:28, Al Thomas via vala-list wrote:

>> You seem to over talking Rust and under talking Vala.
> No, I don't. :)
> Rust is a hard beast to learn. It took me months to have a decent grasp 
> of it, and I'm still missing many "rustic ways" of doing things, while 
> in Vala I was productive in weeks.

May be that's why Rust is still labelled a systems programming language.
So it's in the same application space as Erlang. Vala is a lot more
fun and gives people who are not systems and software engineers the
opportunity to express their ideas. Although Vala has and needs all
levels of abilities.

> But, on the other side: no memory leaks, no segmentation faults, no 
> concurrency mess-ups (unless you try VERY hard).

Vala is pretty good on this, but hopefully you took a little bit of
your time and reported the problem you had with Vala. Just as Rust
users do:
https://github.com/rust-lang/rust/issues/4494

Also Vala links to libraries that may cause such problems. I'm not
sure how Rust deals with that. I found this in the Rust docs:
https://doc.rust-lang.org/book/ffi.html#ffi-and-panics
but that says "Please note that catch_unwind() will only catch
unwinding panics, not those who abort the process."

Is there a lot of wrapping? The initialisation of GTK uses wrapping
in the example:


> What I'm saying is exactly what you said: Rust has many more resources. 
> It's growing much faster (it is not even 2 years old).

I guess that must be a typo. Looks like the first commit was back on

16 June 2010:
https://github.com/rust-lang/rust/commit/c01efc669f09508b55eced32d3c88702578a7c3e
Or maybe you mean from the 1.0 release. Looks like that was 15 May 2015:
https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-100-2015-05-15
So yes, five years from first commit to 1.0 release is pretty good.

> Inevitably, in a couple of years, it will be ahead of Vala even in Gtk/Gnome 

> support, unless hundreds of developers adopt Vala now.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Vala++

[Alessandro Pellizzari]

On 04/04/17 13:28, Al Thomas via vala-list wrote:


From: Alessandro Pellizzari 



You seem to over talking Rust and under talking Vala.


No, I don't. :)

I know all you have linked. I have been following this ml since 2008. I 
also know the article by esr and agree, in part, with him.


Rust is a hard beast to learn. It took me months to have a decent grasp 
of it, and I'm still missing many "rustic ways" of doing things, while 
in Vala I was productive in weeks.


But, on the other side: no memory leaks, no segmentation faults, no 
concurrency mess-ups (unless you try VERY hard).


I don't want to advocate rust (but try it. You will hate it. And then 
you'll love it :).


What I'm saying is exactly what you said: Rust has many more resources. 
It's growing much faster (it is not even 2 years old).
Inevitably, in a couple of years, it will be ahead of Vala even in 
Gtk/Gnome support, unless hundreds of developers adopt Vala now.


I am sorry about it because I really liked the idea behind Vala.
I am glad about it because it's a safer language.

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

Re: [Vala] Vala++

[Al Thomas via vala-list]

> From: Alessandro Pellizzari <a...@amiran.it>
> Sent: Tuesday, 4 April 2017, 10:27
> Subject: Re: [Vala] Vala++


You seem to over talking Rust and under talking Vala. 

> Rust, on the other hand, is a general language, that can be used for 
> many things: CLI apps, OS kernels, C-compatible libraries, GUI apps, 
> servers, web apps, etc. etc.


The https://www.rust-lang.org/ website still labels Rust as a "systems 

programming language", but going through your list and applying Vala:

CLI apps, for Vala see:
https://valadoc.org/glib-2.0/GLib.OptionEntry.html - for handling args

https://wiki.gnome.org/Projects/Vala/IoChannelsSample - for handling pipes
https://valadoc.org/curses/Curses.html - although an ncurses binding would
be good

OS kernels, well that's not a good use of Vala

C-compatible libraries, surprisingly the Vala compiler is mainly in a
C compatible library called libvala. If you want to write a library in
Vala then a few tips:
--hide-internal switch of valac controls symbol visibility with GLib's
G_GNUC_INTERNAL macro
Producing a GIR with valac and then using g-ir-compiler allows bindings
to be produced that can be used in many languages
There is the beginnings of a tutorial at 

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


GUI apps, hmmm GTK+3 anyone? Vala includes excellent bindings and also
composite template code generation routines with the use of the
[GtkTemplate] attribute.


Servers, web apps, etc. :
[DBus] attribute for code generation
https://valadoc.org/gio-2.0/GLib.Socket.html
https://github.com/arteymix/valum/ and importantly work on Vala Server
Gateway Interface (VSGI)
http://www.ambitionframework.org/
Maybe all of these don't fit with your needs, but there is an active Vala 

community and I hope these examples have broadened your outlook a little.

> Bacause of this, the ecosystem is many times bigger, so it's easier to 
> find skilled devs, but also crates (linkable libraries), bindings for 

> current libraries, etc.
There are certainly more resources put in to Rust. Remember it is sponsored
by Mozilla. There is a core team:
https://www.rust-lang.org/en-US/team.html
and some of them are paid to work full team, e.g.:
https://news.ycombinator.com/item?id=13324458

Mozilla's audited financial statement for 2015 ( 
https://static.mozilla.com/moco/en-US/pdf/2015_Mozilla_Audited_Financial_Statement.pdf)
 shows $414,380,000 in royalty revenue and $214,187,000 software development
expenditure. Whereas the GNOME Fiscal Report for 2015 ( 
https://www.gnome.org/wp-content/uploads/2016/08/GAR2015-web.pdf ) shows an 
income of $644,174. Notice the missing zeros at the end there.


Vala follows a very different development model. What is amazing that after
a decade from the initial release Vala is still going strong. Look at the
latest release notes ( 
https://mail.gnome.org/archives/ftp-release-list/2017-March/msg00119.html ) and 
you see at the end 31 people credited with contributions.


Vala/Genie is a very useful tool for producing performant native binaries for
a wide range of applications. Including embedded systems, command line and text
based user interfaces and graphical user interfaces.

Vala certainly has some rough edges that need smoothing off before any
1.0 release - but that is another thread :-) If you wish to participate
then great, otherwise good luck with your chosen development platform.

Al

P.S. for a more critical view of Rust one article is 
http://esr.ibiblio.org/?p=7294=1
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Vala++

[Ulink]

Hi Christian,

> Some of us in GNOME have spent many years writing programming languages
> and runtimes. Therefore our view is somewhat nuanced and opinionated.

As mine is ;-)

But I don't understand why the Gnome guys effectively ditch vala (as it
appears to me, maybe I'm wrong?). I simply can't find any real reason
for this.

Gjs is of course a good choice for small Gnome Desktop apps, but why not
favor BOTH? Vala and Gjs would be a perfect team I think in different areas.

I REALLY don't want (and can't ;-) ) force someone at Gnome to do
anything they don't want to do but it's a pity Vala don't receive more
support from Gnome.

> Congrats! Builder is about 200k of C and it's taken me the past 2 years
> to get there.

To be honest, a colleague has written 3/4 of it, so my part is only
50.000 LOC (mostly system level code), but total LOC is 200.000.

For performance and resource reasons, there was no other option than
Vala (maybe except C, but this would have been 500.000 LOC).

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

Re: [Vala] Vala++

[Christian Hergert]

On 04/04/2017 01:47 AM, Ulink wrote:
> I simply can't understand why the Gnome people seems to hate or at least
> ignore Vala and instead promote Javascript or Rust or other weird stuff.

Some of us in GNOME have spent many years writing programming languages
and runtimes. Therefore our view is somewhat nuanced and opinionated.
Your viewpoint may be different, and that's okay.

> I recently wrote a 200k LOC Gtk app and Vala did the job perfectly. No
> way for Javascript, Python, C++ or even C or Rust.

Congrats! Builder is about 200k of C and it's taken me the past 2 years
to get there. That amount of work should be applauded no matter what the
language.

Cheers,

-- Christian

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

Re: [Vala] Vala++

[Alessandro Pellizzari]

On 04/04/17 09:47, Ulink wrote:


I simply can't understand why the Gnome people seems to hate or at least
ignore Vala and instead promote Javascript or Rust or other weird stuff.


I really like Vala, and I also really like Rust, so don't hate me for 
this post. :)


I think the main problem is that Vala is a very small ecosystem (few 
core developers, few users), ha a "proprietary" syntax, even if it's 
similar to C# and is strongly oriented towards Gtk software (as it's 
based on GLib)


Rust, on the other hand, is a general language, that can be used for 
many things: CLI apps, OS kernels, C-compatible libraries, GUI apps, 
servers, web apps, etc. etc.


Bacause of this, the ecosystem is many times bigger, so it's easier to 
find skilled devs, but also crates (linkable libraries), bindings for 
current libraries, etc.


So, on the long run, I am afraid/glad it's gonna replace Vala completely.

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

Re: [Vala] Vala++

[Alessandro Pellizzari]

On 04/04/17 08:22, Daniel Brendle wrote:


On 04/03/2017 02:16 AM, Nor Jaidi Tuah wrote:



https://blogs.gnome.org/chergert/2017/03/31/rustic-gnome-day-3/



There are many languages that are also fun when it comes to programming
against the Glib based library stack. The more interesting part is: will
there ever be a language that makes it also as convenient to write
gobject-introspectable libraries.


From the post:

"In particular, Niko and Federico have been working on a GObject plugin 
for Rust that allows us to have a nice, almost Vala-esque, syntax for 
writing GObjects"


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

Re: [Vala] Vala++

[Ulink]

Am 2017-04-03 um 02:16 schrieb Nor Jaidi Tuah:
> It looks like Vala is going to have
> a parallel life:
> 
> https://blogs.gnome.org/chergert/2017/03/31/rustic-gnome-day-3/
> 
> I hope the gnome+rust people succeed in
> recreating the Vala awesomeness in Rust
> (even if they don't name it after Vala).

I simply can't understand why the Gnome people seems to hate or at least
ignore Vala and instead promote Javascript or Rust or other weird stuff.

This makes me very unhappy.

IMHO Vala is by far the cleanest, easiest and most performant way (both
in terms of coding and running) to use GLib/Gtk.

I recently wrote a 200k LOC Gtk app and Vala did the job perfectly. No
way for Javascript, Python, C++ or even C or Rust.




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

Re: [Vala] Vala++

[Christian Hergert]

On 04/04/2017 12:22 AM, Daniel Brendle wrote:
> There are many languages that are also fun when it comes to programming
> against the Glib based library stack. The more interesting part is: will
> there ever be a language that makes it also as convenient to write
> gobject-introspectable libraries. That is the one true thing that one
> can do very conveniently with Vala but with no other ecosystem can do
> yet. I hope the rust-gnomies care about that too and not only on using
> the bindings. It's an integral part of integrating well into the gnome
> library ecosystem imho.
> I am stoked to see what the results will be.

Yes, it can go both directions.

-- Christian





signature.asc
Description: OpenPGP digital signature
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Vala++

[Daniel Brendle]

On 04/03/2017 02:16 AM, Nor Jaidi Tuah wrote:
> It looks like Vala is going to have
> a parallel life:
>
> https://blogs.gnome.org/chergert/2017/03/31/rustic-gnome-day-3/
>
> I hope the gnome+rust people succeed in
> recreating the Vala awesomeness in Rust
> (even if they don't name it after Vala).

There are many languages that are also fun when it comes to programming
against the Glib based library stack. The more interesting part is: will
there ever be a language that makes it also as convenient to write
gobject-introspectable libraries. That is the one true thing that one
can do very conveniently with Vala but with no other ecosystem can do
yet. I hope the rust-gnomies care about that too and not only on using
the bindings. It's an integral part of integrating well into the gnome
library ecosystem imho.
I am stoked to see what the results will be.




signature.asc
Description: OpenPGP digital signature
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Vala and GLib license

[Aleksandr Palamar]

The main sentence I'm pointing is:



*You are not responsible for enforcing compliance by third parties with
this License. *
Also about PS4:

   - *WebKit *- http://doc.dl.playstation.net/doc/ps4-oss/webkit.html
   - *Cairo *- http://doc.dl.playstation.net/doc/ps4-oss/cairo.htm
   - *Mono VM* - http://doc.dl.playstation.net/doc/ps4-oss/mono_vm.html
   - *FFmpeg *- http://doc.dl.playstation.net/doc/ps4-oss/ffmpeg.html

*LGPL and FFmpeg FAQ* - https://www.ffmpeg.org/legal.html states:

   1. Compile FFmpeg *without* "--enable-gpl" and *without*
   "--enable-nonfree".
   2. Use dynamic linking (on windows, this means linking to dlls) for
   linking with FFmpeg libraries.
   3. Distribute the source code of FFmpeg, no matter if you modified it or
   not.
   4. Make sure the source code corresponds exactly to the library binaries
   you are distributing.
   5. Run the command "git diff > changes.diff" in the root directory of
   the FFmpeg source code to create a file with only the changes.
   6. Explain how you compiled FFmpeg, for example the configure line, in a
   text file added to the root directory of the source code.
   7. Use tarball or a zip file for distributing the source code.
   8. Host the FFmpeg source code on the same webserver as the binary you
   are distributing.
   9. Add "This software uses code of http://ffmpeg.org>FFmpeg
   licensed under the http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html>LGPLv2.1 and
   its source can be downloaded here" to
   every page in your website where there is a download link to your
   application.
   10. Mention "This software uses libraries from the FFmpeg project under
   the LGPLv2.1" in your program "about box".
   11. Mention in your EULA that your program uses FFmpeg under the
   LGPLv2.1.
   12. If your EULA claims ownership over the code, you have to *explicitly*
   mention that you do not own FFmpeg, and where the relevant owners can be
   found.
   13. Remove any prohibition of reverse engineering from your EULA.
   14. Apply the same changes to all translations of your EULA.
   15. Do not misspell FFmpeg (two capitals F and lowercase "mpeg").
   16. Do not rename FFmpeg dlls to some obfuscated name, but adding a
   suffix or prefix is fine (renaming "avcodec.dll" to "MyProgDec.dll" is not
   fine, but to "avcodec-MyProg.dll" is).
   17. Go through all the items again for any LGPL external library you
   compiled into FFmpeg (for example LAME).
   18. Make sure your program is not using any GPL libraries (notably
   libx264).

And here is what *Microsoft Application Provider Agreement* which include
XBox states:

5) *APP REQUIREMENTS.* Each App you submit to Microsoft for distribution
through the Store must meet the following requirements:

d. *FOSS Software.* If your App includes FOSS, (i) you are responsible for
compliance with all applicable FOSS license terms, including any source
code availability requirements, and (ii) it must not cause any non-FOSS
Microsoft software to become subject to the terms of any FOSS license.
*EA WebKit*: http://gpl.ea.com/eawebkit.html

On Tue, Jul 12, 2016 at 6:04 PM, pelzflorian (Florian Pelz) <
pelzflor...@pelzflorian.de> wrote:

> On 07/12/2016 04:28 PM, Aleksandr Palamar wrote:
> > Yes, of course those platforms have DRM. But GLib, GObject and GIO are
> > available under LGPL 2.1, which states:
> >
> > *10.* Each time you redistribute the Library (or any work based on the
> > Library), the recipient automatically receives a license from the
> original
> > licensor to copy, distribute, link with or modify the Library subject to
> > these terms and conditions. You may not impose any further restrictions
> on
> > the recipients' exercise of the rights granted herein. You are not
> > responsible for enforcing compliance by third parties with this License.
> >
>
> I suppose it is still you who violates the license, but suppose it is
> Sony/Microsoft because they redistribute your software on their store.
> Then Sony/Microsoft would most certainly not want to be liable and
> remove your software just like Apple does now.
>
> (I’m not sure if there really is such DRM, but I suspect it.)
>
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Vala and GLib license

[pelzflorian (Florian Pelz)]

On 07/12/2016 04:28 PM, Aleksandr Palamar wrote:
> Yes, of course those platforms have DRM. But GLib, GObject and GIO are
> available under LGPL 2.1, which states:
> 
> *10.* Each time you redistribute the Library (or any work based on the
> Library), the recipient automatically receives a license from the original
> licensor to copy, distribute, link with or modify the Library subject to
> these terms and conditions. You may not impose any further restrictions on
> the recipients' exercise of the rights granted herein. You are not
> responsible for enforcing compliance by third parties with this License.
> 

I suppose it is still you who violates the license, but suppose it is
Sony/Microsoft because they redistribute your software on their store.
Then Sony/Microsoft would most certainly not want to be liable and
remove your software just like Apple does now.

(I’m not sure if there really is such DRM, but I suspect it.)

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

Re: [Vala] Vala and GLib license

[Aleksandr Palamar]

Yes, of course those platforms have DRM. But GLib, GObject and GIO are
available under LGPL 2.1, which states:

*10.* Each time you redistribute the Library (or any work based on the
Library), the recipient automatically receives a license from the original
licensor to copy, distribute, link with or modify the Library subject to
these terms and conditions. You may not impose any further restrictions on
the recipients' exercise of the rights granted herein. You are not
responsible for enforcing compliance by third parties with this License.

On Tue, Jul 12, 2016 at 3:25 PM, pelzflorian (Florian Pelz) <
pelzflor...@pelzflorian.de> wrote:

> Does XBox One / PS4 have DRM that prevents relinking? Even a translation
> layer may not work. I’m doubtful GLib is compatible with PS4. Please
> note that it is *not* compatible with Apple app stores. Asking the FSF
> may indeed be a good idea.
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Vala and GLib license

[pelzflorian (Florian Pelz)]

Does XBox One / PS4 have DRM that prevents relinking? Even a translation
layer may not work. I’m doubtful GLib is compatible with PS4. Please
note that it is *not* compatible with Apple app stores. Asking the FSF
may indeed be a good idea.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Vala and GLib license

[rastersoft]

I suspect that Jens talks about creating a "translation layer" that
offers to the unmodified GLib all the system calls that it expects, like
"fopen, printf" and so on.


El 11/07/16 a las 17:42, Aleksandr Palamar escribió:
> Jens, do you mean something like linking GLib to your ownn closed source
> black box library with open API that is using specific Sony/Microsoft API
> inside without revealing those secret internal things to the public?
> On Jul 11, 2016 5:50 PM, "Jens Georg"  wrote:
>
> Yes. Obviously the two licenses are not compatible then. The only way out
> there
> would be a compatibility layer that translates those runtimes into something
> GLib can live with.
>
>
> Even if that would violate licence from Sony and Microsoft? Obviously,
>> sharing that code with someone who already has license from them to
>> use their API is not a problem at all. But sharing that code with
>> those who don't have such license will put me into trouble with that
>> companies, but even if people will have those sources - they are
>> useless without previous agreement with Sony/Microsoft and their SDK.
>> That's the one of the moments that kind of preventing me to look into
>> Vala more seriously in view of professional game development. I never
>> know where it will end. The thing is - I have bunch of old code that I
>> may to do some refactoring - go from old C code into C++ with bunch of
>> own new and old bicycles or just went with Vala step by step, maybe
>> even ending with helping community in places where I may be useful.
>> But even how much I don't like C++ as the language, at least I know I
>> won't have any license headache later. Vala looks way better in
>> comparison, but the license of it's core runtime... That was the whole
>> point of the subject.
>>
>> On Jul 11, 2016 5:25 PM, "Jens Georg"  wrote:
>>
>> But If I would need to patch GLib to work on PS4 or XBONE? I doubt
 that
 those platforms will allow me to share usage of their internal
 API. Can I
 keep those patch closed and share them only with people who has
 licenses
 for PS4 and XONE (you aren't able to put that patch in anyway if
 you are
 just standard customer and user of the console and not the
 developer) so
 they would able to use that new code as well, but not with others,
 because
 that may violate license of console platforms.

>>> No. Because you're patching (L)GPL code you would have to grant
>>> access to the modified sources
>>> ___
>>> 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
>

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

Re: [Vala] Vala and GLib license

[rastersoft]

Mmmm... that's a tricky question: you only need to grant access to the
modified sources to the people to whom you distributed the binaries.
This is: if you create a game with a modified GLIB library, and you sell
that binary game only to me, you must grant access to the modified
sources only to me, but not to other people, so, IN THEORY, as long as I
have a license from Sony or Microsoft, you won't be breaking your
license. The problem is that the LGPL allows me to redistribute the code
freely, but since it has code under other license, it would forbide me
to re-redistribute it to people without that license from Sony or
Microsoft... So I'm not sure.

I recomend you to ask to the FSF.

El 11/07/16 a las 16:25, Jens Georg escribió:
>
>> But If I would need to patch GLib to work on PS4 or XBONE? I doubt that
>> those platforms will allow me to share usage of their internal API.
>> Can I
>> keep those patch closed and share them only with people who has licenses
>> for PS4 and XONE (you aren't able to put that patch in anyway if you are
>> just standard customer and user of the console and not the developer) so
>> they would able to use that new code as well, but not with others,
>> because
>> that may violate license of console platforms.
>
> No. Because you're patching (L)GPL code you would have to grant access
> to the modified sources
> ___
> 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

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

Re: [Vala] Vala and GLib license

[Jens Georg]

Yes. Obviously the two licenses are not compatible then. The only way 
out there
would be a compatibility layer that translates those runtimes into 
something

GLib can live with.


Even if that would violate licence from Sony and Microsoft? Obviously,
sharing that code with someone who already has license from them to
use their API is not a problem at all. But sharing that code with
those who don't have such license will put me into trouble with that
companies, but even if people will have those sources - they are
useless without previous agreement with Sony/Microsoft and their SDK.
That's the one of the moments that kind of preventing me to look into
Vala more seriously in view of professional game development. I never
know where it will end. The thing is - I have bunch of old code that I
may to do some refactoring - go from old C code into C++ with bunch of
own new and old bicycles or just went with Vala step by step, maybe
even ending with helping community in places where I may be useful.
But even how much I don't like C++ as the language, at least I know I
won't have any license headache later. Vala looks way better in
comparison, but the license of it's core runtime... That was the whole
point of the subject.

On Jul 11, 2016 5:25 PM, "Jens Georg"  wrote:


But If I would need to patch GLib to work on PS4 or XBONE? I doubt
that
those platforms will allow me to share usage of their internal
API. Can I
keep those patch closed and share them only with people who has
licenses
for PS4 and XONE (you aren't able to put that patch in anyway if
you are
just standard customer and user of the console and not the
developer) so
they would able to use that new code as well, but not with others,
because
that may violate license of console platforms.


No. Because you're patching (L)GPL code you would have to grant
access to the modified sources
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

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

Re: [Vala] Vala and GLib license

[Jens Georg]

But If I would need to patch GLib to work on PS4 or XBONE? I doubt that
those platforms will allow me to share usage of their internal API. Can 
I
keep those patch closed and share them only with people who has 
licenses
for PS4 and XONE (you aren't able to put that patch in anyway if you 
are
just standard customer and user of the console and not the developer) 
so
they would able to use that new code as well, but not with others, 
because

that may violate license of console platforms.


No. Because you're patching (L)GPL code you would have to grant access 
to the modified sources

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

Re: [Vala] Vala and GLib license

[Aleksandr Palamar]

But If I would need to patch GLib to work on PS4 or XBONE? I doubt that
those platforms will allow me to share usage of their internal API. Can I
keep those patch closed and share them only with people who has licenses
for PS4 and XONE (you aren't able to put that patch in anyway if you are
just standard customer and user of the console and not the developer) so
they would able to use that new code as well, but not with others, because
that may violate license of console platforms.

On Mon, Jul 11, 2016 at 4:46 PM, Guillaume Poirier-Morency <
guillaumepoiriermore...@gmail.com> wrote:

> According to GNU's site, if you statically link with GLib, you have to
> at least provide users with object files (not necessarily sources) so
> that they can link against any version they like of the library under
> the LGPL.
>
> https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic
>
> For the rest, I cannot tell, but I'm pretty sure that LGPL is
> sufficiently permissive.
>
> Le lundi 11 juillet 2016 à 16:29 +0300, Aleksandr Palamar a écrit :
> > Hi, Vala-List users.
> >
> > I'm curious about GLib license (which is the core of Vala runtime),
> > mainly
> > because I'm thinking about using Vala in closed source (or zlib if
> > that
> > would be possible in future) project, which may (or not) be used on
> > different platforms including iOS (which doesn't allow dynamic
> > linkage),
> > PS4 and XBoxOne. Would it require to make application available under
> > LGPL
> > as well or I would able to kept application under any license I like
> > while
> > sharing (if target platform allows it, because I doubt about PS4 and
> > XONE)
> > changes for GLib if there was any. Just don't want to go wrong way
> > and
> > force myself to drain inside license problems in future.
> >
> > Regards, Aleksandr Palamar
> > ___
> > vala-list mailing list
> > vala-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/vala-list
> --
>
> Guillaume Poirier-Morency 
>
> Étudiant au baccalauréat en Informatique à l'Université de Montréal
> Développeur d'application web
>
> Mon blog: https://arteymix.github.io/
> Mon projet de coopérative: https://pittoresque.github.io/
> Clé PGP: B1AD6EA5
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Vala app crashing in vprintf on 32-bit arches, not on 64-bit arches

[Michael Gratton]

On Fri, Jun 17, 2016 at 7:55 AM, Michael Gratton  wrote:

Geary is suffering a bug which is causing it to frequently crash on
32-bit installations, in a place where it doesn't crash on a 64-bit
install. The crash occurs in vprintf, during a call to GLib.debug()
from an async method.


So it turns out the format string was bad ("%d" should have been "%lld" 
since a int64 was being passed in) but valac didn't complain - I only 
found the issue digging through the gcc output:


/home/mjg/geary/src/engine/imap-engine/imap-engine-minimal-folder.vala:1235:12: 
warning: format ‘%d’ expects argument of type ‘int’, but 
argument 7 has type ‘gint64 {aka long long int}’ [-Wformat=]
 debug("%s do_replay_removed_message: remote_position=%d 
unknown in local store "

^
/usr/include/glib-2.0/glib/gmessages.h:170:32: note: in definition of 
macro ‘g_debug’

__VA_ARGS__)

   ^

Bug filed: 

//Mike

--
⊨ Michael Gratton, Percept Wrangler.
⚙ 


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

Re: [Vala] Vala - webkit2gtk-4.0.vapi problem Debia Jessie

[Daniel Espinosa]

If you really need both, I don't know if that is possible or recommended,
but you can create a library with widgets you will use in your apps using
different PKG flags.
El abr. 5, 2016 7:51 PM, "Edwin De La Cruz"  escribió:

> Best regards. Again I come to you with a problem I have to use Debian
> webkti Vala with Jessie . When I compiled the following message :
>
> webkit2gtk-web-extension-4.0.vapi:2619.2-2619.38: error: `WebKit'
> already contains a definition for `URIRequest'
> public class URIRequest : GLib.Object {
> ^
> webkit2gtk-4.0.vapi:488.2-488.38: note: previous definition of
> `URIRequest' was here
> public class URIRequest : GLib.Object {
> ^
> webkit2gtk-web-extension-4.0.vapi:2628.2-2628.39: error: `WebKit'
> already contains a definition for `URIResponse'
> public class URIResponse : GLib.Object {
> ^^
> webkit2gtk-4.0.vapi:497.2-497.39: note: previous definition of
> `URIResponse' was here
> public class URIResponse : GLib.Object {
> ^^
> Compilation failed: 2 error(s), 0 warning(s)
>
>
> I have researched and according to some messages is not possible to
> use webkit2gtk -web -extension- 4.0 and webkit2gtk -4.0 at the same
> time :
>
> valac gtk + -3.0 --pkg --pkg webkit2gtk -4.0 --pkg webkit2gtk -web
> -extension- 4.0 wk.vala
>
> So what alternative I can use?
> Or as I use the library ?
>
> I hope I can lead.
> Thank you.
>
>
>
> Mis proyectos de software libre en:
> Github - edwinspire
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Vala wishlist

[Ben]

On Tue, 2016-01-12 at 21:54 +, Afonso wrote:
> My thoughs about Vala
> =
> 
> I just started coding in Vala, and i found it's a quite fun language
> to learn, very simillar to Java and C#. The integration with GLib and
> GObject is simply amazing, and the possibilty to generate C code is
> also very pleasant.
> 
> As `Vala` is still in a development phase, I would like to suggest
> a few features that could help `Vala` reach the next big step.
> 
> 
> # More functional support
> 
> Altough `Vala` has support for closures, it would be good to hava
> even
> more functional power.
> 
> For example, `Vala` could ship with a `filter` function that supports
> every Gee Collection, something like:
> 
>  var books = new TreeSet ();
>  books_from_year = books.filter ( (b) => { return year == 1952; });

Gee collections have .filter, but they return a Gee.Iterator

> 
> Other functions could behave the same way, like `map`, `reverse`,
> `folds`, `all`, `any`, `or`, `all`, `takeWhile`, `dropWhile` just to
> mention a few (i know, i know, Vala != Haskell xD).
> 
> Also, most closures end with a return statement. It would be a lot
> cleaner if one could skip the `return` statement, for example:
> 
>  var f = (a) => { a == 2; }; // Instead of { return a == 2; }
> 
> It does much more sense in a closure context not to have a return
> statement. 
You can do
   var f = (a) => a == 2;

> Also with mutliple statements closures, `Vala` could behave
> a little bit like `Ruby`, and automatically infer what does the
> closure returns:
> 
>  var f = ( a, b ) => {
>   a = b - 1;
>   if ( a > b )
>    "ok"; // return "ok";
>   else
>    "not ok"; // return "not ok";
>  };
> 
> 
> # More syntatic sugar for print
> 
> Whenever `stdout.printf` or `print` are invoked with an object,
> automatically use `to_string ()` method (like `Java`).
> For example, suppose we have the following class definition:
> 
>  public class Book : Object {
>   public string title { get; set; }
>   public int year { get; set; }
> 
>   public string to_string () {
>    return "Title: %s, Year: %d".printf(this.title, this.year);
>   }
>  }
> 
> It would be nice if we could simply print an object like this:
> 
>  void main (string[] args) {
>   Book b = new Book ("The Old Man and the Sea", 1952);
>   print (b); // <=> print (b.to_string());
> 
>   /* Output:
>   >> Title: The Old Man and the Sea, Year: 1952
>   */
>  }
> 
> 
> Automatic array printing for basic types (and objects - using
> `to_string ()` method), like so:
> 
>   void main (string[] args) {
>    string[] authors = { "George Orwell", "John Steinbeck" };
>    int[] years = { 1999, 2000, 2001 };
> 
>   Book b1 = new Book ("The Old Man and the Sea", 1952);
>   Book b2 = new Book ("The Pearl", 1973);
> 
>   Book[] books = { b1, b2 };
> 
>    print (authors);
>    print (years);
>    print (books);
> 
>    /* Output:
>    >> ["George Orwell", "John Steinbeck"]
>    >> [1999, 2000, 2001]
>    >> [Title: The Old Man and the Sea, Year: 1952,
>    Title: The Pearl, Year: 1973]
>    */
> 
>   }

Vala will automatically call to_string() in template strings: 
print (@"$authors\n$years\n);

> 
> Wish you all the best regards
> 
> 3º ano, Mestrado Integrado em Engenharia Informática,
> Universidade do Minho
> 
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Vala wishlist

[yannick inizan]

'to_string' hack exists :

int number = 33;
print (@"$number");

Gee.Traversable supports 'fold' and other few functions :
http://valadoc.org/#!api=gee-0.8/Gee.Traversable

2016-01-12 22:54 GMT+01:00 Afonso :

> My thoughs about Vala
> =
>
> I just started coding in Vala, and i found it's a quite fun language
> to learn, very simillar to Java and C#. The integration with GLib and
> GObject is simply amazing, and the possibilty to generate C code is
> also very pleasant.
>
> As `Vala` is still in a development phase, I would like to suggest
> a few features that could help `Vala` reach the next big step.
>
>
> # More functional support
>
> Altough `Vala` has support for closures, it would be good to hava even
> more functional power.
>
> For example, `Vala` could ship with a `filter` function that supports
> every Gee Collection, something like:
>
> var books = new TreeSet ();
> books_from_year = books.filter ( (b) => { return year == 1952; });
>
> Other functions could behave the same way, like `map`, `reverse`,
> `folds`, `all`, `any`, `or`, `all`, `takeWhile`, `dropWhile` just to
> mention a few (i know, i know, Vala != Haskell xD).
>
> Also, most closures end with a return statement. It would be a lot
> cleaner if one could skip the `return` statement, for example:
>
> var f = (a) => { a == 2; }; // Instead of { return a == 2; }
>
> It does much more sense in a closure context not to have a return
> statement. Also with mutliple statements closures, `Vala` could behave
> a little bit like `Ruby`, and automatically infer what does the
> closure returns:
>
> var f = ( a, b ) => {
>  a = b - 1;
>  if ( a > b )
>   "ok"; // return "ok";
>  else
>   "not ok"; // return "not ok";
> };
>
>
> # More syntatic sugar for print
>
> Whenever `stdout.printf` or `print` are invoked with an object,
> automatically use `to_string ()` method (like `Java`).
> For example, suppose we have the following class definition:
>
> public class Book : Object {
>  public string title { get; set; }
>  public int year { get; set; }
>
>  public string to_string () {
>   return "Title: %s, Year: %d".printf(this.title, this.year);
>  }
> }
>
> It would be nice if we could simply print an object like this:
>
> void main (string[] args) {
>  Book b = new Book ("The Old Man and the Sea", 1952);
>  print (b); // <=> print (b.to_string());
>
>  /* Output:
>  >> Title: The Old Man and the Sea, Year: 1952
>  */
> }
>
>
> Automatic array printing for basic types (and objects - using
> `to_string ()` method), like so:
>
>  void main (string[] args) {
>   string[] authors = { "George Orwell", "John Steinbeck" };
>   int[] years = { 1999, 2000, 2001 };
>
>  Book b1 = new Book ("The Old Man and the Sea", 1952);
>  Book b2 = new Book ("The Pearl", 1973);
>
>  Book[] books = { b1, b2 };
>
>   print (authors);
>   print (years);
>   print (books);
>
>   /* Output:
>   >> ["George Orwell", "John Steinbeck"]
>   >> [1999, 2000, 2001]
>   >> [Title: The Old Man and the Sea, Year: 1952,
>   Title: The Pearl, Year: 1973]
>   */
>
>  }
>
> Wish you all the best regards
>
> 3º ano, Mestrado Integrado em Engenharia Informática,
> Universidade do Minho
>
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Vala 0.31 for Windows

[yannick inizan]

latest stable version is available on MSYS2 repositories

2016-02-15 21:45 GMT+01:00 :

> Hello everyone !
>
> I have build the latest version of Vala for Windows. You can find it here
> :
> https://cloud.openmailbox.org/index.php/apps/files/ajax/download.php?dir=%2FPartag%C3%A9=vala-0.31-setup.exe
>
> Could someone upload it to the GNOME server and update the link in the
> Vala wiki if possible ? Thanks
>
> (And excuse me for English mistakes, I am not a native speaker).
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Vala plugin for MonoDevelop

[Al Thomas]

> From: Gottfried F. Zojer 

> Sent: Saturday, 5 December 2015, 12:21
> Subject: [Vala] Vala plugin for MonoDevelop
> 
> Just wondering if anyone is using vala plugin within monodevelop IDE on a
> Raspberry 2.
> 
> Any feedback welcome



I came across Atom editor the other day.
It sounds promising and could be one to watch.
Not sure it works on the Pi:
https://github.com/atom/atom/issues/7822

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

Re: [Vala] Vala API causing double definition

[Victor A. Santos]

Got it, the problem was the vapi file includes some headers that include 
the header generated by the vala compiler, which shouldn't happen as I can 
see.


Any way, thanks to all ;)
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Vala API causing double definition

[Victor Aurélio Santos]

PS: keep in mind that this isn't a GLib-based library, it's plain C
functions! i.e. Legacy Binds

-- 
Victor Aurélio Santos
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Vala API causing double definition

[Victor Aurélio Santos]

Ben, can you provide more details ?

Thanks.

2015-10-09 10:49 GMT-03:00 Ben Iofel :
> Just put the cheader at the top
>
>
> On Fri, Oct 9, 2015, 9:48 AM Victor Aurélio Santos
>  wrote:
>>
>> PS: keep in mind that this isn't a GLib-based library, it's plain C
>> functions! i.e. Legacy Binds
>>
>> --
>> Victor Aurélio Santos



-- 
Victor Aurélio Santos
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Vala API causing double definition

[Ben Iofel]

Just put the cheader at the top

On Fri, Oct 9, 2015, 9:48 AM Victor Aurélio Santos <
victoraur.san...@gmail.com> wrote:

> PS: keep in mind that this isn't a GLib-based library, it's plain C
> functions! i.e. Legacy Binds
>
> --
> Victor Aurélio Santos
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Vala API causing double definition

[Victor Aurélio Santos]

There's no ajami.h, and just [CCode (cprefix = "Ajami_")] changes
nothing keep getting double definition.

2015-10-08 22:26 GMT-03:00 Ben :
> I think you need [CCode (cprefix = "Ajami_", cheader_filename = "ajami.h")]
> on your top namespace
>
> On Thu, Oct 8, 2015 at 7:29 PM, Victor Aurélio Santos
>  wrote:
>
> Hi, consider the following Vala API file: namespace CAjami { [CCode (cprefix
> = "io_", cheader_filename = "io.h")] namespace IO { [CCode (cname =
> "io_init")] public void init(); [CCode (cname = "io_cleanup")] public void
> cleanup(); } } there's something wrong with that ?, every time I use
> CAjami.IO.cleanup(); inside a member the class get duplicated definition, if
> i just comment out the line with cleanup(); function it compiles normal. the
> vala code: public override void shutdown() { base.shutdown();
> CAjami.IO.cleanup(); } and the error: build/src/ajamiapp.c:66:8: error:
> redefinition of '_AjamiAjami' struct _AjamiAjami {
> build/src/ajamiobjects.h:111:8: note: previous definition is here struct
> _AjamiAjami { build/src/ajamiapp.c:71:8: error: redefinition of
> '_AjamiAjamiClass' struct _AjamiAjamiClass { build/src/ajamiobjects.h:116:8:
> note: previous definition is here struct _AjamiAjamiClass { if I just
> comment out the call the function in the shutdown() signal is build normal.
> Thanks.
> --
> Victor Aurélio Santos ___
> vala-list mailing list vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list



-- 
Victor Aurélio Santos
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Vala API causing double definition

[Ben]

the cheader_filename attribute of [CCode] should go on the top 
namespace.


so [CCode (cheader_filename="io.h", cprefix="Ajami_")] namespace CAjami 
{ ... }


On Fri, Oct 9, 2015 at 9:55 AM, Victor Aurélio Santos 
 wrote:

Ben, can you provide more details ?

Thanks.

2015-10-09 10:49 GMT-03:00 Ben Iofel :

 Just put the cheader at the top


 On Fri, Oct 9, 2015, 9:48 AM Victor Aurélio Santos
  wrote:


 PS: keep in mind that this isn't a GLib-based library, it's plain C
 functions! i.e. Legacy Binds

 --
 Victor Aurélio Santos




--
Victor Aurélio Santos

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

Re: [Vala] vala-list Digest, Vol 86, Issue 5

[gontzal]

ar., 2015.eko urtren 20a 13:00(e)an, vala-list-requ...@gnome.org 
igorleak idatzi zuen:

Send vala-list mailing list submissions to
vala-list@gnome.org

To subscribe or unsubscribe via the World Wide Web, visit
https://mail.gnome.org/mailman/listinfo/vala-list
or, via email, send a message with subject or body 'help' to
vala-list-requ...@gnome.org

You can reach the person managing the list at
vala-list-ow...@gnome.org

When replying, please edit your Subject line so it is more specific
than Re: Contents of vala-list digest...


Today's Topics:

1. Windows compiling; Error with GSettings usen FileChooser.
   (Gontzal Uriarte)
2. Re: Windows compiling; Error with GSettings usen
   FileChooser. (Tarnyko)


--

Message: 1
Date: Tue, 20 Jan 2015 10:16:20 +0100
From: Gontzal Uriarte txasato...@gmail.com
To: vala-list@gnome.org
Subject: [Vala] Windows compiling; Error with GSettings usen
FileChooser.
Message-ID:
CADsu+Bbp+VWVKJHTT1-xWvLdReupLU3ZsLutho=12osgujo...@mail.gmail.com
Content-Type: text/plain; charset=UTF-8

Hello!
I hate windows
But there is no way, when all my school teaches using it!!!
I have finished one free program in Genie. Is like a Interactive Activity
Book but offline. (there is a lot of them online)
named kataderno (see at gitorious)
Ubuntu instalers for teachers book constructor
https://www.dropbox.com/s/xr71tia01ofiiq3/katadernoconstructor_1.0-1_i386.deb?dl=0
and learners book
https://www.dropbox.com/s/ce0ts4tlaw2l8xr/katadernouser_1.0-1_i386.deb?dl=0
.
I have compiled for windows with Tarnyko's tools (ValaWinPKG). All went all
right, but when the program want to show a
Filechooser... Blop... error message: Glib-gio-ERROR No GSettings schemas
are installed on the system.

Note: My application is portable.
Any Ideas about this?

Gontzal.


--

Message: 2
Date: Tue, 20 Jan 2015 11:06:24 +0100
From: Tarnyko tarn...@tarnyko.net
To: Gontzal Uriarte txasato...@gmail.com
Cc: vala-list@gnome.org
Subject: Re: [Vala] Windows compiling; Error with GSettings usen
FileChooser.
Message-ID: e1ydvhy-00021x...@s15847124.domainepardefaut.fr
Content-Type: text/plain; charset=utf-8; format=flowed

Hi Gontzal,

This usually means GTK+'s schemas have not been correctly installed. Try
this :

glib-compile-schemas share\glib-2.0\schemas

when the schemas folder contains the
org.gtk.Settings.FileChooser.gschema.xml file.

Regards,
Tarnyko

Gontzal Uriarte writes:


Hello!
I hate windows
But there is no way, when all my school teaches using it!!!
I have finished one free program in Genie. Is like a Interactive Activity
Book but offline. (there is a lot of them online)
named kataderno (see at gitorious)
Ubuntu instalers for teachers book constructor
https://www.dropbox.com/s/xr71tia01ofiiq3/katadernoconstructor_1.0-1_i386.deb?dl=0
and learners book
https://www.dropbox.com/s/ce0ts4tlaw2l8xr/katadernouser_1.0-1_i386.deb?dl=0
.
I have compiled for windows with Tarnyko's tools (ValaWinPKG). All went all
right, but when the program want to show a
Filechooser... Blop... error message: Glib-gio-ERROR No GSettings schemas
are installed on the system.

Note: My application is portable.
Any Ideas about this?

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


--

Subject: Digest Footer

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


--

End of vala-list Digest, Vol 86, Issue 5

Ok...thanks Tarnyko!!. I have created a new directory in the portable 
app directory named:shaere/glib-2.0/schemas and there i have compiled 
the schemas as you write.

I goes!!!
thanks!!
But, i have another one question may be in other question mail.
Thanks!!
Gontzal.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] vala generated function naming

[Jeremy Slater]

On Sun, Oct 12, 2014 at 11:38 AM, Abderrahim Kitouni
a.kito...@gmail.com wrote:

 Hello,

 Le 12 oct. 2014 15:04, Jeremy Slater jas...@gmail.com a écrit :
 
  I'm having an issue with the way vala generates names for functions like
  callback wrappers and struct array free routines.  I am writing a vapi for
  a library that does not typedef structures, so in my vapi I have to set the
  cname to include struct, i.e. cname=struct some_structure.  This results
  in the generated free for an array of some_structure being generated as
  _vala_struct some_structure_array_free.

 You should use lower_case_cname as well. (not sure of the spelling though, 
 take a look at other vapid)

lower_case_cprefix (I assume is what you meant) appears to only be
used for the direct struct methods like destroy and copy.  the
array_free method for freeing the array of structs, is only
constructed directly from the cname.  The relevant code,
append_struct_array_free, appears to be around
valaccodearraymodule.vala:205.

  In addition, the header I am wrapping defines callbacks as function
  definitions, rather than function pointers.  So when I define my delegates
  I have to include the * in the cname:  cname=callback_function *.  This
  results in a wrapper function for a delegate of test_callback being
  generated as _test_callback_callback_function *.

 Sorry, I didn't understand this part.

So the 'normal' typedef for passing around functions, is using a
function pointer, like:

  typedef int (*get_integer)(int param);

But sometimes headers just declare the function, rather than the pointer:

  typedef int (get_integer)(int param);

This doesn't map into the delegate definition in vala however, so I
need to set the cname for the delegate as the pointer to the function
definition, i.e. cname=get_integer *.
___
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] vala cross-compiling

[Michele Dionisio]

yes I'm speaking about vapigen

after checkin: 7a4f0befbd58286a69367ba78d16187da25724f7
build: Make building vapigen non-optional

it is not more possible to use --disable-vapigen

 miki@HP-EliteBook-840-G1:~/Develop/vala (master) $ git log -1
 commit 3658f709ba698bf6fcfb989c193a5451ff5a147d
 Author: Jürg Billeter j...@bitron.ch
 Date:   Mon Sep 15 18:37:11 2014 +0200

 Release 0.25.4
 miki@HP-EliteBook-840-G1:~/Develop/vala (master) $ ./autogen.sh
--disable-vapigen
 autoreconf: Entering directory `.'
 autoreconf: configure.ac: not using Gettext
 autoreconf: running: aclocal -I m4
 autoreconf: configure.ac: tracing
 autoreconf: running: libtoolize --copy
 autoreconf: running: /usr/bin/autoconf
 autoreconf: running: /usr/bin/autoheader
 autoreconf: running: automake --add-missing --copy --no-force
 autoreconf: Leaving directory `.'
 configure: WARNING: unrecognized options: --disable-vapigen

Not I'm starting to test only rollingback that checkin.

regards





2014-09-16 10:14 GMT+02:00 Luca Bruno lethalma...@gmail.com:

 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

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

Re: [Vala] vala-list Digest, Vol 81, Issue 17

[Marek Gibek]

It should work with MonoDevelop 5.0 and 5.1.

Now I'm upgrading it for MonoDevelop 5.4 and testing under Linux. And
you know what? The debugger works under Linux!!! :D (Maybe it works on
Windows too, but I cannot find working gdb 64-bit and I failed to
compile it myself - I should switch to Linux ;)).

So, please wait a moment - I will announce it and share binary file
when finished.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] vala-list Digest, Vol 81, Issue 17

[Unee0x]

Hey I was just wondering, will this plugin work Linux's monodevelop ?

Sent from my iPhone

 On Aug 30, 2014, at 8:00 AM, vala-list-requ...@gnome.org wrote:
 
 Send vala-list mailing list submissions to
vala-list@gnome.org
 
 To subscribe or unsubscribe via the World Wide Web, visit
https://mail.gnome.org/mailman/listinfo/vala-list
 or, via email, send a message with subject or body 'help' to
vala-list-requ...@gnome.org
 
 You can reach the person managing the list at
vala-list-ow...@gnome.org
 
 When replying, please edit your Subject line so it is more specific
 than Re: Contents of vala-list digest...
 
 
 Today's Topics:
 
   1. [ANNOUNCE] Portable Windows version (MonoDevelop 5.1.4, vala
  0.25.1, mingw64 4.9.1) (Marek Gibek)
   2. Re: [ANNOUNCE] Portable Windows version (MonoDevelop 5.1.4,
  vala 0.25.1, mingw64 4.9.1) (Luca Bruno)
 
 
 --
 
 Message: 1
 Date: Sat, 30 Aug 2014 11:36:27 +0200
 From: Marek Gibek gib...@gmail.com
 To: vala-list@gnome.org
 Subject: [Vala] [ANNOUNCE] Portable Windows version (MonoDevelop
5.1.4, vala 0.25.1, mingw64 4.9.1)
 Message-ID:
CAH4D7VcFr9r7UOtV48+GsL1+yvcfRPW3t023YcPx+PG0u=j...@mail.gmail.com
 Content-Type: text/plain; charset=UTF-8
 
 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
 
 
 --
 
 Message: 2
 Date: Sat, 30 Aug 2014 11:44:14 +0200
 From: Luca Bruno lethalma...@gmail.com
 To: Marek Gibek gib...@gmail.com
 Cc: Vala List vala-list@gnome.org
 Subject: Re: [Vala] [ANNOUNCE] Portable Windows version (MonoDevelop
5.1.4, vala 0.25.1, mingw64 4.9.1)
 Message-ID:
CAHXTfc8j_2QZ4gHw+aOyD1cefrHe+KEtY+k=msp5jkwbk-k...@mail.gmail.com
 Content-Type: text/plain; charset=UTF-8
 
 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: 

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] vala friendly atomic pointer

[Nor Jaidi Tuah]

 Not the simplest solution, but works well.

After thinking more about my problem, I don't
think any reliable efficient solution is going
to be simple. Thanks for the input.


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

Re: [Vala] vala friendly atomic pointer

[Maciej Piechotka]

On Thu, 2013-12-19 at 17:16 +0200, Tal Hadad wrote:
http://www.valadoc.org/#!api=gobject-2.0/GLib.WeakRef
 
 This is a simple solution thanks to the good design of GObject.
 
 Tal
 
 
That might not always work, unfortunatly, due to how structs are
implemented[1]. Beside - they are implemented currently using global
lock in GObject[2].

 From: norjaidi.t...@ubd.edu.bn
  To: vala-list@gnome.org
  Date: Thu, 19 Dec 2013 08:59:44 +0800
  Subject: [Vala] vala friendly atomic pointer
  
  Dear all,
  
  I want to implement something like these:
 *  x = AtomicPointer.@get (ref atomicRef)   // reader
  
 *  AtomicPointer.@set (ref atomicRef, newref)  // writer
  
 *  return AtomicPointer.@get (ref atomicRef)  // reader
  
  but have the benefit of vala ref counting.
  
  The best I can think of is:
  
 *  lock (atomicRef) { x = atomicRef; }
  
 *  lock (atomicRef) { atomicRef = newref; }
  
 *  lock (atomicRef) { return atomicRef; }
  
  But lock is too course.
  e.g., lock (atomicRef) {x = atomicRef;} will also lock
  out other readers, whereas AtomicPointer.get won't.
  
  I realise that the exclusive region is small.
  But if you have a lot of readers, the effect
  may be significant.
  
  Any suggestions?
  
  
  Nice day
  Nor Jaidi Tuah
  
  
 
The combination of lock free and reference pointers is 'hard' (as long
as you don't have double word CAS operation which is not implemented on
practically any hardware). The only way I know about is by
HazardPointers.

Gee 0.8 or newer have it's implementation of HazardPointers[3]. The
basic usage is as follows:

MyObject *object_ptr;

MyObject *read_object = HazardPointer.get_pointerMyObject
(object_ptr);

The drawback is that you need to ensure that all operations are in
HazardPointer.Context. You want the context to live in thread as long as
you know that operation is taking place. Upon destruction all pointers
are freed (exact method is specified by policy).

Regards

[1] https://bugzilla.gnome.org/show_bug.cgi?id=703996
[2] https://bugzilla.gnome.org/show_bug.cgi?id=705728
[3] http://www.valadoc.org/#!api=gee-0.8/Gee.HazardPointer


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

Re: [Vala] vala friendly atomic pointer

[Nor Jaidi Tuah]

Thanks for the replies.

It seems that WeakRef doesn't help with the granularity:
multiple readers will lock out each other (I hope I'm
wrong here). Besides, from
https://bugzilla.gnome.org/show_bug.cgi?id=703996
it appears that WeakRef is totally broken.

As for HazardPointers, according to the documentation:
 HazardPointers are not thread-safe (unless documentation
 states otherwise)

I wish vala has lockread in addition to lock.


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

Re: [Vala] vala friendly atomic pointer

[Maciej Piechotka]

On Sat, 2013-12-21 at 11:41 +0800, Nor Jaidi Tuah wrote:
 Thanks for the replies.
 
 It seems that WeakRef doesn't help with the granularity:
 multiple readers will lock out each other (I hope I'm
 wrong here). Besides, from
 https://bugzilla.gnome.org/show_bug.cgi?id=703996
 it appears that WeakRef is totally broken.
 
 As for HazardPointers, according to the documentation:
  HazardPointers are not thread-safe (unless documentation
  states otherwise)
 
 I wish vala has lockread in addition to lock.
 

(I've wrote both the HazardPointers and documentations to them)

HazardPointers as structure are not thread safe - i.e. you cannot access
single HazardPointer from multiple threads. However they do allow
multi-thread access (that's their purpose).

Best regards


signature.asc
Description: This is a digitally signed message part
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] vala friendly atomic pointer

[Maciej Piechotka]

On Sat, 2013-12-21 at 07:08 +0100, Maciej Piechotka wrote:
 On Sat, 2013-12-21 at 11:41 +0800, Nor Jaidi Tuah wrote:
  Thanks for the replies.
  
  It seems that WeakRef doesn't help with the granularity:
  multiple readers will lock out each other (I hope I'm
  wrong here). Besides, from
  https://bugzilla.gnome.org/show_bug.cgi?id=703996
  it appears that WeakRef is totally broken.
  
  As for HazardPointers, according to the documentation:
   HazardPointers are not thread-safe (unless documentation
   states otherwise)
  
  I wish vala has lockread in addition to lock.
  
 
 (I've wrote both the HazardPointers and documentations to them)
 
 HazardPointers as structure are not thread safe - i.e. you cannot access
 single HazardPointer from multiple threads. However they do allow
 multi-thread access (that's their purpose).
 

Possibly to clarify - I have written the implementation in the Gee, not
invent the whole concept[1]. The idea of the whole concept is to access
threads is thread safe manner so if it is not clear from documentation
it means I need to fix the documentation.

With Gee.HazardPointer you have following 'moving parts':
 - Context(s): Per-thread and organized in a stack. They ensure that
memory will be freed even if thread does not call into Gee for a long
time while not forcing synchronization at each operation.
 - HazardPointer: Denotes a pointer in use. They are not thread safe in
a sense that they are per-thread and short lived. Consider it a 'reader'
operation. They are however needed when you use unowned data (see the
example in documentation).
 - Atomic storage (pointers): Shared storage (i.e. normal memory
accessed by atomic operations). However they can be accessed only by the
HazardPointer operations.

Best regards

[1] What HP is: http://en.wikipedia.org/wiki/Hazard_pointer



signature.asc
Description: This is a digitally signed message part
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] vala friendly atomic pointer

[Nor Jaidi Tuah]

Thank you for the clarification and the link
on HazardPointer.


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

Re: [Vala] vala friendly atomic pointer

[Tal Hadad]

http://www.valadoc.org/#!api=gobject-2.0/GLib.WeakRef

This is a simple solution thanks to the good design of GObject.

Tal

 From: norjaidi.t...@ubd.edu.bn
 To: vala-list@gnome.org
 Date: Thu, 19 Dec 2013 08:59:44 +0800
 Subject: [Vala] vala friendly atomic pointer
 
 Dear all,
 
 I want to implement something like these:
*  x = AtomicPointer.@get (ref atomicRef)   // reader
 
*  AtomicPointer.@set (ref atomicRef, newref)  // writer
 
*  return AtomicPointer.@get (ref atomicRef)  // reader
 
 but have the benefit of vala ref counting.
 
 The best I can think of is:
 
*  lock (atomicRef) { x = atomicRef; }
 
*  lock (atomicRef) { atomicRef = newref; }
 
*  lock (atomicRef) { return atomicRef; }
 
 But lock is too course.
 e.g., lock (atomicRef) {x = atomicRef;} will also lock
 out other readers, whereas AtomicPointer.get won't.
 
 I realise that the exclusive region is small.
 But if you have a lot of readers, the effect
 may be significant.
 
 Any suggestions?
 
 
 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
  
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] vala libgda LINQ

[Juarez Rudsatz]

Luca, Daniel,

LINQ is just some kind of syntax for some functional
 programming aspects. It's about to be a 1:1 mapping with
 filter-map, also fold and scan..


You are mostly correct about LINQ to Objects.
In this case the .net designers capitalized from the popularity of LINQ to
SQL and used the same syntax and naming to add this support to .Net.
I also agree that is not necessary to force the language syntax to get the
desired results.

But LINQ to Entities and LINQ to SQL are different beasts:

Quoting [1] :

 LINQ-to-Objects is a set of extension methods on IEnumerableT that
 allow you to perform in-memory query operations on arbitrary sequences of
 objects. The methods accept simple delegates when necessary.

 LINQ-to-Entities is a LINQ provider that has a set of extension methods on
 IQueryableT. The methods build up an expression tree (which is why
 delegates are actually passed as Expressions), and the provider will
 build up a SQL query based on its parsing of that expression tree.


The L2E implements a ORM that executes the following workflow:

Language syntax - Expression Tree - Query caching - SQL text - database
- serialization - collection objects in languge.

For example, in this code:

var db = new MyDatabaseContext();
var query =
from c in db.Contacts
join o in db.Orders
on c.ContactId == o.ContactId
join p in db.Payments
on p.Number == p.OrderNumber
where p.DueDate  DateTime.Today()
 p.PaidValue  o.Amount
select new
{
ContactName = c.Name,
ContactPhone = c.Phone,
OrderNumber = o.Number,
o.Amount,
o.DueDate,
AmountPaid = p.PaidValue
};

foreach(var contact in query)
{
print(%30s %10s %8i %10f %10d %10f,
contact.ContactName,
contact.ContactPhone,
contact.Amount,
contact.DueDate,
contact.AmountPaid
);
}

What are the language features needed that I still haven't found in Vala:

1) Expression Support, type instrospection support

The whole query statement above is not evaluated locally.
Instead it builds a Expression Tree (AST) and when invocated in foreach
loop it builds a SQL Query and execute against a database, object
repository, etc...

I couldn't find in vala how to store the expression where *p.DueDate 
DateTime.Today()  p.PaidValue  o.Amount* in a Expression tree for
using it later for building a SQL query.

2) Type Aliasing

The classes db.Contacts, db.Orders and db.Payments are aliased to c, o and
p and used after to indicate what class you are refering.
Classes could be refered twice like in Person as teacher and Person as
student.

Why this is important:
Because it binds the language type safety to the data model you have.
Database applications are just boring repetitions of user input forms,
reports and data procedures. When you change a table/class the compiler
will help you check when the name/type change will break your code.
Database aplications usually have hundreds of tables/classes and thousand
of queries and type safety cut the much of the maintanance burden.

3) Anonymous objects

Afte the query get back the results are materialized/serialized to a new
anonymous type with local scope.
In this example the select new statement creates a collection of anonymous
objects. The var query gives to the variable this anonymous type.

Why this is important:
Because it saves the cuts a lot of code for declaring a new class that will
be used once.

I hope this could help understand what the benefits of a language
integrated ORM for data intensive applications. Some things could add
flexibility to language itself.

Other features of LINQ to  Entities:

a) Lazy loading

public class Person
{
string name { get; set; }
Address address { get; set; }
}

// get a record from Person table
Person friend =
from f in db.Persons
where f.Name = Luca
select f;

// Get a record from address table
print(friend.address.street);

b) Inheritance

public class Customer : Person { ... }



[1]
http://stackoverflow.com/questions/7192040/linq-to-entities-vs-linq-to-objects-are-they-the-same
[2]
http://maanshah.wordpress.com/2012/03/02/linq-to-sql-vs-linq-to-objects-vs-linq-to-entities/


 2013/12/4 Daniel Espinosa eso...@gmail.com




 2013/12/3 Juarez Rudsatz juar...@gmail.com

 I checked the samples and some parts of the code.
 Nice work. :-)

 Regarding language support, it seems to remain a good amount of work to
 be done yet.

 Do you mean Vala features right?

  I'm counting the language features that will be necessary:
 - Object serialization

 Are you mean write some where. For XML serialization we have Vala's GXml
 project[1]. On GXml's serialization branch, you'll find my work on GObject
 serialization to XML, comparable with .NET but, I think more flexible[2].

 - Anonymous types

 - Expression and type introspection
 - Type aliasing...
 - Syntax changes


 At the end a Collection have objects with a set of properties, a SELECT
 expression is a 

Re: [Vala] vala libgda LINQ

[Luca Bruno]

LINQ is just some kind of syntax for some functional programming 
aspects. It's about to be a 1:1 mapping with filter-map, also fold and 
scan..


For example:
select field1,field2 from collection where field3==value
can be written as:
collection.filter((r) = r.field3==value).map((r) = {r.field1, r.field2});
Obviously, LINQ is not only that, but that's a good approximation.

That said, implement filter, map and fold in your collections library 
and you can avoid the LINQ syntax :-)
Consider libgee has filter, map, fold and scan with which you can 
implement a large subset of LINQ, including aggregate operators.

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

Re: [Vala] vala libgda LINQ

[Daniel Espinosa]

2013/12/4 Luca Bruno lethalma...@gmail.com

 LINQ is just some kind of syntax for some functional programming aspects.
 It's about to be a 1:1 mapping with filter-map, also fold and scan..

 For example:
 select field1,field2 from collection where field3==value
 can be written as:
 collection.filter((r) = r.field3==value).map((r) = {r.field1, r.field2});
 Obviously, LINQ is not only that, but that's a good approximation.


Vala has provide nice/sexy syntax for GObject/C programing. Have added lot
of new features, witch have been possible to write in C but with lot of
lines of code. I love Vala because allows me to be more productive, even
Genie allows more simplification on Vala's syntax.

I think that former syntax are more productive and easy to read than the
last. Could allow to work with-in Vala's code with lot of data from a
DataBase or any other data source. GdaData objects and interfaces allows to
access that data using just GObjects and Vala code, abstracting most of
internal operations and mapping to properties and methods, and allow to use
Gee collections to make more easy to access to data using by code; but
could reach a next level by adding some syntax support on Vala for SQL like
queries.

I know that adding syntax support may is not easy or is far from Vala
principles.

Then I would like to see a way to allows Vala compiler with a mechanism of
PLUG-INS for syntax support. Then GdaData could add its own plug-in for SQL
syntax when it is installed.

The above allows not to distract Vala from its principles, but allows to
others add syntax for specific task that makes more easy/productive and
clear way to do the same.

Less code and clear syntax, allows more productive less errors.


 That said, implement filter, map and fold in your collections library and
 you can avoid the LINQ syntax :-)
 Consider libgee has filter, map, fold and scan with which you can
 implement a large subset of LINQ, including aggregate operators.
 ___
 vala-list mailing list
 vala-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/vala-list




-- 
Trabajar, la mejor arma para tu superación
de grano en grano, se hace la arena (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] vala libgda LINQ

[Luca Bruno]

On 04/12/2013 16:52, Daniel Espinosa wrote:


Vala has provide nice/sexy syntax for GObject/C programing. Have added 
lot of new features, witch have been possible to write in C but with 
lot of lines of code. I love Vala because allows me to be more 
productive, even Genie allows more simplification on Vala's syntax.


I think that former syntax are more productive and easy to read than 
the last. Could allow to work with-in Vala's code with lot of data 
from a DataBase or any other data source. GdaData objects and 
interfaces allows to access that data using just GObjects and Vala 
code, abstracting most of internal operations and mapping to 
properties and methods, and allow to use Gee collections to make more 
easy to access to data using by code; but could reach a next level by 
adding some syntax support on Vala for SQL like queries.


I know that adding syntax support may is not easy or is far from Vala 
principles.


Then I would like to see a way to allows Vala compiler with a 
mechanism of PLUG-INS for syntax support. Then GdaData could add its 
own plug-in for SQL syntax when it is installed.


The above allows not to distract Vala from its principles, but allows 
to others add syntax for specific task that makes more easy/productive 
and clear way to do the same.


Less code and clear syntax, allows more productive less errors.
Plugins are planned, but not for changing the syntax. Plugins will be 
able to transform the ast into other ast, but neither semantics nor 
syntax are allowed to change.


Consider this alternative, doable with such plugins:
select(Class.foo, Class.bar).from(collection).where(equal(some_field, 
some value)).


Collection may be anything from an array to a gee collection to 
anything. The plugin in this case can generate the relevant code by 
doing the necessary magic, and it has all the information about the 
collection from the ast.


However, such plugins will not be there anytime soon, there's first a 
huge experimental branch to be merged (yet to be completed).


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

Re: [Vala] vala libgda LINQ

[Daniel Espinosa]

2013/12/4 Juarez Rudsatz juar...@gmail.com

 Luca, Daniel,

 LINQ is just some kind of syntax for some functional
 programming aspects. It's about to be a 1:1 mapping with
 filter-map, also fold and scan..


 You are mostly correct about LINQ to Objects.
 In this case the .net designers capitalized from the popularity of LINQ to
 SQL and used the same syntax and naming to add this support to .Net.
 I also agree that is not necessary to force the language syntax to get the
 desired results.

 But LINQ to Entities and LINQ to SQL are different beasts:

 Quoting [1] :

 LINQ-to-Objects is a set of extension methods on IEnumerableT that
 allow you to perform in-memory query operations on arbitrary sequences of
 objects. The methods accept simple delegates when necessary.

 LINQ-to-Entities is a LINQ provider that has a set of extension methods
 on IQueryableT. The methods build up an expression tree (which is why
 delegates are actually passed as Expressions), and the provider will
 build up a SQL query based on its parsing of that expression tree.


 The L2E implements a ORM that executes the following workflow:

 Language syntax - Expression Tree - Query caching - SQL text -
 database - serialization - collection objects in languge.

 For example, in this code:

 var db = new MyDatabaseContext();
 var query =
 from c in db.Contacts
 join o in db.Orders
 on c.ContactId == o.ContactId
 join p in db.Payments
 on p.Number == p.OrderNumber
 where p.DueDate  DateTime.Today()
  p.PaidValue  o.Amount
 select new
 {
 ContactName = c.Name,
 ContactPhone = c.Phone,
 OrderNumber = o.Number,
 o.Amount,
 o.DueDate,
 AmountPaid = p.PaidValue
 };

 foreach(var contact in query)
 {
 print(%30s %10s %8i %10f %10d %10f,
 contact.ContactName,
 contact.ContactPhone,
 contact.Amount,
 contact.DueDate,
 contact.AmountPaid
 );
 }

 What are the language features needed that I still haven't found in Vala:

 1) Expression Support, type instrospection support

 The whole query statement above is not evaluated locally.
 Instead it builds a Expression Tree (AST) and when invocated in foreach
 loop it builds a SQL Query and execute against a database, object
 repository, etc...

 I couldn't find in vala how to store the expression where *p.DueDate 
 DateTime.Today()  p.PaidValue  o.Amount* in a Expression tree for
 using it later for building a SQL query.


I would like to create a Selectable and Expression interface, using GDA as
back-end to implement them. With that in mind we can create programatically
an expression tree to be parsed on demand to get required objects. GdaData
allows you to run queries on-demand, you haven't any SQL command executed
when objects are created, but when data needs to be retrieved.

Then with a mechanism to parse expressions for any kind of data we can
create queries when required. GDA have a SqlParser for strings expressions
and SqlBuilder for programatically created ones, then just put this
infrastructure together to allows:

a) Data collections (Gee ones or Database ones) be queryable.
b) Create plug-ins for syntax support to easy and clean code declarations


 2) Type Aliasing

 The classes db.Contacts, db.Orders and db.Payments are aliased to c, o and
 p and used after to indicate what class you are refering.
 Classes could be refered twice like in Person as teacher and Person as
 student.

 Why this is important:
 Because it binds the language type safety to the data model you have.
 Database applications are just boring repetitions of user input forms,
 reports and data procedures. When you change a table/class the compiler
 will help you check when the name/type change will break your code.
 Database aplications usually have hundreds of tables/classes and thousand
 of queries and type safety cut the much of the maintanance burden.

 3) Anonymous objects

 Afte the query get back the results are materialized/serialized to a new
 anonymous type with local scope.
 In this example the select new statement creates a collection of anonymous
 objects. The var query gives to the variable this anonymous type.

 Why this is important:
 Because it saves the cuts a lot of code for declaring a new class that
 will be used once.

 I hope this could help understand what the benefits of a language
 integrated ORM for data intensive applications. Some things could add
 flexibility to language itself.

 Other features of LINQ to  Entities:

 a) Lazy loading

 public class Person
 {
 string name { get; set; }
 Address address { get; set; }
 }

 // get a record from Person table
 Person friend =
 from f in db.Persons
 where f.Name = Luca
 select f;

 // Get a record from address table
 print(friend.address.street);

 b) Inheritance

 public class Customer : Person { ... }



 [1]
 http://stackoverflow.com/questions/7192040/linq-to-entities-vs-linq-to-objects-are-they-the-same

Re: [Vala] vala libgda LINQ

[Daniel Espinosa]

2013/12/4 Luca Bruno lethalma...@gmail.com

 On 04/12/2013 16:52, Daniel Espinosa wrote:


 Vala has provide nice/sexy syntax for GObject/C programing. Have added
 lot of new features, witch have been possible to write in C but with lot of
 lines of code. I love Vala because allows me to be more productive, even
 Genie allows more simplification on Vala's syntax.

 I think that former syntax are more productive and easy to read than the
 last. Could allow to work with-in Vala's code with lot of data from a
 DataBase or any other data source. GdaData objects and interfaces allows to
 access that data using just GObjects and Vala code, abstracting most of
 internal operations and mapping to properties and methods, and allow to use
 Gee collections to make more easy to access to data using by code; but
 could reach a next level by adding some syntax support on Vala for SQL like
 queries.

 I know that adding syntax support may is not easy or is far from Vala
 principles.

 Then I would like to see a way to allows Vala compiler with a mechanism
 of PLUG-INS for syntax support. Then GdaData could add its own plug-in for
 SQL syntax when it is installed.

 The above allows not to distract Vala from its principles, but allows to
 others add syntax for specific task that makes more easy/productive and
 clear way to do the same.

 Less code and clear syntax, allows more productive less errors.

 Plugins are planned, but not for changing the syntax. Plugins will be able
 to transform the ast into other ast, but neither semantics nor syntax are
 allowed to change.

 Consider this alternative, doable with such plugins:
 select(Class.foo, Class.bar).from(collection).where(equal(some_field,
 some value)).


This could be possible using GDA and GdaData infrastructure. Just require
to create some classes and interfaces. Of course this don't need a Vala
plug-in just install GDA and enable GdaData :-)


 Collection may be anything from an array to a gee collection to anything.
 The plugin in this case can generate the relevant code by doing the
 necessary magic, and it has all the information about the collection from
 the ast.


GdaData already do this. You have mapped tables, records, fields to Gee
collections and implements some interfaces to allow any other to be a data
provider not just databases that actually use GDA as back-end.


 However, such plugins will not be there anytime soon, there's first a huge
 experimental branch to be merged (yet to be completed).


After that merge, are there any plan for plug-in support and include syntax
support too? Are we need to go the Genie way?

If Genie way is recommended, then we need to fix missings in GdaData to
allow basic programically query execution and then think about to create
Vala/Genie syntax.

-- 
Trabajar, la mejor arma para tu superación
de grano en grano, se hace la arena (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] vala libgda LINQ

[Daniel Espinosa]

2013/12/3 Juarez Rudsatz juar...@gmail.com

 I checked the samples and some parts of the code.
 Nice work. :-)

 Regarding language support, it seems to remain a good amount of work to be
 done yet.

Do you mean Vala features right?

 I'm counting the language features that will be necessary:
 - Object serialization

Are you mean write some where. For XML serialization we have Vala's GXml
project[1]. On GXml's serialization branch, you'll find my work on GObject
serialization to XML, comparable with .NET but, I think more flexible[2].

 - Anonymous types

- Expression and type introspection
 - Type aliasing...
 - Syntax changes


 At the end a Collection have objects with a set of properties, a SELECT
expression is a filter of that set of objects and a set of properties. They
could be stored in a DbRecord (as for libgda's GdaData [3] ) to save memory
and adding something like Methods_With_Syntax_Support [4] , Vala compiler
could transform:

 var selection = select name, salary from employees where id = 123;
 stdout.printf (@$(selection.name) / $(selection.salary));

to:
   var _tmp_ = new ArrayListEmployee ();
   _tmp_.add_all ( ((Traversable) employees).filter(
  (g)={ return id.equals (g) true : false; });
   var selection = ((Selectable) _tmp_).get_fields (name, salary);
   if (selection.size != 1)
  throw new SelectableError.MULTIPLE_VALUES_TO_SINGLE (...);
   var _tmp2_ = selection[0].get_field(name);
   var _tmp3_ = selection[0].get_field(salary);
   stdout.printf (@$(_tmp2_) / $(_tmp3_));

 What level of support you are planning?

Because I haven't used LINQ before, I don't know most of its features. Just
think about to allow:

a) Use a SQL like syntax to filter objects and properties, by adding
support to Vala compiler to generate corresponding Vala or C code
b) Object collection must implement at least Gee.Collection and its items
must be Gee.Comparable and Selectable
c) Add a Selectable interface to Gee to allow introspect objects properties
and create a Collection with desired DbRecord set of values.

I don't think mimic LINQ is correct. May we can do better, but is necessary
to define use cases.

The only one I have in mind is:

a) select {list-of-fields} from {collection-object} where {condition}

For this simple expression Vala's compiler should generate required code to:

a) Check for collection-object is a GObject implementing Gee.Collection and
its elements must be Gee.Comparable and Selectable
b) Check for list-of-fields are public properties in collection-object
c) Check for condition is using collection-object 's public properties
d) Generate a PredicateG delegate function to find object required objects
e) Fill a Gee.Collection with filtered objects
f) Generate a Gee.Collection from Selectable, that produce rows and
values/columns (with name=properties' name)

 It would be well received by upstream developers?

Really don't know. I'm CC to Vala and Gee lists to hear them about this
idea.

 I'm planning a new architecture for ouro next applications and considering
 vala. But the type safety and language support are the strengths of linq we
 really appreciate.

 I'm planning to help someway, but I have a long way yet to be produtive.

 Regards

 Juarez

[1] https://git.gnome.org/browse/gxml
[2] https://git.gnome.org/browse/gxml/log/?h=serialization
[3] https://git.gnome.org/browse/libgda/tree/libgda/data
[4]
https://wiki.gnome.org/Projects/Vala/Tutorial#Methods_With_Syntax_Support



  Em 03/12/2013 16:35, Daniel Espinosa eso...@gmail.com escreveu:

 You can see a preview of my work on current stable libgda.

 I've finished interfaces and implementations under GdaData name space.

 I've added some documentation just use --enable-vala-extensions --gtk-doc
 (some other switches are required) to see it installed.

 Missed Selectable interface or implementation.

 I would like to add syntax support on Vala compiler in order to have LINQ
 like one.

 For now is very easy to access to data using GdaData objects, see unit
 tests for more examples.
 El dic 3, 2013 10:03 a.m., Juarez Rudsatz juar...@gmail.com escribió:

 Hi,

 I found that you have been working in a possible implementation of LINQ
 in vala [1].
 I see that you have made good progress regarding this support.
 I want to know what is the current status.
 What's missing yet? How is the work for getting basic support ?

 Regards

 Juarez

 [1]
 https://mail.gnome.org/archives/vala-list/2011-December/msg00140.html




-- 
Trabajar, la mejor arma para tu superación
de grano en grano, se hace la arena (R) (en trámite, pero para los
cuates: LIBRE)
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Vala 0.22.0 - requiring instance of Class to access Class class-members.

[Luca Bruno]

I believe it's a bug in the compiler. It's non-sense to require an instance
when those are class-level instances.
However as a workaround you can use static fields. You can still initialize
them with class construct { } or static construct { }.
Also if you were thinking of overriding a protected class field, I hardly
believe that's implemented (there's a bug somewhere about that).


On Sun, Sep 29, 2013 at 5:58 PM, Thomas Olson tol...@stratagium.net wrote:



 Hello,

 This is the second time I've tried to post to the list, but I haven't seen
 my first attempt show up in the vala-list archive yet, so I thought I would
 resend, just in case.

 I'm still learning my way around vala so I may be doing something wrong,
 but according to the docs at 
 https://wiki.gnome.org/Vala/**Manual/Classeshttps://wiki.gnome.org/Vala/Manual/Classes
 :

  * Class members are shared between all instances of a class. They can
be accessed without an instance of the class, and class methods will
execute in the scope of the class.


 This does not appear to be the case.  In the following example I cannot
 access the prop method of the Parent or Child classes without instantiating
 an instance of those classes.

 public class Parent : Object {
 protected class int _prop;
 public class int prop() { return _prop; }
 class construct {
 _prop = 0;
 }
 }

 public class Child : Parent {
 class construct {
 _prop = 1;
 }
 }

 Parent p = new Parent();
 print (Parent.prop: %d\n, p.prop()); // Works as expected
 print (Parent.prop: %d\n, Parent.prop());// error: Access to
 instance member `Parent.prop' denied

 Child c = new Child();
 print (Child.prop: %d\n, c.prop());// Works as expected
 print (Child.prop: %d\n, Child.prop());// error: The name `prop'
 does not exist in the context of `Child'

 Is this the desired behavior or are class methods, suppose to only be
 accessible from class instances?

 Kind Regards,

 Tom


 __**_
 vala-list mailing list
 vala-list@gnome.org
 https://mail.gnome.org/**mailman/listinfo/vala-listhttps://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] Vala 0.22.0 - requiring instance of Class to access Class class-members.

[Tal Hadad]

 Hello,
 
 This is the second time I've tried to post to the list, but I haven't 
 seen my first attempt show up in the vala-list archive yet, so I thought 
 I would resend, just in case.
 
 I'm still learning my way around vala so I may be doing something wrong, 
 but according to the docs at https://wiki.gnome.org/Vala/Manual/Classes:
 
   * Class members are shared between all instances of a class. They can
 be accessed without an instance of the class, and class methods will
 execute in the scope of the class.

I'll mark some points:

Class members are sharing ACCESS between all instances of a class.
They
 can be accessed without an instance of the class(BUT HAVE TO 
SPECIFY ANOTHER INSTANCE TO GET TO), and class methods will execute 
in the scope of the class(WITH A GIVEN INSTANCE).

There's an only one exception to my marking - static members.
Static
 members belong to the class, not to the instance, and therefore its 
value is shared between all instances and the class.

More about static vs non-static members(in OOP):
http://www.daniweb.com/software-development/csharp/threads/96978/static-vs-non-static-methods

 
 This does not appear to be the case.  In the following example I cannot 
 access the prop method of the Parent or Child classes without 
 instantiating an instance of those classes.
 
 public class Parent : Object {
  protected class int _prop;
  public class int prop() { return _prop; }
  class construct {
  _prop = 0;
  }
 }
 
 public class Child : Parent {
  class construct {
  _prop = 1;
  }
 }
 
 Parent p = new Parent();
 print (Parent.prop: %d\n, p.prop()); // Works as expected
 print (Parent.prop: %d\n, Parent.prop());// error: Access to 
 instance member `Parent.prop' denied
 
 Child c = new Child();
 print (Child.prop: %d\n, c.prop());// Works as expected
 print (Child.prop: %d\n, Child.prop());// error: The name `prop' 
 does not exist in the context of `Child'
 
 Is this the desired behavior or are class methods, suppose to only be 
 accessible from class instances?
 
 Kind Regards,
 
 Tom
 

This is desirable behavior.
Notice that it works fine when calling method prop by instance.
When you call this method by a class name, it fails, since ONLY static method 
are allowed to be called by a class name.
Child.prop() would fail even if prop() is static, since the method belongs to 
Parent, and not to Child.

 I believe it's a bug in the compiler. It's non-sense to require an instance
 when those are class-level instances.

Sorry, but I don't understand you. Why it's a bug in compiler?

 However as a workaround you can use static fields. You can still initialize
 them with class construct { } or static construct { }.

So why don't just do this?

 Also if you were thinking of overriding a protected class field, I hardly
 believe that's implemented (there's a bug somewhere about that)

No I checked this in the past, Vala doesn't support this.
It could theoretically can be possible by register this with GObject class 
struct, but it's a source for ABI breaks.
Better to implicate this with a virtual static get method.

I do accept that this could be a nice feature.

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

Re: [Vala] Vala and Cairo 1.12

[Donn]

On 18/05/2013 16:57, Jonas Kulla wrote:

It's basically the same as declaring foreign functions in C.
Let's say you want to use the function 'int cairo_do_foo()' from Vala,
you would write something like:

namespace Cairo {
 [CCode (cname=cairo_do_foo)]
 extern int do_foo();
}

The 'CCode' part is a directive to valac for how it should
output the C code. We tell it the actual C function name
to use.


Noted. Thanks for the help.

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

Re: [Vala] Vala and Cairo 1.12

[Jonas Kulla]

2013/5/15 Donn donn.in...@gmail.com

  Are there a lot of new functions in 1.12 that you need? If not,
 you could just inline the function signatures in your vala code
 until someone updates the official vapi.

 It seems Evan Nemerson is on the case - yay! - but I'd like to know a
 little more about this inline thing. Do you have an example so I can get
 the picture? (I'm a Pythoner who tripped over Vala and I'm still rubbing my
 chin.)


It's basically the same as declaring foreign functions in C.
Let's say you want to use the function 'int cairo_do_foo()' from Vala,
you would write something like:

namespace Cairo {
[CCode (cname=cairo_do_foo)]
extern int do_foo();
}

The 'CCode' part is a directive to valac for how it should
output the C code. We tell it the actual C function name
to use.

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

Re: [Vala] Vala and Cairo 1.12

[Donn]

On 15/05/2013 02:23, Evan Nemerson wrote:

I just pushed a bunch of changes to the vala cairo bindings.  If
something is still missing, please file a bug.

Thanks Evan, however I'm not sure where these bindings can be found online.

Once fetched, would I simply drop them over my current file:
/usr/share/vala-0.18/vapi/cairo.vapi
?

Or, would I create cairo112.vapi alongside - but then how to use that in 
Vala?


Newbs! So many dumb questions! :D

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

Re: [Vala] Vala and Cairo 1.12

[Donn]

On 14/05/2013 19:59, Jonas Kulla wrote:

some vapis are auto-generated (mostly for glib based libraries I think),
but most are hand written and maintained AFAIK.
Okay, thanks. I didn't know this. I was wondering how the appropriate 
cairo_destroy stuff got into my code when I never call these functions 
from Vala.



Are there a lot of new functions in 1.12 that you need? If not,
you could just inline the function signatures in your vala code
until someone updates the official vapi.
It seems Evan Nemerson is on the case - yay! - but I'd like to know a 
little more about this inline thing. Do you have an example so I can get 
the picture? (I'm a Pythoner who tripped over Vala and I'm still rubbing 
my chin.)




You can take a look at the current vapi to get a feel for
how they're written. If you have specific questions,
feel free to ask them here.

I will do that, the cairo.vapi has me curious. Thanks.

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

Re: [Vala] Vala and Cairo 1.12

[Evan Nemerson]

On Wed, 2013-05-15 at 10:26 +0200, Donn wrote:
 On 15/05/2013 02:23, Evan Nemerson wrote:
  I just pushed a bunch of changes to the vala cairo bindings.  If
  something is still missing, please file a bug.
 Thanks Evan, however I'm not sure where these bindings can be found online.

In the valac git repository:

https://git.gnome.org/browse/vala/plain/vapi/cairo.vapi

 Once fetched, would I simply drop them over my current file:
 /usr/share/vala-0.18/vapi/cairo.vapi
 ?
 
 Or, would I create cairo112.vapi alongside - but then how to use that in 
 Vala?

Usually you would just copy it into your project (as cairo.vapi) and
pass a --vapidir option to valac so it knows where to look for it.
Overwriting files from packages is generally not advisable.


-Evan

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

Re: [Vala] Vala and Cairo 1.12

[Donn]

On 15/05/2013 15:05, Evan Nemerson wrote:

https://git.gnome.org/browse/vala/plain/vapi/cairo.vapi

Great, thanks.


pass a --vapidir option to valac so it knows where to look for it.

I'm also using gtk, and I see a deps file that specifies 'cairo' - this
is all in /usr/share/vala/vapi directory.
If I use the --vapidir option will it know to override the ref to
'cairo' in that deps file?

All of this I will likely encounter as soon as I get an afternoon to
code in. I want to try the cairo recording surface - so thanks a tonne
for making that vapi!!!

(Bows)
:D

\d


--
Cellery- 082 343 5978
Phoney - 028 272 9033
@ddy - donn.in...@gmail.com
webby - ingleink.co.za
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Vala and Cairo 1.12

[Jonas Kulla]

2013/5/14 Donn donn.in...@gmail.com

 Hi,
 Vapi files mystify me. Does anyone know where I can get a vapi (and
 anything else I'd need) such that I can use Cairo 1.12?

 Or, perhaps someone can help me generate it?

 BTW - The valadoc.org/cairo seems to be about version 1.0 of cairo - so
 it's also out of date.


Hi,

some vapis are auto-generated (mostly for glib based libraries I think),
but most are hand written and maintained AFAIK.

Are there a lot of new functions in 1.12 that you need? If not,
you could just inline the function signatures in your vala code
until someone updates the official vapi.

You can take a look at the current vapi to get a feel for
how they're written. If you have specific questions,
feel free to ask them here.

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

Re: [Vala] Vala and Cairo 1.12

[Evan Nemerson]

On Tue, 2013-05-14 at 14:32 +0200, Donn wrote:
 Hi,
 Vapi files mystify me. Does anyone know where I can get a vapi (and 
 anything else I'd need) such that I can use Cairo 1.12?

I just pushed a bunch of changes to the vala cairo bindings.  If
something is still missing, please file a bug.


-Evan


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

Re: [Vala] Vala in Python - More progress and a question

[Donn]

On 20/04/2013 21:14, Evan Nemerson wrote:

..  it's generally a good idea to use
GObject-style construction [1].  In your original example, simply
replace public RedSquare() with construct and it should work as
expected.


Appreciate that, thanks. I shall read up and hack it thus.


A question?
In this thread I have loaded Clutter (library and whatever else it 
loads) in Python.
 I have also included (I am not sure of the wording) Clutter into Vala 
(by way of the --pkg in valac) to some extent - where I made a 
Clutter.Actor object.


I run Python which loads my library: How many times has Clutter now 
loaded into memory? Once or twice?



Is there some general rule I can learn to understand (or test) this 
process? (Under Linux)


Thanks again,
\d
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Vala in Python - More progress and a question

[Evan Nemerson]

On Sun, 2013-04-21 at 09:21 +0200, Donn wrote:
 On 20/04/2013 21:14, Evan Nemerson wrote:
  ..  it's generally a good idea to use
  GObject-style construction [1].  In your original example, simply
  replace public RedSquare() with construct and it should work as
  expected.
 
 Appreciate that, thanks. I shall read up and hack it thus.
 
 
 A question?
 In this thread I have loaded Clutter (library and whatever else it 
 loads) in Python.
   I have also included (I am not sure of the wording) Clutter into Vala 
 (by way of the --pkg in valac) to some extent - where I made a 
 Clutter.Actor object.
 
 I run Python which loads my library: How many times has Clutter now 
 loaded into memory? Once or twice?

It depends a bit on how you define things, but the answer you're
probably looking for is either zero or one times.

When you load a shared library the memory actually used is shared not
just within the same process, but across all processes using that
library.  In all likelihood, some other process (like gnome-shell) is
already using Clutter and your program using Clutter doesn't require any
additional resources.


-Evan

[1]
http://virtualthreads.blogspot.com/2006/02/understanding-memory-usage-on-linux.html

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

Re: [Vala] Vala in Python - More progress and a question

[Donn]

On 21/04/2013 09:53, Evan Nemerson wrote:

When you load a shared library the memory actually used is shared not
just within the same process, but across all processes using that
library.  In all likelihood, some other process (like gnome-shell) is
already using Clutter and your program using Clutter doesn't require any
additional resources.


I'm glad to hear it!

Thanks for the links and your help.


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

Re: [Vala] Vala in Python - Some progress and a question

[Donn]

A follow-up.

Progress

In the python file (test.py) I got the idea to explicitly call the new() 
method of the RedSquare object. I saw it when I did a dir() in Python.


(I first got the idea when I saw how a Clutter.Color was instanced - 
with Clutter.Color.new() - in Python, this is deeply weird.)


New Python line 22
rs = Palelib.RedSquare.new()

Then restore the this.canvas.invalidate() call in the vala code under 
boo(), build it - and the red square appears!


Nice. Odd, but nice.


Question

Why are the various stdout.printf calls not working straight away? When 
the app is closed they all print - as if they were stored in some 
off-screen buffer someplace.




\d

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

Re: [Vala] Vala in Python - Some progress and a question

[Sam Wilson]

On 13-04-20 07:40 AM, Donn wrote:
 Question
 
 Why are the various stdout.printf calls not working straight away? When
 the app is closed they all print - as if they were stored in some
 off-screen buffer someplace.

I could be mistaken, but python uses line buffering, so if you put a
'\n' on the end of your printf's you might get the text to show up right
away.

Sam




smime.p7s
Description: S/MIME Cryptographic Signature
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Vala in Python - Some progress and a question

[Donn]

On 20/04/2013 16:27, Sam Wilson wrote:

I could be mistaken, but python uses line buffering, so if you put a
'\n' on the end of your printf's you might get the text to show up right
away.


You, Sir, are a genius. Hat tip.

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

Re: [Vala] Vala in Python - Some progress and a question

[Evan Nemerson]

On Sat, 2013-04-20 at 13:40 +0200, Donn wrote:
 A follow-up.
 
 Progress
 
 In the python file (test.py) I got the idea to explicitly call the new() 
 method of the RedSquare object. I saw it when I did a dir() in Python.
 
 (I first got the idea when I saw how a Clutter.Color was instanced - 
 with Clutter.Color.new() - in Python, this is deeply weird.)
 
 New Python line 22
 rs = Palelib.RedSquare.new()
 
 Then restore the this.canvas.invalidate() call in the vala code under 
 boo(), build it - and the red square appears!
 
 Nice. Odd, but nice.

Just so you know, what's probably happening is that PyGI was using
g_object_new instead of the constructor you created in Vala.  When
you're writing a library, especially one meant to be consumed from
languages other than Vala, it's generally a good idea to use
GObject-style construction [1].  In your original example, simply
replace public RedSquare() with construct and it should work as
expected.

[1] https://live.gnome.org/Vala/Tutorial#GObject-Style_Construction


-Evan

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

Re: [Vala] Vala to Android - Cairo

[Tal Hadad]

Very good results.
But why the Android device is needed to be rooted?

And is it possible to use OpenGLES in Vala there?

Tal

 From: tarn...@tarnyko.net
 To: vala-list@gnome.org
 Date: Mon, 1 Apr 2013 06:10:40 +0200
 Subject: Re: [Vala] Vala to Android - Cairo
 
 Hi people, 
 
 Last message from myself on this thread, just to let you know that I made a 
 tutorial for using Cairo on Android - from Vala : 
 
 http://www.tarnyko.net/en/?q=node/26 
 
 So we can now draw shapes, text, images... and all sort of nice things on 
 Android's screen from Vala code. 
 
 More interesting stuff in this style will come later, working on this. 
 
 Regards,
 Tarnyko
 ___
 vala-list mailing list
 vala-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/vala-list
  
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Vala to Android - Cairo

[tarnyko]

Hi Tal, thanks for your interest, 

Tal Hadad writes: 


Very good results.
But why the Android device is needed to be rooted? 

Well, during my tutorial, I speed up things by directly copying the native 
binary deep in the phone's internal filesystem ; I think you are not allowed 
to do that with an unrooted phone. 

A solution -not requiring root- would be to regenerate and reinstall the 
whole APK each time you recompile stuff. But the tutorial would have been a 
hell longer (explanations on SDK, APK, a.s.o.) so I decided to concentrate 
on core Vala things.


And is it possible to use OpenGLES in Vala there? 



Potentially, yes. By using the SDL Android port, which has support for ES 
1.1 and 2.0 (see http://bugzilla.libsdl.org/show_bug.cgi?id=1291). 

Vala has already a SDL VAPI, we just need to recompile libs and write some 
glue code, like I did here for Cairo. I'm just too busy to do this right 
now. 

Tal 


From: tarn...@tarnyko.net
To: vala-list@gnome.org
Date: Mon, 1 Apr 2013 06:10:40 +0200
Subject: Re: [Vala] Vala to Android - Cairo 

Hi people,  

Last message from myself on this thread, just to let you know that I made a 
tutorial for using Cairo on Android - from Vala :  

http://www.tarnyko.net/en/?q=node/26  

So we can now draw shapes, text, images... and all sort of nice things on 
Android's screen from Vala code.  

More interesting stuff in this style will come later, working on this.  


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

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

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

Re: [Vala] Vala to Android - Cairo

[tarnyko]

Hi people, 

Last message from myself on this thread, just to let you know that I made a 
tutorial for using Cairo on Android - from Vala : 

http://www.tarnyko.net/en/?q=node/26 

So we can now draw shapes, text, images... and all sort of nice things on 
Android's screen from Vala code. 

More interesting stuff in this style will come later, working on this. 


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

Re: [Vala] Vala to Android - Cairo

[tarnyko]

OK, I'm posting it mostly for the record, please note it is a long mail. 
Feel free to ask questions. Here we go. 

I found some pre-compiled versions of Cairo for Android on the Internet ; 
none of them was complete (with dependencies) nor usable with agcc/valac. 

So, after struggling a bit... 


Cairo 1.10.2 for Android :
http://www.tarnyko.net/repo/cairo-1.10.2-android-(TARNYKO).tar.bz2 


Here is a stand-alone Vala sample :
http://www.tarnyko.net/repo/cairo.vala
to be compiled with :
valac --cc=agcc --pkg cairo -o cairo cairo.vala --Xcc=-lpixman-1 
--Xcc=-lpng15 

It blits a image.png file with some overlay text. Should run fine on an 
Android phone. 


Next step is to display this stuff to Android's screen, and here we have
a problem ; by design, the OS doesn't allow native code to draw to screen.
Any data should be passed between a native library (*.so) and a running Java 
app. So I will use AndroidBitmapInfo from JNI as a vector. 


I've prepared a demo project :
http://www.tarnyko.net/repo/cairo-android-vala.tar.bz2
contains :
android.vapi : Android VAPI (dummy)
cairo-android.vala : Vala source
cairo-android.glue.c : C Android Glue 


should be compiled with :
valac --cc=agcc -X -shared --pkg cairo --pkg android --vapidir . 
cairo-android.vala cairo-android.glue.c -o libcairo-android.so 
--Xcc=-lpixman-1 --Xcc=-lpng15 --Xcc=-ljnigraphics 

and drops a libcairo-android.so file which you can call from Java : 


static { System.loadLibrary(cairo-android); }
drawPNG(bmp); 


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

Re: [Vala] Vala to Android

[Tal Hadad]

Very good!
someone had to break his mind until this would success, and you and many others 
volunteered...

The main problem was GObject and GLib, I think it would interest people in 
other GNOME mailing list.

I recently also tried myself to find ways to use Vala in Android, and you prove 
it works!

This also should be a great start for GTK in android, QT is ahead in this race.

Tal

 From: tarn...@tarnyko.net
 To: vala-list@gnome.org
 Date: Wed, 20 Mar 2013 00:05:47 +0100
 Subject: Re: [Vala] Vala to Android
 
 Nice, thank you very much ! 
 
 Regards,
 Tarnyko 
 
 Luca Bruno writes:
  
  Thanks for your contribution. I've reported it here fyi:
  http://valajournal.blogspot.it/2013/03/vala-on-android.html 
  
  Best regards, 
  
  -- 
  www.debian.org - The Universal Operating System
 ___
 vala-list mailing list
 vala-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/vala-list
  
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Vala to Android

[Nicholas Melnick]

That is super cool, Tarnyko.

 - Nick


- Original Message -
From: tarn...@tarnyko.net
To: vala-list@gnome.org
Sent: Tuesday, March 19, 2013 3:46:40 AM
Subject: [Vala] Vala to Android

Hi folks, 

No it's not a question :-). 

It's very rare for me to message the list when not for a question/answer, 
but I managed to compile a Vala source directly to Android binary
yesterday. And I think it might be of some interest to some people here. 

For the record, I've written a tutorial here :
http://www.tarnyko.net/en/?q=node/25 

It's still very limited (only access to core Vala + GLib/Gobject
methods) but it could easily be extended by porting libraries having Vala 
bindings ; although I know it's not easy stuff. 

For the graphical part, GTK+ doesn't work yet but I know Cairo has been
ported (http://code.google.com/p/cairo4android/) -and Cairo definitely has 
Vala bindings. 

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

Re: [Vala] Vala to Android

[tarnyko]

Thanks Nicholas ! I'm sending a mail (answering Tal) for further discussion 
^^. 


Regards,
Tarnyko 

Nicholas Melnick writes: 

That is super cool, Tarnyko. 

 - Nick 



- Original Message -
From: tarn...@tarnyko.net
To: vala-list@gnome.org
Sent: Tuesday, March 19, 2013 3:46:40 AM
Subject: [Vala] Vala to Android 

Hi folks,  

No it's not a question :-).  

It's very rare for me to message the list when not for a question/answer, 
but I managed to compile a Vala source directly to Android binary
yesterday. And I think it might be of some interest to some people here.  


For the record, I've written a tutorial here :
http://www.tarnyko.net/en/?q=node/25  


It's still very limited (only access to core Vala + GLib/Gobject
methods) but it could easily be extended by porting libraries having Vala 
bindings ; although I know it's not easy stuff.  


For the graphical part, GTK+ doesn't work yet but I know Cairo has been
ported (http://code.google.com/p/cairo4android/) -and Cairo definitely has 
Vala bindings.  


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

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

Re: [Vala] Vala to Android

[tarnyko]

Thanks Tal, 


To be totally honest, I heavily relied on this clever guy's mail :
https://mail.gnome.org/archives/gtk-devel-list/2011-March/msg00096.html 

However, his work was not fully explained, some errors here, some patches  
switches missing there... so I worked hard until I got these d*mn binaries 
:-). And then, you had the Vala part of course, but I begin to be 
experienced there (see former posts about cross-compilation on my blog). 

Now, to go further on this subject : 

- Android's windowing system is called SurfaceFlinger. It's far different 
from X11/Wayland, and exposes fast no pure C apis ; however you can draw on 
it using JNI. 

Porting GTK+ to it would be a HUGE work, involving many and more experienced 
hackers than I am ;-), so we better find a sponsor for that. QT has already 
done that (google for Necessitas). GTK+ is mostly pushed by RedHat, who 
has shown no interest in mobile devices yet ; Canonical is pushing in this 
direction though, but don't they already have a home-made API for their 
Ubuntu Tablet stuff ? (need some facts here). 

- If we cannot find a sponsor, we can still write a Vala wrapper for simpler 
libraries like this one (S4L) :
http://credentiality2.blogspot.gr/2010/08/giving-native-android-c-apps-acces 
s-to.html 

So it would end to be an Android-specific Vala binding ; but it's not so 
bad, you'd need to rewrite your GUI even on QT either, as the screen is lot 
smaller and due to mobile-specific ergonomics. 

I'm playing with Cairo right now. It's not so hard, good for pure bitmap 
operations ; not bad for a start :-) ! 

PS Tal : the mail about GLib was already posted on gtk-list years ago, so I 
better not forward this until I have new stuff. 


Regards,
Tarnyko 

Tal Hadad writes: 


Very good!
someone had to break his mind until this would success, and you and many others volunteered... 

The main problem was GObject and GLib, I think it would interest people in other GNOME mailing list. 

I recently also tried myself to find ways to use Vala in Android, and you prove it works! 

This also should be a great start for GTK in android, QT is ahead in this race. 

Tal 


From: tarn...@tarnyko.net
To: vala-list@gnome.org
Date: Wed, 20 Mar 2013 00:05:47 +0100
Subject: Re: [Vala] Vala to Android 

Nice, thank you very much !  


Regards,
Tarnyko  


Luca Bruno writes:
 
 Thanks for your contribution. I've reported it here fyi:
 http://valajournal.blogspot.it/2013/03/vala-on-android.html 
 
 Best regards, 
 
 -- 
 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

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

Re: [Vala] Vala to Android

[Luca Bruno]

On Tue, Mar 19, 2013 at 9:46 AM, tarn...@tarnyko.net wrote:

 Hi folks,
 No it's not a question :-).
 It's very rare for me to message the list when not for a question/answer,
 but I managed to compile a Vala source directly to Android binary
 yesterday. And I think it might be of some interest to some people here.
 For the record, I've written a tutorial here :
 http://www.tarnyko.net/en/?q=**node/25http://www.tarnyko.net/en/?q=node/25
 It's still very limited (only access to core Vala + GLib/Gobject
 methods) but it could easily be extended by porting libraries having Vala
 bindings ; although I know it's not easy stuff.
 For the graphical part, GTK+ doesn't work yet but I know Cairo has been
 ported 
 (http://code.google.com/p/**cairo4android/http://code.google.com/p/cairo4android/)
 -and Cairo definitely has Vala bindings.


Thanks for your contribution. I've reported it here fyi:
http://valajournal.blogspot.it/2013/03/vala-on-android.html

Best regards,

-- 
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] Vala to Android

[tarnyko]

Nice, thank you very much ! 


Regards,
Tarnyko 


Luca Bruno writes:


Thanks for your contribution. I've reported it here fyi:
http://valajournal.blogspot.it/2013/03/vala-on-android.html 

Best regards, 


--
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] Vala dynamic array with double []

[Tal Hadad]

This is kinda tricky.
First, take a look in Wikipedia:

http://en.wikipedia.org/wiki/Dynamic_array

The bad way, is to use resize method every time:

double[] a = new double[0];
for (int i=0;ilength;i++) {
  a.resize(i);
  a[i]=num;
}

(Never code like this, I just showed you what happens)
Every time you use the resize method, the array is reallocated or increasing 
space(if there any).

Lucky, there are such GArray in GLib:
http://developer.gnome.org/glib/2.31/glib-Arrays.html#GArray

Good luck!
Tal

 From: 2cyouag...@gmail.com
 To: vala-list@gnome.org
 Date: Sun, 27 Jan 2013 20:56:49 +0700
 Subject: [Vala] Vala dynamic array with double []
 
 What alternative to define array like this:
 in PHP or C# we can do
 $arrOptions = array();
 $arrOptions[][] = 1;
 
 any suggestion or what library that have class or other?
 thanks
 
 ___
 vala-list mailing list
 vala-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/vala-list
  ___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Vala protocol buffer support

[Steven Oliver]

Awesome!

Steven N. Oliver


On Thu, Jan 10, 2013 at 12:11 AM, Robert Ancell robert.anc...@gmail.comwrote:

 Hi,

 I've made a plugin for the protocol buffer compiler to support Vala:
 http://launchpad.net/protobuf-vala

 You can read more about it in my blog:

 http://bobthegnome.blogspot.co.nz/2013/01/vala-support-for-protocol-buffers.html

 --Robert

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


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

Re: [Vala] vala-list Digest, Vol 61, Issue 7

[JM]

Interesting. But this feature seems undocumented, I cannot find it in
the tutorial.


Am Sonntag, den 16.12.2012, 20:20 +0100 schrieb Jonas Kulla:
 2012/12/16 JM interfl...@gmx.net
 
  Overriding a signal or making it virtual does not really make sense,
  does it?
  A signal does not have a body, as a function would have and signature is
  always the same, even in child classes.
 
 
  Also your example seems weird, as you have bodys for signals.
 
  Regards
 
 
 No, signals in Vala can be virtual and can have bodies.
 GObject offers so called default handles for signals,
 which can be specified as an offset in the class struct to the handler
 function pointer. Because the handler is in the class struct,
 it can be overriden by subclasses, hence the analogy virtual signal.
 Vala translates the signal body to a virtual function and sets it as the
 default handler for the signal.
 
  - Jonas
 ___
 vala-list mailing list
 vala-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/vala-list


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

Re: [Vala] vala-list Digest, Vol 61, Issue 7

[Nadir Sampaoli]

Have you tried including signal modifier in overridden method too? This way:

public class A : GLib.Object {
  public virtual signal void func () {}
}


public class B : A {
  public override signal void func () {}
}


2012/12/16 vala-list-requ...@gnome.org

 Send vala-list mailing list submissions to
 vala-list@gnome.org

 To subscribe or unsubscribe via the World Wide Web, visit
 https://mail.gnome.org/mailman/listinfo/vala-list
 or, via email, send a message with subject or body 'help' to
 vala-list-requ...@gnome.org

 You can reach the person managing the list at
 vala-list-ow...@gnome.org

 When replying, please edit your Subject line so it is more specific
 than Re: Contents of vala-list digest...


 Today's Topics:

1. Defining new virtual signal is possible,  but overring it
   isn't. (Tal Hadad)


 --

 Message: 1
 Date: Sat, 15 Dec 2012 21:00:24 +0200
 From: Tal Hadad tal...@hotmail.com
 To: Vala Mail List vala-list@gnome.org
 Subject: [Vala] Defining new virtual signal is possible,but
 overring
 it isn't.
 Message-ID: dub118-w23290d650216ac80e0291be5...@phx.gbl
 Content-Type: text/plain; charset=windows-1255


 When I try to:
 public class A : GLib.Object {
   public virtual signal void func () {}
 }


 public class B : A {

   public override void func () {}

 }

 I get an error from Valac:
 error: B.func: no suitable method found to override

 I'm using Vala 0.16.1

 I think that this is a critical bug in Vala, or my code is wrong?

 Thanks,
 Tal


 --

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


 End of vala-list Digest, Vol 61, Issue 7
 

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

Re: [Vala] vala-list Digest, Vol 61, Issue 7

[JM]

Overriding a signal or making it virtual does not really make sense,
does it?
A signal does not have a body, as a function would have and signature is
always the same, even in child classes.


Also your example seems weird, as you have bodys for signals.

Regards


Am Sonntag, den 16.12.2012, 17:41 +0100 schrieb Nadir Sampaoli:
 Have you tried including signal modifier in overridden method too? This way:
 
 public class A : GLib.Object {
   public virtual signal void func () {}
 }
 
 
 public class B : A {
   public override signal void func () {}
 }
 
 
 2012/12/16 vala-list-requ...@gnome.org
 
  Send vala-list mailing list submissions to
  vala-list@gnome.org
 
  To subscribe or unsubscribe via the World Wide Web, visit
  https://mail.gnome.org/mailman/listinfo/vala-list
  or, via email, send a message with subject or body 'help' to
  vala-list-requ...@gnome.org
 
  You can reach the person managing the list at
  vala-list-ow...@gnome.org
 
  When replying, please edit your Subject line so it is more specific
  than Re: Contents of vala-list digest...
 
 
  Today's Topics:
 
 1. Defining new virtual signal is possible,  but overring it
isn't. (Tal Hadad)
 
 
  --
 
  Message: 1
  Date: Sat, 15 Dec 2012 21:00:24 +0200
  From: Tal Hadad tal...@hotmail.com
  To: Vala Mail List vala-list@gnome.org
  Subject: [Vala] Defining new virtual signal is possible,but
  overring
  it isn't.
  Message-ID: dub118-w23290d650216ac80e0291be5...@phx.gbl
  Content-Type: text/plain; charset=windows-1255
 
 
  When I try to:
  public class A : GLib.Object {
public virtual signal void func () {}
  }
 
 
  public class B : A {
 
public override void func () {}
 
  }
 
  I get an error from Valac:
  error: B.func: no suitable method found to override
 
  I'm using Vala 0.16.1
 
  I think that this is a critical bug in Vala, or my code is wrong?
 
  Thanks,
  Tal
 
 
  --
 
  ___
  vala-list mailing list
  vala-list@gnome.org
  https://mail.gnome.org/mailman/listinfo/vala-list
 
 
  End of vala-list Digest, Vol 61, Issue 7
  
 
 ___
 vala-list mailing list
 vala-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/vala-list


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

Re: [Vala] vala-list Digest, Vol 61, Issue 7

[Jonas Kulla]

2012/12/16 JM interfl...@gmx.net

 Overriding a signal or making it virtual does not really make sense,
 does it?
 A signal does not have a body, as a function would have and signature is
 always the same, even in child classes.


 Also your example seems weird, as you have bodys for signals.

 Regards


No, signals in Vala can be virtual and can have bodies.
GObject offers so called default handles for signals,
which can be specified as an offset in the class struct to the handler
function pointer. Because the handler is in the class struct,
it can be overriden by subclasses, hence the analogy virtual signal.
Vala translates the signal body to a virtual function and sets it as the
default handler for the signal.

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