docs: Adds Vega-Altair Theme Test

Related: https://github.com/vega/altair/issues/3519#issuecomment-2359179155
Description
This PR provides a recreation of Vega Theme Test using altair, accessible via the User Guide.
The primary benefit is to provide theme authors some sample code that they can use for testing the effects of their theme config.
I mentioned this in https://github.com/vega/altair/issues/3519#issuecomment-2359179155, but I really think it is valuable to have a quick way to experiment across a wide range of chart/mark types.
Additionally, it serves as an example of composing a complex compound chart.
Compared to the existing compound_charts section - this features a range of data sources w/ a mix of shared/unique and local/url.
Screenshots
Vega-Altair Theme Test
Ignore the slightly yellow hue. Seems to be an artifact of the screenshot itself
fivethirtyeight

latimes

vox

default

Current plan is for this link to replace the current link to Vega Theme Test
https://github.com/vega/altair/blob/02ad17d0f1f71ea5125a7c6c9b43a61fd80c4567/doc/user_guide/customization.rst?plain=1#L793
Code block
Collapsed

Expanded

The addition of this new directive allows directly referencing the contents of a function in the docs.

feat: Adds .. altair-code-ref:: directive
docs: Add folding code block for Vega-Altair Theme Test

There is also some interesting stuff in https://github.com/vega/altair/blob/3a5801edcbb0536b3031a32bc4984fdfe0d8fb8d/tools/codemod.py that can be adapted to support https://github.com/vega/altair/discussions/3570#discussioncomment-10560859.
The short explanation is this supports rewriting & reformatting code to be used elsewhere.
So this would have the benefit of writing in the same style as the rest of altair code, but support autoformatting for a possibly different style if agreed upon in https://github.com/vega/altair/issues/3519.
More generally though, a move towards writing code blocks in .py vs .rst has other benefits from a maintenance perspective:

Code reusability
Code blocks updating in response to IDE refactoring
Clearer diffs during review
Full access to tools like ruff, mypy to ensure code quality

Tasks

[x] Recreate charts used in demo

docs: Adds altair_theme_test.py provides a single chart adaptation of https://vega.github.io/vega-themes/

[x] Allow switching between themes

Working as of fix: Pass theme name to correct property

[x] Integrate into User Guide

[x] docs: Link to vega-altair_theme_test.html in #chart-themes
[x] Show (collapsible) code block used to create charts (thread)

Deferred

Refactor/move tests.altair_theme_test.py (thread)

I've made a start on this with (https://github.com/vega/altair/pull/3630/commits/6e1ca944614b567334f1f48ae028d893b7fa100f)
Could do with a second opinion on where these kinds of source snippets should sit
Uses mkdocs, but polars/docs/source/src

Set page background to match current theme

Would make sense if this is a standalone page (like the original)

Less so if it is part of the user guide

Not sure how feasible this is

Unlike index.html all we have here is the theme name - not the config object

Notes
Theme Selection (Planning)

My understanding (not a web dev) of how switching between themes works in Vega Theme Test:

Takes input from <select id="themes">
Extracts value from selector #themes
Storing config as theme
Passing theme to https://github.com/vega/vega-embed

@joelostblom do you have any ideas on how I'd go about integrating this into the User Guide?
I'm not sure if https://github.com/vega/sphinxext-altair would make sense here?

mypy issue in https://github.com/vega/altair/actions/runs/11194253679/job/31120512491?pr=3630 is unrelated to this PR
Will fix in another one

I have some reservations about this PR. It just adds another page that's really similar to the Vega Themes page. I think it would be better to have a dropdown menu with theme options right on the chart in the documentation section for Changing the Theme. That way, users can get a feel for the interactivity, like they can with the mark properties as eg. shown here. Probably you will still need an adaptation to the renderer for this though.

I have some reservations about this PR. It just adds another page that's really similar to the Vega Themes page. I think it would be better to have a dropdown menu with theme options right on the chart in the documentation section for Changing the Theme. That way, users can get a feel for the interactivity, like they can with the mark properties as eg. shown here. Probably you will still need an adaptation to the renderer for this though.

@mattijn thank you, I'm very open to ideas on how to improve this.
If we can get the theme switching working via a alt.binding_select that would be really interesting.
Maybe we can use an alt.Parameter inside alt.Chart.usermeta?

Good idea! I would be positively surprised if it is supported by the schema, but we can test it within the Vega editor.

Good idea! I would be positively surprised if it is supported by the schema, but we can test it within the Vega editor.

@mattijn this commit shows where we'd need the theme name to end up if that is helpful
https://github.com/vega/altair/pull/3630/commits/f6971dec83ba32b0e3e8eecad3cc9e6401f93bf5
I know that the resulting page is similar to Vega Theme Test, but this was one of the core differences.
In the original, the full theme config is loaded instead of the reference

Good idea! I would be positively surprised if it is supported by the schema, but we can test it within the Vega editor.

@mattijn So it isn't working, but also no errors so far.
from typing import get_args

import altair as alt
from altair.vegalite.v5.schema import _config as theme
from altair.vegalite.v5.schema._typing import VegaThemes

options = "default", *get_args(VegaThemes)

theme_name_select = theme.BindRadioSelectKwds(
    input="select", name="theme_name_select", options=options
)
theme_name_param = theme.VariableParameterKwds(
    bind=theme_name_select, name="theme_name_param", value="default"
)
theme_name_theme = theme.ThemeConfig(
    params=[theme_name_param],
    usermeta={"embedOptions": {"theme": {"expr": theme_name_param["name"]}}},
)

@alt.register_theme("theme_name_theme", enable=False)
def static_theme():
    return theme_name_theme

with alt.themes.enable("theme_name_theme"):
    to_dict = chart.to_dict()
    to_json = chart.to_json()
    to_url = chart.to_url()
    to_html = chart.to_html()

I would have shared the url but

Yeah, this works:
import altair as alt
from vega_datasets import data
import ipywidgets as widgets
from ipywidgets import interact
from ipywidgets import fixed

cars = data.cars.url

chart = alt.Chart(cars).mark_point().encode(
    x='Horsepower:Q',
    y='Miles_per_Gallon:Q',
    tooltip='Name:N',
)

themes = widgets.Dropdown(
    options=['latimes', 'dark', 'default'],
    value='dark',
    description='Theme:'
)

def chart_embed(themes, chart):
    alt.renderers.set_embed_options(theme=themes)
    return chart

interact(chart_embed, themes=themes, chart=fixed(chart))

Maybe we can integrate this using pyscript within our sphinx documentation?

Maybe we can integrate this using pyscript within our sphinx documentation?

@mattijn would that be similar to what @joelostblom and I discussed here? https://github.com/vega/altair/issues/3519#issuecomment-2356379412
Cool that you can get that working with so few lines of code https://github.com/vega/altair/pull/3630#issuecomment-2408665207

I was more thinking along the lines of using the sphinx-pyscript extension. References on this pages are useful for this: https://github.com/JeffersGlass/using-pyscript-in-documentation
Eg. the following raw html page is working already:

    Select theme:
    <select id="embed_theme" py-input="apply_embed_input">
        <option value="default">default</option>
        <option value="latimes">latimes</option>
        <option value="dark">dark</option>
    </select>

loading..

Side note: we should update the altair versions integrated within pyodide, it still on 5.3.0, with the latest version of altair, the hard dependencies are drastically reduced, which is good for loading time of these examples.

I was more thinking along the lines of using the sphinx-pyscript extension. References on this pages are useful for this: JeffersGlass/using-pyscript-in-documentation
Eg. the following raw html page is working already:

@mattijn this is looking really promising to me!
How does the loading time compare to this? https://github.com/vega/altair/blob/42491c7dc5a6975441578b63c884ee74424cdbea/doc/_static/vega-altair_theme_test.html
I did notice that there was already a bit of overhead with loading the datasets from urls, on each refresh
https://github.com/vega/altair/blob/42491c7dc5a6975441578b63c884ee74424cdbea/tests/altair_theme_test.py#L13-L158

@mattijn I've taken a look at sphinx-pyscript.
Based on the level of activity and the length of sphinx_pyscript.py I think it would make more sense to just write a directive ourselves.
Until https://github.com/sphinx-extensions2/sphinx-pyscript/pull/6 is merged, the project is still using https://github.com/pyscript/pyscript/releases/tag/2022.12.1

Awesome! Yeah I was thinking the same after checking out the activity of sphinx-pyscript extension, also realised it is a very tinny wrapper. Writing our own directive makes sense and can be considered realistic. pandas and numpy are hard dependencies of vega_datasets, so altair >= v5.4 with url references should performance-wise be a good way to go. Very promising indeed!

Awesome! Yeah I was thinking the same after checking out the activity of sphinx-pyscript extension, also realised it is a very tinny wrapper. Writing our own directive makes sense and can be considered realistic. pandas and numpy are hard dependencies of vega_datasets, so altair >= v5.4 with url references should performance-wise be a good way to go. Very promising indeed!

Perfect @mattijn
I've got some local changes that so far can build up contents of this tag in https://github.com/vega/altair/pull/3630#issuecomment-2408944677 code block


Update Composer dependencies (2024-01-25-00-17)

Visual regression test passed!
View the visual regression test report


Convert long-pwd to pwd-length

Extend #1310 to specify a length for pwd output, rather than just have a boolean for whether than output should be short or long form.

Thanks for doing this! Looks good.


Use ActionDispatch::Reloader instead of Shotgun

Summary
In development, even the simplest requests take multiple seconds. It's not because Jets is slow, but because shotgun is slow.
Motivation

Rails is significantly faster than Jets in development because of this, despite the fact that Jets is significantly lighter weight than Rails.
Reference-level explanation

Because Jets already relies on ActiveSupport::Dependencies, I think this should be possible?
The following middleware actually works for the simple example that I tried. It's definitely not thread-safe and there are probably a million issues, though.
# config/environments/development.rb
class Reloader
  def initialize(app)
    @app = app
  end

  def call(env)
    ActiveSupport::Dependencies.clear
    @app.call(env)
  end
end

Jets.application.configure do
  config.middleware.use Reloader
end

This article is an interesting read: https://crypt.codemancers.com/posts/2013-10-03-rails-reloading-in-dev-mode/
Drawbacks

It might be more complex 🤷♂
Unresolved Questions

Maybe it's possible to use ActionDispatch::Reloader?

Yup, definitely want to improve the speed of development reloading.  Want to play with the reloader a more because it is more complex.
As a workaround, some folks are have been using https://github.com/dblock/guard-rack
Played with guard-rack also and noticed that it reports harmless errors if you save rapidly.  IE: Another reload happens before rack has fully restarted.
The errors are harmless but can be confusing for folks. May just roll out a guard-rack as an option for the reloader since it is so simple and quick to implement. Reloaders generally seem pretty complex, so think it may require some time to investigate 🤔
Happy to consider PRs here.

What about https://github.com/fxn/zeitwerk?
That's going to be the default code loader in Rails 6 and is supposedly designed to be used in any ruby project.

Yup. Would like to try zeitwerk also.

Addressed this in #254. Using zeitwerk for auto reloading in development mode.
A quick check with time curl localhost:8888/posts

Before: 0m2.259s
After: 0m0.094s

24X improvement. Generally, improvement in the 10x range.
Even though a lot more can be done to clean up the loader, went ahead and rolled it out.
Released in v1.9.0


Make a small lesson on working on a Unix vs Windows system

During the first teaching of this course, it became clear that it really does make a big difference for people entering the area of Semantic Engineering whether they are on Windows or a Unix type system.. We should provide an overview of the major differences and explain how we mitigate them. Lets use this ticket to collect relevant differences.

how to install protege and protege plugins
How file paths work and how encode paths as part of reproducible pipelines


Registration email sends tracking pixel

See https://github.com/solid/node-solid-server/issues/1532 (probably not an NSS issue, but impacts inrupt.net as well.

@justinwb is this you can check. You stated that solidcommunity.net was using an email on sendgrid.
I fund some information on the spy-tracking when using sendgrid mail https://community.auth0.com/t/howto-disable-sendgrids-click-tracking-feature-in-an-auth0-email-template/22958

Thanks @jeff-zucker (and everyone else on the original thread) for resporting this.
This was triggered by a default setting in Sendgrid, which is used by Inrupt for email delivery. This has now been corrected by disabling the option in Sendgrid. Apologies for any inconveniencies!


Wrong type in mutation binding generated for rspc

Consider the following prisma schema:
model Settings {
    key           String    @id @unique
    valueBool     Boolean?
    valueInt      Int?
    valueFloat    Float?
    valueDecimal  Decimal?
    valueString   String?
    valueDatetime DateTime?
}

The generated PrismaClient shows the following:
#[derive(
        Debug,
        Clone,
        :: serde :: Serialize,
        :: serde :: Deserialize,
        :: prisma_client_rust :: rspc :: Type,
    )]
    #[specta(
        rename = "Settings",
        crate = "prisma_client_rust::rspc::internal::specta"
    )]
    pub struct Data {
        #[serde(rename = "key")]
        pub key: String,
        #[serde(rename = "valueBool")]
        pub value_bool: Option<bool>,
        #[serde(rename = "valueInt")]
        pub value_int: Option<i32>,
        #[serde(rename = "valueFloat")]
        pub value_float: Option<f64>,
        #[serde(rename = "valueDecimal")]
        pub value_decimal: Option<f64>,
        #[serde(rename = "valueString")]
        pub value_string: Option<String>,
        #[serde(rename = "valueDatetime")]
        pub value_datetime: Option<
            ::prisma_client_rust::chrono::DateTime<::prisma_client_rust::chrono::FixedOffset>,
        >,
    }

I setup a query and mutation as follows in the rspc router (note that the mutation doesn't return the same type as the query):
#[derive(Debug, Default, Serialize, Deserialize, Type)]
pub(crate) struct Settings {
    pub(crate) profile: Profile,
}

#[derive(Debug, Default, Serialize, Deserialize, Type)]
pub(crate) struct Profile {
    pub(crate) some_setting: Option<String>,
}

RouterBuilder::<Arc<PrismaClient>>::new().query("get", |t| {
            // get all settings
            t(|db, _: ()| async move {
                let some_setting = db
                    .settings()
                    .find_unique(settings::key::equals("my_key".to_string()))
                    .exec()
                    .await
                    .unwrap_or_default();
                Ok(Settings {
                    profile: Profile {
                        some_setting: some_setting.and_then(|s| s.value_string),
                    },
                })
            })
        })
        .mutation("set_string", |t| {
            #[derive(Debug, Serialize, Deserialize, Type)]
            struct SettingsSetStringInput {
                key: String,
                value_string: Option<String>,
            }
            t(|db, args: SettingsSetStringInput| async move {
                let value = db
                    .settings()
                    .upsert(
                        settings::key::equals(args.key.clone()),
                        settings::create(
                            args.key,
                            vec![settings::value_string::set(args.value_string.clone())],
                        ),
                        vec![settings::value_string::set(args.value_string)],
                    )
                    .exec()
                    .await?;
                Ok(value)
            })
        })

I expect the return value to be the same shape as Data above, but here is what rspc generates in TS-land in the end:
export type Procedures = {
    queries:
        { key: "settings.get", input: never, result: Settings },
    mutations:
        { key: "settings.set_string", input: SettingsSetStringInput, result: Settings },
    subscriptions: never
};

export interface Profile { some_setting: string | null }

export interface Settings { profile: Profile }

export interface SettingsSetStringInput { key: string, value_string: string | null }

So when in fact I get the following back from the rspc call in TS-land:
{key: "profile.some_setting", valueBool: null, /*...*/ valueString: "foobar"},
TypeScript thinks I'm getting { profile: { some_setting: "foobar" } }
I think the problem might stem from the following rename generated in prisma.rs:
#[specta(
        rename = "Settings",
        crate = "prisma_client_rust::rspc::internal::specta"
    )]

The Data struct below this statement is not equivalent to Settings which is my custom struct with a profile member. It seems rspc never generates a binding for the Data struct and also uses the wrong type for the return value of the mutation.

I'm 99% sure this is just a naming conflict. All Data structs get a Specta rename to their model name and I'm not changing that, picking a different name for your custom Settings struct should fix it.

You were right! Name conflict, when I changed my struct to AppSettings, an additional binding was created.
Might be worth thinking about documenting this or maybe printing our a warning if such a situation is encountered (provided it can be detected).
Thanks for the help!

The next rspc release will have proper errors for duplicate type names. Sorry for the confusion with it!


fix client prop patch should add {DAV:}prop parent node

After some test, it's seems OOB Sabre WebDav client Propatch method not correctly encapsulate element in XML request (miss '{DAV:}prop') I propose patch with this element

Thanks for the patch!


Create server button does nothing?

I got the mod working but sadly the "Create Server" button appearently does nothing. I also don't know how to close and open the menu.
Please if you continue working on this mod it'd be amazing, lot of people are waiting for enjoy mon bazou with friends :D

Hey there, the "Create Server"-Button actually does do something, there is just no feedback without opening the BepInEx console.
Also there currently is no button to close the menu.

Oh! Thanks for the reply & reply speed!! So my friend might just connect to me and we are all good?. Also there isnt any way to hide the menu?

I manage to join my friend, he appear on my world but frozen and hes on his game anyway, also I get to his screen but I disappear and my game still normally

And now it doesnt work, I was be able to see my friend moving but he was still in his "world"

Multiplayer still doesn't work as it already says in the readme.
There is no synchronisation of worlds and of any objects.

Multiplayer still doesn't work as it already says in the readme. There is no synchronisation of worlds and of any objects.

Oh I understand. Thank you for replying and I hope you can work on this!
Wish you all the best! <3


Fix postgres regression

This fixes the issue with postgres tests not passing. It also adds postgres to the testing, hooray for exploding builds :-).
Also a bug fix and a small change in behavior for authentication: users will now actually be created in the db and will not be created with superuser privileges anymore.

Should we do 2.7/cloudera only for sqlite and postgres?

Haha, I'm in doubt thinking about it. Facts & thoughts:

CDH/HDP are not really tested against yet. To make it useful we need a mini hive cluster. Hopefully I have something coming month. CDH and HDP both have different Hive versions and CDH seems to back port fixes a bit more.
Sqlite is not used / should not be used in production, but comes in handy for development. Sqlite did suffer from regressions and so hampers development if it doesn't work
Postgres is first class citizen in the os world and even enterprise world is picking it up
Python 2.7 is mainstream, but python 3 demand is picking up quickly. I expect future major releases of linux distributions to start using python 3 as a standard soon.

So for now it doesn't really matter if we disable CDH/HDP at all. For backend testing it looks nicer to me to test within the same env, but as was mentioned in the other thread having it completely separated has also benefits.
So does this answer your question? I doubt it ;-)

Agreed, let's comment out hortonwork for now.
Until we have a mini cluster setup, I have a way to run tests against our Hadoop environment and will do so anytime someone touches one of the related operators/hooks.

@mistercrunch Ok, some more bug fixes and I have limited the build matrix to CDH only now.

Nice! Merging.


bug: some tests are broken due to fixing dependency cycles

This example cannot run for instance, because of the fact that we can't import setup_test_provider.
Three alternatives (n°1 is my fav):

Remove this example (and the ones like it) altogether, and count on the MDBOOK to do its work
Re-introduce the fuels-helpers dependency but re-create a dependency cycle just for having a working example
Add the ignore tag to this example, but then it's not tested and easily gets out of sync with the code

This was inadvertently fixed using n°1 in #848. Can be reopened if necessary.


ERROR: project_1.getProject is not a function

I'm submitting a...

[ ] Bug report
[ ] Feature request
[ ] Documentation issue or request

In package

"@ng-toolkit/_utils": "^8.0.1",
    "@ng-toolkit/init": "^7.1.0",
    "@ng-toolkit/pwa": "^8.0.1",
    "@ng-toolkit/universal": "^7.1.2",

Current behavior

Expected behavior

Minimal reproduction of the problem with instructions

Example repository

What is the motivation / use case for changing the behavior?

Environment

Angular CLI : 6.2.5
Angular version: 6.1.10

- Node version: 10.17.0
- Platform:  linux x64

Others:
@angular-devkit/architect         0.8.9
@angular-devkit/build-angular     0.8.9
@angular-devkit/build-optimizer   0.8.9
@angular-devkit/build-webpack     0.8.9
@angular-devkit/core              0.8.9
@angular-devkit/schematics        0.8.5
@angular/animations               9.0.0-next.14
@angular/cdk                      6.4.7
@angular/cli                      6.2.5
@angular/compiler-cli             6.1.3
@angular/flex-layout              7.0.0-beta.24
@angular/material                 6.4.7
@ngtools/webpack                  6.2.9
@schematics/angular               0.8.5
@schematics/update                0.8.5
rxjs                              6.2.2
typescript                        2.7.2
webpack                           4.16.4

@maciejtreder We forgot to update ng-toolkit/init? Because at the npm, it is still at 7.1.2. Maybe this is the reason of the above issue.

Closing now for housekeeping purposes.
The @ng-toolkit/init package has been updated to 8.0.3 today, so everything should be working as intended.


dosen't inject

hey when i click load it loads evrything but the dll dosent inject how can i fix that?

What you're using to inject the dll? If its fedoraloader, then go to https://github.com/lnx00/Fedoraloader/issues

cheers mate


Implement modulus operator for BigInt

The implemented operator behaves as follows:
22 mod 5 = 2
-22 mod 5 = 3
22 mod -5 = -3
-22 mod -5 = -2

Codecov Report

Merging #19 into master will decrease coverage by 0.55%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master      #19      +/-   ##
==========================================
- Coverage     100%   99.44%   -0.56%
==========================================
  Files          19       19
  Lines        1067     1073       +6
==========================================
  Hits         1067     1067
- Misses          0        6       +6

Thanks! ✨
I think I'll do one more release soon(ish), before we need to update the package to Swift 4 and its nice new integer protocols.


Package request: Sourcery.ai

Add Sourcery.ai to packages

Sourcery.ai is a non free package for Python which is available from this link.
Or it can be made available for VScode via this link.
Similar for Vim, Command Line, PyCharm, Emacs or Sublime.
I tried to add this this to my home.nix within a vsocde section:
{
name = "sourcery.sourcery";
publisher = "sourcery.ai";
version = "1.6.0";
sha256 = "0000000000000000000000000000000000000000000000000000";
}
But result:
Cant install sourcery for vscode:
home-manager build switch
produces
building '/nix/store/ag5i8qpv0wkpayjvnkdi0dnwdmhrqa12-sourcery.ai-sourcery.sourcery.zip.drv'...
trying https://sourcery.ai.gallery.vsassets.io/_apis/public/gallery/publisher/sourcery.ai/extension/sourcery.sourcery/1.6.0/assetbyname/Microsoft.VisualStudio.Services.VSIXPackage
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
Dload  Upload   Total   Spent    Left  Speed
0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (22) The requested URL returned error: 400
error: cannot download sourcery.ai-sourcery.sourcery.zip from any mirror
error: builder for '/nix/store/ag5i8qpv0wkpayjvnkdi0dnwdmhrqa12-sourcery.ai-sourcery.sourcery.zip.drv' failed with exit code 1;
last 7 log lines:
>
> trying https://sourcery.ai.gallery.vsassets.io/apis/public/gallery/publisher/sourcery.ai/extension/sourcery.sourcery/1.6.0/assetbyname/Microsoft.VisualStudio.Services.VSIXPackage
>   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
>                                  Dload  Upload   Total   Spent    Left  Speed
>   0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
> curl: (22) The requested URL returned error: 400
> error: cannot download sourcery.ai-sourcery.sourcery.zip from any mirror
For full logs, run 'nix log /nix/store/ag5i8qpv0wkpayjvnkdi0dnwdmhrqa12-sourcery.ai-sourcery.sourcery.zip.drv'.
error: 1 dependencies of derivation '/nix/store/z62dqgjxbm3v3p4hj62bf4aa9nv8y1ix-vscode-extension-sourcery.ai-sourcery.sourcery-1.6.0.drv' failed to build
error: 1 dependencies of derivation '/nix/store/y3rmcb7pcc9j03j0408dsn6g5cnzkvw5-hm.vscodeextensions.extensionsimmutable.json.drv' failed to build
error: 1 dependencies of derivation '/nix/store/ixfc6bjhprz4n88zk6rsgzs8kas925xi-home-manager-files.drv' failed to build
error: 1 dependencies of derivation '/nix/store/qfxzn9qqbzpq5mmsk1py6ni9lw70zhgk-home-manager-generation.drv' failed to build`
When I visit the link in browser I get:
Our services aren't available right now
I note that searching Nix packages for sourcery produces a result for Code Sourcery C++ ABI, which is unrelated, hence the name should be distinctive.
Metadata

homepage URL: https://docs.sourcery.ai/
source URL: https://github.com/sourcery-ai/sourcery
and https://www.vsixhub.com/vsix/20643/
and https://api.github.com/repos/sourcery-ai/sourcery/tarball/v1.6.0
and https://api.github.com/repos/sourcery-ai/sourcery/zipball/v1.6.0
license: mit
platforms: linux, darwin

PR available.


DO NOT MERGE  - Beta3

Description
This PR created to validate the builds pipeline - please DO NOT MERGE

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-communication-callautomation


Automatically create commands for reverse m2m associations

Our instance group model is sad.
tower-cli instance_group
Usage: tower-cli instance_group [OPTIONS] COMMAND [ARGS]...

  Check instance groups within Ansible Tower.

Options:
  --help  Show this message and exit.

Commands:
  get   Return one and exactly one instance group.
  list  Return a list of instance groups.

It only has 2 boring options! Its real reason for existence is because other resources will associate with it. It would make a lot of sense to allow users to reach these commands, like tower-cli job_template associate_ig, from the instance_group base command. For example, tower-cli instance_group associate_job_template.
Since the association commands are already created on the fly from the many-to-many field type, it may be possible to automatically generate reverse association methods on the fly as well.
For example
tower-cli instance_group
Usage: tower-cli instance_group [OPTIONS] COMMAND [ARGS]...

  Check instance groups within Ansible Tower.

Options:
  --help  Show this message and exit.

Commands:
  get   Return one and exactly one instance group.
  list  Return a list of instance groups.

Reverse Associations
  associate_job_template
  disassociate_job_template

This is a real pie-in-the-sky feature, but it might be workable.

this is not obviously possible without creating massive new programming structures.


Batch Inference & Podcast Generation

Here's what the Batch Inference part does:

Try to put as much characters as possible into one batch (200 max)
If it's not possible, it'll try to do a cut whenever there's a semicolon character
If it's not possible, it'll try to do a cut whenever there's a comma character
If it's not possible, it'll try to do a cut after the most logical word (thus, therefore etc.) --> There's a list at the top of the Gradio script, and it's possible to modify it in Advanced Settings
If nothing above worked, it's just going to go past that 200 line (realistically, if your text isn't gibberish, this shouldn't happen :D)

The Podcast Generation feature has these features built in:

Takes two reference speeches and two reference texts (or empty and then transcribed automatically)
You have to give a name to each of the two speakers
You can then paste the podcast script, with one speaker's name followed by a semicolon and then their text, you can do the same with the other speaker, all as long as you want (because it's using the same batch inference as before)

All in all, the batch inference feature allow for a little bit more than real-time inference. (I might do another pull request with real-time streaming)
Immense thanks to all of those who worked on this project, it's really great. There's of course still room for improvement, but I think this is a step forward in terms of OSS TTS, so thanks !

Many thanks ~


Rule idea: no unknown method binding

The rule should warn when trying to bind a method which doesn't exist on the component class. For example:
export default class MyComponent extends React.Component {
  constructor() {
    super();

    this.unknownMethod = this.unknownMethod.bind(this);
  }
}

This bug causes React to throw an error with an unrelated message and difficult to debug.

(Note that in the screenshot AppContainer is the root Component, not the one which binded the unknown method, making it very hard to debug.)

You can't statically know that the method doesn't exist, because you have no idea what React.Component.prototype implements.

Most of the time, apart from lifecycle methods, you don't use any another method from React.Component.prototype. Which are the methods, other than lifecycle and render, which you could use from React.Component?

What I mean is, this would be a weird React-specific rule, and could only apply to things directly inheriting from React.Component - it would make more sense as a generic class rule, but then it becomes impossible to statically enforce.

I think there is benefit in having a React-specific rule for this.

@ljharb I understand your point and the reason I opened the issue here is indeed for the same reason, which is the impossibility to use it with a generic class. As I said this rule would apply only to React Components and I don't believe it's weird because binding in constructor follows from the jsx-no-bind rule.

I'm concerned that it would break in a future version of React, but we could certainly implement it for 0.13, 0.14, and 15.0


Yes install installed for this iOS

Yes install installed for this iOS

Originally posted by @Daddy2200 in https://github.com/BetterDiscord/Installer/issues/67#issuecomment-813598653

Yes install installed for this iOS

Originally posted by @Daddy2200 in https://github.com/BetterDiscord/Installer/issues/67#issuecomment-813598653

{Never delete}

See my comment in #67.


Remove Pre/Post Deployment Tasks/Evaluations from KeptnApp in v1beta1

Pre-requisites:

[x] https://github.com/keptn/lifecycle-toolkit/issues/2574

Goal
Remove the mentioned fields from the KeptnApp CRD and adapt controller logic to use the pro/post tasks/evaluations from the newly introduced KeptnAppContext.
Details
In #2574 , the Pre/Post deployment checks that used to be defined in the KeptnApp CRD, have been moved to the KeptnAppContext CRD. This means that the KeptnApp controller, which creates a KeptnAppVersion
needs to be adapted to retrieve the specification for the pre-/post deployment tasks from the KeptnAppContext, before creating the KeptnAppVersion.
Acceptance Criteria

[ ] The KeptnApp controller uses the pre/post deployment task specification defined in the KeptnAppContext when creating a KeptnAppVersion

DoD

[ ] Unit tests
[ ] Integration tests have been adapted - there should be no KeptnApp CRs in the xx-install.yaml files left. All of those should be replaced by KeptnAppCntext CRs, with the Workload version list being removed
[ ] tests are passing
[ ] ⚠ BREAKING CHANGE is added to the PR

References
Link to the PoC: https://github.com/keptn/lifecycle-toolkit/pull/2570

Hi @bacherfl could you please assign this issue to me as I have just completed the prerequisite.

@geoffrey1330 - sure! let us know if you have any questions when implementing this

@geoffrey1330 - sure! let us know if you have any questions when implementing this

Alright


Add ARIA as an alias for all ARIA based modes.

Include ARIA as an alias for ARIA based TLS modes.
ciphers ARIA works after this.

But throw in some man1/ciphers.pod update too, as discussed in #4287 :-)
[Just in case, I'm signing off for today soon...]

Done the ciphers.pod update

Merged, thanks.

paypal.me/tuchikdevill


Setting up fast_align

I followed the steps mention to setup fast align in my system. However, i am facing some difficulties.
Can anyone tell me exact procedure?
Do I have to train first and then calculate alignment on my test data?
Any python based approach?

Which problem do you have exactly? What exactly do you pretend to obtain?
Regards

I am constantly receiving the below error when I am running the make command
fatal error: google/sparse_hash_map: No such file or directory
So basically I want to generate alignments for 2 sentences in english(source) and hindi(target) languages.That is I want to achieve word correspondes/mapping.
I also wish to understand what method fast_align is using to align words between two languages without having a Neural network trained to do it?
@zparcheta


Hll 2 wave improvements

This addresses #1525 by providing implementations for the standard 2-wave HLL solver for SWE, MHD, CEE as well as the improved 2-wave HLL solver by Einfeldt using Roe averages for SWE.
For completeness, the naive 2-wave HLL solver is added also for MHD.
The motivation for this pull request is

Increase consistency for SWE, MHD, CEE
Provide the standard 2-Wave HLL as the default when calling flux_hll as one would expect

For illustration, the solution of the Sedov Blast wave is compared for the previously default min_max_speed_naive to the new default min_max_speed and flux_hllc.

min_max_speed_naive

min_max_speed

flux_hllc

I have not yet formatted to have significantly fewer changes, otherwise, nearly every line of code is changed due to whitespace to tab conversion.

I haven't thought this through, but I'm just curious. Would something like the following work? Since min_max_speed (and also max_abs_speeds ?) only depend on the eigenvalues of the flux-jacobian of the equations we could define a general function like
function min_max_speed(u_ll, u_rr, normal_direction::AbstractVector, equations::AbstractEquations)
    λ_ll = eigenvalues(u_ll, normal_direction, equations)
    λ_rr = eigenvalues(u_rr, normal_direction, equations)
    λ_min = min(λ_ll)
    λ_max = max(λ_rr)
    return λ_min, λ_max
end

and define for each equation a function returning the eigenvalues, e.g.
function eigenvalues(u, orientation::Integer, equations::CompressibleEulerEquations1D)
    rho, v1, p = cons2prim(u, equations)

    c = sqrt(equations.gamma * p / rho)
    return v1 - c1, v1, v1 + c1
end

For me, it would be more natural to provide the eigenvalues of a system than to provide a function min_max_speed when one wants to add a new equation since the eigenvalues are more equation-specific and, as far as I understand, at least for the "normal" Euler equations or SWE, min_max_speed is generic. Maybe even some other functions that only depend on the eigenvalues could be defined generically? Or would this approach be too general and would not work for  more sophisticated equations (I remember @andrewwinters5000 mentioned that the eigenvalues are not known for the two-layer SWE for example)? For me, ideally, it should be necessary for the definition of an equation to provide the minimal set of functions conisting of  flux, eigenvalues and maybe some conversion functions like prim2cons  and cons2prim. This should be enough to, at least have a working equation with the basic numerical fluxes like flux_lax_friedrichs or flux_hll, shouldn't it? If you have some more sophisticated estimates on the minimal and maximal speeds like Roe averages or if you have a more sophisticated definition for the HLL flux (like for SWE to avoid spurious oscillations in the bottom topography) you can of course provide them for the specific equation, but at least you have some general fallback.

So for the classical HLL 2-Wave solver you would have
function min_max_speed(u_ll, u_rr, orientation::Integer, equations::AbstractEquations)
    λ_ll = eigenvalues(u_ll, orientation, equations)
    λ_rr = eigenvalues(u_rr, orientation, equations)
    λ_min = min(min(λ_ll), min(λ_rr))
    λ_max = max(max(λ_ll), max((λ_rr))
    return λ_min, λ_max
end

which is probably more expensive than the current implementations.
While I can see the elegance in the proposed implementation (especially for SWE and CEE) it is questionable whether this is well suited for e.g. MHD which comes (even in the 1D case) with 8 eigenvalues of which you in principle need only 2.

So for the classical HLL 2-Wave solver you would have
Yes.
Performance-wise you are probably right.

With the upcoming breaking release of v0.6 coming up, is this PR still considered to be merged?

@sloede The main motivation is still there: The naming of wave-speeds is not consistent among equations, most notably for MHD things are different from SWE and CEE.

OK. But is this PR in a shape that can be made ready to merge within the next, say, week?

Probably its easier to start over from main branch, but this should be possible.

OK. I'm not saying it has to be done though. But now would be the time for breaking changes 😄

Yes, that would be nice 👍

The new PR is https://github.com/trixi-framework/Trixi.jl/pull/1708


HIVE-25450: Delta metrics keys should contain database name

What changes were proposed in this pull request?

Why are the changes needed?

Does this PR introduce any user-facing change?

How was this patch tested?

committed in #2613


Defaults in metaprops incorrect or incorrectly parsed

Unlike normal in-statement props, metaprops have some default values which, @tomaham, are not right in the current parsed data (v. 1.2.0  | data-import | built: Fri 13.05.2022 16:59). Some of them (logical operator) were right in the previous import - what happened to them since, I don't know, but we need to rectify this in the workflow (not just in the current data, but really in the workflow, otherwise, some big průser is to be expected with nearcertainty).
Whole metaproperty statement:

elvl always "inferential" (i.e. 3)
mood "indicative"
mood variant "realis"
logical operator "and" (this was solved, but now it is again "=" by some mistake!!!)
certainty "-", not "certain

Metaprop Proptype:

elvl "inferential" (i.e. 3)

Metaprop Propvalue:

elvl "inferential" (i.e. 3)

Otherwise seems OK - i.e. this is not to list all defaults, just diferentially to the current data import (see screenshot below).
This all only concerns metaprops, not in-statement props. If this is a reason to divide IProp into two, i.e. IMetaprop and IProp, let us go ahead with this if @adammertel approves - perhaps it is now the same data type and perhaps it creates some problems, I don't know.

@rljshaw : can you please cross-check the defaults on principle, and if not correct, tell me here?

@davidzbiral I understand that these are default values.
In the case of epistemic level, we decided to disallow all the other options than inferential. But what about other attributes for metaprop statement (e.g., mood indicative) - are those mandatory values that will not be possible to change or those are only default values?
In case all the values you mentioned are not to be set by the user, I would probably hide them in the UI. I am not sure if a division of the model is a good idea now.

@davidzbiral  This problem probably still persists in the import data.
The present approach is: not make any hardcoded object division between Prop and MetaProp, both still use interface IProp (right @adammertel ?).   So to have the right epistemic level in MetaProps, the context of the import needs to be used (my problem).
@adammertel I am not sure about "certainty" and value="-", the code allows just "0", so "0" is the targeted ="-"?
@davidzbiral The defaults of import for props are okay? (e.g. there is no mood in the default, this is right?)
So this is what we have for IProp as default
    'IProp':{             'bundleEnd':False,'bundleStart':False, 'certainty':'1', 'children':[], 'elvl':'1',  'id':'', 'logic':'1', 'mood':[], 'moodvariant':'1', 'bundleOperator':'a', 'type': {'id':'','elvl':'1','logic':'1','partitivity':'1','virtuality':'1'},'value':{'id':'','elvl':'1', 'logic':'1', 'partitivity':'1', 'virtuality':'1'}         },
And this is what we should have for IProp used for Metaprops
    'IProp':{             'bundleEnd':False,'bundleStart':False, 'certainty':'0', 'children':[], 'elvl':'3',  'id':'', 'logic':'1', 'mood':['1'], 'moodvariant':'1', 'bundleOperator':'a', 'type': {'id':'','elvl':'3','logic':'1','partitivity':'1','virtuality':'1'},'value':{'id':'','elvl':'3', 'logic':'1', 'partitivity':'1', 'virtuality':'1'}         },
Right?

@adammertel I am not sure about "certainty" and value="-", the code allows just "0", so "0" is the targeted ="-"?

Yes, "-" is a label, the value in the entity is then "0"

The present approach is: not make any hardcoded object division between Prop and MetaProp, both still use interface IProp

I am not that fixed to this solution. If David confirms, that the number of possible values for meta props is radically different than the classical in-statement prop, I am okey opening the discussion of having two IProp models.

@davidzbiral can confirm your proposed defaults are correct.
As for the question of whether things other than epistemic level should be "locked" to the defaults with meta props, my view is probably yes, since I cannot see when a non default value would be used in meta properties, but I may be forgetting something that @davidzbiral will remember!

Are those mandatory values that will not be possible to change or those are only default values that is possible to change by the user?
In case all the values you mentioned are not to be set by the user, I would probably hide them in the UI.

@tomaham , @adammertel : I confirm Adam's solution.

The list of those default values is clear or not?

@davidzbiral It seems clear, but do I interpret it right? :D  That is the question. Check the value below, please.
The defaults of import for props are okay? (e.g. there is no mood in the default, this is right?)
So this is what we have for IProp as default
'IProp':{ 'bundleEnd':False,'bundleStart':False, 'certainty':'1', 'children':[], 'elvl':'1', 'id':'', 'logic':'1', 'mood':[], 'moodvariant':'1', 'bundleOperator':'a', 'type': {'id':'','elvl':'1','logic':'1','partitivity':'1','virtuality':'1'},'value':{'id':'','elvl':'1', 'logic':'1', 'partitivity':'1', 'virtuality':'1'} },
And this is what we should have for IProp defaults used for Metaprops
'IProp':{ 'bundleEnd':False,'bundleStart':False, 'certainty':'0', 'children':[], 'elvl':'3', 'id':'', 'logic':'1', 'mood':['1'], 'moodvariant':'1', 'bundleOperator':'a', 'type': {'id':'','elvl':'3','logic':'1','partitivity':'1','virtuality':'1'},'value':{'id':'','elvl':'3', 'logic':'1', 'partitivity':'1', 'virtuality':'1'} },

@tomaham , @adammertel : where I can find a textual translation of the values, e.g. logic "1", partitivity "1". I cannot read this, I must see the textual values. I suggest even that this is permanently maintained. Perhaps the InkVisitor dictionary/ies are somewhere on GitHub - if so, can we make them more findable by people like me?
Other than that, the defaults in a normal prop should be:

Certainty = "-" (0), not 1.
Mood = "indication", not empty.

@adammertel , @tomaham:
Let us leave the IProp model for both normal in-statement props and metaprops for now, and only lock the values in metaprops. There might be projects other than ours, which would like to store some things as metaprops that we wouldn't, e.g. that something does not have some quality (negative logic). There also might be projects which, by legacy necessity, will also parse some data into this structure, and some things that normally should be props will be parsed from entity tables as metaprops, but will be set to elvl1 (even if not correctly referenced to a T and R).
So let us only lock the metaprop values (and set proper defaults in parsed data), not change the models.

But what about other attributes for metaprop statement (e.g., mood indicative) - are those mandatory values that will not be possible to change or those are only default values that is possible to change by the user?
In case all the values you mentioned are not to be set by the user, I would probably hide them in the UI. I am not sure if a division of the model is a good idea now.

They are mandatory (in metaprops) - at least we now think so :-).
Yes, this is what we will do now: hide them in the GUI. And thus, the cogwheel button will disappear from metaprops.

@davidzbiral

where I can find a textual translation of the values,

The "translations" for dictionaries are in this file, the list of all dictionaries can be found in this folder

Thanks @davidzbiral  for clarifications. I created #1067 and #1068 to apply these changes inside the InkVisitor.
All the "default" "mandatory" fields will be applied on the creation of the meta prop and will be hidden in the modal.

@tomaham I removed the application-relevant tasks to new issues, so consider this issue as a data-parsing one (= its yours now :))

@tomaham : is this solved?

@tomaham We now removed most things in metaprops, so much is solved, but certainty and logic remain. Defaults are: logic = positive (OK in current import batch, but certainty = "-" (which is, I think numerically the value 0). Here, the current import is incorrect, it has certainty = certain.

Should be corrected in the Import batch [development] 2022-10-22 18:54:22.598885

Checked as corrected on a couple of examples in the Import batch [development] 2022-10-22 18:54:22.598885. The only remaining issue is the default mood "" (empty) instead of 1, asking Adam about this in the open issue #976. Closing this one.


Storage Bucket Retention Constraint v1

Storage Bucket Retention constraint for #271
This PR creates a GCS Storage Bucket Retention constraint that checks for the retention policy of a Storage bucket and compares the user defined number of days the retention of a Storage bucket should be against what it actually is, utilizing the conditions found in the lifecycle Delete action field (age, createdBefore, numNewerVersions) found in a Storage bucket resource.
More information can be found here: https://cloud.google.com/storage/docs/lifecycle?_ga=2.61946092.1397461211.1583171965-991612729.1570764018
This constraint provides the following features:

minimum_retention_days identifies the minimum number of days that a storage bucket life should be.

Generate a violation if any of the following are true:

lifecycle Delete 'age' condition (i.e. retention days) is less than minimum_retention_days
lifecycle Delete 'createdBefore' condition is less than minimum_retention_days
lifecycle Delete 'numNewerVersions' is 0 or does NOT exist
E.g. minimum_retention_days: 100 will generate violations for -->

Any storage buckets that have a retention less than 100 days
Any storage buckets whose difference between now and its 'createdBefore' condition is less than 100 days
Any storage buckets where 'numNewerVersions' is 0 or does NOT exist

maximum_retention_days identifies the maximum number of days that a storage bucket life should be limited to.

Generate a violation if any of the following are true:

lifecycle Delete 'age' condition (i.e. retention days) is greater than maximum_retention_days
lifecycle Delete 'age' condition does NOT exist and maximum_retention_days is defined
lifecycle Delete action itself does NOT exist when maximum_retention_days is defined
E.g. maximum_retention_days: 200 will generate violations for -->

Any storage buckets that have a retention greater than 200 days
Any storage buckets that have a Delete action but no 'age' specified
Any storage buckets that do NOT have a Delete action

exemptions identifies the Storage buckets to exempt from retention restriction.

NOTE: Add values for both minimum_retention_days and maximum_retention_days to define a range of days that the resource retention should be within.

E.g. minimum_retention_days: 100 and maximum_retention_days: 200 will generate violations for -->

Any storage buckets that have a retention less than 100 days
Any storage buckets that have a retention greater than 200 days
Any storage buckets that have a Delete action but no 'age' specified
Any storage buckets that do NOT have a Delete action
Any storage buckets whose difference between now and its 'createdBefore' condition is less than 100 days
Any storage buckets where 'numNewerVersions' is 0 or does NOT exist

Also included in this PR:

Sample constraint
Tests

@briantkennedy Thanks for the review! I've reformatted some of the code (have moved all of the checks into an if-else to account for when there are multiple violations that can be found in a resource and return the first violation) and added more tests. PTAL.


folder starting with ./ is not found in search

Type: Bug
I have recorded the 1-minute video to show the bug: https://streamable.com/7ga23a
VS Code version: Code 1.88.0 (5c3e652f63e798a5ac2f31ffd0d863669328dc4c, 2024-04-03T13:26:18.741Z)
OS version: Windows_NT x64 10.0.22631
Modes:

System Info

Item
Value

CPUs
AMD Ryzen 7 5800H with Radeon Graphics          (16 x 3194)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: enabled_ondirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_graphite: disabled_offvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: enabled

Load (avg)
undefined

Memory (System)
31.41GB (13.35GB free)

Process Argv
C:\Users\iuzeri\Desktop\New folder\app\myws.code-workspace --crash-reporter-id 882bc285-0263-4033-b4e8-7c8dfd94e0d3

Screen Reader
no

VM
0%

Extensions (32)

Extension
Author (truncated)
Version

vscode-intelephense-client
bme
1.10.4

vscode-eslint
dba
2.4.4

gitlens
eam
14.9.0

prettier-vscode
esb
10.4.0

copilot
Git
1.178.0

remotehub
Git
0.62.0

vscode-favorites
how
1.11.0

vscode-docker
ms-
1.29.0

csdevkit
ms-
1.4.29

csharp
ms-
2.23.15

vscode-dotnet-runtime
ms-
2.0.3

vscodeintellicode-csharp
ms-
2.0.25

debugpy
ms-
2024.4.0

isort
ms-
2023.10.1

python
ms-
2024.4.0

vscode-pylance
ms-
2024.4.1

remote-ssh
ms-
0.110.1

remote-ssh-edit
ms-
0.86.0

remote-wsl
ms-
0.88.0

vscode-remote-extensionpack
ms-
0.25.0

remote-explorer
ms-
0.4.3

remote-repositories
ms-
0.40.0

remote-server
ms-
1.5.1

vscode-typescript-next
ms-
5.5.20240408

tortoisegit-buttons-in-vscode
Puv
0.1.37

action-buttons
seu
1.2.2

vscode-stylelint
sty
1.4.0

intellicode-api-usage-examples
Vis
0.2.8

vscodeintellicode
Vis
1.3.1

volar
Vue
2.0.10

php-debug
xde
1.34.0

php-pack
xde
1.0.3

A/B Experiments
vsliv368cf:30146710
vspor879:30202332
vspor708:30202333
vspor363:30204092
vscorecescf:30445987
vscod805cf:30301675
binariesv615:30325510
vsaa593cf:30376535
py29gd2263:30899288
c4g48928:30535728
azure-dev_surveyone:30548225
962ge761:30959799
pythongtdpath:30769146
welcomedialogc:30910334
pythonidxpt:30866567
pythonnoceb:30805159
asynctok:30898717
pythontestfixt:30902429
pythonregdiag2:30936856
pyreplss1:30897532
pythonmypyd1:30879173
pythoncet0:30885854
2e7ec940:31000449
pythontbext0:30879054
accentitlementst:30995554
dsvsc016:30899300
dsvsc017:30899301
dsvsc018:30899302
cppperfnew:31000557
d34g3935:30971562
fegfb526:30981948
bg6jg535:30979843
ccp2r3:30993541
dsvsc020:30976470
pythonait:31006305
gee8j676:31009558
dsvsc021:30996838
gd77d436:30999572

I cannot access the link that you provided.
Does the filename itself include ./? We use this to indicate that you're searching in a particular root in a multi-root workspace. What is the use case in having these characters in the files to include?

dang, streamable deletes files quickly if not registered. here uploaded again: https://www.dropbox.com/scl/fi/zufy5opdzopewfuywfx4x/Code_g3hTVTnuke.mp4?rlkey=rmwwtzf4udh4iokx0zbpxop1t&dl=0

When you save as a workspace, searches should be prefixed by the workspace name. In your case, it would be ./app/src. This is because there could be multiple workspaces open.

but it is very unintuitive, how could user guess that they need to prefix with workspace name? in error message, it might be added, or even vscode automatically understand that by ./src user means that folder (if vscode doesnt find "multiple workspaces" there)

Unfortunately, we approach this situation using the same logic as a multi-root scenario. In the case where somebody adds/removes workspace roots, we want consistent behavior.

at least, there could have been some hint or whatever, so users could know that they need to input workspace name. at least, VScode could detect if only one workspace is open, and if user enters some dir there, popup/hint could be shown like "Hey, we found ./src folder but probably you missed to input workspace name in front" (just imitation, you can sentence it better) instead of "./src directory not found" so many users like me wont search for this. from now I know, but i say just for the sake of other users


Update XCode to 14.3 in ci.

Update XCode to version 14.3 in the below repos:

[ ] flutter/flutter
[ ] flutter/engine
[ ] flutter/packages

closing in favor of https://github.com/flutter/flutter/issues/125814


Ordered forge

Added an option to forge to output ordered according to the entities given.

This will partly address #300, and close #230

Ran some test on the command line now and --ordered seems to work like a charm :+1:

Totally forgot that I hadn't yet merged that. Thanks for the final review.


Add a license

Hi @boyuanliuoptics! I am interested in using this code for a research project.
Would it be possible to add a LICENSE file to this repository? See this page for help choosing a license: https://choosealicense.com/
I would recommend a permissive license like MIT or BSD-3 Clause. (I will also cite your paper, of course!)

Hi @boyuanliuoptics, just wanted to update this issue: I have developed a Python port of the Scheme/MATLAB code. I would like to make a pull request to add it to this repository as an open-source contribution. I would be happy to make a PR to this repository once an open-source LICENSE file exists. Thank you again! 👍

Hi @boyuanliuoptics, just wanted to update this issue: I have developed a Python port of the Scheme/MATLAB code. I would like to make a pull request to add it to this repository as an open-source contribution. I would be happy to make a PR to this repository once an open-source LICENSE file exists. Thank you again! 👍

Hi @bdice , glad to know your interest on this work and thanks for citing our work! I will add an open-source license soon. Sorry for responding late. I have updated my email address. If you have any questions about the code you can also email me.

Hi @bdice , glad to know your interest on this work and thanks for citing our work! I will add an open-source license soon. Sorry for responding late. I have updated my email address. If you have any questions about the code you can also email me.


no-md5 build fails

Type:
Build error
Description:
when configuring openssl with:
"./config shared no-ssl3 no-ssl2 nocamellia no-rc2 no-rc4 no-asm no-mdc2 no-idea no-hw no-rc5 no- des --openssldir=/tmp/test"
make depend error
because "MD5.h" include in d1_clnt.c d1_srvr.c ti_enc.c s3_cbc.c s3_enc.c s3_lib.c s3_clnt.c
Reproduce :
$ ./config shared no-ssl3 no-ssl2 nocamellia no-rc2 no-rc4 no-asm no-mdc2 no-idea no-hw no-rc5 no- des --openssldir=/tmp/test

$ make depend

Failure message:

making depend in crypto/cmac...
make[2]: Entering directory `/proj/mtk16317/1701_panasonic/apollo/oss/source/openssl/1.0.2o/openssl-1.0.2o/crypto/cmac'
../../util/domd ../.. -MD gcc -- -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -O3 -Wall -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -DOPENSSL_NO_DEPRECATED -DOPENSSL_NO_CAMELLIA -DOPENSSL_NO_DES -DOPENSSL_NO_EC_NISTP_64_GCC_128 -DOPENSSL_NO_GMP -DOPENSSL_NO_IDEA -DOPENSSL_NO_JPAKE -DOPENSSL_NO_LIBUNBOUND -DOPENSSL_NO_MD2 -DOPENSSL_NO_MD5 -DOPENSSL_NO_MDC2 -DOPENSSL_NO_RC2 -DOPENSSL_NO_RC4 -DOPENSSL_NO_RC5 -DOPENSSL_NO_RFC3779 -DOPENSSL_NO_SCTP -DOPENSSL_NO_SSL_TRACE -DOPENSSL_NO_SSL2 -DOPENSSL_NO_SSL3 -DOPENSSL_NO_STORE -DOPENSSL_NO_TLS1 -DOPENSSL_NO_UNIT_TEST -DOPENSSL_NO_WEAK_SSL_CIPHERS --  cmac.c cm_ameth.c cm_pmeth.c
make[2]: Leaving directory `/proj/mtk16317/1701_panasonic/apollo/oss/source/openssl/1.0.2o/openssl-1.0.2o/crypto/cmac'
make[1]: Leaving directory `/proj/mtk16317/1701_panasonic/apollo/oss/source/openssl/1.0.2o/openssl-1.0.2o/crypto'
making depend in ssl...
make[1]: Entering directory `/proj/mtk16317/1701_panasonic/apollo/oss/source/openssl/1.0.2o/openssl-1.0.2o/ssl'
In file included from s3_srvr.c:171:0:
../include/openssl/md5.h:70:4: error: #error MD5 is disabled.
 #  error MD5 is disabled.
    ^
In file included from s3_clnt.c:158:0:
../include/openssl/md5.h:70:4: error: #error MD5 is disabled.
 #  error MD5 is disabled.
    ^
In file included from s3_lib.c:155:0:
../include/openssl/md5.h:70:4: error: #error MD5 is disabled.
 #  error MD5 is disabled.
    ^
In file included from s3_enc.c:141:0:
../include/openssl/md5.h:70:4: error: #error MD5 is disabled.
 #  error MD5 is disabled.
    ^
In file included from s3_cbc.c:59:0:
../include/openssl/md5.h:70:4: error: #error MD5 is disabled.
 #  error MD5 is disabled.
    ^
In file included from t1_enc.c:145:0:
../include/openssl/md5.h:70:4: error: #error MD5 is disabled.
 #  error MD5 is disabled.
    ^
In file included from d1_srvr.c:123:0:
../include/openssl/md5.h:70:4: error: #error MD5 is disabled.
 #  error MD5 is disabled.
    ^
In file included from d1_clnt.c:125:0:
../include/openssl/md5.h:70:4: error: #error MD5 is disabled.
 #  error MD5 is disabled.
    ^
make[1]: *** [local_depend] Error 1
make[1]: Leaving directory `/proj/mtk16317/1701_panasonic/apollo/oss/source/openssl/1.0.2o/openssl-1.0.2o/ssl'
make: *** [depend] Error 1

So, you get this even though you don't supply "no-md5" on the config line?
Using your config line (correcting "nocamellia" and "no- des" which I assume are typos) I don't see this problem.  make depend works just fine for me. Is this is a fresh, clean source directory? Or have you done other builds in it previously?

I can't even reproduce this when adding no-md5, instead I get:
s3_srvr.c: In function 'ssl3_send_server_key_exchange':
s3_srvr.c:1609:26: error: 'MD5_DIGEST_LENGTH' undeclared (first use in this function)
     unsigned char md_buf[MD5_DIGEST_LENGTH + SHA_DIGEST_LENGTH];

(Tested using the current OpenSSL_1_0_2-stable)
It's just not possible to build libssl without md5 support. Just don't add no-md5. I'm closing this.


Dummy Functions for Touchscreen

Add "dummy" functions (that pass or return a constant value) to your library, to set up and use the basic functionality of this part.

[x] Determine what basic functionality will be necessary to easily control touchscreen
[x] Set up dummy functions in Smart_Breadboard.py
[x] Run dummy functions in demo.py to confirm nothing has broken functionality

(1/2 hour)

Reccomended functions to set up by professor Fund:

[ ] setup()
[ ] clear_screen()
[ ] send_text_to_screen()
[ ] send_image_to_screen()

Added setupDisplay in commit 84d0d22

Added dummy functions for the display. Running the demo.py file gave no errors.

@creechelseaa please review


Split points into Points and BasePoints in preparation for Graph layer

References and relevant issues
This PR is a precursor to implementing the GraphLayer - see #5861 for a WIP on the graph layer itself.
Description
In discussions during the Graph Layer working group we found that getting the PR close to review was very challenging due to frequent merge conflicts with the Points layer, which were not trivial to resolve because that PR currently makes the split you see in this PR. We therefore decided to bring this change into its own PR.
This PR therefore splits the current Points layer functionality into a _BasePoints and Points layer. This allows the GraphLayer to reuse this code to represent its nodes.
Summary of Key Changes:
data and _points_data
Previously, the list of point coordinates lived at Points.data and self.data was used throughout Points as needed. In this PR, _BasePoints uses a new property, _points_data for all implemented methods.
Points overrides this property to return self.data. This means everything that's in the base class works via _points_data, and can be reused by Graph, but Points still keeps its public API and data setters mostly the same.
_BasePoints.data getter, _BasePoints._points_data and _BasePoints._set_data are all abstract. The _BasePoints.data setter is fully implemented i.e. copied from Points, and Points uses it explicitly via _BasePoints.data.fset(self, data).
Other abstract methods on _BasePoints

_get_ndim: in Points it's remained the same
_make_slice_request_internal: in Points it's remained the same
add: in Points, it's remained the same. In Graph, it would still be used to add nodes but it also takes an indices argument for the nodes - so it's actually not overriding the _BasePoints add... Should we just remove add from _BasePoints entirely?
remove_selected: unchanged in Points, but I actually think we could extract some of the property updating stuff to _BasePoints maybe?
_move_points: _move (which calls _move points once it's worked out which points need moving and to where) is implemented in _BasePoints and then Points._move_points simply does the shift on the data using the given indices.

Extracted from Points to _BasePoints

_on_selection
all features stuff
style and properties stuff (border_color, face_color, text, symbol, size, etc.)
data extent/out of slice/canvas_size properties/setters
get_state/get_value/get_status
selected_data stuff - but self._selected_data is updated directly in points _paste_data
thumbnail stuff
slice stuff outside of _make_slice_request_internal

Remains in Points only
...

Please do not forget to include similar test for a new class.
https://github.com/napari/napari/blob/f66fce680632a1e9b78f73b00863f5ad8ab88d1d/napari/layers/points/_tests/test_points.py#L2660-L2663


Documentation

For general purposes regarding Margarine and his code. Not a major priority on the list however, it is always good to have a place for FAQs and general questions. Will also consist of a guide on how to self-host the code if the person so wishes to.

Changed to documentation in case I feel inspired to make webpages for it.

Removing this out of a Beta 0.9 release as I'm focusing on getting this version out of development.


scroll bar

How to display a scroll bar for large number of records.

It's currently not possible. You'll have to contribute it yourself if you want it.

This is exactly what i want.

i modified some codes, and it works fine now.

I know this is old but it can help other people.
To add a scrollbar simply add the following to your CSS:
.dropdown-menu {
max-height: 350px;
}
When there are more items (can be limited by search-limit) then the available 350px a scrollbar will be added.


WIP: Bump kernel 5.10.186

That's cool. Thanks for doing that. Don't forget to compile on ARM :)
Ping me once that is finished, I will prepare the backport for the LTS branches.


Adapted parallel::{all_of|any_of|none_of} for Ranges TS (see #1668)

Add projection function to all_of, any_of, none_of
Add range version of the above functions (#1668)
corresponding tests

@brjsp our circleci testing infrastructure reports errors from the newly added tests, would you mind fixing those (https://circleci.com/gh/STEllAR-GROUP/hpx/8551)?

should be OK now

@brjsp sadly it's not ok yet. Would you mind to have a look again?

should be ok now

@brjsp yes, compilation errors are gone now, however inspect is still unhappy: https://8587-4455628-gh.circle-artifacts.com/0/tmp/circle-artifacts.6IoAkhH/hpx_inspect_report.html

Congrats @brjsp on your first pull request! Are you interested in receiving a STE||AR Group T-Shirt?


BUG: RegularGridInterpolator error message is wrong

Describe your issue.
The regularGridInterpolator checks that the data to be interpolated has the same dimensions as the reference data points.
However if that checks fails, the error message reports the wrong dimensions:
In scipy/interpolate/_rgi.py at line 303
        xi = _ndim_coords_from_arrays(xi, ndim=ndim)
        if xi.shape[-1] != len(self.grid):
            raise ValueError("The requested sample points xi have dimension "
                             "%d, but this RegularGridInterpolator has "
                             "dimension %d" % (xi.shape[1], ndim))

Last line should be
 "dimension %d" % (xi.shape[-1], ndim))
Since the check is on dimension -1, and the number of dimensions of the points to be interpolated is indeed xi.shape[-1]
Reproducing Code Example
import scipy
from scipy.interpolate import RegularGridInterpolator
data=[[[1.]]]
x=[0]
y=[0]
z=[0]
my_interpolating_function = RegularGridInterpolator((x, y, z), data,bounds_error=False)

my_interpolating_function([[[0.1,0.2]]])

Error message
Traceback (most recent call last):

  File "/tmp/ipykernel_9436/4103262667.py", line 9, in <module>
    my_interpolating_function([[[0.1,0.2]]])

  File "/home/clement/.local/lib/python3.8/site-packages/scipy/interpolate/_interpolate.py", line 2517, in __call__
    raise ValueError("The requested sample points xi have dimension "

ValueError: The requested sample points xi have dimension 1, but this RegularGridInterpolator has dimension 3

SciPy/NumPy/Python version information
1.8.1 1.21.4 sys.version_info(major=3, minor=8, micro=10, releaselevel='final', serial=0

Would you be interested in submitting a PR with a fix @cm7S ?

Sure thing!

From: Evgeni Burovski @.>
Sent: Thursday, June 9, 2022 6:31 PM
To: scipy/scipy @.>
Cc: Clement Marti @.>; Mention @.>
Subject: Re: [scipy/scipy] BUG: RegularGridInterpolator error message is wrong (Issue #16380)
Would you be interested in submitting a PR with a fix @cm7Shttps://github.com/cm7S ?
—
Reply to this email directly, view it on GitHubhttps://github.com/scipy/scipy/issues/16380#issuecomment-1151350969, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AZR3HPTHUIVBS552MTZDWX3VOIL4TANCNFSM5YKIPDYQ.
You are receiving this because you were mentioned.Message ID: @.***>


OSC output on the Quest

Describe the bug
OSC reset on Quest version don't generate .json file on the Quest (/mnt/sdcard/Android/data/com.vrchat.oculus.quest/files/OSC/usr_xxxx/Avatars/ folder) in contrary to pc version generating json (in C:\Users\xxxx\AppData\LocalLow\VRChat\VRChat\OSC\usr_xxxx\Avatars folder)
adb show empty folder, moreover only the "/avatar/change" are sent to localhost:9001:udp, all others parameters dropped, even if valid json is created manually with some parameters.

I have encountered the same problem! Any chance that this can be fixed?

Curiously, @momo-the-monster has mentioned in https://github.com/vrchat-community/osc/issues/45 that OSC output on the Quest should be fixed, but that doesn't seem to be the case...

@Spacechild1 OSC output on quest was broken a month ago. It was fixed last week, and I believe that is included in the current open beta.

OSC output is not yet supporter on the Quest. We removed a bug where OSC output was mistakenly trying to send and causing an exception.
OSC output will be enabled once we have a way to specify the target IP and Port.

@momo-the-monster I've build an embedded C program on the quest to listen on UDP port and data are sended by vrchat, but only the /avatar/change event. The easy way to specify target IP and port could be an OSC command.

@Romaxx Ha, and I've written an Android service that listens on port 9001 and forwards the packets to my PC.
@Spacechild1 ok and what's the results ? do you receive OSC Data other than /avatar/change event ?

 That's what I meant with "same problem" :-)

Hi, I haven't gotten any OSC messges from the avatar on the Quest. (tested in my PC and no problem receiving OSC message)
I even didn't get /avatar/change (enabeld OSC in the VRChat setting)
Any update on this issue???

bump

@momo-the-monster Is there any timeline on when those options are going to be added?
I am using a Termux running locally and being able to send data into VRChat is great but not being able to get any data out of VRChat on device is very frustrating.
If there is no timeline to add this option a work around would be appreciated. I understand the hesitancy of spamming a local port 9001 which might be used by a different app and being unable to turn this off.
Here are some suggestions to lessen that risk or ideas usably as a workaround:

randomly pick a standard port at the far end of the port range (e.g. 16783 ) unlikely to collide with anything
spin up server listening on 9002 just like there is a server on 9000. UDP is a datagram protocol, there is no notion of sessions or server/client.  Programs connecting to port 9002 will receive messages meant for an OSC server. This is an "inverted" OSC conncetion and not directly compatible with other OSC software. This will not work with another server directly. But it is trivial to build an program which connects to the 9002 and a proper server on 9001 as clients on both ends and forwards the messages. This program could also run on machine which has access to port 9002 on the Quest. This way no host port for the server have to be specified to VRChat because the double sided client needs this information not VRChat.
read field of the player character just as a note field for host and port info.
just point it to localhost:9001 and have the user deal with it. Android devices usually don't run 3 dozens of servers many and if so those apps will not work while OSC is turned on.

I am asking VRChat to consider any of there possiblities. As any of these is better than the current implementation.

@momo-the-monster
is there anyway to mod to get osc out?
@Spacechild1 are you able to show how you got osc out of quest?


Sigma-Aldrich: Group paragraph elements or subsections together into a single HierarchyNode

Currently, due to setting minimum line spacing, certain real paragraphs are split up. For example:
" ... "
        {
          "title": "OTHER_OTHER",
          "items": [],
          "raw_title": "The branding on the header and/or footer of this document may temporarily not visually \n"
        },
        {
          "title": "OTHER_OTHER",
          "items": [],
          "raw_title": "match the product purchased as we transition our branding. However, all of the \n"
        },
        {
          "title": "OTHER_OTHER",
          "items": [],
          "raw_title": "information in the document regarding the product remains unchanged and matches the \n"
        },
        {
          "title": "OTHER_OTHER",
          "items": [],
          "raw_title": "product ordered. For further information please contact<EMAIL_ADDRESS>\n"
        },
" ... "

Should be processed into one subsection with a TEXT item inside:
" ... "
        {
          "title": "OTHER_OTHER",
          "items": [
            {
              "type": "TEXT",
              "data": "The branding on the header and/or footer of this document may temporarily not visually match the product purchased as we transition our branding. However, all of the information in the document regarding the product remains unchanged and matches the product ordered. For further information please contact<EMAIL_ADDRESS>            },
          ]
        },
" ... "

I'm thinking of possibly solving this problem by avoiding it altogether. There's somewhat of a pattern for when certain subsections are marked with boldface or not.
Maybe if we can detect start and ends of subsections through those methods, we could just treat all lines under that group as a single paragraph. Would require some modification of the initial hierarchy generator though, so I'm likely going to look at solving other problems for now.


Link to simulateddevice is broken

On the page for Creating and connecting a Node-RED device simulator step 1.e., there is a reference to http://simulatedDevice.mybluemix.net from where you could download a Node-RED flow - however the link is broken.

@ekstrom-ibm The http://simulatedDevice.mybluemix.net link is an example of what the Node-RED link might look like, and is not an active link. The link will differ depending on the name that you gave Node-RED when you instantiated it. The documentation is a little unclear, and will be improved.

e. Click the app link at the top of the page to open Node-RED.
Example: http://simulatedDevice.mybluemix.net

Thanks - that was a clarification for a newbie.

Text was updated a while back:

Click the Routes link to open Node-RED.
Example: http://simulatedDevice.mybluemix.net


Handle uppercase letters in imported data column names

Column names in imported data are normalized as lower-case identifiers by removing upper case letters and other characters, then adding numerical suffixes if necessary to avoid name collisions. For example, when importing a table with columns ID_X, ID_Y, IC_gral they get renamed as _, _1, _gral.
It would be nicer to preserve uppercase letters by converting them to lowercase, but changing this behaviour for existing import sources may break user cases in use.
For new sources, e.g. the BQ connector, we could change it without risk of breaking anything, but it might not be easy (is the name change part of cartodbfication?).
In any case there are some questions I think we should consider for discussion:

Should be change this behaviour globally (and hope we don't break too many cases)
Are uppercase letters common in BQ column names? (same for other data sources)

cc @alejandrohall @alonsogarciapablo @ilbambino
note that a table with all columns in uppercase would be imported as _, _1, _2, _3, ... which is very unfortunate.

AFAIK The column name normalization is part of the Import API, but also part of the import process with COPY in CARTOframes.
I wasn't aware we were dropping uppercase letters... See this and this, so maybe we have a bug somewhere.
How can we reproduce the issue?

I've checked and the loss of the capital letters occurs not in the cartodbfication nor in odbc_fdw. So it must be in the import api, perhaps related to the db connectors.

The problem seems to be here:
https://github.com/CartoDB/cartodb/blob/5b1a8a55b13ac11a5229f0511a5d5ea14f356f0a/app/models/table.rb#L1347-L1348
This is executed when a new Table is created for an existing table; which is performed through TableRegistrar by the data imports.
I think it would be nice to replace the gsub(/[^a-z0-9]/,'_') by StringSanitizer#sanitize which converts to downcase and also transliterates non-ASCII letters to a-z:
CartoDB::Importer2::StringSanitizer.new.sanitize('aAÁäÂ') # => "aaaaa"

We're already using StringSanitizer in Column to sanitize geometry column names (in the importer Georeferencer).
I think the greatest risk of breaking things with this change would be with existing sync tables, because column names would change for existing tables.
We could add a rollbar trace for syncs that  have [^a-z0-9] characters in the column names (before registration) and run it for some days before deciding about doing the change.
Another option would be to only change the sanitization for new import types (like the BQ connector) to avoid affecting existing syncs, by sanitizing column names before table registration, but I don't like having such difference between import methods.

Thanks for the research @jgoizueta
That sounds like a plan 👍

There are some changes of mine that already modified sanitization of col names:
https://github.com/CartoDB/cartodb/pull/14937/files
I couldn't reproduce the issue with a regular import, so obviously there's yet a mismatch between imports and syncs, which is unfortunate :(

By instrumenting the code and reproducing the case I figured that it does something like (in pseudo code) importer->run->register->table_registrar->register->table->before_create->sanitize_columns->ensure_column_has_valid_name.
So I don't really get why it affects DB Connectors but no regular imports. I suspect ogr2ogr may have something to do here.

The patch:
diff --git a/app/models/table.rb b/app/models/table.rb
index 16e3f30f9b..b1099a38c4 100644
--- a/app/models/table.rb
+++ b/app/models/table.rb
@@ -1329,6 +1329,9 @@ class Table

     valid_column_name = get_valid_column_name(table_name, column_name, options)
     if valid_column_name != column_name
+      puts "<RTORRE>"
+      puts Thread.current.backtrace.join("\n")
+      puts "<\RTORRE>"
       connection.run(%Q{ALTER TABLE "#{database_schema}"."#{table_name}" RENAME COLUMN "#{column_name}" TO "#{valid_column_name}";})
     end

The trace I got (cleaned up of framework hooks and beautified):
cartodb/app/models/table.rb:1333:in `ensure_column_has_valid_name'
cartodb/app/models/table.rb:1313:in `block in sanitize_columns'
cartodb/app/models/table.rb:1310:in `each'
cartodb/app/models/table.rb:1310:in `sanitize_columns'
cartodb/app/models/table.rb:230:in `import_to_cartodb'
cartodb/app/models/table.rb:336:in `before_create'
cartodb/app/models/carto/user_table.rb:281:in `service_before_create'
cartodb/app/models/table.rb:79:in `save'
cartodb/app/models/table_registrar.rb:16:in `register'
cartodb/app/connectors/importer.rb:266:in `persist_metadata'
cartodb/app/connectors/importer.rb:118:in `register'
cartodb/app/connectors/importer.rb:90:in `block (2 levels) in register_results'
cartodb/app/connectors/importer.rb:89:in `each'
cartodb/app/connectors/importer.rb:89:in `block in register_results'
cartodb/lib/carto/ghost_tables_manager.rb:54:in `block in run_synchronized'
cartodb/lib/carto/bolt.rb:27:in `run_locked'
cartodb/lib/carto/ghost_tables_manager.rb:53:in `run_synchronized'
cartodb/app/connectors/importer.rb:83:in `register_results'
cartodb/app/connectors/importer.rb:73:in `run'
cartodb/app/models/data_import.rb:851:in `execute_importer'
cartodb/app/models/data_import.rb:440:in `dispatch'
cartodb/app/models/data_import.rb:188:in `run_import!'
cartodb/lib/resque/importer_jobs.rb:8:in `block in perform'
cartodb/lib/resque/base_job.rb:19:in `run_action'
cartodb/lib/resque/importer_jobs.rb:8:in `perform'

Column names are usually converted to lowercase when they go through ogr2ogr, but it is because of the way PG works. E.g:
test=# CREATE TABLE capital_column_names (id int, OtherColumn varchar);
CREATE TABLE
test=# \d capital_column_names
               Table "public.capital_column_names"
   Column    |       Type        | Collation | Nullable | Default
-------------+-------------------+-----------+----------+---------
 id          | integer           |           |          |
 othercolumn | character varying |           |          |

vs
test=# CREATE TABLE capital_column_names_for_real (id int, "OtherColumn" varchar);
CREATE TABLE
test=# \d capital_column_names_for_real
           Table "public.capital_column_names_for_real"
   Column    |       Type        | Collation | Nullable | Default
-------------+-------------------+-----------+----------+---------
 id          | integer           |           |          |
 OtherColumn | character varying |           |          |

(mind that column names like that one have to be quoted to operate with them)

ogr2ogr still has something to do:
https://gdal.org/drivers/vector/pg.html

LAUNDER: This may be “YES” to force new fields created on this layer to have their field names “laundered” into a form more compatible with PostgreSQL. This converts to lower case and converts some special characters like “-” and “#” to “_”. If “NO” exact names are preserved. The default value is “YES”. If enabled the table (layer) name will also be laundered.

(we're using LAUNDER defaulting to YES and to me it turns out a bad idea to start setting it to NO at this point)
This shouldn't affect much this issue, it just makes it harder to figure out, reproduce and test because of the many moving parts with different behaviors.

Being pragmatic, a possible fix (not the best but good enough): https://github.com/CartoDB/cartodb/pull/15252

This PR just adds a warning but does not perform any actual change: https://github.com/CartoDB/cartodb/pull/15253

There are many such instances of Differences in column name sanitization/normalization. See rollbar, #40477

I see a few problems with this approach (in order of difficulty to solve):

There are affected syncs, by inspecting the backtraces from the traces. They will be broken unless we add extra logic.
That sanitization produces wrong identifiers, starting with leading numbers. E.g: 10__name
It does not account for collisions in column names.

I'm reverting the PR to add the traces, as it easily produces 6K log entries/day (one per column-sync).

Many of the cases are due not to capitals but to multiple underscores vs single underscore, but there's a good number of capitals lost too. Interesting data. The problem is worse I had anticipated: many syncs would be affected by the change.
We could change the behaviour only for new connector providers or only for syncs created since some date, but I found it cumbersome.

Some public-facing documentation on the topic:

https://carto.com/developers/import-api/guides/column-names-normalization/
https://github.com/CartoDB/cartodb/blob/master/doc/developer-center/import-api/guides/09-column-names-normalization.md

I was wrong about Column using StringSanitizer (there's a method #sanitize but is not used; Column is used by Georeferencer but not the sanitize method), and the whole sanitization picture is more complicated in our current database, but I've take a deep look into it and have survived to tell you about.
The problem
Imported and synced tables have Table.sanitize_columns called on the new tables which eliminates uppercase and special letters.
For file imports this has no effect because ogr2ogr already converted column names to downcase.
For tables created manually (SQL API) and cartodbfied this is not executed when the table is registered, so they can have uppercase letters, etc. in the column names.
The detailed process:

Imported tables: DataImport#run (dispatch/new_importer/new_importer_with_connecto etc)
uses a TableRegistrar object to create a Table (setting migrate_existing_table;
the presence of it in Table#before_create makes it call Table.sanitize_columns).
Sync tables: no new UserTable record created so before_create is not called,
but Synchronization::Adapter#run calls explicitly (twice) Table.sanitize_columns`` (before cartodbfication through #import_cleanupand after through#setup_table`)
Manually cartodbfied tables are registered by GTM, table is created without migrate_existing_table, so no sanitization.
Special imports (table_copy, from_query) call Table.sanitize_columns explicitly (from DataImport#from_table).

Proposed Versioning Implementation
Let's assume we already have some method that applies normalization for any version that will replace Table.sanitize_columns: (I'm using normalization here but we may end up calling it sanitization or some other nonsense)
module ColumnNormalization
  INITIAL_NORMALIZATION = 0
  CURRENT_NORMALIZATION = 1
  def self.normalize_columns(table_name, version=CURRENT_NORMALIZATION)
    # ...
  end
end

In all cases except for manually created tables (i.e. all cases that sanitize columns) the UserTable register has a non NULL data_import_id. We can use the DataImport record to store the kind of normalization performed (using the extra_options JSON field) so that if the table is syncronized,
the same normalization can be applied to newly imported data.
class DataImport
  attr_setter :normalization
  def before_create
    # ... (keep existing before create stuff here)
    self.normalization ||= ColumnNormalization::CURRENT_NORMALIZATION
    self.extra_options.merge! normalization: normalization
  end
  def applied_normalization
    extra_options[:normalizatio] || ColumnNormalization::INITIAL_NORMALIZATION
  end
end

Normalization can be applied through a Table instance method:
class Table
  # Use without arguments to normalize the registered table,
  # use with a different table name to apply the same normalization
  # to other (unregistered) table
  def normalize_columns(table_name=name)
    if data_import
      version = data_import.applied_normalization
      ColumnNormalization.normalize_columns(table_name, version)
    end
  end
end

Now, Table#import_to_cartodb (called on Table creation for imported tables) should
call the new instance mehod (self.normalize_columns) without arguments instead of Table.sanitize_columns.
Synchronizations (Adapter) must call table.normalize(result.table_name)
with table = ::Table.new(name: @table_name, user_id: @user.id) or @user.tables.where(name: @table_name).
We're doing an additional query to get the Table here, which is done also in other places like TableSetup. In the Synchronization::Member class this operation is available and memoized, but not in Adapter. We could refactor to avoid multiple queries for this. (note that putting the data import or version reference in the synchronizations table would not save doing the query at least once).
Then we should make Table#add_column! and  #modify_column! consistent with the new normalization and change to call #normalize_columns on self insteald of the String methods used now.
Internally the normalization implementation used in ColumnNormalization could use the String methods, or, better, StringSanitizer which should probably replace all use of the String methods and perhaps be integraged in DB::Sanitize.
The idea is having a single source for (low level) sanitization (e.g. DB::Sanitize) then versioned
sanitization provided through Table.
Note normalization should also handle reserved words/column names which is done inconsistently now.

[ ] Unified sanitatization: Remove Column & String sanitization methods,
move into DB::Sanitize? Remove reserved words redundancy/inconsistency
[ ] Implement versioned normalization module
[ ] Implement per data-import versioned normalization
[ ] Add tests
[ ] Add documentation

Details
The method Table.sanitize_columns is used in:

DataImport#from_table in turn from DataImport#dispatch (for table copy & query imports)
and passing Column::RESERVED_WORDS (!). This doesn't happen in syncs, nor user (API) imports, only
in internal imports. In any case we have the DataImport to obtain the correct version.
Table#import_to_cartodb from Table#before_create (i.e. for all registered tables)
and also from Synchronization::Adapter#setup_table.
When called from setup_table we should get the version from the DataImport corresponding to to Sync,
but it should match the table's DataImport... so..
When called from Table creation, we should have assigned a version previously to the table's data import if it exists...
[check how DataImport creates Table, to see if DI is available at construction]
Synchronization::Adapter#import_cleanup

Now Synchronization::Adapter#run uses Table.sanitize_columns twice:

Before cartodbification it calls Synchronization::Adapter#import_cleanup
After it it calls Synchronization::Adapter#setup_table

Imports call it through the Table constructor (before_create with migrate_existing_table option set by TableRegistrar) (if import uses ogr2ogr, i.e. is file-based the table will already be downcase)
Note that we have foreign keys user_tables.data_import_id and data_import.table_id, (so Table <-> DataImport navigation is possible), but we have only data_imports.synchronization_id which is not indexed so Synchronization::Member -> DataImport is not possible efficiently.
We have Synchronization::Member#table that finds the table by user and name, but there's no such thing in the Adapter (the importer).
The Adapter is instantiated with a table_name: the name of the synchronization (which is the table name) then it uses result.table_name (temp table) to normalize columns, cartodbfy, etc.
So we can't rely on Table doing the normalization with previously registered info, since we must normalize the imported table (unregistered) with info from the sync name table (registered).
Note that syncs can't handle multiple files:
https://github.com/CartoDB/cartodb/blob/9391e76933cfc4028aba3675891f32284350244d/app/models/synchronization/adapter.rb#L29-L30
Sanitation Bonanza
There's a plethora of other sanitization methods in addition to Table.sanitize_columns`
String#sanitize_column_name
It uses DB::Sanitize::RESERVED_WORDS and CartoDB::RESERVED_COLUMN_NAMES.
It calls String#sanitize -> String#normalize.
It used to be called by Migrator, but currenlty that is disabled now:
https://github.com/CartoDB/cartodb/blob/9391e76933cfc4028aba3675891f32284350244d/lib/importer/lib/cartodb-migrator/migrator.rb#L44-L46
Table#add_column! and #modify_column! use String#sanitize;
and uses Table::RESERVED_COLUMN_NAMES to rename reserved names to _xxx.
Also Table#create_table_in_database! calls String#sanitize and some rake tasks, etc.
DB::Sanitize#sanitize_identifier
It is used for table names only, not columns.
Called by APiKey#create_db_config, FDW#server_name, ValidTableNameProposer#propose_valid_table_name, ConnectorRunner#result_table_name, ...)
Uses DB::Sanitize::RESERVED_WORDS
StringSanitizer#sanitize
Is used by Column#sanitized_name (uses Column::RESERVED_WORDS).
Used by Column#sanitize which seems unused.
Other Redundancies
Two RESERVED_WORDS:

In DB::Sanitize  used by DB::Sanitize#sanitize_column_name
In Column used by DataImport#from_table and Column#sanitized_name

Two RESERVED_COLUMN_NAMES:

In CartoDB used by String#sanitize_column_name
In Table used by Table#add_column!, Table#modify_column! (the latter through rename_column)

Proposed Versioning Implementation

The trick there is that once you applied a certain version, you have to apply the same version from that moment on. That is, it needs to store the version used (or the mapping of source cols to dest cols) somewhere, along with the sync.

We can use the DataImport record to store the kind of normalization performed (using the extra_options JSON field)

Is that extra_options field persisted? is it the import_extra_options field in the data_imports table?

We could refactor to avoid multiple queries for this

I'd fix it first, avoid extra risk of refactor, then consider it

normalization should also handle reserved words/column names which is done inconsistently now.

That can be solved by quoting column names. Actually many issues can be solved that way.
https://www.postgresql.org/docs/current/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS (refer to quoted identifiers)
E.g:
postgres=# CREATE TABLE test_table("INSERT" int);
CREATE TABLE

About the plan, I'd start with the versioning and then move from there
My 2 cents

While preparing some tests cases to check the PR in staging I've noticed this:
Due to the double sanitization (before/after cartodbfication) described aboved, and the way sanitization was applied we had cases of columns that changed named after the first synchronization. 🤦♂
For example, column like XX was sanitized as __1 (throuh db connector imports). In the initial import, since theres not double sanitization in imports, it appeared as __1. But then, the first synchronization (that could happen a month after the import!) performs the double sanitizations that converts XX to __1 and then to _1. Ouch.
So, if we want to preserve the exact behaviour of existing syncs we should keep the double sanitization; but for new syncs we shouldn't (unless we make the new sanitization idempotent).

For the current state of this issue, please look at this comment in the PR: https://github.com/CartoDB/cartodb/pull/15326#issuecomment-568015817


Sqlite Operationnal Errors

need to retry sql operation on operationnal errors (that prevent two concurrent write to sqlite db).

sqlite only supported as test and dev database


Invariant Violation: ART has been removed from React Native. It can now be installed and imported from '@react-native-community/art' instead of 'react-native'

"react": "16.11.0",
"react-native": "0.62.2",

"react-native-progress":
Tried : '^3.5.0' & '^4.1.2'
Tried : 'npm start --reset-cache'
also
installed : "@react-native-community/art"
Nothing Worked!

Same issue.

Have you guys solved this?

@Aung-Myint-Thein
Not sure what's the problem!
Created a new fresh app of same version and used this library (^4.1.2) and it's working fine.
Note: Problem causes when I use <Progress.Circle> or <Progress.Pie>
(U need to install 'React Native Art' for this)
Currently I'm using only <Progress.Bar> thus no issues.

I was getting this error too until I upgraded react-native-progress from 3.5.0 to 4.1.2. Make sure to clear you node_modules and redownload dependencies.

in file Circle.js, CircleSnail.js , Pie.js,
replace ART.Surface with
import {Surface} from '@react-native-community/art';
and in file Shapes/Arc.js
import {Shape, Path} from '@react-native-community/art';
and replace the same above.

For anyone having this problem, there's a hint in the README.md

Note: If you don't want the ReactART based components and it's dependencies, do a deep require instead: import ProgressBar from 'react-native-progress/Bar';

It worked for me when all other methods failed.

Same Issue, have you guys solved this ?

this issue just on iOS and I solve with this steps

install React Native Art
running command pod install

Same issue.

did you find any solution

I'm getting this error on bundler run, and the IOS simulator is blank

Any package relies on ART will cause the issue with you , not only react-native-progress , but also packages with loaders like this react-native-loading-spinner-overlay , You can change this by finding another package of by fixing your imports
The Art library has been removed as of SDK 36 , If you need to use react-native-progress, which relies on ART, you can use the bare workflow and install @react-native-community/art, or implement your own progress indicator using Svg

"react": "16.11.0",
"react-native": "0.62.2",

"react-native-progress":
Tried : '^3.5.0' & '^4.1.2'
Tried : 'npm start --reset-cache'
also
installed : "@react-native-community/art"
Nothing Worked!

I am also facing the same issue. Is any solution on this?

@PrantikMondal
https://github.com/oblador/react-native-progress/issues/201#issuecomment-623287649
Tried this ?

@PrantikMondal
#201 (comment)
Tried this ?

Hi Aithashi, Thanks for the reply. I am not using this react-native-progress library at all.

same issue
Invariant Violation: ART has been removed from React Native. It can now be installed and imported from '@react-native-community/art' instead of 'react-native'. See https://github.com/react-native-art/art
react-native-cli: 2.0.1
react-native: 0.64.0

same issue

I was getting this error too until I upgraded react-native-progress from 3.5.0 to 4.1.2. Make sure to clear you node_modules and redownload dependencies.

Did not work for me on RN 0.64.1

A combination of what @HeffZilla and @aithashi suggested worked for me, uses the following:

Delete the node_modules folder
install "@react-native-community/art": "^1.2.0"
Upgrade this package to "react-native-progress": "^4.1.2" version
npx react-native start --reset-cache (reset the cache, otherwise NOT gonna work)
Enjoy

Hi All,
Facing this issue in RN upgrade 0.64.1  . I am using below configuration
Xcode 12.4
node 10.0
I have tried all suggestion provided in top, but no luck. Getting below error

Hi, any solution to this? I've been using https://www.npmjs.com/package/react-native-pie-chart which uses @react-native-community/art internally. I've tried all the above steps, but no luck!!

Hi, any solution to this? I've been using https://www.npmjs.com/package/react-native-pie-chart which uses @react-native-community/art internally. I've tried all the above steps, but no luck!!

@yogendrajs
https://github.com/oblador/react-native-progress/issues/201#issuecomment-842263220 This should work as per my knowledge (But I have not tried with RN 0.64+)

@aithashi thanks for the response. I've tried this & everything that's listed down here, but couldn't make it to work. Do you have any other possible workaround?

@ghasemikasra39  answer worked for me as well. I'm using RN 0.65.0

@IM-CrazyDeveloper @rayashi did you find a fix?