Skip to content

Generalized use of property list #73

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

steffenlarsen
Copy link
Contributor

Adds optional property_list parameters to all user-constructible SYCL
object constructors that did not have it before.

This is the wording related this proposal which has been discussed internally.

@keryell
Copy link
Member

keryell commented Feb 20, 2020

This is a great idea.
Is this something you need for 1.2.1 or can it wait fot the next SYCL version?

Copy link
Member

@keryell keryell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like a good proposal.

Steffen Larsen added 2 commits February 26, 2020 11:00
Adds optional property_list parameters to all user-constructible SYCL
object constructors that did not have it before
@steffenlarsen steffenlarsen force-pushed the SYCL-1.2.1/general-property-lists branch from 85dc270 to 3b82101 Compare February 26, 2020 11:01
@fraggamuffin
Copy link

You introduce an exception; current properties are specific; if we dont want it to be in this one, then I will have to change it; with SYCL NEXT constructing object with introp type is to use make function

I still want to remove this exception. I would have to change the wording because this is a restriction they have as well. Could be a separate issue. OK to be separate issue.

Copy link
Member

@keryell keryell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some merge crumbles?

@CLAassistant
Copy link

CLA assistant check
All committers have signed the CLA.

@illuhad
Copy link
Contributor

illuhad commented Mar 17, 2020

I wonder if we should move to a more type-based system for properties, such that passing invalid properties for one class will be caught by the type system. I expect that, if everything accepts properties, it opens the door for a lot of user error, and requires a lot of error handling..

@mkinsner
Copy link

In addition to #78 there are additional explicit constructors required before this change goes in, right? e.g. context?

@AerialMantis
Copy link
Collaborator

I have pushed another PR #81, which introduces a clarification to property_list constructors which removes the ambiguity in SYCL class constructors, allowing us to introduce this change without the worry of creating further ambiguities.

@fraggamuffin
Copy link

mar 19:

  • ready to go, PR81 uses new trait to restrict property list construction to types which are registered as officla - vendor or standard to not trigger an ambiguity
  • extend and clarify, hence 121
  • async handler resolved by PR 81; this is an important change

@steffenlarsen
Copy link
Contributor Author

steffenlarsen commented Mar 23, 2020

I noticed that there were some changes missing to program, specifically:

  • The constructor with linkOption should be split in two, similar to queue and context with async_handler.
  • The documentation of the constructors for program didn't have the new property_list parameter.

This has been fixed with 69b362c.

@keryell keryell merged commit 2fe54e5 into KhronosGroup:SYCL-1.2.1/master Mar 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants