[WIP] Animate row expansion

#728
There are currently 2 limitations:

Programmatic row collapse isn't animated yet
The bottom and top padding inside the expansion have to be removed for a smooth animation, we can
either keep it this way and the user can add his own padding, or we can add an extra div inside the
animation div with the padding

So far so good, I will check out this branch to see the transition, thanks. Please tag me when you complete this feature 👍

BTW, @YassienW https://github.com/react-bootstrap-table/react-bootstrap-table2/issues/735

@AllenFang It's done. Let me know if anything needs to be adjusted

@YassienW oh, sorry, I missed this PR, let me check and thank you for this contribution!!

@YassienW hello, I think this PR is amazing for me, however, I will make it configurable, so I change this PR's base to react-bootstrap-table:feature/row-expand-animate and I will work on it. :)

I would very much like to have the ability to switch of the animation. It is slow and the motion is not smooth. Let me know if I can help with this. I have no pr experience, but I am happy to have a go


How Do I Compile the data-plane-api into a Linux Static Library?

If you are reporting any crash or any potential security issue, do not
open an issue in this repo. Please report the issue via emailing
<EMAIL_ADDRESS>where the issue will be triaged appropriately.
Title: How Do I Compile the data-plane-api into a Linux Static Library?
Description:

Describe the issue.
How Do I Compile the data-plane-api into a Linux Static Library?

[optional Relevant Links:]

Any extra documentation required to understand the issue.

data plane api are protobufs. What language are you compiling them to? You need to generate the protobufs in that language and link them in.

C++ language

There are bazel targets in api/ directories, one for each language. There is no "all protos" in C++, but there is a descriptor set defined here https://github.com/envoyproxy/envoy/blob/main/api/BUILD#L358. You would need to do the same for *_cc_proto targets, and then force link them statically.

I am just getting started with Bazel. Could you please help me with a detailed explanation on how to proceed? My requirement is to use C++ language to obtain xds data from Istio and parse it into the model defined in the data-plane-api. I used the compilation command bazel build envoy/service/discovery/v3:pkg_cc_grpc  and compiled libpkg_cc_grpc.a and libpkg_cc_grpc.so. Can these two libraries meet my requirements?


Parse whole words only

Question/Bug
When using search_dates, it picks partial letters from neighboring words as well thus forming an invalid token and wrong datetime objects. For eg:
sample_string = 'Bubble -58.5 06 Mar 2009 in need of -43.4 30 Oct 1974 also contributed for -17.7 26 Dec 2018 '
en_dates = search_dates(sample_string, languages=['en'],settings={'STRICT_PARSING': True})

Output
[('5 06 Mar 2009 in', datetime.datetime(2009, 3, 5, 0, 0)),
 ('4 30 Oct 1974', datetime.datetime(1974, 10, 4, 0, 0)),
 ('7 26 Dec 2018', datetime.datetime(2018, 12, 7, 0, 0))]

It also picked

letter 5 from -58.5 to 06 Mar 2009 forming '5 06 Mar 2009 in'
letter 4 from -43.4 to 30 Oct 1974 forming '4 30 Oct 1974'
letter 7 from -17.7 to 26 Dec 2018 forming '7 26 Dec 2018'

Either include the whole word or exclude it. Just including partial numbers/letters from previous words makes it an invalid token and wrong DateTime objects.

Expected Output
[('06 Mar 2009 in', datetime.datetime(2009, 3, 5, 0, 0)),
 ('30 Oct 1974', datetime.datetime(1974, 10, 4, 0, 0)),
 ('26 Dec 2018', datetime.datetime(2018, 12, 7, 0, 0))]

The concept of “whole words” is problematic here, as in regular expressions the word boundary marker (\b) would consider 5 in -58.5 a separate word. We may need to write our own word boundary logic to fix this kind of issue.


Spark 2.4 RC support

Hi,
I am having trouble to make the build work using Spark 2.4 RC2/3 tag from the upstream. Does anyone has a working image of Spark 2.4 RC2/3 with Spark Operator?
Thanks!

I can help build an image based upon 2.4 rc3 and update here.

@ligao101 yes, I managed to run on RC2. What is the problem?

@ligao101 Are you running into issue with go generate? If so, the issue has been resolved, and please rebase to the latest master to give it another try.

BTW: I just built and pushed the following images:
gcr.io/spark-operator/spark-operator:v2.4.0-rc3-v1alpha1
gcr.io/spark-operator/spark-operator:v2.4.0-rc3-v1alpha1-py with PySpark support

thanks. It is working fine for me now. Thanks!


Initial setup with Next.js

The technologies that were used for this setup: Next.js, TypeScript, Tailwind CSS.

Initialized the project with create-next-app;
Added a license file for using the project;
Added basic configs and scripts for the project;
Added basic code style and formatting rules;
Added husky, lint-staged and starter commands for GitHub actions for main branch;
Added a home page for testing static generation and project build;

No longer needed.


Transforms with parameters

First off would like to say I'm loving ObjectMapper! Thanks for all the hard work.
I have a requirement to use DateTransform() with timestamps that include millsecond precision. I'd like to submit a PR so others can also take advantage of this behavior. Would you prefer a separate transform for this behavior or optional parameter (with default behavior of second precision) passed to DateTransform()?

Hi @esetnik, I'm glad you like the library :).
I think an optional parameter would be fine in this situation. Thanks!


Basic signup form done

It's not pretty, but it works.
Currently doesn't post anything, but can be hooked up whenever.
Best!
Carnun

P.S. Heading to bed now (it's 10:30pm GMT). Will get started on Routing in the morning. :)

Hmm... at this point I'm thinking it would be much, much easier to get things routed up once the components are actually fleshed out! Looking forward to chatting about it. :)
Best,
Carnun


Introducing DXB FAN

I agree to not ping anybody on Discord/Twitter/email about this pull request. Instead I will inquire by posting a new comment in the pull request if needed.

PRs are reviewed in bulk and and can take up to two weeks to be merged.
This repository is managed using an auto merge action. Please ensure your PR has no deleted lines, and it will be merged.
Please provide the following information for your token.
Please include change to the src/tokens/solana.tokenlist.json file in the PR.
DON'T modify any other token on the list.
At minimum each entry should have

Token Address: CFnPMwVnqExNXggjffQ5fnxY616FT8Ees6QHMVGerucc
Token Name: Dubai Fan Coin
Token Symbol: DXBFAN
Logo: (logo should be uploaded under assets/mainnet//*.<png/svg>) https://raw.githubusercontent.com/solana-labs/token-list/main/assets/mainnet/CFnPMwVnqExNXggjffQ5fnxY616FT8Ees6QHMVGerucc/logo.png
Link to the official homepage of token: https://www.dubai-fan.com
Coingecko ID if available (https://www.coingecko.com/api/documentations/v3#/coins/get_coins__id_):

HI,
I m trying to a my token to Token-list.
How can I upload the logo.png to https://raw.githubusercontent.com/solana-labs/token-list/main/assets/mainnet/ xxx/logo.png ?
The other question is regarding the deletion ?? I haven't delete anything, only adding line but it shows that lines were deleted.
Thanks for your time to help
Rgds
Eric


Add enum for Paladins API endpoint

There's several other enhancements that could be made to better support the Paladins API, but this is the most important and very simple.

Thanks for the PR. Someone actually mentioned to me recently about supporting Paladins API, so I've started work on a library that will be suitable for the APIs of both Smite and Paladins. When I release it, this project will be no longer maintained in place of it, as it will be far more superior and use objects instead.
As for now though, I'll go ahead and merge this.

Great to hear it @jaydenkieran !


How to mock this class!!!!!!!!!!!!!!!

From<EMAIL_ADDRESS>on May 17, 2010 19:13:57
I want to mock this class using powerMock,when i try to test it thrown
java.lang.ExceptionInInitializerError
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
why ??? How to mock it?
class:
public final class ContentFacade
{
private ContentFacade()
{
    contentService = (ContentService)

BaselineStartUp.getApplicationContext().getBean("contentService");
folderContentService = (FolderContentService)
BaselineStartUp.getApplicationContext().getBean("folderContentService");
providerService = (ProviderService)
BaselineStartUp.getApplicationContext().getBean("providerService");
basicService = (BasicService)BaselineStartUp.getApplicationContext
().getBean("basicService");
unknowTerm = (TerminalInfo)BaselineStartUp.getApplicationContext
().getBean("unknowTerm");
}
public static ContentFacade getInstance()
{
    return INSTANCE;
}

}
test:
ContentFacade cfde=PowerMock.createMock(ContentFacade.class); Please provide any additional information below.
Original issue: http://code.google.com/p/powermock/issues/detail?id=260

From<EMAIL_ADDRESS>on May 19, 2010 23:37:23
Please use our mailing-list to ask questions before posting here.
Status: WontFix


Add none-linear version of functions

So they can be used for 100% asynchronous system.

no need for new version


i18n(es): update layouts

What kind of changes does this PR include?

Updated content
Translated content

Description

Updates layouts.md #1232
What does this PR change? Give us a brief description.
Did you change something visual? A before/after screenshot can be helpful.

LGTM :)

Let's go team ES! 🥳. Thanks, @kevinzunigacuellar, @threkk! 🙌


Creating a Simple Chat App in React.js using the Chat Engine API

Formatting and structure checks

[x] Have you used the correct folder and file structure? - see Contribution Guidelines

[x] Is your article properly formatted in Markdown? - see Github Markdown guide

[x] Have you used our preferred heading structure? - H3 (###) and up

[x] Does your article follow any of the suggested structure formats? - see example formats

[x] Is your article over 750 words? - Tool: Wordcounter.net

[ ] Is the article you are submitting an in-depth and unique article? Does it go beyond what is in the official docs and what is covered in other blog sites. See these articles as examples.

[x] Does your article provide enough value and detail about your topic? - Articles should be clear, accurate, and fully explained.

[x] Can your article be understood by beginners? - Assume the audience is smart but has no prior exposure to the common terminology in your article.

[x] Have you included a hero image that is 600x400 pixels and have the copyright to use it? - Tools: Pixlr Image Editor for resizing and Unsplash for Creative Commons images

Grammar & plagiarism checks

[x] Have you spellchecked and grammar checked your article? - Tools: Write&Improve - ProWritingAid - Grammarly
[x] Please place your article through a 3rd party plagiarism checker. We suggest using Quetext, this tool is free and has a daily limit. We typically accept articles with 10% or less.
[x] Have you checked your article for readability? - Tool: Hemmingway
[x] Have you added sources for quotes and images that aren't yours?

Technical checks

[x] Are your code snippets properly formatted for syntax highlighting - see Syntax guide
[x] Have you checked your code runs correctly and you've highlighted all necessary dependencies for installation?
[x] Are the software programs and packages you're highlighting in your article up to date, using current versions and not deprecated?

Topic suggestion this closes

Remove the backticks and add the issue number below to link and close your Topic Suggestion (issue) when your article has been published (PR has been merged). See this video for more details.

This closes #3682

Finally, delete the article checklist notes in blockquotes and submit your PR. We look forward to reviewing your article.

Plagiarism check done ✅

Hey, @owinowendy I have made all the requested changes, kindly check. I however was not sure about the spacing correction I was to make on the title. Thank you.

Hey, @jumamiller I just made the changes requested, please check. My bad I failed to make every previously requested changes.

Great article @Neema-2016.
Thank you for the review @jumamiller.


feat: atchops_rsa_key_generate_base64

- What I did

Added a new atchops_rsa function: atchops_rsa_key_generate_base64
Refactored atchops_rsa_key_generate to utilize the new atchops_rsa_key_generate_base64 function
Added a test to ensure that atchops_rsa_key_generate_base64: 1. properly generated a key, 2. the keys could be used to populate our rsa key srtucts and 3. the keys could be used to encrypt/decrypt a basic plaintext
Refactored test_rsa_generate to test_rsa_key_generate

- How to verify it

New test passes
and previous tests pass

- Description for the changelog
feat: atchops_rsa_key_generate_base64

Can you explain a little more about history of aes generate vs history of rsa generate, we had an aes_generate_base64 and it was removed to keep the public interface simple, so why are we adding rsa_generate_base64

To put it simply, atchops is a wrapper around MbedTLS (we make it simple for us to call MbedTLS for our use case)
MbedTLS AES generation: outputs bytes
MbedTLS RSA generation: outputs base64
So therefore
Atchops AES generation: outputs bytes
Atchops RSA generation: outputs base64


Energy cubes and some generators bad influence at TPS

Hi, @aidancbrady!
On my server where is above 90 mods, the most laggy mod is Mekanism. I'm not trying to insult you, but your mod haven't optimization and this problem corrupts such an interesting and progressive mod. I think that without optimizing your mod just die out. Most of server administrators that I know says that they don't like mekanism because of lags.
When my server more than 30 players its start lagging and opis says me that the most luggy tiles is from mekanism, such as energy cubes, windmill, solar generators, etc. And because most of players cannot optimize their bases, server just slowly die. It's really terrible.
I really hope that you well think about this and make the right decision. Thanks!

Which version of Mekanism are you using? What are the mean and total times for the top Mekanism TEs?

Yeah - I can't do much about this without any data.  Most server owners I've spoken with have seen a great increase in performance with v8.

Exactly - we do actually work hard to try and optimise things. I spent many hours rewriting the recipe system, to hopefully improve performance, in the lead-up to v8, and in fact I am currently (and have been for the past week) rewriting the whole transmitter network system in the hope that it'll make us a lot less hard-going on chunk loads (a merge I'm not looking forward to). It's just that we've got such a large mod on our hands at this point that it makes it difficult to keep on top of every possible optimisation issue.


Some Source endpoints don't show up in Endpoint Aliases

I can't alias some source endpoints.
Some source endpoints don't show up in State/Connection Configuration because there's isn't anything to connect to.....that behavior seems fine. However I could see the user wanting to alias source channels if they intend to reuse the channel at a later point in time (i.e change it's endpoint configuration to Load and use it in connection)
Reproduction Steps

Autodetect SLSC 12251
Mark DUT_Ch1 and Load_Ch1 as source channels
In Routing and Faulting Custom Device, select Endpoint Aliases
Notice that Load_Ch1 is not shown in the Endpoints dropdown.

The SLSC Switch custom device currently does not publish endpoints that have no possible connections. This was a conscious decision on my behalf during development, since the endpoints cannot be meaningfully used, but it may not be the correct one.
@jashnani what use case do you see value in allowing aliases of endpoints which cannot be used to make connections?

I have a fix for this prototyped on the dev/show_unconnectable_source_endpoints branch, but it will likely need to be rebased and partially fixed up once other changes go in due to merge conflicts.

Closing as intended behavior. This a subjective design decision, but it seems that showing un-connectable endpoints in aliases is just adding another step for confusion. When you get to the connection endpoint assignment page, you would not see the aliased endpoint since it cannot be connected to any destinations.


Do not force to use yarn

Allow users to run the command rather than forcing 😃
I think people can type npm i or yarn after doing create-react-native-app myApp
My main concern is due to I want to use pnpm which is fast & saves a lotta disk space than both npm & yarn 😉
As a guy doing a lotta projects in react-native I don't think I need to waste space for more node_modules  😜

As a guy doing a lotta projects in react-native I don't think I need to waste space for more node_modules 😜

lol

I think people can type npm i or yarn after doing create-react-native-app myApp

99% of the time you will be doing this, and this is the behavior of create-react-app, so we aren't going to change this. if you want to add a flag to disable it, then that would be fine! a PR is welcome for that.

I forgot about this commit ;) https://github.com/react-community/create-react-native-app/commit/1609cef0b5e4429631516b3edbed43248e32aab4
you can specify --package-manager when running create-react-native-app if you want! will cut a release with this shortly

Thanks !!  I knew there must be some flag but couldn't figure it out 😂

pnpm also supported #412


small trip bug with questing

🐛 Bug Report
After my quest trip ended it gave me a prompt to send again with q, doing =q however sent two trips at the same time and gave twice the rewards after the trip ended.

bump


Ollama with  Codellama 7b not working

Before submitting your bug report

[ ] I believe this is a bug. I'll try to join the Continue Discord for questions
[ ] I'm not able to find an open issue that reports the same bug
[ ] I've seen the troubleshooting guide on the Continue Docs

Relevant environment info
- OS:
MacOs
- Continue:
- IDE:
VS Code

Description
I tried to configure Configure Ollama with Codellama 7b but i keep on getting http://localhost:11434/v1/api/chat url not found. I have confirmed my ollama server is running
To reproduce
No response
Log output
No response

I was getting 404 errors from using Ollama 0.1.10, I upgraded to Ollama 0.1.28 and the errors messages were improved, giving a better 400 error response description. I suggest checking your ollama version is up to date.

@ajasingh MattyRad is correct that this will be resolved by upgrading your version of Ollama. I'm going to close the issue, but feel free to re-open or message me in Discord if you continue to see problems


Simplify symbol version mangling

 Issue by brson
Thursday Oct 31, 2013 at 23:27 GMT
For earlier discussion, see https://github.com/rust-lang/rust/issues/10208
This issue was labelled with: A-linkage, B-RFC, P-low in the Rust repository

In the spirit of stripping down and simplifying our broken versioning scheme (#10188, #10207), this is a suggestion to remove a bunch of complexity from our name mangling.
The description of how we mangle symbols is mostly correct. The most important thing this mangling gets us is that it allows multiple, different crates to define the functions by throwing in some hashes, and that's worth preserving. The other versioning benefits are theoretical and don't work.
Where the current mangling includes a hash of the crate metadata and the type signature and also a version tag, instead we can just add a unique hash that either represents the crate metadata as currently defined or the strict version hash as suggested in #10207.
cc #2166

There is further reason to change the hashing scheme. In particular, using the entire crate in the name of every symbol is completely incompatible with incremental compilation. To make things work, I think you cannot use the data from other symbols at all (or at least only very, very carefully).
That means we can:

use the crate-name and version-number
use the signature of the symbol itself
if we want to get fancy, use the info from things that the symbol depends on, since if those change, the symbol must be rebuilt anyhow

@alexcrichton and I talked about this at one point but I sort of have forgotten our conclusion. We should settle on something and update the incr. comp. RFC to reflect the consensus.
cc @brson @michaelwoerister

If we just always built the hashes that we plan to use for incremental compilation (that is, hashes that also include the dependencies of a symbol) that would solve the problem without much additional cost in complexity. And it should shield against name clashes when using two versions of the same item.
Using the crate version number will also solve this problem though (if somewhat less reliably because it depends on really adhering to proper version numbering)

Just had a conversation with @alexcrichton on IRC. The synopsis:

We should hash the symbols with the combination of:

the package id supplied by cargo (or, if using command line, just the crate name);
the types of its local symbols (which are persistently hashable, since they are based on DefIds)

It's not worth hashing the types of all dependent symbols, because:

publishing two versions of same crate with different types will still cause conflicts locally
in a post-cargo world, it's not clear how realistic this scenario is anyway

It occurs to me that if we REALLY wanted the full crate hash, we could use a single dummy symbol.

Based on my read of the prior comments and things, this still seems to address the main use-cases for hashing. But there is a lot of prior commentary, so if something is being overlooked, please do bring it up.

publishing two versions of same crate with different types will still cause conflicts locally

Will it? Let's say we have the following function and struct in two versions of the same crate:
struct SomeStruct(SomeOtherStruct);

fn foo() -> SomeStruct {
    return bar();
}

The only difference in the two versions of the crate is the definition of SomeOtherStruct, e.g.:
// in version A
struct SomeOtherStruct(u64);

// in version B
struct SomeOtherStruct(u32);

This makes the two versions of foo() incompatible on the ABI level, but their hash would be the same because (solely) going through DefIds will hide the different binary layouts of SomeStruct, since the DefId of SomeOtherStruct is the same for both versions (unless a correct crate version number is part of the DefId, which we cannot rely on in general).

@michaelwoerister

Will it? Let's say we have the following function and struct in two versions of the same crate:

Yes, sorry. I should have written "will likely cause".

@alexcrichton points out that we could hash not only the path to the struct's name, but also its contents, which would address this issue. Essentially we create a hash for the struct definition, and when you reference that struct, you include that hash (or something like that).

Because it seems that @alexcrichton didn't know what I was talking about, I just wanted to elaborate on this "dummy symbol" idea I was tossing around. The idea would be to encode the hash of the crate's AST not on EVERY symbol, but just on ONE symbol we make at the end. So for each crate we'd make a symbol like:
fn crate$HASH() {
    dep1$HASH1();
    dep2$HASH2();
    dep3$HASH3();
}

where depN$HASHN are the dummy symbols from our dependencies.
The entire purpose of this would be to generate "defensive" link errors where a version is updated in place. You'd still need a hash on every symbol with crate+version-number to allow for multiple versions of a library to co-exist.

@alexcrichton points out that we could hash not only the path to the struct's name, but also its contents, which would address this issue. Essentially we create a hash for the struct definition, and when you reference that struct, you include that hash (or something like that).

I know, but at that point we would effectively also hash all the dependency of a type, right?

The idea would be to encode the hash of the crate's AST not on EVERY symbol, but just on ONE symbol we make at the end

That's quite a neat idea :)

Isn't an alternative to just generate a random number every time you generate code for a function, and store it in the output file's AST (and incremental compilation database)?

This has always been a complicated topic. The requirements and implementation have shifted a lot over the years, without I think anybody really understanding them, myself included.
TL;DR I don't think the way we are attempting to encode the entire dag/ast structure into symbols is buying us much and we can do a simpler scheme that is compatible w/ incremental compilation.
This is the current description of symbol hashing. From what I can tell the motivations under 'few issues to handle' are still accurate, except that I don't know what

the hash shown in the filename needs to be predictable and stable for build tooling integration. It also needs to be using a hash function which is easy to use from Python, make, etc.

means, and we're definitely violating it. The 'hash' in the filenames is now just an arbitarary string that the build tooling may optionally pass to rustc via the -C extra-filename flag.
I suspect the technical description under 'here is what we do' is very wrong.
Just some quick notes from reviewing what symbol hashing actually does:
The symbol hashing function is symbol_hash. It hashes a type, along with same crate-global data called LinkMeta, as well as the ambiguously-named crate_metadata, which is just an optional vec of strings passed on the command line via -C metadata.
LinkMeta contains the crate name and the Strict Version Hash.
The SVH is a hash of the crate contents. Note that it also hashes the command-line provided metadata. It also hashes the crate attributes.
The SVH is designed to allow the compile-time crate-loader to detect all upstream changes so it can generate errors and demand a recompile.  I believe the primary effect of the SVH today is that, in dependency chain A -> B -> C, if A is rebuilt with modifications, then B is not rebuilt, then C is rebuilt, the build of C will fail because the crate A that B references contains a different SVH than when B was originally built and thus B's deps don't resolve.
I'm surprised that I don't see anywhere where the SVH is transitively hashing the SVH of its dependencies. I would expect such transitive hashing to sort of 'lock' the crates together, ensure that two crates that have the same source but resolve two different versions of an upstream lib are different. As it is it looks like all the hashes within a crate only depend on crate-local information. This can't be right...
Cargo uses -C metadata to, well, do whatever it wants:

I'm not sure where Cargo's 'metadata' originates from - it's specified in the constructors of most kinds of targets.
@alexcrichton says it boils down to the crate name, version and the 'source' (to distinguish the exact same source built from e.g. git vs crates.io), and the extra data being mixed in is mostly about changing the filename of test-crates to avoid on-disk conflicts.
This seems really suspicious that we're relying on the build tool to some non-trivial work to prevent symbol collisions. It would seem more robust to the non-Cargo world for rustc to understand the possible configurations that produce conflicts and require Cargo to specify them semantically, not for Cargo to just throw a blob at rustc to fix the problem. It strikes me as making up for an insufficient definition of the SVH.

NB: mangle_exported_name is doing some weird hacks.
There are at least three paths in trans that define symbol names:

Names for non-generics are defined in base.rs using [mangle_eported_name].
Names for generics are defined in monomorphize.rs using exported_name. NB: monomorphization is doing it's own symbol hashing which is much different from that defined in link.rs
mangle_internal_name_* functions are used for a variety of shims.

It's quite an ad-hock clusterfuck.
From my understanding the current requirements here are actually pretty simple:

Avoid symbol name collisions globally. Ideally the information that goes into these hashes derives only from the structure of the crate DAG and its ASTS, but we see with the crate_metadata that some of the uniquifying information is provided from without.
Detect when dependencies of dependencies have changed and thus the metadata is no longer accurate. This is what the SVH does, and actually has little to do with symbol versioning, though the SVH is hashed into symbols.

The old system had a notion of symbol versioning as well, for binary upgrades, but we've never used it and no longer mangle a version into the symbol name. Such a system is moot as long as we're using something SVH-like to force non-binary-compatibility when crates change.
I'm very inclined to redesign the whole thing from scratch.
Some quick ideas:

Accept that having unique symbol names requires having unique crate names and versions. That is, two different (or the same) crates named "foo=1.0.0" may have symbol collisions. We don't need to worry about transitively hashing dependencies of things; we're not trying to hash the structure of the entire upstream dag. In a Cargo-based world, Cargo can ensure that crate-identifying information is unique enough.
Continue creating an SVH for a crate, but now as the final step of building a crate, encoding its complete structure. Downstream deps will continue put their upstream SVH's in their metadata, solely for the crate loader to detect inconsistencies. Though I didn't understand it fully, this sounds like what niko was proposing. The change here is that SVH's are no longer encoded into symbol hashes, but just passed around in the metadat for the crate loader.
The symbol hashes only encode the crate version (including whatever cargo-derived metadata is deemed necessary) and the monomorphized function type.

cc @graydon You probably remember better than I the original motivations. I do think we've basically given up on some of them.

One thing that today's Rust no longer does is guarantee anything about whether the crate loaded at runtime is the same as the crate seen at compiletime. We used to have stronger guarantees when the filename was derived from the crate version/contents. I don't recall exactly why we changed this behavior, but it was probably because having the filenames change constantly was annoying, or maybe because cargo couldn't predict them (this could have something to do with the cryptic 'tooling' comments in the old description of version hashing).

I don't recognize any of the code there; I think it's all been worked over many times since I worked on it. Plus it appears that cargo took over half the things rustc was trying to do in the meantime, and a significant number of design assumptions in linkage and versioning have changed. And I haven't a clue what "a post-cargo world" might refer to.
I encourage you to err on the side of hashing both types and (transitive) dependencies into symbols, and to try to ensure that multiple crates with the same self-chosen symbolic name can coexist in a single program. It might also be worth trying to recover the logic underlying separate hashes and version fields in names; I believe it had to do with the ability (indeed, requirement on linuxes) to have a major-number soname pointing to one of many different minor-version dylibs. Beyond that I'm not sure I'll be much help untangling the current technical concerns.
(I'm also on vacation presently, so...)

Hm. Re-reading and reconsidering. I don't get what the motive is for the proposed "Accept that having unique symbol names requires having unique crate names and versions". This seems like going back to a world of a global linkage namesapce, which we worked quite hard to avoid. Am I misunderstanding? If not, why?
I would point out that the SVH is the code that seems new to me. The other bits seem, on re-reading, somewhat similar to how things were when I last looked at this (years ago!) ... the "ad-hoc clusterfuck" part seems a bit exaggerated. It has a simple structure: it's a funnel into mangle, either directly or via a couple functions that work out the string-name and hash to provide:

When there's a path, use that as the string name, otherwise derive a name from a type and sequence (eg. for "glue" functions for types; though I doubt we have anything like that anymore and suspect those helpers could be removed)
When there's exported linkage, derive hash from global disambiguation material to avoid cross-linkage collisions, otherwise use crate-local type-context material to avoid collisions among internal instantiations of a polymorphic function

@comex

Is it a viable alternative to just append some random characters (rather than a hash) every time you generate code for a function, and store the name in the output file's AST (and incremental compilation database)?

It is, and I considered some sort of UUID-based approach, but I'd really prefer if incr. comp. and "from scratch compilation" produce the same, deterministic results. Having deterministic symbol names has other advantages too.

@michaelwoerister

I know, but at that point we would effectively also hash all the dependencies of a type, right?

Yes. But just for types, and it's not the "dependencies" of the type, it's the contents of the type. This is well-defined, whereas dependencies are an approximation that the compiler gathers up internally. This means that the hash would be portable amongst many implementations. It also means we could implement it today before we have a firm notion of dependencies.

PS, I think that I just recognized a new (potential) requirement I hadn't fully considered before. That is, portability amongst implementations. It seems ideal to me if compiling the same thing twice would give the same result, and even more so if it would give predictable, deterministic results (even if those results are not easily predictable).

@brson

One thing that today's Rust no longer does is guarantee anything about whether the crate loaded at runtime is the same as the crate seen at compiletime.

Isn't this somewhat ensured by the SVH? That is, if the name of every symbol reflects the entirety of the crate...?

@graydon

try to ensure that multiple crates with the same self-chosen symbolic name can coexist in a single program

This seems like a key point I'd like to dig into a bit more. First off, I think it gets at @brson's questions about a "post cargo" world -- I think the more accurate term is "post-crates.io". Given that we have a central repository of code, most crate names are fairly unique. But it seems clearly better if we can accommodate two crates with same name, but I want to try and understand how similar those crates can be. For example, even the SVH will fail if I copy-and-paste the same code and compile it twice under two distinct crate names, even if there is no logical problem there. It seems like at the extreme end, a random UUID is required.
OTOH, the proposal of hashing the signatures (and perhaps we even throw in the local AST contents, but not the contents of any referenced symbols) of every symbol seems pretty likely to succeed. Crates would have to have the same fn with the same impl and the same types in order to have a conflict. Now, this could certainly occur: like, there might be some common crate foo and both the conflicting crates might define the same helper:
extern crate foo; // same in both crates
fn frobify() -> foo::Data { // same in both crates
    foo::frobify()
}

But barring this, I think the two crates would not conflict (assuming no hash collisions, of course). Before I go further, let me check: Am I missing some other scenario?
In any case, it seems like we are sort of converging on one potential design here, where we hash the contents of each item along with some set of dependencies. I think it's important that this set of dependencies be pretty easy to specify and not be based on the compiler's internal dependency set. But it could be a bigger set than I specified above: for example, when hashing a function foo, we might also include the hash of any functions that it calls (figuring out something for cycles, of course).
 But maybe it's good enough in practice. It also depends I guess on how much importance we plan on shared dylibs and so forth. I'm rapidly coming to the conclusion that binary distributions don't carry their weight, for a variety of reasons. So if we entertain the notion that we are always building from source (perhaps "pre-compiled" source like optimized MIR), then it seems like we might get away with just having user-provided "salt". Cargo gets this from crates.io, but some linux distro might add their own salt when compiling rust packages based on whatever universal database they use. In other words, perhaps just exporting the problem IS the most reliable solution?

PS @graydon thanks for commenting even on your vacation ;) that was enlightening.

Just to clarify what I wrote here:

I'm rapidly coming to the conclusion that binary distributions don't carry their weight, for a variety of reasons. So if we entertain the notion that we are always building from source (perhaps "pre-compiled" source like optimized MIR), then it seems like we might get away with just having user-provided "salt"

What I mainly mean is that if I am authoring some Rust library, I would not distribute pre-compiled forms. I would post the source somewhere (perhaps in mangled form). This is of course the Python/Ruby model, but it's also the Java model (.class files), and it seems to be how most C packages work these days too. It gives us the advantage that we can re-compile the source for a variety of environments and optimization scenarios (think: cross-compilation, -O0 vs -O3, -g, landing pads, LTO, etc). Now a linux distro might still compile a binary version and distribute that, but they would already be introducing their salt or what have you to ensure a lack of overlap. I guess this basically corresponds to how many C packages let you define some prefix to use for disambiguating their symbols, except that it's invisible to the user.

Hm. Re-reading and reconsidering. I don't get what the motive is for the proposed "Accept that having unique symbol names requires having unique crate names and versions". This seems like going back to a world of a global linkage namesapce, which we worked quite hard to avoid. Am I misunderstanding? If not, why?

Yes, that's basically right, it is saying that Cargo package names are the global namespace. It's a simplifying assumption to avoid having do redesign exactly what dependencies get hashed into symbols. I do think it would be better to include dependencies, but also that (effectively) everything will work if we don't.

@brson
One thing that today's Rust no longer does is guarantee anything about whether the crate loaded at runtime is the same as the crate seen at compiletime.

Isn't this somewhat ensured by the SVH? That is, if the name of every symbol reflects the entirety of the crate...?

Yes, that's probably right.

Would one still be able to rename a cargo package locally, at the site of use? IOW build two packages that call themselves "foo" as different names in the crate using them, in order to link them together into a composite work? My concern is that we worked hard to ensure this capability -- no global cross-crate namespace -- and it seems valuable in terms of allowing people naming freedom without having to always consult a global registry.
(Especially if you're planning on supporting multiple such registries, private registries, or crates developed in house that might otherwise collide with cargo central names)

The different hashing for monomorphization probably points to additional requirements that I don't recall offhand. But, for example, when I was working on collapsing identical monomorphizations from different crates, I needed the symbol names to hash to the same value without the two crates having knowledge of each others' existance.

I agree wholeheartedly with @brson's summary and his action items at the end are exactly what I would propose as well. To add a bit, I think a crate having a "unique name and version" can be generalized to what @nikomatsakis was saying by saying a crate should have a "unique salt". Cargo will calculate this salt by hashing the (name, version, source), and other systems can create the salt differently. Either way it's not talking specifically about names or versions, just a hopefully-unique string going into compilation.
I also think that we may not want to dive too much into the area about future-proofing ourselves for strong ABI compatibility just yet. We're so far away from that place that I'd fear we don't even know what to plan for in terms of symbol naming. We can always change the names of the symbols at any time with the way we compile today, so I wouldn't be too worried. Especially if we create a simple system it'll be easier to change!

@graydon

Would one still be able to rename a cargo package locally, at the site of use?

Within the world of Cargo, yeah this should always be possible. Cargo's unit of deduplication is a triple of (name, version, source) where the source includes the URL of the kind of source in question, and this unit is hashed and passed down to the compiler to be mixed into all symbols (e.g. the metadata @brson was alluding to). Along those lines this use case should be covered already so long as the compiler guarantees that the command-line-given-metadata is mixed into the symbol hashes somehow.

The different hashing for monomorphization probably indicates additional requirements that I don't recall offhand.

My assumption would be that this hash is to disambiguate monomorphic instances of the same generic function. It's interesting though that this seems to sidestep the whole SVH business, making monomorphized symbols the only thing not dependent on it. Looks like an oversight more than a conscious decision.

Gotcha, yeah, the triples you're describing from cargo are serving the same role as pkgids were in the earlier design (and in earlier comments in the source -- some of which have I think been erroneously changed to refer to crate names alone, which is a bit too crude). So long as two symbolic crate names "foo" and "foo" can be segregated by different source strings input to the hash, you should be fine.

So I want to see this get implemented soon. I just re-read the thread and I think the following proposal seems to be what we all collectively agreed upon:

Compiler accepts some metadata on the command line
Each symbol name gains a hash that is computed from:

its DefIndex, which is a stable, persistent identifier derived from the module path

this is basically the identifier that the compiler itself uses to link things in incr. comp.

the crate name (just because)
compiler metadata from the command line

when using cargo, this would include the version number, source, and maybe some other stuff
if using some alternative build manager, it'll include that

The major thing which this scheme does not attempt to prevent is user error in terms of guaranteeing correct compilation of dependencies. In particular, if there is a crate A used by a crate B used by a crate C and crate A changes, it may be that one can recompile crate C without noticing that crate B has not been recompiled. Today this (in principle) fails because crate B's SVH would have to change (although as @brson noted this may not be true if the dependencies are not incorporated into the SVH).
We could in principle sort of prevent this case with a dummy symbol or something like that, however, we choose not to because:

Cargo makes this scenario far less likely in practice.
If we ever want to support binary compatibility, then we DON'T necessarily want to force B to be recompiled. In particular, we would want to be able to redeploy a version of A that has a bug fix without recompiling B (or even C).

One consideration not raised here is the "debugger experience". It'd be nice to get these hashes into the symbol name in an unintrusive-way. We also might want to have symbols include the crate name as a prefix, e.g., crate::foo::bar::zed::hash.
Does this seem like an accurate summary to everyone?

(Note that we can continue to keep the SVH in the metadata if want, so that compiles continue to fail in the same fashion that they do now. We just don't want it to be a part of all symbol names.)

(Note also that I changed from what I originally wrote, in that I substituted the DefPath in place of hashing types that appear in the signature or anything like that. I don't think that this hashing serves any particular purpose.)

@nikomatsakis sounds like an accurate summary to me!

In particular, if there is a crate A used by a crate B used by a crate C and crate A changes, it may be that one can recompile crate C without noticing that crate B has not been recompiled.

I'm happy to try this, but worried about going back to this state. I remember that adding the SVH was the thing that stopped us having bizarre linker errors all the time. You suggest that in a cargo world this doesn't matter, but the problem it solved for us was our own pain in tree.
In an incremental compilation world I might expect, instead of a crate-level SVH, that all items hash their upstream item dependencies (not crate dependencies), which can continue to be re-validated for consistency like the SVH.

@brson

I remember that adding the SVH was the thing that stopped us having bizarre linker errors all the time.

I guess you mean "made those errors fail faster"? That is, it seems like this only helps if our makefiles are buggy...or am I missing something?

In an incremental compilation world I might expect, instead of a crate-level SVH, that all items hash their upstream item dependencies (not crate dependencies), which can continue to be re-validated for consistency like the SVH.

Yes, @michaelwoerister suggested something like this earlier. Perhaps we should do this as an intermediate step. I didn't want to because I wanted an algorithm we could actually spec someday, but maybe it's not worth jumping all the way to that, and better to take incremental steps (no pun intended) that preserve some of the properties of the current system.

Oh, also: if we keep the SVH -- or something like it -- in crate metadata (which I think we can do), then it would presumably also help give clean errors when you forget to compile some intermediate step, just as it does today. But I'm assuming here that the compiler actually checks the SVH's recorded in the transitive crate graph for compatibility...

I actually wanted to work on this next and hopefully come up with a PR by the end of the week. I think Niko gave an accurate summary of the suggested solution and also Brian's concern about it is valid. Let's take a look at the requirements again:

We want two versions of the same crate be able to live next to each other without conflict.
We want symbol names to be stable across multiple incremental compilation runs.
We want the compiler to notice if something is wrong with the graph of crates being linked and give an understandable error message instead of some obscure linker failure.
We want, in principle, to support binary compatibility of crates, so one binary can be swapped out for another if that is semantically correct.
We want to prevent unnoticed linkage inconsistencies where the binary interface of a function changes without downstream crates noticing it.

The suggested solution makes it possible to have (1), (2) and (3), while (4) and (5) are more troublesome. Point (4) falls out of this approach naturally, but only if we pass on (5). That is, if we only use the commandline provided metadata to salt symbol names, it's easy to end up with two incompatible symbols with the same name and the runtime linker has no way of noticing.
The more sophisticated approach, with symbol hashes also incorporating dependencies, would mean that we have to very carefully define what gets incorporated. The hash would need to include anything that changes the binary interface of a function but it should not depend on the function body. Otherwise we lose (4) again. But it would lead to incompatible functions always having different symbol names, thus guaranteeing (5).
Note that by itself this would not prevent linker conflicts: Two similar versions of some crate A would have the same symbol names except for the differences (this could probably solved with something like COMDAT sections or "linkonce" linkage). All in all this approach would be more user-friendly; although some additional work would probably be needed to provide good error messages in case of inconsistencies.
Another thing to note is monomorphizations: The DefPath of a generic function alone is not sufficient to distinguish two instantiations of that function. We'll have to incorporate type arguments too. That's not hard, but it's something where the current algorithm actually is a bit strange and does things differently from 'normal' symbols AFAIR.
I think it would be a good idea to implement the simple version described by Niko now, as it will let us proceed with the incremental compilation work. Having good error messages in the compiler should be doable by storing SVHs in crate metadata and checking those when pulling in dependencies. And I'd suggest to punt on binary compatibility for the time being and add an SVH symbol that will make inconsistent linkage setups fail.
The second, more sophisticated approach can be done later and would then enable binary compatibility too. The salt could still be incorporated into symbol names then, it just would not be necessary anymore.

@nikomatsakis wrote:

I guess you mean "made those errors fail faster"? That is, it seems like this only helps if our makefiles are buggy...or am I missing something?

Niko and I talked about this some more.
A particular case where I believe we did indeed get errors to fail faster (which may or may not fall into the category that @brson  is referencing) was when our makefiles were not setting up the LD_LIBRARY_PATH correctly, and we would get semi-useful errors  during attempts to dynamically link build products from the wrong stage of the boot-strapped compiler. If the symbols didn't have distinct so-called "salt" for different source code origina,  those errors could be masked or yield much harder to diagnose issues
Niko and I agreed that this may be an important case to consider
However,  we should be able to retain this rough safe guard if we perhaps do something like include distinct salt in the distinct stages of the bootstrapped compilers

However, we should be able to retain this rough safe guard if we perhaps do something like include distinct salt in the distinct stages of the bootstrapped compilers

Yes I think that would be a good idea in any case.
Additionally, in the first implementation (PR https://github.com/rust-lang/rust/issues/31539) of the changes proposed here, I'd like to include the even stronger safe-guard mentioned above: Add an SVH_safeguard_<actual SVH> symbol to every crate and link to that in every dependent crate. That way the dynamic linker should fail when trying to link to any other version of a dependency (like now), but we'd still have stable symbols for incremental compilation. These safeguard links would just need to be in their own compilation unit, so they don't interfere with regular compilation unit invalidation.

I guess you mean "made those errors fail faster"? That is, it seems like this only helps if our makefiles are buggy...or am I missing something?

Yes, I supposed that's right. It may just not be a problem in our build system anymore.

Closing in favor of https://internals.rust-lang.org/t/pre-rfc-a-new-symbol-mangling-scheme/8501.

It's happened once or twice before, but in general I don't think we should be closing RFC issues in favor of internals threads -- one of the main ways in which RFC issues are different from internals threads (and thereby can justify their own existence) is that they are less ephemeral, and therefore more useful for tracking and cross-referencing purposes.

@glaebhoerl To me, the problem is that there's so much clutter here that it obscures what tracks actionable things that we may want to do in the future (instead of 100s of issues that will likely go nowhere); I expect the linked IRLO thread to eventually become a proper RFC.

Yeah, the "hazard" is just that if for whatever reason it doesn't, the issue wouldn't then get reopened. So in general it seems like a sounder rule to close-in-favor-of once the RFC or whatever has actually happened. (If we apply case-by-case reasoning, I do agree that it seems unlikely in this one.)
And yes, reducing clutter is a noble goal, thanks for working on it :)

@glaebhoerl Indeed it's not a slam dunk either way I think and it has the risks / drawbacks you mention; so I agree on the general idea. That said, it is my experience that this issue tracker is mainly used to file low-effort low-quality requests that are eventually abandoned, never closed, and never  revisited. IRLO seems like a better venue for discussing such topics since it is designed for ephemeral things (as you mentioned before).


Cmake - proposal / WIP

This is a shot across the bow to make this project easier to consume for everyone. With CMake, you can continue to use MSVC, build on Linux/Unix etc. And it will be much easier for consumers to actually use this software:
$ mkdir build
$ cd build
$ cmake ..
$ make
$ sudo make install

This makes packaging for all distributions trivial.
This is NOT finished. This is just an initial step showing how simple this can look if done right.

Linux works. The other OSs I'll need to convert the specific compilation flags still (I can't test or use windows)
daemon/client compile as well
make install also works
all the binaries compile/link OK
added proper version numbering (1.0.0)
create static internal library works

I've also reorganized the code to make sure there's no duplicate Cpp/H files around. Windows build may require a few more files to be moved to src and included in the build sequence, or otherwise fixed up.
There's a ton more here that can and needs to be done, but I'd like @opcm folks to sniff at this and get warmed up for doing this change, since it will make the project trivial to consume for all customers (not just clearlinux users).
Note: this was ~ 3 hours of work. Please don't let this go to waste.

@ahkok this is great! Thank you for making this proposal. cmake will really pay off if we can join two current Makefile (Linux/*BSD/OSX) and MSVC project files processes. BTW you can check your PR builds on OSX here: https://travis-ci.org/opcm/pcm/pull_requests
I am not sure why github dropped travis from pcm CI checks (need to look into it)

I welcome changes in this direction, please continue with this, it is very much appreciated!

Next I'll need to work on MSVC/Windows builds and Mac/BSD - Windows will be a little bit more complex.

Not much progress today. Twiddled on MacOS builds yet but I think we may need to replace the xcodebuild section - I'm looking to see if there's examples where people have done similar things, but nothing came up yet.
FWIW I think this will take a few weeks at least to iron out for MacOS and Windows. Given that I'm a Linux dev only I'll need to find some cross platform folks that can help with this.

thanks. Now we have moved to cmake in the master branch.


3364 user getting 403 errors when viewing their training providers on the courses as an accredited body page

Context
When an accredited body user tries to list courses for a provider that they are not directly associated with but that does deliver courses on behalf of the accredited body they are getting a 403 response in publish.
Publish currently calls the ProvidersController#show endpoint and includes the courses and the ProviderPolicy#show? policy does not allow this. Updating that policy will have undesirable side effects and will require complex coupling of with Course. So, we're going to switch Publish to use the CourseController#index endpoint to retrieve these courses. Unfortunately that also uses the ProviderPolicy#show? (via an alias) when the courses are scoped by provider. It also disregards any other filter params in that case.
Changes proposed in this pull request
Don't use ProviderPolicy in the CoursesController#index
Rely on the CoursePolicy::Scope to restrict access appropriately
Remove the can_list_courses? policy from `ProviderPolicy'
Guidance to review
Checklist

[x] Make sure all information from the Trello card is in here
[x] Attach to Trello card
[x] Rebased master
[x] Cleaned commit history
[x] Tested by running locally

 User getting 403 errors when viewing their training providers on the "courses as an accredited body" page


IndexOptimize with UpdateStatistics = 'ALL' causes 'the session is in the kill state'

Description of the issue
[IndexOptimize] with @UpdateStatistics = 'ALL' causes 'the session is in the kill state'
SQL Server version and edition
Microsoft SQL Server 2014 (SP3-CU4-GDR) (KB4583462) - 12.0.6433.1 (X64)
Oct 31 2020 02:54:45
Copyright (c) Microsoft Corporation
Developer Edition (64-bit) on Windows NT 6.3  (Build 9600: ) (Hypervisor)
Version of the script
2022-12-03 17:23:44
What command are you executing?
USE [master]
EXECUTE [dbo].[IndexOptimize]
@Databases = 'database1',
@FragmentationLow = NULL,
@FragmentationMedium = NULL,
@FragmentationHigh = NULL,
@Indexes = 'database1.dbo.TABLE1._NC_IX_TABLE1_DateTime',
@UpdateStatistics = 'ALL',
@OnlyModifiedStatistics = 'Y',
@LogToTable = 'Y'
What output are you getting?
Date and time: 2023-05-11 15:18:05
Server: TESTDB
Version: 12.0.6433.1
Edition: Developer Edition (64-bit)
Platform: Windows
Procedure: [master].[dbo].[IndexOptimize]
Parameters: @Databases = 'database1', @FragmentationLow = NULL, @FragmentationMedium = NULL, @FragmentationHigh = NULL, @FragmentationLevel1 = 5, @FragmentationLevel2 = 30, @MinNumberOfPages = 1000, @MaxNumberOfPages = NULL, @SortInTempdb = 'N', @MaxDOP = NULL, @FillFactor = NULL, @PadIndex = NULL, @LOBCompaction = 'Y', @UpdateStatistics = 'ALL', @OnlyModifiedStatistics = 'Y', @StatisticsModificationLevel = NULL, @StatisticsSample = NULL, @StatisticsResample = 'N', @PartitionLevel = 'Y', @MSShippedObjects = 'N', @Indexes = 'database1.dbo.TABLE1._NC_IX_TABLE1_DateTime', @TimeLimit = NULL, @Delay = NULL, @WaitAtLowPriorityMaxDuration = NULL, @WaitAtLowPriorityAbortAfterWait = NULL, @Resumable = 'N', @AvailabilityGroups = NULL, @LockTimeout = NULL, @LockMessageSeverity = 16, @StringDelimiter = ',', @DatabaseOrder = NULL, @DatabasesInParallel = 'N', @ExecuteAsUser = NULL, @LogToTable = 'Y', @Execute = 'Y'
Version: 2022-12-03 17:23:44
Source: https://ola.hallengren.com
Date and time: 2023-05-11 15:18:05
Database: [database1]
State: ONLINE
Standby: No
Updateability: READ_WRITE
User access: MULTI_USER
Recovery model: FULL
Is accessible: Yes
Msg 596, Level 21, State 1, Line 0
Cannot continue the execution because the session is in the kill state.
Msg 0, Level 20, State 0, Line 0
A severe error occurred on the current command.  The results, if any, should be discarded.

When I set @UpdateStatistics = 'ALL', the script finishes successfully.

When I set @UpdateStatistics = 'INDEX', the script finishes successfully.

The same error, when I set parameter @UpdateStatistics = 'COLUMNS'.


Black screen with logo

Describe the bug
Shows black screen with Mapbox logo.
To Reproduce
Running example app.
Expected behavior
Showing maps.
Screenshots
Versions (please complete the following information):

Platfrom: Android
Device: Device Opportunity
OS: [ColorOS
SDK Version 28
React Native Version 0.60

Additional context
Add any other context about the problem here.

Works with 7.0.10.
7.2.0 I have black screen.
Using Android with
"react": "16.9.0"
"react-native": "0.61.5"

Please try to build the example app and try to reproduce it there.
Come back with your findings.
Thanks

I spent hours on this, turns out it was missing an access token, even though I was setting it on launch.
In my case for example, I had misconfigured react-native-config for android only, so android wasn’t receiving the access token value, while iOS was.
An easy way to debug what’s going on is to run
adb logcat | grep Mbgl

You might notice something else in those logs. Hope this will help you, or someone else.

Well, this might be a bit late, but if you still having this issue, you simply having an issue with the Api key, so make sure you follow the documentation, it happened to me and it fixed it.


Update pyproject.toml

We don't plan to use dataclasses, so this line is unnecessary.

No, this caused problems with dependency resolving with poetry and that why it was added. That was because of rich and pycairo and could possibly break installation for everyone. We should have dataclasses or else everybody's installation would break.

That doesn't seem right. rich specifies the dataclasses requirement on its own, so we shouldn't have to do it again (https://github.com/willmcgugan/rich/blob/f092b1d04252e6f6812021c0f415dd1d7be6a16a/pyproject.toml#L27). That said, there does seem to be something fishy with how rich interacts with poetry.

Also, from next if changing any dependency please change the lock file also. Using
poetry lock

That doesn't seem right. rich specifies the dataclasses requirement on its own, so we shouldn't have to do it again

That caused a deps resolving issue in poetry latest, (possibly fixed in poetry's beta version), adding dataclassess fixes the install. If you commit the lock files all the tests would fail. ;-)

Is there an issue for this you can link to? This error still occurs when we attempt to add new dependencies. If we can't use poetry without having to work around its bugs it may be best to hold off on it.

Is there an issue for this you can link to?

I don't know. But on discussing with them on discord told me that this is fixed in latest pre-release. So we can possibly wait until it is released.

This error still occurs when we attempt to add new dependencies.

One thing which can possibly be done is remove support for python 3.6 and we have no problem on that. Or else have the current configuration and wait for new release from poetry. I don't think we need to add any new dependency for now.

Pretty much a thing which can be done is remove support for python 3.6 and remove the line. Or else keeping the current config does it.

Python 3.6 is no longer active or receiving bugfixes (only security updates), but it is not officially at "end of life" until Dec 2021.
https://www.python.org/dev/peps/pep-0494/

So its probably better to close this PR and wait until either python 3.6 is EOL or poetry has a new release.(Which fixes this issue)

Shouldn't we wait for a new poetry release and then merge this PR? @naveen521kk

Yes. Pretty much they will having one very soon. I can confirm from their pre-release that it is fixed there.

Uuuh so @naveen521kk just left the chat. So who is in charge of determining when this PR can be merged? @eulertour ?

I remember removing it in another PR. So this can be closed.


Add: faithfulness_metric for lime_image and lime_tabular

Hello,
here is a pull request to add faithfulness_metric used in  IBM/AIX360 package.
The metric straightforward and gives us an idea about the local fidelity of the classifier. You can find its description in the link below. Shortly, this metric evaluates the correlation between the importance assigned by the interpretability algorithm to attributes and the effect of each of the attributes on the performance of the predictive model.
I start  integrating this in lime_image and  lime_tabular explainers. I test the code in Tutorial  - Image Classfication Keras.ipynb and using Lime_for_regression.ipynb.

I am not convinced this is a particularly good faithfulness metric. Anyway, if we thought this was the goal, we should provide an explanation that maximizes this metric (not LIME explanations).
Sorry!


[Feat] Better loading state when buttons fetch data from server

Right now the text pops in awkwardly on the button components. Ideally they'd have a better default loading state and "fill in" elegantly

#150


Do I need to change the prompt in step 3?

Do I change the prompt in step 3 to the prompt generated in step 1? Thanks

Nope, I think it's an error, in the huggingface version this line is different so the prompt is the same(https://huggingface.co/spaces/MohamedRashad/PaintsUndo/blob/main/app.py):
def interrogator_process(x):
    image_description = wd14tagger.default_interrogator(x)
    return image_description, image_description

hi - please do not change codes.
that huggingface space is wrong and gives worse results.

hi - please do not change codes.
that huggingface space is wrong and gives worse results.

Yes, but I think that part is correct... why step 3 must have a different prompt thank step 1 prompt?

Because the beginning frames are not correspondent to the tags - if your tags are "1girl, dog, cat", the beginning frames without that dog and cat will suffer. Later frames are less influenced, though.

@yuesam That's my mistake, i though the stage 1 prompt will enhance stage 3 but i was clearly wrong.
I fixed it in the space, Happy building ^^


Unexpected indentation for LaTeX

Description
The results of beautification are not what I expect.
Input Before Beautification
This is what the code looked like before:
\documentclass{article}

\begin{document}

\begin{equation}
a = 1.
\end{equation}

\end{document}

Expected Output
I expected to see 2 spaces for indentation before a = 1. The beautified code should have looked like this:
\documentclass{article}

\begin{document}

\begin{equation}
  a = 1.
\end{equation}

\end{document}

Actual Output
I saw only 1 space for indentation before a = 1. The beautified code actually looked like this:
\documentclass{article}

\begin{document}

\begin{equation}
 a = 1.
\end{equation}

\end{document}

Comments
Directly running latexindent -w test.tex in the terminal does give 2 spaces for indentation, so I suspect this is not a bug with latexindent.pl.
Steps to Reproduce

Add code to Atom editor
Run command Atom Beautify: Beautify Editor
This beautified code does not look right!

Debug
Here is a link to the debug.md Gist: https://gist.github.com/edwinksl/e47e089d515f65ad77645318179cd54f
Checklist
I have:

[x] Tried uninstalling and reinstalling Atom Beautify to ensure it installed properly
[x] Reloaded (or restarted) Atom to ensure it is not a caching issue
[x] Searched through existing Atom Beautify Issues at https://github.com/Glavin001/atom-beautify/issues
so I know this is not a duplicate issue
[x] Filled out the Input, Expected, and Actual sections above or have edited/removed them in a way that fully describes the issue.
[x] Generated debugging information by executing Atom Beautify: Help Debug Editor command in Atom and added link for debug.md Gist to this issue

I think there is a bug at https://github.com/Glavin001/atom-beautify/blob/master/src/beautifiers/latex-beautify.coffee#L25
I see usage of indent_char but no indent_size! 😝
Pull Request welcome!


replace --instance with --region

Hrm, I hadn't noticed this issue. We don't have anything in this plugin that references --instance.


Kitchen Sink - create a detailed sample for how to use maps

The map sample in kitchen sink is either not working or just useless. I see that there are a couple of lats and longs from somewhere in New York but even those don't show up even when I zoom in on NY.
Besides it centers on where I am and unless I check the chrome dev I have no idea where the pins are.
https://studio.ensembleui.com/app/e24402cb-75e2-404c-866c-29e6c3dd7992/screen/36e52d1a-39c5-4a6b-b064-2be6cfe3cf7b
Please add the following -

Map zooms in on NY and shows the pin
TextInput for people to add address - this should be an auto-complete
As soon as the user picks an address from the list, map moves to that address
Button - Add Pin. Tapping on this button adds a Pin at the address that the user entered

Maps are going to be one of the most highly used feature of Ensemble and one of the most demo-able ones too but it is in a tragically bad shape right now.

cc @amin-nas Amin, please provide input.
@sharjeelyunus please do this next week when you are back from conference. This is very important.

Please document Google's StaticMap for simpler use cases where user just wants a map image. This should be in the kitchen sink for the Maps widget and also in the documentation.
cc @RuthLHanan

@RuthLHanan is this done?


refactor(sensor): no longer dumps "skew" of zero value in "CameraMatrix"

Pull Request Test Coverage Report for Build 878489388

10 of 10 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.02%) to 81.64%

Totals

Change from base Build 878063843:
0.02%

Covered Lines:
4300

Relevant Lines:
5267

💛  - Coveralls


MobileFacenet SE Train from scratch

I just want to know how do you train the se_mobile_facenet. May I know the parameter you use to train the mobile facenet model? (Optimizer, learning rate, batch size, loss function and its alpha, dataset, number of epoch for each scheduler or anything else). Thank you in advance

It's too far away, and most of those things seems wrong now...
As far as I can remeber and from my recorded data, it's configured as this:
import losses, train

basic_model = mobile_facenet.mobile_facenet(256, dropout=0, name="se_mobile_facenet_256", use_se=True)
data_path = '/datasets/faces_emore_112x112_folders'
eval_paths = ['/datasets/faces_emore/lfw.bin', '/datasets/faces_emore/cfp_fp.bin', '/datasets/faces_emore/agedb_30.bin']

tt = train.Train(data_path, save_path='keras_se_mobilefacenet_emore.h5', eval_paths=eval_paths,
    basic_model=basic_model, lr_base=0.001, batch_size=640, random_status=3)
sch = [
  {"loss": keras.losses.CategoricalCrossentropy(label_smoothing=0.1), "epoch": 15, "optimizer": "nadam"},
  {"loss": losses.ArcfaceLoss(scale=64), "epoch": 4, "bottleneckOnly": True},
  {"loss": losses.ArcfaceLoss(scale=64), "epoch": 30},
  {"loss": losses.BatchHardTripletLoss(0.35), "epoch": 10},
  {"loss": losses.BatchHardTripletLoss(0.3), "epoch": 10},
  {"loss": losses.BatchHardTripletLoss(0.25), "epoch": 10},
  {"loss": losses.BatchHardTripletLoss(0.2), "epoch": 20},
]
tt.train(sch, 0)

Loss
Epochs
First epoch (label_smoothing=0.1)

Softmax
15
13256s 2s/step - loss: 5.9982 - accuracy: 0.3615

Bottleneck Arcface
4
4111s 452ms/step - loss: 21.7145 - accuracy: 0.8624

Arcface 64
30
13043s 1s/step - loss: 16.7003 - accuracy: 0.9491

Triplet (BS 1440)
50
6688s 2s/step - loss: 0.2319

When looking back at this

It's better to use an optimizer with weight_decay, like SGDW / AdamW.
bottleneckOnly is NOT essential here, as I will reload the weights data from softmax to arcface.
Maybe train Arcface from scratch without softmax is better.
Inferencing se_mobile_facenet is too slow, though it's smaller.

Recently I'm mainly using SGDW, I would recommend this simple one but NOT tested:import tensorflow_addons as tfa
import train, losses

basic_model = mobile_facenet.mobile_facenet(256, dropout=0, name="se_mobile_facenet_256", use_se=True)
data_path = '/datasets/faces_emore_112x112_folders'
eval_paths = ['/datasets/faces_emore/lfw.bin', '/datasets/faces_emore/cfp_fp.bin', '/datasets/faces_emore/agedb_30.bin']
tt = train.Train(data_path, save_path='keras_se_mobilefacenet_emore.h5',
    eval_paths=eval_paths, basic_model=basic_model, model=None, lr_base=0.1, lr_decay=0.1, lr_decay_steps=[20, 30],
    batch_size=512, random_status=0, output_wd_multiply=10)

optimizer = tfa.optimizers.SGDW(learning_rate=0.1, weight_decay=5e-4, momentum=0.9)
sch = [
    {"loss": losses.ArcfaceLossT4(scale=64), "epoch": 40},
]
tt.train(sch, 0)

And the dataset, Insightface have uploaded a new dataset glint360k, which seems can reach a better result, but it's too large...

Thanks for the answer, I'll try it as soon as possible. But I found an issue that a model trained with Triplet loss has smaller cosine distance (when I do inference for the same person) and larger cosine distance (for different person) compared to model that trained with ArcFace loss. Is there any intuition why this is happening?

Ya, I found that too. There actually are some evidences in the paper ArcFace: Additive Angular Margin Loss for Deep Face Recognition section 3.2. Ablation Study on Losses.

I tried to combine triplet with arcface, and lower triplet alpha every 10 epochs, it seems better.
sch = [
    {"loss": losses.ArcfaceLoss(scale=64), "epoch": 10, "triplet": 32, "alpha": 0.35},
    {"loss": losses.ArcfaceLoss(scale=64), "epoch": 10, "triplet": 32, "alpha": 0.3},
    {"loss": losses.ArcfaceLoss(scale=64), "epoch": 10, "triplet": 32, "alpha": 0.25},
    {"loss": losses.ArcfaceLoss(scale=64), "epoch": 10, "triplet": 32, "alpha": 0.2},
]

I see, so it's better to train the model by combining the arcface with triplet loss to get the smaller cosine distance. Or I can train the model with arcface first, then continue the training by using BatchHardTripletLoss. And if the model won't convergence, I can reduce the margin, right?

Yes. The author of the ArcFace paper also tried that combination, but found no good, so I think it's better to try arcface only first.

I'll try it, thank you


Feature Tables, DB Port, new Scripts

Features:

new tables: feature/featureloc/featureprop/feature_relationship
CV term lookup by name with cache
export genbank, gff3, fasta from chado
stupid/simple scripts to list organisms, open a dbshell (I was fond of python manage.py dbshell in django)
optional progress bar dependency for long export steps (tqdm, was quite easy to use. https://pypi.python.org/pypi/tqdm)

Additionally:

dbport was added to the ChadoAuth, and defaults to 5432.
**vars(args) is used instead of manually specifying all the parameters, this means that the entire argparse parameter set is passed to the auth call
On the auth call side, **kwargs is used and completely ignored, while we take all the named parameters.

API Changes

Password is now -w and port is -p, more similar to the psql flags.

Added a progress bar while waiting for some ~500 phages to export as gff3.

should be quite nice :)

Ooooh sweet!
Thank you!


Fresh install with pnpm isn't working

Version
5.0.4
Reproduction link
cli.vuejs.org
Environment info
  System:
    OS: Linux 5.10 Ubuntu 20.04.4 LTS (Focal Fossa)
    CPU: (32) x64 AMD Ryzen 9 5950X 16-Core Processor
  Binaries:
    Node: 16.14.2 - /usr/bin/node
    Yarn: 1.22.15 - /usr/bin/yarn
    npm: 8.6.0 - /usr/bin/npm
  Browsers:
    Chrome: Not Found
    Firefox: Not Found
  npmGlobalPackages:
    @vue/cli: 5.0.4

PNPM version is 7.0.0-rc.3 (I also tested rc.2)

Steps to reproduce
Regular vue create project-name. Manual or default 3.x install doesn't matter.
In the end, choose PNPM as your package manager (or launch with --packageManager=pnpm)
What is expected?
A cleanly installed project
What is actually happening?
No install except the basic generation of the required package.json and other related files (no node_modules)
Error: command failed: pnpm install --reporter silent --shamefully-hoist
    at ChildProcess.<anonymous> (/usr/lib/node_modules/@vue/cli/lib/util/executeCommand.js:138:16)
    at ChildProcess.emit (node:events:526:28)
    at maybeClose (node:internal/child_process:1092:16)
    at Process.ChildProcess._handle.onexit (node:internal/child_process:302:5)```

---
I added a link to the Vue CLI docs as I didn't know where to start up this code. StackBlitz and Codepen both basically generate the project for you, but that step before is actually what's going wrong.

<!-- generated by vue-issues. DO NOT REMOVE -->

i got the same issue did you find a solution ?

I did not. I chose to abandon Nuxt3 and write what I need myself. It's still in beta and as such there are many strange bugs and workarounds.

Any update on this?
I get the same error when adding a vue plugin to my existing project
$ vue add tauri

📦  Installing vue-cli-plugin-tauri...

 ERROR  Error: command failed: pnpm install --reporter silent --shamefully-hoist vue-cli-plugin-tauri -D
Error: command failed: pnpm install --reporter silent --shamefully-hoist vue-cli-plugin-tauri -D
    at ChildProcess.<anonymous> (/usr/lib/node_modules/@vue/cli/lib/util/executeCommand.js:138:16)
    at ChildProcess.emit (node:events:527:28)
    at maybeClose (node:internal/child_process:1092:16)
    at Process.ChildProcess._handle.onexit (node:internal/child_process:302:5)

Figured my issue. It might be yours.
Found out that pnpm install --reporter silent --shamefully-hoist vue-cli-plugin-tauri -D actually returned an error code 1. So I ran the command without --reporter silent and got this error:
 ERR_PNPM_PUBLIC_HOIST_PATTERN_DIFF   This module was created using a different public-hoist-pattern value. run "pnpm install" to recreate the modules directory.

Somehow, something had created a node_modules folder in the project. I removed it and ran pnpm install as instructed.
Now I'm getting a different error . But that might belong on a different issue

I have met this issue today. I have found the packageManager field value is 'pnpm' in .vuerc file. Then change to 'npm' and it can fix this issue temporarily.

@bartlian That's useful for me. Thank u so much! Maybe it's PNPM7.1  of  i use

I have met this issue today. I have found the packageManager field value is 'pnpm' in .vuerc file. Then change to 'npm' and it can fix this issue temporarily.
thanks

Thanks to @Hergeirs', I found this solution :

Delete your node_modules folder
Run vue add tauri

And it worked for me, node_modules is recreated in the process

I am having this problem too, I can't create a new Vue.js App with the pnpm package manager. Strangely, the logs stack trace has a reference to yarn, idk if it's related:
 ERROR  Error: command failed: pnpm install --reporter silent --shamefully-hoist
Error: command failed: pnpm install --reporter silent --shamefully-hoist
    at ChildProcess.<anonymous> (/home/saiansh/.config/yarn/global/node_modules/@vue/cli/lib/util/executeCommand.js:138:16)
    at ChildProcess.emit (node:events:390:28)
    at maybeClose (node:internal/child_process:1064:16)
    at Process.ChildProcess._handle.onexit (node:internal/child_process:301:5)

I am also facing this Issue.

cd your_project_path
rm -rf .npmrc && rm -rf node_modules
pnpm install

An alternative quick-fix (workaround) not yet mentioned is to use the vue cli command OPTION "-m, --packageManager   Use specified npm client when installing dependencies"
-- for example: vue create my-app -m npm or vue create my-app --packageManager yarn
-- helpful source link: https://v3.cli.vuejs.org/guide/creating-a-project.html#vue-create

Tried your approach. Still not able to create vue 2 scaffolded project with pnpm. Issue still persists.

Tried your approach. Still not able to create vue 2 scaffolded project with pnpm. Issue still persists. @ReSpawN @ayu14214

Hmmm.. Let me try it in Vue 2. I will hopefully get back to you soon.

I am also facing this Issue.

+1 faced on both node v14 and 16. Setting npm as dependency manage save the issue.

How to solve this problem?

How to solve this problem?

Post more messages and wait for next release 😁

Using pnpm v6 solved the issue for me

pnpm v7 makes breaking change to set strict-peer-dependencies=true by default. To solve this problem, you can add strict-peer-dependencies=false in .npmrc file.

This issue was fixed in #7265 and should be closed.


Fix deprecated ykind projector in scala 3.5

kind-project and other has lifted from experiment to stabilized in:
https://github.com/scala/scala3/pull/20199
We need this for scala 3.5.0: https://github.com/typelevel/sbt-tpolecat/issues/223

Hello.
Any chance to see this merged?
Thanks for the hard work 👍

Hello. Is it possible to release a version? Scala 3.5.0 is out.

hey, I just got in the maintainer team of this project. I'm trying to make release soon!


Data doesn’t agree with that shown on purple air.com map

First of all, thanks for this app. It's very cool.
In my rural area there is only one sensor within a twenty mile radius, and it consistently reads around twenty points less on your app than the reading shown on the purple air site. Do you know of an explanation?
Screenshots attached.

This is due to that the Air Quality app is providing an AQI reading using the US EPA's conversion formula to more align Purple Air sensor readings with that of how the EPA determines its AQI level.
You can see where the conversion is being applied in the code here:
https://github.com/finiteloop/air-quality/blob/d7be4c7c5afe85223564191e1c947b93e08b5fd9/server/update_data/purpleair.py#L149

I also updated the app to show a toggle so you can switch between the two readings: https://github.com/finiteloop/air-quality/commit/7df9b5f2b23b3ac97571da167db1d29279df4ded
As @bhaggs said, the measurement that is the default is still what the EPA deems the most actionable / correct based on this research paper: https://cfpub.epa.gov/si/si_public_record_report.cfm?Lab=CEMM&dirEntryId=348236
But I have gotten this question enough, I thought I should provide a toggle.
App Store review is in flight and should be released this weekend.

Thanks 🙏
On Sat, Aug 28, 2021 at 19:58 Bret Taylor @.***> wrote:

Closed #10 https://github.com/finiteloop/air-quality/issues/10.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/finiteloop/air-quality/issues/10#event-5222255790,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAHOLV7X5LZGN22NYGHAABDT7GH6HANCNFSM5CRPSUFQ
.


shotman: init at 0.2.0

Description of changes
https://git.sr.ht/~whynothugo/shotman
Tested works in sway and hyprland.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 194378 on x86_64-linux 1

1 package built:

shotman

As shotman provide a binary, maybe the platforms should be set in meta ?

Result of nixpkgs-review pr 194378 run on x86_64-linux 1

1 package built:

shotman

As a sway user, this work without issue (tested basic feature like taking screenshot to a file or to the clipboard)


Integration with Nebius AI Studio added

Hey team,
Thanks for a great framework! Adding integration with Nebius AI Studio, which provides access to state-of-the-art models.

@ksolo may I kindly ask you to review it before it diverges too much from the main? thanks!

@Aktsvigun apologies on the delay I was traveling for the holidays.

@Aktsvigun Can you open a follow up PR with documentation? Examples can be found here (https://github.com/andrewyng/aisuite/tree/main/guides)

Hi @ksolo, thank you! Sure, will do.


Vote service throws a 500 and says it has a syntax error.

I use the vote service. The backend tests in the main repo suddenly became failures:
FAILED tests/system/action/poll/test_reset.py::PollResetActionTest::test_reset_correct
FAILED tests/system/action/poll/test_reset.py::PollResetActionTest::test_reset_not_allowed_to_vote_again
FAILED tests/system/action/poll/test_reset.py::PollResetActionTest::test_reset_permissions
FAILED tests/system/action/poll/test_stop.py::PollStopActionTest::test_stop_correct
FAILED tests/system/action/poll/test_stop.py::PollStopActionTest::test_stop_entitled_users_at_stop_user_only_once
FAILED tests/system/action/poll/test_stop.py::PollStopActionTest::test_stop_permissions
Error message:
{'success': False, 'message': 'Vote service sends HTTP 500 with the following content: b'{"error":"internal","message":"clearing counter: getting max score: calling zrange redis commant: ERR syntax error"}'.'}

Duplicate of https://github.com/OpenSlides/openslides-vote-service/issues/98


Bump Gen1 minimum firmware version to 1.11.0 (2021-07-15)

Due to many fixes and new functionalities introduced in subsequent firmware versions, the minimum firmware version supported by aioshelly is increased to 1.11.0 (2021-07-15). This release included the last major change in API functionality (transition for lights).
Changelog: https://shelly-api-docs.shelly.cloud/gen1/#changelog

Same question, should we mark this as breaking change?

OK, maybe I was too strict with the version number.
Therefore I suggest using version 1.11.0 (2021-07-15 according to the documentation) as the minimum version for gen1, this version introduced transition for lights.

Sounds great

I don't remember why in the code the date for 1.11.0 is 2023-02-26 (maybe this was a beta?) https://github.com/home-assistant/core/blob/c8bb72935d935680ea7a9c5f8bde552f2d8f7dcd/homeassistant/components/shelly/const.py#L36-L37
What do you think?

Looking at the timeline of the releases I assume it was a pre-release firmware we tested. I downgraded a bulb (SHCB-1) to v1.11.0 using Firmware Archive Link Generator and it is dated 20210720-184102/v1.11.0-g6abd92e. I assume the few days difference is due the time it was released to the time it was actually built.
We can use 2021-07-15 as mentioned in the changelog, I think we should also add this in the PR description that the minimum is set this version that supports transitions.

OK, maybe I was too strict with the version number.

Therefore I suggest using version 1.11.0 (2021-07-15 according to the documentation) as the minimum version for gen1, this version introduced transition for lights.

Sounds great

I don't remember why in the code the date for 1.11.0 is 2023-02-26 (maybe this was a beta?) https://github.com/home-assistant/core/blob/c8bb72935d935680ea7a9c5f8bde552f2d8f7dcd/homeassistant/components/shelly/const.py#L36-L37

What do you think?

Looking at the timeline of the releases I assume it was a pre-release firmware we tested. I downgraded a bulb (SHCB-1) to v1.11.0 using Firmware Archive Link Generator and it is dated 20210720-184102/v1.11.0-g6abd92e. I assume the few days difference is due the time it was released to the time it was actually built.

I got lost, as code there was a reference to 2023-02-06 and one to 2021-07-20; how is just a few days ?


Enforce 60minute minimum for autotest cycles

While courses should have some flexibility, a minimum should be enforced to avoid having the server be overloaded.

Make this dynamic instead: 2-5 minutes per student.


Splitting data into data batches

Currently, the particle_interaction function implemented on GPU is taking the whole dataset. This can lead to out of memory errors, especially on GPUs with less VRAM. To mitigate this problem, the data should be batched into smaller chunks before processing!
This should be addressed by calculating the needed and available memory on the GPU. Dividing these two values gives a lower bound on the number of batches to divide the dataset into.

Two approaches:

Static dividing of the data based on the total VRAM size of the GPU. This gives the index values to be passed down for calculation.
Dynamically determine how much space is left on the GPU and generate the index list. The number of elements of the index list changes every time, depending on how much the GPU is utilized.

check #38

Currently, only the phase function is batched due to the large number of angles that sometimes require calculation. The approach should be generalized further for other functions.


pure text DOI to url

There are always some kinds of DOI text on webpages like
DOI: 10.7176/JEP/11-6-08
are we able to convert this text to an sci-hub url directly?

Yes. It would be nice to add this feature.

http://www.socolar.com/Article/Index?aid=100055099031&jid=100000001481
这个网页它不能够直接高亮，添加至用户匹配后也是不成功，请问是什么原因呢？

@ZZY117 Check out v1.0.17


nimble/host: Set length correctly in perdioic_set_adv_data

This change sets length field only if data is non NULL, else sets  length to zero.
Core 5.4, Vol 4, Part E, section 7.8.62 states
"If Operation is not 0x03 or 0x04 and Advertising_Data_Length is zero, then the Controller shall return the error code Invalid HCI Command Parameters (0x12).."
Current code sets length to size of data. However, to validate above, need to send 0 length . So calculate length only if data is present.

currently ble_gap_periodic_adv_set() assumes that data is always valid and I'm not sure on how this patch would work since *data is dereferenced mutliple times later on in the function

Thanks for pointing this out. I have updated the patch to copy data only if len is valid . ( in the cases where length can be zero )

Hi @sjanc  , please let me know if there are any more comments.


Seems to conflict with indentLine plugin

Plugin seems to conflict with https://github.com/Yggdroot/indentLine.

It does not let indentLine enable.
Animation starts drawing signs from indentLine plugin.

I use indent-blankline.nvim I solved it excluding "nofile" :
  {
    "lukas-reineke/indent-blankline.nvim",
    config = function()
      require("indent_blankline").setup{
        buftype_exclude = { "terminal", "nofile" },
        filetype_exclude = { "dashboard","mason" },
      } end,
  },

I'm not sure how it would work on indentline. I checked the repo and perhaps you can try something like this
let g:indentLine_bufTypeExclude = get(g:, 'indentLine_bufTypeExclude', ['nofile'])

if you are using a mapping then you could execute two commands, one to begin or stop the animation and the other to toggle indentline.


Would you accept a PR with the configurable option to select the plain text?

Hey! thank you for this awesome plugin.
Would you be willing to accept a PR where setup takes the option to select the plain text ":bug:" instead of "🐛" ?

It may take forever, since I still need to master lua though 😄

Hi @mjacobus. Very glad to hear you like the plugin.
I thought about adding that feature as well. I think it can be accomplished quite easily by adding an extra option or field to items.lua.
But youre very welcome to share your thoughts on a potential solution.
Thanks a lot.

@mjacobus  I've added the functionality. Please checkout the README to see how to activate the functionality :)
Let me know if theres any trouble with it.
Thanks for the suggestion!

@Dynge that is so awesome, thank you very much!
It was not very clear to me though, how to set that up. I see by the code I should use complete_as = text, but I am not quite sure where to place it.
Should it be?
  require("gitmoji").setup({
    completion = {
      complete_as = "text"
    }
  })

Or...
require("cmp").setup({
  sources = {
    {
      name = 'gitmoji',
      opts = {
....
    }
  })
})

  require("gitmoji").setup({
    completion = {
      complete_as = "text"
    }
  })

This should do it. 😃

Thanks for the feedback. Ill update the readme to hopefully make it clearet

Closing the issue - assuming it works for you. 😁

You assumed correctly. 😄
Thank you so much 🙇🏻

Thats good to hear!


VS code resolving keyboard input into wrong characters

Issue Type: Bug
Fresh installation of VSCode for aarch64 on Ubuntu
Try out keyboard shortcuts ctrl + Z, ctrl + Y
Expected behaviours: undo and redo.
Output: Nothing happens
While debugging when I go to
View > Command Pallette > Developer: Toggle keyboard shortcut troubleshooting
e.g If I press
Ctrl + Z, it gets resolved to Ctrl + NumpadMultiply even when the logs shows Ctrl and Z are inputted. Some other keys like Ctrl + C get resolved correctly tho
The log output for Ctrl Z from Developer: Toggle keyboard shortcut troubleshooting before I open a file for editing is:
[2021-11-28 09:54:12.495] [renderer1] [info] [KeybindingService]: / Received  keydown event - modifiers: [ctrl], code: , keyCode: 17, key: Control
[2021-11-28 09:54:12.498] [renderer1] [info] [KeybindingService]: | Converted keydown event - modifiers: [ctrl], code: , keyCode: 5 ('Ctrl')
[2021-11-28 09:54:12.499] [renderer1] [info] [KeybindingService]: \ Keyboard event cannot be dispatched in keydown phase.
[2021-11-28 09:54:13.618] [renderer1] [info] [KeybindingService]: / Received  keydown event - modifiers: [ctrl], code: NumpadMultiply, keyCode: 90, key: z
[2021-11-28 09:54:13.622] [renderer1] [info] [KeybindingService]: | Converted keydown event - modifiers: [ctrl], code: NumpadMultiply, keyCode: 56 ('Z')
[2021-11-28 09:54:13.624] [renderer1] [info] [KeybindingService]: | Resolving ctrl+[NumpadMultiply]
[2021-11-28 09:54:13.625] [renderer1] [info] [KeybindingService]: \ No keybinding entries.
[2021-11-28 09:54:13.628] [renderer1] [info] [KeybindingService]: / Dispatching keybinding triggered via menu entry accelerator - ctrl+z
[2021-11-28 09:54:13.630] [renderer1] [info] [KeybindingService]: | Resolving ctrl+[KeyZ]
[2021-11-28 09:54:13.631] [renderer1] [info] [KeybindingService]: \ From 1 keybinding entries, matched undo, when: no when condition, source: built-in

It resolve to Ctrl + NumpadMultiply and also Ctrl Z.
After I open a file for editing, the log output is:
[2021-11-28 10:36:05.697] [renderer1] [info] [KeybindingService]: / Received  keydown event - modifiers: [], code: , keyCode: 0, key:
[2021-11-28 10:36:05.699] [renderer1] [info] [KeybindingService]: | Converted keydown event - modifiers: [], code: , keyCode: 0 ('unknown')
[2021-11-28 10:36:05.701] [renderer1] [info] [KeybindingService]: \ Keyboard event cannot be dispatched in keydown phase.
[2021-11-28 10:36:06.447] [renderer1] [info] [KeybindingService]: / Received  keydown event - modifiers: [ctrl], code: NumpadMultiply, keyCode: 106, key:
[2021-11-28 10:36:06.449] [renderer1] [info] [KeybindingService]: | Converted keydown event - modifiers: [ctrl], code: NumpadMultiply, keyCode: 103 ('NumPad_Multiply')
[2021-11-28 10:36:06.451] [renderer1] [info] [KeybindingService]: | Resolving ctrl+[NumpadMultiply]
[2021-11-28 10:36:06.452] [renderer1] [info] [KeybindingService]: \ No keybinding entries.

Now it only resolve to Ctrl + NumpadMultiply.
How does Ctrl - Z turns to Ctrl - NumpadMultiply?
This issues seems specific to VS code, what am I doing wrong?
VS Code version: Code 1.62.3 (ccbaa2d27e38e5afa3e5c21c1c7bef4657064247, 2021-11-17T08:05:05.159Z)
OS version: Linux arm64 4.14.186-gf9bc07ab427c-dirty
Restricted Mode: No

System Info

Item
Value

CPUs
undefined

GPU Status
2d_canvas: unavailable_softwaregpu_compositing: disabled_softwaremultiple_raster_threads: enabled_onoop_rasterization: disabled_offopengl: disabled_offrasterization: disabled_softwareskia_renderer: enabled_onvideo_decode: disabled_softwarevulkan: disabled_offwebgl: unavailable_softwarewebgl2: unavailable_software

Load (avg)
29, 29, 29

Memory (System)
3.69GB (0.12GB free)

Process Argv
--no-sandbox --disable-extensions --crash-reporter-id 9a4d725a-35b5-4ae0-8210-13608a72df90

Screen Reader
no

VM
0%

DESKTOP_SESSION
xfce

XDG_CURRENT_DESKTOP
XFCE

XDG_SESSION_DESKTOP
undefined

XDG_SESSION_TYPE
undefined

Extensions disabled
A/B Experiments
vsliv368:30146709
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythontb:30283811
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscoreces:30384385
pythondataviewer:30285071
vscod805cf:30301675
pythonvspyt200:30340761
binariesv615:30325510
bridge0708:30335490
dockerwalkthru:30377721
bridge0723:30353136
pythonrunftest32:30373476
pythonf5test824:30373475
javagetstartedt:30391933
pythonvspyt187:30373474
vsqsis300:30402085
vsaa593:30376534
vssld246cf:30401891
vscexrecpromptt2:30404948
vscop804cf:30404767
vs360:30404995

@maleeqB Are you perhaps connecting with remoting software to this Linux machine? You might be running into this issue: https://github.com/microsoft/vscode/wiki/Keybinding-Issues#troubleshoot-linux-keybindings


⚠ Bofrost.at has degraded performance

In 10a881b, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 2366 ms

Resolved: Bofrost.at performance has improved in 72bce6b.