Am 19.05.2015 09:19, schrieb Christian Stroetmann:
On the 19th of May 2015 08:33, Pekka Paalanen wrote:
On Mon, 18 May 2015 19:23:20 -0700
Bryce Harringtonbr...@osg.samsung.com wrote:
On Sat, May 02, 2015 at 11:52:22PM +0200, Auke Booij wrote:
On 19 April 2015 at 14:51, Jeroen
On Sat, May 02, 2015 at 11:52:22PM +0200, Auke Booij wrote:
On 19 April 2015 at 14:51, Jeroen Bollen jbin...@gmail.com wrote:
Hello,
It seems like this discussion died off. Currently there is no way to tell,
from the Wayland XML specification whether an argument is a bitfield, or
On 19 April 2015 at 14:51, Jeroen Bollen jbin...@gmail.com wrote:
Hello,
It seems like this discussion died off. Currently there is no way to tell,
from the Wayland XML specification whether an argument is a bitfield, or
whether the argument takes an enum and what enum this is.
I am
About the 2 ways of adding an enum:
The user can always specify an error handler to handle unknown values. The
error handle can then handle the error value, or unknown value.
On Mon, 27 Apr 2015 09:05 Pekka Paalanen ppaala...@gmail.com wrote:
On Sat, 25 Apr 2015 14:11:32 +
Jeroen Bollen
On Sat, 25 Apr 2015 14:11:32 +
Jeroen Bollen jbin...@gmail.com wrote:
I think that totally depends on how the interface is specified. This
applies only to one of the two ways an enum can grow.
What other way can it grow? It can only grow bigger. If the application
isn't aware of new
On 21 Apr 2015 09:18, Pekka Paalanen ppaala...@gmail.com wrote:
Two things I came up with in the IRC discussion was that only arg
types of int an uint are eligible for enums, and only uint for
bitfields. I think wayland-scanner should enforce that.
I just realised another aspect of this. Can a
On Mon, 27 Apr 2015 15:49:27 +0300
Pekka Paalanen ppaala...@gmail.com wrote:
In the end, all I care is about the definition of the new attributes
related to enum. If you really want to write a generator that can break
the build of other people, you can.
I would just want the definition of
On 27 April 2015 at 14:49, Pekka Paalanen ppaala...@gmail.com wrote:
On Mon, 27 Apr 2015 13:26:39 +0200
Auke Booij a...@tulcod.com wrote:
Apologies for my lack of responses, I have been abroad for a few days.
On 23 April 2015 at 10:38, Pekka Paalanen ppaala...@gmail.com wrote:
This is a
Apologies for my lack of responses, I have been abroad for a few days.
On 23 April 2015 at 10:38, Pekka Paalanen ppaala...@gmail.com wrote:
This is a sort of sanity condition on being a bitfield: it does not
require all combinations are valid, but it also distinguishes it from
a regular enum.
In fact, I am still
a bit confused why an API breakage in these early years of wayland is
considered such a big deal, compared with a daily struggle of not
having sufficient typing information.
Same here
To pq:
If an request specifies how unknown enum values should be handled, it just
On 04/27/2015 12:05 AM, Pekka Paalanen wrote:
- From the first definition of an interface, specify how unknown values
should be handled. Otherwise users do not expect unknown values to
appear.
The latter case is where you do not want an automatic always-on warning
or error.
This is no
I think that totally depends on how the interface is specified. This
applies only to one of the two ways an enum can grow.
What other way can it grow? It can only grow bigger. If the application
isn't aware of new values added, it should output a warning or an error.
On Fri, 24 Apr 2015 22:05
On Thu, 23 Apr 2015 10:44:50 -0700
Bill Spitzak spit...@gmail.com wrote:
On 04/22/2015 11:38 PM, Pekka Paalanen wrote:
Given this and that they must not affect codegen, what are the remaining
differences between enums and bitfields? Enum can be an int, but a
bitfield cannot? Is it worth
On Thu, 23 Apr 2015 14:45:32 +
Jeroen Bollen jbin...@gmail.com wrote:
Hello,
I do think that docenum and enum should be split up. I don't really get the
purpose of docenum though. Even if an enum can be extended, that extension
would technically be an extension to the protocol, would it
Since all the codegen packages that want to use this enum attribute have
not been written yet I don't think back-compatibility is an issue. They
are not using uint because they do not exist yet!
The C codegen can continue to ignore the enum, or use it in a way that
does not break code that
Hello,
I do think that docenum and enum should be split up. I don't really get the
purpose of docenum though. Even if an enum can be extended, that extension
would technically be an extension to the protocol, would it not?
Completeness of enums is information that can be encoded in strongly
On 04/22/2015 11:49 PM, Pekka Paalanen wrote:
Allowing fully qualified names is another thing. Should we allow it? Is
it good practice? Is it useful? How would the fully qualitified names
look like?
Even if it's not used for codegen, you need it for docgen if you want
to be able to reference
Using enum=interfacename.enumname would probably work. The
interfacename. is optional if you are describing a method on the same
interface. Another possibility is to just add interface=interfacename
to the argument along with enum=enumname.
The second possibility wouldn't work for bitfields
(yes the language binding could prevent this, but programmers writing
direct Wayland api are already wading into dangerous waters and can
probably be trusted to do this correctly. So for now I don't think there
is any need for a strict control).
I do not quite agree with this. Yes, they
I think there may be some confusion about how this would be used by a
language binding, and why bitmap is necessary, and also why it has to be
on the enumeration.
Imagine an interface called Widget, and it has two methods
set_type(Type) and set_flags(Flags). set_type takes an enumeration
On 04/23/2015 11:28 AM, Jeroen Bollen wrote:
Using enum=interfacename.enumname would probably work. The
interfacename. is optional if you are describing a method on the same
interface. Another possibility is to just add interface=interfacename
to the argument along with enum=enumname.
On Wed, 22 Apr 2015 08:38:22 -0700
Bill Spitzak spit...@gmail.com wrote:
On 04/21/2015 11:34 PM, Pekka Paalanen wrote:
I also think this discussion is going off-topic. You wanted to add
annotations to the XML, so you could find out about enum and bitfield
arguments, so let's keep to
On Wed, 22 Apr 2015 11:47:51 +0200
Auke Booij a...@tulcod.com wrote:
On 22 April 2015 at 08:34, Pekka Paalanen ppaala...@gmail.com wrote:
I also think this discussion is going off-topic. You wanted to add
annotations to the XML, so you could find out about enum and bitfield
arguments, so
On Thu, 23 Apr 2015 10:17:12 +0200
Auke Booij a...@tulcod.com wrote:
On 23 April 2015 at 08:38, Pekka Paalanen ppaala...@gmail.com wrote:
On Wed, 22 Apr 2015 11:47:51 +0200
Auke Booij a...@tulcod.com wrote:
On 22 April 2015 at 08:34, Pekka Paalanen ppaala...@gmail.com wrote:
I also
On 23 April 2015 at 08:38, Pekka Paalanen ppaala...@gmail.com wrote:
On Wed, 22 Apr 2015 11:47:51 +0200
Auke Booij a...@tulcod.com wrote:
On 22 April 2015 at 08:34, Pekka Paalanen ppaala...@gmail.com wrote:
I also think this discussion is going off-topic. You wanted to add
annotations to
On Tue, 21 Apr 2015 16:32:40 +
Jeroen Bollen jbin...@gmail.com wrote:
I think I have thought out a solution.
The scanner should be able to parse multiple specification files. There
would be the default wayland.xml, and for example a gnome.xml, which is an
extension to the wayland.xml.
I think this looks like the correct patch.
Only correction is that I would put the enum right after the type=int
consistently. Some of your cases you put the summary between them.
On 04/19/2015 01:30 PM, Auke Booij wrote:
On 19 April 2015 at 14:51, Jeroen Bollen jbin...@gmail.com wrote:
On 22 April 2015 at 08:34, Pekka Paalanen ppaala...@gmail.com wrote:
I also think this discussion is going off-topic. You wanted to add
annotations to the XML, so you could find out about enum and bitfield
arguments, so let's keep to that. There is value in simplicity.
How about this:
Add
On Mon, 20 Apr 2015 15:54:59 +
Jeroen Bollen jbin...@gmail.com wrote:
On Mon, 20 Apr 2015 at 09:03 Pekka Paalanen ppaala...@gmail.com wrote:
Also, adding the strict type information to the XML spec has no benefit
for C, which is the de facto language for Wayland core developers. A C
I think I have thought out a solution.
The scanner should be able to parse multiple specification files. There
would be the default wayland.xml, and for example a gnome.xml, which is an
extension to the wayland.xml. It does only contain things like added
interfaces, added requests, added events
Even the patches I did to the automatic documentation generation would
benefit greatly from this. There could be a clickable link from the
argument to the enumeration, or (with a good deal more work) it could
detect enums that are used only once and place them right there under
the arg.
And
On 20 April 2015 at 09:03, Pekka Paalanen ppaala...@gmail.com wrote:
Hi,
Thanks for taking the time to respond. I'll address your issues one by
one, but the overarching picture is that such typing information
should and would not be interpreted by bindings as a promise, but
rather as a hint.
On Sun, 19 Apr 2015 12:51:50 +
Jeroen Bollen jbin...@gmail.com wrote:
Hello,
It seems like this discussion died off. Currently there is no way to tell,
from the Wayland XML specification whether an argument is a bitfield, or
whether the argument takes an enum and what enum this is.
Hi,
On Mon, 20 Apr 2015 09:43:42 +0200
Auke Booij a...@tulcod.com wrote:
On 20 April 2015 at 09:03, Pekka Paalanen ppaala...@gmail.com wrote:
Hi,
Thanks for taking the time to respond. I'll address your issues one by
one, but the overarching picture is that such typing information
should and
On Mon, 20 Apr 2015 at 09:03 Pekka Paalanen ppaala...@gmail.com wrote:
Also, adding the strict type information to the XML spec has no benefit
for C, which is the de facto language for Wayland core developers. A C
compiler also does not raise errors if you violate the rules. This and
all the
Hello,
It seems like this discussion died off. Currently there is no way to tell,
from the Wayland XML specification whether an argument is a bitfield, or
whether the argument takes an enum and what enum this is.
I am currently in the progress of writing a Wayland binding generator for
the Rust
On Mon, 1 Sep 2014 22:07:44 +0200
Nils Chr. Brause nilschrbra...@gmail.com wrote:
On Mon, Sep 1, 2014 at 10:45 AM, Pekka Paalanen ppaala...@gmail.com wrote:
Another problem with this patch is that while it adds new syntax to the
protocol XML, it does not add anything that would either
2014-09-03 10:15 GMT+03:00 Pekka Paalanen ppaala...@gmail.com:
On Mon, 1 Sep 2014 22:07:44 +0200
Nils Chr. Brause nilschrbra...@gmail.com wrote:
On Mon, Sep 1, 2014 at 10:45 AM, Pekka Paalanen ppaala...@gmail.com wrote:
Another problem with this patch is that while it adds new syntax to the
On Wed, 3 Sep 2014 10:28:30 +0300
Giulio Camuffo giuliocamu...@gmail.com wrote:
2014-09-03 10:15 GMT+03:00 Pekka Paalanen ppaala...@gmail.com:
On Mon, 1 Sep 2014 22:07:44 +0200
Nils Chr. Brause nilschrbra...@gmail.com wrote:
On Mon, Sep 1, 2014 at 10:45 AM, Pekka Paalanen
Another possibility would of course be to add an 'is_bitfield=true'
attribute to enum elements that are actually bit fields instead of using
'bitfield' elements. Every sanely written scanner should be able to cope
with that, shouldn't it?
On Wed, Sep 3, 2014 at 1:09 PM, Nils Chr. Brause
On Wed, 3 Sep 2014 15:03:55 +0200
Nils Chr. Brause nilschrbra...@gmail.com wrote:
Another possibility would of course be to add an 'is_bitfield=true'
attribute to enum elements that are actually bit fields instead of using
'bitfield' elements. Every sanely written scanner should be able to
On Wed, Sep 3, 2014 at 9:15 AM, Pekka Paalanen ppaala...@gmail.com wrote:
On Mon, 1 Sep 2014 22:07:44 +0200
Nils Chr. Brause nilschrbra...@gmail.com wrote:
While I'm at that, I would also like to make use of the enum names in the
generated C code. As far as I can see, this would not break
On Mon, Sep 1, 2014 at 10:45 AM, Pekka Paalanen ppaala...@gmail.com wrote:
On Sat, 30 Aug 2014 17:20:45 +0200
Nils Chr. Brause nilschrbra...@gmail.com wrote:
There are programming languages, that are more strongly typed than
C. People creating Wayland bindings for these languages probably
There are programming languages, that are more strongly typed than
C. People creating Wayland bindings for these languages probably want
to make use of this strong type system by declaring each enumeration a
distict type.
For code generation to work with these languages, there needs to be
44 matches
Mail list logo
