On Fri, 26 Jan 2024 23:59:50 GMT, Nir Lisker wrote:
> Added a utility method to run code on the FX thread if it's not already, and
> changed the animation methods to use it.
This pull request has now been integrated.
Changeset: c5ab220b
Author: Nir Lisker
URL:
> Added a utility method to run code on the FX thread if it's not already, and
> changed the animation methods to use it.
Nir Lisker has updated the pull request incrementally with one additional
commit since the last revision:
Update tests
-
Changes:
- all:
On Mon, 29 Jan 2024 22:13:25 GMT, Kevin Rushforth wrote:
>> I don't think the executor service catches the exception because if it did
>> then the `AnimationTimer` test would also always pass. I do get the AIOOB
>> exceptions from the background thread caught in the handler (which fails the
On Mon, 29 Jan 2024 19:00:46 GMT, Kevin Rushforth wrote:
>> Nir Lisker has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update tests
>
> tests/system/src/test/java/test/com/sun/javafx/animation/Synch
> Added a utility method to run code on the FX thread if it's not already, and
> changed the animation methods to use it.
Nir Lisker has updated the pull request incrementally with one additional
commit since the last revision:
Use AtomicReferences
-
Changes:
- all:
On Mon, 29 Jan 2024 19:05:46 GMT, Kevin Rushforth wrote:
>> Nir Lisker has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update tests
>
> tests/system/src/test/java/test/com/sun/javafx/animation/Synch
> Added a utility method to run code on the FX thread if it's not already, and
> changed the animation methods to use it.
Nir Lisker has updated the pull request incrementally with two additional
commits since the last revision:
- Fix removed methods
- Correct methods i
On Mon, 29 Jan 2024 19:22:17 GMT, Jose Pereda wrote:
>> Nir Lisker has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update tests
>
> modules/javafx.graphics/src/main/java/javafx/animation/Animati
On Mon, 29 Jan 2024 16:42:15 GMT, Nir Lisker wrote:
>> Added a utility method to run code on the FX thread if it's not already, and
>> changed the animation methods to use it.
>
> Nir Lisker has updated the pull request incrementally with one additional
> commit si
> Added a utility method to run code on the FX thread if it's not already, and
> changed the animation methods to use it.
Nir Lisker has updated the pull request incrementally with one additional
commit since the last revision:
Update tests
-
Changes:
- all:
> Added a utility method to run code on the FX thread if it's not already, and
> changed the animation methods to use it.
Nir Lisker has updated the pull request incrementally with one additional
commit since the last revision:
Rename more Animation methods
-
Changes:
> Added a utility method to run code on the FX thread if it's not already, and
> changed the animation methods to use it.
Nir Lisker has updated the pull request incrementally with one additional
commit since the last revision:
Update Timeline method
-
Changes:
- all:
On Mon, 29 Jan 2024 13:07:21 GMT, Kevin Rushforth wrote:
> I don't think this will do what you want. This will return almost
> immediately, before any of the animation has run (as soon as the runnable
> that sets the uncaught exception handler finished).
I observed that this setup works
> Added a utility method to run code on the FX thread if it's not already, and
> changed the animation methods to use it.
Nir Lisker has updated the pull request incrementally with one additional
commit since the last revision:
Add null parent checks
-
Changes:
- all:
On Mon, 29 Jan 2024 12:44:07 GMT, Kevin Rushforth wrote:
>> Probably you won't like `xxImpl` either?
>> I'm not sure we should start adding `runMustBeOnFxThread` to every method
>> name out there that should run on the FX thread. In this case, maybe we
>> could simply add a small javadoc with
> Added a utility method to run code on the FX thread if it's not already, and
> changed the animation methods to use it.
Nir Lisker has updated the pull request incrementally with one additional
commit since the last revision:
Change method names
-
Changes:
- all:
> Added a utility method to run code on the FX thread if it's not already, and
> changed the animation methods to use it.
Nir Lisker has updated the pull request incrementally with one additional
commit since the last revision:
Update tests
-
Changes:
- all:
> Added a utility method to run code on the FX thread if it's not already, and
> changed the animation methods to use it.
Nir Lisker has updated the pull request incrementally with one additional
commit since the last revision:
Add system test
-
Changes:
- all:
> Added a utility method to run code on the FX thread if it's not already, and
> changed the animation methods to use it.
Nir Lisker has updated the pull request incrementally with one additional
commit since the last revision:
Remove irrelevant tests
-
Changes:
- all:
On Sat, 27 Jan 2024 19:43:22 GMT, Jose Pereda wrote:
> However, I'm not sure about the method naming `OnFxThread`, as it might imply
> that what it does is already done on the FX thread, therefore not needing to
> be wrapped up by `runOnFxThread`.
I understand what you mean, but the way I see
> Added a utility method to run code on the FX thread if it's not already, and
> changed the animation methods to use it.
Nir Lisker has updated the pull request incrementally with one additional
commit since the last revision:
Move parent check to invoking thread
-
C
On Sat, 27 Jan 2024 19:27:25 GMT, Jose Pereda wrote:
>> Nir Lisker has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update documentation on AnimationTimer methods
>
> modules/javafx.graphics/src/main/java/
On Sat, 27 Jan 2024 18:06:24 GMT, Kevin Rushforth wrote:
> The API looks good now, so you should be able to update the CSR.
I think that the update to the CSR from an hour ago included all the changes
already.
-
PR Comment:
On Wed, 10 Jan 2024 02:36:32 GMT, Philippe Altherr wrote:
> 8324797: Code example in JavaDoc of ObservableValue#when doesn't compile
By the way, [code snippets](https://openjdk.org/jeps/413) brought a solution to
this with external snippets. The example code exists in a standard compiled
java
> Added a utility method to run code on the FX thread if it's not already, and
> changed the animation methods to use it.
Nir Lisker has updated the pull request incrementally with one additional
commit since the last revision:
Update documentation on AnimationTimer m
> Added a utility method to run code on the FX thread if it's not already, and
> changed the animation methods to use it.
Nir Lisker has updated the pull request incrementally with two additional
commits since the last revision:
- Remove whitespace
- Include playFrom* m
On Sat, 27 Jan 2024 16:07:54 GMT, Kevin Rushforth wrote:
>> Nir Lisker has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Call the correct super method
>
> modules/javafx.graphics/src/main/java/javafx/animat
On Sat, 27 Jan 2024 15:40:53 GMT, Kevin Rushforth wrote:
>> Nir Lisker has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Doc changes to AnimationTimer methods
>
> modules/javafx.graphics/src/main/java/javaf
> Added a utility method to run code on the FX thread if it's not already, and
> changed the animation methods to use it.
Nir Lisker has updated the pull request incrementally with one additional
commit since the last revision:
Call the correct super method
-
Changes:
> Added a utility method to run code on the FX thread if it's not already, and
> changed the animation methods to use it.
Nir Lisker has updated the pull request incrementally with one additional
commit since the last revision:
Doc changes to AnimationTimer methods
-
C
On Fri, 26 Jan 2024 23:59:50 GMT, Nir Lisker wrote:
> Added a utility method to run code on the FX thread if it's not already, and
> changed the animation methods to use it.
The tests from [JDK-8159048](https://bugs.openjdk.org/browse/JDK-8159048)
should either be removed or re
Added a utility method to run code on the FX thread if it's not already, and
changed the animation methods to use it.
-
Commit messages:
- Remove whitespace
- Remove whitespace
- Run methods on the FX thread
Changes: https://git.openjdk.org/jfx/pull/1352/files
Webrev:
e a PauseTransition that doesn't
manipulate properties?
On Thu, Jan 25, 2024 at 11:02 AM John Hendrikx
wrote:
>
> On 24/01/2024 22:06, Nir Lisker wrote:
>
> This is the ballpark of what I meant with "the downside might be some
> surprise when these methods behave
Isn't that exactly what the Worker interface and its Task and Service
implementations are for? Service says
A Service is a non-visual component encapsulating the information required
> to perform some work on one or more background threads. As part of the
> JavaFX UI library, the Service knows
of the animation. Only the
> internal operation of adding the animation to AbstractPrimaryTimer
> should be posted to the FX thread. If that is not possible, this
> suggests to me that we should choose option 1. Introducing new and
> surprising semantics to an existing API is not the way to go.
>
>
and I (and a couple others) had an
> offline discussion and think this is the way to go.
>
> Given the short amount of time to get this into 22, I will file the JBS
> issue in the next hour or so.
>
> Nir: if you want to take it, that would be great. Otherwise, I will do it.
> We need
rds
> Jurgen
>
>
>
> On Wed, 24 Jan 2024 15:15:31 +0200, Kevin Rushforth
> wrote:
>
> Thank you to Jurgen for raising the question and to Nir, John, and Michael
> for evaluating it.
>
> I conclude that there is insufficient motivation to revert the change in
> beh
the pitfall.
I don't see a good use case for modifying controls in a background thread
while still interacting with the scenegraph, hence for adding multithread
support.
- Nir
On Mon, Jan 22, 2024, 12:59 Jurgen Doll wrote:
> Here's an example as requested by Nir:
>
> public class FxTimeLineTes
I don't see a ColorPicker bug in JBS that was created in the last 2 weeks,
which means it's still in internal triage. Kevin will have to take a look.
On Mon, Jan 22, 2024 at 12:20 PM PavelTurk wrote:
> Hello all.
>
> On January 10, 2024 I opened an issue with internal review ID 9076431
> about
On Fri, 19 Jan 2024 16:07:31 GMT, Michael Strauß wrote:
> The `Animation` class states in the documentation of various methods that the
> method call would be asynchronous, using language similar to:
>
>
> {@code stop()} is an asynchronous call, the {@code Animation} may not stop
>
animations
relate? Playing an animation is something that is done explicitly, usually
in order to manipulate data. Can you give a real use case, like a minimized
version of what you're doing?
- Nir
On Sat, Jan 20, 2024 at 2:42 AM Michael Strauß
wrote:
> Hi Jurgen,
>
> the start, stop, p
o be considered and approved while
> we are still in RDP1. I would not consider such a change once we hit
> RDP2 on Feb 1.
>
> Before even considering this, I'd like to hear from Johan Vos, Jose
> Pereda (who implemented JDK-8159048), Nir Lisker (who has done a lot of
> work on animation
On Fri, 19 Jan 2024 16:00:49 GMT, John Hendrikx wrote:
>> The SimpleSelector and CompoundSelector classes are public classes in an
>> exported package, javafx.css, but they are not intended to be used by
>> applications. They are implementation details. They cannot be constructed
>> directly
On Fri, 19 Jan 2024 10:02:19 GMT, John Hendrikx wrote:
> The SimpleSelector and CompoundSelector classes are public classes in an
> exported package, javafx.css, but they are not intended to be used by
> applications. They are implementation details. They cannot be constructed
> directly and
On Fri, 19 Jan 2024 10:02:19 GMT, John Hendrikx wrote:
> The SimpleSelector and CompoundSelector classes are public classes in an
> exported package, javafx.css, but they are not intended to be used by
> applications. They are implementation details. They cannot be constructed
> directly and
On Thu, 4 Jan 2024 12:21:15 GMT, John Hendrikx wrote:
> Improves performance of selector matching in the CSS subsystem. This is done
> by using custom set implementation which are highly optimized for the most
> common cases where the number of selectors is small (most commonly 1 or 2).
> It
On Fri, Dec 22, 2023 at 3:35 PM João Jandre Paraquetti
wrote:
>
> Hello Nir,
>
> Thank you for your detailed response, but this process does seem a bit
> too complex.
>
> I've been thinking, wouldn't it be easier to use the process below?
> - Create a paused transien
On Fri, 10 Nov 2023 23:39:21 GMT, Nir Lisker wrote:
>> Moves the filter setting of the samplers from the device parameters
>> configuration to the use-site, allowing for dynamic changes in the sampler.
>> This PR does internal plumbing work only to bring it close to th
I recently came across a place where I needed this conversion. This is what
I did:
String fullName = color.toString();
String cssName = "#" + fullName.substring(2, fullName.length() - 2);
Is this what you want to avoid writing? (Ignoring that the javadox of
toString() says "The content and
06/lib/vdsm/storage/nbd.py#L184
3. Starting qemu-nbd with exporting the bitmap using systemd-run:
https://github.com/oVirt/vdsm/blob/0fc22ff0b81d605f10a2bc67309e119b7462b506/lib/vdsm/storage/nbd.py#L419
Nir
> This means that `setStyle` wins over `getStyleSheets().add`, which wins
over a property set by the developer which wins over the default FX
Stylesheet.
And binding a property wins even more.
On Sun, Dec 17, 2023, 16:49 John Hendrikx wrote:
>
> On 16/12/2023 23:02, Mark Raynsford wrote:
> >
On Sat, 9 Dec 2023 17:55:32 GMT, Michael Strauß wrote:
>> This PR enhances the documentation of `Platform.Preferences.accentColor`:
>>
>>
>>/**
>> - * The accent color.
>> + * The accent color, which can be used to highlight the active or
>> important part of a
>> + * control and
On Sat, 9 Dec 2023 08:40:31 GMT, Michael Strauß wrote:
>> This PR enhances the documentation of `Platform.Preferences.accentColor`:
>>
>>
>>/**
>> - * The accent color.
>> + * The accent color, which can be used to highlight the active or
>> important part of a
>> + * control and
On Sat, 9 Dec 2023 07:07:27 GMT, Michael Strauß wrote:
> This PR enhances the documentation of `Platform.Preferences.accentColor`:
>
>
>/**
> - * The accent color.
> + * The accent color, which is usually a vivid color that contrasts with
> the foreground
> + * and background
On Fri, 8 Dec 2023 00:53:56 GMT, Ambarish Rapte wrote:
> Gradle 8.5.0 released on Nov 29, 2023, supports JDK 21.
> We need to update Gradle to 8.5 in order to update the boot JDK.
> There are not API level changes in Gradle that we need to work on, hence the
> change is only Gradle version
ssref.html
>
>
>
> I subscribe to a school of thought that requires specifications written by
> humans for humans. The CSS reference is, in my opinion, an authoritative
> source, so I would be against developing any tooling that generates it from
> the source code.
>
>
>
On Thu, 7 Dec 2023 17:21:05 GMT, Michael Strauß wrote:
>> Please read [this
>> document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548)
>> for an introduction to the Platform Preferences API, and how it interacts
>> with the proposed style theme and stage appearance features.
s specifications written by
> humans for humans. The CSS reference is, in my opinion, an authoritative
> source, so I would be against developing any tooling that generates it from
> the source code.
>
>
>
> -andy
>
>
>
>
>
> *From: *Nir Lisker
> *Date
teXProperty. How would that work with
> annotations?
>
>
>
> What do you think?
>
>
>
> -andy
>
>
>
>
>
>
>
> *From: *Nir Lisker
> *Date: *Wednesday, December 6, 2023 at 02:37
> *To: *Andy Goryachev
> *Cc: *Michael Strauß , openjfx-dev <
> openjfx-
CSS system would have to wrap it, or otherwise track them) but
>> that's all hidden. It gets rid of the StyleableProperty uglyness and the
>> need for users to create those, and puts the "extra" CSSMetaData
>> information a styleable property needs firmly where
On Thu, 7 Dec 2023 01:05:44 GMT, Michael Strauß wrote:
>> Please read [this
>> document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548)
>> for an introduction to the Platform Preferences API, and how it interacts
>> with the proposed style theme and stage appearance features.
I thought about the option of reflection, but I opted to propose
annotations instead. The following is my reasoning.
Firstly, reflection is very magic-y. The author of the class has no
indication of what side effects happen due to the code they write, the
output (css handling in this case) comes
There's already ongoing work for this in
https://bugs.openjdk.org/browse/JDK-8297300. John provided some fixes, I
need to get back to it.
On Mon, Dec 4, 2023 at 9:53 PM Johan Vos wrote:
> Also, these commits often affect many files at once (in scattered
> locations), and that makes backports
ranch is split from the
master.
- Nir
[1] https://openjdk.org/jeps/454
[2]
https://download.java.net/java/early_access/jdk22/docs/api/java.base/java/lang/foreign/package-summary.html
[3] https://openjdk.org/jeps/413
[4] https://openjdk.org/jeps/440
[5] https://openjdk.org/jeps/441
[6] https://openjdk.org/jeps/456
On Tue, 21 Nov 2023 21:11:43 GMT, Nir Lisker wrote:
> Deprecating for removal `getDateFormat()` in `TimeStringConverter` and
> `DateStringConverter` after it was removed already in
> `DateTimeStringConverter`, and `getNumberFormat()` in `NumberStringConverter`
> (and subclasses)
aziness? John also mentioned that any displayed
instance of a class will initialize these anyway (on first use). A benefit
can only arise if we create an instance but don't show it, in which case
why did we create it?
And I would be very much interested to hear from Nir his idea of an API
> that
On Fri, 1 Dec 2023 10:07:37 GMT, Ambarish Rapte wrote:
>> I agree with 2. and I also think that `TextureParameters` would be a better
>> name for this.
>>
>> This should also follow in below method names and such (ex.
>> `setTextureParameters()` instead of `setTextureData()`)
>
> These
On Fri, 1 Dec 2023 09:14:28 GMT, Ambarish Rapte wrote:
>> Nir Lisker has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Addressed review comments
>
> modules/javafx.graphics/src/main/native-prism-d3d/D3D
On Tue, 28 Nov 2023 23:34:30 GMT, Andy Goryachev wrote:
>> Provide a public utility method for use by custom and core Nodes to simplify
>> boilerplate around styleable properties as well as to save some memory.
>>
>>
>> /**
>> * Utility method which combines {@code CssMetaData} items
On Wed, 29 Nov 2023 15:54:17 GMT, Andy Goryachev wrote:
> > I'm unconvinced that this is the way to solve the issue it describes in its
> > doc. The problem is that each control wants to add its own css metadata to
> > that of its parent (recursively), and that the list is immutable (or
> >
On Tue, 28 Nov 2023 23:34:30 GMT, Andy Goryachev wrote:
>> Provides a public utility method for use by the skins (core and custom) to
>> simplify initialization of styleable properties.
>>
>>
>> + /**
>> + * Utility method which combines CssMetaData items in one unmodifiable list
>> with the
On Tue, 28 Nov 2023 00:51:36 GMT, Andy Goryachev wrote:
>> Provides a public utility method for use by the skins (core and custom) to
>> simplify initialization of styleable properties.
>>
>>
>> + /**
>> + * Utility method which combines CssMetaData items in one unmodifiable list
>> with the
On Tue, 28 Nov 2023 00:51:36 GMT, Andy Goryachev wrote:
>> Provides a public utility method for use by the skins (core and custom) to
>> simplify initialization of styleable properties.
>>
>>
>> + /**
>> + * Utility method which combines CssMetaData items in one unmodifiable list
>> with the
Perhaps the review should continue for
https://github.com/openjdk/jfx/pull/1232. Then try to continue to the maven
publication part of the build file as discussed on that issue by consulting
with the author (who is very helpful).
On Tue, Nov 28, 2023 at 11:21 AM Johan Vos wrote:
> Hi Sarang,
>
On Thu, Nov 2, 2023 at 4:40 PM Yuriy wrote:
> Hi Nir!
>
> This is Yuriy.
> We agreed to continue the subject via email.
>
So the options are:
1. Using Managed Block Storage (cinderlib) with a driver that supports
NVMe/TCP.
Lastest oVirt has the needed changes to configure th
On Tue, 21 Nov 2023 23:19:56 GMT, Andy Goryachev wrote:
> It's just weird - allowing core classes to override yet denying this freedom
> to the app dev.
I don't think these classes should have existed. They don't add any
functionality and could have been specialized constant implementations.
On Tue, 21 Nov 2023 21:11:43 GMT, Nir Lisker wrote:
> Deprecating for removal `getDateFormat()` in `TimeStringConverter` and
> `DateStringConverter` after it was removed already in
> `DateTimeStringConverter`, and `getNumberFormat()` in `NumberStringConverter`
> (an
On Tue, 21 Nov 2023 21:11:43 GMT, Nir Lisker wrote:
> Deprecating for removal `getDateFormat()` in `TimeStringConverter` and
> `DateStringConverter` after it was removed already in
> `DateTimeStringConverter`, and `getNumberFormat()` in `NumberStringConverter`
> (an
On Tue, 21 Nov 2023 21:11:43 GMT, Nir Lisker wrote:
> Deprecating for removal `getDateFormat()` in `TimeStringConverter` and
> `DateStringConverter` after it was removed already in
> `DateTimeStringConverter`, and `getNumberFormat()` in `NumberStringConverter`
> (an
On Tue, 21 Nov 2023 21:47:36 GMT, Andy Goryachev wrote:
> Are we going to make all these private at some point?
They are going to be made package-private so that they are not public API while
still can be read by subclasses. There's no "internal protected" visibility
that would be ideal here.
Deprecating for removal `getDateFormat()` in `DateTimeStringConverter` and
`DateTimeStringConverter` after it was removed already in
`DateTimeStringConverter`, and `getNumberFormat()` in `NumberStringConverter`
(and subclasses).
-
Commit messages:
- Deprecate protected methods
; That was my thinking as well, which is captured in
> https://bugs.openjdk.org/browse/JDK-8240844
>
> Perhaps this is the right time to move this forward?
>
> -- Kevin
>
>
> On 11/17/2023 4:06 PM, Nir Lisker wrote:
>
> Hi,
>
> A previous discussion mentioned the rem
On Sat, 18 Nov 2023 05:50:35 GMT, Michael Strauß wrote:
>> Please read [this
>> document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548)
>> for an introduction to the Platform Preferences API, and how it interacts
>> with the proposed style theme and stage appearance
ses are
seldom used.
What could be a way to deal with that dependency? Perhaps the module can be
declared 'requires static'. Or extract the adapter packages into a
different "interop" module (javafx.javabeans) like javafx.swing?
- Nir
Vote: YES
On Thu, Nov 16, 2023 at 7:00 PM Kevin Rushforth
wrote:
> Vote: YES
>
> -- Kevin
>
> On 11/16/2023 7:38 AM, Kevin Rushforth wrote:
> > I hereby nominate Florian Kirmaier [1] to OpenJFX Committer.
>
Vote: YES
On Thu, Nov 16, 2023 at 6:55 PM John Neffenger wrote:
> Vote: YES
>
> John
>
> On 11/16/23 7:54 AM, Kevin Rushforth wrote:
> > I hereby nominate Martin Fox [1] to OpenJFX Committer.
>
>
>
> 3D line and point primitives
>
I filed https://bugs.openjdk.org/browse/JDK-8316398 for this already. As
noted, it requires a somewhat complex computation for intersections and
possibly for contains. If you would like to write these Mesh classes, like
the current TriangleMesh, I can write the
On Thu, 9 Nov 2023 02:45:34 GMT, Michael Strauß wrote:
>> Nir Lisker has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Addressed review comments
>
> modules/javafx.graphics/src/main/native-prism-d3d/D3DPhon
On Mon, 13 Nov 2023 01:23:13 GMT, Michael Strauß wrote:
>> About 2, I tried that initially and got into problems iterating over the
>> enum in `D3DMeshView.cc` line 293. How would you perform the iteration?
>
> You're right, there's no implicit conversion from scoped enums to integers.
> While
> On 14 Nov 2023, at 19:46, Michael Richardson wrote:
>
>
> Yoav Nir wrote:
>> - Although it is implied, it should be stated explicitly that
>> TS_MAX_QUEUE does not mean no more child SAs with these TS ever. As
>> some child SAs get deleted and perha
> On 13 Nov 2023, at 12:31, Sahana Prasad wrote:
>
> Hello,
>
> I've read the draft and support its adoption.
To clarify, the draft is already adopted since July 2021. The question now is
whether it is ready to proceed to publication.
> Specifically, we (at Red Hat) have use cases where
Hi.
I’ve read the draft. Overall, it’s similar to a non-standardized solution we
did at Check Point several years ago, so I agree that it is a solution that
works. Of course, since there *are* a bunch of working implementations, that
is not particularly insightful.
With a lot of flows, it’s
looks like the sampler settings needed to be added anywhere, and
> that was the easiest to do at the time. Now they were just moved.
Nir Lisker has updated the pull request incrementally with one additional
commit since the last revision:
Addressed review comments
-
Changes:
- all: https://git.o
On Thu, 9 Nov 2023 02:44:44 GMT, Michael Strauß wrote:
>> Moves the filter setting of the samplers from the device parameters
>> configuration to the use-site, allowing for dynamic changes in the sampler.
>> This PR does internal plumbing work only to bring it close to the ES2
>> pipeline. A
On Thu, 9 Nov 2023 03:15:27 GMT, Michael Strauß wrote:
>> Moves the filter setting of the samplers from the device parameters
>> configuration to the use-site, allowing for dynamic changes in the sampler.
>> This PR does internal plumbing work only to bring it close to the ES2
>> pipeline. A
On Thu, 9 Nov 2023 03:16:51 GMT, Michael Strauß wrote:
>> Moves the filter setting of the samplers from the device parameters
>> configuration to the use-site, allowing for dynamic changes in the sampler.
>> This PR does internal plumbing work only to bring it close to the ES2
>> pipeline. A
Moves the filter setting of the samplers from the device parameters
configuration to the use-site, allowing for dynamic changes in the sampler.
This PR does internal plumbing work only to bring it close to the ES2 pipeline.
A followup PR will create the public API.
Summary of the changes:
*
> On 8 Nov 2023, at 8:34, Loganaden Velvindron wrote:
>
> I support moving forward with hybrids as a proactively safe deployment
> option. I think that supporting
> only Kyber for KEX is not enough. It would make sense to have more options.
>
> Google uses NTRU HRSS internally:
>
For signatures or keys in something like a certificate, I understand how you
would want to have both the PQ and classical keys/sigs in the same structure,
so satisfy those who want the classical algorithm and those who prefer the
post-quantum.
For key exchange? For the most part a negotiation
> On 7 Nov 2023, at 0:29, Blumenthal, Uri - 0553 - MITLL
> wrote:
>
> Do we want rfc describing the final NIST standards? And for which? I'm ok
> with that — in this order of priority: ml-kem, ml-dsa, slh-dsa.
>
> Probably yes, and in the order you described.
Sure, as long as by
101 - 200 of 10085 matches
Mail list logo
