Re: [Vala] Compiling a shared library with entry point

[Al Thomas via vala-list]

 > On Monday, 11 May 2020, 06:02:32 BST, Rasmus René Bronné Lindegaard via 
 > vala-list  wrote: 
> I'm currently working on a project where it would be extremely useful if I 
> could execute the shared library I'm compiling.
> I know it can be done with C, so it should be doable with Vala.

I can compile the following:

void main () {
print ("Running...\n");
}

with:

valac --library test -X -pie -X -fPIE demo.vala

and it works for me.

The output from `readelf --file-header demo` is:

ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class: ELF64
  Data:  2's complement, little endian
  Version:   1 (current)
  OS/ABI:    UNIX - System V
  ABI Version:   0
  Type:  DYN (Shared object file)
  Machine:   Advanced Micro Devices X86-64
  Version:   0x1
  Entry point address:   0x6d0
  Start of program headers:  64 (bytes into file)
  Start of section headers:  6712 (bytes into file)
  Flags: 0x0
  Size of this header:   64 (bytes)
  Size of program headers:   56 (bytes)
  Number of program headers: 9
  Size of section headers:   64 (bytes)
  Number of section headers: 31
  Section header string table index: 28

Regards,

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

Re: [Vala] 回复： 回复： About VAPI's instance position

[Al Thomas via vala-list]

> On Sunday, 23 February 2020, 10:32:48 GMT, 放下 via vala-list 
>  wrote: 

> 1. crashed at RSA_public_encrypt() on msys2 on windows 7
> #8 0x67e4fb2f in libcrypto-1_1-x64!BN_clear_free ()
> #9 0x67e474ce in libcrypto-1_1-x64!BN_CTX_free ()
> #10 0x67f618d8 in libcrypto-1_1-x64!RSA_padding_add_PKCS1_OAEP ()

> 2. crashed at RSA_private_decrypt() on archlinux:
> unmap_chunk(): invalid pointer
> #5 0x76d1495d in BN_clear_free () at /usr/lib/libcrypto.so.1.1
> #6 0x76d0d02f in BN_CTX_free () at /usr/lib/libcrypto.so.1.1

Calls to BN_CTX_free and BN_clear_free suggest some problem in the memory 
management when using BIGNUM: 
https://github.com/openssl/openssl/blob/master/include/openssl/bn.h

That could be difficult to track down. You need to understand how memory in the 
buffers you are passing is being used and the difference between stack 
allocated and heap allocated memory.

One thing you can try is adding the `--debug` switch when calling `valac`. This 
should help show the Vala source code line numbers in the backtraces.

Regards,

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

Re: [Vala] About VAPI's instance position

[Al Thomas via vala-list]

> On Saturday, 22 February 2020, 07:58:10 GMT, 放下 via vala-list 
>  wrote: 
> if set the instance_pos as 2.1, the code can compile and will crashed at 
> function public_encrypt / private_decrypt,

2.1 sounds about right. That may not be the cause of the crash.

The documentation is helpful: 
https://www.openssl.org/docs/man1.1.1/man3/RSA_public_encrypt.html

`flen` should be the size of `from`. So you should use `array_length_pos` with 
`from` instead of `array_length = false`.

For improved code readability you can make `padding` a Vala enum called 
`Padding` that binds `RSA_PKCS1_PADDING`, etc.

A useful tip is to look at the C code generated from the Vala. Use `--ccode` or 
`--save-temps` with valac to get the intermediate C files. If you still have 
troubles please post the intermediate C code generated from Vala.

Best wishes,

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

Re: [Vala] link to Genie Doc

[Al Thomas via vala-list]

   > On Monday, 3 February 2020, 17:23:22 GMT, webierta--- via vala-list 
 wrote:  
 > Hello, I want to communicate that the Genie Doc wiki on programming with
> Genie (in Spanish) has changed servers and is now available at> 
> https://geniedoc.blogspot.com

Thanks for keeping that tutorial on the Internet! I've updated the link.
Regards,
Al
  
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Help with manual binding vapi for old C lib that uses only ASCII.

[Al Thomas via vala-list]

   > On Saturday, 11 January 2020, 01:59:00 GMT, Jason Martin via vala-list 
 wrote:  
> Does [CCode (type = "char*")] limit string to ascii only?

char declares the type so the compiler knows the size of the memory. On POSIX 
(Unix) and most other platforms that is 8 bits. The * indicates the parameter 
is a pointer to that data type. The rest is convention. So typically char* 
points to an array of char that is used to hold a string. The convention in C 
is for this array to be terminated by zero. The character encoding is not 
specified to the compiler, it is a matter to be agreed upon by the programs 
using the char array. It could be ASCII, but there are plenty of other 
character encodings that can fit in a char (typically 8 bits) and this include 
multi-byte encodings like Unicode's UTF-8. So, no, [CCode (type = "char*")] 
doesn't limit the string to ASCII.

> If not should I just use char*?Good question. You should probably just use 
> 'string' to start with. I guess the [CCode (type = "char*")] is to stop a 
> compiler warning about gchar*, but I've not investigate that with any code.
Hope that helps,
Al
  
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] General Information about this list & Vala

[Al Thomas via vala-list]

  > On Monday, 16 December 2019, 18:01:57 GMT, giacomo alberini via vala-list 
 wrote:  
 > 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?

These are good questions and don't seem to be covered in 
https://wiki.gnome.org/Projects/Vala/DeveloperDocumentation at
 the moment. 

This list is a good place to ask questions on what the Vala compiler and tools 
"should" do in general. A separate devel mailing list was used in the past, but 
I think this one is fine now. You can also ask questions on IRC (some use the 
Matrix.org IRC bridge).
Once it is understood what "should" happen then the best place to communicate 
is https://gitlab.gnome.org/GNOME/vala/issues Raise an issue with an example 
and either work on a patch or hope someone will also want to fix the same 
problem and work on it. The idea of what "should" happen may also change at 
this point because a more technical discussion or patches can lead to a better 
understanding of a problem and change the agreed view of the solution.

In the last few days there has been a fair amount of activity in the Vala 
GitLab instance. An example of fixing a problem 
is:https://gitlab.gnome.org/GNOME/vala/merge_requests/98https://gitlab.gnome.org/GNOME/vala/issues/534This
 was one issue to do with the null coalescing operator, but is a good example 
of collaborative development. Notice there are several different patches 
attempting to resolve this from different people over a few years. The point is 
don't be put off making a contribution if you don't have "the" solution. Give 
it your best effort and the work you have done may inspire others at a later 
time to finish it off.
Contributions can also be in the form of documentation. As someone new to the 
code base there will be many questions and that helps review the documentation. 
For example, https://wiki.gnome.org/Projects/Vala/Hacking is supposed to give 
an overview of how the Vala compiler works, but needs a lot of work. If someone 
is asking questions then it helps guide the development of the documentation to 
make it more relevant.

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

If GUI (GTK) is your area of interest then a starting issue could be 
instantiation of third party GTK widgets. For example when using a GtkBuilder 
file with a GtkSourceView widget then the Vala code requires 
typeof(Gtk.SourceView).ensure () to register the type, but using GtkTextView 
doesn't. An example in a project: 
https://gitlab.gnome.org/GNOME/gnome-games/blob/461d4dd5be74abd7570c42ccbb852809c0bc6f11/src/main.valaI've
 got some notes on the problem, but haven't produced a simple test case or 
looked at the C code generated by Vala.
Best wishes,
Al




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

Re: [Vala] valaDevelop

[Al Thomas via vala-list]

   > On Friday, 10 May 2019, 12:28:26 BST, Wolfgang Mauer 
 wrote: > due to low interest/feedback I will give 
up the development of 
> valaDevelop and dedicate myself to mono/C# again...

For anyone thinking of developing a project this has been a valuablecase study 
in the advantages of free/open source licensing.
valaDevelop has gathered ten stars, four watchers and one fork on GitHubin the 
eleven weeks since it was announced - 
https://mail.gnome.org/archives/vala-list/2019-February/msg00032.htmlbut now 
the developer has decided to move on there is a binary blob leftthat will 
slowly go stale.
Most Vala projects appear to be free software/open source so I think most 
peopleon this list understand the advantages and that includes forking dead 
projects.

Best wishes Wolfgang with your future projects.

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

Re: [Vala] Interpreting exit status

[Al Thomas via vala-list]

 
> On Sunday, 5 May 2019, 15:36:38 BST, rastersoft  
wrote: > I have a little problem: I'm launching a process using 
> GLib.Process.spawn_async, and use g_child_add_watch() to receive the 
> exit status valueBut waitpid documentation is not 
> very clear... Can I assume that the value set by the "exit()" call in 
> the spawned program is always stored in the upper 8 bits?

I can give some insight based on my own experience, which boils down to: - use 
GLib SubProcess - use the Open Group documentation for anything that is unclear 
with POSIX (Unix)
https://valadoc.org/gio-2.0/GLib.Subprocess.get_exit_status.html states 'This 
is equivalent to the system WEXITSTATUS macro' and 
http://pubs.opengroup.org/onlinepubs/9699919799/functions/wait.htmlstates 
'WEXITSTATUS(stat_val) If the value of WIFEXITED(stat_val) is non-zero, this 
macro evaluates to the low-order 8 bits of the status argumentthat the 
childprocess passed to _exit() or exit(), or the value the child process 
returned from main()'
I hope that helps.

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

Re: [Vala] ThreadPool

[Al Thomas via vala-list]

 
> On Sunday, 14 April 2019, 14:44:46 BST, Wolfgang Mauer 
 wrote: > is it possible to remove all 
"unprocessed" Threads in a ThreadPool?
> Practically I would like to remove all "pending/unprocessed" thread in 
> the pool before I add a new one.

You could use the ThreadPool's move_to_front () to prioritise the new task.I 
understand ThreadPool to be a parallelised version of foreach. A functionis 
passed in when the ThreadPool is created and data is then fed in with push ().

If the processing is complete and you want to remove the remaining data to 
starta new run then use free () and create a new ThreadPool. That's the only 
way Ican think of.
Some references if it 
helps:http://changelog.ca/log/2012/10/09/vala_glib_thread_poolhttps://stackoverflow.com/questions/29883007/gthreadpool-is-not-creating-more-than-n-threadshttps://developer.gnome.org/glib/stable/glib-Thread-Pools.html
Al
  
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Confusing closure behavior

[Al Thomas via vala-list]

 
> On Tuesday, 9 April 2019, 07:25:43 GMT+1, Vivien Kraus 
 wrote:  
> Digging a little deeper, I have some more confusion.  This makes the
> for-loop and the foreach-loop behave differently.  What do you think of:

The scope for i is main () and the for loop will finish when i is 1, The bodyof 
the loop won't be run when i is 1 though.
The foreach loop iterates over the array, but the end check is hidden in 
theunderlying code generated by Vala, The count isn't available to the Vala 
code.
I can't think of a way of fixing an enclosed variable at the point the closure 
isdeclared, rather than run.
Al
  
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Confusing closure behavior

[Al Thomas via vala-list]

   > On Monday, 8 April 2019, 23:01:05 BST, Vivien Kraus 
 wrote:  
> I have come across this weird closure thing.  In other programming
> languages, I would expect the closure in t to have a copy of i, but it
> only has a reference.  Is it expected?

That's an interesting question!

If you want a copy then pass it as an argument. If you want to usea variable 
from the enclosing scope then use a closure, but bewareif it changes in the 
enclosing scope it will change in the closure.

That was my initial thought. Kind of made sense until I read you expected other 
programming languages to make a copy.
If you look at the C code generated, use --ccode with valac, youwill see a 
struct, _data, is created to hold the enclosed variables.It makes sense then 
that i, although a value type, is a reference.
Now there are some rough edges with how Vala handles value typesin 
generics:https://gitlab.gnome.org/GNOME/vala/issues/564https://gitlab.gnome.org/GNOME/vala/merge_requests/52
If you think there is also a problem with closures then head overto 
https://gitlab.gnome.org/GNOME/vala/issues and make your case.

Al


> public delegate void Thunk();

> public static void run (Thunk t) {
>     t ();
> }

> int main() {
>     int i = 0;
>     Thunk t = () => {
>         stdout.printf ("%d = 0, right?\n", i);
>     };
>     i = 1;
>     run (t);
>     return 0;
> }

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

Re: [Vala] multithreading -> weird behaviour on win(msys)[SOLVED] and macOS

[Al Thomas via vala-list]

   > On Thursday, 14 March 2019, 22:13:25 GMT, Wolfgang Mauer 
 wrote: > I am now very cautious and claim that 
part of my problem is partly due 
> to valac (imho a valac bug)

> ALL the path coming from File.get_path(), on windows should be 
> C:\bla\bla but the valac don't like it (proof glib-compile-resources 
> works with C:\bla\bla)

> So the commandline to valac MUST look like this and then it works...
> valac -g 
> --output=C:/msys64/home/Wolfgang/Projekte/vDevelop/valaDevelop/bin/valaDevelop
>  
&-> snip <-&
> C:/msys64/home/Wolfgang/Projekte/vDevelop/valaDevelop/OptionDialogs/package_options_dialog.vala
>  
valac makes use of GLib, which provides cross-platform support for things like 
accessing files.Remember that you are operating in an MSYS2 shell. From what 
I've read MSYS2 brings aPOSIX environment to Windows and hence the forward 
slash separators.
valac shouldn't be making assumptions about the file path separators. That is 
the job of GLib.Now if you are experiencing similar problems when compiling 
with a Windows native compilerlike MSVC then there may be a bug. May be valac 
isn't using GLib as it should. May be GLibhas a bug. First, though, you need a 
better understanding of the environment you're compiling in.The could be a 
start: http://www.mingw.org/wiki/posix_path_conversion


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

Re: [Vala] multithreading -> weird behaviour on win(msys) and macOS

[Al Thomas via vala-list]

  > On Thursday, 14 March 2019, 05:59:16 GMT, Wolfgang Mauer 
 wrote: > So please give me a hand.. Is this a 
vala or GLib problem?
> >As far as the bug goes it 
>is:https://gitlab.gnome.org/GNOME/vala/issues/664 > 
>https://gitlab.gnome.org/GNOME/glib/issues/1512

Looking over the report again I think the callback from g_child_watch_add () 
wasn'tbeing called so the process exited by the output kept being piped in. 
That's why itwas null.
Given the GLib API is a higher level API to abstract away platform 
implementationsthen the first place to look is GLib. I have made a quick note 
onhttps://gitlab.gnome.org/GNOME/glib/issues/1512that this is occurring on both 
Windows and macOS.
One thing you could try is to find an alternative way of tidying up after the 
output hasfinished. The GLib documentation for g_spawn_async_with_pipes () ( 
https://developer.gnome.org/glib/stable/glib-Spawning-Processes.html#g-spawn-async-with-pipes
 )is detailed, with notes on cross platform support.
So the answer to your question is neither. The problem needs further 
investigation beforethe direct cause can be identified and fixed.


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

Re: [Vala] multithreading -> weird behaviour on win(msys) and macOS

[Al Thomas via vala-list]

   > On Wednesday, 13 March 2019, 00:10:30 GMT, Wolfgang Mauer 
 wrote:  > Tried this, run perfect on linux, runs 
"better" on win

Are you being sarcastic here? I've read through the rest of your mail and you 
aregetting a cc exited error. You're not running the program, the program fails 
to compile:
> C:msys64homeWolfgangProjekte
>     Develop
> alaDevelopml_configuration.vala:40:10: error: \x used with no following 
> hex digits
> : warning: missing terminating " character
> : warning: missing terminating " character
> error: cc exited with status 1

This probably has something to do with the Windows file path separatorbeing a 
backslash.

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

Re: [Vala] multithreading -> weird behaviour on win(msys) and macOS

[Al Thomas via vala-list]

 > On Tuesday, 12 March 2019, 22:40:17 GMT, Wolfgang Mauer 
 >  wrote: 
> Are there any sample using "GLib.Subprocess" with async 
> stdin/stdout/stderr ?
See https://stackoverflow.com/a/54391519
That one splices the output from one command to the input of another. So a bit 
more than you probablyneed, but a good start.

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

Re: [Vala] multithreading -> weird behaviour on win(msys) and macOS

[Al Thomas via vala-list]

 
   > On Tuesday, 12 March 2019, 22:03:28 GMT, Wolfgang Mauer 
 wrote:  
 > Well i found the "problem", it wasn't my code but i tried the example 
> from the valadoc 
> "https://valadoc.org/glib-2.0/GLib.Process.spawn_async_with_pipes.html;

> Just let it compile himself
>    string[] spawn_args = {"valac", "--pkg", "glib-2.0", 
> "GLib.Process.spawn_async_with_pipes.vala"};
> and "voilà" on win and mac the output is like this, never ending
 
> stderr: (NULL)stdout: (NULL)stderr: (NULL)stdout: (NULL)stderr: 

Firstly, use GLib.Subprocess. It is a newer and easier API.
As far as the bug goes it 
is:https://gitlab.gnome.org/GNOME/vala/issues/664https://gitlab.gnome.org/GNOME/glib/issues/1512
Really that needs someone with access to Mac and Windows 
to write a relevant test case in C for g_spawn_async_with_pipesAll I can find 
is https://gitlab.gnome.org/GNOME/glib/blob/master/tests/spawn-test.c






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

Re: [Vala] multithreading -> weird behaviour on win(msys) and macOS

[Al Thomas via vala-list]

 

   > On Tuesday, 12 March 2019, 15:48:59 GMT, Wolfgang Mauer 
 wrote:  
> With Linux everything works like expected with no errors/warnings but on 
> Windows(10/MSYS64) and macOS it get lots of errors.

> (valaDevelop.exe:2980): Gtk-CRITICAL **: 16:33:50.460: 
> gtk_text_view_get_buffer: assertion 'GTK_IS_TEXT_VIEW (text_view)' failed
These are type checks for the GType system. 
Seehttps://gitlab.gnome.org/GNOME/gtk/blob/master/gtk/gtktextview.h#L42https://developer.gnome.org/gobject/stable/gobject-Type-Information.html#G-TYPE-CHECK-INSTANCE-TYPE:CAPS
Probably text_view is null, so you may have some kind of scoping problem. You 
are usingclosures that should encapsulate the enclosing scope.
One thing to try is compiling with debug information and then use 
G_DEBUG=fatal-criticals and a debugger.
For example see 
https://wiki.gnome.org/Projects/Vala/DeveloperDocumentation#Debugging

You are then in to checking versions of libraries on macOS and Windows and to 
see if 
they are up to date as possible or comparable with what was used on Linux.

You also need to be checking the version of Vala used and the C code generated 
to make sure
there is nothing unusual.

> Any idea ?
Nothing specific, but the above might give you some things to try.

>                        // Timeout with 0 goes to "UI-Thread" ?! >             
>           GLib.Timeout.add(0, () =>

The 0 specifies the delay before the timeout source is called, nothing to do 
with a thread.GLib.Timeout.add() is a convenience method: 
https://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html#g-timeout-addIt
 adds the timeout to the global GMainContext and the docs advise "the callback 
will be invoked in whichever thread is running that maincontext"To specify the 
GMainContext you would need to use 
https://valadoc.org/glib-2.0/GLib.TimeoutSource.html and then attach() it to 
the relevantGMainContext.

Al




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

Re: [Vala] introduce valaDevelop

[Al Thomas via vala-list]

  The screenshots make this look a nice tool. Good to see Vala getting some new 
tooling.
 > On Friday, 22 February 2019, 16:00:13 GMT, Wolfgang Mauer 
 >  wrote: 
> The IDE is Freeware! At now there is no plan to make it OpenSource.
> I have to make something clear:
> ...I[t] should be and stay easy to use!

You don't have to accept contributions to your project just because the source 
code is availableand licensed to be re-used relatively openly. If the criteria 
for accepting a contribution is it meets your design principles of what you 
consider easy to use that is fine. Just say why you don't likeit if you get a 
pull request. That's the power of being a maintainer, use it wisely ;)

Some people are wary of downloading and running binary blobs from a repository. 
Making the sourceavailable means people can look over what they are building. 
The whole tool set you are using islicensed in such a way: Vala, GTK+, GLib, 
GtkSourceView, Ubuntu, etc. If nothing else it's worthbecoming more aware of 
why these projects are "open"/free.
Nice work on the Vala front, thanks for starting to share your work.
All the best,
Al
  
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Newbie question (using directive)

[Al Thomas via vala-list]

 
> On Wednesday, 20 February 2019, 13:30:08 GMT, Wolfgang Mauer 
 wrote:  > The sample was C#, but yes i do use ... 
--pkg=gio-2.0

> I know the problem(have a look to compiler.vala), that's why i ask to 
> "improve".

One possibility is the Vala compiler is applying different symbol resolution 
rules for properties and inheritance. So public Menu menu; is generating a 
conflict, whereas class App:Application {} is using the first 
symbolencountered. If it is following the latter rule then I would say that was 
a bug.
A test case illustrating the bug is required and then an issue to be opened at 
gitlab.gnome.org 


Am 20.02.19 um 14:20 schrieb Al Thomas via vala-list:
>    > On Wednesday, 20 February 2019, 13:16:38 GMT, Wolfgang Mauer 
> wrote:  >> The same would happen in C# if you 
>had two
>>> classes/interfaces/whatever with the same name but defined in distinct
>>> namespaces.
>> Sorry, but you are wrong!!!
>> The "Application" is ONLY resolved by the "using Gtk;" and not
>> "GLib.Application"
> Are you using --pkg gio-2.0 ? GLib.Application is part of the gio-2.0 binding.
>    
> ___
> 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] Newbie question (using directive)

[Al Thomas via vala-list]

   > On Wednesday, 20 February 2019, 13:16:38 GMT, Wolfgang Mauer 
 wrote:  >> The same would happen in C# if you had 
two 
>> classes/interfaces/whatever with the same name but defined in distinct 
>> namespaces.

> Sorry, but you are wrong!!!
> The "Application" is ONLY resolved by the "using Gtk;" and not 
> "GLib.Application"

Are you using --pkg gio-2.0 ? GLib.Application is part of the gio-2.0 binding.
  
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Meson sets odd destination folder for Vala

[Al Thomas via vala-list]

> On Sunday, 10 February 2019, 11:26:21 GMT, rastersoft  
> wrote: 
> I'm using meson to compile my vala projects, and now I want to create a 
> library, but I'm unable to install the .gir file. It creates it inside 
> "meson/src/25a6634@@TestLibrary@sha", but when it wants to install them, 
> it presumes it is created at "meson/src".

Try the vala_gir and install_dir options of shared_library: 
http://mesonbuild.com/Vala.html#gobject-introspection-and-language-bindings
 
  
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] C# developer, newbie question

[Al Thomas via vala-list]

   > On Tuesday, 18 December 2018, 14:44:30 GMT, Wolfgang Mauer 
 wrote:  > So i have to make the "new StatusList" 
!?
Not sure if it's the only way, but the following project uses 
 in the UI filethen instantiates the widget in 
the constructor of the main window and adds it to that window.
These files might give you a way to achieve what you want:
https://github.com/phastmike/gdx/blob/master/data/ui/share-window.uihttps://github.com/phastmike/gdx/blob/master/data/ui/share-spot-view.uihttps://github.com/phastmike/gdx/blob/master/src/Widgets/ShareWindow/share-window.vala

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

Re: [Vala] C# developer, newbie question

[Al Thomas via vala-list]

   > On Tuesday, 18 December 2018, 14:44:30 GMT, Wolfgang Mauer 
 wrote:   
> So i have to make the "new StatusList" !?
 
 
> But how the glade-file "mainpaned" should look like??? Just remove the 
> StatusList ?
 
 
OK, to instantiate it I think it needs to be a GtkChild. What error are you 
getting with GtkChild?


  > Am 18.12.18 um 15:37 schrieb Al Thomas:
 >> On Tuesday, 18 December 2018, 13:51:25 GMT, Wolfgang Mauer 
 >>  wrote:  >> [GtkTemplate(ui = 
 >> "/v/StatusList.glade")] public StatusList statusList;  << what to do 
 >> here? Both [GtkChild] and [GtkTemplate] don't work > The type StatusList is 
 >> already defined and the GtkBuilder code is dealt with in its own class. So 
 >> it should just be: > public StatusList statusList; > No need to tell Vala 
 >> to generate extra code, you are just storing a reference to the widget in 
 >> the main widget.

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

Re: [Vala] C# developer, newbie question

[Al Thomas via vala-list]

   >On Tuesday, 18 December 2018, 13:34:17 GMT, Wolfgang Mauer 
 wrote:  
 > Is there a way to have a GtkTemplate inside a GtkTemplate ?

It sounds like you are trying to use a widget contained within another widget?
I would try that in the GtkBuilder file. So the second widget is references as 
a component within the larger widget, but is defined separately. The Vala code 
would be two separateclasses with the relevant GtkTemplate annotations.
  
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] C# developer, newbie question

[Al Thomas via vala-list]

   > On Tuesday, 18 December 2018, 09:27:06 GMT, Wolfgang Mauer 
 wrote: > In vala tried Gtk.Builder 
"extend_with_template".

> If i try this in vala with

> [GtkChild] private Box mainBox;
> i get the error "error: [GtkChild] is only allowed in classes with a 
[GtkTemplate] attribute"

> Is there a other attribute for the gtk.builder using "extend_with_template"?
No there isn't. You either use [GtkChild] in a class marked with [GtkTemplate] 
andVala generates the right code for you or you code it all using the GTK+ API.
All the best,
Al
  
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Why is 77 greater than 4294967295?

[Al Thomas via vala-list]

 
> On Friday, 23 November 2018, 06:15:37 GMT, Heiher  
wrote:  >Wow! Why the comparison behavior of a signed long with an unsigned int
>isn't same as C/C++ in Vala?
> if (i > uint.MAX)  => if (_tmp6_ > (G_MAXUINT))

If you wish to look in to this further then I understand Vala follows the 
'usualarithmetic conversion' rules, similar to C. This is where the rank 
details forsimple types are used. See 
https://wiki.gnome.org/Projects/Vala/LegacyBindings#Simple_Type_StructsHere a 
long is rank 8 and uint is rank 7 so there is an implicit cast to long:
if (_tmp6_ > ((glong) G_MAXUINT)) {}
As Michele Dionisio points out earlier this a problem on an architecture wherea 
long is the same size as an int. On my PC I don't have that problem, 
althoughpersonally I think there should be an --explicit-cast-only option at 
some pointfor Vala.

What is also interesting is the use of _tmp6_ after these two recent 
commits:https://gitlab.gnome.org/GNOME/vala/commit/32ffc862417be39d42a1b8eeb3d0748b3e138affhttps://gitlab.gnome.org/GNOME/vala/commit/e701142da4601ece5ca71cc4484728b08969c74eCompiling
 now from master shows the temp variable is no longer generated. The output 
from:/home/vala_from_master/bin/valac test.vala --ccode --target-glib 2.40is:
/* test.c generated by valac 0.42.1.163-2a1c9, the Vala compiler
 * generated from test.vala, do not modify */

#include 
#include 

void _vala_main (void);

void
_vala_main (void)
{
    glong i = 0L;
    FILE* _tmp0_;
    FILE* _tmp1_;
    FILE* _tmp3_;
    i = (glong) 77;
    _tmp0_ = stdout;
    fprintf (_tmp0_, "%ld\n", i);
    _tmp1_ = stdout;
    fprintf (_tmp1_, "%u\n", 0);
    if (i < ((glong) 0)) {
        FILE* _tmp2_;
        _tmp2_ = stdout;
        fprintf (_tmp2_, "Never made it here.\n");
    }
    _tmp3_ = stdout;
    fprintf (_tmp3_, "%u\n", G_MAXUINT);
    if (i > ((glong) G_MAXUINT)) {
        FILE* _tmp4_;
        _tmp4_ = stdout;
        fprintf (_tmp4_, "Why am I here.\n");
    }
}

int
main (int argc,
  char ** argv)
{
    _vala_main ();
    return 0;
}

Some may also notice the #include  has gone. This is 
after:https://gitlab.gnome.org/GNOME/vala/commit/2ceaa53017b933a2856b878d436d2ae040b0f9b6
Firstly, many thanks to ricotz for the continued work on improving the Vala 
compiler. Secondlythis is a significant step to allowing Vala to compile code 
using only the standard C library, withoutneeding GLib. Potentially this could 
be done by compiling with --nostdpkg and using a basic-types-libc.vapi binding.

If anyone is interested in this aspect of Vala then try out master. Report any 
edge case bugs youfind and possibly have a go at hacking on the compiler. Some 
relevant issues are:
https://gitlab.gnome.org/GNOME/vala/issues/703https://gitlab.gnome.org/GNOME/vala/issues/624https://gitlab.gnome.org/GNOME/vala/issues/623
Have fun!
Al






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

Re: [Vala] Newbie need help

[Al Thomas via vala-list]

   > On Tuesday, 23 October 2018, 08:51:22 BST, wolfgang.ma...@kabelmail.de 
 wrote: > what is the difference between valac and 
vala? (Compiler / Interpreter)
> valac -> compiler(ok)
> vala -> interpreter  what/how/usage

valac is the compiler. The command, vala, combines compiling with valac and 
then running the output.
It allows a simple script like:

#!/usr/bin/vala
void main () {
    print ("compiled and run in one command!\n");
}

Although you may reach its limits quickly if you try anything too complex, e.g. 
https://gitlab.gnome.org/GNOME/vala/issues/618The use of the --run-args switch 
may help - 
https://gitlab.gnome.org/GNOME/vala/commit/0e45b19dfabce1b2f04733d7ec6eb02d6692b549

All the best,

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

Re: [Vala] printf question

[Al Thomas via vala-list]

  > On Tuesday, 9 October 2018, 16:16:44 BST, wolfgang.ma...@kabelmail.de 
 wrote:  > Is this a Bug?
> cellRendererText.text = ("%"+int64.FORMAT).printf((int64)obj); << 
> int64.FORMAT = "li"
> this works, but when i try this, witch is the same
> cellRendererText.text = ("%li").printf((int64)obj);
> i get thiss error 
> application.vala:192.45-192.54: error: Argument 1: Cannot convert from 
> `int64' to `long'

I think it should be %lli. Try:

void main () {
    int64 a = 1234567890123456789LL;
    print ("%li\n".printf ((int32)a));
    print ("%lli\n".printf (a));
}

A 'long' is at least 32 bits, a 'long long' is at least 64 bits. A good summary 
is https://en.wikipedia.org/wiki/C_data_types
I think that was the conclusion I came to when I wrote that up in the Genie 
docs: https://wiki.gnome.org/Projects/Genie#Numbers

int64.FORMAT in Vala is bound to GLib's G_GINT64_FORMAT. See the Vala binding: 
https://gitlab.gnome.org/GNOME/vala/blob/master/vapi/glib-2.0.vapi#L687
The GLib documentation advises 'This is the platform dependent conversion 
specifier for scanningand printing values of type gint64'  See 
https://developer.gnome.org/glib/2.56/glib-Basic-Types.html#G-GINT64-FORMAT:CAPS
 To my mind that is wrong in GLib. Now there may be some platform reason for 
doing this, but I suggest you raise an issue with GLib at 
https://gitlab.gnome.org/GNOME/vala/issues then we can take it from there. 

Note how the use of just %li in my code example truncates the number. The Vala 
compiler is recognising this in your second example and giving an error. If you 
cast to int32 it should compile. The Vala compiler has not been set up to 
recognise the creation of %li using string concatenation. So it is passed 
through to the output C and the C compiler does its thing with a resulting 
potential loss of data. Is this a bug in the Vala compiler? May be, but there 
may also be a limit to how much checking can be coded in to the compiler. Of 
course if someone submitted a patch that made it just work then that would be a 
different story :) BTW to read the generated C code use the --ccode switch with 
valac.

Hope that helps,

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

Re: [Vala] Newbie need help

[Al Thomas via vala-list]

   > On Monday, 8 October 2018, 00:41:45 BST, wolfgang.ma...@kabelmail.de 
 wrote: > In file included from 
/usr/include/webkitgtk-4.0/webkit2/webkit2.h:54:0,/usr/include/webkitgtk-4.0/webkit2
>                 from 
> /home/wolfgang/Projekte/TestSqlite/application.vala.c:10:/WebKitJavascriptResult.h:28:10:
>  fatal error: jsc/jsc.h: 
> Datei oder Verzeichnis nicht gefunden

> Is this not possible?

Likely something to do with:
https://bugs.launchpad.net/ubuntu/+source/webkit2gtk/+bug/1795901

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

Re: [Vala] Newbie need help

[Al Thomas via vala-list]

   > On Tuesday, 2 October 2018, 19:10:29 BST, wolfgang.ma...@kabelmail.de 
 wrote: > So thank's a lot for help, but back to 
monodevelop ...
> Wolfgang

> PS. Maybe the vala-team should think about it

The 'vala-team' is anyone using Vala. It is a community driven open source 
project.
This discussion has brought out some really useful tips from developers using 
Vala,
but there has already been significant work in this area. For example (with a 
nice screenshot):
https://blogs.gnome.org/chergert/2017/11/11/code-indexing-in-builder/
That was backed by work done through Google Summer of Code:
https://anoopchandu.wordpress.com/2017/08/24/code-search-for-gnome-builder-final-report/

Things could always be improved and in the Vala world that means developers 
fixing and improving
their tools with the support of the rest of us by reviewing code and 
maintaining projects. Anyone using
Vala needs to understand that development model.

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

Re: [Vala] Newbie need help

[Al Thomas via vala-list]

   > On Sunday, 30 September 2018, 22:57:23 BST, Wolfgang Mauer 
 wrote: 
> Does that mean that vala-dvelopers must use command-line tools? (Back to the> 
> 80's ;-))

> Please give me a hand if there are some useful IDE's.

If you want to develop for the Linux platform then use GNOME Builder. It is 
important to understand from the beginning that tool is geared towards Flatpak 
distribution.

For a more cross-platform approach then VS Code with the Vala language 
extension. There are also Vala language servers available. 

For more information read: https://wiki.gnome.org/Projects/Vala/Tools There is 
a lot of choice.

Debugging with gdb/lldb can be a bit rough so contributions in that area are 
welcome.
All the best,

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

Re: [Vala] any latest vala binary for windows?

[Al Thomas via vala-list]

   > On Thursday, 20 September 2018, 01:40:27 BST, oyster via vala-list 
 wrote:  > It installs mingw-w64-x86_64-vala-0.38.4-1 
first, which happens do not work on my
> MSYS2(no matter I input `valac`, `valac --help`, `valac test.vala`,
> there is no message displays;  `valac test.vala` does not produce any
> C file)

If there is no output at all it suggests you are not running valac from within 
the MSYS2 shell.
You will want to run in mingw64.exe for native Windows development. More 
options are give
in the Vala wiki: https://wiki.gnome.org/Projects/Vala/ValaOnWindows

Your undefined references, e.g. c:(.text+0xd2f): undefined reference to 
`g_type_check_instance_cast',
are GLib symbols. I think it means the build is not finding the GLib C headers. 
The C headers should
be in the include directory given by pkg-config --cflags glib-2.0

Good luck,

Al




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

Re: [Vala] any latest vala binary for windows?

[Al Thomas via vala-list]

   > On Thursday, 20 September 2018, 00:45:51 BST, oyster via vala-list 
 wrote:  > I give up building from source. So is there any 
binary vala for
> windows? On MSYS2, there is an old mingw-w64-x86_64-vala-0.38.4-1

It looks like 0.42.0 is there: 
https://github.com/Alexpux/MINGW-packages/pull/4350

I'm not a Windows user so can't really help further.

Al



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

Re: [Vala] Any tips for newbies

[Al Thomas via vala-list]

 Hi, 

> On Wednesday, 19 September 2018, 09:57:22 BST, Robin Wils via vala-list 
>  wrote: > I am working on a [small simple 
> project](https://gitlab.com/RobinWils/BAG-art-creator/tree/master) and have a 
> feeling that
> the GNOME Vala website only contains some basics.
> I use a grid which I want to be able to resize when a menu_button gets 
> clicked so I probably need a way to recreate/refresh the grid.

Your project seems to need two widgets: a color palette for selecting colors 
and an interactive grid that allows the color of each square in the grid to be 
changed. You may want to consider custom GTK widgets for this. I've collected a 
few links, but have not put this in to practise myself. From what I understand 
a custom widget inherits from Gtk.DrawingArea and uses Cairo to render the 
contents.

Some guides I've found:
 - 
https://codeburst.io/how-to-build-a-custom-gtk-widget-with-haskell-eaff04a6262 
- 'How To Build A Custom GTK Widget With Haskell', I found this explained the 
principles very well, although the code isn't too relevant because it is in 
Haskell
 - https://wiki.gnome.org/Projects/Vala/CustomWidgetSamples - this is the Vala 
code sample, but you probably want to understand a bit more about how things 
work in GTK before coding anything up - 
https://developer.gnome.org/gtkmm-tutorial/stable/chapter-drawingarea.html.en - 
this provides a good overview of the principles, although the code examples are 
C++
 - https://valadoc.org/gtk+-3.0/Gtk.DrawingArea.html - also includes a small 
Vala code sample
 - 
https://stackoverflow.com/questions/9395111/gtkdrawingarea-how-to-make-it-drawable
 - may be useful to help understand the 'draw' signal a bit better
There is also the concept of off screen windows in GTK, but I don't know enough 
to explain it.

Hope that helps,

Al













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

Re: [Vala] Any tips for newbies

[Al Thomas via vala-list]

   > On Wednesday, 19 September 2018, 09:57:22 BST, Robin Wils via vala-list 
 wrote: > I am working on a [small simple 
project](https://gitlab.com/RobinWils/BAG-art-creator/tree/master) and have a 
feeling that the GNOME Vala
> website only contains some basics. One of my issues is that I haven't found a 
> way to recreate a object.

Making a clear distinction between Vala, the language, and using Vala for 
developing a GTK+ application is important. It sounds like you are looking for 
more information on developing with GTK+. By the way, in the Vala language 
creating an object is instantiating a class, like this:

void main () {
    new MyObject ();
}

class MyObject {}

If you want to create another instance just use new MyObject() again.

> I use a grid which I want to be able to resize when a menu_button gets 
> clicked so I probably need a way to recreate/refresh the grid.

You might want to look at GtkFlowBox, which was introduced with GTK+ 3.12: 
https://valadoc.org/gtk+-3.0/Gtk.FlowBox.html
> I was wondering of there are any other useful sites or tips for new Vala 
> users. I am probably already doing some
> bad practises in that project since I am new to the Vala language.

The GNOME game Five-or-More has a Vala port that was finished as part of Google 
Summer of Code: https://gitlab.gnome.org/GNOME/five-or-more/merge_requests/1
There are a number of GTK+ tools that can be started from the command line:
gtk3-demo - useful to see the widgets available, although the code demos are in 
C
gtk3-widget-factory - another demo of widgets
gtk3-icon-browser - shows available icons

Elementary OS's Sudoku may also be of interest: 
https://github.com/parnold-x/sudoku
StackOverflow, https://stackoverflow.com/questions/tagged/vala , is also used 
for asking questions about GTK+ and Vala. Take a look at some of the very good 
answers there. If you're asking a question then include a simple working 
example showing the problem.

All the best,

Al

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

Re: [Vala] bad configure for MSYS2 + MingW 64 on Win7 64 bits

[Al Thomas via vala-list]

> On Wednesday, 19 September 2018, 09:55:46 BST, oyster via vala-list 
 wrote:  
 > bad configure for MSYS2 + MingW 64 on Win7 64 bits
> On my MSYS2 + MingW 64, there exists actually /bin/pkg-config.exe, but
> the configure tries to find /bin/pkg-config.sh
> it will fail without doubt.

> ./configure
> ./make -j8

It looks like you are building a project with Autotools. So you could try:

export PKG_CONFIG=/bin/pkg-config.exe
./configure
./make -j8

See https://autotools.io/pkgconfig/pkg_check_modules.html
MSYS2 is a separate project, so you may have to raise an issue with them. 
Depending on what you are doing.

> btw, vala lives in github.com now. but the strange thing is that I did
> not find issues part to report bugs

No, Vala lives on GNOME's GitLab instance: https://gitlab.gnome.org/GNOME/vala
This is also linked to from the Vala 'home page': 
https://wiki.gnome.org/Projects/Vala See the section on Contributing.
GitHub is just a mirror of the GNOME repositories and is not monitored for 
issues or pull requests.
 
Regards,

Al

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

[Vala] Feedback needed on quirky warning/error messages from libvala

[Al Thomas via vala-list]

Hi All,

With the development of language servers [1] for Vala and the possibility of 
warning/error messages going beyond English [2] it would be helpful to get 
examples of warnings/errors that aren't clear enough.

If you have a code example and associated message please create an issue [3] or 
if that is too much post to this list.

Regards,
Al

[1] - 
https://wiki.gnome.org/Projects/Vala/Tools#Language_Server_Protocol_Support
[2] - https://gitlab.gnome.org/GNOME/vala/tree/wip/gettext
[3] - https://gitlab.gnome.org/GNOME/vala/issues
___
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] avoid "method never used" warning for methods linked to Glade files in private class

[Al Thomas via vala-list]

> On Tuesday, 1 May 2018, 17:49:09 BST, rastersoft  
wrote: > When the class is public everything is fine, but when I declare it as 
> private (which I need for several reasons) I receive a "method '' 
> never used" warning.

> How can I avoid those warnings?

Do you still get the warning if you mark it 'internal' instead of 'private'?  
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Graphing with libdazzle

[Al Thomas via vala-list]

> On Thursday, 29 March 2018, 19:47:42 BST, Steven Oliver 
 wrote:  > Has anyone on here ever used libdazzle 
[1]?...> There is documentation
> for it on valadoc [3] but, sadly, as is typical for valadoc, it's a
> lot of function and property listings with no explanations or
> examples.

This isn't a tip to solve your problem, but an observation for anyone looking 
tocontribute back to the Vala ecosystem.
The libdazzle Vala binding is generated from a GObject Introspection Repository 
(GIR) 
file:https://github.com/nemequ/vala-girs/blob/master/gir-1.0/Dazzle-1.0.gir
The GIR is generated from GObject annotations 
(https://wiki.gnome.org/Projects/GObjectIntrospection/Annotations/)and those 
include documentation comments. For example, if you look down the entries in 
https://valadoc.org/libdazzle-1.0/Dazzle.html The entry for BindingGroup has a 
description.This is taken from the C source: 
https://gitlab.gnome.org/GNOME/libdazzle/blob/master/src/bindings/dzl-binding-group.c#L28So
 if anyone wishes to improve the documentation for their tooling then 
submitting patches, or merge requests through GitLab in the case of libdazzle, 
is going to help us all.Of course we can only do as much as we can to 
contribute back and this is a general commentabout how anyone and everyone can 
help improve documentation for the libraries they use.
Regards,
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

[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] Date format

[Al Thomas via vala-list]

  On Wednesday, 28 March 2018, 11:50:33 BST, rastersoft  
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

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

Re: [Vala] Date format

[Al Thomas via vala-list]

> On Wednesday, 28 March 2018, 11:15:48 BST, rastersoft 
 wrote: >> Pass "%x" for the format string.
> I used that, but the year is printed with only two digits... 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 options 
to play around with 
though:https://valadoc.org/glib-2.0/GLib.DateTime.format.html
Regards,
Al
  
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] valadoc Question

[Al Thomas via vala-list]

> On Friday, 23 March 2018, 19:00:09 GMT, Steven Oliver 
 wrote: 
> How do I determine the list of icon names I can pick from? For
> whatever reason valadoc doesn't list them. Is there somewhere else I
> can look for the list?

I think what you want is the Freedesktop.org icon naming 
specification:https://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html
This may help a little 
too:https://stackoverflow.com/questions/36805505/gtk-stock-is-deprecated-whats-the-alternative/
Regards,

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

Re: [Vala] GLib.assert_no_error not working?

[Al Thomas via vala-list]

> On Friday, 9 March 2018, 00:17:30 GMT, Michael Gratton  
wrote:  >> On Thu, Mar 8, 2018 at 9:26 PM, Al Thomas  
wrote:
>> The assertion is in a catch block so err will be set. Whereas 
>> assert_no_error
>> is used to check err is unset (i.e. null). The line about 'produce a 
>> message that includes
>> the error message and code' seems like a copy/paste error in the 
>> documentation.

> That doesn't seem right at all. What's the point of the argument then?
Of course! I hope I understand now. assert_no_error is used to check the error 
is unset. The assertion is from GLib and used with C.So in C you have GError as 
an out argument and if the argument is nullthen assert_no_error passes. That is 
the point of the argument.

In Vala, however, the GError is hidden. It is only exposed inside the catch 
block and so will always be set. So I think I understand now. You know the 
error willalways be set so it will always fail and then print the values of the 
GError.I have difficulty taking in the idea of asserting there is no error in a 
catch block.Maybe assert_not_reached would be clearer and just print the 
err.message before.Although it is a little more code.

Thinking it through again, it looks like assert_no_error is broken in GLib.I 
think assert_false is as well. Have you ever tried assert_false( false )?That 
should pass, but fails for me.
Regards,
Al
  
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] GLib.assert_no_error not working?

[Al Thomas via vala-list]

> On Thursday, 8 March 2018, 00:14:12 GMT, Michael Gratton  
wrote: 
> GLib.assert_no_error doesn't seem to do anything that its API docs 
> advertises for me - doesn't asset, doesn't pretty print the error 
> message.

> See the attached minimal test case, per the comments I'd expect it to 
> abort on line 9, but it actually aborts on line 11. This is what I get:

> Am I missing something here?

The assertion is in a catch block so err will be set. Whereas assert_no_erroris 
used to check err is unset (i.e. null). The line about 'produce a message that 
includesthe error message and code' seems like a copy/paste error in the 
documentation.
What you might want is assert_error, but the C docs for that advise 'If you 
want totest that err is set, but don't care what it's set to, just useg_assert 
(err != NULL)'
Regards,
Al
  
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Legacy Bindings: "Inject" & operator?

[Al Thomas via vala-list]

> On Thursday, 1 March 2018, 07:55:19 GMT, Dr. Michael Lauer 
 wrote:  
 > I pondered whether it would be helpful to add a to_string() method to make
> this a bit more convenient.

Yes, to my mind to_string() should be used more in bindings. It makes it much 
easier to use instring templates, etc.

> This doesn’t work though, since time_t is bounds as IntegerType, hence the 
> compiler bails out> Independent of whether this patch can make it to 
> glib-2.0.vapi or not, I wonder> whether there is a CCode attribute that could 
> make this happen without introducing
> a vala helper method.

There are CCode attributes type and type_cname listed at 
http://www.vala-project.org/doc/vala/Attributes.html#CCode_Attribute
May be they are relevant.
Al

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

Re: [Vala] What is the internal access specification (Re: A couple of Vala questions)

[Al Thomas via vala-list]

> On Monday, 29 January 2018, 07:26:22 GMT, Manish Jain 
 wrote: 
> Does 'internal' hook into the Vala package system, meaning internal > members 
> cannot be accessed from a different package ?

A simple library like:
[CCode (gir_namespace = "libexample", gir_version = "0.1")]
namespace ExampleLib {

    public void test () {
        WhateverNameYouLikeForInternalUse.do_some_work ();
    }
}

namespace WhateverNameYouLikeForInternalUse {

    internal void do_some_work () {
        print( "Internal test function called\n" );
    }
}
compiled with the --hide-internal option like:valac demo.vala -X -fPIC -X 
-shared --hide-internal --library libexample --header libexample.h --gir 
libexample-0.1.gir --output libexample.so
will not show the internal function in the symbol table of the library. To see 
the symbols use:readelf --dyn-syms --wide libexample.so
If you look at the C code produced you should see the G_GNUCINTERNAL_MACRO 
being 
used:https://developer.gnome.org/glib/stable/glib-Miscellaneous-Macros.html#G-GNUC-INTERNAL:CAPS

I understand DLLs compiled for Windows with MSVC using a different arrangement 
- the symbols are hiddenby default. Vala doesn't currently do anything about 
that.
Regards,
Al






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

Re: [Vala] compiler warning for Variant.strv()

[Al Thomas via vala-list]

> On Thursday, 25 January 2018, 10:32:07 GMT, Yasushi SHOJI 
 wrote:  
> void main () {
>         Variant ary = new Variant.strv({"foo", "bar", "baz"});
> }


> In file included from /usr/include/glib-2.0/glib/gmessages.h:35:0,
>                 from /usr/include/glib-2.0/glib.h:62,
>                 from /tmp/a.vala.c:5:
> /usr/include/glib-2.0/glib/gvariant.h:118:33: note: expected ‘const
> gchar * const* {aka const char * const*}’ but argument is of type
> ‘gchar ** {aka char **}’
> GVariant *                      g_variant_new_strv
>   (const gchar * const  *strv,

You can use Vala's implicit conversion module to create a string array.I've 
figured out how to do this for string arrays, not just basic types. Itdoesn't 
produce the C warnings when compiling:
void main () {    string[] my_array = {"foo", "bar", "baz"};
    test (my_array);
    Variant my_variant = my_array;
    test (my_variant);
 }

void test (Variant variant) {
    print (@"$(variant.get_type_string ())\n");
    print (@"$(variant.print (true))\n");
}

The implicit conversion is invoked when assigning the array to a variable of 
type Variant. It is also invoked when passing the string array as an argumentto 
a function that expects a Variant type parameter.
This also works for GLib HashTable, which is a dictionary over D-Bus. This 
should be very useful for using DBusConnection. Code snippet:
var a = new HashTable of string, Variant ( str_hash, str_equal );
a.insert( "first", 1 );
a.insert( "second", "test" );
b:Variant = a;

A couple of references for anyone 
interested:https://wiki.gnome.org/Projects/Vala/DBusServerSample#Type_Table
https://valadoc.org/gio-2.0/GLib.DBusConnection.html

All the best,
Al

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

Re: [Vala] Package `Gee-0.8' not found

[Al Thomas via vala-list]

 
   > On Thursday, 25 January 2018, 16:41:31 GMT, Ralf Ganswindt 
 wrote:  
 > I'm experimenting with Vala and so far I like how it works. However, I
> tried to compile a basic gee example from the sample programs and I get the
> following:

> $ valac --pkg Gee-0.8 list.vala
> error: Package `Gee-0.8' not found in specified Vala API directories or

It should be --pkg gee-0.8 It is case sensitive!
You also need the development files installed. For Ubuntu that would be 
something likeapt install libgee-dev

> GIR files:
You want to avoid GIR files to start with. They are GObject Introspection 
Repository (GIR)files that contain enough information about a C library's 
interface to generate bindings forvarious languages, including Vala. The Vala 
tool vapigen can then be used to generate aVala Application Programming 
Interface (VAPI) file from the GIR. valac can do this automaticallyif a VAPI is 
not found.
By using the capitalized version, --pkg Gee-0.8, valac tried to generate the 
VAPI for you by
searching for the relevant GIR. It looks like that wasn't found either, 
probably because youdon't have the development files installed. If you look at 
the files in the dev package youshould see the difference in filenames.

When starting out you want to focus on using VAPI files for interfacing with 
libraries.
All the best,
Al
  
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] compiler warning for Variant.strv()

[Al Thomas via vala-list]

> On Thursday, 25 January 2018, 10:32:07 GMT, Yasushi SHOJI 
 wrote:  
> void main () {
>         Variant ary = new Variant.strv({"foo", "bar", "baz"});
> }


> /usr/include/glib-2.0/glib/gvariant.h:118:33: note: expected ‘const
> gchar * const* {aka const char * const*}’ but argument is of type
> ‘gchar ** {aka char **}’
> GVariant *                      g_variant_new_strv
>  (const gchar * const  *strv,
>                                ^~

Vala does have implicit conversion for Variant types, e.g.:
Variant a = "a string";Variant b = 10;
I've not figure out how well this works with collections, but there is this 
patch:https://mail.gnome.org/archives/commits-list/2010-October/msg08428.html

I've tried: Variant test = {"foo", "bar", "bax"};but get "error: initializer 
list used for `GLib.Variant?', which is neither array nor struct"
I also tried explicit casting:string[] test = {"foo", "bar", "baz"};
Variant result = (Variant) test;
This compiles without C warnings, but I get a runtime critical from 
GLib:GLib-CRITICAL **: g_variant_ref: assertion 'value->ref_count > 0' failed
So it looks like some development is needed in that area, if someone wants to 
take up the challenge!
Al






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

Re: [Vala] Newbie help requested for scrolling a TextView

[Al Thomas via vala-list]

  > On Thursday, 25 January 2018, 11:37:49 GMT, Manish Jain 
 wrote: > I was filling up the view> with text += . And I think Vala> removes the trailing 
newline, so essentially my buffer always had> just one line! 
By using += with the text property of the buffer you are re-writing the 
wholebuffer on each change. You should probably be looking at one of the 
insertfunctions of Gtk.TextBuffer.
I doubt Vala is removing trailing newlines unless you are telling your program 
to, even if unintentionally! Your Vala program is using library functions so 
lookcarefully at these library functions' documentation and what they are 
returning.

 > At runtime, both textview and scale occupy 50% of the grid's> real-estate. 
 > Can I tell the grid to give 75% coverage to the view> and 25% to the scale, 
 > or is there some way I can size the widgets> myself from within my code?

You would want a 4 column grid and to make the width of the view3 and the width 
of the scale 1. A nice example 
(Python):http://python-gtk-3-tutorial.readthedocs.io/en/latest/layout.html#id1

Regards,

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

Re: [Vala] compiler warning for Variant.strv()

[Al Thomas via vala-list]

> On Thursday, 25 January 2018, 11:19:44 GMT, Abderrahim Kitouni 
>  wrote: 
> You can try to use the latest development version of Vala. Most of those
> warnings should go away.

Unfortunately that isn't fixed in this case.
The g_variant_new_strv has a C type signature for the array of strings as:const 
gchar * const *strv
See 
https://developer.gnome.org/glib/stable/glib-GVariant.html#g-variant-new-strv
and Vala is generating the type as gchar**. Still two levels of indirection, 
but not similarenough for the compiler. I'm not aware of a way of explicitly 
setting the C type of an array in a Vala binding. The "Legacy Bindings" 
document references array lengthsa lot, but not the type of array:
https://wiki.gnome.org/Projects/Vala/LegacyBindings


On Thu, 25 Jan 2018, 11:32 Yasushi SHOJI,  wrote:

> Is there anyway to fix this except "-Wno-incompatible-pointer-types"?
>
>
> $ cat a.vala
> using Gee;
>
> void main () {
>        Variant ary = new Variant.strv({"foo", "bar", "baz"});
> }
>
>
> $ valac --pkg gee-0.8 a.vala --no-color
> a.vala:4.11-4.55: warning: local variable `ary' declared but never used
>        Variant ary = new Variant.strv({"foo", "bar", "baz"});
>                ^
> /tmp/a.vala.c: In function ‘_vala_main’:
> /tmp/a.vala.c:38:31: warning: passing argument 1 of
> ‘g_variant_new_strv’ from incompatible pointer type
> [-Wincompatible-pointer-types]
>  _tmp5_ = g_variant_new_strv (_tmp4_, 3);
>                                ^~
> In file included from /usr/include/glib-2.0/glib/gmessages.h:35:0,
>                  from /usr/include/glib-2.0/glib.h:62,
>                  from /tmp/a.vala.c:5:
> /usr/include/glib-2.0/glib/gvariant.h:118:33: note: expected ‘const
> gchar * const* {aka const char * const*}’ but argument is of type
> ‘gchar ** {aka char **}’
>  GVariant *                      g_variant_new_strv
>  (const gchar * const  *strv,
>                                  ^~
> Compilation succeeded - 1 warning(s)
> --

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

Re: [Vala] Newbie help requested for scrolling a TextView

[Al Thomas via vala-list]

   > On Thursday, 25 January 2018, 01:00:05 GMT, Manish Jain 
 wrote: 
> Despite a lot of effort to write an event handler, I still cannot get > the 
> scale to tell the view to scroll. I have tried scrolling with the
> scroll_to_iter() method, but the iterator always lands me at the top of 
> the file, whereas I want the view to move south.

Have you tried moving the TextIter with something 
like:https://valadoc.org/gtk+-3.0/Gtk.TextIter.set_line.html

It sounds like you want a TextIter instance for your vscale widget that you can 
then moveabout the document and then scroll to it.
It may be your almost there, just missing the last piece of the puzzle!
Regards,
Al
  
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] FreeBSD - vala/GTK3 - Seat & FileChooserNative types not found

[Al Thomas via vala-list]

   > On Saturday, 23 December 2017, 09:33:52 GMT, Philip Brown 
 wrote:  
> Thank you! That is a great explanation. FreeBSD's latest release for 
> vala is only at vala-0.30. I will have to see what I can do about 
> updating to a minimum of vala-0.32.

If you hadn't found it, this ticket for getting Vala 0.36.4 into FreshPorts has 
been completed:https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221941

Good to see Vala being used so widely.
Al
  
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Confusing issue with static struct method: too many arguments to function

[Al Thomas via vala-list]

   > On Monday, 22 January 2018, 22:00:19 GMT, Michael Murphy 
 wrote:  > I have the following which is automatically 
generated by bindgen.

Would that be vala-gen-introspect ? That's a bit of an old tool. I'm not sure 
how well it fares, butmay be a good starting point for a hand written bindings.

>    [CCode (has_type_id = false)]
>   public struct Sector {
>        public static Sector megabyte (uint64 value);
>    }

If this is a named initializer then you want:
public Sector.megabyte (uint64 value);

An initializer of a struct is similar to a constructor of an object. 

> distinst_sector_megabyte ((guint64) 512, &_tmp39_);

My working assumption would be the return value, Sector, has been converted to 
an outparameter. I've not looked in to the reasoning for that.
Hope that helps,
Al
  
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] error in GLib.DataInputStream

[Al Thomas via vala-list]

> On Saturday, 6 January 2018, 11:24:01 GMT, Michele Dionisio 
>  wrote: 

> but this is not true, infact in documentation of glib method
> g_data_input_stream_read_line ()
> we have
> error                      GError for error reporting.

GError is the mechanism in C for returning the error. It is the standard 
mechanism across
GLib and doesn't give any indication of the type of errors that can be 
returned. The GError
conventions allows for bindings to recognise the mechanism. For example in 
Python, PyGObject
allows the try...except syntax to be used when it recognises GError. So having 
the GError
parameter in the C documentation doesn't mean it will raise any error, although 
technically it
could.

The documentation for GIOError ( 
https://developer.gnome.org/gio/stable/gio-GIOError.html ) 
shows functions for converting standing C errno.h errors to GIOError ( 
g_io_error_from_errno () )
and converting Windows errors to GIOError ( g_io_error_from_win32_error () ). 
Also G_IO_ERROR
is described as the "Error domain for GIO". My interpretation of that is GIO is 
providing an
abstraction over errors from different implementations.

> an example of this problem can be reached if you do
> var fileInStream = new DataInputStream ( new ConverterInputStream
> and ConverterInputStream can raise any possible GError and not only IO.

A quick look over https://developer.gnome.org/gio/stable/GConverter.html shows 
only
GIOErrors. The reference to G_CONVERTER_ERROR is a result code for 
GConverterResult.

> do you think that I have to raise a bug for that?

If you are writing a GConverter then I think you should be throwing IOErrors. 
The GIOError
documentation advises "In general, new error codes either only apply to new 
APIs, or else 
replace G_IO_ERROR_FAILED in cases that were not explicitly distinguished 
before." If your
error does not have an equivalent then use G_IO_ERROR_FAILED.

I don't currently believe this is a bug in the Vala bindings.

All the best,

Al


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

Re: [Vala] i18n help

[Al Thomas via vala-list]

> On Friday, 22 December 2017, 18:10:37 GMT, Dr. Michael J. Chudobiak 
>  wrote: 

> I'm having trouble with i18n. The _("") macros in my program work, but 
> the N_("") ones (for initializing string arrays) don't. Any pointers on 
> what the issue could be?

> This is the program:
>https://git.gnome.org/browse/moserial

>From 
>https://stackoverflow.com/questions/10715821/vala-resources-and-localization
"The only real complication is that you need to define GETTEXT_PACKAGE at the C 
level"

I'm not seeing that in the Makefile:
https://git.gnome.org/browse/moserial/tree/Makefile.am

So that would be the first thing to investigate if it was me.

Al

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

Re: [Vala] FreeBSD - vala/GTK3 - Seat & FileChooserNative types not found

[Al Thomas via vala-list]

> On Friday, 22 December 2017, 16:17:53 GMT, philip is hungry via vala-list 
>  wrote: 

> I am trying to compile a vala program on FreeBSD

From the file paths it looks like you are trying to compile Dino on FreeBSD:
https://github.com/dino/dino

> Running "make" I encounter the following errors:
> /home/philip/Downloads/dino-master/main/src/ui/conversation_summary/message_textview.vala:68.14-68.22:
>  error: The type name `Seat' could not be found
>    List seats = window.get_display().list_seats();
>    ^

These errors are from the Vala compiler, rather than the C compiler. Although 
it is a good idea to check your installed libraries and C headers, as you have 
done, you should focus on the Vala side first. The Vala compiler is saying it 
can't find Seat.

One possibility is the Gdk namespace has not been brought in to scope with the 
'using' keyword. The source from Dino:
https://github.com/dino/dino/blob/master/main/src/ui/conversation_summary/message_textview.vala
shows that it is in scope. So unless you've modified the source that shouldn't 
be the reason.

Gdk.Seat is defined in gdk-3.0.vapi. You should check that the VAPI is in the 
appropriate search path and that Seat is defined. From 
https://developer.gnome.org/gdk3/stable/GdkSeat.html it looks like GdkSeat was 
added since Gdk 3.20. GNOME 3.20 and libraries were release March 2016. That 
would tie in with a minimum Vala version of 0.32.0 - released 21 March 2016.

I hope that gets you further along the way,

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

[Vala] gtk+-3.0 bindings - big change little end user impact (hopefully)

[Al Thomas via vala-list]

Hello Fellow Vala Fans,
A long standing change to generate the GTK+ 3 bindings from GIR, instead of 
usingthe older GIDL method, has now gone into Vala mainline:
https://git.gnome.org/browse/vala/commit/?id=a8e6aff63e5e1502290ba93398314acf2ad45b60
This enables better bindings to be generated more easily and has already 
resolved 
twobugs:https://bugzilla.gnome.org/show_bug.cgi?id=791130https://bugzilla.gnome.org/show_bug.cgi?id=791570
Thanks to Evan Nemerson and Rico Tzschichholz for starting and finishing this 
work, respectively.

The newly generated bindings are now available for testing in the 0.39.2 
preview release and will be available from Vala 0.40. The changes should have 
minimal impact. They have already passed building many Vala projects that are 
in Vala CI. See this 
build:http://paldo.org:8010/builders/vala-staging/builds/356
If a binding has changed, for example a parameter has become nullable, you may 
needto use conditional pre-parsing in your Vala code:#if VALA_0_40    // New 
binding call#else    // Old binding call#endif

If you believe there is an error in a binding please raise a ticket through our 
bugzilla.
The 0.39.2 preview release has already had some external testing. A regression 
was found andbug report with test case raised. The issue was a side effect of 
work to reduce the numberof temporary variables used in Vala generated C and 
has now been fixed. If you are usinginheritance to chain up setting a struct at 
instantiation time then details are 
here:https://bugzilla.gnome.org/show_bug.cgi?id=791785
All the best,
Al

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

Re: [Vala] Introspection for exception instances

[Al Thomas via vala-list]

> On Monday, 13 November 2017, 14:36:17 GMT, Michael Gratton  
> wrote: 
> PS: Has anyone used the glib backgrace_symbols() function[0] to 
> generate a stack trace in Vala?

I haven't, but take a look at:https://github.com/PerfectCarl/vala-stacktrace
That appears to make use 
of:https://valadoc.org/linux/Linux.backtrace_symbols.html
Al
  
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Introspection for exception instances

[Al Thomas via vala-list]

> On Monday, 13 November 2017, 14:36:17 GMT, Michael Gratton  
> wrote:  
 > PS: Has anyone used the glib backgrace_symbols() function[0] to 
> generate a stack trace in Vala?

I haven't, but take a look at:https://github.com/PerfectCarl/vala-stacktrace
That appears to make use of:



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

Re: [Vala] Introspection for exception instances

[Al Thomas via vala-list]

> On Monday, 13 November 2017, 14:25:04 GMT, Michael Gratton  
> wrote: 

> For example, given an instance of a 
> IOError.CANCELLABLE, I'd like to be able to come up with a string 
> representation of it as "IOError.CANCELLABLE". At the moment the best I 
> can get is the quark and code as strings, i.e. "g-io-error" and "32" 
> (or whatever).

I hope this gets you a step further, but I've not applied this with GLib's 
cancellable.
The general pattern is:

void main () {
    try {
    test ();
    } catch (IOError error) {
    print (error.message + "\n");
    }
}

void test () throws IOError {
    throw new IOError.CANCELLED ("This test has been cancelled");
}

Just compile with valac --pkg gio-2.0 cancellable_error.vala and you will see
the message. 

So you probably want to be looking at:
https://valadoc.org/gio-2.0/GLib.Cancellable.set_error_if_cancelled.html
https://developer.gnome.org/gio/stable/GCancellable.html#g-cancellable-set-error-if-cancelled

From the Valadoc representation is looks as though the GError is taken as an 
out parameter,
but for this method it should be an in parameter. So there could be something 
wrong with the bindings there.

> Relatedly, since the error's code is an enum, it would be handy to be 
> able to use it in a switch statement, e.g.:

> switch (io_error.code) {
> case IOError.CANCELLABLE:
>    ...
>    break;
> }

I'm not sure about this one. I've tried:

case IOError.CANCELLED.code

and had a look at:

https://valadoc.org/gio-2.0/GLib.IOError.from_errno.html
https://developer.gnome.org/glib/stable/glib-Error-Reporting.html#g-error-matches
https://developer.gnome.org/gio/stable/gio-GIOError.html#GIOErrorEnum

but nothing obvious worked.

I assumed CANCELLABLE was a typo.

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

Re: [Vala] testrunner.sh on OpenIndiana

[Al Thomas via vala-list]

> On Wednesday, 8 November 2017, 20:23:24 GMT, Jason Martin 
>  wrote: 

> ERROR:/export/home/agrellum/oi-userland/components/developer/vala/build/i86/tests/_test/main.c:111:control_flow_bug736774_2_main:
> assertion failed: (keep != "test")
> Maybe real OpenIndiana or Vala bug? I am not good with core dumps and gdb 

The core dump is because of the failed assertion. That's how GLib assertions 
work.
So the real question is why keep == "test". This is a memory leak bug:
https://bugzilla.gnome.org/show_bug.cgi?id=736774

keep has been defined as a pointer type, string*. I hope that helps a bit.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] testrunner.sh on OpenIndiana

[Al Thomas via vala-list]

> On Wednesday, 1 November 2017, 19:48:37 GMT, Jason Martin 
>  wrote: 

> All but three pass now. My patch below. Comments might help someone.

> ERROR:/export/home/agrellum/vala-0.36.6/tests/_test/main.c:111:control_flow_bug736774_2_main:
> assertion failed: (keep != "test")

That's disturbing! It would be good to get to the root cause of this one, 
although it probably doesn't relate to the testrunner.

> /dbus/enum-string-marshalling
> main.vala:17.42-17.57: error: The type name `UnixOutputStream' could not be
> found

This needs --pkg gio-unix-2.0, but I can't figure out how the current build 
system passes that in VALAFLAGS.

> /dbus/filedescriptor-errors/server
> Conversion from character set '646' to 'UTF-8' is not supported

Not sure this is Vala related.

> Patch:
I've tried to apply the patch, but mail systems often remove the leading 
spaces. I've added them back after copy and pasting, but that patch still 
doesn't apply. I used:
patch testrunner.sh copied-from-mail.patch
I get:
patch:  malformed patch at line 16: @@ -114,26 +119,32 @@

It would be better now to open an "Improve testrunner.sh portability" bug at 
bugzilla with a git formatted patch.

+# OpenIndiana add -v flag for extra logging
Seems like a good idea.

+# Hardcoded --cc flag for now; Use ./configure CC=gcc when building vala
+# System can have many CC's and gcc may not be default
+# Remove -X -Werror=int-conversion; Not an option with gcc (GCC) 4.9.4
OpenIndiana build

Maybe the flags should be split over multiple lines, with a tab indent. e.g.
+VALAFLAGS="$VALAFLAGS \
-v \
--cc=gcc \
--vapidir $vapidir \
--disable-warnings"

Given the age of the GCC4 series I'm inclined to say OpenIndiana should carry 
an out of tree patch removing the int-conversion option. By splitting the flags 
over multiple lines it would make that patch easier to read.

Also OpenIndiana may move to GCC5 at some point:
https://www.openindiana.org/2017/04/23/gcc-6-and-the-status-of-compilers-in-openindiana/

If no --cc option is given and CC is not set then Vala uses cc. See:
https://git.gnome.org/browse/vala/tree/codegen/valaccodecompiler.vala

Thanks,

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

Re: [Vala] GIO run as root Fail

[Al Thomas via vala-list]

On Tuesday, 24 October 2017, 16:08:09 BST, Edwin De La Cruz 
 wrote: 

> It was definitely not possible to run as root. I had to run as a user
> and it works as expected.
> Thanks to everyone for your replies.

GIO is using GVFS and the FUSE daemon. The FUSE daemon is reported not to be 
accessible from root:
https://wiki.gnome.org/Projects/gvfs/doc#FUSE_daemon
https://bugzilla.gnome.org/show_bug.cgi?id=560658

Maybe that is related.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] New test framework updates.

[Al Thomas via vala-list]

> On Sunday, 15 October 2017, 00:46:23 BST, Jason Martin  
> wrote: 
> It looks like the first echo -n problem is on line 222 in testrunner.sh

> if $VALAC $VALAFLAGS -o test$EXEEXT $([ -z "$PACKAGES" ] || echo $PACKAGES
> | xargs -n 1 echo -n " --pkg") main.vala &>log; then

> Unknown option -n

From the echo man page:" -n do not output the trailing newline
  -e enable interpretation of backslash escapes"
That sounds pretty much like printf. This appears to be a very good write 
up:https://unix.stackexchange.com/questions/65803/why-is-printf-better-than-echo
From what I can tell printf is more portable and now built in to most shells.

So I would suggest opening a report in bugzilla and submitting a patch with 
printf working on solaris and sunos. We can then take it from there.
All the best,
Al
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] default value is less accessible than method

[Al Thomas via vala-list]

> On Tuesday, 10 October 2017, 20:11:15 BST, Ondrej Tuma  
> wrote: 
> I have simple code (in attachment), when I try to compile, i got error:

> GLib.Object.vala:15.39-15.52:
> error: default value is less accessible than method `Node.add'
>     public Node add (uint direction = Direction.AUTO) {
                                      ^^
> Compilation failed: 1 error(s), 0 warning(s)

> What's wrong?

 You want:
public enum Direction {    LEFT,    RIGHT,    AUTO}
instead of:
enum Direction {    LEFT,    RIGHT,    AUTO}
Without an explicit access modifier the default is 'internal'.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] New Graphviz code (libgvc)

[Al Thomas via vala-list]

> On Sunday, 8 October 2017, 20:12:11 BST, Guido Trentalancia 
>  wrote: 

> I have noticed that vala version 0.38 has added code that depends on> the 
> Graphviz software package (libgvc dependency).

> would it be possible to make such support optional by a new option for the 
> configure script ?

Please see https://bugzilla.gnome.org/show_bug.cgi?id=787375

It looks like the license for Graphviz is now the Eclipse Public License, but 
the Common Public License in the past. See http://www.graphviz.org/Download.php
My own thinking is Vala should switch to a charts interface in valadoc and 
include a null implementation. This then allows the null or Graphviz 
implementation to be selectable. It also allows for an alternative 
implementation in the future. The valadoc charts implementation is used to 
create object hierarchy diagram as seen at valadoc.org. The current 
implementation can output these as SVG, PNG and also HTML image map. The HTML 
image map gives the tooltips that appear in the valadoc.org diagrams. So an 
alternative implementation is not that simple.
Regards,
Al
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Not Existing CCodeBaseModule in Vala context

[Al Thomas via vala-list]

> From: Sébastien Granjoux 
> Sent: Wednesday, August 30, 2017, 8:55:04 PM GMT+1
> Subject: [Vala] Not Existing CCodeBaseModule in Vala context

> With vala 0.38, I get the error:
>     error: The name `CCodeBaseModule' does not exist in the context of `Vala'
> on the following line
>   scope_prefix = Vala.CCodeBaseModule.get_ccode_lower_case_prefix (scope);

> I don't know much about Vala but this line looks valid to me. It is 
> working with Vala 0.36. I think the CCodeBaseModule comes from the vala 
> compiler itself, I imagine that it is always available in the Vala 
> namespace. How could I fix this code?

It is because of this change:
https://git.gnome.org/browse/vala/commit/?id=c9aa4716b2645af40080bd6523065e78fceba3b4

CCode and Codegen are internal to libvala. That allows internal refactoring of 
the codewithout breaking users of libvala. There will be on going work to 
reduce the size of theVala API. Ideally libvala clients would be internal to 
the Vala project and external users wouldmake use of those clients, e.g. valac 
and valadoc.
Please give details of your project and specific use case for 
get_ccode_lower_case_prefix ()
Regards,
Al
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Newbie help needed for Vala delegates/lambda expressions

[Al Thomas via vala-list]

> From: Manish Jain 
> Sent: Wednesday, August 30, 2017, 10:31:00 AM GMT+1
> Subject: [Vala] Newbie help needed for Vala delegates/lambda expressions

> After programming for a long time with C/C++, I am trying to get 
> comfortable with Vala for my GUI programming.

Hi, and welcome to Vala land.

> Here are 2 delegates I set up to add a couple of integers :
> delegate int _dg_add2(int a, int b);

> _dg_add2 f_add2(int a, int b)
> {
>     return () => a + b;
> }

> int c2 = f_add2(a, b);  //Problem here

> The compiler gives me the message : error: Assignment: Cannot convert 
> from `_dg_add2' to `int'. But then, a similar conversion was reached 
> successfully with the first call to f_add

> So what is wrong with my understanding ? Thanks for any help.

You are returning a function, not an integer. That is what the error messageis 
telling you. To evaluate the function, which does return an integer, you needto 
place parentheses after the function. So:
int c2 = f_add2(a, b);  //Problem here
should be:
int c2 = f_add2(a, b)();  //Problem almost gone
Your type signature (the delegate) is also wrong for the return function.So: 
delegate int _dg_add2(int a, int b);
should be:
delegate int _dg_add2();

That's because your lambda expression doesn't have any parameters.
Regards,

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

Re: [Vala] Potential Vala build system change (switch to Meson)

[Al Thomas via vala-list]

> On Thursday, August 17, 2017, 9:34:13 PM GMT+1, Dmitry Golovin 
>  wrote:

> As far as I know, Meson support building Vala code and it should not be too 
> difficult to change > the build system to Meson. Anyone working on it 
> already? Is there a bug open for build system > migration?
There is an unstable branch here: 
https://git.gnome.org/browse/vala/log/?h=wip%2Fmeson
You should definitely try it out. It is much much faster at building from a 
fresh start. About 15 seconds for Meson/Ninja compare to 2 and a half minutes 
with autotools on my system. The branch is unstable - there are forced pushes 
to it - so don't rely on it for contributing. It builds the binaries for Vala 
fine, but the test suite is still a work in progress. Getting the test suite 
working well would be a big improvement for the contributor experience to Vala. 
Maybe for 0.38. We'll see. There are also problems with generating VAPIs and 
other targets, but that is a lower priority.
There is also a tracking page on the wiki: 
https://wiki.gnome.org/Projects/Vala/DeveloperDocumentation/MesonAlthough I 
haven't updated it yet with the recent work by ricotz.
You should also note Meson 0.42 is out! This adds support for: - Genie - 
coloured diagnostics from valac 0.37.1+ (thanks Ben Iofel, MarvinW and Rico 
Tzschichholz) - VALAC and VAPIGEN set by environment variables
The approach to testing is the main problem at present. It would be nice to 
integrate the automatic test discovery from the valadate work along with TAP 
reporting and XFAIL tests into the Meson branch. That probably needs some 
significant patches to Meson.

Meson is giving a very nice Vala experience. With great speed from ninja and 
useful extensions such as gnome.compile_resources() and gnome.generate_gir(). 
So give it a whirl for your own projects too.

Al
___
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] Null Coalescing Assignment Operator

[Al Thomas via vala-list]

> From: Guillaume Poirier-Morency 
> Sent: Sunday, 28 May 2017, 16:59
> Subject: Re: [Vala] Null Coalescing Assignment Operator

> Le dimanche 28 mai 2017 à 10:20 +0200, Ulink a écrit :
> > > thing = thing ? create ();
> > 
> > I think you meant
> > 
> > thing = thing ?? create ();

> Yeah, my mistake! Evan actually pointed that out first on IRC.

> > Edward seems lazy and don't want to write "thing" two times ;-)

> What I think we need is an Elvis accessor to turn:

>C? c = null;
>var a = thing_a ();
> if (a != null) {
> var b = thing_b ();
> if (b != null) {
> c = thing_c ();
> }
> }

> into:


>var c = thing_a ()?.thing_b ()?.thing_c ();

I think it's better just to give your variables sensible defaults and
avoid the whole null things as much as possible. So use an empty string
for a customer without an email address and so on. Look up the computer
scientist Tony Hoare and why he thinks nulls were his billion dollar 

mistake! :)

I think the ?. notation is often referred to as the safe navigation operator.
As you say there is also the Elvis operator, ?:, when used as a binary
operator and ? : used as a ternary operator. And of course ?? used as a
null coalescing operator. If programmers aren't using this kind of symbolic
logic regularly it can be hard to recall precisely what is supposed to be
happening and read existing code. It's kind of like the combination of key
presses needed to exit vim when it suddenly pops up on a newly installed
Unix system. Take a look at this for a mildly amusing read:
https://stackoverflow.blog/2017/05/23/stack-overflow-helping-one-million-developers-exit-vim/

As far as the null safe navigation operator goes here are some interesting
counterpoints:
http://enterprisecraftsmanship.com/2015/05/11/3-misused-of-operator-in-c-6/

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

Re: [Vala] Use defined pathes inside a method

[Al Thomas via vala-list]

> From: Sascha Manns 
> Sent: Wednesday, 3 May 2017, 16:00
> Subject: Re: [Vala] Use defined pathes inside a method

> > interface and not the whole configuration object.
> I prepared that config.vala [1].

> can't used because of it itn't instancable. But how can i work with such
> pathes instead?

> Also i added a metod which imports the settings from the gsettings
> schema and connects this to its properties from the interface. Is the
> implementation usable in that case? It would be great, that the
> gsettings and the defined pathes are useable inside each other class.


An interface is an abstraction, so you need a configuration object that
implements the interface. Having one big interface that matches your
configuration object just duplicates your effort. The suggestion was
to break the interfaces into smaller parts so the configuration object
implements multiple interfaces. For a little more detail see:
https://martinfowler.com/bliki/HeaderInterface.html
https://martinfowler.com/bliki/RoleInterface.html

So you could have a FilePathsForSaving and a AuthorContactDetails interface
that are both implemented by your configuration object. When you come to
use them you only need a subset of the configuration object. So you could
have a method:
void save_my_work (Work work_object, FilePathsForSaving 
my_big_configuration_object) {...}

The advantage is that each method only needs a subset of the data and it
means you can feed alternative objects in, so long as they implement the
same interface. That could be useful for testing individual components of 

your application. So if you want to write a test of the save_my_work() command
then you can feed in paths in a temporary directory and check the relevant data
is saved without having to construct a whole configuration object, just the 
FilePathsForSaving.


An alternative would be to have smaller objects as fields of the configuration
object. So instead of PublisherSettings having:
public string firstname { get; set; }
public string surname { get; set; }
...

you could have:
public AuthorContactDetails author_contact_details;
and then the AuthorContactDetails object has properties for the name, etc.

Your GSettings method should probably take the configuration object as an
argument, e.g. :
void modify_configuration_from_gsettings (ref PublisherSettings 
my_big_configuration_object) {...}
this also gives you the flexibility to set the configuration from other user 
interfaces:
void modify_configuration_from_command_line (ref PublisherSettings 
my_big_configuration_object, ref unowned string[] args) {...}


If you need more ideas take a look at other projects, this is how Geary handles 
it:
https://git.gnome.org/browse/geary/tree/src/client/application/geary-config.vala

BTW, I don't think you want a new MainLoop in your GetGSettings function:
https://github.com/saigkill/gnome-publisher/blob/master/src/config.vala#L82

All the best,

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

Re: [Vala] Call to arms for an OpenSSL binding!

[Al Thomas via vala-list]

> From: "guillaumepoiriermore...@gmail.com" 
> Sent: Sunday, 23 April 2017, 20:22
> Subject: [Vala] Call to arms for an OpenSSL binding!


> I am working on merging all existing bindings for OpenSSL
> If you have anything, please consider sharing it so that I can include
> it .


In case you missed it, the mailing list message you link to has a follow
up message that has a link to:
https://bugzilla.gnome.org/show_bug.cgi?id=684446
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Use defined pathes inside a method

[Al Thomas via vala-list]

> From: Sascha Manns 
> Sent: Thursday, 20 April 2017, 16:08
> Subject: [Vala] Use defined pathes inside a method

> i have defined some stuff in my Defines class [1].

> What is a good way to use the contents of the properties inside a mathod

> or class?

I would create a single configuration object that implements multiple
interfaces. The interfaces allow settings to be grouped. So the single object is
passed around, but a specific interface is given as the type for the argument 
to 

a service object constructor. This also makes it easier to test a service
object because you need to pass a dummy configuration that only matches the 

interface and not the whole configuration object.

A few bookmarks I've collected over time:
https://softwareengineering.stackexchange.com/questions/114924/config-class-struct-pattern-or-anti-pattern-alternatives
https://lostechies.com/joshuaflanagan/2009/07/13/how-we-handle-application-configuration/
http://stackoverflow.com/questions/12302702/configuration-design-pattern-across-java-system
https://softwareengineering.stackexchange.com/questions/40313/is-a-single-config-object-a-bad-idea

You can have multiple interfaces with the same property name. So you can have 
quite small
interfaces for different use cases and not worry that the same property is 
being re-used.
When refactoring the interfaces I find it useful to adjust the interface 
definition and
then let the Vala compiler point out where the changes need to be made.

I'm curious if other people have a better approach.

All the best,

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

Re: [Vala] Gschema: failed to parse value

[Al Thomas via vala-list]

> From: Sascha Manns 
> Sent: Wednesday, 19 April 2017, 20:35
> Subject: Re: [Vala] Gschema: failed to parse  value

> i have looked in other projects on git, and found out, that a empty

> default element is available by using double quotes.

Hmmm, this has caught out other people too:
https://rm5248.com/gsettings/

The problem to do with properties is because you are assigning the body
of the property. That's not how is should be done. So in 

src/core/create_publication_core.vala the property:


private string entity_file_local = {get {_filename = publication_title + 
entity_file_suffix; return _filename;}}

should be:

private string entity_file_local {get {_filename = publication_title + 
entity_file_suffix; return _filename;}}

Also, if you haven't already figured it out Path.DIR_SEPARATOR needs to be cast 
to a string:


private string project_dir {get {_path = target_dir + 
(string)Path.DIR_SEPARATOR + publication_title + (string)Path.DIR_SEPARATOR + 
create_language; return _path;}}
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Handling strings

[Al Thomas via vala-list]

> From: Sascha Manns 
> Sent: Wednesday, 19 April 2017, 15:10
> Subject: Re: [Vala] Handling strings

> I tried it out:
> private string _filename;
> private string _path;
> private string entity_file_suffix = ".ent";
> private string entity_file_local = {get {_filename =
> publication_title + entity_file_suffix; return _filename;}}

> But got the same compiler error:
> core/create_publication_core.vala:52.42-52.42: error: syntax error,
> expected `}'
> private string entity_file_local = {get {_filename =
> publication_title + entity_file_suffix; return _filename;}}

> ^

This compiles for me:

void main () {
 var a = new Test ();
  print (@"Path: $(a.path)\n");
}

class Test {
 private string ext = ".ext";
  private string text = "text";
  private string _backing_store_for_filename;
  private string filename {get {_backing_store_for_filename =
  text + ext; return _backing_store_for_filename;}}
  private string _path;
  public string path {get {_path = "/full/path/" + filename; return _path;}}
}

I'm not sure what you are trying to achieve in your object design here.
If publication_title is only set at construction time you can set these
fields in the constructor, but if publication_title can be changed throughout
the running of the program then I don't see a problem with a property that
calculates the path. The other option is to have a method that returns the
path name from the given fields.

I have tried compiling what you have uploaded to 
https://github.com/saigkill/gnome-publisher
Unfortunately I get an error:

git.mk: Generating .gitignore
make  all-recursive
make[1]: Entering directory '/srv/random-builds/gnome-publisher'
Making all in data
make[2]: Entering directory '/srv/random-builds/gnome-publisher/data'
GEN  org.gnome.Publisher.desktop
/usr/bin/msgfmt: error while opening 
"data/org.gnome.Publisher.appdata.xml.in.po" for reading: No such file or 
directory
Makefile:627: recipe for target 'org.gnome.Publisher.desktop' failed

It was pointed out on IRC that the callback in 
https://github.com/saigkill/gnome-publisher/blob/master/src/ui/build_publication.vala
should be functions, not properties. So:

[GtkCallback]
private void on_btnBuild_clicked {
/* tbf */
}


should be:

[GtkCallback]
private void on_btnBuild_clicked (Button button) {
/* tbf */
}

For example see:
https://blogs.gnome.org/tvb/2013/05/29/composite-templates-lands-in-vala/
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Handling strings

[Al Thomas via vala-list]

> From: Sascha Manns 
> Sent: Wednesday, 19 April 2017, 13:42
> Subject: Re: [Vala] Handling strings

> I tried it out in that way:
> // Constants used by create_publication_core
> private string _filename;
> private string _path;
> private const string REV_HIST = "Revision_History.xml";
> private const string AUTHOR_GROUP = "Author_Group.xml";
> private const string ENTITY_FILE_SUFFIX = ".ent";
> private const string DIRECTORY_SEPARATOR_CHAR = "/";
> private const string ENTITY_FILE_LOCAL = {get {_filename =
> publication_title + ENTITY_FILE_SUFFIX; return _filename;}}

> The compiler says:
> core/create_publication_core.vala:51.48-51.48: error: syntax error,
> expected `}'
> private const string ENTITY_FILE_LOCAL = {get {_filename =
> publication_title + ENTITY_FILE_SUFFIX; return _filename;}}
  ^

> Maybe i miss anything?

You've added 'const'. It should be:

private string ENTITY_FILE_LOCAL = {get {_filename =
 publication_title + ENTITY_FILE_SUFFIX; return _filename;}}

Constants do not change during the running of the program. They can, however,
be concatenated at compile time. So you could do:
private const string PATH = DIRECTORY_SEPARATOR_CHAR + AUTHOR_GROUP;

If the field is changeable during the running of the program then it shouldn't
be marked as 'const'.

By the way, GLib has a constant already for directory separator:
https://valadoc.org/glib-2.0/GLib.Path.DIR_SEPARATOR.html
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Handling strings

[Al Thomas via vala-list]

> From: Sascha Manns 
> Sent: Wednesday, 19 April 2017, 12:43
> Subject: [Vala] Handling strings

> I'm getting the information that the access to instance member is denied.


> How can i concat strings in Vala?

Concatenation of variables is done at run time, so you either need to
make the strings constant or use properties to allow the concatenation to
occur at run time:

void main () {
 var a = new Test ();
  print (@"Extension: $(Test.ext)\n");
  print (@"Filename: $(a.filename)\n");
  print (@"Path: $(a.path)\n");
}

class Test {
  public const string ext = ".ext";
  private string _filename;
  public string filename {get {_filename = "test" + ext; return _filename;}}
  private string _path;
  public string path {get {_path = "/full/path/" + filename; return _path;}}
}
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Gtk.FileChooserButton

[Al Thomas via vala-list]

> From: Sascha Manns 

> Sent: Monday, 10 April 2017, 18:35
> Subject: [Vala] Gtk.FileChooserButton

> In Vala i tried to port it:

> public string revupdfolder { get; set; }
> [Gtk.Child] private Gtk.FileChooserButton fileChooserRevUpd;
> private void on_fileChooserRevUpd_file_set () {
> revupdfolder = fileChooserRevUpd.current_folder;
> }

> But it looks like there is no way to get the current folder like

> Gtk-Sharp it does, or?

It is likely to be:
revupdfolder = fileChooserRevUpd.get_current_folder ();

Valadoc shows that FileChooserButton implements FileChooser:
https://valadoc.org/gtk+-3.0/Gtk.FileChooserButton.html
On that Valadoc page there is a sub-section "All known members
inherited from interface Gtk.FileChooser". One of those is the
method get_current_folder (). It doesn't look like there is a
similar property.

Regards,

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

Re: [Vala] cannot locate ITS rules for org.gnome.Publisher.appdata.xml.in

[Al Thomas via vala-list]

> From: Sascha Manns 
> Sent: Sunday, 9 April 2017, 11:02
> Subject: [Vala] cannot locate ITS rules for org.gnome.Publisher.appdata.xml.in

> After ./autogen.sh and make i'm getting:

> sascha@linux-ktr9:~/Projects/gnome-publisher1/data> make
>   GEN  org.gnome.Publisher.appdata.xml
> /usr/bin/msgfmt: cannot locate ITS rules for
> org.gnome.Publisher.appdata.xml.in


msgfmt is a gettext program and ITS appears to stand for Internationalization 
Tag Set.
>From the gettext manual "Marking translatable strings in an XML file is done 
>through 

a separate "rule" file, making use of the Internationalization Tag Set 
standard" - see 

https://www.gnu.org/software/gettext/manual/html_node/Preparing-ITS-Rules.html

So I would guess your <_p> tags in 

https://github.com/saigkill/gnome-publisher/blob/master/data/org.gnome.Publisher.appdata.xml.in
might need some metadata.

You might get a few more clues from here:
https://github.com/mesonbuild/meson/issues/1565

Regards,

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

Re: [Vala] Compact class with an unusual (in GLib terms) constructor

[Al Thomas via vala-list]

> From: Gergely Polonkai 
> Sent: Wednesday, 5 April 2017, 16:39
> Subject: [Vala] Compact class with an unusual (in GLib terms) constructor

> libjwt[1] has a strange constructor in GLib terms:

> int jwt_new(jwt_t **jwt);

> It returns 0 on success (like many C functions) or any valid errno on
> failure. I made the following binding for now:

> [CCode (cname = "jwt_new")]
> public static int create(out JWT jwt);

> Is there a better way to do this?


These kind of constructors are fairly common in the C world and I
think there should be a more Valaesque way of binding them using
a Vala constructor that throws an error.

This is only a theory and may not work. I will try playing around
with it myself at some time, but the approach I have in mind is:

1. Bind errno as an errordomain instead of an enum, not tried to see
   if that is possible. Also be aware enums can't have values given
   in the VAPI. The values have to be defined externally in the C header


2. Bind jwt_new as a private function

3. A function in a VAPI can have a body, so create a Vala constructor
   as for a normal class that can throw the errordomain


4. Then add logic to the constructor that checks the return value
   of jwt_new and either sets this to the instance or throws the 

   errordomain

Good luck!

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

Re: [Vala] Writing binding for non-GLib library using FILE *

[Al Thomas via vala-list]

> From: Gergely Polonkai 
> Sent: Wednesday, 5 April 2017, 16:20
> Subject: [Vala] Writing binding for non-GLib library using FILE *

> I’m trying to create a binding for libjwt, and one of its functions use
> FILE * pointer to save a JWT token to a file. Reading [2] makes me think I
> can use FileStream here, but vala complains:


> libjwt.vapi:77.28-77.37: error: The type name `FileStream' could not be
> found


FileStream is part of the GLib namespace. I think you either need to make
that explicit, so GLib.FileStream. Alternatively you can include the
namespace in your VAPI by adding:

using GLib;

at the beginning of the VAPI.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Button not visible

[Al Thomas via vala-list]

> From: Sascha Manns 
> Sent: Wednesday, 5 April 2017, 11:57
> Subject: Re: [Vala] Button not visible

> To work with signals i like to use *.clicked.connect. So i tried
> box_pack_start (Gtk.Button revision = new Gtk.Button.with_label ("Add
> new Revision"));


Now you have a grasp of the basic concepts - top level window, layout
containers, widgets and signals - you might want to look at
GTK+ composite templates in Vala.

You write a GtkBuildable UI file (XML in an editor or using Glade).
This lets you group your windows/dialogs with their child widgets and
identify the signals. You then use GResource to embed the UI files and
the [GtkTemplate], [GtkChild] and [GtkCallback] attributes in Vala to
wire up the UI code. For an example see:

https://mail.gnome.org/archives/vala-list/2016-June/msg00075.html

Regards,

Al
___
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++

[Al Thomas via vala-list]

> From: Alessandro Pellizzari 
> 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

[Vala] Writing DLLs, was Re: Starting with Vala

[Al Thomas via vala-list]

> From: "r...@no-log.org" 
> Cc: vala-list 
> Sent: Tuesday, 4 April 2017, 8:41
> Subject: Re: [Vala] Starting with Vala

> You could take a look to "check_fs" which is better and my lastest 

> "graph_map".

I really like what you have done here:

[CCode (cname="G_MODULE_EXPORT event_save_bitmap")]
public bool event_save_bitmap() { ... }

in:
https://github.com/Raumy/graphmap/blob/master/src/graphmap.vala

Does this allow you to produce a Windows DLL? The G_MODULE_EXPORT
should add __declspec(dllexport) on the Windows platform. As per:

https://developer.gnome.org/glib/stable/glib-Dynamic-Loading-of-Modules.html#G-MODULE-EXPORT:CAPS

Thanks,

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

Re: [Vala] Gtk.ProgressBar

[Al Thomas via vala-list]

> - Original Message -

> From: "webie...@gmail.com" 
> Sent: Saturday, 11 March 2017, 18:55
> Subject: [Vala] Gtk.ProgressBar

> I explain: From a FileChooserDialog is selected and opens the vCard
> file, and if it is too large it takes a while to analyze and import the
> contacts. At that time I want to open a window or dialog (without
> buttons) with a Gtk.ProgressBar that shows the progress of the
> operation. And when the operation is finished, the window / dialog is
> automatically closed.


Ideally you would use asynchronous, event based programming in Vala/Genie.
So something like:
1. Write an asynchronous process vCard function that runs in a background
   thread. I've not figured out the best way of doing this, but look at the
   async keyword in Vala and https://developer.gnome.org/gio/stable/ch02.html
2. Write an "app_paused" object that stores two states. The first state is
   for a Timeout source (https://valadoc.org/glib-2.0/GLib.Timeout.html) that
   will then complete and then the second state is showing a spinner dialog.
   This needs a cancel method to cancel the timer or close the dialog.
   For a progress bar you would need some kind of signalling, so more complex.
3. You combine these two by starting the "app_paused" object then call
   yield process_vCard(). When the processing is finished the code after the
   yield should call the app_paused cancel method.
It would be nice to find some good examples of this.

> At the moment I have not known how to solve it, and I am using
> Notify.Notification to report the process, but this requires a new
> dependency (libnotify) and I prefer to use few dependencies.


>From https://wiki.gnome.org/HowDoI/GNotification:
"As of GLib 2.39, it is no longer necessary to link against libnotify to 

create notifications in your application, GIO now provides an API for it: 

GNotification."

So create a Notification (https://valadoc.org/gio-2.0/GLib.Notification.html)
and send it through you GApplication send_notification method (
https://valadoc.org/gio-2.0/GLib.Application.send_notification.html )

Good luck with it,

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

Re: [Vala] Errors trying to re-generate poppler-glib.vapi

[Al Thomas via vala-list]

> - Original Message -

> From: Francesco Poli 
> Sent: Wednesday, 8 March 2017, 23:07
> Subject: [Vala] Errors trying to re-generate poppler-glib.vapi

> I am trying to re-generate poppler-glib.vapi from Poppler-0.18.gir with the 
> following command-line:

>   $ vapigen --vapidir /usr/share/vala-0.34/vapi/ \
> --pkg cairo --pkg gio-2.0 --library poppler-glib \
> /usr/share/gir-1.0/Poppler-0.18.gir

> Unfortunately, I get the following errors:

>  Poppler-0.18.gir:5044.71-5044.71: error: The type name 
> `Poppler.Backend.CAIRO.Surface' could not be found
> 


I'm not sure this will solve your exact problem, but there is some 

metadata that you should reference with your vapigen command:

https://git.gnome.org/browse/vala/tree/vapi/metadata/Poppler-0.18.metadata?h=0.34

Hope that helps,

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

Re: [Vala] Resource API inconsistent

[Al Thomas via vala-list]

> - Original Message -
> From: Günther Wutz 
> Subject: Re: [Vala] Resource API inconsistent

> Works now like a charm! The only bummer, there is no simple Method to
> read a resource in as string - have to use a InputStream because
> FileUtils doesn't work with resources-uri's.


If it's any easier you can cast Bytes to a string:

Bytes _template_resource = resources_lookup_data( 
"/templates/boot/fstab.mustache", ResourceLookupFlags.NONE );
string _template = (string)_template_resource.get_data();
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Resource API inconsistent

[Al Thomas via vala-list]

> - Original Message -

> From: Günther Wutz 
> Sent: Sunday, 5 February 2017, 11:23
> Subject: [Vala] Resource API inconsistent

> if i want to lookup resource data via the glib API, i would normally
> use g_resources_open_stream. This function call doesn't need a

> object. 


The documentation at 
https://developer.gnome.org/gio/stable/GResource.html#g-resource-open-stream 
gives the function signature as:


GInputStream *
g_resource_open_stream (GResource *resource,
const char *path,
GResourceLookupFlags lookup_flags,
GError **error);

So that looks like it needs a GResource object to me.


> If its registered beforehand i can use it globally in my
> application. 


If you use glib-compile-resources to produce a C file and then compile
the C file into your Vala program the resources are registered globally
as static resources. If you are doing that then you could use:
https://valadoc.org/gio-2.0/GLib.resources_open_stream.html

I'm not finding that static function documented anywhere in the GNOME 
documentation.
The closest I could find is:
https://developer.gnome.org/gio/stable/GResource.html#GStaticResource
This says "GStaticResource is an opaque data structure and can only be 

accessed using the following functions", but doesn't list these functions.
This could be an omission. Maybe because the resource uri scheme is used by 
most people.
For example using a uri of "resource:templates/boot/fstab.mustache" 

to open the InputStream.


I've use the static method resources_lookup_data() in Vala/Genie, but 

not tried the resource URI method.


> In contrast vala needs a Resource object to use this> function, which seems 
> wrong. Am i missing something here?


The method in Vala matches the g_resource_open_stream
C API. This needs a GResource object as shown above.

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

Re: [Vala] How to check if string is empty

[Al Thomas via vala-list]

- Original Message -
> From: Alexandre Oliveira 
> Sent: Monday, 16 January 2017, 19:27
> Subject: Re: [Vala] How to check if string is empty

> I tried this in my method, even replacing 'string' for 'string?', but I
> still get the same message in my terminal.


> What is your suggestion to suppress these messages?

Don't suppress them, they are warnings from the runtime that things are wrong.
Ideally Vala would have warned you when the program was compiled, but
the valac switch --enable-experimental-non-null is not there yet.

> On 16/01/2017 17:23, Guillaume Poirier-Morency wrote:

> > You should test for nullity before addressing the string.

> > 
> > return str == null || str.length == 0;
> > 
> > If you expect the string to be potentially 'null', use the 'string?'
> > type instead.


This is sound advice. Works for me:

void main () {
string? a = null;
if (is_empty (a)) {
print ("string is empty\n");
}
a = "\0";
if (is_empty (a)) {
print ("string is empty\n");
}
}

bool is_empty(string? str) {
return str == null || str == "";
}


Really you should be thinking about avoiding nulls. As C.A.R.Hoare said "I call 
it my billion-dollar mistake. It was the invention of the null reference in 
1965. This has led to innumerable errors, vulnerabilities, and system crashes, 
which have probably caused a billion dollars of pain and damage in the last 
forty years." 
[https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions]
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Stop Gtk.Spinner?

[Al Thomas via vala-list]

- Original Message -

> From: "webie...@gmail.com" 
> Sent: Monday, 16 January 2017, 11:35
> Subject: [Vala] Stop Gtk.Spinner?

> how can I stop this widget in Genie when I press a key?


You've not fully understood the concept of scope.
In your constructor, the line:

var spinner = new Gtk.Spinner()

creates a new variable, spinner, in the scope of your constructor.
Remove the 'var' keyword and it will work. It will use the spinner
variable declared in the scope of the class and so it will be available
in your 'tecla' class method.

I've also added the underscore to make the variable private, so it is
only visible in the scope of the class and not to any part of the program
that instantiates the class.


// compila con valac --pkg gtk+-3.0 nombre_archivo.gs
[indent=4]
uses Gtk

init
Gtk.init( ref args )
var test = new TestVentana()
test.show_all()
Gtk.main()

class TestVentana:Window

_spinner: Gtk.Spinner

construct()
title = "Ejemplo Gtk"
default_height = 300
default_width = 300
border_width = 50
window_position = WindowPosition.CENTER
destroy.connect( Gtk.main_quit )

_spinner = new Gtk.Spinner()
_spinner.active = true
add( _spinner )

key_press_event.connect( tecla )

def tecla( key:Gdk.EventKey ):bool
_spinner.active = false
return true
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Genie Wiki and logo

[Al Thomas via vala-list]

> - Original Message -
> From: "webie...@gmail.com" 
> Sent: Monday, 2 January 2017, 17:18
> Subject: Re: [Vala] Genie Wiki and logo

> But then, is Genie dead? Is it better to learn Vala and forget Genie?


Genie has a smaller user base. If you have a GitHub account you can
find other Genie projects with this query:

https://github.com/search?utf8=%E2%9C%93=extension%3Ags+indent+OR+def+OR+uses+OR+construct+NOT+package+NOT+function=Code=searchresults

That query is part of getting Genie recognised on GitHub:
https://github.com/github/linguist/pull/3396

A recent project that runs on Windows 10 and uses SDL2:
https://github.com/darkoverlordofdata/shmupwarz-vala

The commit log for the Genie scanner and parser:
https://git.gnome.org/browse/vala/log/vala/valageniescanner.vala
https://git.gnome.org/browse/vala/log/vala/valagenieparser.vala

So I don't think you can say Genie is "dead". It would depend on how
optimistic you are, whether it is worth sticking with Genie or learning Vala.

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

Re: [Vala] xgettext and genie

[Al Thomas via vala-list]

> - Original Message -

> From: rastersoft 
> Sent: Friday, 16 December 2016, 20:09
> Subject: [Vala] xgettext and genie



> An user asked about using autovala with genie, so I'm working on adding
> support for it.

Sounds good, thanks.

> My question is: how can I extract the translatable strings with xgettext
> from a genie source file? xgettext has support for vala, but the manpage
> says nothing about genie, and when trying, it tries with C syntax...


You could try:
xgettext --language=Vala
This picks up:
print _( "simple translation sample" )

print dgettext( null, "simple translation sample" )

print( _( "simple translation sample" ))
print( dgettext( null, "simple translation sample" ))
in Genie.

You could also try:
xgettext --language=Python
if there are any problems with white space parsing, although I'm not sure that 
is used. Genie doesn't use the # for comments though.


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

[Vala] Valadoc.org is fully operational again

[Al Thomas via vala-list]

In case anyone hadn't noticed valadoc.org is fully working again.

Thanks to Elementary OS [1] who are hosting the site [2].

Development is now being done at https://github.com/valadoc and includes a 
number of recent updates, including better URIs for bookmarking and external 
linking. There is also work started on changing valadoc.org to use Valum [3].

The content is up to date. With Valum 0.3 [4] and libcolumbus [5] recently 
being added.

Thanks should also go out to Chris Daley of Valadate project for hosting a 
mirror ( http://valadoc.valadate.org ) and the company RooJSolutions ( 
http://valadoc.roojs.com ) for also hosting a mirror while things got back to 
normal.

[1] - https://elementary.io/
[2] - http://blog.elementary.io/post/152967321211/were-now-hosting-valadocorg
[3] - https://github.com/Valadoc/valadoc-org/pull/40
[4] - https://arteymix.github.io/valum/2016/11/11/announcing-valum-0-3.html
[5] - 
http://voices.canonical.com/jussi.pakkanen/2012/12/03/introducing-libcolumbus-a-fast-online-approximate-matching-library/
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list