Accessibility does not scroll past after a certain row

Hi @ashfurrow,
Thanks for the tutorial, as always it's a great read :+1:
I've implemented in a similar fashion in one my (Swift) projects where each UITableViewCell contains a UICollectionView and each collectionView then has UICollectionViewCell's. And my collectionView cell is again customized in a Xib.
Now when I tried to implement accessibility on this, this is going through some weird behavior
What I did so far -
(1) Since each UITableViewCell contains UICollectionView, so I set tableview cell's accessibility to false.
e.g. dummyTableViewCell.isAccessibilityElement = false
(2) Then I override UIAccessibilityContainer methods on my UICollectionView class.
e.g.      override func accessibilityElementCount() -> Int {                  return subViews.count }
and so on
While this reads through every element  of collectionView inside tableView cell, but then VO stops after 4th or 5th row and does not scroll past anymore. I did try again w/ implementing UIScrollView delegate methods, but nothing is working out so far.
I'm not sure what I'm missing here. Any pointers would certainly help.  Thanks Ash!

Hmm, good question! I think the issue is the count you're returning. I haven't done accessibility on this tutorial (might make for a good follow up!) but the subviews count won't be the total number of cells since cells are reused (if you have a collection view with 100 cells but only 5 fit on screen at once, the you'll only ever have dice subviews). I'm away right no but I'll try take to take a look when I get back. In the meantime, if you find a solution, please let me know!

Did you make any progress on this @manojmahapatra?

@jeffbowen I fixed my actual issue w/ a tweak how VoiceOver should read out the parent view UITableViewCell in my case. So VoiceOver is reading out TableViewCell instead it's child view, which is UICollectionView and double tapping each child view (UICollectionViewCell) will traverse to specific controller for further use.
I'm not sure whether you are looking for the above solution, might be different in your case. Let me know.

@manojmahapatra Interesting. I'm trying to replicate the behavior of the App Store app where it scrolls through all the collection view cells in a row. Wonder if they implemented their collection views in table view cells differently than @ashfurrow's solution or if they just did a good amount of custom work to get accessibility working like that.

@jeffbowen  have you succeeded with this issue?

@MelanyG No. I had to move on.

setting below code on tableview cell
accessibilityElements = [collectionView]
worked for me


Save deletes pdf file

Description
Having my phd-thesis project opened in atom, and having compiled (latex) earlier, upon saving (cmd-s), the compiled pdf-file is deleted (sic! - not moved to trash) from the project folder.
Steps to Reproduce

Clone the rep https://github.com/valentin-krasontovitsch/phd-thesis
Add project folder in atom
Open loday.tex
Hit your keyboard shortcut for save while in the editor pane or choose save from the file menu

Expected behavior:
Nothing (since no actual changes to file)
Actual behavior:
phd_thesis_krasontovitsch.pdf gets deleted
Versions
Atom    : 1.8.0
Electron: 0.36.8
Chrome  : 47.0.2526.110
Node    : 5.1.1
OS X El Capitan Version 10.11.5
NB problem reproducable without any latex packages (more precisely: on clean install) installed, and in safe mode.

the same thing is happening with other editors, so i guess this is a problem with my computer....


Add local node maintainers and committers

Add maintainers and committers groups for hiero-local-node

@hendrikebbers I rebased on top of main to remove the deleted user attest08.


UIPCIR-6 provide fast-add permission-set

Provide a permission set, Fast add: Create, for use in other modules
that plan to have a "fast-add" button.
Refs UIPCIR-6

Test errors found. See https://jenkins-aws.indexdata.com/job/folio-org/job/ui-plugin-create-inventory-records/job/PR-15/1/

Test errors found. See https://jenkins-aws.indexdata.com/job/folio-org/job/ui-plugin-create-inventory-records/job/PR-15/2/


MDEXP-726 - Extend mapping profile schema

Purpose
Describe the purpose of the pull request.
MDEXP-726 - Extend mapping profile schema
Approach
How does this change fulfill the purpose?
TODOS and Open Questions

[ ] Use GitHub checklists. When solved, check the box and explain the answer.

Learning
Describe the research stage. Add links to blog posts, patterns, libraries or addons used to solve this problem.


readNativeFrames Performance Optimizations

This is an issue to track various investigations and changes to optimize readNativeFrames implementation, which I noticed in pprof profiles seemed to take up a majority of the CPU time in parsing DICOMs with Native pixel data.
More comprehensive tests and benchmarks were added in #160 to aid with this.

#157 led to some significant performance improvements by reducing slice allocations.

Also, on this subject, @kaxap has observed that eliminating calls to binary.Read may reduce slice allocations and improve performance a bit, so that's something we should try. In particular, doing something like the following to read uint8, uint16, uint32s, etc:
buf := make([]byte, bitsAllocated/8)
for pixel := 0; pixel < pixelsPerFrame*samplesPerPixel; pixel++ {
  _ := io.ReadFull(d, buf)
  val := int(binary.LittleEndian.Uint16(buf))
}

The main advantage here is reusing the buffer slice (since bitsAllocated should be constant), instead of binary.Read creating one within.

it is also possible to lazily load frames from file which will result in smaller memory footprint (some dicom files can be gigabytes in size)

This is somewhat along the lines of #162--which is allowing interested parties to not read the pixel data, or perhaps, to pause reading before actually parsing the PixelData. We can also read in the bytes and do nothing with unpacking them until a user wants the image.Image, which is almost what we do today. I'm leaning towards something similar to current behavior + an option to not read PixelData (or any blocklist of tags potentially). We also already have a "streaming" option where frames can be consumed by a consumer as they are parsed, instead of having to wait for the full set of frames (or the whole dicom) to be parsed.
What do you think? Also, would love to learn more about your use cases if you have any particular ones. Cheers!

Most of the cases all I want to do is to get some tags and a single frame rendered (for a thumbnail or a preview). Lazy mode (when we save offsets in file for each frame instead of reading all of them into RAM) looks very appealing in this case.

Regarding memory usage, we've recently had our server (32GB RAM) run out of memory while attempting to parse a 1GB zipfile containing dicoms.
Using pprof, I've benchmarked parsing a 55MB zipfile containing 222 dicom images (each image 526KB, total ~117MB unzipped) and noticed readNativeFrames() ballooning memory usage to ~1.74GB.
Is this high memory usage (15x) expected?

Interesting, thank you for reporting! I don't think this is expected. Out of curiosity, what version of the library are you using? Does it include some of the recent optimizations included in this issue?
I'll take a closer look tonight and dive deep if needed this weekend.

Thanks for looking into this! I don't have much experience profiling performance so I appreciate the help.
Our prod server that ran out of memory is using v0.4.5, which obviously does not have the recent optimizations.
However, my benchmark is using v1.0.3. We were hoping that upgrading the library would solve the issue.

Thanks! So, something that sticks out to me is that we are packing smaller integers into the possibly larger go int type in the NativeFrame. This is done in order to have a clean API with the same static types for the caller no matter what the underlying integer type might be (e.g. 8-bit, 16-bit unsigned integers). I think this is useful from the user's perspective, so they have one NativeFrame type to deal with, and they can use regular 'ol ints.
However, this could easily cause large increases in memory compared to the size of a DICOM on disk--for example an underlying set of 8-bit integers in the DICOM would be read into a slice of normal Go ints--which might be 32 or 64bits wide (8 times more memory).
This is a situation in which generics in Go would be very helpful, so we could have a NativeFrame<intLikeType>.
Simple option?
One temporary and somewhat simple solution could be using uint32 in this API instead of int, if I can verify that DICOMs don't ever have 64 bits of data in them for NativeFrames (this saves 32 bits per int on 64-bit wide systems).
More involved option
Another option is exploring having a different NativeFrame type per size of integer. While it's not the cleanest as just being able to access the underlying data directly, I could envision something like the below, where we make NativeFrame an interface and not a struct. And, we have 3 structs that implement the interface that wrap the underlying int types.

type NativeFrame interface {
    Rows() int
    Cols() int
    BitsPerSample int
    GetPixel(x, y int) int
}

type nativeFrame8 struct {
    underlyingData uint8
}
...
type nativeFrame16 struct {
    underlyingData uint16
}
...

In the absense of generics, this will allow our memory representation to be as small as possible, while still exposing a consistent integer API for any entities that want to use the NativeFrame data. That being said, if a caller is copying out the data from the underlying NativeFrame, and grabbing it as ints, we'll run into the same problem of expanding it in memory anyway, just downstream from here (e.g. when turning this into an image later for example, if it goes through an intermediate int stage)...so might need to look at a couple of our use cases to see.
Let me know if folks have any thoughts or if you can shed light on any use case specific details.
Also, this might not explain all of the memory overhead--will look into other possible options soon too.
We should be able to use the BenchmarkReadNativeFrames to see the impact of various possible changes on the memory profile at least in that fn.

Reading through the DICOM spec, it appears that allocating more than 32 bits is rare. If I'm understanding correctly, 64 bits are only used for Double Float Pixel Data.
FWIW, I've looked at ~90 chest CT scans that have been uploaded to our web app by doctors and they all allocate 16 bits.
Our use case involves parsing a CT scan with 1-N series. For each series, we parse the header to immediately filter out series that don't meet our criteria (not enough slices, too large slice thickness, etc.). After getting a list of viable series, we parse & store the pixel data for every slice in these series (this can take up a lot of memory if the scan has many viable series). After creating a 3D volume from the series' pixel data, we then save jpg images as slices for each anatomical plane (coronal, axial, sagittal). Saving the images doesn't require much memory since we write each pixel sequentially, converting it from int to uint16 (similar to NativeFrame.GetImage()).
If you don't mind, I'm going to take a stab at implementing the NativeFrame interface. I don't think we should worry too much about downstream memory usage with this implementation. The user can drop bits by converting the int returned by GetPixel() to whatever uint type they wish so int isn't stored long-term.

@bbeckrest That is my understanding as well re: the size of the pixel data.
Regarding the NativeFrame interface I proposed in https://github.com/suyashkumar/dicom/issues/161#issuecomment-846706345 I think it's reasonable but keeping in mind my performance comment.
With my performance comment, what I meant was calling GetPixel() int in certain circumstances will allocate a fullsize integer. In some cases, that integer may only be temporary, and be sent for garbage collection--like if iterating and processing pixel by pixel--this is the scenario in which we will see a drastic reduction in memory. In other scenarios we will not see a reduction in memory footprint, at the cost of a slightly more API. That might be an okay tradeoff, but it is probably still a narrow set of use cases. On the otherhand, not using int in the API, and instead using int32 always will always help in 64 bit systems--maybe we can give the user the option to grab other sizes of ints. We need to be careful about possible overflow here though.
Overall I think my proposal is ok https://github.com/suyashkumar/dicom/issues/161#issuecomment-846706345, and I think it should be a good tradeoff in the interim, espicially if it will help you with your usecase. I'm not 100% sure if it will solve all of your problems, if during the creation of the 3D Volume you ever hold the whole series in memory as full ints, but you of course have a better sense of that than I! I think that generics in Go will help a lot here so we can have PixelData<IntType> types (or something like that).
Please let me know if you'd like to send a PR for this, and let me know if there are any questions! No worries if you don't have time, I can knock this out at some point soon too. 😄

@suyashkumar Yeah the proposal in https://github.com/suyashkumar/dicom/issues/161#issuecomment-846706345 would be helpful for my use-case since the volume could be stored as uint16.
Yesterday, I attempted to implement it but got stuck and realized I didn't really know what I was doing (here's my attempt). It's a decently large & important change so I'll probably defer to you here. I was having an issue implementing the NativeFrames interface while minimizing the API change.

hi @bbeckrest! So there is another issue that may somehow be related to this (though I'm not exactly sure how or why). For files that have a weird bytesAllocated, we ended up not reading the pixel data correctly, which I'm addressing in #210. Another user of the library was experiencing around 1.7GB of memory being allocated (that wasn't being cleaned up properly by the Go gc) and their dicom was triggering this condition. It could still very well be an independent issue. Just figured I'd mention it!
Anyway, I do think I will circle back to my proposed solution above, and will take a look at your attempt as well!

though I'm not exactly sure how or why

We have a DICOM (33Mb) with bitAllocated = 1

using pydicom to read the pixel data results into an array with type=uint8 251 Mb ~ 33 Mb * 8
using this library results into about 2Gb ~ 251 Mb * 8 memory located, the output array is []int (64bit)

I guess the issue is from data type representation.

Yep, in the case you describe that is the case (though in the comment above I was referring to another issue).
https://github.com/suyashkumar/dicom/issues/161#issuecomment-846706345 is where I lay out a possible interface for handling this in as clean of a way as possible. I can probably also add a getData interface{} that people can type assert to the right underlying type too if they just want the underlying data.
Though now that go has generics in 1.18 we may be able to adopt those to have a NativeFrame, but if we do, then folks will need to have a hard dep on at least go 1.18 and we would have generics exposed in a public API (which may not be that bad at this point...)

 It needs a lot of clean up and extra testing, but feel free to play with it if you have dicoms that were previously causing you issues.

So with the exploratory changes in #315, I've learned of another large contributor to this memory ballooning, and it's not the uint16->int64 expansion interestingly iiuc.
Right now, the way frames parse the data is a 2D array something like [][]uint16, with the first dimension being the pixel, and the inner dimension being the number of values per pixel (as a slice). So the way this is setup, we have 1 []uint16 slice per pixel. Well, it looks like an empty slice descriptor in Go itself is 24 bytes (!) (initial ref), so this means we're allocating 24 bytes per pixel to often times store 1-3 values per pixel (that are each 2 bytes only in the case of uint16)!
So, at a minimum, we might want to store a flat underlying representation of the values in the frame, and then offer APIs that help you navigate by pixel easily as needed. (That is, if we even want to process NativePixelData at all during processing).
Either way, even if we process it later, we'll want to be mindful of this. I haven't verified that this is the issue, but I'm guessing much of the memory is actually going to the slice headers as opposed to the uint16->int64 expansion!

Some updates: in https://github.com/suyashkumar/dicom/pull/315#issuecomment-2274827280 you'll see an implementation that yields significant memory and cpu improvements for native pixeldata processing. I still need to iterate and clean up some tests / api though. Please let me know if you have any thoughts in general here though. This will be a pretty significant change to how Native PixelData is represented and interacted with.


generate-sas expiry example doesn't work on official docker image

This is autogenerated. Please review and update as needed.
Describe the bug
The following expiry example from here does not work on the official az cli docker image.

end=`date -u -d "30 minutes" '+%Y-%m-%dT%H:%MZ'`
sas=`az storage container generate-sas -n mycontainer --https-only --permissions dlrw --expiry $end -o tsv`
az storage blob upload -n MyBlob -c mycontainer -f file.txt --sas-token $sas

Command Name
This issue relates to the az storage container generate-sas command, but the problem in the example is with the date command.
Errors:
docker run -it mcr.microsoft.com/azure-cli:latest bash
bash-5.1# end=`date -u -d "30 minutes" '+%Y-%m-%dT%H:%MZ'`
date: invalid date '30 minutes'

To Reproduce:
See "Errors" section.
Expected Behavior
I expect a date example that works on the official docker image.
Environment Summary
Linux-5.10.25-linuxkit-x86_64-with, Alpine Linux v3.16
Python 3.10.5
Installer: DOCKER

azure-cli 2.39.0

Additional Context
None

@evelyn-ys for awareness

This is actually not CLI issue. You can use man date to see the usage for date command in bash.
date -u -d "30 minutes" '+%Y-%m-%dT%H:%MZ' does work:

Official image uses alpine as base image. The date command in alpine does not support -d flag (https://github.com/docker-library/official-images/issues/771).
Installing coreutils date to make it work again: apk add --update coreutils.
@jiasli Should we fix this in docker image?
https://github.com/Azure/azure-cli/blob/ddd64676165eba9c8ea22fac1270711b8ca9da09/Dockerfile#L8


⚙Tech Debt: Conditionally set aria-labelledby in builders using createLabel

Some components use the internal createLabel builder, such as createCombobox. But if an user doesn't use the label, we're still setting aria-labelledby, which shouldn't happen.

Are we thinking the label action should update some sort of store like using label which the element the aria-labelledby attribute is applied to depends on so we can update it?

Are we thinking the label action should update some sort of store like usingLabel which the element the aria-labelledby attribute is applied to depends on so we can update it?

That could be a solution! Or we override the label builder itself.
Another suggestion by @paoloricciuti was to provide the id as an option. But I think most people will probably ignore it. I'd like some mix between the two somehow though... Have to think this one through.

As per the aria-labelledby set via the store that gets set to true when using the label action I think it could be a good idea but has @TGlide pointed out this will make aria-labeledby not ssrable...it shouldn't be that much of a problem especially since if you are using the label you still get the for->Id relation to link them.
Another option could be let the user specify during the creation fase if you want the label or not (although not very pretty can solve the SSR issue)

Related issue: "The aria-controls attribute must point to an element in the same document" (#752)
Seems like a bit of a chicken-egg problem, since the dialog isn't created until the button is pressed.
https://validator.w3.org/nu/?doc=https://www.melt-ui.com/docs/builders/dialog


59 | Spiral Matrix II | C++

Title - Spiral Matrix II
What will change - C++ solution for the problem will be added afresh
Type of Issue -
Please add/delete options that are not relevant.

[x] Adding New Code

Programming Language
Please add/delete options that are not relevant.

[x] C++

Self Check

Ask for issue assignment and wait to get assigned to it before making Pull Request.
Add your file in the proper folder
Clean Code and Documentation for better readability
Add Title and Description of the program in the file

:star2: Star it :fork_and_knife:Fork it :handshake: Contribute to it!
Discord server ✉ - https://discord.gg/CXksGdn
Happy Coding,

Title - Spiral Matrix II
What will change - C++ solution for the problem
Type of Issue -
Please add/delete options that are not relevant.
Adding New Code
Programming Language
Please add/delete options that are not relevant.
C++
Self Check
Ask for issue assignment and wait to get assigned to it before making Pull Request.
Add your file in the proper folder
Clean Code and Documentation for better readability
Add Title and Description of the program in the file
🌟 Star it 🍴Fork it 🤝 Contribute to it!
Discord server ✉ - https://discord.gg/CXksGdn
Happy Coding,

please assign this task to me

I appreciate it if you could assign this issue to me. I would love to work on it.
Thank you.

@rituraj735 you cooldown for a while.

[x] Assigning to @NavyaIyanampudi


the doc for the docker mount path is not clear

System Info
context: when use transformer library, the model params are in cache, for example, ~/.cache/huggingface/hub/models--meta-llama--Llama-2-7b-hf/snapshot/<commit_id>/<model_params_tensor.bin>.
if the model params has been in local, how to mount and how to set the model_id in TGI? the doc is not clear.

the mount  relative path is regarding the snapshot or the ultimate model parameter tensor?
in container, the model will load the parameters under the folder /data?  has no doc for the /data

volume= <relative path for what?>  # for the snapshot or the ultimate model parameter tensor?

docker run --gpus all --shm-size 1g -p 8080:80 -v $volume:/data ghcr.io/huggingface/text-generation-inference:1.3 --model-id $<what_to_set????>

the doc for relationship between the mount volume and model_id is not clear
Information

[X] Docker
[ ] The CLI directly

Tasks

[X] An officially supported command
[ ] My own modifications

Reproduction
model = org_name/model_name #??
volume= <what_to_set??> #regarding the snapshot or the ultimate tensor.pth??
docker run --gpus all --shm-size 1g -p 8080:80 -v $volume:/data ghcr.io/huggingface/text-generation-inference:1.3 --model-id $<what_to_set????>

Expected behavior
more clear doc for the docker mount path

Totally agree on this, a docker-compose.yml would be beneficial also! Great repo!

I am totally new to this docker stuff, also immediately failed trying to run a local model.
this is what worked for me. assume your model dir is ./models and there's Mistral-7B-Instruct-v0.2 in there:
docker run --gpus all --shm-size 1g -p 8080:80 \
        -v ./models:/models \
        ghcr.io/huggingface/text-generation-inference:latest \
        --model-id /models/Mistral-7B-Instruct-v0.2


SECURITY.md

🟡 Heimdall Review Status

Requirement
Status
More Info

Reviews

🟡
0/1

Denominator calculation

Show calculation

1 if user is bot
0

1 if user is external
0

From .codeflow.yml

1

Additional review requirements

Show calculation

Max
0

0

From CODEOWNERS

0

Global minimum
0

Max

1

1

1 if commit is unverified
0

Sum
1

Review Error for mookey86 @ 2024-12-04 03:44:39 UTC
User must have write permissions to review


chore(deps): update all non-major

This PR contains the following updates:

Package
Type
Update
Change

axum
dependencies
minor
0.6.20 -> 0.7.2

clap
dependencies
patch
4.4.8 -> 4.4.10

cockroachdb/cockroach

patch
v23.1.11 -> v23.1.12

config
dependencies
patch
0.13.3 -> 0.13.4

http
dependencies
patch
0.2.10 -> 0.2.11

leptos
dependencies
patch
0.5.2 -> 0.5.4

pikav-client (source)
dependencies
patch
0.20.3 -> 0.20.5

prost
dependencies
patch
0.12.1 -> 0.12.3

rust
final
minor
1.73-alpine3.17 -> 1.74-alpine3.17

serde (source)
dependencies
patch
1.0.192 -> 1.0.193

sqlx
dev-dependencies
patch
0.7.2 -> 0.7.3

sqlx
dependencies
patch
0.7.2 -> 0.7.3

tracing-subscriber (source)
dependencies
patch
0.3.17 -> 0.3.18

twa-jwks (source)
dependencies
patch
1.2.4 -> 1.2.6

uuid
dependencies
minor
1.5.0 -> 1.6.1

Release Notes

tokio-rs/axum (axum)
v0.7.2: axum - v0.7.2
Compare Source

added: Add axum::body::to_bytes (#2373)
fixed: Gracefully handle accept errors in serve (#2400)

v0.7.1: axum - v0.7.1
Compare Source

fix: Fix readme.

v0.7.0: axum - v0.7.0
Compare Source

breaking: Update public dependencies. axum now requires

hyper 1.0
http 1.0
http-body 1.0

breaking: axum now requires tower-http 0.5
breaking: Remove deprecated WebSocketUpgrade::max_send_queue
breaking: The following types/traits are no longer generic over the request body
(i.e. the B type param has been removed) (#1751 and #1789):

FromRequestParts
FromRequest
HandlerService
HandlerWithoutStateExt
Handler
LayeredFuture
Layered
MethodRouter
Next
RequestExt
RouteFuture
Route
Router

breaking: axum no longer re-exports hyper::Body as that type is removed
in hyper 1.0. Instead axum has its own body type at axum::body::Body (#1751)
breaking: extract::BodyStream has been removed as body::Body
implements Stream and FromRequest directly (#1751)
breaking: Change sse::Event::json_data to use axum_core::Error as its error type (#1762)
breaking: Rename DefaultOnFailedUpdgrade to DefaultOnFailedUpgrade (#1664)
breaking: Rename OnFailedUpdgrade to OnFailedUpgrade (#1664)
breaking: TypedHeader has been move to axum-extra (#1850)
breaking: Removed re-exports of Empty and Full. Use
axum::body::Body::empty and axum::body::Body::from respectively (#1789)
breaking: The response returned by IntoResponse::into_response must use
axum::body::Body as the body type. axum::response::Response does this
(#1789)
breaking: Removed the BoxBody type alias and its box_body
constructor. Use axum::body::Body::new instead (#1789)
breaking: Remove RawBody extractor. axum::body::Body implements FromRequest directly (#1789)
breaking: The following types from http-body no longer implement IntoResponse:

Full, use Body::from instead
Empty, use Body::empty instead
BoxBody, use Body::new instead
UnsyncBoxBody, use Body::new instead
MapData, use Body::new instead
MapErr, use Body::new instead

added: Add axum::extract::Request type alias where the body is axum::body::Body (#1789)
added: Add Router::as_service and Router::into_service to workaround
type inference issues when calling ServiceExt methods on a Router (#1835)
breaking: Removed axum::Server as it was removed in hyper 1.0. Instead
use axum::serve(listener, service) or hyper/hyper-util for more configuration options (#1868)
breaking: Only inherit fallbacks for routers nested with Router::nest.
Routers nested with Router::nest_service will no longer inherit fallbacks (#1956)
fixed: Don't remove the Sec-WebSocket-Key header in WebSocketUpgrade (#1972)
added: Add axum::extract::Query::try_from_uri (#2058)
added: Implement IntoResponse for Box<str> and Box<[u8]> ([#2035])
breaking: Simplify MethodFilter. It no longer uses bitflags (#2073)
fixed: Fix bugs around merging routers with nested fallbacks (#2096)
fixed: Fix .source() of composite rejections (#2030)
fixed: Allow unreachable code in #[debug_handler] (#2014)
change: axum's MSRV is now 1.66 (#1882)
added: Implement IntoResponse for (R,) where R: IntoResponse (#2143)
changed: For SSE, add space between field and value for compatibility (#2149)
added: Add NestedPath extractor (#1924)
added: Add handle_error function to existing ServiceExt trait (#2235)
breaking: impl<T> IntoResponse(Parts) for Extension<T> now requires
T: Clone, as that is required by the http crate (#1882)
added: Add axum::Json::from_bytes (#2244)
added: Implement FromRequestParts for http::request::Parts (#2328)
added: Implement FromRequestParts for http::Extensions (#2328)
fixed: Clearly document applying DefaultBodyLimit to individual routes (#2157)

clap-rs/clap (clap)
v4.4.10
Compare Source
Documentation

Link out to changelog
Cross link derive's attribute reference to derive tutorial

v4.4.9
Compare Source
Fixes

(help) Show correct Command::about under flattened headings
(help) Respect hide when flattening subcommands

mehcode/config-rs (config)
v0.13.4
Compare Source

hyperium/http (http)
v0.2.11
Compare Source
What's Changed

Fix MIRI warnings in HeaderMap::iter().

leptos-rs/leptos (leptos)
v0.5.4
Compare Source
v0.5.4
v0.5.3 inadvertently introduced a regression in the <A/> tag that broke [aria-current=page]. Here's 0.5.4 with a fix!
0.5.3 release notes below:

Along with the usual set of bugfixes and small improvements, there are two noteworthy additions in this release.
Improved rust-analyzer support in #[component] macro body
Good LSP support for proc macros is hard, because proc macros depend on parsing a stream of input into a valid Rust syntax tree, but while typing you are constantly creating a stream of new, invalid trees. This release tweaks how the #[component] macro emits code in order to enable better rust-analyzer support within the body of components.
If you've disabled rust-analyzer inside #[component] for better DX, try toggling that off and see if this is a better experience than it was before!
Apologies for any regressions this causes. Please report any issues that arise.

There is still additional work to be done to support rust-analyzer in the view! macro. The hoped-for improvements here are solely inside the #[component] body.

Optional Context <Provider/> Component
Since 0.5.0, there've been a couple instances of bugs or confusing behavior related to the fact that context now follows the reactive graph, not the component tree (see #1986, #2038).
This release includes a <Provider/> component that provides a certain value via context only to its children:

#[component]
pub fn App() -> impl IntoView {
    // each Provider will only provide the value to its children
    view! {
        <Provider value=1u8>
            // correctly gets 1 from context
            {use_context::<u8>().unwrap_or(0)}
        </Provider>
        <Provider value=2u8>
            // correctly gets 2 from context
            {use_context::<u8>().unwrap_or(0)}
        </Provider>
        // does not find any u8 in context
        {use_context::<u8>().unwrap_or(0)}
    }
}

provide_context continues working as it has since 0.5.0, and if you're using it without problems you can ignore this, or use it if you prefer to aesthetics. If you're in a situation where you need to provide multiple context values of the same type and ensure that they are scoped correctly and that siblings do not overwrite one another, use <Provider/>. If you have no idea what I mean, check the issues above for examples of the bugs this fixes.
What's Changed

docs: make it easy to see how to run each example in its README by @gbj in https://github.com/leptos-rs/leptos/pull/2085
Fix aria-current attribute value by @alexisfontaine in https://github.com/leptos-rs/leptos/pull/2089

Full Changelog: https://github.com/leptos-rs/leptos/compare/v0.5.3...v0.5.4
v0.5.3
Compare Source
v0.5.3
Along with the usual set of bugfixes and small improvements, there are two noteworthy additions in this release.
Improved rust-analyzer support in #[component] macro body
Good LSP support for proc macros is hard, because proc macros depend on parsing a stream of input into a valid Rust syntax tree, but while typing you are constantly creating a stream of new, invalid trees. This release tweaks how the #[component] macro emits code in order to enable better rust-analyzer support within the body of components.
If you've disabled rust-analyzer inside #[component] for better DX, try toggling that off and see if this is a better experience than it was before!
Apologies for any regressions this causes. Please report any issues that arise.

There is still additional work to be done to support rust-analyzer in the view! macro. The hoped-for improvements here are solely inside the #[component] body.

Optional Context <Provider/> Component
Since 0.5.0, there've been a couple instances of bugs or confusing behavior related to the fact that context now follows the reactive graph, not the component tree (see #1986, #2038).
This release includes a <Provider/> component that provides a certain value via context only to its children:

#[component]
pub fn App() -> impl IntoView {
    // each Provider will only provide the value to its children
    view! {
        <Provider value=1u8>
            // correctly gets 1 from context
            {use_context::<u8>().unwrap_or(0)}
        </Provider>
        <Provider value=2u8>
            // correctly gets 2 from context
            {use_context::<u8>().unwrap_or(0)}
        </Provider>
        // does not find any u8 in context
        {use_context::<u8>().unwrap_or(0)}
    }
}

provide_context continues working as it has since 0.5.0, and if you're using it without problems you can ignore this, or use it if you prefer to aesthetics. If you're in a situation where you need to provide multiple context values of the same type and ensure that they are scoped correctly and that siblings do not overwrite one another, use <Provider/>. If you have no idea what I mean, check the issues above for examples of the bugs this fixes.
Complete Changelog

fix: relax 'static bound on as_child_of_current_owner by @gbj in https://github.com/leptos-rs/leptos/pull/1955
IntoView and IntoAttribute for std::fmt::Arguments improvements by @tqwewe in https://github.com/leptos-rs/leptos/pull/1947
workflows: bump setup-node to version 4. by @martinfrances107 in https://github.com/leptos-rs/leptos/pull/1944
Minor: bumped tj-actions/changed-files to @39. by @martinfrances107 in https://github.com/leptos-rs/leptos/pull/1942
feat: add new method to Trigger by @tqwewe in https://github.com/leptos-rs/leptos/pull/1935
feat: impl IntoAttribute for Cow<'static, str> by @tqwewe in https://github.com/leptos-rs/leptos/pull/1945
chore: Add server to procMacro for helix as well by @kerkmann in https://github.com/leptos-rs/leptos/pull/1951
Allow arbitrary attributes for anchor component by @koopa1338 in https://github.com/leptos-rs/leptos/pull/1953
fix: add leptos_axum::build_static_routes (closes #1843) by @gbj in https://github.com/leptos-rs/leptos/pull/1855
Implement IntoAttribute for TextProp by @SleeplessOne1917 in https://github.com/leptos-rs/leptos/pull/1925
chore: fix clippy on login_with_token_csr_only by @gbj in https://github.com/leptos-rs/leptos/pull/1965
fix: router docs feature stable to nightly by @chrisp60 in https://github.com/leptos-rs/leptos/pull/1959
chore: typed-builder and typed-builder-macro - bumped version numbers. by @martinfrances107 in https://github.com/leptos-rs/leptos/pull/1958
fix: leptos_router::params_map! by @chrisp60 in https://github.com/leptos-rs/leptos/pull/1973
docs: Fix 08_parent_child.md callback example code. by @gibbz00 in https://github.com/leptos-rs/leptos/pull/1976
Fix [] url in 12_transition.md by @gibbz00 in https://github.com/leptos-rs/leptos/pull/1980
book: point leptos_server docs.rs url to latest version. by @gibbz00 in https://github.com/leptos-rs/leptos/pull/1982
docs: clarify need to provide context in two places for server functions by @gbj in https://github.com/leptos-rs/leptos/pull/1983
fix: treat Suspense as containing a Set of resources, not a counter by @gbj in https://github.com/leptos-rs/leptos/pull/1985
examples: fix hackernews_js_fetch style.css path (closes #1992) by @gbj in https://github.com/leptos-rs/leptos/pull/1994
fix: run <ErrorBoundary/> in a child so siblings don't collide (closes #1987) by @gbj in https://github.com/leptos-rs/leptos/pull/1991
examples: remove incorrect CSR information for hackernews_js_fetch example by @gbj in https://github.com/leptos-rs/leptos/pull/1997
fix: correctly reset island/not-island state of SSRed Suspense streaming into island (closes #1996) by @gbj in https://github.com/leptos-rs/leptos/pull/2000
book: Fix  link in metadata.md by @gibbz00 in https://github.com/leptos-rs/leptos/pull/1999
docs: fix CodeSandbox for resources by @gbj in https://github.com/leptos-rs/leptos/pull/2002
docs: remove outdated APP_ENVIRONMENT variable by @gbj in https://github.com/leptos-rs/leptos/pull/2013
feat: Action::new and Action::server by @chrisp60 in https://github.com/leptos-rs/leptos/pull/1998
chore: remove duplicate benchmarks in leptos_reactive by @gbj in https://github.com/leptos-rs/leptos/pull/2014
docs: add note about context shadowing (closes #1986) by @gbj in https://github.com/leptos-rs/leptos/pull/2015
re-export slice! by @blorbb in https://github.com/leptos-rs/leptos/pull/2008
fix: allow nested functions in Attribute (closes #2023) by @gbj in https://github.com/leptos-rs/leptos/pull/2027
fix: use create_effect for <Portal/> to avoid hydration issues (closes #2010) by @gbj in https://github.com/leptos-rs/leptos/pull/2029
impl Default for TextProp by @blorbb in https://github.com/leptos-rs/leptos/pull/2016
Docs: ActionForm examples for complex arguments by @chrisp60 in https://github.com/leptos-rs/leptos/pull/2017
fix document book input name query by @datewu in https://github.com/leptos-rs/leptos/pull/2024
Minor: stop using std::fmt, instead used core::fmt. by @martinfrances107 in https://github.com/leptos-rs/leptos/pull/2033
Updates to Leptos Book by @diversable in https://github.com/leptos-rs/leptos/pull/2036
examples: add CSR with server functions example (closes #1975) by @gbj in https://github.com/leptos-rs/leptos/pull/2031
Have fetch example conform to docs guidance around using  and  in conjunction by @MoonKraken in https://github.com/leptos-rs/leptos/pull/2035
feat: <Provider/> component to fix context shadowing (closes #2038) by @gbj in https://github.com/leptos-rs/leptos/pull/2040
updated axum session to latest 0.9 in examples by @genusistimelord in https://github.com/leptos-rs/leptos/pull/2049
ci(examples): fix portal test by @gbj in https://github.com/leptos-rs/leptos/pull/2051
docs: add warning for nested Fn in attribute (see #2023) by @gbj in https://github.com/leptos-rs/leptos/pull/2045
fix: correctly mark Trigger as clean when it is re-tracked (closes #1948, #2048) by @gbj in https://github.com/leptos-rs/leptos/pull/2059
Add instruction to install trunk to examples/README.md by @hpepper in https://github.com/leptos-rs/leptos/pull/2064
fix: dispose previous route or outlet before rendering new one (closes #2070) by @gbj in https://github.com/leptos-rs/leptos/pull/2071
ci(leptos): run ci on change instead of check by @agilarity in https://github.com/leptos-rs/leptos/pull/2061
fix: make prop serialization opt-in for devtools (closes #1952) by @gbj in https://github.com/leptos-rs/leptos/pull/2081
fix: improved rust-analyzer support in #[component] macro? by @gbj in https://github.com/leptos-rs/leptos/pull/2075

New Contributors

@gibbz00 made their first contribution in https://github.com/leptos-rs/leptos/pull/1976
@datewu made their first contribution in https://github.com/leptos-rs/leptos/pull/2024
@diversable made their first contribution in https://github.com/leptos-rs/leptos/pull/2036
@MoonKraken made their first contribution in https://github.com/leptos-rs/leptos/pull/2035
@hpepper made their first contribution in https://github.com/leptos-rs/leptos/pull/2064

Full Changelog: https://github.com/leptos-rs/leptos/compare/v0.5.2...v0.5.3

timayz/pikav (pikav-client)
v0.20.5
Compare Source
Bug Fixes

deps: update all non-major (#74) (881866c)

v0.20.4
Compare Source
Bug Fixes

deps: update all non-major (#73) (6b68306)

tokio-rs/prost (prost)
v0.12.3
Compare Source
PROST! is a Protocol Buffers implementation for the Rust Language. prost generates simple, idiomatic Rust code from proto2 and proto3 files.
This patch updates brings a few new fixes:

Fix code generation for Name trait (https://github.com/tokio-rs/prost/pull/944)

v0.12.2
Compare Source
PROST! is a Protocol Buffers implementation for the Rust Language. prost generates simple, idiomatic Rust code from proto2 and proto3 files.
This patch updates brings a few new features and fixes:

feat: Generate implementation for Name trait (https://github.com/tokio-rs/prost/pull/931)
fix: generate Name::full_name properly (https://github.com/tokio-rs/prost/pull/923)

serde-rs/serde (serde)
v1.0.193
Compare Source

Fix field names used for the deserialization of RangeFrom and RangeTo (#2653, #2654, #2655, thanks @emilbonnek)

launchbadge/sqlx (sqlx)
v0.7.3
38 pull requests were merged this release cycle.
Added

[#2478]: feat(citext): support postgres citext [[@hgranthorner]]
[#2545]: Add fixtures_path in sqlx::test args [[@ripa1995]]
[#2665]: feat(mysql): support packet splitting [[@tk2217]]
[#2752]: Enhancement #2747 Provide fn PgConnectOptions::get_host(&self) [[@boris-lok]]
[#2769]: Customize the macro error message based on the metadata [[@Nemo157]]
[#2793]: derived Hash trait for PgInterval [[@yasamoka]]
[#2801]: derive FromRow: sqlx(default) for all fields [[@grgi]]
[#2827]: Add impl FromRow for the unit type [[@nanoqsh]]
[#2871]: Add MySqlConnectOptions::get_database()  [[@shiftrightonce]]
[#2873]: Sqlx Cli: Added force flag to drop database for postgres [[@Vrajs16]]
[#2894]: feat: Text adapter [[@abonander]]

Changed

[#2701]: Remove documentation on offline feature [[@Baptistemontan]]
[#2713]: Add additional info regarding using Transaction and PoolConnection as… [[@satwanjyu]]
[#2770]: Update README.md [[@snspinn]]
[#2797]: doc(mysql): document behavior regarding BOOLEAN and the query macros [[@abonander]]
[#2803]: Don't use separate temp dir for query jsons (2)  [[@mattfbacon]]
[#2819]: postgres begin cancel safe [[@conradludgate]]
[#2832]: Update extra_float_digits default to 2 instead of 3 [[@brianheineman]]
[#2865]: Update Faq - Bulk upsert with optional fields  [[@Vrajs16]]
[#2880]: feat: use specific message for slow query logs [[@abonander]]
[#2882]: Do not require db url for prepare [[@tamasfe]]
[#2890]: doc(sqlite): cover lack of NUMERIC support [[@abonander]]
[No PR]: Upgraded libsqlite3-sys to 0.27.0

Note: linkage to libsqlite3-sys is considered semver-exempt;
see the release notes for 0.7.0 below for details.

Fixed

[#2640]: fix: sqlx::macro db cleanup race condition by adding a margin to current timestamp [[@fhsgoncalves]]
[#2655]: [fix] Urlencode when passing filenames to sqlite3 [[@uttarayan21]]
[#2684]: Make PgListener recover from UnexpectedEof [[@hamiltop]]
[#2688]: fix: Make rust_decimal and bigdecimal decoding more lenient [[@cameronbraid]]
[#2754]: Is tests/x.py maintained? And I tried fix it. [[@qwerty2501]]
[#2784]: fix: decode postgres time without subsecond [[@granddaifuku]]
[#2806]: Depend on version of async-std with non-private spawn-blocking [[@A248]]
[#2820]: fix: correct decoding of rust_decimal::Decimal for high-precision values [[@abonander]]
[#2822]: issue #2821 Update error handling logic when opening a TCP connection [[@anupj]]
[#2826]: chore: bump some sqlx-core dependencies [[@djc]]
[#2838]: Fixes rust_decimal scale for Postgres [[@jkleinknox]]
[#2847]: Fix comment in sqlx migrate add help text [[@cryeprecision]]
[#2850]: fix(core): avoid unncessary wakeups in try_stream!() [[@abonander]]
[#2856]: Prevent warnings running cargo build [[@nyurik]]
[#2864]: fix(sqlite): use AtomicUsize for thread IDs [[@abonander]]
[#2892]: Fixed force dropping bug [[@Vrajs16]]

tokio-rs/tracing (tracing-subscriber)
v0.3.18: tracing-subscriber 0.3.18
Compare Source
This release of tracing-subscriber adds support for the [NO_COLOR][NO_COLOR] environment
variable (an informal standard to disable emitting ANSI color escape codes) in
fmt::Layer, reintroduces support for the [chrono][chrono] crate, and increases the
minimum supported Rust version (MSRV) to Rust 1.63.0.
It also introduces several minor API improvements.
Added

chrono: Add [chrono][chrono] implementations of FormatTime (#2690)
subscriber: Add support for the [NO_COLOR][NO_COLOR] environment variable in
fmt::Layer (#2647)
fmt: make format::Writer::new() public (#2680)
filter: Implement layer::Filter for Option<Filter> (#2407)

Changed

log: bump version of tracing-log to 0.2 (#2772)
Increased minimum supported Rust version (MSRV) to 1.63.0+.

Thanks to @shayne-fletcher, @dmlary, @kaifastromai, and @jsgf for contributing!

timayz/twa-jwks (twa-jwks)
v1.2.6
Compare Source
Bug Fixes

deps: update all non-major (#15) (f5e5a71)

v1.2.5
Compare Source
Bug Fixes

deps: update all non-major (#14) (ad09841)

uuid-rs/uuid (uuid)
v1.6.1
Compare Source
What's Changed

Fix uuid macro in consts by @KodrAus in https://github.com/uuid-rs/uuid/pull/721

Full Changelog: https://github.com/uuid-rs/uuid/compare/1.6.0...1.6.1
v1.6.0
Compare Source
What's Changed

doc: fix links in v6 module by @metalalive in https://github.com/uuid-rs/uuid/pull/714
Stabilize UUIDv6-v8 support by @KodrAus in https://github.com/uuid-rs/uuid/pull/718
Prepare for 1.6.0 release by @KodrAus in https://github.com/uuid-rs/uuid/pull/719

New Contributors

@metalalive made their first contribution in https://github.com/uuid-rs/uuid/pull/714

Full Changelog: https://github.com/uuid-rs/uuid/compare/1.5.0...1.6.0

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

:tada: This PR is included in version 0.7.0 :tada:
The release is available on:

GitHub release
v0.7.0

Your semantic-release bot :package::rocket:


Build fails in master due to coordinate repr changes

The astropy/regions tests on travis-ci in master are failing for the two builds using Astropy dev:
https://travis-ci.org/astropy/regions/jobs/175035799#L743
https://travis-ci.org/astropy/regions/jobs/175035801#L745
Those are doctest changed because apparently the repr changed for SkyCoord. Example:
_______________________________ test_circle_sky ________________________________
    def test_circle_sky():
        center = SkyCoord(3 * u.deg, 4 * u.deg)
        reg = CircleSkyRegion(center, 2 * u.arcsec)

>       assert str(reg) == 'CircleSkyRegion\ncenter: <SkyCoord (ICRS): (ra, dec) in deg\n    (3.0, 4.0)>\nradius: 2.0 arcsec'
E       assert 'CircleSkyReg...s: 2.0 arcsec' == 'CircleSkyRegi...s: 2.0 arcsec'
E         Skipping 54 identical leading characters in diff, use -v to show
E            deg
E         -     ( 3.,  4.)>
E         ?      -   -
E         +     (3.0, 4.0)>
E         ?        +    +
E           radius: 2.0 arcsec

This is annoying because it makes the tests fail for all open PRs.
@bsipocz @astrofrog or anyone: suggestion how to modify (or remove?) the tests to fix this?
(I might have time to fix this on the weekend or Monday if it's clear what to do, but not today.)

Fixed in #71

Great!
If #71 goes in the next few days, fine, no need to split it out.

Fixed in #71


provisioning/ignition/boot-process: document how to simulate first boot

Running Ignition on an already booted root filesystem has many traps.
One of them is that systemd service presets are not reevaluated,
resulting in all new supposed-to-be-enabled services being disabled by
default.
Document how to invalidate the machine-id file so that systemd
reevaluates the service presets.
How to use/Testing done
Booted a qemu image, then created the first_boot flag file and booted it again with an Ignition config set. The service in the Ignition config does not get enabled unless one also did invalidate the machine-id file.

What do you think about removing the /etc/machine-id file instead? The method you describe feels like an obscure implementation detail whereas removing feels more intuitive to outsiders.

Yes, removing is probably the better idea (https://manpages.debian.org/testing/systemd/machine-id.5.en.html#FIRST_BOOT_SEMANTICS)


FrontDoorTlsProtocolType missing after 2019-04-01

Bug Report

import path of package in question, e.g. .../services/frontdoor/mgmt/2019-11-01/frontdoor
38.1.0
output of go version
go version go1.13 darwin/amd64

Hi 👋
I'm trying to upgrade terraform to the newest version of the SDK, it seems that FrontDoorTlsProtocolType is missing after 2019-04-01.
But it still appears to be in the rest api spec?
Something wrong in the generation? https://github.com/Azure/azure-rest-api-specs/blob/master/specification/frontdoor/resource-manager/Microsoft.Network/stable/2019-05-01/frontdoor.json#L1395-L1405
(I can't see a frontdoor.json after 2019-05-01 so I assume that means the API spec hasn't changed since then, that's also the version that the constant disappeared in).
https://github.com/Azure/azure-sdk-for-go/blob/master/services/frontdoor/mgmt/2019-04-01/frontdoor/models.go#L775
https://github.com/Azure/azure-sdk-for-go/blob/master/services/frontdoor/mgmt/2019-11-01/frontdoor/models.go#L974

What happened?
Missing field FrontDoorTlsProtocolType

What did you expect or want to happen?
The field to be there

How can we reproduce it?
Look at above links

Anything we should know about your environment.

https://github.com/terraform-providers/terraform-provider-azurerm/pull/5385

I just tested latest autorest.go and this is what it generated:
// FrontDoorTLSProtocolType - Defines the TLS extension protocol that is used for secure delivery
type FrontDoorTLSProtocolType string

...
type CustomHTTPSConfiguration struct {
	// REQUIRED; Defines the source of the SSL certificate
	CertificateSource *FrontDoorCertificateSource `json:"certificateSource,omitempty"`

	// REQUIRED; The minimum TLS version required from the clients to establish an SSL handshake with Front Door.
	MinimumTLSVersion *MinimumTLSVersion `json:"minimumTlsVersion,omitempty"`

	// REQUIRED; Defines the TLS extension protocol that is used for secure delivery
	ProtocolType *FrontDoorTLSProtocolType `json:"protocolType,omitempty"`

	// Parameters required for enabling SSL with Front Door-managed certificates (if certificateSource=FrontDoor)
	FrontDoorCertificateSourceParameters *FrontDoorCertificateSourceParameters `json:"frontDoorCertificateSourceParameters,omitempty"`

	// KeyVault certificate source parameters (if certificateSource=AzureKeyVault)
	KeyVaultCertificateSourceParameters *KeyVaultCertificateSourceParameters `json:"keyVaultCertificateSourceParameters,omitempty"`
}

I am uncertain if that means this is fixed, or broken worse given your comment on constants @jhendrixMSFT

@timja, could you help to confirm whether this problem is fixed in the latest version of the SDK?
https://github.com/Azure/azure-sdk-for-go/tree/main/services/frontdoor/mgmt/2020-11-01/frontdoor

From @chamons comment it's not fixed.
Nothing appears to have changed:
https://github.com/Azure/azure-sdk-for-go/blob/da4167617ea762d2b4e17f8c0798073c679251a2/services/frontdoor/mgmt/2020-11-01/frontdoor/models.go#L277
According to @jhendrixMSFT this should just be a constant and not be settable.
(note I haven't tried to upgrade and I raised this nearly 2 years ago so just doing my best from checking the code)

Unfortunately, I misspoke earlier.  When the enum is marked as modelAsString: true, it means that this enum should be treated as extensible, i.e. more values might be added in the future.  In this case, it's not treated as a constant, so callers are expected to provide the value, even if there's only one to choose from.


Add Create movies feature like UE4.

proposal:
UE4's sequencer can create movies and render output as a video file.
Maybe godot can add this feature too.
sample
sample

I think there's a lot of stuff to develop in terms of Godot as a game engine yet.
Moving the engine into film (when we already have Blender) would only siphon development away from what most people are using it for, and the film direction isn't necessarily popular among Unity users either (with some, according to blog comments, feeling shafted as they use the engine to make games).

Yeah. I wouldn't say this something that could never be added, but I think the priority for the devs is going to be stuff that enhances Godot as a game engine specifically.

Have you ever considered the animation of the transition levels？
Then store it to disk.

The real-time CG animation like Final Fantasy or The Witcher 3.
How did you make the shot?
Make it in blender?
:p

real-time animation is generally done using tiered sets of AnimationPlayers and AnimationTreePlayers. For example, one AnimationPlayer that moves a limb on a character, another for animating sets of limbs (by animating calls to the previous AnimationPlayer's animations), and then a 3rd one for animating sets of characters for entire levels.
Furthermore, A "director" mode is a planned feature for the 3.1 relase (as stated on the roadmap) to simplify the creation of CG, real-time animated performances. Note that the roadmap's timeline is off.
I'm sure many people would like to have better animation systems, but what you specifically requested here is the ability to output animated content as a video file. Depending on how easy that is to implement with existing features, that may actually end up in 3.1, especially if someone motivated (like you?) implements the functionality on their own and merges it in.

In fact, it's quite simple already to create a video out of animated gameplay content (including cinematic animations in Godot) using something as simple as OBS that can track and record the video output of another program already.

There is a lot of gamedev features that godot is missing. I would very  much prefer if developer effort is focused on those. A sequencer could be added to the timeline some day, but its far from a point where it should be a priority. We still miss a number of key animation features that Unity and Unreal has had for a long time.

For those interested, I made a proof of concept of this: https://github.com/Calinou/godot-video-rendering-demo
There are many things that should be improved for it to be more usable (better usability, faster frame saving), but it's a start.

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.
The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.
If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!


required fields don't do anything in Java

They add @NonNull annotations, but otherwise, there's no consequence. If I have a model with a required field, I'd expect that MyModel.builder().build() would throw an exception, but as it is, it allows you to build a model with null required fields.

I think this seems related to the issue around adding validation methods https://github.com/pinterest/plank/issues/185

Haha I'm disagreeing with my past self.


Gem tries to install native extensions globally

I am using a rbenv managed ruby and trying to locally install a gem package with a native extension. No matter what I do, gem tries to install it globally.
The gem I am trying to install is red-arrow. I tried the following options:
$ gem install red-arrow
$ gem install --user-install red-arrow
$ GEM_HOME=<path-to-rbenv-gem-home> gem install red-arrow
$ GEM_HOME=<path-to-rbenv-gem-home> gem install --user-install red-arrow

They still try to install the extension globally.

Hi, sorry you're having trouble, but this is an issue tracker for rbenv, not for gem which comes from Ruby. Rbenv doesn't control where gem will install gems. For what it's worth, gem install --user-install red-arrow should be the correct invocation. Also see "USER INSTALLATION DIRECTORY" in the output of gem env. Good luck!


Oneshot jobs

I'm a bit hesitant to propose this but how about supporting oneshot jobs in helmfile?
An oneshot job can be either a K8S job or a pod created via helm upgrade --install to accomplish a job like db migration, enqueueing a large job to a kind of workflow system, etc.
As of today, we have to resort a variant of kubectl run --image $img to run an oneshot job, even in a situation that our regular app are managed by helm and shared the image, envvars with oneshot jobs.
AFAIK, there's no such tool to support this use-case. And supporting it in helmfile allows us to provide a more docker-compose-like U/X to helm users, but the docker-build feature.
Thoughts?
cc/ @roboll @sstarcher

I see this as a job for helm hooks as either a pre-upgrade or a post-upgrade hook.  The chart that needs the job to run should be the one running the job.

@sstarcher Interesting!
Hooks didn't work for me as, for example, I do run a DB migration separately from a deployment of regular app to avoid down time.
I'd use a hook if the job being run via it is composed of just small, short-running, safe tasks. Not for scheduling a large, long-running batch job paired with the regular server app.

ya, it won't work if your application does not understand both database versions to allow for live migrations, but the hook is certainly the preferable mechanism as long as development puts in the time to allow the application to be cleanly upgraded.

@sstarcher A change is almost always backward-compatible but it is just that my migration takes a table lock too long due to the size of table :)
I fully agree that hooks are good for dev purpose. Transparent automatic db migration would indeed be valuable for dev envs!
My use-case seems to be more about prod envs.

I don't know enough about your situation, but I'm still not sure why you would not wait until you wanted to do the db migration to upgrade the helm chart.  That way the migration got kicked off at the appropriate time.

@sstarcher Probably you're suggesting the same thing as I do?
I wasn't sure what would be a solution to my problem at the time of writing this issue
But maybe I'd be happy with something like helmfile sync --selector task=migrate-db if it runs helm upgrade --install to run a new db-migration pod. Then, what we'd actually need to implement to support my use-case will be only #28?

Or maybe helmfile run --selector task=migrate-db to upgrade the chart labeled with task=migrate-db AND keep tailing logs until the task finishes would be even nicer.

@mumoshu ya in that situation #28 should give the main portion.  As for tailing the logs that could be a nice feature, but it would likely best be supported under a separate issue and maybe with a flag of --follow or such, but that's a good bit more of a complicated situation.

@sstarcher Thanks. Opened #50

Hi @gtaylor,
Would this use-case looks like to fit within the scope of helmfile, given it will be supported out-of-box via #28?
Just wanted to sync up with you 😃I appreciate any feedback from you.

I'll be closing this once I add a small example about it to README.


It takes ~3mn to compile with angular

I have Angular 1.3.8 in my bower_components folder (bower install angular), and it bugs the 6to5-brunch compiler.
If I try the brunch debug option I can see that it halts at:
brunch:pipeline Compiling 'bower_components\angular\angular.js' with 'ES6to5Compiler' +1ms

There is no error, it just stops and the process takes ~30% of my processor until I kill it.
If I remove the 6to5-brunch module it works, if I remove the angular folder from bower_components it works fine as well.
edit: the compilation works, it just takes like 3mn to complete

My bower file:
{
  "name": "angular-brunch-seed-no-fuss",
  "version": "0.6.0",
  "dependencies": {
    "modernizr": "~2.8.3",
    "angular": "~1.3.8",
    "angular-resource": "~1.3.8",
    "angular-sanitize": "~1.3.8",
    "angular-mocks": "~1.3.8",
    "angular-ui-router": "0.2.13",
    "jquery": "~2.1.3",
    "lodash": "~2.4.1",
    "ocModal": "~0.1.9",
    "bootstrap-sass-official": "~3.3.1"
  },
  "overrides": {
    "angular-mocks": {
      "main": []
    },
    "modernizr": {
      "main": "modernizr.js"
    },
    "lodash": {
      "main": "dist/lodash.js"
    },
    "bootstrap-sass-official": {
      "main": [
		"assets/stylesheets/_bootstrap.scss",
		"assets/fonts/bootstrap/glyphicons-halflings-regular.eot",
		"assets/fonts/bootstrap/glyphicons-halflings-regular.svg",
		"assets/fonts/bootstrap/glyphicons-halflings-regular.ttf",
		"assets/fonts/bootstrap/glyphicons-halflings-regular.woff",
		"assets/javascripts/bootstrap.js"
		]
    }
  },
  "resolutions": {
    "angular": "~1.3.8"
  }
}

But If I just override angular it works (it takes 31s... but it works)
{
  "name": "angular-brunch-seed-no-fuss",
  "version": "0.6.0",
  "dependencies": {
    "modernizr": "~2.8.3",
    "angular": "~1.3.8",
    "angular-resource": "~1.3.8",
    "angular-sanitize": "~1.3.8",
    "angular-mocks": "~1.3.8",
    "angular-ui-router": "0.2.13",
    "jquery": "~2.1.3",
    "lodash": "~2.4.1",
    "ocModal": "~0.1.9",
    "bootstrap-sass-official": "~3.3.1"
  },
  "overrides": {
    "angular": {
      "main": []
    },
    "angular-mocks": {
      "main": []
    },
    "modernizr": {
      "main": "modernizr.js"
    },
    "lodash": {
      "main": "dist/lodash.js"
    },
    "bootstrap-sass-official": {
      "main": [
		"assets/stylesheets/_bootstrap.scss",
		"assets/fonts/bootstrap/glyphicons-halflings-regular.eot",
		"assets/fonts/bootstrap/glyphicons-halflings-regular.svg",
		"assets/fonts/bootstrap/glyphicons-halflings-regular.ttf",
		"assets/fonts/bootstrap/glyphicons-halflings-regular.woff",
		"assets/javascripts/bootstrap.js"
		]
    }
  },
  "resolutions": {
    "angular": "~1.3.8"
  }
}

If there was a way to ignore to bower_components (see https://github.com/6to5/6to5-brunch/issues/4) it would probably fix my problem, but it might be interesting to see why it takes so long to compile angular... Maybe it's just because the lib has a lot of code, but if that's the case then the 6to5 compiler is really inefficient!

I realized sometime later after creating this plugin that even though it is theoretically harmless, 6to5 is not designed for processing code that was already targeting ES5 standards.
#4 needs to be resolved to account for this (with a default value that excludes bower_components without requiring any user intervention).
If you think 6to5 ought to investigate why it is so slow to process angular.js (I don't), you could raise the topic in the core 6to5 issue tracker.

I switched to Traceur for the moment, I'll take another look at 6to5 when #4 gets resolved. Anyway I think that Traceur is probably better for Angular code since Angular 2 uses Traceur.

Anyway I think that Traceur is probably better for Angular code since Angular 2 uses Traceur.

I would assert that the primary motivation there is that they're both Google products. 6to5 has many advantages over Traceur for any ES6 code (including angular apps) when evaluated objectively.

Yes but 6to5 only includes validated specs and AtScript won't get validated for now. Traceur supports AtScript since they need it for Angular 2...

Yeah if you're intending to use AtScript it's an entirely different story.

Yes, I want my project to be Angular2-ready :)


Request for original dataset

I visited the web site of Alchemy but could not download the original dataset as described in this issue https://github.com/tencent-alchemy/Alchemy/issues/17.
Actually, I have emailed to Dr. Guangyong (one of the paper's authors) and received that
``the order in CSV file is randomly permuted and the data (each molecular property) is normalized for the contest.''
So I would like to use the original data like the format of the QM9 dataset,
that is, the xyz coordinates, property values, and their units (e.g., eV and eV/atom) that are not normalized.

Thanks for your interests in our work, you can download our original dataset in the format of the QM9 from our official link https://alchemy.tencent.com/data/alchemy-v20191129.zip
Best Regards
Guangyong

Thank you very much for providing the dataset and now I could download it.
I have a question about the energy value in the Alchemy dataset.
In the QM9 dataset, almost all of the studies transform the internal energy (original provided data ) to the atomization energy and learn the atomization energy and evaluate its prediction performance (chemical accuracy is 1.0 kcal/mol) in their papers. This transformation is done by using the atomref information in the QM9 repository.
https://github.com/masashitsubaki/QuantumDeepField_molecule#datasets
Could you provide the atomref information used in the Alchemy? Or did the Alchemy contest use the internal energy directly instead of the atomization energy?


Charts/issues/5197 - fixed host app crash by adding a check before ca…

Issue Link :link:
Link to issue: https://github.com/ChartsOrg/Charts/issues/5197
Goals :soccer:
Fix the crash of the host app from within the library code whenever you get in a situation where the CGFloat calculated in the renderers' isDrawingValuesAllowed function are equal to CGFloat.infinity or to CGFloat.nan, as type casting those causes a crash.
Implementation Details :construction:
Honestly it's pretty self explanatory and it's rather a dumb-value check, nothing crazy or complicated. The issue explains it all already.
Testing Details :mag:
I didn't add any tests, as there's no point in testing something that i added because if fails at the compiler level so i don't think any tests are required, but please let me know.

@Naveen-C-Ramachandrappa thanks for the approval. Do you know when we can expect the PR to be merged in? Thanks a lot 😄


Compatibility tests

Validating equality of JSON output of multiple functions relating to DissectReader:

NewReader
ReadPartial
Read

Each test follows the same basic procedure:

Define test data root directory
Iterate through replay files recursively
Read each replay file
Read the JSON file for each replay file containing the expected data
Compare unmarshalled expexted JSON data with state of DissectReader after reading the replay file
(each test has a different scope/behaviour here)

There currently is a folder for Y8S1 replays, for future (or past) seasons, we can just simply add another folder, as long as each replay comes with a expected JSON of the same name. The tests will automatically pick these files up.
To enable testing for a few aspects of the output, I had to change how the JSON is (un)marshalled for some types.
In most cases, this only included implementing the json.Unmarshaler interface.
For one type, MatchUpdateType though, I had to also change the json.Marshaler implementation since the previous one didn't allow deriving the original value from the marshalled JSON. (see feedback.go)
Closes #38.

With #41, whichever gets merged last, will probably have merge conflicts due to the renaming of DissectReader to Reader.
I'll happily fix them in this PR though if you want to merge #41 first.

Thanks for handling the conflicts! You can add the rec files now with the updated gitignore

You can add the rec files now with the updated gitignore

Oh wow, didnt even notice those weren't uploaded.
I tried uploading them, but they exceed the Git size limit of 100MB.
Do you think we should add something like [Git LFS}(https://git-lfs.com)?

Yeah we could just upload them with lfs

How do they exceed the size limit? Isn't one like usually 12mb?

I was not thinking LFS would be necessary

As far as I know, we should not need LFS? But, I would agree that is the way to go if needed

Ah no nevermind, I wasn't thinking straight, I had a test testing on the unzipped replay file which then was like 130MB.
I'll remove that test, should be fine to upload then.


readme: Updated contributors section

Thanks, merged :+1:

I'm just doing the hard work for you

xD


(WIP) Feature/postgres similarity functions

See
https://github.com/moj-analytical-services/splink/pull/2199
for original PR
https://github.com/duckdb/duckdb/blob/0be3e7b43680f0bfd851f8788581aaaf4bf8cd3f/src/core_functions/scalar/string/damerau_levenshtein.cpp#L4
https://github.com/duckdb/duckdb/blob/main/test/sql/function/string/test_damerau_levenshtein.test
Also
https://iamberke.com/post/2012/04/10/Damerau-Levenshtein-distance-in-SQL
Here's the exampe code I've been using:

example

import os
from uuid import uuid4

from sqlalchemy import create_engine, text

import splink.postgres.comparison_level_library as cll
import splink.postgres.comparison_library as cl
from splink.datasets import splink_datasets
from splink.postgres.blocking_rule_library import block_on
from splink.postgres.linker import PostgresLinker

def get_pg_credentials():
    return {
        "user": os.environ.get("SPLINKTEST_PG_USER", "splinkognito"),
        "password": os.environ.get("SPLINKTEST_PG_PASSWORD", "splink123!"),
        "host": os.environ.get("SPLINKTEST_PG_HOST", "localhost"),
        "port": os.environ.get("SPLINKTEST_PG_PORT", "5432"),
        "db": os.environ.get("SPLINKTEST_PG_DB", "splink_db"),
    }

# Create the engine
creds = get_pg_credentials()
engine = create_engine(
    f"postgresql+psycopg2://{creds['user']}:{creds['password']}"
    f"@{creds['host']}:{creds['port']}/{creds['db']}"
)

cl_settings = {
    "link_type": "dedupe_only",
    "comparisons": [
        {
            "output_column_name": "first_name",
            "comparison_levels": [
                cll.null_level("first_name"),
                cll.exact_match_level("first_name"),
                cll.jaro_winkler_level("first_name", 0.8),
                cll.else_level(),
            ],
            "comparison_description": "Exact match vs. anything else",
        },
        {
            "output_column_name": "surname",
            "comparison_levels": [
                cll.null_level("surname"),
                cll.exact_match_level("surname"),
                cll.damerau_levenshtein_level("surname", 2),
                cll.else_level(),
            ],
            "comparison_description": "Exact match vs. anything else",
        },
        cl.damerau_levenshtein_at_thresholds("dob", [2, 1]),
        cl.jaro_at_thresholds("email", [0.9]),
    ],
    "blocking_rules_to_generate_predictions": [
        block_on("first_name"),
    ],
    "retain_matching_columns": True,
    "retain_intermediate_calculation_columns": True,
}

df = splink_datasets.fake_1000
linker = PostgresLinker(
    df,
    cl_settings,
    engine=engine,
)
linker.estimate_u_using_random_sampling(1e4)

@vfrank66  - thanks so much for this.  It's all looking good except one thing.  I've added tests for the new functions.
The jaro and jaro winkler tests pass, but the damerau_levenshtein ones do not.
I have used the same tests from duckdb here
I'm no expert but i had a little look at the wiki description of the algo here.
Do you think it's possible that your implementation is the version without transpositions, whereas the duckdb one is the one with transpositions, and that's the source of the test failure?
Do you have any thoughts on how to proceed?
For what it's worth, i'm happy to merge the jaro/jaro winkler code as it is - so if you'd prefer to do that, and think about this later, let me know

@RobinL sorry for the late reply I need to start by saying I need some time to make some changes. In Postgres the functions I created in sql were abysmal in performance. It would be ideal to run off a .c compiled extension, which is available. I fully instead to switch out my logic with pg_similarity extension but I have not done. pg_similarity extension has levenshtein but not damerau_levenshtein.
I had terrible cost and performance on AWS RDS so I switched to duckdb with great performance.
I do have transpositions although they are handling differently. I think the main differenc is this algorithm:  https://github.com/duckdb/duckdb/blob/0be3e7b43680f0bfd851f8788581aaaf4bf8cd3f/src/core_functions/scalar/string/damerau_levenshtein.cpp#L7, but I have no idea how to implement this.
Since I do not have time to review and implement this change right this moment, I asked claude-sonnet 3.5, for better or worse, here is original https://gist.github.com/vfrank66/3f80eb2ee3a2fbaae3e790085ad57075 here is revised: https://gist.github.com/vfrank66/7dce95e64548fa9ce213652ab5fb30ae

Thanks @vfrank66  - happy just to leave this open for a bit in case you have time.
That's very useful info re: performance. I meant to say actually - I did some investigation recently into the postgres extension for DuckDB, which I think is a very promising way forward.  Copy and pasing a message from our internal Slack which may be of interest:

I’m giving the duckdb postgres extension a whirl for CPR work.  I was keen to understand what it actually does.
It seems pretty suitable for use in Splink as the best way of executing linkage agaisnt a postgres backend.
In a nutshell, when you run lengthy/complex duckdb SQL against a postgres table, it:

Pulls the minimum amount of data from postgres required to execute the query, correctly preserving typing.
1.b They’ve written optimised code to parallelise the read , to transfer data as efficiently as possible
Once data is received by duckdb (into memory),  it effectively becomes a duckdb tabe, and all further processing is done using DuckDB

We can see this at work e.g. with this code:
con.execute("INSTALL postgres")
con.execute("LOAD postgres")

con.execute(
    f"ATTACH '{postgres_connection_string_preprod}' AS postgres_db (TYPE POSTGRES)"
)
con.execute("SET pg_debug_show_queries=true")

sql = """
select jaro_winkler_similarity(l.first_name, r.first_name) as first_name_sim
from postgres_db.personrecordservice.person l
cross join postgres_db.personrecordservice.person r
limit 10
"""
con.execute(sql).df()```

where we see this is the only work being done by postgres:
```BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ

	COPY (SELECT "first_name" FROM "personrecordservice"."person" WHERE ctid BETWEEN '(0,0)'::tid AND '(4294967295,0)'::tid) TO STDOUT (FORMAT binary);

	COPY (SELECT "first_name" FROM "personrecordservice"."person" WHERE ctid BETWEEN '(0,0)'::tid AND '(4294967295,0)'::tid) TO STDOUT (FORMAT binary);

COMMIT```

Though it does potentially look like there’s duplication there in the double read.

I think you might be able to use with the DuckDB linker as is by doing a `create table df as (select * fom postgres` and then passing the string "df" to the DuckDB linker as the data argument, with the connection set to the same duckdb connection that's been set up to connectthrough to postgres

Oh yay that is great I will make time to look into this Postgres extension next week. that may be exactly what I need.
Due to Postgres function performance on millions of comparisons I wanted to store data is Postgres, calc in duckdb, and store back to Postgres. Due to ACID compliance across multiple predicting applications. I do understand DuckDb in-memory is ACID but would only apply for single process.

I should have a gist soon, another week, of my completed work, this is just a update.
This works great and if you are okay with using client side side processing,with duckdb but persisting to postgres this is much better than splink.postgres in terms of performance. I am no longer going to use splink.postgres implementation, because duckdb is so much faster.
Currently only problem I do have is that this does not work con.execute("SET pg_experimental_filter_pushdown=true") . Instead it is copying all the data. Which is fine for me because I can predicate pushdown with pyscopg beforehand. And one must set con.execute("SET pg_pages_per_task=250000;") otherwise the default batch size is 1_000.

Thanks for the update. Yeah I also experienced trouble/unexpected results with the duckdb postgres extension.  Specifically, doing a select * from table limit 1 was, to my suprise, fetching the whole table back to duckdb and then doing the limit.  Hopefully this will be improved going forwards.  The pages per task tip is a good one, I wasn't aware of that option

This worked on the predicate filter
con.execute("SET pg_use_ctid_scan=false")
con.execute("SET pg_experimental_filter_pushdown=true")

con.execute(
        """
SELECT sanitized_gender, tf_sanitized_gender
FROM db.public."__splink__df_tf_sanitized_gender"
WHERE sanitized_gender = 'MALE'
"""
    ).df()

Proceduse a correct predicate filter:

BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ

        COPY (SELECT "sanitized_gender", "tf_sanitized_gender" FROM "public"."__splink__df_tf_sanitized_gender" WHERE ctid BETWEEN '(0,0)'::tid AND '(4294967295,0)'::tid AND ("sanitized_gender" = 'MALE' AND "sanitized_gender" IS NOT NULL)) TO STDOUT (FORMAT binary);

@vfrank66 I'm just going through and cleaning up open PRs. What do you thinks best to do with this?  I think the best options are either to:
(1) Merge the jaro and jaro winkler UDFs
(2) Close this an recommend to users that they'd be better using duckdb with the postgres extension

I just saw this too:
https://www.theregister.com/2024/08/20/postgresql_duckdb_extension/
Which references the pg_duckdb extension here.
This allows duckdb workloads to be run within postgres.  Feels like between this and the postgres extension for duckdb the recommended approach should be to use one of these options rather than UDFs in postgres.  Do you agree?

Yes I agree. This should be dropped.
I would even recommend dropping Postgres support personally. Anyone that wishes to use it would not get all the similarity functions and if added the performance would be work for any developer running over 10 million total comparisons, based on my short experience.
Although I do understand some people have bigger database servers than they do application servers. So maybe it should be left alone.

Thanks - yeah, agree it's a bit of a niche use case


Add support for assemble block scoped flags, prefixes, and suffixes

The flags, prefix, and suffix comments are very handy but they should be block scoped. That would make reading of blocks. It would also make it much simpler to pass flags, prefixes, and suffixes from an include file parser (see #40).

Implementing this for flags is not possible, unfortunately. See #71 for details.


bug when LLM tries to nav to url without http(s)://

for first step when code calls navURL()
if url is https://www.youtube.com it works fine
but if url is www.youtube.com, user is brought to a url like: chrome-extension://gjakknclnkongbpncjjaemkbppmcelke/www.youtube.com which does not work

fixed in navURL()


linter for non-memory-comparable primary keys

I would like to propose a new linter, for which I am happy to provide a PR for. The linter warns when the PRIMARY KEY includes a column that is non-memory comparable. i.e.
The following types are acceptable:

INT/BIGINT/VARBINARY/BLOB/DECIMAL

The following are not:

VARCHAR/TEXT/FLOAT/JSON

The use-case is two fold:

You can't safely store a distinct set of key's in an in-memory map (i.e. 'A' != 'a' in the map, but in MySQL these could be treated equal).
Because of collations, you can't safely range on a key. So its not possible to know if key 'X' is above key 'Y'.

This might sound obscure, but I am looking to adopt skeema for this use-case :P We are developing a schema-change tool that has optimizations that depends on memory-comparable keys. When the key is non-memory-comparable, we currently detect it - but it means we need to fall back to a slower schema change method. So being able to lint it at the user level is a win for us.

Thank you for the feature request! I'd accept a PR for this if it can be made more generic -- I'd envision it as an option that allows you to configure which data types are permissible for use in primary keys. I believe that should still fulfil your use-case (assuming it's only checking column types and not any other aspect of the column?) but still permit companies with similar-but-slightly-different PK limitations to leverage it.
The linter package has some helpers for making these "allow lists" easy to code, see e.g. the similar data type checking use-case in allow-auto-inc / lint-auto-inc via check_auto_inc.go. This makes use of the helpers Rule.RelatedListOption and Options.IsAllowed.
In terms of option naming and functionality, I can see at least two possible approaches:
a) Enhance the existing lint-pk to make data type checking part of it. Add new related option allow-pk which allows you to supply a comma-separated list of acceptable PK data types. However, since lint-pk defaults to being enabled at warning level, the default for allow-pk would need to be very permissive... either explicitly listing every semi-reasonable PK data type, or treating an empty list as allowing anything, or implementing a special "all" value which is fully permissive.
or
b) Make this a separate new linter check, lint-pk-type, which defaults to disabled (ignore). New companion option allow-pk-type accepts a comma-separated list of acceptable PK data types. Since this is a new rule which defaults to being disabled, there's no need to worry about a default value for allow-pk-type / handling a special "all" value, so this implementation is slightly simpler.
That said, definitely open to discussing other approaches!
If submitting a PR, a few things to keep in mind:

tengo.Column.TypeInDB comes directly from information_schema.columns.column_type, which means it includes things like lengths / display widths / unsigned attribute / set or enum values / etc. This will inherently need a bit more handling than the similar logic in lint-auto-inc, since lint-auto-inc only has to deal with a limited set of column types by nature of AUTO_INCREMENT only being present on numeric types anyway.

We should maintain compatibility with MariaDB also, which potentially increases the number of weird column types. Off the top of my head, I believe all their additional column types (uuid, inet6, inet4) don't have sizes or other attributes to worry about in the previous bullet, but just something to think through.

One of the integration tests in the linter package, TestCheckSchema, automatically enables all linter checks and then runs them against a set of table definitions in linter/testdata/validcfg/*.sql. There's a .skeema file in that directory if you need to pre-configure the allow-list for PK types for testing purposes.

Thank you so much for the pointers! Okay, give me some time and I'll work on a PR.

Skeema v1.10 has been released and includes this feature (lint-pk-type and allow-pk-type). Thanks again for the pull request!


#561 replace travis with GitHub action

Hi everyone,
I'm not 100% sure if it fits like this. Actually I wanted to resolve #561 . Maybe you have some tips for me:

Unfortunately the build fails with npm run standard, but this happens in master too. Should I just ignore that?
I removed greenkeeper-lockfile from the action, because it says here https://github.com/greenkeeperio/greenkeeper-lockfile that this is now build-in.

Does it fit otherwise?
Best regards

I changed the version declaration to a string. Otherwise the actions always takes node version 10 ;-)
Sorry for that!

Hey @atodorov this should satisfy your change request so we can merge it, correct?

@Gontrum can you rebase on top of the latest master and resolve the conflicts please.

@Gontrum can you rebase on top of the latest master and resolve the conflicts please.

Sure :-)
Should be clean, now. Thank you guys for your help.

@lukasoppermann I don't see any obvious conflicts here but I can't "Rebase & merge". The only available options for me are "Merge pull request (with a merge commit)" or "Squash and merge".

@atodorov same here. I always "squash & merge" in any case, as it keeps the history a bit more clean & understandable. Does anything speak against squash & merge?

@atodorov same here. I always "squash & merge" in any case, as it keeps the history a bit more clean & understandable. Does anything speak against squash & merge?

FTR: I think the issue here was a merge commit in the PR itself.
I personally prefer "Rebase & merge" to keep the history clear and also keep the individual commits separate so we can trace back history more granularly. In this particular case I agree squash was the right thing to do since there were many commits fixing items from the code review process or adding changes missing from the original commit.

@atodorov thanks for the hint with the merge commit, I will keep that in mind.

@atodorov so if a PR has multiple commits that make sense by themselves I agree with the "Rebase & merge". Often though the PR history is not cleaned up. But we could ask for a clean history as well. 👍


Transparent icons gallery

Now with more transparency!
Closes https://github.com/flutter/flutter/issues/5376

cc @HansMuller

...but shouldn't we replace the defaults, wherever they live? Or are these just for the gallery?

Yeah, I'll replace the default in the next PR :)


HBASE-22294 Removed deprecated method from WALKeyImpl

Removed deprecated methods in ReplicationLoadSink.
Fixes: HBASE-22294

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
20
Docker mode activated.

_ Prechecks _

+1
hbaseanti
0
Patch does not have any anti-patterns.

+1
@author
0
The patch does not contain any @author tags.

-0
test4tests
0
The patch doesn't appear to include any new or modified tests.  Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ master Compile Tests _

+1
mvninstall
269
master passed

+1
compile
52
master passed

+1
checkstyle
76
master passed

+1
shadedjars
279
branch has no errors when building our shaded downstream artifacts.

+1
findbugs
193
master passed

+1
javadoc
34
master passed

_ Patch Compile Tests _

+1
mvninstall
251
the patch passed

+1
compile
54
the patch passed

+1
javac
54
the patch passed

+1
checkstyle
74
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedjars
278
patch has no errors when building our shaded downstream artifacts.

+1
hadoopcheck
538
Patch does not cause any errors with Hadoop 2.7.4 or 3.0.0.

+1
findbugs
193
the patch passed

+1
javadoc
32
the patch passed

_ Other Tests _

+1
unit
8604
hbase-server in the patch passed.

+1
asflicense
25
The patch does not generate ASF License warnings.

11044

Subsystem
Report/Notes

Docker
Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-186/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/186

Optional Tests
dupname  asflicense  javac  javadoc  unit  findbugs  shadedjars  hadoopcheck  hbaseanti  checkstyle  compile

uname
Linux 054187f2f0e7 4.4.0-143-generic #169~14.04.2-Ubuntu SMP Wed Feb 13 15:00:41 UTC 2019 x86_64 GNU/Linux

Build tool
maven

Personality
/testptch/patchprocess/precommit/personality/provided.sh

git revision
master / ab3d6cf811

maven
version: Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z)

Default Java
1.8.0_181

findbugs
v3.1.11

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-186/1/testReport/

Max. process+thread count
4849 (vs. ulimit of 10000)

modules
C: hbase-server U: hbase-server

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-186/1/console

Powered by
Apache Yetus 0.9.0 http://yetus.apache.org

This message was automatically generated.


Clean up duplicated SASS and CSS

This PR fixes duplicated selectors in SASS as well as CSS.
Closes #10643
Signed-off-by: Takuya Noguchi<EMAIL_ADDRESS>

/assign @bradtopol

/kind design cleanup

@tnir can you fix merge conflicts please?
/assign @lucperkins

@tnir Make sure to resolve the merge conflict in sass/_base.sass and then regenerate the CSS using make sass-build.

Closing because the conflicts have not been addressed for 23 days. If you get a chance to fix them, please reopen this PR.


WIP: Bugfix/lazy component loading states and fetching

Short description and why it's useful

added ability to reload component when fetch fails
added loading states for async sidebar components
added error handling for offline/online errors

TODO

add left sidebar support
add custom width support
refactor transitions
add x button

Screenshots of visual changes before/after (if there are any)
(Failed loading - is offline)

(Failed loading - is online)

Component is loading

The solution is still dirty and needs polishment. Just leaving the WIP PR to mostly show screenshots :)

This is pretty important fix and should be applied even when not polished. However - the Micorcart, Menu + Wishlist sidebars should be eagerly loaded for the offline mode - this is something i discussed with @patzick and there is a ticket for that. So I'd preffer to have them eagerly loaded this week and then think off what's left for this fancy loader You created here @filrak - we should have both!

It will be finished today. With this approach user will be able to refresh failed component just with one click (we can even try to do this automatically after connection is restored).
I'm not that a big fan of eager loading of this components. No matter if we have eager load or prefetch they still need to be downloaded anyway and in uncertain network conditions the bigger initial bundle is the worse for us.
What is the exact reason of eager load of this offscreen components?
@patzick ?

Go to product page, swithc internet off, add product to the cart -try checking the cart status :) Good luckl;  at least for now ;)
That's the reason for eagerly loading the key components - just cart, wishlist + navigation.

but this PR will solve this problem

Ok, then this PR is prty useless in core functionalities. More like an additional feature

We should have it + Microcart + navigation eagerly loaded. I really like this feature - let's merge it in

I added automatic reload of failed components when user cames back online

Ok; fine with me

Done. I will improve some parts during stability phase but for now it works perfectly fine and solves the problem gracefully ;).

CR does not link issues so i need a separate comment - related issues #2408, #2451


Considering env var ZSH_DISABLE_COMPFIX during initialization

This PR provides a fix for #938 by considering the environment variable ZSH_DISABLE_COMPFIX.
By default, on initialization compinit is called like before. That means compaudit is called and security checks are performed. This might block the shell, waiting for user input. Especially this is not desired in the presence of non-interactive shells. Another scenario, in which security checks might not be desired is a multi-user system. For security reasons, compinit requires completion directories to be owned by the same user who runs the command.
If we set ZSH_DISABLE_COMPFIX="true", then compinit -u -C is called. Effectively, -C will skip all security checks and -u will use all files found for completion (see compinit). This is considered best practice in oh-my-zsh.
Note: this might need to be mentioned in the sdkman.io docs

@marc0der thanks for the hints! I applied the changes and force-pushed the new version. Please let me know if there is sth else.

Thanks for contributing this!

This is now deployed in the beta channel. Please let me know if it behaves as expected and I'll be happy to release to stable.

@marc0der I can confirm that it works on the beta channel. Here are my tests:

✅  On the lates stable version, I received a compinit warning (this also happened in the presence of the env var ZSH_DISABLE_COMPFIX="true", I have no screenshot for that).

✅  On the beta channel, we observe the same behavior when the env var ZSH_DISABLE_COMPFIX is not set to "true". This is expected because we did not want to change the 'default' behavior.

✅  The beta version now skips the compinit security checks if we set the env var ZSH_DISABLE_COMPFIX="true". Especially this removes the initial input dialog when opening a new zsh shell, which blocked the terminal.

Great, thanks for confirming. I'll release this to stable shortly.

Thank you, your OS project really works like clockwork! 👍


[SPARK-7431] [ml] [Python] Made CrossValidatorModel call parent init in PySpark

Fixes bug with PySpark cvModel not having UID
Also made small PySpark fixes: Evaluator should inherit from Params.  MockModel should inherit from Model.
CC: @mengxr

Merged build triggered.

Merged build started.

Test build #32086 has started for   PR 5968 at commit aebf97e.

Test build #32086 has finished for   PR 5968 at commit aebf97e.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
class Evaluator(Params):

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/32086/
Test PASSed.

Testing again since master is changing rapidly

Test build #789 has started for   PR 5968 at commit aebf97e.

LGTM

Test build #789 has finished for   PR 5968 at commit aebf97e.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Unrelated failure.  retesting

Test build #791 has started for   PR 5968 at commit aebf97e.

Test build #791 has finished for   PR 5968 at commit aebf97e.

This patch fails to build.
This patch does not merge cleanly.
This patch adds no public classes.

Test build #794 has started for   PR 5968 at commit aebf97e.

Test build #794 has finished for   PR 5968 at commit aebf97e.

This patch passes all tests.
This patch does not merge cleanly.
This patch adds the following public classes (experimental):
class Evaluator(Params):

Just rebased...but that did not require resolving any conflicts, so I'm not sure why the last test report an unclean merge.

Merged build triggered.

Merged build started.

Test build #32317 has started for   PR 5968 at commit 57f13cd.

Test build #32317 has finished for   PR 5968 at commit 57f13cd.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
class Evaluator(Params):

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/32317/
Test PASSed.

Merging into master and branch-1.4


TLS Implementation?

Why is this feature valuable to you? Does it solve a problem you're having?
We recently received a letter stating that static access tokens will no longer be acceptable and that Dropbox is switching to TLS. Is this something that will be updated in the module or will we need to change how this process works on our end?  Or is it already available within this package?

These changes are already supported by this Dropbox JavaScript SDK:
TLS: Dropbox will begin requiring TLS 1.2, and no longer allow TLS 1.0 or TLS 1.2. The client will automatically use the latest available version so no action should be required as long as the system supports TLS 1.2.
Tokens: Dropbox is switching to issuing short-lived access tokens (and optional refresh tokens) instead of long-lived access tokens. You can find more information on this migration here. This SDK has already been updated to support this. You can find examples in the Example folders.
For reference, apps can still get long-term access by requesting "offline" access, when needed, in which case the app receives a "refresh token" that can be used to retrieve new short-lived access tokens as needed, without further manual user intervention.
Also, while the creation of new long-lived access tokens is now deprecated, we don't currently have a plan to disable existing long-lived access tokens, or to stop accepting them on API calls. (If that changes, we will of course announce that ahead of time.) That being the case, you can continue using existing long-lived access token(s) without interruption, if you have any.