Re: [Vala] State of the Vala union

[Nor Jaidi Tuah]

> Well, I suppose I have higher requirements than they have. From a
> production-ready
> compiler I would expect
> – no (or at best very obscure) type errors to get through
> – no compiler crashes
> – no broken code generated

Possibly you have eliminated every compiler :-)

Nice day
Nor Jaidi Tuah




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

Re: [Vala] State of the Vala union

[Matthias Berndt]

Hi Al,

thanks for responding!

> I guess it depends on what you are producing. Some one has just stated on 
> this list
> they have been part of a 200K lines of code project. They must have thought 
> it was
> production ready.
Well, I suppose I have higher requirements than they have. From a 
production-ready
compiler I would expect
– no (or at best very obscure) type errors to get through
– no compiler crashes
– no broken code generated
I don't think these are unreasonable criteria, yet valac fails all of them.

> Some of these have been addressed with the 0.36.0 release.
Yes, some. And more remain.

> There has been a lot of bug fixing over the last six months so it can be
> hard to keep up. As far as generics I think the top priority for any 1.0
> release should be handling simply type structs by auto boxing:
> https://bugzilla.gnome.org/show_bug.cgi?id=774713
My problem is that type checking for generics is unsound because of covariance,
and as a response you point out another bug that is also not fixed yet. I'm
sorry, but I don't see how that addresses the issue I've raised?? And the
deeper issue is that this unsoundness problem is probably close to impossible
to fix without breaking large amounts of user code, the current maintainers
have really painted themselves into a corner here.
It is certainly impossible to fix if there is no way to get hold of the
current maintainers to actually discuss issues and possible solutions.

> As far as increased type checking then some of the issues that came up with
> interfaces may also be relevant:
> https://bugzilla.gnome.org/show_bug.cgi?id=779038
> https://bugzilla.gnome.org/show_bug.cgi?id=686542
So… more bugs from 2012?

> Some one did recently have a go at an AST printer if that was any help:
> https://git.gnome.org/browse/vala/log/?h=wip%2Fbaedert%2Fnullable
> 
> Some one else had a go at using LLVM as a back end:
> https://github.com/chebizarro/vala/commits/master
Cool. Last commit from four months ago.

> > – autotools. In 2017.
> 
> It may surprise you to learn another developer has tried switching to Meson:
> https://git.gnome.org/browse/vala/log/?h=wip%2Fmeson
And here's the next problem with Vala development: it's basically impossible
to know who's working on what. vala-devel-list seems dead. An open source
project cannot attract contributors like that, can it?

> Seriously?
Absolutely.

> People are developing tools for Vala. Jump to definition in Vim?
> Take a look at:
> https://wiki.gnome.org/Projects/Vala/Vim#Jump_to_Definition
> Auto completion in Atom? Take a look at a nice screenshot:
> https://atom.io/packages/valhalla
So I'm supposed to switch between two editors whenever I need one or the other?
You're kidding, right?

> There is a wiki page for tools:
> https://wiki.gnome.org/Projects/Vala/Tools
> These are recent contributions, but they will only improve further if people
> want to contribute.
I'm talking about the status quo and why Vala is not fun to hack with. If you 
want
to convince me that the tooling isn't so bad, pointing to a Wiki page won't do 
it.
Name one (!) editor that is free software and supports basics like jump to 
definition
*and* code completion and doesn't crash all the time. Really, I've tried a 
bunch of
them. GNOME Builder made the best impression, except it invariably crashed 
within
seconds when trying to edit the valac source code (I think it actually crashed 
in
libvala, which kinda confirms my point about the compiler not being production
ready).

> Hmm, focus on the negative. A slightly more positive take:
> https://blogs.gnome.org/mcatanzaro/2017/02/19/on-problems-with-vala/
To be honest that looks pretty bleak to me as well. Quotes like “I can 
confidently
say that Vala has more bugs than any other programming language you might be
considering using for GNOME development.” really say it all.
And you know what? The bugs aren't even the issue, bugs can be fixed. The issue 
is
that despite the activity you pointed to, I don't see people actually getting 
patches
merged into the comiler. And I also see a compiler that is based on a lot of 
mutable
state and side effects, that doesn't use best practices (e. g. many places use 
getters
and setters rather than properties) and that suffers from Vala's shortcoming as 
a 
language (e. g. defining simple model classes is a pain).

> Would map, filter, flat_map not be the Gee.Traversable interface?
> https://valadoc.org/gee-0.8/Gee.Traversable.html
Right, I missed that, essentially due to bad tooling I would argue.
But now that I know about the methods on Traversable, I'd like to point out 
they're
pretty useless too. Calling map or flat_map on a List yields an Iterator, which 
is
useless when I need a List. And it's quite hard to do much better, because Vala 
doesn't
support higher kinded types, that is, type parameters that can in turn take type
parameters. That's another flaw in the language design.

> That would be nice. Immutability is important. Some work with 

[Vala] Radio-Button Signals

[Sascha Manns]

Hello list,

I have a GtkBox with three childs: a label and two GtkRadioButtons. If a
user chooses one of them, what kind of signal will be sent? The
group-changed?

Greetings Sascha

-- 
Sascha Manns
Maifeldstraße 10
56727 Mayen

P: +49-2651-4014045
W: http://saigkill.tuxfamily.org




signature.asc
Description: OpenPGP digital signature
___
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

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

[Gergely Polonkai]

Hello,

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?

Best,
Gergely
___
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

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

[Gergely Polonkai]

Hello,

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

As I don’t need that functionality right now I skipped it, but it would be
nice to make the binding generally available, so the question is: what is
the correct binding such a function?

int jwt_dump_fp(jwt_t *jwt, FILE *fp, int pretty);

Best,
Gergely


[1] https://github.com/benmcollins/libjwt
[2]
https://wiki.gnome.org/Projects/Vala/LegacyBindings#Out_and_Reference_Parameters_and_Return_Values
___
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] Button not visible

[Ulink]

> 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"));
> It looks like this isn't possible. What can i do?

Move revision outside from the box_pack_start() to access it from
outside, e.g. (not tested):

var revision = new Gtk.Button.with_label ("Add new Revision");
revision.clicked.connect(() => {
   revision.label="You cowardly clicked me!";
});
box.pack_start(revision);


P.S.: You know "using Gtk;" on top of your source file? This avoids most
of (not all) the "Gtk." stuff.

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