[Feature][Hbase] Implement Hbase connector catalog and typeconverter

Search before asking

[X] I had searched in the feature and found no similar feature requirement.

Description
Implement Hbase connector catalog and typeconverter
next work for https://github.com/apache/seatunnel/pull/6348
Usage Scenario
No response
Related issues
No response
Are you willing to submit a PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

@Hisoka-X Is this issue still being processed? If not, you can assign it to me
cc @TaoZex


✨ Brave history

This plugin will parse your Brave browser history and add it to the bottom of the centerpiece search list. This should give a nice fallback in case no other plugin entries match your search. Furthermore, this is another step on making the omnibox in your browser obsolete :blush:.
The list of history entries is sorted by the number of visits to a page followed by the last visit to a page.
This resolves #24.


[Improvement]: Can't infer the dependently-typed inside the query expression

Description
Here foo is a SQL connector.
Employee[] employees = check from var emp in foo->query(`SELECT * FROM employees`) select emp;

and it gives cannot infer type for parameter 'rowType'
Describe your problem(s)
No response
Describe your solution(s)
No response
Related area
-> Compilation
Related issue(s) (optional)
No response
Suggested label(s) (optional)
No response
Suggested assignee(s) (optional)
No response

Spec issue: https://github.com/ballerina-platform/ballerina-spec/issues/1208

We are closing this issue since this is tracked in the spec.


Dropzone not working

Trying to upload a new image in Image block, the upload button doesn't work.
I think it's related to lazy loading of libraries.

also trying to upload multiple items with ContentUploadModal is not working

@tiberiuichim any ideas?

it was my browser, sorry


fix bug of #3917. Ignore order difference when compares the domain spec of the current and the loaded domain

fix bug of #3917, Ignore order difference when compares the domain spec of the current and
the loaded domain.
Proposed changes:
-It shouldn't raise except when the domain spec of the current and
the loaded domain is same but with different order. Change the two list as set the ignore the order difference when compares them.
Status (please check what you already did):

[x] made PR ready for code review
[ ] added some tests for the functionality
[ ] updated the documentation
[ ] updated the changelog
[x] reformat files using black (please check Readme for instructions)

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


added spec for multi network support; fixed minor typos;

added support for multiple Ethereum networks; fixed minor typos;

Why not use chainID instead of a string name? Seems like that would be more flexible. Checkout this list of chainids for different EVM networks: https://chainid.network/

I guess both options could work.
A usecase (although not really advisable) for using strings instead of chainID is the ability to have multiple registries in the same chain.

@oed @mirceanis is the short name in the registry unique? Another point why using the registry might not be enough is because we are going to support permissioned Quorum-based networks as well which might not be added to the registry. But a hybrid of short name + handling for such systems + handling for potential registries per network might work.

@awoie The Quorum based networks still needs to have a unique chainId in order to prevent reply attacks as I mentioned yesterday. So even if they are not in the registry it should be fine. But I think you should investigate before you start maintaining your own separate registry for basically the same thing 🙂

@oed As far as I understood, just because there is a registry, nobody prevents a Quorum-based blockchain from using an already registered chainId, right? These are basically private networks.

Yeah there isn't any enforcement. But if they did it's probably a really bad idea since it enables replay attacks. If they are not aware of this it's a real problem.

@oed I agree that this will be a good idea but there won't be a guarantee that private/permissioned networks, e.g., based on Quorum, will find its way into the registry. If they don't share any state with other networks such as the public Ethereum mainnet, then they could manage their replay protection internally within their consortium by allocating their own chain IDs, potentially having clashes with chainid.network.
Anyways, it is not the intention of the did:ethr spec to come up with an exhaustive list of chain IDs. The did:ethr community/implementers of the spec will need to specify the target ERC1056 registry per network in the resolver implementation to allow others to resolve did:ethr: DIDs.
I'm in favour of the string notation because it is more verbose. It would be great if we could use "short name" (if unique) anyways for chainid.network chains, e.g., did:ethr::0xab. If we want to support multiple ERC1056 registries per network, then this could be done by amending the did:ethr by another discriminator, e.g., did:ethr:[-]. If a private/permissioned network ignores the registry, then we could just add another discriminator for chains outside of the chainid.network universe.
@oed @mirceanis thoughts?

The way I see it, these 2 methods of wrapping an address into a DID do not exclude each other, and this is more of a matter of configuration.
Using config of the resolver it is already possible to wrap an address into a DID on different chains and the sole purpose of this is to allow disambiguation.
The resolver will have to be configured with the proper RPC endpoint and registry address anyway and the mapping: network name -> (rpc, registry) can just as easily live next to chainID -> (rpc, registry)

@mirceanis @oed The did:ethr spec and the implementation (resolver) are different things. In theory, many did:ethr resolver implementations can exist but they all should be able to resolve the did to the same did document. I agree that we won't have to specify the RPC endpoint in the did:ethr spec but we will have to specify the ERC1056 registry address of the target network. Anyways, I believe it makes sense to have everything that is chainid.network related in the did:ethr implementation. I agree with the approach that an implementation will include a mapping from did:ethr: to chainid.network entry. @oed From this perspective, I believe the current proposal in the PR is fine.

So will we use "networkName" (alastria:telsius, ropsten, rinkeby, etc) or "chainId" (the ones provided from https://github.com/ethereum-lists/chains )


Cannot read property 'arrayOf' of undefined

I removed the node_modules and run npm i then as usual npm run android and got this error
ERROR
ExceptionsManager.js:63 Cannot read property 'arrayOf' of undefined
handleException                     @ ExceptionsManager.js:63
handleError                         @ InitializeCore.js:69
reportFatalError                    @ error-guard.js:42
guardedLoadModule                   @ require.js:143
_require                            @ require.js:132
(anonymous)                         @ blob:http://localhost:8081/aa1add59-5743-43fd-b4f8-ecbf4395de2c:148151
executeApplicationScript            @ debuggerWorker.js:38
(anonymous)                         @ debuggerWorker.js:63

ExceptionsManager.js:63 Module AppRegistry is not a registered callable module (calling runApplication)
handleException                     @ ExceptionsManager.js:63
handleError                         @ InitializeCore.js:69
reportFatalError                    @ error-guard.js:42
__guardSafe                         @ MessageQueue.js:316
callFunctionReturnFlushedQueue      @ MessageQueue.js:115
(anonymous)                         @ debuggerWorker.js:70

React Native version:
Environment:
  OS: Linux 4.17
  Node: 10.9.0
  Yarn: Not Found
  npm: 6.2.0
  Watchman: Not Found
  Xcode: N/A
  Android Studio: Not Found

Packages: (wanted => installed)
  react: 16.3.1 => 16.3.1
  react-native: 0.55.2 => 0.55.2

Describe what you expected to happen:
It should run perfectly
Snack, code example, or link to a repository:
I did not changed any code.

this was some other library issue not react native.


[WIP] ILVerify implementation

ILVerify is used to check whether IL codes in the contract assemblies are verifiable, to ensure no invalid IL code inside.

[x] Add initial implementation of ILVerify (AssemblyChecker). - 50%
[x] Merge ILVerify implementation with ContractAuditor.
[x] Refactor ContractAuditor tests to optimize run time.
[x] Add a few test cases to ensure ILVerify coverage. (Add 1 positive finding to ensure ILVerify implementation is working.)

:white_check_mark: Build AElf <IP_ADDRESS>3 completed (commit https://github.com/AElfProject/AElf/commit/e38a07c004 by @aerkol)


[FLINK-12931][python] Fix lint-python.sh cannot find flake8

What is the purpose of the change
The lint-python.sh will execute failed during installing flake8 when there is anaconda2/anaconda3 installed. We need to solve this issue because anaconda is a pretty common package that developers install and use.
The reason to this issue is that conda install flake8 will try to install flake8 into the conda home which may be the conda installed by user, not the miniconda installed by lint-python.sh.
Brief change log

Updates lint-python.sh to specify the conda home explicitly when executing conda remove and conda install

Verifying this change
This change can be verified as follows:

Executes ./dev/lint-python.sh and it will succeed
Installs anaconda2/anaconda3, starts a new shell and makes sure the newly installed anaconda2/anaconda3 is used.
Executes ./dev/lint-python.sh -f and it will fail without the changes of this PR

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (no)
The serializers: (no)
The runtime per-record code paths (performance sensitive): (no)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: (no)
The S3 file system connector: (no)

Documentation

Does this pull request introduce a new feature? (yes / no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

@bowenli86 Thanks a lot for reporting this issue. Could you check if this PR can solve the problems you encountered?

LGTM, +1

Tried it locally, it works. Thanks @dianfu

@flinkbot approve all

Forget to associate PR in commit，So, close it by Fixed in master:8d98223282e8479964f13d92c5e0a591c1a72c71


Updates first-pass proposal

Think this is a decent starting point, there is a lot to this that I think we'll discover as we move through implementation. I'll try to continue to update this document for anything major. IMO we'll probably be iterating on this a bunch.

 (13) Service Instance Update

@jmrodri I was unsure of the field name on APBs to describe the plan graphs. I originally wanted to call it transitions, but I think updates_to is better from an author perspective. CC @cfchase @dymurray

@jmrodri Addressed your comments :+1:.  I'm going to be moving off update to look into some upstream catalog things, so this should get merged with the expectation that an implementation may not happen for a sprint or two. This represents the initial design work and requirements for a first pass.

@eriknelson +1 on updates_to:.
This looks good to me. My only question is: Does the APB author need to write two paths for the Gold plan? How does the Gold plan know which plan he is transitioning from? I guess I'm a little uncertain how an APB author would control the logic for upgrading different versions.
e.g.
Dev->Gold goes from version 1.0 to 2.0 where there's a massive schema change / db migration
Silver->Gold has no schema change / db migration

I only bring this up in an instance where knowing the previous plan (state of the app) is necessary for the APB. I only see that information being passed around in the broker to manage state.
Overall this looks great, ACK, just bringing up a concern. Sorry if its been worked through :)

@dymurray

How does the Gold plan know which plan he is transitioning from?

The UpdatePayload that gets passed into the APB with a previous_values section that contains the previous plan_id:
{
  "context": {
    "platform": "cloudfoundry",
    "some_field": "some-contextual-data"
  },
  "service_id": "service-guid-here",
  "plan_id": "plan-guid-here",
  "parameters": {
    "parameter1": 1,
    "parameter2": "foo"
  },
  "previous_values": {
    "plan_id": "old-plan-guid-here",
    "service_id": "service-guid-here",
    "organization_id": "org-guid-here",
    "space_id": "space-guid-here"
  }
}

Dev->Gold goes from version 1.0 to 2.0 where there's a massive schema change / db migration
Silver->Gold has no schema change / db migration

This is a much bigger question. The spec reads to me like plans and plan updates were originally designed for tiers of service (multi-tenant DB vs dedicated instance) rather than versions and their updates. I don't know that it makes sense to couple versions to plans, because then you start talking about having a plan for every permutation of <tier>+<version>+...+<N-deployment-variant>, and that starts to get ugly quickly. Version is probably more appropriate passed as a parameter, but that opens up some interesting (and potentially complex) scenarios:
I have an instance of MyFooApp-v1.2.1 that holds an active binding to an instance of PostgreSQL-v9.5. Its database has schema v1 with a bunch of important data in it. What happens when:

I update MyFooApp instance to v2.0.0, which requires a schema+data migration. More importantly, what happens when that fails?

I update PostgreSQL-v9.5to v9.6, does this impact MyFooApp at all? Again, what if it fails?

These are both fair game for the next pass at this that takes active bindings into account, IMO.


ObjectDescriptor serialization support does lots of work but leaves result unused.

Release Type: Official Release + GitHub
Version: All
Platform(s): All
Describe the bug
The ObjectDescriptor class in Stride.Core.Reflection space has some major usage issues and this seems like a high use operation fundamental to serialization. It prepares 'MemberDescriptorBase' instances which seem in high use.

The method bool PrepareMember(...) is used to indicate that the member is prepared and should be serialized. It returns false if the member should not be serialized which is in conflict with the Func this method generates called 'ShouldSerialize' which goes unused.  This method does a bunch of reflection and checking, then assigns a llambda with capture to the member -> e.g. (to a 'MemberDescriptorBase' type and 'member' property of type Func 'ShouldSerialize').

This llambda creates a closure that is capturing the member itself (because it is used within but not supplied as a parameter).
And the default value (which is available in the 'member' as the attribute is cached and only different except in one case...)
The default value, captured in the closure, is majority of the time 'null'...

*** This closure is created but is never used or invoked anywhere at all except in the testing script DescriptorTest.cs
Expected behavior
The member should be serialized based on the assigned method to determine if it should be serialized. Func 'ShouldSerialize' should be used, or this should be removed or greatly simplified. This one method is 200 lines long, performs a lot of reflection, and has limited result while assigning future GC collected memory to each instance, which goes unused.

Simplify method and/or use the result.
Change the Func signature to provide the instance of the member as an argument and move the llambda to a pure method. (capturing current state is unnecessary).
Move any default value adjustments (edge case having to do with matching numeric types) into the above method OR cache the modified default value directly into the 'MemberDescriptorBase' instance or the 'DefaultValueAttribute' (the default value attribute is already cached there).

Screenshots
Showing closure captures on mouse hover is removed when taking screenshot.
Additional context
I am investigating attribute usage and API documentation to learn the engine and I am raising an issue along the way. I do not have familiarity with the entire serialization system. However, following references seems all that is needed.

Sorry, moving to Pull Request.

im working on a roslyn version of the editor so we get rid off all that validation during runtime
https://github.com/NexStandard/stride/tree/branch_name
its by far not ready and should first be just an prototype and prove of concept


jest-each tests fail when using parameters set in beforeAll

🐛 Bug Report
You cannot pass a variable set in the beforeAll block as a parameter to a parameterized test, as .each is run before beforeAll.
To Reproduce
let values
beforeAll(() => {
  values = ['hello', 'world']
})

describe('test setting variable in before all', () => {
  test('non-parameterized', () => {
    expect(values).toHaveLength(2) // passes
  })

  test.each(values)('parameterized', (value) => {
    expect(value).toBeDefined() // fails - values is undefined
  })

  let otherValues = [1, 2, 3]
  test.each(otherValues)('parameterized with variable set right before test', (value) => {
    expect(value).toBeDefined() // passes
  })
})

Expected behavior
The beforeAll block should run before a parameterized test, in order to match the behaviour in non-parameterized tests.
Link to repl or repo (highly encouraged)
N/A see block of code above
Run npx envinfo --preset jest
 System:
    OS: macOS High Sierra 10.13.6
    CPU: x64 Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz
  Binaries:
    Node: 8.9.4 - ~/.nvm/versions/node/v8.9.4/bin/node
    npm: 6.1.0 - ~/.nvm/versions/node/v8.9.4/bin/npm
  npmPackages:
    jest: ^23.4.0 => 23.4.0

@mattphillips what do you think about this?

All tests tests and hooks are collected before we start executing any of them, so you cannot use dynamic data from a hook to define its or tests (which .each is sugar for)

Related issue: https://github.com/facebook/jest/issues/6888
As @SimenB said tests need to be defined synchronously. Perhaps we should add this to the docs?

Ah, we've added an error message now! Nice.
I'm fine with adding a note in the FAQ or something, a lot of people want to use stuff in beforeAll/Each when defining tests (mostly because of async work). Having it in the docs makes sense to me!

FWIW, I've also run into this and expected beforeAll() to actually complete before test.each().
The documentation on test.each doesn't say anything about this.

@dandv it's documented under troubleshooting - hope that helps

If anyone needs to compute variables dynamically in beforeAll block, here is a way to do so: pass function references instead of values. Code example:
let values;

function getFirstValue() {
  return values[0];
}

function getSecondValue() {
  return values[1];
}

beforeAll(() => {
  // Values of the array are computed dynamically
  values = ['hello', 'world'];
});

describe('Test setting variables in beforeAll', () => {
  test.each([getFirstValue, getSecondValue])('parameterized', (valueFn) => {
    let value = valueFn();
    // the rest of the test code...
  })
});

If the data array is long, one could experiment with iterators like this:
let values;
let i = -1;

function getValue(i) {
  i++;
  return values[i];
}

beforeAll(() => {
  values = ['hello', 'world'];
});

describe('Test setting variables in beforeAll', () => {
  test.each([getValue, getValue])('parameterized', (valueFn) => {
    let value = valueFn();
    // the rest of the test code...
  })
});

Another example with a more complexe structure and Typescript:
test.each<[string, () => Partial<TransactionsData>, any]>([
  [
    'empty data',
    () => ({}),
    {
      type: {
        type: 'any.required',
      },
      amount: {
        type: 'any.required',
      },
      userId: {
        type: 'any.required',
      },
    },
  ],
  [
    'type and negative amount',
    () => ({
      // @ts-expect-error validation test
      type: 'foo',
      amount: -1,
      userId: customer1._id,
    }),
    {
      type: {
        type: 'any.required',
      },
      amount: {
        type: 'any.required',
      },
    },
  ],
  [
    'not existent user',
    () => ({
      type: 'credit',
      amount: 10,
      userId: 'not-existent'
    }),
    {
      userId: {
        type: 'any.not-found'
      },
    },
  ]
])(
  'admin creates a transaction with invalid %s',
  (_, data, expectedErrors) => assertInvalidData(
    app.service('kidsous-transactions').create(data()),
    expectedErrors,
  ),
);

As the submitted data is the only part where I need a variable define in beforeAll (customer1), I put a function only at this place.
This also allows me to keep raw data for the string representation of each case.


How do we remove crates?

There's clutter-y chaff in some lists...  corange-rs is 3rd in engines even though it hasn't been touched in 3 years.
There has to be objective criteria for removing things or else it can get contentious.  One person says "We should remove A" and then the owner of A says "wait, why?" and there's an argument.  An off-the-top-of-my-head idea for how that might work is, a crate gets removed if:

A crate is unmaintained and has no commits for X time (6 months?  A year?)
And it isn't obviously useful in its current state (a crate such as an audio codec may not get many commits because it's basically done)
And someone submits a PR for the removal

What are objective criteria to determine usefulness?

I dunno!  Any suggestions?  :D

No good suggestions from my side :)
A few objective criteria that do not quite measure usefulness come to mind:

number of recent downloads on crates.io
compiles on current Rust
declared abandoned by author/maintainer

We could grey abandoned crates out, or put them in a separate category.
There may still be useful code in them, for reference, so I wouldn't like to just chuck them out.

I suggest having the lowest threshold being editions since those are a thing now: about once/edition, if it wasn't touched in ~an edition and doesn't represent a "finished work" that is thus "continuously useful"? It gets booted (or downgraded to a historical archive) without comment required. Essentially, someone who was introduced in 2019 to Rust (hi) will be very confused by the code in a library that was written at the beginning of 2015, when Rust 1.0 was still alpha, so even reading those is less useful. And from where I am standing, I still kind of blink at the idea of trying to use anything written before 2018.

That's...  actually not a terrible idea IMO.

Leaving comment here instead of opening a new issue about this..
It looks like there are also some crates that have been yanked/discontinued from Crates.io... nCollide in particular (which has been replaced with nCollide2D and nCollide3D) is the one that comes to mind.

One more case for the historical archive, i guess? https://amethyst.rs/posts/amethyst--starting-freshR

I propose at least having a the following rules

if the the current maintainers of a crate clearly deprecate it (e.g. Amethyst, nCollide)  => remove it or replace it with the new version
if it looks unmaintained, fulfilling all of the criteria (subject to debate)

no updates for a year
author and maintainers don't seem to respond
not a finished crate (e.g. an audio codec can be a finished crate)

I also think that the consequences of remove a crate too soon are that severe, because re-adding it isn't hard at all. Instead it's way more useful to keep these lists a relatively current snapshot of the state of the ecosystem.

This issue has been open for 4+ years now. what even is this blocked on?
I thought arewegameyet.rs itself was abandoned because it showed so many old entries like amethyst or conrod etc.. which are explicitly abandoned by the authors themselves.
The older projects just increase noise and diminish the utility of the website imo.
This is not an "official" list, so we don't need rigid rules for deprecation either.

Did the project have any updates in the past six months? No? then deprecate.
If the project is done. Then, keep it.
If the project is explicitly abandoned by the authors with an announcement? deprecate.

If the rules don't work, they can be evolved later. But listing the abandoned projects mixed with the latest maintained projects is just not the way.

I definitely think dealing with this is long overdue - at the very least it'd be worth us ditching any libraries that are obviously dead (archived repos, etc), but I do think the rules you suggested sound reasonable.
I also think we're going to have our hand forced by API rate limits sooner or later, as the more libraries we have on the site, the more calls we're making into Crates.io/GitHub every time we publish (see #378).
I think the main blockers to moving forward are:

We need to decide whether we de-emphasise the old items or just remove them (my vote would be for the latter, as I'm not convinced that many people would look at the archives, but I could be wrong!).
Someone needs to actually do the work of figuring out which crates are in scope for removal.
Ideally, we should figure out a process for pruning stuff in the future so that we don't end up back here in another four years...

You may notice that the common factor in all of these is actually having time to do the thing - everyone in the gamedev working group has been pretty busy lately, so I think nobody's really had the bandwidth to make this a priority.

I am not in the gamedev group, but i can atleast go though all the projects and make a list of all the projects that are either explicitly abandoned (with a link to the announcement) or inactive for more than one year.
Is that acceptable?

If you want, that'd be a big help, I think :)

Name
Reason
Last Activity Date
Repo link

alto
archived
July 2020
https://github.com/jpernst/alto

ambisonic
no activity
Feb 2021
https://github.com/mbillingr/ambisonic

amethyst
archived
April 2022
https://github.com/amethyst/amethyst/

amethyst_network
archived
April 2022
https://github.com/amethyst/amethyst/

arcana
no activity
July 2022
https://github.com/arcana-engine/arcana

audir
no activity
Dec 2020
https://github.com/norse-rs/audir

beehive
no activity
May 2020
repo deleted :(

bmfont
no activity
Jan 2021
https://github.com/KalitaAlexey/bmfont-rust

building-blocks
no activity
Feb 2022
https://github.com/bonsairobo/building-blocks

calx-ecs
no activity
July 2018
https://github.com/rsaarelm/calx-ecs

caper
no activity
Jan 2022
https://github.com/shockham/caper

cgmath
no activity
April 2022
https://github.com/rustgd/cgmath

chariot
no activity
April 2018
https://github.com/ChariotEngine/Chariot

coffee
no activity
May 2020
https://github.com/hecrj/coffee

conrod
abandoned
Jan 2022
https://github.com/pistondevelopers/conrod

const-tweaker
no activity
Aug 2021
https://github.com/tversteeg/const-tweaker

corange-rs
no activity
2015
https://github.com/lucidscape/corange-rs

crayon
no activity
May 2019
https://github.com/shawnscode/crayon

crow
no activity
Oct 2021
https://github.com/lcnr/crow

crystalorb
no activity
Jan 2022
https://github.com/ErnWong/crystalorb

dces
no activity
May 2022
https://gitlab.redox-os.org/redox-os/dces-rust

distill
no activity
Nov 2021
https://github.com/amethyst/distill

MuOxi
no activity
Sep 2021
https://github.com/duysqubix/MuOxi

ears
no activity
April 2020
https://github.com/nickbrowne/ears

enet
no activity
March 2022
https://github.com/futile/enet-rs

euler
no activity
June 2018
https://github.com/alteous/euler

ezing
no activity
Nov 2018
https://github.com/michaelfairley/ezing

fmod
no activity
July 2021
https://github.com/GuillaumeGomez/rust-fmod

froggy
no activity
Sep 2020
https://github.com/kvark/froggy

fungui
no activity
Jan 2019
https://github.com/thinklibs/fungui

gfx-hal
maintenance mode
Aug 2021
https://github.com/gfx-rs/gfx

glsp
on hold
Mar 2020
https://github.com/fleabitdev/glsp/

gme
no activity
Mar 2021
https://github.com/JayPavlina/Game-Music-Emu-Rust

graco
no activity
Feb 2020
https://gitlab.com/chrisrabotin/graco

hlua
no activity
Oct 2018
https://github.com/tomaka/hlua

vulkust
abandoned
Aug 2022
https://github.com/Hossein-Noroozpour/vulkust

rust-3d
no activity
Aug 2020
https://github.com/I3ck/rust-3d

imgui-ext
no activity
Nov 2020
https://github.com/germangb/imgui-ext

imgui-inspect
no activity
April 2021
https://github.com/aclysma/imgui-inspect

immi
no activity
July 2018
https://github.com/tomaka/immi

netcode
no activity
June 2020
https://github.com/jaynus/netcode.io

keeshond
no activity
May 2022
https://gitlab.com/cosmicchipsocket/keeshond

keeshond_datapack
no activity
May 2022
https://gitlab.com/cosmicchipsocket/keeshond

ketos
no activity
Jan 2020
https://github.com/murarth/ketos

laminar
no activity
April 2022
https://github.com/TimonPost/laminar

legion
no activity
Oct 2021
https://github.com/amethyst/legion

libovr
no activity
2016
https://github.com/lucidscape/libovr-rs

lichen
no activity
April 2022
https://github.com/viperscape/lichen

liquidfun
no activity
2015
https://github.com/rjanicek/liquidfun-rust

luajit
no activity
Feb 2019
https://gitlab.com/Dreae/luajit-rs

mold2d
no activity
Dec 2018
https://github.com/DarinM223/mold2d

molt
no activity
May 2020
https://github.com/wduquette/molt

navmesh
no activity
Dec 2021
https://github.com/PsichiX/navmesh

ncollide2d
passively maintained
Mar 2022
https://github.com/dimforge/ncollide

ncollide3d
passively maintained
Mar 2022
https://github.com/dimforge/ncollide

netstack
no activity
April 2020
https://github.com/Vengarioth/netstack

nphysics2d
passively maintained
July 2021
https://github.com/dimforge/nphysics

nphysics3d
passively maintained
July 2021
https://github.com/dimforge/nphysics

nuklear-rust
no activity
Oct 2020
https://github.com/snuk182/nuklear-rust

obj
no activity
Jun 2021
https://github.com/kvark/obj

ogmo3
no activity
Aug 2021
https://github.com/17cupsofcoffee/ogmo3

optimath
no activity
Jun 2021
https://github.com/djugei/optimath/

oxygen_quark
no activity
Jan 2019
repo deleted

peacock
no activity
April 2021
https://github.com/maxdeviant/peacock

physme
archived
Dec 2021
https://github.com/soycan-sim/physme

portmidi
no activity
May 2022
https://github.com/musitdev/portmidi-rs

pyro
archived
Aug 2022
https://github.com/MaikKlein/pyro

pyxel
no activity
Jul 2019
https://github.com/adtennant/pyxel

quicksilver
no activity
Oct 2020
https://github.com/ryanisaacg/quicksilver

raui
no activity
Nov 2021
https://github.com/RAUI-labs/raui

rendy
no activity
Jan 2021
https://github.com/amethyst/rendy

rhusics
no activity
Aug 2020
https://github.com/rustgd/rhusics

rovr
no activity
2015
https://github.com/binsoftware/rovr

vitral
no activity
Aug 2018
https://github.com/rsaarelm/vitral

rsoundio
abandoned
Dec 2020
https://github.com/klingtnet/rsoundio

rust-webvr
abandoned
May 2020
https://github.com/servo/rust-webvr

sharecart1000
no activity
Mar 2021
https://github.com/Lokathor/sharecart1000-rs

steering
no activity
Sep 2018
https://github.com/orhanbalci/rust-steering-behaviors

tachyon-networking
no activity
Feb 2022
https://github.com/gamemachine/tachyon-networking

tcod
no activity
Jan 2021
https://github.com/tomassedovic/tcod-rs

tessellation
no activity
Jun 2021
https://github.com/hmeyer/tessellation

three
abandoned
Sept 2022
https://github.com/three-rs/three

throne
no activity
Oct 2021
https://github.com/t-mw/throne

torchbear (renamed jazz)
no activity
April 2022
https://github.com/jazzdotdev/jazz

vorbis
no activity
2016
https://github.com/tomaka/vorbis-rs

weasel
no activity
Nov 2020
https://github.com/Trisfald/weasel

wrapped2d
no activity
May 2020
https://github.com/Bastacyclop/rust_box2d

wrapping_coords2d
no activity
May 2022
https://github.com/facorread/wrapping_coords2d

natura
no activity
Feb 2022
https://github.com/ziyasal/natura

That too way longer than expected. Anyway, i left some repos alone if i felt like they were sort-of complete or still popularly used. eg: gl wrappers or codec decoders.
I think almost all repos before 2022 are completely safe to remove. These are in alphabetical order, so cleaning up in a PR should be pretty straight forward.
If any of these sleeping projects wake up, then we can re-add them :)

That list looks fairly reasonable to me - there's only a few I've spotted that could be contentious:

amethyst - could be worth keeping purely for how historically relevant it is to the ecosystem?
bmfont - pretty commonly used format (though https://github.com/shampoofactory/bmfont_rs is more recently updated and has a more idiomatic API, so maybe let's just add that instead)
cgmath - still fairly widely used as it's stable and has been around for a long time
ezing - feels fairly 'done', not sure how much you could really add to this other than more easing functions

As far as I can tell, most of the others are not being developed and/or have been superceded by other crates.
I'll try to see if any other WG members have any strong opinions on this.

I found https://github.com/rust-gamedev/arewegameyet/issues/372 . So, it seems we already removed a bunch of crates in 2020.
amethyst - I don't think users who come to arewegameyet are looking for historically relevant crates. They probably want to look at what rust ecosystem offers them today.
cgmath - I just thought it would better to redirect users towards glam/euclid/nalgebra which are still maintained. But I will leave this to the judgement of WG members.

I honestly don't mind either way, and just to get things going, I'll propose:
Do all the non-contentious ones first, and discuss amethyst and cgmath after that.
For amethyst and cgmath, we even have the option of listing them (since they're high up in Google searches) and explicitly pointing the readers to the newer ones.

blocked on #546 which might be merged before summer :+1:

#546 is merged now[^1], so hopefully we can get this moving again in 2024 🎆
I've re-raised @workingjubilee's PR using the new archive functionality - I'd appreciate it if people in this thread could give it a look over and make sure I've not missed/broken anything 😄

#556

Once this is merged, we can maybe take a look at archiving some more of the crates mentioned here: https://github.com/rust-gamedev/arewegameyet/issues/95#issuecomment-1612288616
Given that we're just de-emphasizing crates now instead of removing them from the site entirely, hopefully there'll be a bit more consensus about which ones should be moved.
[^1]: I had to use admin rights to do it, which I feel a bit uncomfortable about, but nobody other than me is reviewing changes at the moment and I really don't want this issue to be blocked for a sixth year...

#556 is merged as well now :)
Further PRs to archive crates that are unambigiously dead/unmaintained would be welcomed.


DashContainerModel.onResize and dash util convertStateToGL should be made null safe

If the Model's cmp has been unmounted, these method may still fire and will throw in this state.


Bubble

Hello,
We're building a visual development framework (https://bubble.is) and we'd love to be part of caniuse. Could chat about that?
Emmanuel

Not sure what you mean by being "part of"...the site is managed by just myself, with data contributions possible according to https://github.com/Fyrd/caniuse/blob/master/CONTRIBUTING.md
But feel free to contact me via http://a.deveria.com/contact/ if you'd like to explain privately.


Can't remove directory of log after dbt run

Hi, we try to upgrade airflow-dbt-python 1.0.2 from version 0.14.5
But after we upgraded we got the error can't remove log directory
[2023-03-27, 04:47:29 UTC] {functions.py:222} INFO - 04:47:29  Done. PASS=16 WARN=0 ERROR=0 SKIP=0 TOTAL=16
[2023-03-27, 04:47:32 UTC] {dbt.py:176} ERROR - An error has ocurred while executing dbt run
Traceback (most recent call last):
  File "/home/airflow/.local/lib/python3.10/site-packages/airflow_dbt_python/operators/dbt.py", line 170, in execute
    result = self.dbt_hook.run_dbt_task(
  File "/home/airflow/.local/lib/python3.10/site-packages/airflow_dbt_python/hooks/dbt.py", line 207, in run_dbt_task
    with self.dbt_directory(
  File "/usr/local/lib/python3.10/contextlib.py", line 142, in __exit__
    next(self.gen)
  File "/home/airflow/.local/lib/python3.10/site-packages/airflow_dbt_python/hooks/dbt.py", line 296, in dbt_directory
    with TemporaryDirectory(prefix="airflow_tmp") as tmp_dir:
  File "/usr/local/lib/python3.10/tempfile.py", line 869, in __exit__
    self.cleanup()
  File "/usr/local/lib/python3.10/tempfile.py", line 873, in cleanup
    self._rmtree(self.name, ignore_errors=self._ignore_cleanup_errors)
  File "/usr/local/lib/python3.10/tempfile.py", line 855, in _rmtree
    _shutil.rmtree(name, onerror=onerror)
  File "/usr/local/lib/python3.10/shutil.py", line 724, in rmtree
    _rmtree_safe_fd(fd, path, onerror)
  File "/usr/local/lib/python3.10/shutil.py", line 663, in _rmtree_safe_fd
    onerror(os.rmdir, fullname, sys.exc_info())
  File "/usr/local/lib/python3.10/shutil.py", line 661, in _rmtree_safe_fd
    os.rmdir(entry.name, dir_fd=topfd)
OSError: [Errno 39] Directory not empty: 'logs'

Our code.
dbt_run = DbtRunOperator(
        task_id="dbt_run",
        project_dir=s3://{S3_BUCKET}/dbt/dbt-project.zip,
        profiles_dir=s3://{S3_BUCKET}/dbt/profiles.yml,
        project_conn_id=S3_CONN,
        profiles_conn_id=S3_CONN,
        fail_fast=True,
    )

We  run on airflow version 2.5.0 with python  3.10.8

Hey, thanks for reporting an issue.
This is definitely a weird one.
Using a TemporaryDirectory context manager should handle temporary directory cleanup; the fact that logs/ is empty or not shouldn't impact cleanup as it should be deleted anyways. I've researched online and this could be caused by a thread or other process keeping a file handle open and stopping Python from deleting it. This could even be a bug in Python...
Which dbt-core version are you using?
For the time being, I'll ignore errors in cleanup. This could cause some space leak though.


display dartdoc summary in code completions

Blocked on https://github.com/dart-lang/sdk/issues/23694.

We had another user request for this.

Fixed in https://github.com/dart-atom/dartlang/pull/674, and by analysis server changes.


[VL][CI] fix centos7 CI

What changes were proposed in this pull request?
this is quick fix on Centos7 CI
the pre-built image has some issue if updating some dependencies. this patch bypass the dependency setup stage.
How was this patch tested?
pass GHA

===== Performance report for TPCH SF2000 with Velox backend, for reference only ====

query
log/native_3193_time.csv
log/native_master_09_18_2023_bb48a9970_time.csv
difference
percentage

q1
43.85
43.04
-0.808
98.16%

q2
23.10
24.97
1.870
108.09%

q3
37.17
36.87
-0.304
99.18%

q4
41.01
41.75
0.746
101.82%

q5
69.55
69.76
0.215
100.31%

q6
6.72
5.05
-1.674
75.09%

q7
82.81
86.37
3.558
104.30%

q8
80.72
80.53
-0.198
99.75%

q9
116.02
117.29
1.264
101.09%

q10
46.55
47.13
0.580
101.25%

q11
19.42
19.27
-0.159
99.18%

q12
25.04
25.24
0.205
100.82%

q13
49.57
50.78
1.219
102.46%

q14
16.98
18.15
1.169
106.88%

q15
27.62
28.92
1.294
104.68%

q16
16.29
15.70
-0.585
96.41%

q17
120.24
120.19
-0.051
99.96%

q18
161.04
161.67
0.627
100.39%

q19
12.27
12.35
0.076
100.62%

q20
28.58
28.67
0.085
100.30%

q21
239.93
243.12
3.192
101.33%

q22
15.38
15.16
-0.220
98.57%

total
1279.86
1291.96
12.102
100.95%


WIP Enable loom-based JARs for DP images in midstream

Once we land the enabled loom from upstream,  we can point to the loom JARs for our midstream

@matzew I was thinking, can we do a test run on 1.13 to make sure it all good first?

Superseded by https://github.com/openshift-knative/eventing-kafka-broker/pull/1053


sysctl settings to tune the network

It might be a good idea to do some tuning of the system (mostly network) for apps with lots of concurrent connections.
This is mostly important for the portal instance:
net.ipv4.tcp_rfc1337 = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.ip_local_port_range = 1024 65535
maybe a few more options?
https://easyengine.io/tutorials/linux/sysctl-conf/
https://wiki.ubuntu.com/ImprovedNetworking/KernelSecuritySettings

it looks like tcp_tw_reuse only matters for connections initiated by the server, so from portal to backend nodes, and doesn't really do much for connections to clients connecting to portal.
https://vincent.bernat.ch/en/blog/2014-tcp-time-wait-state-linux#summary


Item Search

Every time I search for an item using the dropdown box in the bottom-left, I can't seem to switch to a different result. For example:
I search for the Patched Shirt, and I can only select Patched Shirt (Furniture)
Is there a shortcut to pick the item I need? Thanks in advance!

you can try getting the item's four digit long id (It is four digit long in Gamecube and Wii)
For example, go to this sheet to find it
But i already picked it for you, its 2411 for the Patched Shirt

Thank you very much for your help
On Mon, 29 Jan 2024 at 5:21 pm, Ivan951236 @.***> wrote:

you can try getting the item's four digit long id (It is four digit long
in Gamecube and Wii)
For example, go to this sheet
https://docs.google.com/spreadsheets/d/14CdvRHy0Bpm5qkbBYSGRJAytu4UqOKXcatMTBOf3PAU/edit
to find it
But i already picked it for you, its 2411 for the Patched Shirt
—
Reply to this email directly, view it on GitHub
https://github.com/Cuyler36/ACSE/issues/120#issuecomment-1915212647, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ASBBNQT77K2T4Y2FDWXYQT3YQ7LCXAVCNFSM6AAAAABAN73X5OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJVGIYTENRUG4
.
You are receiving this because you authored the thread.Message ID:
@.***>

Thank you very much for your help
…
On Mon, 29 Jan 2024 at 5:21 pm, Ivan951236 @.> wrote: you can try getting the item's four digit long id (It is four digit long in Gamecube and Wii) For example, go to this sheet https://docs.google.com/spreadsheets/d/14CdvRHy0Bpm5qkbBYSGRJAytu4UqOKXcatMTBOf3PAU/edit to find it But i already picked it for you, its 2411 for the Patched Shirt — Reply to this email directly, view it on GitHub <#120 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASBBNQT77K2T4Y2FDWXYQT3YQ7LCXAVCNFSM6AAAAABAN73X5OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJVGIYTENRUG4 . You are receiving this because you authored the thread.Message ID: @.>

No problem :)


Add unit tests for package

Mocha seems like a reasonable choice, but I don't have any strong preferences.

Hi @jaeddy , what's the status of this? If unit testing hasn't been incorporated yet, I can add mocha testing. I can also take a stab at #7 and set up Travis CI + code coverage in the same PR.
Let me know if this is already being tackled, don't want to duplicate efforts.
Thanks!

Hey @jb-adams — nobody has started on this, to my knowledge. That would be awesome — thanks!

awesome, will do!
I'm encountering a runtime error when building on Travis CI only, which is causing the build to fail. It looks like the information from git-repo-info inside src/lib/environment.js is not loading correctly in Travis.
Travis:
{ sha: '98e67888f6d2d60ee2e46ee058a02a55344b593f',
  abbreviatedSha: '98e67888f6',
  branch: undefined,
  tag: null,
  committer: null,
  committerDate: null,
  author: null,
  authorDate: null,
  commitMessage: null,
  root: '/home/travis/build/jb-adams/gh-openapi-docs',
  commonGitDir: '/home/travis/build/jb-adams/gh-openapi-docs/.git',
  worktreeGitDir: '/home/travis/build/jb-adams/gh-openapi-docs/.git',
  lastTag: null,
  commitsSinceLastTag: Infinity }
 RUNTIME EXCEPTION  Exception occurred while loading your tests

Local:
{ sha: '98e67888f6d2d60ee2e46ee058a02a55344b593f',
  abbreviatedSha: '98e67888f6',
  branch: 'feature/unit-testing',
  tag: null,
  committer: 'Jeremy Adams<EMAIL_ADDRESS>  committerDate: '2020-05-21T19:03:01.000Z',
  author: 'Jeremy Adams<EMAIL_ADDRESS>  authorDate: '2020-05-21T19:03:01.000Z',
  commitMessage:
   'temporarily removed global installs from travis.yml, mocha testing',
  root: '/Users/jadams/Github/jb-adams/gh-openapi-docs',
  commonGitDir: '/Users/jadams/Github/jb-adams/gh-openapi-docs/.git',
  worktreeGitDir: '/Users/jadams/Github/jb-adams/gh-openapi-docs/.git',
  lastTag: null,
  commitsSinceLastTag: Infinity,
  parents: [ '13cd43ec549eacfda283a54dd8c92473288ef367' ] }

Specifically this is causing an undefined exception in the toLowerCase method in src/lib/config.js
Are the null fields in the Travis build repo info expected behavior? Or is there something else I need to configure?

This is being caused by the git checkout command in the Travis build steps. eg:
git clone --depth=50 --branch=feature/unit-testing https://github.com/jb-adams/gh-openapi-docs.git jb-adams/gh-openapi-docs
cd jb-adams/gh-openapi-docs
git checkout -qf 98e67888f6d2d60ee2e46ee058a02a55344b593f # this command

git checkout prevents the correct branch info from being loaded from the .git folder via the git-repo-info library. But resetting the branch to git checkout $BRANCH_NAME enables the branch info to be loaded properly, and lets unit testing complete normally.
Maybe need to add a command to before_script to do this before running unit tests.


PARAMETERS THAT CAN BE INHERITED

Seems like docs do not have a full list of what can be inherited in a timeline.
Example in docs include these:
easing: 'easeOutExpo',
direction: 'alternate',
loop: true

but they are not in the table:

I'm trying this and not sure whether it should work or not according to docs:
opacity: {         value: [0, 1],         easing: 'linear'       }

Thanks for pointing this out, I forgot the easing parameter in the docs.
I fixed that and hopefully made this section a little bit clearer.


Documentation updates

Type of changes

[ ] 🐛 Bug fix
[ ] 🎁 New feature
[x] 📄 Documentation / docstrings
[ ] 🧪 Tests
[ ] Other

Checklist

[ ] 💻 I've run the latest black with default args on new code.
[ ] 🧪 I've added tests for new code.
[ ] ✔ I ran pytest with the --codeblocks flag to ensure that my changes are compatible with the codeblocks
found in the documentation.
[ ] 🕵 I accept that @avi-perl may be pedantic (just a little) in the code review.

Description
Updates settings used for documentation

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (cc94987) 100.00% compared to head (73b0760) 100.00%.

Additional details and impacted files
@@            Coverage Diff            @@
##            master       #15   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           10        10
  Lines          709       709
=========================================
  Hits           709       709

Flag
Coverage Δ

unittests
100.00% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Add action support

It seems that {{radio-button name="test" action="incrementCount"}} doesn't call the action in the controller.
Is this helper supposed to have action support? Or is this a planned feature?

Hey @Globegitter , thanks for the suggestion. I'm trying to think what the benefit of having action support would be, maybe you could give a use case we could discuss?
If you wanted to do something when something changed you could do something like this:
// app/templates/application.hbs
{{radio-button value='one' checked=selectedNumber}

// app/controllers/application.js
...
    selectedNumberChanged: function(){
      console.log('the selected number is now %@'.fmt(this.get('selectedNumber')))
    }.observes('selectedNumber'),
...

closing this for now, just let me know if you want to discuss this any more and i'll reopen


blog: Add blog post for Usr Merge

If someone could build the site locally and make sure the post displays correctly, that'd be great. I can't get it to work on Windows+WSL; Hugo throws some weird error.
Signed-off-by: Evan Maddock<EMAIL_ADDRESS>

Post looks visually mostly fine on my end, apart from an issue I already noticed in a less severe fashion in the last blog post and have a hacky fix for here: https://github.com/getsolus/solus-site.github.io/pull/34

This is how the Steps look as a hyphenated list, but the italicized parts look weird:

Can we just put the :tada: emoji directly into the document as Unicode?

Added a short blurb about epoch. The style issue is being handled outside the scope of this PR (https://github.com/getsolus/solbit/pull/4).


Database password rotation problem

I have passed manage_master_user_password_rotation false but, in the secret manager it rotates the password every 7 days, why?
variable "manage_master_user_password_rotation" {
  description = " Whether to manage the master user password rotation. Setting this value to false after previously having been set to true will disable automatic rotation"
  type        = bool
  default     = false
}

Related to https://github.com/terraform-aws-modules/terraform-aws-rds/issues/538?

I got caught by this too :(

This issue has been resolved in version 6.5.5 :tada:


[LS] Cannot use new import syntax & path imports together

Current Behavior
Due to the design of the LS & how sema.Checker locations are set at runtime, a contract imported using the new import syntax cannot import a contract using relative path imports (aka file imports).
Expected Behavior
You should be able to use relative path imports & new import syntax together.
This is especially important if somebody copy + pastes core contracts into their project.  These contracts may import each other and be using the path import syntax -> causes downstream error -> causes confusion.
Steps To Reproduce
A.cdc
import "B"            // will have a diagnostic error in vscode because of imported contract not being able to resolve C.cdc properly
pub contract A {}

B.cdc
import C from "../foo/C.cdc"
pub contract B {}

C.cdc
pub contract C {}

Environment
- LS version: v0.32.0
- Network: n/a

This hit me today when trying to debug whey imports using a mix of paths and "new import syntax" did not work.

https://discord.com/channels/613813861610684416/1204034793856180224
cc @gregsantos is this something we should try to prioritize?


[Add]  DSA playlist in Python

Site URL
https://www.youtube.com/playlist?list=PLrk5tgtnMN6TYBW0-U4YhIRyYEVpqVEnJ
Description of the above provided site
Data Structures and Algorithms form the backbone of computer science and software development. These topics are vital for any programmer aiming to excel in the industry. As Python is a widely used language in the tech industry a dedicated playlist on these topics in Python would be a valuable addition.
Category
Youtube
Sub Category
Data Structures
Checklist

[X] I have checked the existing issues
[X] I have read the Contributing Guidelines
[X] I am willing to work on this issue (optional)
[X] I am a GSSoC'23 contributor

You may start working on it


Remove temporary work around and bump containerd versions

Containerd 1.7.4 has the fix for the dependency issue fixed previously in https://github.com/containerd/rust-extensions/pull/179

I guess something might have been wrong with 1.7.4, 1.7.5 was released last night so updated to that version

After rebasing and upgrading to the latest versions, things seems more stable, had a green pass and now only a couple tests failed, will run it a few more times.
failed test is run:
2023-09-26T20:27:12.7165195Z     container_linux_test.go:721: write /proc/self/fd/15: broken pipe
2023-09-26T20:27:12.7176473Z     container_linux_test.go:729: write /proc/self/fd/15: broken pipe
2023-09-26T20:27:12.7266379Z     container_linux_test.go:751: expected output "hello\nhello\n" but received ""
FAIL: TestContainerAttachProcess (0.18s)
2023-09-26T20:27:13.5154455Z     container_linux_test.go:520: write /proc/self/fd/15: broken pipe
2023-09-26T20:27:13.5171721Z     container_linux_test.go:533: write /proc/self/fd/15: broken pipe
2023-09-26T20:27:13.5676024Z     container_linux_test.go:554: expected output "hello\nhello\n" but received ""
FAIL: TestContainerAttach (0.15s)

another successful run

another successful run

another successful pass


I want to customize my autocad but when i can zoom through mouse scroll at the time this action was not recorded so i need help. pls anyone reply ? and if you post any samples for cad record through winappdriver means better.

Can you please be more descriptive?

check https://github.com/microsoft/WinAppDriver/blob/master/Samples/C%23/Paint3DTest/ScenarioZoom.cs

I want to record my mouse scroll action through UIRecorder.
How can i record mouse scroll action ?


VS CODE IDE Extension - Relative Paths are not interpolated

Bug Description
Using the mirrord extension via debugger in VS Code IDE, relative paths set on MIRRORD_CONFIG_FILE env set in launch.json is not interpolated correctly. Using an absolute path works as intended.
see discord discussion: https://discord.com/channels/933706914808889356/1001193615474827264/1148741565003604078
Steps to Reproduce
VsCode Info
Mirrord Extension Version: v3.52.0
VSCODE Version: 1.81.1 (Universal)
OS: Darwin arm64 22.5.0
Example launch.json with relative path
{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Launch Service",
            "type": "go",
            "request": "launch",
            "mode": "exec",
            "program": "${workspaceFolder}/artifacts/build/debug/darwin/arm64/${workspaceFolderBasename}",
            "hideSystemGoroutines": true,
            "env":{
                "MIRRORD_CONFIG_FILE": "${workspaceFolder}/artifacts/config/mirrord.yaml"
            }
        }
    ],
}

Backtrace
No response
Relevant Logs
Error: ENOENT: no such file or directory, open '/${workspaceFolder}/artifacts/config/mirrord.yaml'

Your operating system and version
macOS 13.4.1
Local process
VSCODE IDE Extension
Local process version
No response
Additional Info
https://github.com/golang/vscode-go/blob/master/docs/debugging.md

if I remember correctly, this was solved for launch.json but still doesn't work for settings.json right?

if I remember correctly, this was solved for launch.json but still doesn't work for settings.json right?

sorry for the late reply, last week got away from me. @aviramha yes that is correct


Massive Speedup

I've been fiddling with the main script last night and managed to make some tweaks that reliably allowed for faster runs on my phone.
This fiddling relies less on wait() and moves to checking for when a skill is complete by searching for the same image as we check for at the start of each stage. This allows slower phones to still reliably use the script as is, and speeds up the script for faster processing speeds. I will post the fiddled with regular script if anyone would be willing to give it a test to ensure it still works reliably on more than my own device.
An important note, this only speeds up the activation of skills, clicking of NPs, and makes the result screen script more reliable (I was getting interrupts in the instance of leveling my Mystic Code)
--EDIT Also need to check if it works reliably with slow battle speed, since I used it with fast.

I think we don't need to even consider slow battle speed.
There's literally no need to use it when "botting".

A better way would be that we normalize(abstract?) the wait() in our script, so changes can be made easily instead of hard-coded in our routine.
After that we can measure the length of skill animation, card clicking speed, or even average battle animation, to name a few.
Although I'd personally put it on the bottom of the priority list, XD
(Won't have enough free time in the foreseeable future - at least for 3 months. And I guess Potchy & ryugawa has their own module to maintain.)

@TryBane how did you speed up the skills? I tried looking for the correct wait() modifier but was unable to, thank you

Thanks TryBane, that was real informative for me; especially with little
experience in programming
On Mon, Dec 3, 2018, 9:17 PM TryBane<EMAIL_ADDRESS>wrote:

@ParasiteEve https://github.com/ParasiteEve I noticed that every time a
skill is cast, the battle.png image that is used to determine that a battle
has begun in the script, disappears from the screen during the animation.
What I did was set a small period to wait ( .4 seconds if I recall
correctly) then keep checking if the image is back within a loop. After it
is found, it waits another .4 seconds before activating the next skill.
I did this without looking at the API though, just going off of my own
programming experience and the syntax I noticed being used within the Lua
script as of now. However, I found a few options that are likely better to
use. And this is why I posted a new topic #114
https://github.com/29988122/Fate-Grand-Order_Lua/issues/114 because I
feel that the entire script can be modified to be much faster, efficient,
flexible, and less error prone.
If you are still curious, the option I found I will probably use is the
"waitVanish()" to wait until the image disappears from site, then the
"wait()" as normal, except it will be searching for the image itself rather
than for a specified amount of time. After the image is found, since there
is a slight delay between activating a skill when it appears, I would set
an additional wait() for .2-.4 seconds. These two functions will be
processed back to back to ensure that a skills animation completed before
moving on to the next skill. It is important to note that when you choose a
targetable skill, the battle.png image does NOT disappear when the menu to
choose a servant to activate the skill on comes up. So I plan to implement
another image search looking for the x button in the top right corner to
determine if that menu is up, and if it is, to then select the servant to
use the skill on.
For anyone who has worked with the script, you know that this isn't easy
to accomplish with how the script is setup now. Which is why I want to do
an overhaul.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/29988122/Fate-Grand-Order_Lua/issues/113#issuecomment-443944663,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AVQgKLxq0JS70ZTyhclJxtpRl_Wc7nPWks5u1dtBgaJpZM4Y_Rr7
.


Could not find module discourse/mixins/presence

Hi y'all... I'm back. And currently, I'm trying to catch up with all the great stuff you did while I was away. Currently, I'm running into this:
[Error] Error: Could not find module `discourse/mixins/presence` imported from `discourse/plugins/babble/discourse/components/babble-composer`
	end (vendor-2e72f89b7b393cd8eb92fe563e177473.js, line 11)
	(anonyme Funktion) (vendor-2e72f89b7b393cd8eb92fe563e177473.js, line 11)

…any ideas?
…yeah; I do! ;)…:
Addition 1: must have been this here on the mothership: https://github.com/discourse/discourse/commit/02a968bd27c32a7413fdb63f696abfcecd6e018e
(I wonder when Discourse is really stable enough to really code plugins… sigh)
Addition 2: can be closed by applying this: https://github.com/gdpelican/babble/pull/22

Closed for #22


How nngraph works?

I implemented two equal networks. The first one uses only nn modules, the second one uses nngraph. I compared performance and I found that nngraph implementation works in two times lower. Why?

Hard to tell, since you did not provide any details ;-)
You could show your source code, or, even better, you could try to create a minimal example where the problem can be seen.


PSR-1322-1 view and change declaration link

Replaced by https://github.com/hmrc/pension-scheme-return-frontend/pull/962


About email validation

Hi,
There is no domain extention control on email validation.
If write account@domain validation is OK, but @domain is not a domain.
Because there is no an extention.

See https://github.com/jzaefferer/jquery-validation/blob/master/CONTRIBUTING.md

IMPORTANT NOTE ABOUT EMAIL VALIDATION. As of version 1.12.0 this plugin is using the same regular expression that the HTML5 specification suggests for browsers to use. We will follow their lead and use the same check. If you think the specification is wrong, please report the issue to them. If you have different requirements, consider using a custom method.

see https://github.com/jzaefferer/validation-content/pull/14/files for how to use a custom email pattern


TFCA-393

Due to the API having passed the Change Approvals Board, this issue is to be handed over to live services.


Hot Reload from Google3 causes redscreen on

https://b.corp.google.com/issues/159165121. Note that this and https://github.com/flutter/flutter/issues/59699 are unrelated, despite the similarities in subject.

cc @iskakaushik

Looks like memory is spiking in the indicated use case; Kaushik is working on bisecting a range of commits.

Downgrading to P2 while we attempt to reproduce this.

Triage: This is going to be fixed by a Dart roll.

Triage: @kf6gpe is seeking an update on whether the Dart roll fixed this.

Dart roll containing https://github.com/dart-lang/sdk/commit/1a8190db493f8d09510a60568cc23bd1d04446c0 will help further the investigation and likely even fix this issue. David Murphy is leading the investigation on this. Let's wait for his test results.

@iskakaushik Do you know the latest on this? (Checking in for critical issue triage). Thanks!

David Murhpy @ Google is working on this. He mentioned that he has it working as of today. There were a couple of hoops to jump through to get it to work, but hot reload is now working for him. Given that there is a workaround, I propose that we continue to use this issue to figure out how we can make the experience better. David mentioned that there are potentially some areas of improvement in the tool. I've asked david to post more details here when he gets a chance.
Given this, I'm reducing the priority to a P3.

cc @dabhaid

Update: Hot reload to emulator working. Not necessarily the elided configuration.

This particular issue was a result of a target mismatch: the target platform was being misidentified as linux, consequently the incremental build being pushed was for the wrong target. Coercing the platform fixes the issue on both emulator and elided configuration. The fix is mentioned in https://b.corp.google.com/issues/159165121, that bug is still open as the fix depends on a magic environment variable.


Mark modified files

For modified files but not yet saved, perhaps a star besides the name just to know what exactly runs. Then, when we save, the star would disappear.
Before:

After:

Great project thanks !

Good idea! Will add to list :-)


Export Icon and Table component

Export Icon and Table component so they can be used in consuming packages.

Snapshot tests failing because of minor/irrelevant changes to an icon that expands a text field.


Fix docstring line continuation indentation

When we need to continue lines within docstrings for method arguments (or similar), we need to indent. Otherwise, the rendering of the sphinx documentation is not correct.

Done.


Using latest api version of a resource

In ARM template it's possible to not hardcode the API version for a given resource but dynamically (at 'run time') detect the latest api available for a resource:
"variables": {
    "acrApiVersion": "[first(providers('Microsoft.ContainerRegistry', 'registries/taskRuns').apiVersions)]"
},
resources": [
    {
      "type": "Microsoft.ContainerRegistry/registries/taskRuns",
      "apiVersion": "[variables('acrApiVersion')]",
      ...
    }
]

(note - the ordering is not guaranteed and sorting is not available, thus the first() not necessarily returns the latest available, usually it does)
In bicep this is not possible:
resource promoteRegistryTask 'Microsoft.ContainerRegistry/registries/taskRuns@${first(providers('Microsoft.ContainerRegistry', 'registries/taskRuns')).apiVersions}' = {

Error BCP047: String interpolation is unsupported for specifying the resource type.
Error BCP062: The referenced declaration with name "promoteRegistryTask" is not valid.

Can such scenario be supported in bicep? Is this something ARM template disallows by-design?

Thanks for raising this! We have #622 which is similar, but I don't think covers the ability to get the 'latest' at runtime.
Some things to point out about API versioning in ARM:

API version is not a property of a resource - it defines the contract for interacting with a resource. Generally if you haven't changed any of the properties you supply, the effect on the underlying resource state will be identical between the older and newer version, unless the newer API contract has a breaking change (next point). Although it can feel odd to be using a very old API version, there is usually no great need to update unless for example you need to access some new properties added to a newer version.
Teams are permitted to make breaking changes to the structure of the API contract between API versions. They are not permitted to make breaking changes to the structure of the API contract for an existing API version. This may mean that if you upgrade versions without changing the structure of your request, you run the risk of being unexpectedly broken at deploy time.
Without having a known API version at authoring time, we cannot provide a great editor experience (type validation, intellisense etc), as we cannot know what properties are available.

So generally, our feeling on this is that we want to discourage people from picking up the API version at runtime and instead encourage pinning to a version and making the explicit decision to upgrade. That being said, we definitely see the need to simplify the syntax, know whether you're on the latest, and have an easy path to upgrade if you're not and want to be - currently we're thinking of addressing this with #622.
Does that make sense for your use case?

@stan-sz - any thoughts on the above? otherwise, I think we will plan to close this one

Thanks for the thorough explanation, @alex-frankel.

For reference, https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/test-cases#use-hardcoded-api-version

Also related to #516


openssl binaries are not given for testing

Hi,
Why Openssl exmaple is not included in the shared binaries?
I have compiled both version for test example.  Please provide yours to verify the results

Hello, I'm also trying to understand the code, are you still working on it? You can talk about it

Hi,
Why Openssl exmaple is not included in the shared binaries?
I have compiled both version for test example. Please provide yours to verify the results

Hello, I'm also trying to understand the code, are you still working on it? You can talk about it

Yes i worked on this project and taken diff of two binaries. what kind of query you have please ask here


[ZEPPELIN-1274]Write "Spark SQL" in docs rather than "SparkSQL"

What is this PR for?
Some of the doc files say "SparkSQL" but the collect spelling is "Spark SQL" (need a white space between "Spark" and "SQL").
Lets's replace it with the collect one.
What type of PR is it?
Improvement
Todos

[x] - Replace all of "SparkSQL" in some files into "Spark SQL".

What is the Jira issue?
https://issues.apache.org/jira/browse/ZEPPELIN-1274
How should this be tested?
Check the changes by some people.

@sarutak Thanks for fixing this. I found more SparkSQL in the below 2 files.

docs/manual/dynamicform.md#using-form-templates
docs/interpreter/livy.md#configuration

Could you change them as well? :)

@AhyoungRyu Thanks for the notification. I'll fix them soon.

@sarutak Looks good. Thanks!

Merging if there's no more discussion


add type annotations to application code

Update most of the application code with type annotations.

Nice! Did you use a tool to auto-generate the annotations?

No, I used it as an excuse to figure out how to configure vscode with ruff, and experiment with editing and the git UI it has.


Brew cask audit fails with "Error: 'English' cannot be parsed to a Locale"

General troubleshooting steps

[x ] I have checked the instructions for reporting bugs (or making requests) before opening the issue.

[x ] None of the templates was appropriate for my issue, or I’m not sure.

[x ] I ran brew update-reset && brew update and retried my command.
[x ] I ran brew doctor, fixed as many issues as possible and retried my command.
[x ] I understand that if I ignore these instructions, my issue may be closed without review.

Description of issue
Running brew cask audit fails with error: Error: 'English' cannot be parsed to a Locale
Output of your command with --verbose --debug
$ brew cask audit --verbose --debug
Error: 'English' cannot be parsed to a Locale
Follow the instructions here:
  https://github.com/caskroom/homebrew-cask#reporting-bugs
/usr/local/Homebrew/Library/Homebrew/locale.rb:15:in `parse'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/dsl.rb:129:in `map'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/dsl.rb:129:in `language_eval'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cask.rb:23:in `initialize'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cask_loader.rb:17:in `new'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cask_loader.rb:17:in `cask'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cask_loader.rb:53:in `cask'
/usr/local/Homebrew/Library/Homebrew/compat/hbc/cask_loader.rb:10:in `cask'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cask_loader.rb:98:in `cask'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cask_loader.rb:11:in `load'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cask_loader.rb:11:in `instance_eval'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cask_loader.rb:11:in `load'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cask_loader.rb:43:in `load'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cask_loader.rb:115:in `load'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cask_loader.rb:163:in `load'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/scopes.rb:9:in `map'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/scopes.rb:9:in `all'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli/audit.rb:12:in `block in run'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli/abstract_command.rb:49:in `casks'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli/audit.rb:12:in `run'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli/abstract_command.rb:35:in `run'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:97:in `run_command'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:167:in `run'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:131:in `run'
/usr/local/Homebrew/Library/Homebrew/cmd/cask.rb:8:in `cask'
/usr/local/Homebrew/Library/Homebrew/brew.rb:95:in `<main>'
Error: Kernel.exit
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:178:in `exit'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:178:in `rescue in run'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:155:in `run'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:131:in `run'
/usr/local/Homebrew/Library/Homebrew/cmd/cask.rb:8:in `cask'
/usr/local/Homebrew/Library/Homebrew/brew.rb:95:in `<main>'

Output of brew cask doctor
$ brew cask doctor
==> Homebrew-Cask Version
Homebrew-Cask 1.3.4-8-g24d7475
caskroom/homebrew-cask (git revision 855df; last commit 2017-09-26)
==> Homebrew-Cask Install Location
<NONE>
==> Homebrew-Cask Staging Location
/usr/local/Caskroom
==> Homebrew-Cask Cached Downloads
~/Library/Caches/Homebrew/Cask
==> Homebrew-Cask Taps:
/usr/local/Homebrew/Library/Taps/caskroom/homebrew-cask (3745 casks)
/usr/local/Homebrew/Library/Taps/caskroom/homebrew-versions (172 casks)
==> Contents of $LOAD_PATH
/usr/local/Homebrew/Library/Homebrew/cask/lib
/usr/local/Homebrew/Library/Homebrew
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3/lib/ruby/gems/2.3.0/gems/did_you_mean-1.0.0/lib
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3/lib/ruby/site_ruby/2.3.0
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3/lib/ruby/site_ruby/2.3.0/x86_64-darwin9.0
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3/lib/ruby/site_ruby/2.3.0/universal-darwin9.0
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3/lib/ruby/site_ruby
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3/lib/ruby/vendor_ruby/2.3.0
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3/lib/ruby/vendor_ruby/2.3.0/x86_64-darwin9.0
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3/lib/ruby/vendor_ruby/2.3.0/universal-darwin9.0
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3/lib/ruby/vendor_ruby
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3/lib/ruby/2.3.0
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3/lib/ruby/2.3.0/x86_64-darwin9.0
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3/lib/ruby/2.3.0/universal-darwin9.0
==> Environment Variables
LANG="en_GB.UTF-8"
PATH="~/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/Homebrew/Library/Homebrew/shims/scm"
SHELL="/bin/bash"

Ping @reitermarkus.

$ defaults read .GlobalPreferences AppleLanguages
(
    English
)

Ping @reitermarkus.

Interesting, I have changed the language using the System Preferences to another language and then back to English and now I get "en-GB" and brew cask audit works fine. I am not sure why the value was "English" to start with but it seems that this may not be an issue with brew cask itself.

@miccal Thanks a lot for your help. I will now close the issue.


Incorrect request drop rate with rate limiter policy

I tried to run the rate limiter policy with different scenarios as below but the request decisions where not as expected.

I used the below rate limiter policy where I changed the limit value to 100 requests/minute per user based on the user header but the drop rate is very high and very few requests got accepted.

kind: ConfigMap
metadata:
  name: flowcontrol
  namespace: aperture-system
  labels:
    aperture.tech/validate: "true"
apiVersion: v1
data:
  rate-limit-policy.yaml: |
    evaluation_interval: "0.5s"
    circuit:
      - constant:
          value: "100.0"
          out_ports:
            output:
              signal_name: "RATE_LIMIT"
      - rate_limiter:
          in_ports:
            limit:
              signal_name: "RATE_LIMIT"
          selector:
            service: "demo1-demo-app.demoapp.svc.cluster.local"
            control_point:
              traffic: "ingress"
          label_key: "request_header_user"
          limit_reset_interval: "60s"

I have used the same load-test.js using K6 available on main and tilt under demoapp1 pod.
Below is the output from Druid:

In this scenario, I have configured the classification for demoapp using the example available on main and changed the policy as below:

kind: ConfigMap
metadata:
  name: flowcontrol
  namespace: aperture-system
  labels:
    aperture.tech/validate: "true"
apiVersion: v1
data:
  rate-limit-policy.yaml: |
    evaluation_interval: "0.5s"
    circuit:
      - constant:
          value: "100.0"
          out_ports:
            output:
              signal_name: "RATE_LIMIT"
      - rate_limiter:
          in_ports:
            limit:
              signal_name: "RATE_LIMIT"
          selector:
            service: "demo1-demo-app.demoapp.svc.cluster.local"
            control_point:
              traffic: "ingress"
          label_key: "request_header_flow_user"
          limit_reset_interval: "60s"

In this case, all the requests got accepted and none got dropped, which I feel is also not correct as I tried different values like 10, 50 etc and still it was accepting all. I tried flow_user as value for label_key and that too had same output.

distcache was fixed today. We will validate this tomorrow.

This was resolved.


Show object diffs of match failures as well as deep-equals

Matches are more useful and common, but we don't show diffs when there's a failure there.
It's not clear how to do that for a string, but at least for objects, we can show the pattern in green and the actual keys in red, and only show the keys that are present in the pattern.

This exists now, it's pretty slick: https://github.com/tapjs/tcompare
Will start pulling into v13 soon.

53dd6fd isaacs use tcompare instead of tmatch (54 minutes ago)
02de0bc isaacs use tcompare instead of tsame (2 hours ago)
23d581b isaacs docs: add tcompare to tap 100 (2 hours ago)
22a8ae8 isaacs Use tcompare.format instead of pretty-format (2 hours ago)
5071452 isaacs<EMAIL_ADDRESS>(2 hours ago)


rewrites dynamic dns, disabling indirection, proxying, and automation

@philipcmonk, I'd appreciate your feedback on the changes to lib/{async,stdio,tapp}.hoon.

These changes have now been ported to lighter-than-eyre (and a portion of them already merged in #1197)

Merging in the interest of monorepo integration, will solicit further review as necessary.


Add kubesec-scan v0.3.0

This adds kubesec plugin to krew as "kubesec-scan" which can be called as
"kubectl kubesec-scan".
Checklist for plugin developers:

[x] Read the Plugin Naming Guide (for new plugins)
[x] Verify the installation from URL or a local archive works (kubectl krew install --manifest=[...] --archive=[...])

cc: @stefanprodan

I've released v0.3.1 with your stdout fix. Thanks!


Multiple Build Config

Describe the solution you'd like
I would like to have multiple build configurations on ONE branch.
For example, I'd like an AppStore , and Ad-Hoc, for devices, and a simulator build config...all on the master branch.
Describe alternatives you've considered
multiple branches. each with one config

This would be very useful. Especially to differentiate on release type. At the moment we're creating multiple apps for each release type for each platform (e.g. iOS: Ad-hoc and App Store). This clutters the app overview page a bit when you've quite some apps.
Only 1 app per platform would be necessary if we could define multiple build definitions within 1 app.
Other approach would be to introduce a different branch for testing:

develop: integration branch that will be used for Ad-Hoc/Alpha channel releases
master: production branch that will be used for App-Store/Play-store production releases

@mdbill How are you now handling multiple release types?

@mdbill How are you now handling multiple release types?

I'm still building locally with my Macbook. I couldn't convince myself to switch to appcenter.

In my case I think its enough to have the resign option at store distribution. For me I found the solution to download the IPA file with AddHoc built run a resign script for signing with store and upload the IPA to store.
Because if you have to rebuild it it could be an additional error source


EditorPlugins that depend on the resources that Node has will not be visible when SubInspector is focused

Godot version
4.0.dev(dc3175e4cdb4e54e1c6200b6c4d07646eea95284)
System information
Any
Issue description
EditorPlugins that depend on the resources that Node has will not be visible when SubInspector is focused.
https://user-images.githubusercontent.com/61938263/210553656-86669f57-e41f-427e-a650-30630c27d850.mp4
This is caused by two problems:
The first is caused by implicit editor deletion in Node3D. This is fixed by #70907.
The other is due to a change in inspector update timing, which is regression by #68498. Revert PR #70909 will fix this issue, but if not, we will need to update SubInspectorEditor in the correct way.
Steps to reproduce
Select Path3D or CollisionPolygon3D and open a SubInspector such as Script.
Minimal reproduction project
plugintest.zip

What is supposed happen when you click on the script resource?

@YuriSizov

What is supposed happen when you click on the script resource?

Nothing happen and it keeps bugging, the Curve/PolygonEditorPlugin in the viewport is hidden.

The path should stay editable in the viewport?

Yes, the SubInspector is only open rather than being focused, and the bug is still happening the moment I select the Node, not just the moment I set the Script.
Perhaps this is because “the process of keeping SubInspector open“ removes the EditorPlugin that depends on other inspector resources. It looks like there may be a fundamental problem somewhere in the Inspector's update method, but I don't know.

This doesn't seem to have anything to do with the update tree changes, other than... it is possible that the old and excessive update tree behavior would self-correct the issue, unintentionally. But otherwise this just looks like our old friend "multiple editor plugins cannot be active at once".

I don't think this is a truth now.

Well, we never changed anything about it, so it's still true. KoBeWi had a plan to add support for multiple plugins to be active at once, but reduz didn't want the complexity and instead it was fixed for the majority of offenders on the case-by-case basis. That's why we have the shader editor always on now. But still many plugins have hacks to work around this limitations.

In practice, this works correctly when you revert the update changes by #70909.

As mentioned, I see no evidence that the changes in that PR had anything to do with your problem, other than perhaps rapid updates were overriding the state of the inspector hiding the issue with these few plugins that are now exposed.

I can't reproduce it in beta8 and master, clicking on the script property in the Inspector always jumps to the script editor, and sets the edited object to that script in the Inspector, just same as disabling interface/inspector/open_resources_in_current_inspector .
Need to modify some settings?

It seems to jump to ScriptEditor if open_resources_in_current_inspector is disabled. It needs to be enabled.

https://user-images.githubusercontent.com/30386067/210568353-6edb44d4-3db1-47dd-9f5b-2090d35685a2.mp4
I deleted the cache dir, config dir, and data dir, and tried again, and it was the same as before.

@Rindbee There is a setting to stop switching to the script editor, I think. But regardless, the issue is reproduceable, I can confirm this.

@Rindbee Maybe it needs to remove 'Script' from Resource to Open in New Inspector.

Probably not completely fixed. At least, Skeleton3DEditor is fixed by #70909 and #70907, but the CurveEditor and CollisionPolygonEditor are still broken by script's SubInspector.

At least, Skeleton3DEditor is fixed by #70909 and #70907, but the CurveEditor and CollisionPolygonEditor are still broken by script's SubInspector.

They get into a bad state by any new edited object: you can click on the Curve resource for the Path node and have the same issue. And you can reproduce it in beta 1 (though not in 3.x, so it is some kind of regression technically).
This all points to the fact that the revert of the optimization wasn't really necessary. The bug is not related to it. The main improvement from the revert is that deselecting the node and then reselecting it now fixes the state of the editor. But folding and unfolding any resource breaks it again.
Long story short: it's the specific plugins that need to be fixed.

The update_tree call should not affect the plug-ins used for nodes, at most it will only affect the plug-ins used for resources.

The update_tree call should not affect the plug-ins used for nodes, at most it will only affect the plug-ins used for resources. Of course there may be some exceptions.

Indeed, these issues have nothing to do with update_tree. Updating the tree is purely a process of recreating the inspector. These issues are about plugins not handling edited objects correctly.

Indeed, the SkeletonEditor bug is fixed by https://github.com/godotengine/godot/pull/70907 only; https://github.com/godotengine/godot/pull/70909 seems to be irrelevant.
Also, I agree that the optimization only mainly causes problems with the Curve resource in the Curve3DEditor (although there was a problem with AnimationPlayerEditor), but that there are bugs independent of the optimization.
If we fix the plugin so that the above script's SubInspector bug does not occur, it is quite possible that the optimization will not cause the bug.
However, I want to avoid clear bugs as we are close to RC for the time being.
So for now, we should fix the plugin before optimization. After that, we recommend reapplying the optimization, taking note of the problem that occurred this time.

Oh, Path3D editor plugin is a convoluted mess. So what happens when you select the script in the Inspector is the following:

Script resources have an editor plugin attached to them, ScriptEditorPlugin, which is a plugin that has a top bar menu; the normal logic for this is to activate the top bar menu to switch to that plugin's view, and naturally hide all other plugins that may be currently visible. For this make_visible is called on all of them, with false being passed to other plugins, including Path3DEditorPlugin.
Path3DEditorPlugin handles this call by hiding parts of the UI it adds (the toolbar), but also by clearing its stored Path3D reference, and sending a changed signal to its Curve3D resource.
When a Curve3D resource attached to a Path3D node changes, it is handled by the Path3D::_curve_changed method, which in turn calls into Node3D::update_gizmos, inherited Node3D. This method is editor-only and is responsible for updating the gizmos, naturally. In this case it adds to the MessageQueue a request to call its internal counterpart that does the actual updating, Node3D::_update_gizmo.
The internal method checks for simple things, it makes sure that the node is still visible in the tree (which it is) and then calls for a redraw on the gizmo object. If the node was not visible, it would call clear. But this time we trigger a redraw.
This brings us back to the Path3DEditorPlugin, or rather its auxiliary class Path3DGizmo. Path3DGizmo::redraw does the normal gizmo object thing and constructs visual elements for the gizmo. This includes a visualization of the curve, as well as handles for controlling said curve. Problem is, handles are only supposed to be drawn for the currently edited path. If we go back to point 2 of this list, we will remind ourselves that we just cleared the edited path. So of course we decide that there is a mismatch and we don't have anything to draw. Thus handles disappear.

Now, you might wonder why we call make_visible on Path3DEditorPlugin in the first place? We never switch to the script editor, so this seems pointless. And I agree. This is pointless, and something that I'm looking into next. At the same time, the handling of make_visible in Path3DEditorPlugin is still questionable. Even if we do switch to the script editor, we probably shouldn't remove the reference of the last edited path from Path3DEditorPlugin. Because when we switch back to the 3D view, the gizmos will be gone anyway as a result. This is in fact what happens in 3.x, so the issue with the plugin dates way back.
So, what should we do? I'll see if we can prevent pointless make_visible calls, which would technically fix the regression. But there is still a buggy behavior in Path3DEditorPlugin that needs fixing by someone who knows more about this plugin than I, it's just consistent with a buggy behavior in 3.x.
Oh, and collision polygons are kind of the same, kind of worse too. They don't have a dedicated plugin. Instead Polygon3DEditorPlugin is used for the polygon part. And Polygon3DEditorPlugin doesn't have its own gizmos. Instead it spawns a mesh instance that has gizmos. Upon receiving make_visible(false) it resets its inner state (by calling edit(nullptr)), effectively removing the mesh instance and all of its bells and whistles.

I guess there is a hint as to why Skeleton3DEditor is working. Skeleton3DEditor now uses SubGizmo, so the place where the drawing is performed may be different from those EditorPlugin. But my memory is a bit hazy...

@TokageItLab Skeleton3DEditor isn't an EditorPlugin, so doesn't appear to implement make_visible at all. It's just a UI element of the inspector plugin, EditorInspectorPluginSkeleton. Their owner, Skeleton3DEditorPlugin, doesn't implement make_visible either.
So yeah, as long the edited object is visible in the inspector, its gizmos should be displayed correctly in this case. Plugins for Path3D and CollisionPolygon3D work independently from the inspector. Maybe that's how they should be rewritten then, no new system needed. Just use subgizmos. Should be pretty easy for Path3D, but not for CollisionPolygon3D due to that intermediate mesh instance.

Okay, I don't think we can fix the issue with clicking on the script resources making gizmos disappear right now. As I mentioned before, this issue also exists in 3.x, you just always switch your view to the script editor. In 4.0 you can remain in the 3D view, but that doesn't really matter much to the issue itself, as the behavior is essentially the same.
Godot editor has a stack of edited objects, and the one selected last is the one that controls which plugins are active, and which are not. Selecting a script, a resource that has a main screen plugin associated with it, makes it the latest selected object, which tells all plugins that handle other objects to hide themselves. This logic is very core to the whole editing and inspecting experience, and I wouldn't want to touch it right now. We should look into improving it in future, but for now I'd leave it as is.
The situation can be improved, as mentioned above, by fixing the plugins themselves, so they don't remove the reference on being hidden, or by using subgizmos.


PLEASE DO NOT COMMIT DIRECTLY ON THE master BRANCH!

@dlfivefifty
I have some requests and opinions about the latest release v1.0.0.

We don't have an agreement about releasing v1.0.0 yet in this thread (https://github.com/JuliaApproximation/FastGaussQuadrature.jl/pull/127).
I believe we are not ready for v1.0.0 because the API is not stable. (i.e. Some deprecated methods are not removed.)
Adding deprecations is not considered as a breaking change.

Introducing deprecations is not breaking; removing deprecations is breaking.

https://github.com/SciML/ColPrac#incrementing-the-package-version

Please just approve my PRs because I also have the privilege of merge.
I am one of the core maintainers of this package, so please feel free to discuss and request reviews.

I tried to change the repository settings to protect the master branch, but I didn't have enough permissions for that.

Umm I’m the owner of the package. The API has been stable and there’s no reason to not tag v1.0

I’m the owner of the package.

I truly respect the role you've played, and I deeply appreciate the effort you've put into maintaining this package. Thank you.
Considering that this package is under the JuliaApproximation organization and not an individual account like dlfivefifty, could we have more discussions and PR-based development?

The API has been stable and there’s no reason to not tag v1.0

As I've mentioned multiple times (https://github.com/JuliaApproximation/FastGaussQuadrature.jl/pull/123#issuecomment-1729616430, https://github.com/JuliaApproximation/FastGaussQuadrature.jl/pull/123#issuecomment-1729806939, https://github.com/JuliaApproximation/FastGaussQuadrature.jl/issues/128#issue-1923050029), I believe the API is not yet fully stable. Specifically, it would be better not to include deprecated functions like gausschebyshev and besselroots in v1.0.0.
I opened a new issue for v2.0.0: https://github.com/JuliaApproximation/FastGaussQuadrature.jl/issues/129

I’m also the owner of JuliaApproximation. Endless discussions are not necessarily productive and sometimes one just has to make decisions.