generate schema for datapackaging

In our migration to datapackages (and away from the pqsl database), we need to basically translate the existing sqlalchemy schema into table schemas that conform to the frictionless data spec.

Right now you can generate a functional set of metadata based on the existing psql database by running this notebook. Especially for the resource and table schema specs, I'm imagining the full metadata will be stored in one place and we'll use it/modify it to generate whatever version specific metadata we need. As I was discussing in Issue #319, we're probably going to want the ability to pull a subset of the data sets into a package, which means we'll want to pull a subset of table schema's from the main metadata. Are there any good existing packaging feature that would aid in this process @lwinfree @roll?
To note: once we have a good working packaging process set up, the plan is to remove the existing psql database so we won't be able to regenerate the metadata. I assume we'll have to update it in a piecemeal fashion as the table specs change.

@cmgosnell
Just as a note (if I got it right you don't need it already) that for initial SQL export you can use datapacakge-py:
# pip install tableschema-sql
from sqlalchemy import create_engine
from datapackage import Package, Resource

DATABASE_URL = 'postgresql://roll:roll@localhost:5432/movies'

descriptor = {'resources': [{'path': 'countries'}, {'path': 'locations'}]}
package = Package(descriptor, storage='sql', engine=create_engine(DATABASE_URL))
package.infer()
package.save('descriptor.json')

@roll is this a way to go from having a datapackage descriptor to having an empty SQL database based on the included TableSchemas and their interrelationships?
Is there a similarly concise way to generate a tabular datapackage descriptor (or at least a list of tabular data resource descriptors) given an SQLAlchemy engine?

Thanks @roll! this would have saved us lots of time! Do you have any tools for easily manipulating or accessing slices of the metadata once it's created? I won't be too hard to just manipulate the json file if there aren't existing tools, but it'd probably be good to use them if they exist.

@zaneselvans
It creates a datapackage (pull) from an existent SQL database (allowing to use a subset of tables where a table goes to be converted to a resource). The infer step means that we also ask to use metadata reflection. The codebase is relatively simple and comes at tableschema-sql-py driver -  https://github.com/frictionlessdata/tableschema-sql-py/tree/master/tableschema_sql
On the other hand, we can do the other direction (push) something like this:
# pip install tableschema-sql
from sqlalchemy import create_engine
from datapackage import Package, Resource

DATABASE_URL = 'postgresql://roll:roll@localhost:5432/movies'

package = Package('path/to/datapackage')
package.save(storage='sql', engine=create_engine(DATABASE_URL))

And it's not only for SQL we also have drivers for Pandas, BigQquerly, Elasticsearch etc. Other question that some of them require some improvements.
Here architecture overview:

https://github.com/frictionlessdata/implementations#frictionless-data-implementations

@cmgosnell

Do you have any tools for easily manipulating or accessing slices of the metadata once it's created?

Sure, that's the main datapackage-py responsibility - https://github.com/frictionlessdata/datapackage-py#datapackage-py
For example, using the library you can re-arrange your all-in-one internal data package into smaller published data packages.


Add a list variant supporting variable-height items for use with an async data-store that knows item highs a priori

First things first: working prototype: https://github.com/asutherland/react-list/tree/quantized-variable-list
With demo page via gh-pages: http://asutherland.github.io/react-list/quantized.html
And many thanks for all the great work on react-list!
Context / Background
I am working on an experimental react.js-based desktop-targeted email app based on the mobile-targeted Firefox OS email app as part of an overhaul of the back-end to support conversation-centric operation (like gmail) versus message-centric operation (standard IMAP).
My requirements are:

Asynchronous data-store control flow.  The email back-end runs in a DOM Worker and it's an offline client intended to run on devices without gobs of memory, so the state lives in IndexedDB.
True virtual list behaviour with random-access seeking where displaying items M..N should not require loading/displaying all of 0..M-1 as well.

Fancy scope creep:

It's cool to have variable-height display of a conversation based on how many new/unread messages there are, or how important it is, etc.  See https://clicky.visophyte.org/files/screenshots/20150507-153614.png for a shoddy example from a few days ago.
It's nice to be able to both buffer for anticipated scrolling and know what is actually visible so we can prioritize actions like fetching message snippets for the visible messages before the not-yet-visible messages.

Simplifications:

Many UIs are based on everything being a fixed multiple of a grid/similar.  In the example of the conversations case, the idea is there's basically a conversation overview (with a height multiple of 1), and up to 3 tidbits from unread messages (each with a height multiple of 1).
For a uniform height implementation we already need to maintain a concise index/view of the conversations.  It's relatively cheap to store the height multiple information as well.

Why react-list
react-list has continually been the best option in my various react.js experiments over the past several months.  I really enjoy how clean the code is and the effort that's gone into keeping it clean.  I figured I'd start from react-list as a base and see if it makes sense to contribute something that meets my needs.  I am okay if this is too crazy / different.
General Implementation
In my branch I added some docs to the README.md at https://github.com/asutherland/react-list/tree/quantized-variable-list#reactlistquantizedheightlist that should help shed some light.
Because of the async control flow, how I've already implemented my data model/backend, and the idiom I settled on for getting the older 0.3.x react-list to re-render as my data updates and having my components be smart with shouldComponentUpdate, I settled on:

The quantized height list widget is more stateless than its relatives.  Its owner/user pushes in the stuff to display as props.
The list widget issues seek() calls (a prop function passed in by the owner/user) to trigger the data-model to fetch more data and eventually update the props.
The only real state the widget has is avoiding issuing redundant seek() calls by requiring the user to have scrolled some minimum distance before a new seek call is issued.  I store this directly as _lastScroll on the component instance rather than using setState.  This feels wrong (and may also technically be wrong :), but I was trying to avoid needing a custom shouldComponentUpdate mechanism that would ignore that state property since we don't actually want to trigger any re-rendering until the new data comes in via props.  The custom shouldComponentUpdate is still probably right.

Questions

Is this something that seems appropriate to live in react-list in any form?
Is this implementation approach viable?  Does a better way to do this jump out?
What's a less horrible name than QuantizedHeightList? :wink:

Check out the new 0.5.0 release with better variable height support. Also, check out the 3rd example on http://devblog.orgsync.com/react-list/ that demonstrates the itemHeightGetter prop. My goal was to keep the API as simple as possible. Once it gets too complicated it's difficult to build anything on top of it.
For your email case, it seems you could always return the correct height given an email index because you'd know how many preview lines you're showing. I'm going to close this issue for now since the support is now in master.

Awesome variable-height update support.
Unfortunately I don't think the async data-flow where the data lives in a separate DOM Worker entirely lines up for my conversation use case.  react-list assumes the getters can synchronously provide information.  (A reasonable simplifying requirement!)  I could deal with this by having a synthetic spacer element, but this seems to be fighting the work react-list is doing internally.
So I figure I'll see what happens if I whittle down QuantizedHeightList to a standalone implementation that assumes my seek flow using props.  Assuming it's small enough, perhaps it makes sense for me to create a react-async-virtual-list thing for consumers with similar use-cases.  And then I'd continue to use react-list for things like account lists and folder lists where all of the information is synchronously available and there's no need for the async flow.

Can't your itemHeightGetter return some height for when it's loading and then another height when you have the information necessary?

Sort of?  In 0.5.0 with type=variable the coordinate space is item indices.  updateVariableFrame synchronously figures out what item indices are visible by what the itemHeightGetter returns at that instant.  Calling itemHeightGetter is no indication that an item wants to be rendered, just that it's visible or above the visible area (both updateVaraibleFrame and getSpaceBefore) do this.  So any lies I tell really complicate things.  The only viable option is for my Worker to send height information on all the items from 0 until react-list stops asking for things that aren't known in the page.
This doesn't sound too horrible at first glance since users normally scroll downwards, but gets worse when dealing with the fact that a potentially huge number of changes may occur in that list in the "space before" impacting the coordinate space.  When the list widget's understanding of this is just a coordinate space offset it's told about, it nicely simplifies things.  It also allows the back-end to be aware of a stable "focus" item/position so that if changes happen in the "space before" that we can provide visual persistence for the user while still updating scroll positions to be accurate by tracking the concept of coordinate space drift between the actual true list and what the user currently sees.  When the user stops scrolling, we can synchronously update scrollTop and our display transforms in a single pass to reset the drift to 0.
Also there's some O(n) scaling issues.  While react-list can obviously optimize things to do more caching/etc. at the cost of needing to handle cache invalidation, it's hard to compete with the canonical data model that owns the changes and has access to persistent data-storage like IndexedDB.


 Last update 17c1eaa...bbde761

Thanks @omerzach!


Add BSP for Adafruit Feather M4 CAN Express

Summary
Adds a BSP for the Adafruit Feather M4 CAN Express board.
Blinky, Neopixel and USB examples have been tested on actual hardware.
There was some discussion in #622 about using features for CAN support rather than adding a new BSP. However, as this board uses a SAME51 part (rather than the SAMD on the M4 Express) I thought it made sense to keep it separate as it would have dependencies on a different PAC.
The CAN module is not yet exposed in the BSP. My intention would be to support the embedded_can HAL using the mcan crate (cf. #654).
Checklist

[X] CHANGELOG.md for the BSP or HAL updated
[X] All new or modified code is well documented, especially public items
[X] No new warnings or clippy suggestions have been introduced (see CI or check locally)

If Adding a new Board

[X] Board CI added to crates.json
[X] Board is properly following "Tier 2" conventions, unless otherwise decided to be "Tier 1"

@jboynes, using a different chip/BSP is definitely a stronger reason to have a different BSP. But it's also not a total dealbreaker to reuse the existing BSP. Other than CAN, are there any other major differences between the E51J and D51J chips? And what about the boards themselves? Are the pinouts essentially identical between the two boards? Or is there variation there as well?
We might be able to get away with some hacking in Cargo.toml, which I think would benefit everyone. You would get free Tier 1 support and there would be less code duplication.

To my knowledge, the only difference between the D51J and E51J is the presence of the CAN module.
The chip identifies differently which could affect debugging (e.g. the "chip" value in [metadata]). By default though, flashing is done using hf2 which does not rely this. The board does have pads to attach a SWD probe though.
Differences on the board compared to the M4 are:

battery pin V_DIV changed from PB01 to PB00
neopixel data pin D8_NEOPIX changed from PB03 to PB02
PB03 is now used as power for the neopixel NEO_PWR

The on-board CAN transceiver uses the following pins which are unused on the basic M4:

PB13 is used to enable the +5V supply for the CAN transceiver BOOST_EN
PB12 is used to put the CAN transceiver in standby mode CAN1_S
PB14 and PB15 are used for CAN data CAN1_TX and CAN1_RX

Another advantage of having this as a separate BSP crate is that it can version separately from the feather_m4 one, especially as the embedded_can HAL is still relatively new so there are likely to be CAN-specific changes that won't affect most users. It would also allow the base BSP to be updated with needing to test on CAN hardware.

I'm quite curious how this BSP will develop. My understanding is that you want to implement embedded-can on mcan in some opinionated way that will kind of work for toy projects. As far as my knowledge goes embedded-can is quite limited and makes a lot of assumptions (like that TX and RX is supposed to use the same frame type which in MCAN is not that straightforward). This is why we only use primitives from embedded-can, like Id enums and such.

I'm quite curious how this BSP will develop. My understanding is that you want to implement embedded-can on mcan in some opinionated way that will kind of work for toy projects. As far as my knowledge goes embedded-can is quite limited and makes a lot of assumptions (like that TX and RX is supposed to use the same frame type which in MCAN is not that straightforward). This is why we only use primitives from embedded-can, like Id enums and such.

I don't have many opinions here :shrug:. My thought was that embedded_hal was using embedded_can so that would be a natural way to go. I agree the API looks fairly basic at the moment (e.g. I see no support for CAN-FD, filters, priorities, etc.) which just means there's work to do. That's mainly why I thought that any BSP for a board with CAN would see more churn than one without. It's also a case for not making this a Tier 1 BSP, at least for now.
Having more boards supported would allow more testing of the HAL and its abstractions. This PR adds a SAM E51-based board, and I've proposed adding a SAM C21 (Cortex-M0) board as well for some diversity in Microchip/Atmel devices. And of course, there are other devices using Bosch's M_CAN IP as well (e.g. the STM32G4 (cf. fdcan) and LPC5516 MCUs, or the TCAN4550 external controller).

@jboynes, I think this case is right on the deciding line. The small board differences could be handled with #[cfg] attributes in the bsp_pins! macro, and selecting the correct chip variant could be done with a Cargo feature. But I don't see any way to change the package metadata. That's probably the biggest driver to using a separate BSP. However, by going the separate route, you give up Tier 1 support and increase code duplication. We could eventually consider upgrading the board to Tier 1, but it probably wouldn't happen immediately.
I think I'll leave it up to you (and possibly anyone else who wants to weigh in). Would you prefer this as a separate BSP? If so, we can merge it.

Would you prefer this as a separate BSP? If so, we can merge it.

I think it would be preferable for now, because:

It can be Tier 2
Being Tier 2, it can iterate more quickly in response to changes in the CAN HAL
It can still be upgraded to Tier 1 when things stabilize

There's not a lot of production code to maintain in the BSP itself. I think most of the maintenance work would be in tracking dependencies. Ideally, the BSP would only define devices on the board and the pin mappings that connect to them; things that are board specific, and only things that are board specific.
I will explore if there's a way to refactor this to reduce the duplication. I'll take a look at unifying with the atsme54_xpro as that's also Tier 2 and would also be affected by the CAN support.


add reference to react-router-scroll to the docs

I guess this was removed because the functionality was removed from the router, and then someone created a standalone package for this right?
But lots of old issues and pulls still reference the old docs "rackt" that don't exist any more. But people will still find those issues and can't find any reference to the old scroll behavior in the current docs.
Let's add this reference.

Yeah not sure why I didn't add that. Didn't want to self-promote, I guess.

Wait, shoot, now that I've had my coffee – react-router-scroll doesn't manage scrolling to hash links. That's why I didn't add that note there.

Haha okay. But well.. I still think it should be somewhere in the docs. If only so that people looking to preserve their scroll position know where to look. How about Troubleshooting.md instead?

Sure! It's mentioned in a couple of the upgrade guides, but it would be nice to have a reference in the main docs.


 retains detached DOM nodes that already left

Vue version
https://github.com/vuejs/core/commit/52cdb0f991dc154ae32a2900874d5dbc4e078565
Link to minimal reproduction
https://play.vuejs.org/#eNp9UTtPwzAQ/iuHl4JUmgGmKq14qAMMgCCjl5BeglvHtvwIlar8d85OU4qEmsn+XvnuvGf3xsy6gGzOcldZYTw49MEsuRKt0dbDHizW0ENtdQsTkk644qrSynnoShkQFlFx6W3AK67ybIihALp4bI0sPdINIP8M3msFd5UU1XbB2Wi/SAfOloVuGol5NghTBNkKWyonvEgI0JevRQfdtajHDLIODECBzh9UGcmGH2d/IvLspBabMu9omlo0s43Tihaxjx7OKt0aIdG+muhznM0hMZErpdTfzwmLc09HvPrCavsPvnG7iHH2ZtGh7ajxkfOlbdAP9OrjBXd0PpKtXgdJ6jPkOzotQ+w4yB6CWlPtE11q+5SeU6imcKudR1rHYahYNCr7pKeNBnw8M/pv3ZvZbfJx1bP+Bx9owfc=
Steps to reproduce

(On Chrome devtools) Trigger GC and take initial heap snapshot.
Click "Toggle" button twice (Text disappears and appears again)
(On Chrome devtools) Trigger GC again and take second heap snapshot.
Compare 3. and 1.

What is expected?
There is no detached DOM node.
What is actually happening?
There are detached DOM nodes that disappeared on step 2. It is retained by the old vnode in the scope of <Transition> render function via postClone callback of resolveTransitionHooks.

System Info
No response
Any additional comments?
The detached nodes will be released when a next leave transition. So memory usage does not increase forever. But this behavior always keep some detached nodes which makes harder to find actual memory leak. In addition, since it keeps unused DOM tree in memory, it can be a problem under an environment where memory usage is restricted like mobile app's WebView.

chunk-FAED3IGF.js?v=cd150bc5:9710 Uncaught (in promise) TypeError: Cannot read properties of null (reading 'nextSibling')
at nextSibling (chunk-FAED3IGF.js?v=cd150bc5:9710:31)
at removeFragment (chunk-FAED3IGF.js?v=cd150bc5:7224:14)
at remove2 (chunk-FAED3IGF.js?v=cd150bc5:7195:9)
at unmount (chunk-FAED3IGF.js?v=cd150bc5:7173:9)
at patch (chunk-FAED3IGF.js?v=cd150bc5:5905:7)
at patchBlockChildren (chunk-FAED3IGF.js?v=cd150bc5:6341:7)
at processFragment (chunk-FAED3IGF.js?v=cd150bc5:6433:9)
at patch (chunk-FAED3IGF.js?v=cd150bc5:5928:9)
at patchBlockChildren (chunk-FAED3IGF.js?v=cd150bc5:6341:7)
at patchElement (chunk-FAED3IGF.js?v=cd150bc5:6233:7)

@Xiaofusun
Please create a new issue with minimal reproduction

UsePointGeocoder coordinate point analysis, it's not working well since this afternoon（坐标点解析，下午开始不能用了）
On 09/3/2024 @.***> wrote：
@Xiaofusun
Please create a new issue with minimal reproduction
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.***>


Bug Report: When changing downscroll in modchart the gray notes dont move to the top or the bottom

Please check for duplicates or similar issues, as well performing simple troubleshooting steps (such as deleting the YoshiCrafter29 folder from AppData) before submitting an issue.
If you're using an older version of the engine, check if the bug haven't been already fixed
PS : the "everything goes black while changing state in developer mode bug" is not a bug, it's been designed this way to refresh all bitmaps between states to allow easier modding.
Which target are you using?

[X ] Windows
[ ] Mac
[ ] Linux

What version of the engine are you using (Bottom left of the screen in main menu) ?
1.0.1
Have you identified any steps to reproduce the bug? If so, please describe them below in as much detail as possible. Use images if possible.
Add modchart to song
Change EngineSettings.downscroll to true/false in modchart mid song
Please describe your issue. Provide extensive detail and images if possible.
When I use a modchart to change downscroll midsong in the beathit function the gray notes do not move up or down, but stay in the place they were in previously. The colored notes still move down or up and will move above or below the gray notes.

Oh actually the engine isnt designed to automatically move arrows from bottom to top when the downscroll value is changed. This allows people to program their smooth transition during switch. However, i should add a function to auto switch these.

PlayState.setDownscroll(downscroll:Bool, autoPos:Bool)
Will be available in the next Yoshi Engine version.


Does [-Wshorten-64-to-32] warning matter?

I install SQLite.swift using Carthage following the README.md. I have to build it twice. The first time it always fails, with the following error message plus all the warning messages in the second build:
...
/Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:9057:26: warning: unused variable 'sqlite3one' [-Wunused-const-variable]
configure: error: in `.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher':
configure: error: C compiler cannot create executables
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:28978:6: warning: "gethostuuid() is disabled." [-W#warnings]
...

The second time it finishes, but with a lot of such warnings:
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:28978:6: warning: "gethostuuid() is disabled." [-W#warnings]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:30362:14: warning: implicit conversion loses integer precision: 'ssize_t' (aka 'long') to 'int' [-Wshorten-64-to-32]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:32081:42: warning: implicit conversion loses integer precision: 'unsigned long long' to 'int' [-Wshorten-64-to-32]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:32244:11: warning: implicit conversion loses integer precision: 'ssize_t' (aka 'long') to 'int' [-Wshorten-64-to-32]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:32356:10: warning: implicit conversion loses integer precision: 'ssize_t' (aka 'long') to 'int' [-Wshorten-64-to-32]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:33556:33: warning: implicit conversion loses integer precision: 'long long' to 'int' [-Wshorten-64-to-32]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:35226:17: warning: implicit conversion loses integer precision: 'ssize_t' (aka 'long') to 'int' [-Wshorten-64-to-32]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:35537:11: warning: implicit conversion loses integer precision: 'size_t' (aka 'unsigned long') to 'int' [-Wshorten-64-to-32]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:35545:11: warning: implicit conversion loses integer precision: 'size_t' (aka 'unsigned long') to 'int' [-Wshorten-64-to-32]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:35838:19: warning: implicit conversion loses integer precision: 'ssize_t' (aka 'long') to 'int' [-Wshorten-64-to-32]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:36001:37: warning: implicit conversion loses integer precision: 'unsigned long' to 'int' [-Wshorten-64-to-32]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:36216:53: warning: implicit conversion loses integer precision: 'unsigned long' to 'int' [-Wshorten-64-to-32]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:76542:21: warning: implicit conversion loses integer precision: 'i64' (aka 'long long') to 'int' [-Wshorten-64-to-32]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:81870:44: warning: implicit conversion loses integer precision: 'long long' to 'int' [-Wshorten-64-to-32]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:105825:26: warning: implicit conversion loses integer precision: 'u64' (aka 'unsigned long long') to 'int' [-Wshorten-64-to-32]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:105827:36: warning: implicit conversion loses integer precision: 'unsigned long long' to 'int' [-Wshorten-64-to-32]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:105873:26: warning: implicit conversion loses integer precision: 'u64' (aka 'unsigned long long') to 'int' [-Wshorten-64-to-32]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:105875:36: warning: implicit conversion loses integer precision: 'unsigned long long' to 'int' [-Wshorten-64-to-32]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:9057:26: warning: unused variable 'sqlite3one' [-Wunused-const-variable]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:28978:6: warning: "gethostuuid() is disabled." [-W#warnings]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:9057:26: warning: unused variable 'sqlite3one' [-Wunused-const-variable]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:28978:6: warning: "gethostuuid() is disabled." [-W#warnings]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:9057:26: warning: unused variable 'sqlite3one' [-Wunused-const-variable]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:28978:6: warning: "gethostuuid() is disabled." [-W#warnings]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:30362:14: warning: implicit conversion loses integer precision: 'ssize_t' (aka 'long') to 'int' [-Wshorten-64-to-32]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:32081:42: warning: implicit conversion loses integer precision: 'unsigned long long' to 'int' [-Wshorten-64-to-32]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:32244:11: warning: implicit conversion loses integer precision: 'ssize_t' (aka 'long') to 'int' [-Wshorten-64-to-32]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:32356:10: warning: implicit conversion loses integer precision: 'ssize_t' (aka 'long') to 'int' [-Wshorten-64-to-32]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:33556:33: warning: implicit conversion loses integer precision: 'long long' to 'int' [-Wshorten-64-to-32]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:35226:17: warning: implicit conversion loses integer precision: 'ssize_t' (aka 'long') to 'int' [-Wshorten-64-to-32]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:35537:11: warning: implicit conversion loses integer precision: 'unsigned long' to 'int' [-Wshorten-64-to-32]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:35545:11: warning: implicit conversion loses integer precision: 'unsigned long' to 'int' [-Wshorten-64-to-32]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:35838:19: warning: implicit conversion loses integer precision: 'ssize_t' (aka 'long') to 'int' [-Wshorten-64-to-32]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:36001:37: warning: implicit conversion loses integer precision: 'unsigned long' to 'int' [-Wshorten-64-to-32]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:36216:53: warning: implicit conversion loses integer precision: 'unsigned long' to 'int' [-Wshorten-64-to-32]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:76542:21: warning: implicit conversion loses integer precision: 'i64' (aka 'long long') to 'int' [-Wshorten-64-to-32]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:81870:44: warning: implicit conversion loses integer precision: 'long long' to 'int' [-Wshorten-64-to-32]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:105825:26: warning: implicit conversion loses integer precision: 'u64' (aka 'unsigned long long') to 'int' [-Wshorten-64-to-32]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:105827:36: warning: implicit conversion loses integer precision: 'unsigned long long' to 'int' [-Wshorten-64-to-32]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:105873:26: warning: implicit conversion loses integer precision: 'u64' (aka 'unsigned long long') to 'int' [-Wshorten-64-to-32]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:105875:36: warning: implicit conversion loses integer precision: 'unsigned long long' to 'int' [-Wshorten-64-to-32]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:28978:6: warning: "gethostuuid() is disabled." [-W#warnings]
.../Carthage/Checkouts/SQLite.swift/Vendor/sqlcipher/sqlite3.c:9057:26: warning: unused variable 'sqlite3one' [-Wunused-const-variable]

So does the error in the first build and the warnings in the second build matter?

Consolidating this into #300.


Error with Entry.writerScanner: token too long

If you pass too long string (or byte slice) without newlines to *io.PipeWriter, provided by Entry.WriterLevel, you can see errors like this:
Error while reading from Writer: bufio.Scanner: token too long.
Sample code to reproduce this issue:
package main

import "github.com/sirupsen/logrus"
import "bytes"
import "time"

func main() {
        i := 1
        b := []byte{0}
        log := logrus.New()
        for {
                log.Info("Logging ", i, " bytes")
                log.Writer().Write(b)
                b = bytes.Repeat(b, 2)
                i *= 2
                time.Sleep(200 * time.Millisecond)
        }
}

This is head of output on my machine:
INFO[0000] Logging 1 bytes
INFO[0000] Logging 2 bytes
INFO[0000] Logging 4 bytes
INFO[0000] Logging 8 bytes
INFO[0000] Logging 16 bytes
INFO[0001] Logging 32 bytes
INFO[0001] Logging 64 bytes
INFO[0001] Logging 128 bytes
INFO[0001] Logging 256 bytes
INFO[0001] Logging 512 bytes
INFO[0002] Logging 1024 bytes
INFO[0002] Logging 2048 bytes
INFO[0002] Logging 4096 bytes
INFO[0002] Logging 8192 bytes
INFO[0002] Logging 16384 bytes
INFO[0003] Logging 32768 bytes
INFO[0003] Logging 65536 bytes
ERRO[0003] Error while reading from Writer: bufio.Scanner: token too long
INFO[0003] Logging 131072 bytes
ERRO[0003] Error while reading from Writer: bufio.Scanner: token too long
INFO[0003] Logging 262144 bytes
ERRO[0003] Error while reading from Writer: bufio.Scanner: token too long
INFO[0003] Logging 524288 bytes
ERRO[0003] Error while reading from Writer: bufio.Scanner: token too long
INFO[0004] Logging 1048576 bytes
ERRO[0004] Error while reading from Writer: bufio.Scanner: token too long

This error (ErrTooLong) is set in Scanner.Scan if buffer length is greater than max token size.
Maximum token size is defined as constant - bufio.MaxScanTokenSize. Current value is 65536. But you can override it with passing custom buffer and max token size to Scanner.Buffer.
So I see 2 ways of fixing this error:

Use own buffer and increase max token size
Use bufio.Reader and handle ErrBufferFull error from it

We've run into this issue in https://github.com/joyent/containerpilot/issues/423. In our case it's happening because we're piping stdout of a child process and can't enforce that we're terminating it with newlines. (It's an end-user error for our project, but we still need to handle it gracefully.)
Looking at the implementation here, I'd argue that simply increasing the token size just pushes the issue off. I'll see if I can figure out a way to gracefully handle this error by handling ErrBufferFull as suggested above.

I agree with you, increasing buffer size is not a solution.
We've faced this problem while using containerpilot with healthcheck (same as in mentioned joyent/containerpilot#423) but figured out, that it's not a containerpilot bug.

In my opinion logrus shouldn't provide Logger.Writer.  Implementing a completely independent io.Writer that serves as an adapter/bridge to logrus is easy and the solution is much less complicated than Logger.Writer.
I've expressed a similar opinion in another open issue where Logger.Writer was used to redirect the standard log into logrus: https://github.com/sirupsen/logrus/issues/436 There I've provided a logrus writer adapter optimised for the standard log library.
@tgross I've checked your exec.Command example in issue https://github.com/joyent/containerpilot/issues/423 and a solution without Logger.Writer  would look like:
package main

import (
	"bytes"
	"github.com/sirupsen/logrus"
	"os/exec"
)

func main() {
	w := &logrusWriter{
		entry: logrus.StandardLogger().WithField("logger", "cmd"),
	}

	cmd := exec.Command("sh", "-c", "echo stdout; echo 1>&2 stderr")
	cmd.Stdout = w
	cmd.Stderr = w

	cmd.Start()

	err := cmd.Wait()
	w.Flush()
	if err != nil {
		logrus.Fatal(err)
	}
}

type logrusWriter struct {
	entry *logrus.Entry
	buf   bytes.Buffer
}

func (w *logrusWriter) Write(b []byte) (int, error) {
	origLen := len(b)
	for {
		if len(b) == 0 {
			return origLen, nil
		}
		i := bytes.IndexByte(b, '\n')
		if i < 0 {
			w.buf.Write(b)
			return origLen, nil
		}

		w.buf.Write(b[:i])
		w.alwaysFlush()
		b = b[i+1:]
	}
}

func (w *logrusWriter) alwaysFlush() {
	w.entry.Warning(w.buf.String())
	w.buf.Reset()
}

func (w *logrusWriter) Flush() {
	if w.buf.Len() != 0 {
		w.alwaysFlush()
	}
}

As a safety valve you could put in a check for too large w.buf sizes.

Also encountering this issue when piping the output of a process with many progress-bar messages like Processing Files: 123/45678910\r (no \n).
Write() uses bufio.Scanner, and bufio.Scanner lets you change the line-detection method to anything using scanner.Split(). We can (ab)use this to print our long no-linebreak buffer and avoid bufio.ErrTooLong. Here's one way: https://gist.github.com/AlbinoDrought/c292adc185ea6593338fb5b56ac89aa7


Signature built in

Signature built in with the operations of BuiltInRunners

We should add a test that runs a cairo program using the signature builtin like this one (we can do it on another PR if it's easier)


Add REST API

I had very nice experience with Symfony and fosRestBundle.
Have a look here: https://bin.binee.co/api/doc
Do you know if FOSRest works with Silex?

I will look into it. This is the first Silex/Symphony project I have done. I usually use ZF2. When I started PWX I was looking into micro frameworks and found Silex to be pretty interesting. The API is not so important at this point. I added the ticket to keep it in mind for the future. I could see this to be an interesting feature for hosting companies and such.

Thanks for implementing this!


Footer: Hide on Post Detail View

https://www.pivotaltracker.com/story/show/155407153

@alanpeabody Have a moment to 👀? I’d like to get this out with #380 since they’re tightly-related.


(Nearly) all in GML Reference->Maths->Number Functions

The only thing I left out was using epsilons and fixing double comparison where i see them, because it's just something that I really don't want to deal with right now

At some point we need to have a test WAD for functions because I can't just test everything myself easily, simply because I don't know how they all work. I just implemented them using what I could use.

Looks good!


Add catch for error on adding to project it's already associated with.

An issue I've ran into is that the job will run on against issue updates/adds when it's already associated with the given project. In those cases, this error is thrown...
Error: /21 17:30:36 [ERROR] POST https://api.github.com/projects/columns/11063427/cards: 422 Validation Failed [{Resource:ProjectCard Field:data Code:unprocessable Message:Project already has the associated issue}]
Failed to get results from GitHub

Added a check for this message which will just add a note to the info log but not throw an error.
Signed-off-by: John Mertic<EMAIL_ADDRESS>

Hi @jmertic! Thank you for your PR.
this must be solved with https://github.com/takanabe/github-actions-automate-projects/pull/26. could you check?

Hi @takanabe!
My Go coding skills aren't amazing, but it would appear that #26 is broadly looking for any project cards for an issue, where mine is specifically looking at the error of trying to add a project card on an issue already with one. Not sure if that captures the same use case.

Any chance this could be merged? It would be nice to not get an error if I forget there's automation and assign the project manually.

Thank you for your patch and Sooooooooooooooooooooooooooooooooooooooooory for my late reply. I'll check if I can merge this PR from now 📝


[PIP-74] Support auto scaled consumer receiver queue

Motivation

Pick a proper receiver queue size is not an easy thing. If the value is too small, it impact the throughput, and if the value is too large, it consumes too many memory. With default set up, the queue size is 1000, and the max message size is 5MB, this means maximum of 5GB memory occupation.

This is part of the work for PIP 74. We need auto scale currentReceiverQueue to control client memory.

Modifications
Add optional autoScaledReceiverQueueSizeEnabled for consumer client.
Previous receiverQueueSize is the max value of this auto scaled queue size.
Every time the client will try to double the size of currentReceiverQueue if it limits message throughput. Currently, it's determined by the following two conditions in exact order:
A) Current receiver queue (ConsumerBase#incomingMessages) is full after we put a message into it. (it's marked by scaleReceiverQueueHint as true).
B) Application wants process more messages but the receiver queue is empty. (expectMoreIncomingMessages is called in this PR).
The queue size won't grow if we got new messages during A and B. So if assume current receiver queue size is 10, and the timeline would be like

Consumer send flow command to client, and client receive 10 messages, so scaleReceiverQueueHint is marked as true.
Application calls receive() repeatedly and processed all 10 messages. And in the meanwhile no new message is sent to client[1].
Receiver queue size will be doubled to 20.
...

NOTE:
Condition A here is slightly different from original design in PIP-74 described as "there are messages pending to be sent for this consumer" (let's refer it as Condition X). This is proposed with these consideration:
a) We can assume that when receiver queue is full, the chance of broker have no more messages is insignificant in practice.
b) If we accept a), then Condition A implies Condition X, as new messages are pending because local queue size is full.  But it's NOT vice versa.
c) Once fact we should accept is that we don't need expand queue size every time it limits the throughput as some slight and occasional delay is acceptable and won't affect overall throughput. And by replacing Condition A with Condition X, we can reduce the sensitivity of the expansion.
Verifying this change

[x] Make sure that the change passes the CI checks.

This change added tests and can be verified as follows:
(example:)

org.apache.pulsar.client.impl.AutoScaledReceiverQueueSizeTest

Does this pull request potentially affect one of the following parts:
If yes was chosen, please highlight the changes

Dependencies (does it add or upgrade a dependency): (no)
The public API: (yes, add a config for consumer builder)
The schema: (no)
The default values of configurations: (no)
The wire protocol: (no)
The rest endpoints: (no)
The admin cli options: (no)
Anything that affects deployment: (no)

Documentation
Check the box below and label this PR (if you have committer privilege).
Need to update docs?

[x] no-need-doc

/pulsarbot run-failure-checks

Here is a test with bin/pulsar-perf on local standalone server to confirm the effect of this PR.


Proposed method PlacePhoneCall does not need to be async

There is no async task awaited in PlacePhoneCall.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 9f4d0869-b5c2-c17b-63d4-f325856d1a79
Version Independent ID: a5f487c3-4e56-838f-89a9-b8fa0dc13261
Content: Xamarin.Essentials: Phone Dialer - Xamarin
Content Source: docs/essentials/phone-dialer.md
Product: xamarin
Technology: xamarin-essentials
GitHub Login: @jamesmontemagno
Microsoft Alias: jamont

Fixed here: https://github.com/MicrosoftDocs/xamarin-docs/pull/1847
Thanks for the feedback!


implement threading as everything hangs while encoding

https://nikolak.com/pyqt-threading-tutorial/


added terrain collision code

Hello, I created a patch that adds support for terrain collision. It's not completely bug-free, but I wanted to get some feedback, so I created the pull request now.
I would not suggest to merge it (yet).

This is incredibly important to have Terrain Collision. The standard assets CharacterController can do it and modifiable terrains are a common level implementation. I think we should fix the conflicts here, test it and merge it.

Scratch that. This is already a feature of this library. My version of Unity was freaking out, but in 2017.1, this actually works fine.

Lol, was I drunk when I opened this?


Add keyboard navigation to JingetDropDown and JingetDropDownTreeList

Is your feature request related to a problem? Please describe.
The user should be able to easily move between the items using the keyboard and select the desired option.
Describe the solution you'd like
It is preferable to use the facilities & utilities in the select2.js

Is your feature request related to a problem? Please describe. The user should be able to easily move between the items using the keyboard and select the desired option.
Describe the solution you'd like It is preferable to use the facilities & utilities in the select2.js

JingetDropDownList already supports the keyboard navigation & this feature should be applied for JingetDropDownTreeList only, as this component render the items manually.


Typo in readme

sample-azure.yml example has capital C in credentials, that need to be fixed.
ERRO[0000] Error parsing config file: unknown fields in config: Credentials
armclient command worked after changing C to small c

README still has capital C

Fixed now


[CONTROLLER] support returning new status to agent

This PR is for:

Server

Fixes support returning new status to agent
Steps to reproduce the bug

delete auto created domain

Changes to fix the bug
Affected branches

main

Checklist

[ ] Added unit test to verify the fix.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.zhengya seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Update README.txt

README.txt file states that privateKey option should be under options key, but it works only on top level of crx configuration (on the same level with src and dest keys).

Hello, this is due to #44 and #58. #44 needs to be fixed sorry about it.


Support Plugin system

Support to extend the features of GitQL SDK and engine to load plugins
Related issue: https://github.com/AmrDeveloper/FileQL/issues/1

GitQL SDK Dynamic Std functions and Aggregations
https://github.com/AmrDeveloper/GQL/releases/tag/0.20.0
Now SDK user can add, remove or override functions, add DSL functions for their XQL


Fix foundry-list proof id lookup

foundry-list was broken by a change to the way kcfgs are stored introduced in pyk#325 resulting in a KeyError for 'proofid' whenever it was run. This changes it to use the correct key.

@nwatson22 following https://github.com/runtimeverification/evm-semantics/pull/1702 being merged, please update this PR in the way you're thinking. Basically:

We should always be reading/writing entire AGProof, not just a KCFG
We should be using AGProof.summary to do the foundry-list command.

Perhaps we should also sort the stats in foundry_list before displaying. I've seen the foundry-list check fail because of a different kcfg order.

Perhaps we should also sort the stats in foundry_list before displaying. I've seen the foundry-list check fail because of a different kcfg order.

Good point, I'll add that to this branch.


Edited message still show their original text in the chat list

After editing a message, it seems like it still remains unedited in the chat list. Clicking the chat shows the edited message as expected.

fixed internally


HDFS-15810. RBF: Use BigInteger for Router capacity metrics

NOTICE
Please create an issue in ASF JIRA before opening a pull request,
and you need to set the title of the pull request which starts with
the corresponding JIRA issue number. (e.g. HADOOP-XXXXX. Fix a typo in YYY.)
For more details, please see https://cwiki.apache.org/confluence/display/HADOOP/How+To+Contribute

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 35s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
33m 49s

trunk passed

+1 :green_heart:
compile
0m 42s

trunk passed with JDK Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
compile
0m 38s

trunk passed with JDK Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08

+1 :green_heart:
checkstyle
0m 26s

trunk passed

+1 :green_heart:
mvnsite
0m 43s

trunk passed

+1 :green_heart:
javadoc
0m 41s

trunk passed with JDK Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
javadoc
0m 56s

trunk passed with JDK Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08

+1 :green_heart:
spotbugs
1m 13s

trunk passed

+1 :green_heart:
shadedclient
14m 20s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 33s

the patch passed

+1 :green_heart:
compile
0m 33s

the patch passed with JDK Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
javac
0m 33s

the patch passed

+1 :green_heart:
compile
0m 28s

the patch passed with JDK Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08

+1 :green_heart:
javac
0m 28s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 17s

the patch passed

+1 :green_heart:
mvnsite
0m 32s

the patch passed

+1 :green_heart:
javadoc
0m 30s

the patch passed with JDK Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
javadoc
0m 47s

the patch passed with JDK Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08

-1 :x:
spotbugs
1m 19s
/new-spotbugs-hadoop-hdfs-project_hadoop-hdfs-rbf.html
hadoop-hdfs-project/hadoop-hdfs-rbf generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0)

+1 :green_heart:
shadedclient
14m  2s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
17m 48s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs-rbf.txt
hadoop-hdfs-rbf in the patch passed.

+1 :green_heart:
asflicense
0m 34s

The patch does not generate ASF License warnings.

93m  9s

Reason
Tests

SpotBugs
module:hadoop-hdfs-project/hadoop-hdfs-rbf

Return value of java.math.BigInteger.add(BigInteger) ignored in org.apache.hadoop.hdfs.server.federation.metrics.RBFMetrics.getNameserviceAggregatedBigInt(ToLongFunction)  At RBFMetrics.java:in org.apache.hadoop.hdfs.server.federation.metrics.RBFMetrics.getNameserviceAggregatedBigInt(ToLongFunction)  At RBFMetrics.java:[line 795]

Failed junit tests
hadoop.hdfs.server.federation.router.TestRouterRpcMultiDestination

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2910/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/2910

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell

uname
Linux ee336fa6323a 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 19043f9fa20f545ecd1836fdc1598826727cb4fa

Default Java
Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2910/1/testReport/

Max. process+thread count
2481 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs-rbf U: hadoop-hdfs-project/hadoop-hdfs-rbf

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2910/1/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

Would you update the web UI to use the new metrics?
https://github.com/aajisaka/hadoop/blob/486ddb73f9999693177787e4abff7c932be9b925/hadoop-hdfs-project/hadoop-hdfs-rbf/src/main/webapps/router/federationhealth.html#L116-L118

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 57s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  1s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
markdownlint
0m  1s

markdownlint was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
16m  5s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
25m 56s

trunk passed

+1 :green_heart:
compile
28m 23s

trunk passed with JDK Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
compile
21m  0s

trunk passed with JDK Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08

+1 :green_heart:
checkstyle
4m  2s

trunk passed

+1 :green_heart:
mvnsite
2m 30s

trunk passed

+1 :green_heart:
javadoc
1m 52s

trunk passed with JDK Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
javadoc
2m 51s

trunk passed with JDK Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08

+1 :green_heart:
spotbugs
4m 30s

trunk passed

+1 :green_heart:
shadedclient
18m 14s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 24s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m  1s

the patch passed

+1 :green_heart:
compile
25m 13s

the patch passed with JDK Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
javac
25m 13s

the patch passed

+1 :green_heart:
compile
20m 10s

the patch passed with JDK Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08

+1 :green_heart:
javac
20m 10s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
4m  5s

the patch passed

+1 :green_heart:
mvnsite
2m 17s

the patch passed

+1 :green_heart:
javadoc
1m 42s

the patch passed with JDK Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
javadoc
2m 39s

the patch passed with JDK Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08

+1 :green_heart:
spotbugs
4m 26s

the patch passed

+1 :green_heart:
shadedclient
17m 13s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
18m 14s

hadoop-common in the patch passed.

-1 :x:
unit
27m 24s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs-rbf.txt
hadoop-hdfs-rbf in the patch passed.

+1 :green_heart:
asflicense
1m  3s

The patch does not generate ASF License warnings.

255m 32s

Reason
Tests

Failed junit tests
hadoop.hdfs.server.federation.router.TestRouterRpc

hadoop.hdfs.server.federation.router.TestRouterFederationRename

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2910/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/2910

Optional Tests
dupname asflicense mvnsite codespell markdownlint compile javac javadoc mvninstall unit shadedclient spotbugs checkstyle

uname
Linux c35012684956 4.15.0-136-generic #140-Ubuntu SMP Thu Jan 28 05:20:47 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 64dbbf2d0c6bcbcb8a8714e5e53f3b136c758af5

Default Java
Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2910/2/testReport/

Max. process+thread count
2143 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common hadoop-hdfs-project/hadoop-hdfs-rbf U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2910/2/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
1m  2s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
markdownlint
0m  0s

markdownlint was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
15m 32s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
23m 29s

trunk passed

+1 :green_heart:
compile
23m 31s

trunk passed with JDK Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
compile
19m 41s

trunk passed with JDK Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08

+1 :green_heart:
checkstyle
4m  9s

trunk passed

+1 :green_heart:
mvnsite
2m 15s

trunk passed

+1 :green_heart:
javadoc
1m 44s

trunk passed with JDK Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
javadoc
2m 31s

trunk passed with JDK Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08

+1 :green_heart:
spotbugs
3m 45s

trunk passed

+1 :green_heart:
shadedclient
17m 12s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 22s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
1m 25s

the patch passed

+1 :green_heart:
compile
22m 50s

the patch passed with JDK Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
javac
22m 50s

the patch passed

+1 :green_heart:
compile
19m 37s

the patch passed with JDK Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08

+1 :green_heart:
javac
19m 37s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
3m 59s

the patch passed

+1 :green_heart:
mvnsite
2m 12s

the patch passed

+1 :green_heart:
javadoc
1m 42s

the patch passed with JDK Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
javadoc
2m 32s

the patch passed with JDK Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08

+1 :green_heart:
spotbugs
4m  1s

the patch passed

+1 :green_heart:
shadedclient
17m 15s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
17m 13s

hadoop-common in the patch passed.

-1 :x:
unit
22m 49s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs-rbf.txt
hadoop-hdfs-rbf in the patch passed.

+1 :green_heart:
asflicense
0m 49s

The patch does not generate ASF License warnings.

234m  9s

Reason
Tests

Failed junit tests
hadoop.hdfs.server.federation.router.TestRouterRpc

hadoop.hdfs.server.federation.router.TestRouterWebHdfsMethods

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2910/3/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/2910

Optional Tests
dupname asflicense mvnsite codespell markdownlint compile javac javadoc mvninstall unit shadedclient spotbugs checkstyle

uname
Linux fc0d8ce1f9a2 4.15.0-101-generic #102-Ubuntu SMP Mon May 11 10:07:26 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 1a2cdd0e09b68c27ba0410e6fbc1953c266bf002

Default Java
Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2910/3/testReport/

Max. process+thread count
1972 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common hadoop-hdfs-project/hadoop-hdfs-rbf U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2910/3/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

@aajisaka @goiri @cxorm  mind giving it another look? The test errors are irrelevant. I also attached a screenshot in the jira ticket for 2*LONG.max_value = 16ZB display capacity

Can we align the name of the JIRA and the PR?

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
23m 33s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
markdownlint
0m  0s

markdownlint was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
15m 56s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
22m 46s

trunk passed

+1 :green_heart:
compile
22m 30s

trunk passed with JDK Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
compile
19m 13s

trunk passed with JDK Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08

+1 :green_heart:
checkstyle
4m  0s

trunk passed

+1 :green_heart:
mvnsite
2m 12s

trunk passed

+1 :green_heart:
javadoc
1m 41s

trunk passed with JDK Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
javadoc
2m 35s

trunk passed with JDK Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08

+1 :green_heart:
spotbugs
3m 43s

trunk passed

+1 :green_heart:
shadedclient
17m  3s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 20s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
1m 25s

the patch passed

+1 :green_heart:
compile
21m 42s

the patch passed with JDK Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
javac
21m 42s

the patch passed

+1 :green_heart:
compile
19m  4s

the patch passed with JDK Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08

+1 :green_heart:
javac
19m  4s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
3m 56s

the patch passed

+1 :green_heart:
mvnsite
2m 10s

the patch passed

+1 :green_heart:
javadoc
1m 40s

the patch passed with JDK Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
javadoc
2m 30s

the patch passed with JDK Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08

+1 :green_heart:
spotbugs
4m  4s

the patch passed

+1 :green_heart:
shadedclient
17m 11s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
17m 13s

hadoop-common in the patch passed.

+1 :green_heart:
unit
22m  2s

hadoop-hdfs-rbf in the patch passed.

+1 :green_heart:
asflicense
0m 47s

The patch does not generate ASF License warnings.

251m 41s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2910/4/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/2910

Optional Tests
dupname asflicense mvnsite codespell markdownlint compile javac javadoc mvninstall unit shadedclient spotbugs checkstyle

uname
Linux 7d1a7396c0f0 4.15.0-136-generic #140-Ubuntu SMP Thu Jan 28 05:20:47 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 666eb74cdd23ee4c0cffbd771d4d11ccd79e3920

Default Java
Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2910/4/testReport/

Max. process+thread count
1993 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common hadoop-hdfs-project/hadoop-hdfs-rbf U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2910/4/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

@goiri  Updated the PR title to align with the JIRA title.

@aajisaka  Can you take another look? Thanks!

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 33s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
markdownlint
0m  0s

markdownlint was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
16m  4s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
20m 13s

trunk passed

+1 :green_heart:
compile
20m 47s

trunk passed with JDK Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
compile
18m 23s

trunk passed with JDK Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08

+1 :green_heart:
checkstyle
3m 43s

trunk passed

+1 :green_heart:
mvnsite
2m 22s

trunk passed

+1 :green_heart:
javadoc
1m 55s

trunk passed with JDK Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
javadoc
2m 38s

trunk passed with JDK Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08

+1 :green_heart:
spotbugs
3m 57s

trunk passed

+1 :green_heart:
shadedclient
14m 35s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 27s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
1m 28s

the patch passed

+1 :green_heart:
compile
21m 47s

the patch passed with JDK Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
javac
21m 47s

the patch passed

+1 :green_heart:
compile
21m 39s

the patch passed with JDK Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08

+1 :green_heart:
javac
21m 39s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
4m  1s

the patch passed

+1 :green_heart:
mvnsite
2m 24s

the patch passed

+1 :green_heart:
javadoc
1m 47s

the patch passed with JDK Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
javadoc
2m 44s

the patch passed with JDK Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08

+1 :green_heart:
spotbugs
4m 33s

the patch passed

+1 :green_heart:
shadedclient
16m 51s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
18m 37s

hadoop-common in the patch passed.

-1 :x:
unit
19m  0s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs-rbf.txt
hadoop-hdfs-rbf in the patch passed.

+1 :green_heart:
asflicense
0m 51s

The patch does not generate ASF License warnings.

223m 47s

Reason
Tests

Failed junit tests
hadoop.hdfs.server.federation.router.TestRouterRpc

hadoop.hdfs.server.federation.router.TestRouterRpcMultiDestination

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2910/5/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/2910

Optional Tests
dupname asflicense mvnsite codespell markdownlint compile javac javadoc mvninstall unit shadedclient spotbugs checkstyle

uname
Linux 9c18113f0fbf 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 5e2857499a97d80f4ea02b942cb3b856592fe11d

Default Java
Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2910/5/testReport/

Max. process+thread count
2611 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common hadoop-hdfs-project/hadoop-hdfs-rbf U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2910/5/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

Thank you @fengnanli, @cxorm, and @goiri!


Uninitialised variable in print_exponential_number

Hi - I get the following warning when compiling printf.c (master [8b831c1]):
printf.c:899:47: warning: 'abs_exp10_covered_by_powers_table' may be used uninitialized in this function [-Wmaybe-uninitialized]
I've not done any in-depth analysis of how print_exponential_number works, so I'm not sure if this really matters. Still, it would be nice if abs_exp10_covered_by_powers_table could be initialised with a default value to get rid of this warning.

This is a compiler "bug". Look at the logic:
  // ... snip ...
  if (abs_number == 0.0) {
    floored_exp10 = 0;
  }
  else  {
    // ... snip ...
    normalization.raw_factor = // ... snip ...
  }
  // ... snip ...
  normalization.multiply = (floored_exp10 < 0 && abs_exp10_covered_by_powers_table);
  // ... snip ...

You see? It can't be used uninitialized.
What compiler are you using?

I have the same issue with using this library with ESP-IDF

I have the same issue with using this library with ESP-IDF

I don't know what ESP-IDF means. Please file a bug against either the IDE or the compiler it uses to generate warnings. There is no issue here.

I don't know what ESP-IDF means. Please file a bug against either the IDE or the compiler it uses to generate warnings.

It will not compile with -Wmaybe-uninitialized unless I default abs_exp10_covered_by_powers_table to false.

First of all, you're treating warnings as errors. That is your prerogative, but the library's build mechanism does not do that on its own.
Secondly, and again - a warning here is a bug in your compiler. There is no sense in complaining about it here. The code is correct. Please file a bug against the compiler.

First of all, you're treating warnings as errors. That is your prerogative, but the library's build mechanism does not do that on its own.
Secondly, and again - a warning here is a bug in your compiler. There is no sense in complaining about it here. The code is correct. Please file a bug against the compiler.

The only place that abs_exp10_covered_by_powers_table is defined is at https://github.com/eyalroz/printf/blob/19a487cd210d7de0914809fdf5d8bb45af1656c7/src/printf/printf.c#L873
which is under an if-else statement. I don't see how this is a compiler error.

I see, the code won't check for abs_exp10_covered_by_powers_table if floored_exp10  == 0

@203Null : Exactly.

The compiler I used is Xtensa ESP32 gcc 8.4.0 (2021r2)
On GodBolt with the same compiler, it works fine https://godbolt.org/z/ofqnoWbzM
I will make an issue in their Github repo

I saw you did some commits regarding this issue.
https://github.com/eyalroz/printf/blob/f8ed5a9bd9fa8384430973465e94aa14c925872d/src/printf/printf.c#L631
Those codes are actually fine with my compiler (not sure about others)
These lines in print_exponential_number are actually the ones causing issues for me. Porting your changes over solves it.
https://github.com/eyalroz/printf/blob/f8ed5a9bd9fa8384430973465e94aa14c925872d/src/printf/printf.c#L908

@203Null : Please open a separate about your issue; explain exactly on which system and with which compiler in what version you get an error, and copy the relevant compiler output.

It's the exact same issue. I posted my log earlier https://github.com/eyalroz/printf/issues/123?notification_referrer_id=NT_kwDOATAnpbMzMTk2MDU5NTAzOjE5OTMzMDkz#issuecomment-1093291418
Just want to point out the #pragma GCC diagnostic ignored "-Wmaybe-uninitialized" was added to the wrong place (I assume you added them to fix this issue judging by the commit name.)


[FEATURE REQUEST] allow text entry modal to expand when writing longer sentences

Is your feature request related to a problem? Please describe.
Quickadd is one of my most used plugins — I'm not being hyperbolic when I say that it really has changed my life. I use it for therapy notes/ intermittent journalling— but one slightly annoying thing about the way that the modals for the plugin are currently rendered is that the text entry field doesn't expand when writing longer sentences. I.e. it is currently not possible to automatically wrap the sentence being written.
Describe the solution you'd like
A clear and concise description of what you want to happen.
So Instead of typing a lot of test into a line, i'd want the modal to automatically wrap the text and grow in height— like with todoist.
Additional context
Add any other context or screenshots about the feature request here.

I'm super glad to hear that you find QuickAdd useful!
This feature has been implemented in the latest update :)


Jhin 4th Shot

Just wanted to let you know Jhin's 4th shot is still grey when it's usually purple.

I think it's because of the game. When we update the CharacterDataStack it gets corrupted.
I don't think this can be fixed


API planned?

Hi,
I am using your extension, which works great, thanks a lot!
While I was using windows I used to use my StreamDeck to control the lighting for my scenes.
While there is a community version of the StreamDeck Software it does not include the plugins the Windows version had.
As I would really love to have my hot keys for lighting back on the Deck, I was wondering if there was any sort of API planned or if you have any documentation which shows possible outside interactions, which I could call to change Lighting.
Thanks!

Hi @jqlifice! I do not intend to add an API for controlling this extension. The only interface is the menu. I would suggest you search the Internet for e.g. hue python API or something similar. Although I did not try such an API, I know some exist...

Hi @vchlum
thanks for the response, I was hoping to solve it just by shell commands and not having to write my own application, but Ill find a way to get it done. Thanks for your swift response!


[BUG]

Release version
APIOps Toolkit for Azure APIM v4.1.0
Describe the bug
Publisher pipeline publishes to dev APIM with no issue. When publishing to prod I get the following error in the "Run publisher for Prod environment" step:
Unhandled exception. System.IO.FileNotFoundException: The configuration file 'configuration.prod.yaml' was not found and is not optional. The expected physical path was '/home/vsts/work/1/s/configuration.prod.yaml'.
Expected behavior
Documentation says "Note that the configuration file is optional." so I expected not to get an error saying it is not optional.
Actual behavior
Unhandled exception stops execution:
Unhandled exception. System.IO.FileNotFoundException: The configuration file 'configuration.prod.yaml' was not found and is not optional. The expected physical path was '/home/vsts/work/1/s/configuration.prod.yaml'.
Reproduction Steps
Follow all setup steps and run extractor pipeline and complete pull request to tigger publisher pipeline. During publish to prod stage the error occurs.

Where do you provide the destination apim instance name?

Where do you provide the destination apim instance name?

As per step 3 here I set the environment variable APIM_NAME_prod. The documentation isn't clear exactly if that is the correct variable name however I made the assumption given:
a) The documentation says: "You can optionally enter the APIM_NAME the higher environment if you have that information ready or you can enter it at a later point."; and
b) The screenshot shows the same syntax being used for the RESOURCE_GROUP_NAME and RESOURCE_GROUP_NAME_prod variables which use the same logic.

Did you read the wiki section? I think it talks about setting the destination apim name there.
Having said that it seems that what you are doing is correct and the configuration file should not be required. @guythetechie any thoughts?

Did you read the wiki section? I think it talks about setting the destination apim name there.
Having said that it seems that what you are doing is correct and the configuration file should not be required. @guythetechie any thoughts?

What is the wiki section? I've read through the documentation related to APIOps in general and Azure DevOps for implementation in the link above.

https://github.com/Azure/apiops/wiki/Configuration#configuration-yaml

https://github.com/Azure/apiops/wiki/Configuration#configuration-yaml

Ok thanks for that. FYI I did add the configuration faile with the first line of the service name and it works. The only issue is that following the setup documentation I shouldn't need to do that to make it work.
Also, reading the wiki still doesn't make it clear what the APIM_NAME environment variable name should be for the higher environment e.g. APIM_NAME_

We will revise the docs. Thanks.

I fell into this same issue, followed the docs and expected it to work without adding the config, apologies for not raising this myself

@troyha and @dannythomas13 - the configuration file should not be mandatory. If you look at the pipeline, we pass the value of CONFIGURATION_YAML_PATH to the publisher only if it's defined: https://github.com/Azure/apiops/blob/36c7e4e0ac2bd5a7fb64d85e5502c5b486ff63d9/tools/azdo_pipelines/run-publisher-with-env.yaml#L132
Looks like the CONFIGURATION_YAML_PATH is hard-coded in the PROD step here. https://github.com/Azure/apiops/blob/36c7e4e0ac2bd5a7fb64d85e5502c5b486ff63d9/tools/azdo_pipelines/run-publisher.yaml#L64
Remove that line, and it should work without a file. It will get its settings from environment variables. We'll make sure the docs are updated.

Updated the documentation to instruct how to adapt the pipelines to scenarios where the configuration files won't be utilized. @troyha  and @dannythomas13  thank you for your input. Also please take a look at the changes that we carried here on the CONFIGURATION_YAML_PATH section and let us know if you think its better now.

@troyha you bring up a valid point. The intent

@troyha You bring up a valid point. The intent was to push people to go with a configuration file as its the recommended approach vs overriding using environment variables. But I agree that it contradicts with the fact that its optional. Stay tuned for an update.

@troyha please check the updated docs. Thanks again for raising the issue.
Bottom line is, as @guythetechie suggested if you don't want to utilize the configuration file for higher environments, you can simply remove the  CONFIGURATION_YAML_PATH:  $(Build.SourcesDirectory)/configuration.prod.yaml from the environment section where you are calling the publisher template.
I also included a link to the wiki directly to make it clear to folks that they can override the configurations using environment variables. I also highlighted the fact that at a minimum you will need to set the apimServiceName environment variable as the publisher needs it to know where to publish.


[webview] Link to file is not working

file:/// scheme should open the file in default app?

No plant to fix this for the time being.


feat!: deprecate x/params from x/posts

Description
Closes: #XXXX
Deps: https://github.com/desmos-labs/desmos/pull/1097
This PR deprecates x/params features from x/posts.

Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...

[ ] included the correct type prefix in the PR title
[ ] added ! to the type prefix if API or client breaking change
[ ] targeted the correct branch (see PR Targeting)
[ ] provided a link to the relevant issue or specification
[ ] followed the guidelines for building modules
[ ] included the necessary unit and integration tests
[ ] added a changelog entry to CHANGELOG.md
[ ] included comments for documenting Go code
[ ] updated the relevant documentation or specification
[ ] reviewed "Files changed" and left comments if necessary
[ ] confirmed all CI checks have passed

Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...

[ ] confirmed the correct type prefix in the PR title
[ ] confirmed ! in the type prefix if API or client breaking change
[ ] confirmed all author checklist items have been addressed
[ ] reviewed state machine logic
[ ] reviewed API design and naming
[ ] reviewed documentation is accurate
[ ] reviewed tests and test coverage
[ ] manually tested (if applicable)

Waiting https://github.com/desmos-labs/desmos/pull/1097 merged into master


Anime Website

I have made a complete layout of a static anime website.
Issue No.: #615
Website screenshot:

@Harshit-Raj-14 this is assigned to someone else !

@siddhi-244 Yes, I saw, but the last update on that issue was a month ago. So, possibly it was dropped by the one who raised the issue. Since the SWOC is ending and I had made the project. I thought of contributing. Can it still be accepted.

@siddhi-244 @Vanshiii203  Yes, I saw, that it was assigned to someone else, but the last update on that issue was a month ago. So, possibly it was dropped by the one who raised the issue. Since the SWOC is ending and I had made the project. I thought of contributing. Can it still be accepted.
Thank you.

@siddhi-244 @Vanshiii203 Yes, I saw, that it was assigned to someone else, but the last update on that issue was a month ago. So, possibly it was dropped by the one who raised the issue. Since the SWOC is ending and I had made the project. I thought of contributing. Can it still be accepted.
Thank you.

Comment under the issue and get it assigned to yourself and then you can raise a PR


feat: Add warnings for usage of restricted bit sizes

Description
Problem*
Breaking change warning for #4162
Summary*
Additional Context
Documentation*
Check one:

[ ] No documentation needed.
[ ] Documentation included in this PR.
[x] [Exceptional Case] Documentation to be submitted in a separate PR.

PR Checklist*

[x] I have tested the changes locally.
[x] I have formatted the changes with Prettier and/or cargo fmt on default settings.

[Exceptional Case] Documentation to be submitted in a separate PR.
@sirasistant is the plan to document it alongside the actual breaking change?

Yep!


hide manage zones, leave it  in the  file  for devs

#90

@micheal-w-wells Thanks for doing this, there's just a couple things I noticed.
It looks like you accidentally merged the previous PLD error code here: https://github.com/bcgov/range-web/blob/c2171e81f62e0b1d57f2e63e5c5404126647b41a/src/components/rangeUsePlanPage/pastures/PastureBox.js#L116-L125,
https://github.com/bcgov/range-web/blob/c2171e81f62e0b1d57f2e63e5c5404126647b41a/src/components/rangeUsePlanPage/pastures/PastureBox.js#L33-L43.
https://github.com/bcgov/range-web/blob/c2171e81f62e0b1d57f2e63e5c5404126647b41a/src/components/rangeUsePlanPage/pastures/PastureBox.js#L7.
Could you please remove that?
As well, could you please remove the code in Navbar.js, instead of commenting it out like in this PR?

  I'll clean it up. the commented out one normally I'd totally agree, but that button is super handy for me in test so in this case I will leave it there.


major: complete web implementation

👋 Welcome to v0.1.0 (Stable)
In this Pull Request, I am completing & finishing the web implementation. Lots of planning & to-do are complete. Now we can say this is ready and stable enough. The content of the website is totally complete, the project readme are rewrited, lots of package are installed, and lots of changes than master branch. One of incomplete things is localization.
🚧 Changes I've made

Integrate project with Strapi
Localize content with i18n
Implement dark mode
Use dynamic data from Strapi
Improve UI & UX
Add required images
Improve image with <NuxtImg />
Setup SEO & Metadata in meta.ts
Add favicon for the website
Design the OpenGraph image banner for social media preview
More and more styling
Add some SEO-related files

LET'S DO IT.

frfrfrfrfrfr


Feature Request — Obfuscate Tailwind CSS classes

For performance proposes, everything that can be made to improve final bundle size is welcome. Even better if automated.
As feature request, would be nice to obfuscate classes on production bundle. Like webpack-obfuscator, for example.
Example
Original code:
# index.vue

Hey!

# tailwind.css
.text-gray-500 { color: #888; }

Final code:
# index.html

Hey!

# tailwind.css
.a { color: #888; }

What libraries can achieve this? This would be a good option if we could add it as a plugin to the PostCSS config.

I honestly never had success accomplishing this, even with Webpack. For standalone Vite (or PostCSS) I can't even find a reference.
If it helps, some readings:

React with css-modules: (1) (2)
Vue with css-modules: (1) (2)
mangle-css-class-webpack-plugin

This doesn't look like this is a mainstream issue and should therefore be handled individually.


Added explicit nullable references.

Closes #49

Tested locally and found nothing broken. Pushed to staging for further testing - @RobQuincey-DC  @paul-dorsetcouncil
I've discussed a couple of things with Rob that we need to look into a bit more.


performs well in NVIDIA agx platform，and some questions about batch inference

Thanks for your help, I have tested this tool in NVIDIA agx platform, we get a nearly 3X speed up compared using mmdetection directly.That's an amazing result!
And I have another question about batch inference for help. Mmdetection2.4 has supported batch inference. It is useful for us to add batch inference  in this tool. The existed batch inference method in this tool is not work well, right?
By the way, this is really a good tool for the people use mmdetection. I hnow this is your part time job and there are still some inference qusetions while testing.  I will use this tool for a long time and I wish I can do something for  this tool if I can ,such as docs writing, hhhh.
My email<EMAIL_ADDRESS>and wechat : heboyong

Hi
Batch inference works on most models. Just set the opt_shape_param:
    opt_shape_param=[
        [
            [1,3,320,320],
            [1,3,800,1312],
            [4,3,1344,1344],
        ]
    ]

should give you a model with batch support (max_batch_size=4).
And of cause, I do need more help on this project. I will create a group on qq or wechat later. Let's work together to make this project better.

@grimoire Would u like invite me to wechat group? my wechat id: jintianiloveu

@heboyong @jinfagang I have create a QQ group:<PHONE_NUMBER>.
Join if you want to discuss or participate this project.

@heboyong
Hi, I would like to know which method will get nearly 3X speed up compared to using mmdetection directly? I tested the faster rcnn and got about a 30% up.


Default actions and local actions in same update

When a local Rule is evaluated, the assignments deriving from DefaultActions and from Task.Actions are compacted in a single Update.
This behavior does not respect the semantics of AbU that mandates the generation of two Update records: one for the default actions and one for the actions of the task.
Affected versions:

v0.0.0..v0.2.0

Fixed in v0.3.0.


Add ./nobuild tools <tool>... to selectively build tools

You can specify more than one tool as well, eg. ./nobuild tools bme bang

@zhiayang looks goode to me! :+1: Thank you for your contribution! :kissing:


Add redis auth and move connection to redishelpers

Changes proposed

Add support for redis authentication. Currently it assumes the keys for redis.user and redis.password are set in matchmaker_config.json. If this needs to be moved to look at env vars or similar, can do.

Refactored redis connection pool to live in redishelpers (avoids duplication) and updated backendapi, frontendapi, and mmforc entry points to use this helper method.

Misc clean up, such as; removed unreferenced packages and removed trailing whitespace.

Thanks a bunch for submitting a PR!  Nice dry code here.
In this case, we need to keep it relatively easy to have per-component pool settings.  Although all components are currently using the same pool settings, we expect them to have separate scaling requirements under load.  We'll need to preserve the ability to tweak the settings on a per-program basis once we've gotten feedback from production usage and run more comprehensive scale load tests.
Maybe we could add some more changes to work with your approach?  The matchmaker_config.json file could hold the current used values as defaults, then we could add equivalent env vars to config/config.go:envMappings so these values could easily be overridden in the Kubernetes manifests on a per-pod basis?  Thoughts?


RuntimeError: Resource temporarily unavailable for jaxlib>0.1.37 + mpi4py

jax=0.1.62
jaxlib=0.1.43
I bumped into an issue running multiple processes which call jax in parallel using Open MPI. I was able to distill the error as follows:
I'm running the following code snippet with CPU backend:
from mpi4py import MPI
import jax

seed=7
comm=MPI.COMM_WORLD

print(jax.__version__, seed, comm.Get_rank())

jax.lib.xla_bridge.get_backend().platform
rng = jax.random.PRNGKey(seed)

in parallel over 26 (independent) processes using mpi4py by executing the command
mpirun -np 26 python bug.py

This miniprogram runs on a big 128 GB compute node with 30 Haswell processors [more on the Haswell node specifics here]. All processors are reserved exclusively for this calculation.
Every time I run this job, a number of random processes terminate with the jax RuntimeError
Traceback (most recent call last):
  File "./bug.py", line 11, in <module>
    jax.lib.xla_bridge.get_backend().platform
  File "/global/cfs/cdirs/m3444/.conda/envs/jax-debug/lib/python3.8/site-packages/jax/lib/xla_bridge.py", line 163, in get_backend
    return backend(platform)
  File "/global/cfs/cdirs/m3444/.conda/envs/jax-debug/lib/python3.8/site-packages/jax/lib/xla_bridge.py", line 118, in _get_local_backen
d
    backend = xla_client.get_local_backend(platform)
  File "/global/cfs/cdirs/m3444/.conda/envs/jax-debug/lib/python3.8/site-packages/jaxlib/xla_client.py", line 249, in get_local_backend
    backends = _get_local_backends()
  File "/global/cfs/cdirs/m3444/.conda/envs/jax-debug/lib/python3.8/site-packages/jaxlib/xla_client.py", line 225, in _get_local_backend
s
    backend = factory()
  File "/global/cfs/cdirs/m3444/.conda/envs/jax-debug/lib/python3.8/site-packages/jaxlib/xla_client.py", line 169, in _cpu_backend_facto
ry
    client = _xla.get_cpu_client(asynchronous=True)
RuntimeError: Resource temporarily unavailable

I also tried distributing the same 26 MPI processes over two and more identical compute nodes and see the same behavior.
Occasionally, I see the same error occur in the PRNGKey function.
I also found out that this error does NOT occur with jax=0.1.58, jaxlib=0.1.37. Does anyone have an idea what might be causing this -- it must be within the commit jaxlib=0.1.37 --> jaxlib=0.1.38.

We're going to have a hard time debugging this without being able to reproduce it, which might be hard. Does it need a particular MPI setup or does it reproduce in, say, a cloud VM?
I'm not aware of any change in jaxlib that would have intentionally triggered this problem, so we probably need to debug this the hard way.
I think the first step would be to debug what resource we are running out of. Some guesses are

memory
threads
?

If I were going to try debugging this myself, I might see if I can reproduce the behavior under strace and see if I can see which system call failed.

@hawkinsp I'd be happy to try out different suggestions. I can try to reproduce this behavior on a different cluster and see if I get it there. It might be important to understand what the observation tells us that the error does not appear for jaxlib=0.1.37 -- the old version can give us a baseline for comparison.
How do I try to reproduce the behavior under the strace -- I'm not familiar with this.

I checked two more linux platforms, and my mac's osx: the upshot is that 2/3 linux platforms give the same error; the other linux platform and the osx platform do not throw an error. How can I get the details of the faulty linux platforms to share them here?
Is it expected that the pip version of jax shows problems on some linux platforms?
The good news is that to reproduce the error it seems like we don't need a node with a large number of cores. All one needs is to run the minimal code snippet above with more than 24 MPI processes:
mpiexec -np 26 python -W ignore bug.py

Could you share the output of uname -a and ulimit -a for the Linux platforms, both those that failed and those that succeeded?
I'm unable to reproduce this problem on a Google Compute Platform cloud VM under Debian 10. I created an n1-standard-64 instance (64 vCPUs) and installed Debian 10. I installed Python 3.7 and mpi4py using apt and everything seems to work fine with your repro.
If you were able to reproduce this on a reasonably standard linux platform, it would be helpful if you can share details. I need to be able to reproduce this to debug it, and the best case would be that we can reproduce it in some configuration we can both get access to (e.g., on a cloud VM).

linux platform (error shows up)

Linux cori01 4.12.14-150.47-default #1 SMP Wed Dec 18 15:05:52 UTC 2019 (8162e25) x86_64 x86_64 x86_64 GNU/Linux
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 2060260
max locked memory       (kbytes, -l) unlimited
max memory size         (kbytes, -m) unlimited
open files                      (-n) 4096
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) unlimited
cpu time               (seconds, -t) unlimited
max user processes              (-u) 2048
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Linux platform (error shows up)

Linux scc1 3.10.0-1062.12.1.el7.x86_64 #1 SMP Tue Feb 4 23:02:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) 20000000
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 1030652
max locked memory       (kbytes, -l) unlimited
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1024
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

linux platform (NO error)

Linux cuiw-ubuntu 4.15.0-96-generic #97-Ubuntu SMP Wed Apr 1 03:25:46 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 126673
max locked memory       (kbytes, -l) 16384
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 126673
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

linux platform (NO error)

Linux fe001 4.4.0-31-generic #50-Ubuntu SMP Wed Jul 13 00:07:12 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 15665
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 15665
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

I think the issue is the value of ulimit -u, the limit on the number of user processes. Here "user processes" also includes threads, and Jax is creating, for each process spawned by MPI, a threadpool with one thread per CPU core.
e.g., on my n1-standard-64 with an IPython session that has run a trivial JAX computation, I see:
ps -AL | grep 6947 | wc -l
83

If I set ulimit -u 1024 before calling mpirun, I also see the Resource exhausted error.
JAX uses threading internally in some fairly fundamental ways, so we're not going to be able to eliminate threading, but we can certainly provide an option to reduce the size of some of the internal threadpools. Or perhaps we can detect this kind of MPI configuration and choose a more appropriate thread pool size automatically.
You might be able to work around the problem for now by raising ulimit -u, but you might need superuser privileges on your machine to do this.

@hawkinsp I see, so what is the proper way to manually set the number of threads that jax creates? I feel like I should be able to tell it to use a single thread if needed. This is particularly helpful when large simulations are launched and one needs to fit within the available resources.
I currently have
os.environ['MKL_NUM_THREADS']='1' # set number of MKL threads to run in parallel
os.environ['OPENBLAS_NUM_THREADS']='1'
os.environ['OMP_NUM_THREADS']='1'

os.environ["NUM_INTER_THREADS"]="1"
os.environ["NUM_INTRA_THREADS"]="1"

# set XLA threads and parallelism
os.environ["XLA_FLAGS"] = "--xla_cpu_multi_thread_eigen=false intra_op_parallelism_threads=1"
os.environ["XLA_PYTHON_CLIENT_PREALLOCATE"]="0"

but it doesnt see to help.

JAX uses threading internally in some fairly fundamental ways, so we're not going to be able to eliminate threading, but we can certainly provide an option to reduce the size of some of the internal threadpools. Or perhaps we can detect this kind of MPI configuration and choose a more appropriate thread pool size automatically.

I see, and then it must be this intrinsic threading in jax, that was updated when jaxlib=0.1.37 --> jaxlib=0.1.38 so when I ran my code with jaxlib=0.1.37, the required intrinsic number of threads was smaller so the calculation was able to fit within the memory requirements. I guess this makes sense.

Happily it turns out there's an easy solution to this: the libraries underlying JAX respect CPU affinity values and when creating a threadpool sizes it according to the task's CPU affinity map. So if you tell MPI to assign, say, one core per process via the appropriate options to mpirun, JAX will size its thread pool appropriately. You'll still have more than one thread, but this should work well enough to solve your problem.
e.g.,
mpirun --cpus-per-proc 1 -np 26 python3 t.py

worked fine for me. (I gather you should probably use --map-by instead of --cpus-per-proc these days but I don't know MPI and I leave that part as an exercise for the reader.)
Does that help?

Unfortunately neither of
mpirun --cpus-per-proc 1 -np 26 python t.py
mpirun --map-by 15 -np 26 python t.py
mpirun --map-by ppr:15:core -np 26 python t.py
mpiexec --map-by ppr:15:core -np 26 python t.py

etc. work for me.
However, the idea is spot on, because the SLURM command srun has a similar flag which did the job:
srun --ntasks-per-core 1 -n 26 python t.py

@hawkinsp it might be helpful to comment on this somewhere on the jax documentation page.


Bump inmanta-dev-dependencies[async,extension,pytest] from 2.66.0 to 2.67.0 (#390)

Pull request opened by the merge tool on behalf of #390

Merged in 6735e914c4a37edc0c9eab0dee54ad065c3a96fd


Manually mapping column names to object properties

There is a question on SO  for the same issue with Dapper, which has already been answered.
How can I do this with sqlkata?

Why not using alias?
class User
{
  public string UserName {get; set;}
}

var users = db.Query("Table").Select("user_name as UserName").Get<User>();