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 Harrington wrote:
On Sat, May 02, 2015 at 11:52:22PM +0200, Auke Booij wrote:
On 19 April 2015 at 14:51, Jeroen Bollen wrote:
Hello,
It seems li
On the 19th of May 2015 08:33, Pekka Paalanen wrote:
On Mon, 18 May 2015 19:23:20 -0700
Bryce Harrington wrote:
On Sat, May 02, 2015 at 11:52:22PM +0200, Auke Booij wrote:
On 19 April 2015 at 14:51, Jeroen Bollen wrote:
Hello,
It seems like this discussion died off. Currently there is no w
On Mon, 18 May 2015 19:23:20 -0700
Bryce Harrington wrote:
> On Sat, May 02, 2015 at 11:52:22PM +0200, Auke Booij wrote:
> > On 19 April 2015 at 14:51, Jeroen Bollen wrote:
> > > Hello,
> > >
> > > It seems like this discussion died off. Currently there is no way to tell,
> > > from the Wayland
On Sat, May 02, 2015 at 11:52:22PM +0200, Auke Booij wrote:
> On 19 April 2015 at 14:51, Jeroen Bollen 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 a
On 19 April 2015 at 14:51, Jeroen Bollen 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 currently in the p
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
> 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
sp
On 27 April 2015 at 14:49, Pekka Paalanen wrote:
> On Mon, 27 Apr 2015 13:26:39 +0200
> Auke Booij wrote:
>
>> Apologies for my lack of responses, I have been abroad for a few days.
>>
>> On 23 April 2015 at 10:38, Pekka Paalanen wrote:
>> >> This is a sort of sanity condition on being a bitfiel
On Mon, 27 Apr 2015 15:49:27 +0300
Pekka Paalanen 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 the attribute be
On Mon, 27 Apr 2015 14:20:09 +0200
Auke Booij wrote:
> On 21 Apr 2015 09:18, "Pekka Paalanen" wrote:
> > Two things I came up with in the IRC discussion was that only
> > types of int an uint are eligible for enums, and only uint for
> > bitfields. I think wayland-scanner should enforce that.
>
On Mon, 27 Apr 2015 13:26:39 +0200
Auke Booij wrote:
> Apologies for my lack of responses, I have been abroad for a few days.
>
> On 23 April 2015 at 10:38, Pekka Paalanen wrote:
> >> This is a sort of sanity condition on being a bitfield: it does not
> >> require all combinations are valid, bu
On 21 Apr 2015 09:18, "Pekka Paalanen" wrote:
> Two things I came up with in the IRC discussion was that only
> 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 (non-bitfield) en
Apologies for my lack of responses, I have been abroad for a few days.
On 23 April 2015 at 10:38, Pekka Paalanen 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.
>
> Is that an
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 wrote:
> On Sat, 25 Apr 2015 14:11:32 +
> Jeroen Bollen wrote:
>
> > > I t
On Sat, 25 Apr 2015 14:11:32 +
Jeroen Bollen wrote:
> > I think that totally depends on how the interface is specified. This
> > applies only to one of the two ways an can grow.
>
> What other way can it grow? It can only grow bigger. If the application
> isn't aware of new values added, it
> I think that totally depends on how the interface is specified. This
> applies only to one of the two ways an 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 Bil
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 tri
On Thu, 23 Apr 2015 14:45:32 +
Jeroen Bollen 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 not?
I list
On Thu, 23 Apr 2015 10:44:50 -0700
Bill Spitzak 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 to have th
> (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 sh
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="
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
call
> 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
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 ot
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 to have the distinction in the language at
all?
The distinction is that in a bi
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
> t
On Thu, 23 Apr 2015 10:17:12 +0200
Auke Booij wrote:
> On 23 April 2015 at 08:38, Pekka Paalanen wrote:
> > On Wed, 22 Apr 2015 11:47:51 +0200
> > Auke Booij wrote:
> >
> >> On 22 April 2015 at 08:34, Pekka Paalanen wrote:
> >> > I also think this discussion is going off-topic. You wanted to a
On 23 April 2015 at 08:38, Pekka Paalanen wrote:
> On Wed, 22 Apr 2015 11:47:51 +0200
> Auke Booij wrote:
>
>> On 22 April 2015 at 08:34, 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 an
On Wed, 22 Apr 2015 08:38:22 -0700
Bill Spitzak 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 that. There is
On Wed, 22 Apr 2015 11:47:51 +0200
Auke Booij wrote:
> On 22 April 2015 at 08:34, 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 that. There is
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 wrote:
Hello,
It seems li
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 that. There is value in simplicity.
Absolutely agree
How about this:
Auke's ori
On 22 April 2015 at 08:34, 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 that. There is value in simplicity.
>
>
> How about this:
>
> Add three new, m
On Tue, 21 Apr 2015 16:32:40 +
Jeroen Bollen 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. It does only 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 an
On Mon, 20 Apr 2015 15:54:59 +
Jeroen Bollen wrote:
> On Mon, 20 Apr 2015 at 09:03 Pekka Paalanen 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
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 i
On Mon, 20 Apr 2015 at 09:03 Pekka Paalanen 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 above are the l
On Mon, 20 Apr 2015 09:43:42 +0200
Auke Booij wrote:
> On 20 April 2015 at 09:03, Pekka Paalanen 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
On 20 April 2015 at 09:03, Pekka Paalanen 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.
> I'm starting to thi
On Sun, 19 Apr 2015 12:51:50 +
Jeroen Bollen 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,
I'm startin
Well clearly gmail does line wrapping, which I did not realize. So
while I figure that out, please enjoy the patch which I attached.
On 19 April 2015 at 22:30, Auke Booij wrote:
> On 19 April 2015 at 14:51, Jeroen Bollen wrote:
>> Hello,
>>
>> It seems like this discussion died off. Currently th
On 19 April 2015 at 14:51, Jeroen Bollen 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 currently in the p
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 l
On Wed, Sep 3, 2014 at 9:15 AM, Pekka Paalanen wrote:
>
> On Mon, 1 Sep 2014 22:07:44 +0200
> "Nils Chr. Brause" 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 any existing
> > code, would it
On Wed, 3 Sep 2014 15:03:55 +0200
"Nils Chr. Brause" 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 cope
> with that, sh
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
wrote
I see.
In that case, I'll have to maintain my own xml file for my C++ bindings.
Thanks,
Nils
On Wed, Sep 3, 2014 at 10:20 AM, Pekka Paalanen wrote:
> On Wed, 3 Sep 2014 10:28:30 +0300
> Giulio Camuffo wrote:
>
> > 2014-09-03 10:15 GMT+03:00 Pekka Paalanen :
> > > On Mon, 1 Sep 2014 22:07:44
On Wed, 3 Sep 2014 10:28:30 +0300
Giulio Camuffo wrote:
> 2014-09-03 10:15 GMT+03:00 Pekka Paalanen :
> > On Mon, 1 Sep 2014 22:07:44 +0200
> > "Nils Chr. Brause" wrote:
> >
> >> On Mon, Sep 1, 2014 at 10:45 AM, Pekka Paalanen
> >> wrote:
> >
> >> > Another problem with this patch is that whil
2014-09-03 10:15 GMT+03:00 Pekka Paalanen :
> On Mon, 1 Sep 2014 22:07:44 +0200
> "Nils Chr. Brause" wrote:
>
>> On Mon, Sep 1, 2014 at 10:45 AM, Pekka Paalanen wrote:
>
>> > Another problem with this patch is that while it adds new syntax to the
>> > protocol XML, it does not add anything that w
On Mon, 1 Sep 2014 22:07:44 +0200
"Nils Chr. Brause" wrote:
> On Mon, Sep 1, 2014 at 10:45 AM, Pekka Paalanen 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 explain nor
> > validate/enforce it. (We
On Mon, Sep 1, 2014 at 10:45 AM, Pekka Paalanen wrote:
>
> On Sat, 30 Aug 2014 17:20:45 +0200
> "Nils Chr. Brause" wrote:
>
> > 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 stro
On Sat, 30 Aug 2014 17:20:45 +0200
"Nils Chr. Brause" wrote:
> 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.
>
> F
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
informat
54 matches
Mail list logo
