https://gorouter.dev/ points to pub.dev

https://gorouter.dev/ started pointing to the pub package go_router and all its documentation seems to be lost.

I can see this change currently. Not sure if it's intended or not. Labelling for insights from the team.

This is expected as we plan to use readme as central place for documentations. The some of the documentation got moved to https://pub.dev/documentation/go_router/latest/ and https://github.com/flutter/packages/tree/main/packages/go_router/example
Feel free to file issues or prs if you think there are parts of documentations that need to be improved.

we plan to use readme as central place for documentation.

There is so much more in https://gorouter.dev/ than would ever be appropriate to fit in a README, including a much more slow-paced introduction and tutorial for each concept, in-depth discussion of advanced scenarios and topics, and translations of the whole documentation into Japanese. pub.dev doesn't any way to publish different translations of the README (that I'm aware of). If we take a word count of the current README, it is 728 words. If we take a word count of the full documentation on the website, it is 13,703 words - a generous 19x larger. But inappropriate for a README.

This is expected

But look at the comments here - it's apparently not expected by anyone else.
If there is a plan to eventually bring back this valuable resource at a new location, or to rewrite everything that used to be in the old resource, why not at least provide a link to the old documentation UNTIL it has been migrated to the new location?
It would be quite challenging for developers to learn how to use some of the advanced aspects of go_router without the old guides.

Feel free to file issues or prs if you think there are parts of documentation that need to be improved.

Why encourage people to create new PRs from scratch when all of that documentation had already existed in the past? It will lead to people unnecessarily duplicating effort.
For anyone stumbling upon this, you can find the source files for the original documentation here:
https://github.com/csells/go_router/tree/main/docs
And the Japanese translation is still browsable at this site:
https://zenn.dev/inari_sushio/scraps/01ef7604a4b934

@ryanheise Thanks so much for saying my heart out in detail.

If we take a word count of the current README, it is 728 words. If we take a word count of the full documentation on the website, it is 13,703 words - a generous 19x larger.

Why encourage people to create new PRs from scratch when all of that documentation had already existed in the past? It will lead to people unnecessarily duplicating effort.

Can't agree more!

@ryanheise @iLoveDocs You can find an archived version of the docs here

Thanks for the reply. Let me explain a few things.
Why we do this
The some of the old guides were outdated or incorrect due to API changes in the new go_router version. while some part was still useful, the other part may lead to undesired behavior. Flutter does not own the https://gorouter.dev/ so it takes extra effort to contact the owner and update docs. At some point we would have to migrate the doc to somewhere owned by flutter, so we decided Readme with link to the API doc or example is a good place to put them, and it also matches the style of other first party packages.
Parity between old docs and new docs.
besides the out-dated part of old docs, there are still some parity between old and new docs. some of them were moved to the API doc directly, for example https://pub.dev/documentation/go_router/latest/go_router/GoRoute/redirect.html. Some of was removed by purposes and some of them was straight up missing due to oversight. If the latter two cause confusions, I sincerely apologize. Either we made a mistake and think something that should be removed but shouldn't or we missed it entirely. We are still trying our best to improve the documentation. If you think some part or some APIs needs more explanation or mentions from the readme, please file an issue to discuss that so we can prioritize it.

Thank you for the reply, but I found it to be quite a confusing reply.

Why we do this: Some of the old guides were outdated or incorrect due to API changes in the new go_router version.

A decision to not continue to maintain the old tutorials/guides should not be disguised as a necessary result of the old tutorials/guides being out of date. The reason they are out of date is because of an explicit choice to not maintain them. It is Flutter's right to make that choice, but it would be more transparent to address the feedback by saying "we decided not to keep the old tutorials/guides up to date for reasons X, Y, Z".

Flutter does not own the https://gorouter.dev/ so it takes extra efforts to contact the owner and update docs.

The domain ownership is not a blocker. Flutter owns https://docs.flutter.dev/ and could have maintained the new copy of the guides there before letting them get out of date.

We are still trying our best to improve the documentation. If you think some part or some APIs needs more explanation or mentions from the readme, please file an issue to discuss that so we can prioritize it.

No amount of improvements to the README will address my concern, because if the guide/tutorial-like nature of gorouter.dev were to be incorporated into the README, then the README page would become inappropriately large. And updating the API documentation also won't address my concerns because API documentation pages are also inappropriate places to host guides and tutorials. Guides and tutorials are based on use cases and goals that have a broader scope than just a single class, method, field or function API (which is the scope of an API doc). One example would be nested navigation. This is a large topic, too big for the README. But then it is also a topic that you can't just spread out into the individual API doc pages because what's needed is a guide showing how all the pieces fit together, not just separate pages about each individual API. The API page on ShellRoute just shows an example for the ShellRoute class but does not give a wholistic example showing how this can fit with bottom navigation. And there are many other scenarios missing such as how to handle a tab view which might be handled differently. And there is also the scenario of wanting to update the AppBar or access the drawer from nested routes. A developer cannot easily find the answers to these questions by simply reading through the README or reading through the API, they need a guide.
I would expect the README to be reserved for a summary of usage, the API docs to be reserved for docs for the respective APIs, and tutorials/guides to be hosted elsewhere, such as docs.flutter.dev.
Don't get me wrong, it's nice to have a good quality README, and some people will be able to get the gist of things from the README alone, but many people will be lost without a guide. Navigation is a complex topic deserving of such a guide.

it also matches the style of other first party packages.

I don't think all packages are equal. If the usage of a package can be easily explained in a README alone, then great! But that is not the case for packages that have greater complexity. For example, this is the case for the various firebase packages which have necessary guides linked and hosted at another more appropriate place.

it would be more transparent to address the feedback

We do have an issue that tracks this efforts https://github.com/flutter/flutter/issues/102171
Although I agree we could have done better communicating to the public.

The domain ownership is not a blocker. Flutter owns https://docs.flutter.dev/ and could have maintained the new copy of the guides there before letting them get out of date.

The domain was already outdated before we start the migration, so some works were needed before the migration. So it downed to where was the best place to do these, readme or a section in https://docs.flutter.dev/. I chose the earlier for easier maintenance, and I think we can mimic the original gorouter.dev to have a lot of section and link to different page in the readme too. It was just that we decided to separate some doc to API page. We can always change that back to be a more goroute.dev style if the discussion turned out to favor that in the end.

And updating the API documentation also won't address my concerns because API documentation pages are also inappropriate places to host guides and tutorials

Although I slightly disagree the API documentation pages are inappropriate, I think improving doc will not be bound to readme or API page update. Depends on the topics, we may choose to write a doc in https://docs.flutter.dev/,  medium post, or youtube vids. We can be flexible, this is just a starting point.

The domain ownership is not a blocker. Flutter owns https://docs.flutter.dev/ and could have maintained the new copy of the guides there before letting them get out of date.

The domain was already outdated before we start the migration

That's a bit of an exaggeration. You cite the "Declarative Routing" page as one example, which said that it didn't matter which order you defined routes in. But that was not "out of date" at the time. It was stated that it is an invalid usage to define multiple conflicting routes, and given that, it indeed didn't matter what order the routes were defined in. go_router has since been changed to allow multiple matches in the list and to pick the first one, so "now" it's out of date, but at the time of the handover, you could not say that the documentation had already fallen out of date. It fell out of date after the migration.
Duration the migration, I can see the approach you have taken, but in the process, you also cut it down to size substantially, removing content, making the sentences more terse and less readable, less flowing and less connected. It is understandable that the document would be less helpful after cutting it down in size dramatically, but let's please have back all those sections that you cut out.

I think we can mimic the original gorouter.dev to have a lot of section and link to different page in the readme too.

Yes, but it fits in the README only because you deleted all of those sections/topics:

deep linking
url path strategies
debugging
transitions
keys
async
neglect
tab bars

I don't think it's worth the loss. I hope you will bring back all of that great documentation.

We can always change that back to be a more goroute.dev style if the discussion turned out to favor that in the end.

The early feedback was "a big downgrade from the previous documentation we had", and that is in line with the latest feedback in this issue.
There are also plenty of questions on StackOverflow about how to solve various navigation problems, and other issues submitted here asking for more documentation and examples on how to solve common navigation problems, so it is clear that what we need isn't a terse README, but a more meaty guide that covers common design scenarios, i.e. what gorouter.dev used to have before. A good start would be to bring back the old doc pages for those topics that had been cut out of the migration.

As a brand new user, I had to go to outdated YouTube videos to learn go_router because the readme was so sparse.

Still using the old documentation also or directly reading the code.

@ryanheise thanks for the feedback. I don't agree with most of your points, I hope you understand that the original docs were written by a Googler in their spare time and didn't go through the normal review and quality checking process that other docs go through.
We do cover deep linking and url path strategies on flutter.dev, which will be kept up to date. I agree we should link to these pages like the old docs.
For debugging, transitions, keys, async, and neglect, etc... Transitions are done using pageBuilder, debugging is done using debugLogDiagnostics, keys should no longer be necessary for nested navigation, so I consider that page out of date. The async page just shows how to use FutureBuilder, so I would recommend users use the Fetch data from the internet cookbook article on flutter.dev instead. (This page doesn't seem to have anything to do with go_router.)
The tab bars documentation is out of date with the new ShellRoute class (and more out of date still when stateful nested navigation is shipped: https://github.com/flutter/packages/pull/2650 ).
Keep in mind that the original docs are still available, but as @chunhtai pointed out, they are out of date, and we plan to document things in the README, API documentation, or on flutter.dev, not using docs.page going forward.

I think we are just saying the old doc is more useful and complete than what is currently available. Updating it's content and integrating everything that is missing in the current documentation would probably make everyone happy.
some example of hard to understand information: what's the difference between go and push.

I don't agree with most of your points

Most of your response was of the form: X is out of date, Y is out of date, Z is out of date, as if I had been claiming otherwise. But I didn't claim otherwise, and that was certainly not my point.

For debugging, transitions, keys, async, and neglect, etc... Transitions are done using pageBuilder, debugging is done using debugLogDiagnostics, keys should no longer be necessary for nested navigation, so I consider that page out of date. The async page just shows how to use FutureBuilder, so I would recommend users use the Fetch data from the internet cookbook article on flutter.dev instead. (This page doesn't seem to have anything to do with go_router.)

We actually agree that some of these pages are now out of date, but I'm saying that the new README, despite as you now say going through a supposedly higher level of quality assurance, is to many people of lower quality than the original documentation because it leaves out all of these well-written topic guides that were so illuminating and helpful to new users of go_router back when those guides were still not out of date, and it is unfortunate that the Flutter team has allowed this more appreciated documentation to become out of date, seemingly without acknowledging how much they were appreciated.
If any of these pages are now out of date, it strengthens my point because it means that developers now have no guidance on how to accomplish these omitted topics in the new version of go_router.

The tab bars documentation is out of date with the new ShellRoute class (and more out of date still when stateful nested navigation is shipped: flutter/packages#2650 ).

The reason that this needed its own topic guide is because the TabBarView scenario and the BottomNavigationBar scenario are completely different. In the latter, you would typically use nested navigators to maintain the stack for each page, but in a TabBarView, there is only a single page and it needs to be a stateful widget so that it can animate sideways to reveal the different content. You don't implement these in the same way. One pushes a page onto the stack, the other needs a hook so that you can call the appropriate method on a controller to trigger the sideways animation between tab views.
And the way you keep stressing how it's getting "more out of date" does not help your case, and does not have good optics when the point was that there is dissatisfaction with the Flutter Team's choice to allow these guides to become out of date in the first place, while also strangely not being able to acknowledge how much we appreciated these guides. As I have pointed out in a previous comment, these guides were largely not out of date at the time of handover. ShellRoute, for instance, did not even exist at the time of handover.

and we plan to document things in the README, API documentation, or on flutter.dev, not using docs.page going forward.

if you covered these guide topics on flutter.dev, that would be perfect. There is nothing too different between "using docs.page" vs using "flutter.dev" aside from the hosting location, and as I commented above:

Flutter owns https://docs.flutter.dev/ and could have maintained the new copy of the guides there before letting them get out of date.

I will leave it here, since everything has been said. Hopefully the Flutter team can acknowledge what people liked about the old guides before committing to a plan of action that simply dismisses the old guides as out of date and (ironically) not meeting Google's quality requirements.

the Flutter team has allowed this more appreciated documentation to become out of date, seemingly without acknowledging how much they were appreciated.

We don't own the domain nor the keys to publish, and we have no way to use docs.page for packages in the flutter/packages repo so we couldn't just copy-paste these and keep them up to date.

it is unfortunate that the Flutter team has allowed this more appreciated documentation to become out of date, seemingly without acknowledging how much they were appreciated.

What are you using to measure appreciation? We don't own the original gorouter docs so we don't have any insight into the page views.  We can't update these docs, which is why they are out of date.

there is dissatisfaction with the Flutter Team's choice to allow these guides to become out of date in the first place [...]  these guides were largely not out of date at the time of handover

That's true, but again we can't update the docs so I disagree that this was a choice on our end. If we were given the keys to publish, and got some help setting that up in the flutter/packages repo perhaps things would be different.

Flutter owns https://docs.flutter.dev/ and could have maintained the new copy of the guides there before letting them get out of date.

That would require a review from our technical writers. cc: @sfshaza2

Hopefully the Flutter team can acknowledge what people liked about the old guides before committing to a plan of action that simply dismisses the old guides as out of date and (ironically) not meeting Google's quality requirements.

Ack.

again we can't update the docs, which is why they are out of date.

OK, I think I can see where both you and @chunhtai are misunderstanding. It seems you think that someone is asking you to edit the docs specifically at the gorouter.dev site. But nobody in this issue ever said we must keep the old domain name to keep the docs maintained. The docs could be migrated and maintained elsewhere to keep them up to date. The old README suggested that the documentation would be migrated to a new place where you CAN edit it.
Specifically, the old README made the announcement that the package would be moved into the flutter/packages repository and that the gorouter.dev documentation would be moved to docs.flutter.dev, so that was the expectation. But even if it ended up being moved to the README instead of flutter.dev, it is of course still being migrated to some place where you DO have the ability to update the docs AND keep them up to date. E.g. as a start: cat docs/*.mdx > README.md.
The issue, then, is that in the migration process, we lost a lot of content because of the chosen approach to build up the README from scratch. That was always going to be a slow process that would leave us with unhelpful holes in the documentation for a considerable time. It would have been better to start with the old (excellent) documentation, maintain it, and to incrementally mold it to to Google's preferred documentation style over time. This would maximise availability of the documentation during the migration.
Feel free to thumbs down this feedback again, I am just wishing to offer my feedback on this migration but you can do with it what you will.

The tab bars documentation is out of date with the new ShellRoute class (and more out of date still when stateful nested navigation is shipped: flutter/packages#2650 ).

The reason that this needed its own topic guide is because the TabBarView scenario and the BottomNavigationBar scenario are completely different. In the latter, you would typically use nested navigators to maintain the stack for each page, but in a TabBarView, there is only a single page and it needs to be a stateful widget so that it can animate sideways to reveal the different content. You don't implement these in the same way. One pushes a page onto the stack, the other needs a hook so that you can call the appropriate method on a controller to trigger the sideways animation between tab views.

Since you have continued to respond, do you have any response to this comment? Wouldn't it have been better to copy the old doc page into the new documentation, and then maintain that documentation as go_router continues to change?
Otherwise, how else are developers going to learn how to implement TabBar navigation inside go_router in the meantime?
You say that this page is out of date now that we have the new ShellRoute class, but this is wrong for the reasons given above. Nested navigators don't even help to solve this problem(*), or at the very least, it's an orthogonal problem. The problem in question here is not how to nest navigators but rather how to animate between the different tab views at the same hierarchical level. You still need some hook to be able to call the appropriate method (or setter) on the controller to trigger the tab switching animation. Any response to that or are you just leaving it at your last response? That is, that you should dismiss the majority of what I'm saying?
(*) Who is using nested navigators in tab bars anyway? Isn't this an anti-pattern? In material design, bottom navigation bars are the ones where we navigate across independent nested hierarchies, while tab bars are where we are navigating across the "same" level in the hierarchy. I am happy to be corrected on that point, though, it does not affect the above argument. The problem of how to use tab bars in go_router specifically relates to what hook you need to respond to and link up with the appropriate controller method that animates the tabs.

Hopefully the Flutter team can acknowledge what people liked about the old guides before committing to a plan of action that simply dismisses the old guides as out of date and (ironically) not meeting Google's quality requirements.

Ack.

Don't be too enthusiastic now :-)

What are you using to measure appreciation? [...] we don't have any insight into the page views.

For qualitative, I suggest reading the feedback here and in other issues (and the pull request that committed the new README) from the 7+ people who have shared their views.
If you want quantitative, I suggest counting the number of comments and up-votes.
I think the consensus is clear: we love the original, comprehensive docs. They cover topics that are no longer mentioned in the new README, and so it would be a good idea to bring these missing pages back (e.g. as sections in the README, and ideally incorporated into less-cramped guides on flutter.dev).

The docs could be migrated and maintained elsewhere to keep them up to date.

I don't think so, the original docs used docs.page, which we don't have tooling to support right now. Adding them to flutter.dev would require a review from our technical writers, but that will take some time since the content is also out of date now.

the old README made the announcement that the package would be moved into the flutter/packages repository and that the gorouter.dev documentation would be moved to docs.flutter.dev

We chose to focus on adding features for 5.0.0 instead, but adding GoRouter docs to flutter.dev is still important for us.

The reason that this needed its own topic guide is because the TabBarView scenario and the BottomNavigationBar scenario are completely different. In the latter, you would typically use nested navigators to maintain the stack for each page, but in a TabBarView, there is only a single page and it needs to be a stateful widget so that it can animate sideways to reveal the different content. You don't implement these in the same way. One pushes a page onto the stack, the other needs a hook so that you can call the appropriate method on a controller to trigger the sideways animation between tab views.

This isn't a pattern we intend to recommend, since we found that users have a hard time understanding it. Instead, the sample should use ShellRoute with TabBar, not a TabBarView.

If you want quantitative, I suggest counting the number of comments and up-votes.

We do, that's why we've been working on other issues with more upvotes.

I think the consensus is clear: we love the original, comprehensive docs. They cover topics that are no longer mentioned in the new README, and so it would be a good idea to bring these missing pages back (e.g. as sections in the README, and ideally incorporated into less-cramped guides on flutter.dev).

The README is probably the best place for these right now, but we plan to add more to flutter.dev also. Feel free to send us a pull request if it's urgent.


Using UART with ESP32

I would like to use NuttX with ESP32 and I am looking for a UART driver. I see that there is the nuttx/include/nuttx/serial/serial.h file where I find the uart_setup(dev), uart_send(dev, ch) functions.
So what is the dev here? I figured out that I can pass CONSOLE_DEV from nuttx/arch/xtensa/src/esp32/esp32_serial.c, but there is a esp32_serial.h file missing which is why, I think, I keep getting this error
src/esp32_uart_driver.c:65:16: error: 'CONSOLE_DEV' undeclared (first use in this function)
   uart_setup(&(CONSOLE_DEV));

Please let me know if I have understood it incorrectly or if I am using the wrong files/functions thinking they are UART driver.

I found https://nuttx.apache.org/docs/latest/components/drivers/character/serial.html where it says

Each serial device driver must implement an instance of struct uart_ops_s
which is implemented in the nuttx/arch/xtensa/src/esp32/esp32_serial.c in the case of ESP32, but I cannot to use it because of the error I mentioned above.

The UART0 is chosen as serial console by default (Maybe because I am using the nsh config of ESP32). Also, when I check the .config file, I can see CONFIG_UART0_SERIAL_CONSOLE=y, so it is configured! The problem is that the definition of CONSOLE_DEV is not happening.

Please look the inside esp32_serial.c file, since CONFIG_UART0_SERIAL_CONSOLE is defined, the only way to CONSOLE_DEV be undefined is if USE_SERIALDRIVER is false. And this symbol is defined inside arch/xtensa/src/common/xtensa.h Probably you disabled CONFIG_DEV_CONSOLE or enabled CONFIG_CONSOLE_SYSLOG.
In order to be get better results with NuttX you need to learn to navigate inside the source code and search for symbols! :-)

Apparently CONFIG_DEV_CONSOLE is enabled and CONFIG_DEV_CONSOLE is disabled.

I am using adafruit huzzah32 - esp32 feather board which is similar to esp32-devkitc. (Both use WROOM32. Also, huzzah32 works fine with ESP-IDF when configured as esp32-devkitc)
The USE_SERIALDRIVER is in fact defined when tested at the end of esp32_serial.c with the preprocessor conditional inclusions you have suggested. I also check if CONSOLE_DEV is defined too by the end of esp32_serial.c and it is, but it is  not accessible in the driver I am trying to develop (nuttx/boards/xtensa/esp32/common/src/esp32_uart_driver.c).
Is there a working example that uses the uart_setup(uart_dev_t *dev) from serial.h that you can direct me to, so that I can have a look at it and understand how it is configured, or to check if I am doing it differently? That would be really great.

@SrivamsiMalladi you don't need to create a esp32_uart_driver.c because the uart driver is already created inside arch/xtensa/! All you need to do it use the device from userspace. So, your application will open the /dev/ttyS1 (because /dev/ttyS0 is used as console) and read/write to it. This is the same way as things works on Linux, FreeBSD, MacOS, etc. Search inside apps/ and you will find a lot of examples.

Did you enable "[*] UART 1" in the menuconfig? Otherwise /dev/ttyS1 will not be created!

you don't need to create a esp32_uart_driver.c because the uart driver is already created inside arch/xtensa/

Yea I saw that it is already available, but I am working on a custom UART driver, so wanted to create a separate driver wrapping the original driver.

your application will open the /dev/ttyS1 (because /dev/ttyS0 is used as console) and read/write to it.

Yea, I could get the UART to work this way with /dev/ttyS0 (UART0) (Need to try with /dev/ttyS1 or UART1), but I want to use the driver so that I need not rewrite the basic UART operations and interrupt methods.

Did you enable "[*] UART 1" in the menuconfig? Otherwise /dev/ttyS1 will not be created!

I did not enable it earlier. But after you told, I enabled it in the System Type > ESP32 peripheral Selection > [*] UART1. Even then the error 'CONSOLE_DEV' undeclared is occurring.

I suggest you to start with the basics, first clear everything:
$ make distclean

Then configure the board:
$ ./tools/configure.sh esp32-devkitc:nsh

Now compile/flash it:
$ make -j flash ESPTOOL_PORT=/dev/ttyUSB0

Use picocom/minicom/etc to see the nsh>
You should get UART0 working, then enable UART1 and compile/flash it again, you should see /dev/ttyS1

Yes! I can see the /dev/ttyS1 after enabling UART1. But I the error 'CONSOLE_DEV' undeclared still exists when trying to use uart_setup(&CONSOLE_DEV);

I don't understand what exactly you are trying to do. If the code is creating /dev/ttyS0 and /dev/ttyS1 it means everything is correct. Why are you calling uart_setup(&CONSOLE_DEV)? I think console was already created, look /dev/console !
The console is registered using "esp32_setup(&CONSOLE_DEV);"

@acassis, I got the /dev/ttySx to work. I can read and write to the /dev/ttyS1, for example, to send and receive messages over serial/UART.
What I want to do is to use the predefined driver methods like uart_read(), uart_write() and also methods that deal with UART interrupts, so that I do not have to rewrite them again. This is why I am looking into using uart_setup() and other functions.

My goal is to use interrupts with UART. For example, in ESP-IDF, the UART driver interrupts has several events like break detected or received data on rx line etc. I want to use them. Please let me know what I need to use to get this behavior.
One thing I can think of to implement this is to have a task constantly running which continuously reads from /dev/ttySx. When something is read, the main thread is alerted about the data reception. Basically I am building the interrupt from scratch.
Is there a better way to do it?


[Core] Persistence connection pooling and write context management

Description
#530 highlighted that validators were crashing after a few rounds of the blockchain. This was a result of incomplete connection pooling implementation in #407 which had to be amended.
Once fixed, the management of utility & persistence write contexts throughout the modules had to be cleaned up to avoid deadlocks and concurrency issues. In doing so, code cleanup and improvements were made throughout.
The following is an example video showing the blockchain going from height=0 to height=190.
https://user-images.githubusercontent.com/1892194/227062656-b928fd6f-daf4-41d9-8553-d5d0d8e5888d.mov
Issue
Fixes #530, #621
Type of change
Please mark the relevant option(s):

[ ] New feature, functionality or library
[x] Bug fix
[x] Code health or cleanup
[ ] Major breaking change
[ ] Documentation
[ ] Other

List of changes

Node - Add a deadline to the primary event handling to get visibility into concurrency issues
Persistence Interface - Consolidated Close and Release and avoid returning an `error
Persistence Module - Implement proper postgres pooling acquisition & release
Consensus Interface - Consolidated ResetRound, ResetForNewHeight ClearLeaderMessagesPool
Consensus Module - Fix utilityContext and persistenceContext acquisition & release throughout + code cleanup
Change the default pooling configurations to numbers that closer reflect the practical operations of a node
General - Improve logging, terminology and documentation throughout
See CHANGELOGs for an exhaustive list of all modifications

Testing

[x] make develop_test
[x] LocalNet w/ all of the steps outlined in the README

Required Checklist

[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have tested my changes using the available tooling
[x] I have updated the corresponding CHANGELOG

If Applicable Checklist

[ ] I have updated the corresponding README(s); local and/or global
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have added, or updated, mermaid.js diagrams in the corresponding README(s)
[ ] I have added, or updated, documentation and mermaid.js diagrams in shared/docs/* if I updated shared/*README(s)

@bryanchriswhite I've removed @gokutheengineer from reviewing this PR so he can focus on downloading and applying blocks, but would appreciate if you could take a look.
We need to prioritize this to make sure we can move > 5 blocks at any point in time.

Merged with main and reran everything to make sure that it still works.

@deblasis How about now? :)


Reorganize test directory structure

Move all functions for benchmarks into a single file in the testproject directory.
Except subdirectory with single file for runner discovery test such that we can check the amount of discovered files and still add new functions or files in the testproject directory
Add tags to functions and filter on them in function collection of tests. As such, we have direct association and control over the available functions associated with a test while simultaneously keeping the flexibility to add more functions. Also this serves as a smoke test for the tags.

Closes https://github.com/aai-institute/nnbench/issues/13

Nice work, but I think we should advertise semantic structure of the benchmarks on the file level as well.
By that, I mean that similar benchmarks should be grouped in the same file, with supporting tags like you did in this PR. For instance, take a look at how JAX does it: https://github.com/google/jax/tree/main/benchmarks
By looking at that tree, you would know immediately which file to check if you were tasked with e.g. looking up a differential equation solver benchmark or a matrix inversion benchmark.
My proposal: Rename the testproject folder to benchmarks (or testbenchmarks or something), keep the semantic tags, and make a file for each larger test (e.g. one for pure @nnbench.benchmark collection (+failure cases?), one for @nnbench.parametrize collection, etc.)
Then, in each respective test, collect on the single corresponding benchmark file only.


db2start throws SQL1042C  An unexpected system error occurred.

Trying to deploy on Mac (macOS High Sierra)
Created a /db2 folder on the host, added /db2 mount point via Docker  - Preferences
Ran the following -
docker run -i -t --privileged=true --name="db2inst1" -p 50000:50000 -v /db2:/home angoca/db2-instance
./createInstance
su - db2inst1
. ~db2inst1/sqllib/db2profile
su - db2inst1
db2inst1@ace6e0af1103:~$ db2start
SQL1042C  An unexpected system error occurred.
db2 diag log shows -
2017-12-13-<IP_ADDRESS>8165+000 E7247E1026            LEVEL: Error (OS)
PID     : 7930                 TID :<PHONE_NUMBER>23008 PROC : db2star2
INSTANCE: db2inst1             NODE : 000
HOSTNAME: ace6e0af1103
FUNCTION: DB2 UDB, oper system services, sqloopenp, probe:80
MESSAGE : ZRC=0x870F0002=-2029060094=SQLO_BPSE "Debug logic error detected"
DIA8501C A buffer pool logic error has occurred.
CALLED  : OS, -, open                             OSERR: EINVAL (22)
DATA #1 : Codepath, 8 bytes
5:11:18:20:24:40
DATA #2 : File name, 55 bytes
/home/db2inst1/sqllib/ctrlha/.db2.000.ace6e0af1103.pgrp
DATA #3 : SQO Open File Options, PD_TYPE_SQO_FILE_OPEN_OPTIONS, 4 bytes
SQLO_CRTREV, SQLO_READWRITE, SQLO_SHAREWRITE, SQLO_FORCE_NON_BUFFERED, SQLO_WRITETHRU, SQLO_SECURE
DATA #4 : Hex integer, 4 bytes
0x000001B4
DATA #5 : signed integer, 4 bytes
0
DATA #6 : Hex integer, 4 bytes
0x00004000
DATA #7 : String, 105 bytes
Search for ossError*Analysis probe point after this log entry for further
self-diagnosis of this problem.

Hi
I am having the same problem and I also have mac OS Sierra


Suggestions mostly about I/O

Dear Bryant,
I would like to suggest and implement the following changes:

Add support for observations in SAC format. Sometimes it can be useful to read metadata included on the SAC file headers. For instance, reading the source-receiver distance in order to compute a measurement window based on a predefined apparent velocity.

Allow observations and synthetics to have a different data format. The above modification would require this. Currently, both observations and synthetics must have the same format and SPECFEM cannot output waveforms in SAC.

Remove requirement: all synthetics must have a corresponding observation. According to "_setup_quantify_misfit" (preprocess/default.py line 344), the number of observations and synthetics must be the same. However, there might be situations where not all synthetics have an observation. For instance, one event might not be recorded at one or more stations defined on the STATIONS file.

Initialize adjoint traces by reading the STATIONS file. The function "initialize_adjoint_traces" (preprocess/default.py line 296) reads the variable "data_filenames" which lists the file names of the observations. This will cause adjoint sources from stations with no observations not to be initialized. This can be avoided by initializing the adjoint traces by setting their name according to the STATIONS file.

Additionally, I have a question. Are the adjoint sources being initialized at all? I see the function "initialize_adjoint_traces" (preprocess/default.py line 296) is defined but I cannot find any part of the code where it is called.
Finally, on which branch I should include my changes? There are more additions I would like to add in the future.
Best,
Eduardo Valero.
PhD student at KAUST.

Hi @evcano, this all looks great! Thank you for taking the time to look through the code and determine points for improvement, I admit the default preprocessing module could use some work so I'd be very happy for you to implement these changes.

Add support for observations in SAC format.

I agree this would be useful. My tendency has been to grab metadata from the Specfem STATIONS and CMTSOLUTION (or other source types) files and validate via station names since it's guaranteed that these files will be available, but I think a separate check on the availability of SAC headers would be useful.
I also think that using this metadata to compute measurement windows would be a very nice feature and a great addition to the module.

Allow observations and synthetics to have a different data format.

Yes, totally agree this would be useful. Because I tend to use Pyatoa to do my preprocessing, which has some logic trees to determine data format, this is not something I thought much about.
Although I will say that the 3D_GLOBE version of SPECFEM can output SAC formatted seismograms, so it could be useful to check how those are formatted and ensure SeisFlows can handle them.

Remove requirement: all synthetics must have a corresponding observation

Yes you're right, there is no hard check that ensures that the obs data available matches the syn data.
I think the restriction can be left in, however there needs to be a check at L355 here
https://github.com/adjtomo/seisflows/blob/4365b9c3ff2d6805e5d4ee7b2fba6eab887145eb/seisflows/preprocess/default.py#L353-L359
that discards observations which do not have a matching synthetic, otherwise the "quantify_misfit" function may mismatch files as it loops through data.

Initialize adjoint traces by reading the STATIONS file.

Good catch, I think my plan was to scrap the adjoint source initialization entirely which is why this function is not called. Instead I would prefer to let the "quantify_misfit" function write everything out based on the available synthetic data.
The initialization is a leftover from the old codebase and I am not sure it is necessary.

Finally, on which branch I should include my changes? There are more additions I would like to add in the future.

Please feel free to submit PRs to the devel branch, and we can code review and iterate from there. Happy to talk through the process to determine how changes should be implemented here in this issue.
Thanks again for proposing these changes, looking forward to seeing the PR :)

Hi @bch0w,
I submitted a PR addressing the first two points of this issue.
Please see my commit to check how I adress point 3: 8cbe5d8

Hi @evcano, just letting you know I had a look at your previous PR and it looked great. Looking forward to the updated PR

The suggestions stated on this issue were merged on PR #155. Issue closed.


Fixed issue in digital twins sample in deserializing into offsetDateTime

OffsetDateTime wasn't be deserialized into correctly because the mapper saw the property as a string. It isn't ideal, but defining the type in our DigitalTwinPropertyMetadata as a String instead of an OffsetDateTime at least lets our sample run as expected.
Also make the BasicDigitalTwinMetadata's property metadata map contain DigitalTwinPropertyMetadata values instead of object values

Closing this PR as I found out why the mapper in our client couldn't parse date times from strings

https://github.com/Azure/azure-sdk-for-java/pull/16975 is the correct solution


updated web site to 6.4.0.CR1 and removed nearly everything linking t…

Please review this PR
The web is not yet published, first you have to look if it is OK like this.
There is still a thing that does have to do eng-ops. When a directory on filemgmt.jboss.org for jbpm has the right permission the last link to sourceforge https://sourceforge.net/projects/jbpm/files/jBPM 6/ can be removed.

@mbiarnes there seems to be a merge conflict. Could you please resolve it?
I've quickly scrolled through the changes and it looks good, thanks!

@psiroky merge conflicts resolved

Merged. @mbiarnes could you please make sure to publish the pages?


Static UI PR preview

A preview of the PR that would be made to source repo

Some missing changes at this point:

Emode enable

Functional sorting
Charts in pool details screens
Help tooltip and proper font size


Duplicate liberty deploy being run on a multi module project

Steps to reproduce

Run mvn io.openliberty.tools:liberty-maven-plugin.3.3.5-M3-SNAPSHOT:dev on the typeE from https://github.com/turkeylurkey/lmp-multimodules. Notice dev mode starts normally.
Stop dev mode
Add a src/main/java directory with a class to the ear module.
Run mvn io.openliberty.tools:liberty-maven-plugin.3.3.5-M3-SNAPSHOT:dev again, notice that after dev mode starts, liberty:deploy runs again between the war test compilation and ear source compilation:

[INFO] Running liberty:deploy
[INFO] CWWKM2102I: Using artifact based assembly archive : io.openliberty:openliberty-kernel:null:<IP_ADDRESS>:zip.
[INFO] CWWKM2102I: Using installDirectory : /Users/kathrynkodama/Desktop/test/lmp-multimodules/testCases/typeE/pom/target/liberty/wlp.
[INFO] CWWKM2102I: Using serverName : defaultServer.
[INFO] CWWKM2102I: Using serverDirectory : /Users/kathrynkodama/Desktop/test/lmp-multimodules/testCases/typeE/pom/target/liberty/wlp/usr/servers/defaultServer.
[INFO] Copying 1 file to /Users/kathrynkodama/Desktop/test/lmp-multimodules/testCases/typeE/pom/target/liberty/wlp/usr/servers/defaultServer
[INFO] CWWKM2144I: Update server configuration file server.xml from /Users/kathrynkodama/Desktop/test/lmp-multimodules/testCases/typeE/pom/src/main/liberty/config/server.xml.
[INFO] CWWKM2185I: The liberty-maven-plugin configuration parameter "appsDirectory" value defaults to "apps".
[INFO] CWWKM2160I: Installing application guide-maven-multimodules-ear.ear.xml.
[INFO] Parsing the server file /Users/kathrynkodama/Desktop/test/lmp-multimodules/testCases/typeE/pom/target/liberty/wlp/usr/servers/defaultServer/server.xml for features and includes.
[INFO] Parsing the server file /Users/kathrynkodama/Desktop/test/lmp-multimodules/testCases/typeE/pom/target/liberty/wlp/usr/servers/defaultServer/configDropins/overrides/liberty-plugin-variable-config.xml for features and includes.
[INFO] Copying 1 file to /Users/kathrynkodama/Desktop/test/lmp-multimodules/testCases/typeE/pom/target/liberty/wlp/usr/servers/defaultServer
[INFO] CWWKM2144I: Update server configuration file server.xml from /Users/kathrynkodama/Desktop/test/lmp-multimodules/testCases/typeE/pom/src/main/liberty/config/server.xml.
[INFO] CWWKM2001I: Invoke command is [/Users/kathrynkodama/Desktop/test/lmp-multimodules/testCases/typeE/pom/target/liberty/wlp/bin/server, debug, defaultServer].
[INFO]
[INFO] Listening for transport dt_socket at address: 7777
[INFO] Launching defaultServer (Open Liberty <IP_ADDRESS>/wlp-1.0.54.cl210720210629-1900) on Eclipse OpenJ9 VM, version 11.0.11+9 (en_CA)
[INFO] [AUDIT   ] CWWKE0001I: The server defaultServer has been launched.
[INFO] [AUDIT   ] CWWKG0093A: Processing configuration drop-ins resource: /Users/kathrynkodama/Desktop/test/lmp-multimodules/testCases/typeE/pom/target/liberty/wlp/usr/servers/defaultServer/configDropins/overrides/liberty-plugin-variable-config.xml
[INFO] [AUDIT   ] CWWKZ0058I: Monitoring dropins for applications.
[INFO] CWWKM2010I: Searching for CWWKF0011I: in /Users/kathrynkodama/Desktop/test/lmp-multimodules/testCases/typeE/pom/target/liberty/wlp/usr/servers/defaultServer/logs/messages.log. This search will timeout after 90 seconds.
[INFO] [AUDIT   ] CWWKT0016I: Web application available (default_host): http://<IP_ADDRESS>:9080/converter/
[INFO] [AUDIT   ] CWWKZ0001I: Application guide-maven-multimodules-ear started in 0.241 seconds.
[INFO] [AUDIT   ] CWWKF0012I: The server installed the following features: [el-3.0, jsp-2.3, servlet-3.1].
[INFO] [AUDIT   ] CWWKF0011I: The defaultServer server is ready to run a smarter planet. The defaultServer server started in 6.045 seconds.
[INFO] CWWKM2015I: Match number: 1 is [2021-07-08, 15:21:14:143 EDT] 00000038 com.ibm.ws.kernel.feature.internal.FeatureManager            A CWWKF0011I: The defaultServer server is ready to run a smarter planet. The defaultServer server started in 6.045 seconds..
[INFO] ************************************************************************
[INFO] *    Liberty is running in dev mode.
[INFO] *        To run tests on demand, press Enter.
[INFO] *        To restart the server, type 'r' and press Enter.
[INFO] *        To stop the server and quit dev mode, press Ctrl-C or type 'q' and press Enter.
[INFO] *
[INFO] *    Liberty server port information:
[INFO] *        Liberty server HTTP port: [ 9080 ]
[INFO] *        Liberty debug port: [ 7777 ]
[INFO] ************************************************************************
[INFO] guide-maven-multimodules-jar source compilation was successful.
[INFO] guide-maven-multimodules-jar tests compilation was successful.
[INFO] guide-maven-multimodules-war source compilation was successful.
[INFO] guide-maven-multimodules-war tests compilation was successful.
[INFO] Running liberty:deploy
[INFO] CWWKM2102I: Using artifact based assembly archive : io.openliberty:openliberty-kernel:null:<IP_ADDRESS>:zip.
[INFO] CWWKM2102I: Using installDirectory : /Users/kathrynkodama/Desktop/test/lmp-multimodules/testCases/typeE/pom/target/liberty/wlp.
[INFO] CWWKM2102I: Using serverName : defaultServer.
[INFO] CWWKM2102I: Using serverDirectory : /Users/kathrynkodama/Desktop/test/lmp-multimodules/testCases/typeE/pom/target/liberty/wlp/usr/servers/defaultServer.
[INFO] Copying 1 file to /Users/kathrynkodama/Desktop/test/lmp-multimodules/testCases/typeE/pom/target/liberty/wlp/usr/servers/defaultServer
[INFO] CWWKM2144I: Update server configuration file server.xml from /Users/kathrynkodama/Desktop/test/lmp-multimodules/testCases/typeE/pom/src/main/liberty/config/server.xml.
[INFO] CWWKM2185I: The liberty-maven-plugin configuration parameter "appsDirectory" value defaults to "apps".
[INFO] CWWKM2160I: Installing application guide-maven-multimodules-ear.ear.xml.
[INFO] CWWKM2010I: Searching for CWWKZ0001I.*guide-maven-multimodules-ear in /Users/kathrynkodama/Desktop/test/lmp-multimodules/testCases/typeE/pom/target/liberty/wlp/usr/servers/defaultServer/logs/messages.log. This search will timeout after 40 seconds.
[INFO] CWWKM2015I: Match number: 1 is [2021-07-08, 15:21:14:127 EDT] 00000041 com.ibm.ws.app.manager.AppMessageHelper                      A CWWKZ0001I: Application guide-maven-multimodules-ear started in 0.241 seconds..
[INFO] [AUDIT   ] CWWKT0017I: Web application removed (default_host): http://<IP_ADDRESS>:9080/converter/
[INFO] guide-maven-multimodules-ear source compilation was successful.
[INFO] [AUDIT   ] CWWKZ0009I: The application guide-maven-multimodules-ear has stopped successfully.
[INFO] [AUDIT   ] CWWKT0016I: Web application available (default_host): http://<IP_ADDRESS>:9080/converter/
[INFO] [AUDIT   ] CWWKZ0003I: The application guide-maven-multimodules-ear updated in 0.054 seconds.
[INFO] guide-maven-multimodules-ear tests compilation was successful.
[INFO] guide-maven-multimodules-pom tests compilation was successful.

Expected Behaviour
liberty:deploy should only run once on startup

Since the Maven EAR lifecycle does not include source compilation, dev mode should skip source compilation for EAR modules.  It should still recompile tests in case the user configures integration tests, for example in https://github.com/OpenLiberty/guide-maven-multimodules


💅🏻 How to handle styling.

What are approach are we using for styling? Tailwind, Twind, Styled components, emotion... there's soo many options.

Css-in-js - Emotion =)

Css-in-js - Emotion =)

I think tailwind is a good approach and theres tailwind in js with twind
https://github.com/tw-in-js/twind

I think tailwind is a good approach and theres tailwind in js with twind
https://github.com/tw-in-js/twind

I think either emotion with their Object Style syntax or tailwind/twind
both options don't require naming and make it easier to not have unused CSS in the code or class names names like "wrapper"

I think either emotion with their Object Style syntax or tailwind/twind
both options don't require naming and make it easier to not have unused CSS in the code or class names names like "wrapper"

Hopefully this doesn't become a divisive topic.
I think we should use emotion with a design system based on CSS custom properties. I'm not a fan of tailwind; I think it clutters the html and I don't really see much benefit in using it other than it's hot right now.
With emotion, I'm a fan of using the styled.div syntax because it's closer to native CSS, but I'm open to hearing how the object style syntax might be better.

Hopefully this doesn't become a divisive topic.
I think we should use emotion with a design system based on CSS custom properties. I'm not a fan of tailwind; I think it clutters the html and I don't really see much benefit in using it other than it's hot right now.
With emotion, I'm a fan of using the styled.div syntax because it's closer to native CSS, but I'm open to hearing how the object style syntax might be better.

I think we should use emotion with a design system based on CSS custom properties. I'm not a fan of tailwind; I think it clutters the html and I don't really see much benefit in using it other than it's hot right now.
With emotion, I'm a fan of using the styled.div syntax because it's closer to native CSS, but I'm open to hearing how the object style syntax might be better.

As far as I know, both emotion/style and emotion/(core/react) are the same expect that with styled you create an HTML element with the css. on the other side, we add the css to the HTML tag using the css attribute (css can take css`` => for css string syntax  or an object for the style object syntax . =)
I hope this helps ^_^

I think we should use emotion with a design system based on CSS custom properties. I'm not a fan of tailwind; I think it clutters the html and I don't really see much benefit in using it other than it's hot right now.
With emotion, I'm a fan of using the styled.div syntax because it's closer to native CSS, but I'm open to hearing how the object style syntax might be better.

As far as I know, both emotion/style and emotion/(core/react) are the same expect that with styled you create an HTML element with the css. on the other side, we add the css to the HTML tag using the css attribute (css can take css`` => for css string syntax  or an object for the style object syntax . =)
I hope this helps ^_^

As far as I know, both emotion/style and emotion/(core/react) are the same expect that with styled you create an HTML element with the css. on the other side, we add the css to the HTML tag using the css attribute (css can take css`` => for css string syntax or an object for the style object syntax . =)
I hope this helps ^_^

So is it a purely stylistic choice? I've used the template strings syntax because it separates the styles from the html and, which I find far easier to read than having them inline like this:

    This is orange on a big screen and darkorchid on a small
    screen.

The css props with template strings like this:
const paragraph = css`
  color: turquoise;
`
render(

    Some text.

)

is closer to how I would approach it; both the jsx and css are easier to read.
However, with the styled.div syntax you get the advantage of semantic naming, making it easy to read and understand what the component is actually for, you can easily export those components to reuse elsewhere, and it's written like native css
const Card = styled.div`
  padding: 1rem;
`
const Description = styled.p`
  color: purple;
`

render(
  <Card>
    <Description>This is the description.</Description>
  </Card>
)

As far as I know, both emotion/style and emotion/(core/react) are the same expect that with styled you create an HTML element with the css. on the other side, we add the css to the HTML tag using the css attribute (css can take css`` => for css string syntax or an object for the style object syntax . =)
I hope this helps ^_^

So is it a purely stylistic choice? I've used the template strings syntax because it separates the styles from the html and, which I find far easier to read than having them inline like this:

    This is orange on a big screen and darkorchid on a small
    screen.

The css props with template strings like this:
const paragraph = css`
  color: turquoise;
`
render(

    Some text.

)

is closer to how I would approach it; both the jsx and css are easier to read.
However, with the styled.div syntax you get the advantage of semantic naming, making it easy to read and understand what the component is actually for, you can easily export those components to reuse elsewhere, and it's written like native css
const Card = styled.div`
  padding: 1rem;
`
const Description = styled.p`
  color: purple;
`

render(
  <Card>
    <Description>This is the description.</Description>
  </Card>
)

I'm good with emotion and the styled components approach ⬆

I'm good with emotion and the styled components approach ⬆

Naming everything is a double-edged sword. it's useful for reusable components but gets annoying for a one-off component that isn't going to be reusable

Naming everything is a double-edged sword. it's useful for reusable components but gets annoying for a one-off component that isn't going to be reusable

@codyarose @merodiro is it possible to combine both methods?
If it is reusable, use styled, otherwise, just use the object syntax???

@codyarose @merodiro is it possible to combine both methods?
If it is reusable, use styled, otherwise, just use the object syntax???

Not everything that needs styling needs to be named too, we can use context styling:
const Article = styled.article`
  // Aticle specific styling
  & > p + p {
    margin-bottom: 10px
  }
`

render(

(...)

(...)

(...)

)

Not everything that needs styling needs to be named too, we can use context styling:
const Article = styled.article`
  // Aticle specific styling
  & > p + p {
    margin-bottom: 10px
  }
`

render(

(...)

(...)

(...)

)

@codyarose @merodiro is it possible to combine both methods?
If it is reusable, use styled, otherwise, just use the object syntax???

I don't really like the idea of mixing styling syntax 🤔

@codyarose @merodiro is it possible to combine both methods?
If it is reusable, use styled, otherwise, just use the object syntax???

I don't really like the idea of mixing styling syntax 🤔

Agreed @YPAzevedo
A mixture of both could be used, but we should probably stick to one syntax. Naming elements can be annoying, but it gets the benefit of semantic intention, which helps other devs and your future self understand the structure. Taking advantage of nesting would cover most cases where there's not much value added by giving the element it's own name.

Agreed @YPAzevedo
A mixture of both could be used, but we should probably stick to one syntax. Naming elements can be annoying, but it gets the benefit of semantic intention, which helps other devs and your future self understand the structure. Taking advantage of nesting would cover most cases where there's not much value added by giving the element it's own name.

Ok, so we are moving with emotion and styled components approach? How should we reach a decision?

Ok, so we are moving with emotion and styled components approach? How should we reach a decision?

@YPAzevedo the people that have commented so far have come to a consensus - maybe you can work with Cody to get this started? :smile:

@YPAzevedo the people that have commented so far have come to a consensus - maybe you can work with Cody to get this started? :smile:

Making a PR to add the packages now.

Making a PR to add the packages now.

Okay, cool. I think for now we should just get emotion installed and ready to use. Not much styling has been done so far, so I'm not really worried about how they're styled right now. Once we get a design system going we can make PRs to refactor those

Okay, cool. I think for now we should just get emotion installed and ready to use. Not much styling has been done so far, so I'm not really worried about how they're styled right now. Once we get a design system going we can make PRs to refactor those

https://github.com/OpenSourceRaidGuild/website/pull/32

https://github.com/OpenSourceRaidGuild/website/pull/32


Feature Request: Slice replacement operation

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): No
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Windows 10
TensorFlow installed from (source or binary): binary
TensorFlow version (use command below): b'unknown' 1.4.0
Python version: 3.6.3 Anaconda
Bazel version (if compiling from source): N/A
GCC/Compiler version (if compiling from source): N/A
CUDA/cuDNN version: N/A
GPU model and memory: N/A
Exact command to reproduce: N/A

Describe the problem
In the last couple of weeks I have answered up to three questions in Stack Overflow (this, this and this) solving essentially the same problem, namely how to replace a slice in one tensor with the contents of (a slice of) another tensor. On the one hand, newer users try to solve it with a slice assignment to a variable, which is easy and intuitive but wrong. On the other hand, even for experience users it can be quite a hassle (my approaches are either to concatenate thing after thing or make comprehensive masks and use tf.where, both of them, I suspect, take more resources than the operation should require).
I think everyone would benefit from a slice replacement operation that returns a tensor with a slice replaced with some values. I do not know about the technical challenges of this (e.g. to keep gradient propagation and so on), but syntactically there is the problem that one cannot use slicing syntax with functions. Like in tf.slice, a couple of begin and size tensors could be passed:
tf.replace_slice(my_tensor, [1, 2], [3, 4], new_values)

But, similarly to how tf.Tensor implements __getitem__ for easy slicing, it would be neat to have a simplified syntax for this. Maybe (not necessarily) something like:
my_tensor = my_tensor.replace[1:4, 2:6].with_values(new_values)

(I was going to say  .with(new_values), but that's a keyword)
It could also be just:
my_tensor = my_tensor[1:4, 2:6].replace_with(new_values)

Which is more similar to how slice assignment works for variables, but that seems harder to implement consistently (the slicing should return not just a regular tensor, and the slicing operation would be created anyway even if it's not necessary).
Source code / logs
N/A

Thank you for your post. We noticed you have not filled out the following field in the issue template. Could you update them if they are relevant in your case, or leave them as N/A? Thanks.
Have I written custom code
OS Platform and Distribution
TensorFlow installed from
TensorFlow version
Bazel version
CUDA/cuDNN version
GPU model and memory
Exact command to reproduce

It has been 15 days with no activity and the awaiting response label was assigned. Is this still an issue?

Not sure if that message is meant for me, the author of the issue, or, more likely, the asignee, but anyway, in case it helps triggering some workflow, yes, it is still an "issue", in the sense that is a feature request that has not been implemented nor rejected.

Nagging Assignee @drpngx: It has been 14 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

We have the inplace_ops which can do update. Could you look into that and see what you think?

/CC @zffchen78

Yes. It's available with a direct import, not via the public API. The question is whether it is what you need. For the strided version, there the XlaDynamicUpdateSlice IIRC. Can you check that?

@drpngx Thanks, yes XlaDynamicUpdateSlice seems exactly like what I was referring to. I see these ops have been added more recently and they do not yet have a public documented API for regular Python graph building but I guess they will eventually, so if it is a feature that is already being worked on maybe the issue can be closed?

If you want to have it exposed the way you describe in the preamble, then we're not working on it AFAIK.

Well yes in principle I was hoping for a general way to access the feature, not necessarily that specific syntax but some public API that is not particular to XLA. Of course you decide whether or not adding this makes sense/is worth the effort.

Nagging Assignee @drpngx: It has been 16 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

This seems useful, tf.replace_slice could be shorthand for the dynamic_slice and concat operations necessary.
I don't think the shorthand syntax you proposed are consistent with other operators we have, so we'd rather hold on those.

Nagging Assignee @drpngx: It has been 14 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @drpngx: It has been 29 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @drpngx: It has been 44 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

This is a feature that I am looking for.  I have tried  DynamicUpdateSlice(original, replacement, start) in my code, but am getting the following error:
NameError: name 'DynamicSliceUpdate' is not defined
@drpngx, can you tell me how to "import" the command?
Thank you!

I'm not sure I understand what is wrong. Are you thinking of @tf_export? Do you more code so that I understand the context?

Is this proposed tf.replace_slice going to be implemented? the only way to do something similar is with tf.scatter_nd_update for a variable. But in essence, it is useless, since it does not support gradient back-prop.  This is a major pitfall for Tensorflow cause the same op can be easily realized in Pytorch.

I made a Python-level implementation of this, at least for the simple case without strides (analogous to tf.slice). Surely it is less efficient (in time and space) than a proper op and kernel, but I think it's quite convenient. It allows me to write something like this:
import tensorflow as tf

with tf.Graph().as_default():
    x = tf.reshape(tf.range(60), (4, 3, 5))
    x2 = replace_in(x)[:2, ..., -3:].with_value([100, 200, 300])
    with tf.Session() as sess:
        print(sess.run(x2))

Which prints:
[[[  0   1 100 200 300]
  [  5   6 100 200 300]
  [ 10  11 100 200 300]]

 [[ 15  16 100 200 300]
  [ 20  21 100 200 300]
  [ 25  26 100 200 300]]

 [[ 30  31  32  33  34]
  [ 35  36  37  38  39]
  [ 40  41  42  43  44]]

 [[ 45  46  47  48  49]
  [ 50  51  52  53  54]
  [ 55  56  57  58  59]]]

The main function is this:
import tensorflow as tf

def replace_slice(input_, replacement, begin, size=None):
    inp_shape = tf.shape(input_)
    if size is None:
        size = tf.shape(replacement)
    else:
        replacement = tf.broadcast_to(replacement, size)
    padding = tf.stack([begin, inp_shape - (begin + size)], axis=1)
    replacement_pad = tf.pad(replacement, padding)
    mask = tf.pad(tf.ones_like(replacement, dtype=tf.bool), padding)
    return tf.where(mask, replacement_pad, input_)

size is optional because in principle it is inferred from replacement, but can be specified to broadcast it.
The nicety of Python-like indexing is supported with this blob of ugly code, which is very likely a subset of similar logic already existing in TensorFlow. I tested it in a few cases and seems to work in general, although it assumes indices are tf.int32 and there may be more special cases I'm not seeing.
class replace_in:
    def __init__(self, tensor):
        self._tensor = tensor
    def __getitem__(self, slices):
        return replace_in._SliceReplacer(self._tensor, slices)
    def with_value(self, replacement):  # Just for convenience in case you skip the indexing
        return replace_in._SliceReplacer(self._tensor, (...,)).with_value(replacement)
    class _SliceReplacer:
        def __init__(self, tensor, slices):
            self._tensor = tensor
            self._slices = slices
        def with_value(self, replacement):
            begin, size = _make_slices_begin_size(self._tensor, self._slices)
            return replace_slice(self._tensor, replacement, begin, size)

# This computes begin and size values for a set of slices
def _make_slices_begin_size(input_, slices):
    if not isinstance(slices, (tuple, list)):
        slices = (slices,)
    inp_rank = tf.rank(input_)
    inp_shape = tf.shape(input_)
    # Did we see a ellipsis already?
    before_ellipsis = True
    # Sliced dimensions
    dim_idx = []
    # Slice start points
    begins = []
    # Slice sizes
    sizes = []
    for i, s in enumerate(slices):
        if s is Ellipsis:
            if not before_ellipsis:
                raise ValueError('Cannot use more than one ellipsis in slice spec.')
            before_ellipsis = False
            continue
        if isinstance(s, slice):
            start = s.start
            stop = s.stop
            if s.step is not None:
                raise ValueError('Step value not supported.')
        else:  # Assumed to be a single integer value
            start = s
            stop = s + 1
        # Dimension this slice refers to
        i_dim = i if before_ellipsis else inp_rank - (len(slices) - i)
        dim_size = inp_shape[i_dim]
        # Default slice values
        start = start if start is not None else 0
        stop = stop if stop is not None else dim_size
        # Fix negative indices
        start = tf.cond(tf.convert_to_tensor(start >= 0), lambda: start, lambda: start + dim_size)
        stop = tf.cond(tf.convert_to_tensor(stop >= 0), lambda: stop, lambda: stop + dim_size)
        dim_idx.append([i_dim])
        begins.append(start)
        sizes.append(stop - start)
    # For empty slice specs like [...]
    if not dim_idx:
        return tf.zeros_like(inp_shape), inp_shape
    # Make full begin and size array (including omitted dimensions)
    begin_full = tf.scatter_nd(dim_idx, begins, [inp_rank])
    size_mask = tf.scatter_nd(dim_idx, tf.ones_like(sizes, dtype=tf.bool), [inp_rank])
    size_full = tf.where(size_mask,
                         tf.scatter_nd(dim_idx, sizes, [inp_rank]),
                         inp_shape)
    return begin_full, size_full

Thanks for this great piece of code! One thing I found out on a MacBook installation: It does not accept float64 as input tensors
Cryptic error:
[[Node: ScatterNd_1 = ScatterNd[T=DT_BOOL, Tindices=DT_INT32](ScatterNd_1/indices, ones_like, ScatterNd_1/shape)]]

@javidcf May I ask you if the above code worked on CPU-only implementation? I cannot get it to work on CPU-version on Mac.

@beniroquai Thank you for your comments. That is strange, it seems to work for me with tf.float64 values, and both in CPU and GPU. I am using TensorFlow v1.12.0 on Windows 10. Unfortunately I don't have access to a Mac system to try there.

Now TF 2.0 comes up with tf.tensor_scatter_nd_update which I think could partly satisfy this feature requirement.

@javidcf,
Could you please take a look and refer to the official doc link and let us know if the issue still persists. Thank you!

@tilakrayal Thank you, yes I think that is pretty much it, it would be great to somehow have slicing syntax support but that resolves the issue.


Example use configuration from k8s configmap

I am not found example how read config map and use to application configuration as resource/application.yaml

@minatorak I think what you are looking for is a configtree feature in spring-boot.
It is documented in the spring boot reference: https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#features.external-config.files.configtree


Add an AppBarDropDownButton

Proposal: Add an AppBarDropDownButton
Summary
There is currently a DropDownButton control, but no corresponding control to place into a commandbar.
Rationale
Adding dropdown menus in a commandbar currently requires adding a (maybe retemplated) AppBarButton with an associated menuflyout. Unfortunately, even if the placement property of the Flyout is set, there is still a gap between both elements:

In comparison, the commandbar menu for secondary controls does not show this issue:

While it is possible to add workarounds to the application (e.g. manipulate the margins of the flyout), this should be handled automatically. As can be seen, the style of both flyout is also different (at least on the current windows insider build)

Functional Requirements

Usage Examples

Detailed Feature Design

Open Questions

@jesbis and @chigy, can you comment on how to disable shadow in MenuFlyout?
@lhak - thank you for this feature proposal. Sounds like you have a reasonable workaround for your scenario. Between your current approach and the option to use AppBarElementContainer to place a DropDownButton into a CommandBar, I don't think it makes sense for us to add a new AppBarDropDownButton class.

Just a little thought about applying default styles to controls based on their container/parent...
TargetType="AppBar/DropDownButton"
Treating the TargetType and Style values more like a path to help make things more conditional?


Dao code generation behaves inconsistent

Given the following example the code generator creates a property in the DAO class for the table:
@UseDao(tables: [
  Portfolio
])
class PortfolioDao extends DatabaseAccessor<AlanDatabase>
    with _$PortfolioDaoMixin {
  // this constructor is required so that the main database can create an instance
  // of this object.
  PortfolioDao(AlanDatabase db) : super(db);
}

Creates the following Mixin:
mixin _$PortfolioDaoMixin on DatabaseAccessor<AlanDatabase> {
  $PortfolioTable get portfolio => attachedDatabase.portfolio;
}

Adding a second table to the above DAO like this:
@UseDao(tables: [
  Portfolio,
  Position
])
class PortfolioDao extends DatabaseAccessor<AlanDatabase>
    with _$PortfolioDaoMixin {
  // this constructor is required so that the main database can create an instance
  // of this object.
  PortfolioDao(AlanDatabase db) : super(db);
}

Will result in a completly empty Mixin as you can see below:
mixin _$PortfolioDaoMixin on DatabaseAccessor<AlanDatabase> {
}

Not a big deal at the end but it could confuse people that are new to dart/moor and might not be the desired behavior for the generator, or am I  wrong?

Is the Position class generated? If so, there's nothing we can do unfortunately: It doesn't exist when moor_generator runs, and in that case the analyzer doesn't recognize the @UseDao annotation at all, so we can't find the class.
I added a test for when the class exists, and that works as expected.

The Position class is table (like the Portfolio class), I don't get the point why one works and the other not? Both should exist when the code generator is running, maybe I don't understand how things are working internally, but it would be interesting to find out why it's not generating the code. If I have some minutes the next days I will have a look, thanks for your feedback

Can you post the definition for the Position class then? If I can reproduce this I'm happy to work on a fix.

Sorry for the delay, below is the code:
import 'package:alan/database/dateTimeHelper.dart';
import 'package:moor/moor.dart';
import 'package:uuid/uuid.dart';

class Positions extends Table {
  TextColumn get id => text().clientDefault(() => Uuid().v4())();
  TextColumn get title => text()();
  TextColumn get isn => text()();
  RealColumn get buy => real().withDefault(Constant(0))();
  RealColumn get amount => real().withDefault(Constant(0))();
  RealColumn get last => real().withDefault(Constant(0))();
  TextColumn get market => text()();
  TextColumn get typeId => text()();
  IntColumn get buyDate => integer()
      .map(const DateTimeConverter())
      .withDefault(currentDateAndTimeInt)();
  Set<Column> get primaryKey => {id};
}

The datetime convert used above would be this:
import 'package:flutter/foundation.dart';
import 'package:moor/moor.dart';

const Expression<int> currentDateAndTimeInt =
    _CustomDateTimeIntExpression("strftime('%s', CURRENT_TIMESTAMP)");

class _CustomDateTimeIntExpression extends CustomExpression<int> {
  @override
  Precedence get precedence => Precedence.primary;

  const _CustomDateTimeIntExpression(String content) : super(content);
}

@immutable
class DateTimeConverter extends TypeConverter<DateTime, int> {
  const DateTimeConverter();

  @override
  DateTime mapToDart(int fromDb) {
    if (fromDb == null) {
      return null;
    }
    final DateTime epochStart = DateTime.utc(1970);
    return epochStart.add(Duration(seconds: fromDb));
  }

  @override
  int mapToSql(DateTime value) {
    if (value == null) {
      return null;
    }
    final utcDate = value.toUtc();
    final DateTime epochStart = DateTime.utc(1970);
    if (utcDate.isBefore(epochStart)) return 0;
    return utcDate.difference(epochStart).inSeconds.abs();
  }
}

Sorry for the delay, below is the code:
import 'package:alan/database/dateTimeHelper.dart';
import 'package:moor/moor.dart';
import 'package:uuid/uuid.dart';

class Positions extends Table {
  TextColumn get id => text().clientDefault(() => Uuid().v4())();
  TextColumn get title => text()();
  TextColumn get isn => text()();
  RealColumn get buy => real().withDefault(Constant(0))();
  RealColumn get amount => real().withDefault(Constant(0))();
  RealColumn get last => real().withDefault(Constant(0))();
  TextColumn get market => text()();
  TextColumn get typeId => text()();
  IntColumn get buyDate => integer()
      .map(const DateTimeConverter())
      .withDefault(currentDateAndTimeInt)();
  Set<Column> get primaryKey => {id};
}

The datetime convert used above would be this:
import 'package:flutter/foundation.dart';
import 'package:moor/moor.dart';

const Expression<int> currentDateAndTimeInt =
    _CustomDateTimeIntExpression("strftime('%s', CURRENT_TIMESTAMP)");

class _CustomDateTimeIntExpression extends CustomExpression<int> {
  @override
  Precedence get precedence => Precedence.primary;

  const _CustomDateTimeIntExpression(String content) : super(content);
}

@immutable
class DateTimeConverter extends TypeConverter<DateTime, int> {
  const DateTimeConverter();

  @override
  DateTime mapToDart(int fromDb) {
    if (fromDb == null) {
      return null;
    }
    final DateTime epochStart = DateTime.utc(1970);
    return epochStart.add(Duration(seconds: fromDb));
  }

  @override
  int mapToSql(DateTime value) {
    if (value == null) {
      return null;
    }
    final utcDate = value.toUtc();
    final DateTime epochStart = DateTime.utc(1970);
    if (utcDate.isBefore(epochStart)) return 0;
    return utcDate.difference(epochStart).inSeconds.abs();
  }
}

This reminds me of some of the problems that I have when I use converters, can you try without the converter?

This reminds me of some of the problems that I have when I use converters, can you try without the converter?

I just gave it a spin, the same behavior  DAO is generated empty (no properties)
Like I mentioned in the start, not a big deal just curious for the why

I just gave it a spin, the same behavior  DAO is generated empty (no properties)
Like I mentioned in the start, not a big deal just curious for the why


nfeh.desktop: Categories does not have a semicolon (';') as trailing character

desktop-file-validate does not accept nfeh.desktop:
error: value "Utility" for string list key "Categories" in group "Desktop Entry" does not have a semicolon (';') as trailing character

Reference:
https://travis-ci.org/AppImage/AppImageHub/builds/266227270#L543

Thanks for creating the issue, but this is beyond my control. I'm using electron-builder for creating the packages and that is what produces the desktop file.
Just throwing out ideas here, How about running a sed command to remove the trailing semicolon before you run desktop-file-validate?

electron-builder offers native support for this since v19.22.1.
References:
https://github.com/AppImage/AppImageHub/issues/2
https://github.com/electron-userland/electron-builder/releases/tag/v19.22.1

Okay, so updating the dependencies should be enough right?
I'm working on a new app that works across DEs and WMs, gonna end this one soon. I'll try to make the necessary changes to this as soon as I can. PRs are of course welcome :smile:

I hope so, yes.


CvRDT or CmRDT?

Just found this cool library. Thanks for the awesome work you've put into it!
I'm relatively new to the ideas underlying CRDTs but having a great time digging into various research papers and other sources on the subject. I plan to dig into your code more deeply soon, but was wondering if you could provide any additional information about how the CRDTs are implemented in this library from a high level? For example, in the readme, you mention "As long as ops from a site are executed in the order they were generated, the CRDT will maintain consistenct." Does that mean that this library is built out using CmRDTs and that I have to guarantee delivery order over my transport?
Thanks in advance!

Found the answer here: https://github.com/alex-shapiro/ditto/issues/100
Very cool.


A way to silence 'x' is not accessed

Say one has this code:
    def has_delete_permission(self, request, obj=None):
        return False

It will say obj is not accessed, so then one changes it to:
    def has_delete_permission(self, request, _=None):  # _ = obj
        return False

Then it says request is not accessed. Renaming request to _, also doesn't work because then its a duplicate argument. renaming it to __ doesnt silence it either. Would be nice to silence the warning without losing what the arguments are, and when there are more than one.
Describe the feature you'd like
A way to silence the warning when its known they are not accessed, e.g. A function whose prototype may change, but must always return False is marked that some of the args are not accessed with the comment # pyls_not_accesed
    def has_change_permission(self, *args, **kwargs):  # pyls_not_accesed
        return False

Thank you for the report. This project is no longer active. If you are using the Python language server in VSCode, the language server you are using is Pylance and please the http://github.com/microsoft/pylance-release to report issues.
If you are using Visual Studio, then, please use http://github.com/microsoft/PTVS to report issues.
thank you


MINOR: A few cleanups in BrokerToControllerChannelManager

I made a few edits to make the code style more consistent while reading that file.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

Maybe we can use the file in checkstyle/checkstyle.xml to force scala code style, but this is a big change and should be done with the approval of at least 3 PMC members. 🤔

@showuon Could you review this one? The changes are trivial.

I'll check later.

Failed tests are unrelated:
    Build / JDK 17 and Scala 2.13 / org.apache.kafka.streams.integration.PurgeRepartitionTopicIntegrationTest.shouldRestoreState
    Build / JDK 17 and Scala 2.13 / org.apache.kafka.streams.integration.PurgeRepartitionTopicIntegrationTest.shouldRestoreState
    Build / JDK 8 and Scala 2.12 / org.apache.kafka.connect.mirror.integration.MirrorConnectorsIntegrationSSLTest.testReplication()
    Build / JDK 8 and Scala 2.12 / org.apache.kafka.connect.integration.ExampleConnectIntegrationTest.testSinkConnector
    Build / JDK 8 and Scala 2.12 / kafka.api.PlaintextEndToEndAuthorizationTest.testNoConsumeWithoutDescribeAclViaSubscribe()
    Build / JDK 8 and Scala 2.12 / org.apache.kafka.streams.integration.PurgeRepartitionTopicIntegrationTest.shouldRestoreState
    Build / JDK 8 and Scala 2.12 / org.apache.kafka.streams.integration.NamedTopologyIntegrationTest.shouldAllowRemovingAndAddingNamedTopologyToRunningApplicationWithMultipleNodesAndResetsOffsets
    Build / JDK 11 and Scala 2.13 / org.apache.kafka.streams.integration.PurgeRepartitionTopicIntegrationTest.shouldRestoreState


[WIP] Fixes #181 and adds support for OAuth2 / Okta.

This PR Fixes #181 and provides additional examples for using TLS with S4K and OAuth2.
Also, it's a WIP until I finish doing some testing.
Remaining items:

Resolve auth failures from Prometheus. This requires adding an OAuth2 section to the PodMonitors provided in this PR once it's merged into master.
(Optional) Resolve broker restart that occurs when attemptAuthenticationProviderToken: "true". See note: https://github.com/datastax/pulsar-openid-connect-plugin#using-authenticationprovidertoken
Investigate/resolve auth issues with S4K

Superseded by https://github.com/datastax/pulsar-helm-chart/pull/278


Validate the resulting feed

Both by parsing the RSS for expectations, and by calling the W3 validation API.
To note, there are some gems out there, but they haven't been updated in 3+ years, and given one call, things were simple enough to implement with a post request + nokigiri.
Fixes #16

Nifty!

:cool:


error: with the ' _ecm.Componentcomponents::JointPosition' method

OS: Ubuntu 18.04 (installed using Virtual Machine)
binary/source: source
version

[Msg] Ignition Gazebo Server v4.7.0
[Msg] Ignition Gazebo GUI    v4.7.0

I got this error while calculating joints position using the _ecm.Component<components::JointPosition> method.
error: cannot convert ‘const ignition::gazebo::v3::components::Component<std::vector<double>, ignition::gazebo::v3::components::JointPositionTag, ignition::gazebo::v3::serializers::VectorDoubleSerializer>*’ to ‘float’ in initialization

 float leftAileron = _ecm.Component<components::JointPosition>(this->joint[2500]);

Associated code snippet
void CessnaPlugin::PublishState(const EntityComponentManager &_ecm)

{
    IGN_PROFILE("CessnaPlugin::PublishState");

    // All the lines are shown below throw this error

    float propellerRpms = _ecm.ComponentData<components::JointVelocity>(this->joint[6])/(2.0*M_PI)*60.0;
    float propellerSpeed = propellerRpms / this->propellerMaxRpm;
    float leftAileron = _ecm.Component<components::JointPosition>(this->joint[2500]);
    float leftFlap =  _ecm.Component<components::JointPosition>(this->joint[1]);
    float rightAileron =  _ecm.Component<components::JointPosition>(this->joint[2]);
    float rightFlap =  _ecm.Component<components::JointPosition>(this->joint[3]);
    float elevators =  _ecm.Component<components::JointPosition>(this->joint[4]);
    float rudder =  _ecm.Component<components::JointPosition>(this->joint[5]);
}

Additional Context
I am trying to get the values in float. [please refer cessna.proto for this.]
This method _ecm.Component<components::JointPosition> has 'std::vector(double)' type which can't be converted to 'float'.
Note: In the code snippet, the 4 in this->joint[4]  comes from here
Cessna parameters as described in plugin class
class ignition::gazebo::systems::CessnaPluginPrivate
{
   public: static const unsigned int kLeftAileron  = 0;

    public: static const unsigned int kLeftFlap     = 1;

    public: static const unsigned int kRightAileron = 2;

    public: static const unsigned int kRightFlap    = 3;

    public: static const unsigned int kElevators    = 4;

    public: static const unsigned int kRudder       = 5;

    public: static const unsigned int kPropeller    = 6;
};

Since the automatically generated file cessna.pb.h can't be edited, I could find any solution for this. Any suggestion is appreciated.
P.S. This cessna plugin works completely fine on ignition gazebo edifice and gazebo-11 when tested.
Thanks

A joint in its most generic form can have more than one degree of freedom. This is the reason why the JointPosition component stores a vector:
https://github.com/ignitionrobotics/ign-gazebo/blob/a41cf80049c07977079d0b215398dc4225b63038/include/ignition/gazebo/components/JointPosition.hh#L38-L39
In 99% of cases, you're using either a revolute or prismatic joint, therefore the vector contains only one element:
const auto& jointPosition = _ecm.ComponentData<components::JointVelocity>(jointEntity);
assert(jointPosition.size() == 1);
const float position = jointPosition[0];

Thanks @diegoferigo

Hello @diegoferigo
I am trying to use _ecm.setComponentData() in my gimbal plugin. The error is in this line
auto error = (position - this->dataPtr->command);

Complete error
 error: invalid operands of types ‘const ignition::gazebo::v5::components::Component<std::vector<double>, ignition::gazebo::v5::components::JointPositionTag, ignition::gazebo::v5::serializers::VectorDoubleSerializer>*’ and ‘double’ to binary ‘operator-’

Code snippet
void GimbalSmall2dPlugin::PostUpdate(const UpdateInfo &_info,
    	const EntityComponentManager &_ecm)

{
	IGN_PROFILE("GimbalSmall2dPlugin::PostUpdate");

	auto position = _ecm.Component<components::JointPosition>(this->dataPtr->tiltJoint[0]);

	if (_info.simTime > this->dataPtr->lastUpdateTime)
	{

		auto dt = (this->dataPtr->lastUpdateTime - _info.simTime);
		auto error = (position - this->dataPtr->command);
		auto force = this->dataPtr->pid.Update(error, dt);
		_ecm.SetComponentData(this->dataPtr->tiltJoint, components::JointForceCmd(force));
		this->dataPtr->lastUpdateTime = _info.simTime;

	}

	static int i = 1000;
	if(++i > 100)
	{
		i=0;
		std::stringstream ss;
		ss << position;
		msgs::StringMsg m;
		m.set_data(ss.str());
		this->dataPtr->pub.Publish(m);
	}

	IGN_PROFILE_END();
}

Any suggestion for this?


Add thumbnails for iFrames

iFrames take too long to load (in Video page) and it would be great to have thumbnails until they appear to prevent people from living the page before the videos are showing.

The issue can be corrected by removing iFrames from the page (replacing them by thumbnails), and just adding links to YouTube videos.


[Web, Chrome 92] AudioElement is not getting disposed correctly

Chrome 92 has introduced a limit on the number of audio tags that can be allocated per tab. 75 for desktop, 40 for mobile. This causes issues when playing a lot of audio files, since currently the AudioElements are not removed after playing.
Full Description
AudioPlayers currently does not remove created AudioElements from the DOM. This obviously leads to issues when the browser has a hard limit of the number of AudioElements that can be active at once. Even calling setUrl(String url) will cause the issue to pop up eventually, since a new AudioElement is created every time.
I've added a workaround that seems to fix the issue, but I'm not sure this would be the best way to solve it.
In audioplayers_web.dart change release() and start(double position) to the following
void release() {
    player?.src = '';
    player?.remove();
    _cancel();
    player = null;
  }

void start(double position) {
    isPlaying = true;
    if (currentUrl == null) {
      return; // nothing to play yet
    }
    if (player == null) {
      recreateNode();
    }
    player?.play();
    player?.currentTime = position;
    player?.onEnded.listen((event) {
      release();
    });
  }

player?.src = ''; is important, since only calling player?.remove() won't properly destroy the AudioElement.
Code to Reproduce
Easiest way to reproduce is ofcourse to create an app with the latest AudioPlayers (0.19.1), and play a lot of audio using any of the available methods. Personally I'm using AudioCache but as a quick test I'm sure you could do something like
for(int i = 0; i < 100; i++) {
  AudioPlayer().play('assets/audio/sound.mp3');
}

Log Errors
App error:
NotSupportedError: Failed to load because no supported source was found.

 See crbug.com/1144736#c27

Files/URLs/Sources

audioplayers/lib/src/audioplayers_web.dart

Platforms

OS: web, Chrome
OS version: Chrome 92.0.4515.107
Device: physical, Windows 10
flutter version: Flutter 2.2.3 stable
audioplayers version: 0.19.1

Is this still a thing in audioplayers: ^1.1.0 ? If yes, do you want to make a PR for this?


[Unsplash] Change desktop background on all monitors

Extension
https://www.raycast.com/eggsy/unsplash
Description
This is an awesome extension. Use it daily. But it only ever affects one desktop. It should change all desktops or have options for this.
Who will benefit from this feature?
No response
Anything else?
No response

I'll see what I can do!

Hey @jackmsvaughan,
Thank you for the issue, I'd like to point out that the feature you requested already exists under extension settings which you can find by simply pressing Cmd + Option + , while hovering any of the commands from Unsplash; then you'll simply scroll down through the list on the right and find the option "Apply Wallpaper To"... Changing that setting to "Every Desktop" should help you get what you want!

Let me know if there's anything else, and please react/respond so I can close the issue! I'm not sure if the setting works since I don't have a second monitor installed, this will help me fix it if it wasn't working! Thanks.

Perhaps there can be two separate commands for setting wallpaper to current desktop and every desktop? That could be useful and simple to integrate.

That's a really great idea @yug2005! I'm working on a huge update right now, I will add a separate action to set on each display and remove that setting there 🤞


Client makes taiko-geth lag to last verified block

I updated to the latest taiko-client on git, commit https://github.com/taikoxyz/taiko-client/commit/949f376bc0e3772e8bd0ad3bad9ae5263c1b57b8 on branch grimsvotn
My node was then stuck on the "Last Verified Block" and didn't sync to the latest block on L2
Constant state of 30 minute lag. I reset the node and re-synced 4 times and it was consistent.
The logs from the execution engine (taiko-geth)
INFO [06-16|19:50:32.473] Imported new potential chain segment     number=195,809 hash=632700..400460 blocks=1    txs=1     mgas=0.128    elapsed="530.507µs" mgasps=240.986  age=30m8s     dirty=56.22MiB
INFO [06-16|19:50:32.473] Recovered head state                     number=195,809 hash=632700..400460
INFO [06-16|19:50:32.473] Extend chain                             add=10 number=195,809 hash=632700..400460
INFO [06-16|19:50:32.474] Chain head was updated                   number=195,809 hash=632700..400460
WARN [06-16|19:50:44.597] Ignoring already known beacon payload    number=195,809 hash=632700..400460 age=30m20s
WARN [06-16|19:50:56.718] Ignoring already known beacon payload    number=195,809 hash=632700..400460 age=30m32s

Meanwhile, the taiko-client had a lot of this in the logs
unexpected ForkchoiceUpdate response status: VALID
I rolled back to commit https://github.com/taikoxyz/taiko-client/commit/cb4dada3ef9d9cf673af20a942e6326ac7ed556b and then it synced right and everything worked.

Assigned to @davidtaikocha , think this PR introduced this bug: https://github.com/taikoxyz/taiko-client/commit/45d73b9da34232cf6a3c8636e97aef5854bb86bb


Build docs with Python 3

Fixes https://github.com/WoLpH/python-utils/issues/6

Coverage remained the same at 100.0% when pulling 46b2192c1c146bffda04ffe696a8934015af5777 on hroncok:py3docs into 6bbe13bab33bd9965b0edd379f26261b31a3e427 on WoLpH:develop.

Coverage remained the same at 100.0% when pulling 46b2192c1c146bffda04ffe696a8934015af5777 on hroncok:py3docs into 6bbe13bab33bd9965b0edd379f26261b31a3e427 on WoLpH:develop.

I think the fix can be even simpler. I added this a long time ago when Sphinx didn't have a warning for non-local images such as build status. But it seems it's been integrated for some time now: https://github.com/sphinx-doc/sphinx/issues/2466
I'll merge this in any case but I think I'll remove the entire bit of monkey patching :)
Thanks for the help as always Miro!


SOLR-16397: Adding MLT API V2

https://issues.apache.org/jira/browse/SOLR-16397

Description
Adding API v2 for the More Like this request handler.
Solution
The API follows a similar approach to RealTimeGetAPI, where the new API uses the MLT hander to process the requests.
Tests
Please describe the tests you've developed or run to confirm this patch implements the feature or solves the problem.
Checklist
Please review the following and check all that apply:

[x] I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
[ ] I have created a Jira issue and added the issue ID to my pull request title.
[x] I have given Solr maintainers access to contribute to my PR branch. (optional but recommended)
[x] I have developed this patch against the main branch.
[x] I have run ./gradlew check.
[ ] I have added tests for my changes.
[ ] I have added documentation for the Reference Guide

Looks great @aalbahem, thanks for the PR!  I made one small tweak to the @EndPoint annotation used to expose /mlt and added a CHANGES.txt entry, but otherwise this was good to go.
Merging now and will backport to branch_9x in a few days so this can make the upcoming 9.2.

@gerlowskija should we add the new endpoint to the ref guide?