Error re-indexing Catalog - Magento 2.4.0

When I launch the indexer:reindex command, I receive everytime the following error:
Catalog Search index process unknown error:
{"error":{"root_cause":[{"type":"cluster_block_exception","reason":"index [magento2_product_1_v1] blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];"}],"type":"cluster_block_exception","reason":"index [magento2_product_1_v1] blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];"},"status":403}

I've seen colleagues run into this error (haven't seen it personally) and it's generally due to ES putting itself into read-only mode when it encounters a disk-full error.
The following link has been shared in an internal slack with info on how to pull ES out of read-only mode: https://selleo.com/til/posts/esrgfyxjee-how-to-fix-elasticsearch-forbidden12index-read-only
Simplest solution is to simply warden env down -v on the project (to destroy not just containers, but also wipe out data volumes) and rebuild the project. You could do surgery to delete just the ES container and associated volume, then warden env up followed by re-indexing Magento, but then you're getting into complicated territory.
Also a note, if you're on a Mac, the reason many run into this is due to having insufficient space allocated to the Docker Desktop storage volume: https://docs.docker.com/docker-for-mac/space/ but it could also happen when your disk fills up even momentarily. Is it a pain? Yep, but is how ES operates to prevent data loss when running out of disk space on a production cluster.

Thank you @davidalger


Add uploadFromUrl and restructure other upload methods (fixes #70)

See #70. Previously, upload() took $data and uploadFile() invoked upload(). However, uploadFromUrl() takes $url and otherwise needs exactly the same code as upload(). To allow sharing this common code, I had to restructure upload() a bit into a private method, uploadCommon() (maybe there's a better name for that?), and then its public use is made clearer by a new name, uploadData().
The previous merge is just a few days old (so hasn't spread far yet) and still falls under "current development", so this API change seems acceptable to me, as it leads to consistent naming of the three public upload methods. For further consistency, I renamed download() to downloadData() as well.

Minor code change in addition to the restructuring: is_null($text) is a better way to test input parameters than === null.

@waldyrious, would you be able to squeeze in a review one of these days? :wink:

Apart from the minor comments I've left inline, this LGTM :)

@waldyrious, would you be able to squeeze in a review one of these days? :wink:

Oh, crap, you were faster :P I had this page open for the last few days and didn't refresh it before starting the review. I'm saying this just to reassure you that I didn't review the PR now following your prompt, but indeed hadn't forgotten :)

Sorry. :wink: I guess all the quick review turnarounds in the past spoiled me a bit, but I thought I'd poll you after 5 days.
Thanks again, time to wrap up this one.


feat: build mysqli backend

[x] Double check some configure options

configure: WARNING: unrecognized options: ... --with-mysqlnd, --with-pdo-mysqli

@Angelmmiguel I can remove --enable-pdo to untangle it from mysqli but having both enabled at the same time is certainly possible since there is code that might use the PDO construct and other might use the mysqli function set.

@Angelmmiguel I can remove --enable-pdo to untangle it from mysqli but having both enabled at the same time is certainly possible since there is code that might use the PDO construct and other might use the mysqli function set.
From https://www.php.net/manual/en/ref.pdo-mysql.php: For example, on Ubuntu the php5-mysql package installs the ext/mysql, ext/mysqli, and PDO_MYSQL PHP extensions. On CentOS, the php-mysql package also installs these three PHP extensions.

Ahh I see, I missed that comment. Makes sense, we can enable it in this case.


[TASK] Integrate frontend Cypress Rancher integration test to Jenkins

Task Requirement
Discuss the details of the integration current Cypress Rancher integration test to Jenkins environment
Target Deployment

CI installer Jenkins
Daily E2E test Jenkins

Plan

Close this issue. We can track the state in https://github.com/harvester/tests/issues/1179


Rename mks to webmks

As requested by @bmclaughlin, renaming mks to webmks  as a follow up to https://github.com/ManageIQ/manageiq/pull/16519
@miq-bot add_label gaprindashvili/yes, fine/yes, euwe/yes
@miq-bot assign @gtanzillo

Gaprindashvili backport details:
$ git log -1
commit fec04f5d77faea25368fceddae4ae9bae43d48d7
Author: Gregg Tanzillo<EMAIL_ADDRESS>Date:   Tue Nov 28 17:44:47 2017 -0500

    Merge pull request #16544 from jntullo/rename_mks

    Rename mks to webmks
    (cherry picked from commit a3cfae4612ffb488585d15d0e726b624d053de49)

    https://bugzilla.redhat.com/show_bug.cgi?id=1510131

This change is included in https://github.com/ManageIQ/manageiq/pull/16591 (Euwe) and https://github.com/ManageIQ/manageiq/pull/16589 (Fine)


Update project website: AboutUs, README

Add developer's own details and pictures in AboutUs
Update README to briefly describe the project

Features and issues not added yet:

[ ] README.md CI banners not pointing to own project
[ ] README.md traces of AB3 remain
[ ] AboutUs.md src="images/user_name_in_lower_case.png" missing for some members
[ ] _config.yml needs to be updated
Assigned to @jovantanyk to fix


Coupled 2D3V deliverable

Description
Prototype of a coupled fluid-particle system written for NEPTUNE milestone M4c.2.
Adds a NESO-particles ParticleSystem and a Nektar EquationSystem to the SimpleSOL solver.
Type of change

[x] New feature (non-breaking change which adds functionality)

Testing

[x] SimpleSOLTest.2DWithParticles in test/integration/solvers/SimpleSOL/test_SimpleSOL.cpp

Runs the SimpleSOL solver with the "SOLWithParticles" equation system for a small number of steps with periodic BCs on all sides
Tests for fluid-particle mass conservation
Passes iff mass is conserved to a tolerance of 1e-14 AND the solver returns 0.

Test Configuration:
OS: Ubuntu 22.04
Compiler: GCC 11.3.0 / OneAPI v2022.1.0
SYCL implementation: Hipsycl v0.9.2 / DPC++ v2022.1.0
MPI details: MPICH v4.0.2
Hardware: CPU (Intel Alder Lake)
Checklist:

[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] I have used understandable variable names
[x] I have run clang-format against my *.hpp and *.cpp changes
[x] I have run cmake-format against my changes to CMakeLists.txt
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] My changes generate no new warnings

SimpleSOLTest.2DWithParticles now checks for mass conservation using Will's diagnostic class.
I've had a look through all the changes and done a bit more tidying up - it's ready to merge in my opinion.

Many thanks for your hard work too!


[Feature] Add "Share Link" functionality

Hi,
There would be nice to add functionality to create a link to preview environment and share it with somebody.
I've found this useful in a case where you are working on a page, and you need do show somebody an article or page (without publishing it) who hasn't got access to strapi.
I know that to make this the PREVIEW_SECRET will no longer be a secret, but maybe there is other option?

Hi @kuli00 Based on your suggestion, I think I will be making the PREVIEW_SECRET optional in an upcoming release 👍🏻

Hi @kuli00 The Strapi preview button plugin has recently updated with breaking changes and includes a new "copy link" button which can be disabled if desired. The secret key and env vars are all optional as well. In reality, the secret key was never really a secret. 😄
Thank you for this feature request! 🎉


How to handle CORS?

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If this is a layout/rendering issue, please provide screenshots for both Tokamak and SwiftUI that highlight the difference.
Desktop (please complete the following information):

OS: [e.g. macOS 12.4]
Browser [e.g. chrome, safari]
Version of the browser [e.g. 22]
Version of Tokamak [e.g. 0.10.1]

Smartphone (please complete the following information):

Device: [e.g. iPhone 6]
OS: [e.g. iOS15.1]
Browser [e.g. stock browser, safari]
Version of the browser [e.g. 22]
Version of Tokamak [e.g. 0.10.1]

Additional context
Add any other context about the problem here.

Can you describe what you are trying to do? I think CORS should be handled by your server, not the frontend framework.

I am trying to use JDoodle plugin. I either get a 400 error from the site or a CORS error.
struct CompilerView: View {   init() {     let document = JSObject.global.document     let script = document.createElement("script")     script.setAttribute("src", "https://www.jdoodle.com/assets/jdoodle-pym.min.js")     script.setAttribute("type", "text/javascript")     document.head.appendChild(script)   }   var body: some View {       VStack {                  DynamicHTML("a", ["href": "https://www.google.com"]) {           Text("This is a link")         }       HTML("script", ["src": "https://www.jdoodle.com/assets/jdoodle-pym.min.js", "type": "text/javascript"])        HTML("div", [         "data-pym-src": "https://www.jdoodle.com/plugin",         "data-language": "java",         "data-version-index": "4",         "data-libs":"mavenlib1, mavenlib2",         "Access-Control-Allow-Origin": "*"       ])     }   } }

It appears to be an Apple Safari issue as it works in Chrome... I should have known.....


Remove IRC support

Mozilla IRC was permanently shutdown, and that is causing exceptions when highfive tries to ping a reviewer there. The project doesn't use IRC anymore though, so this removes support for it.
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/dist-packages/highfive/app.py", line 58, in new_pr
    return handler.run(event)
  File "/usr/local/lib/python3.6/dist-packages/highfive/newpr.py", line 71, in run
    self.new_pr()
  File "/usr/local/lib/python3.6/dist-packages/highfive/newpr.py", line 409, in new_pr
    author, to_mention
  File "/usr/local/lib/python3.6/dist-packages/highfive/newpr.py", line 123, in set_assignee
    client = irc.IrcClient(target="#rust-bots")
  File "/usr/local/lib/python3.6/dist-packages/highfive/irc.py", line 16, in __init__
    self.ircsock.connect(("irc.mozilla.org", 6667))
ConnectionRefusedError: [Errno 111] Connection refused

r=me unless you're waiting on something to merge


Separate Schema and Type again

This is basically a rollback of #3949, but on top of work done since. Shane objected to cramming Schema and Type into a single file, so this is the rollback and we are exploring other options.

Updated to ToT, which I inadvertently missed.

And removed Scott's commit, as this caused Kotlin problems.


model.inp.infiltration yielding IndexError: list index out of range

Hello, the title pretty much says it all.
Reproducible example:
download link for swmm model
import swmmio
inp_path = "model.inp"
mymodel = swmmio.Model(inp_path)
infiltration = mymodel.inp.infiltration

and here's the output:
failed to parse infiltration with cols: ['Subcatchment', 'Suction', 'HydCon', 'IMDmax']. head:
[INFILTRATION]

S10              4.33       0.43       0.368      0          0
S11              4.33       0.43       0.368      0          0
S116_2           4.33       0.43       0.368      0          0
S116_3           4.33       0.43       0.368      0          0
S12              4.33       0.43       0.368      0          0
S13              4.33       0.43       0.368      0          0
S14              4.33       0.43       0.368      0
Traceback (most recent call last):

  File "C:\Users\Daniel\anaconda3\envs\SYS6582Uncrtnty\lib\site-packages\spyder_kernels\py3compat.py", line 356, in compat_exec
    exec(code, globals, locals)

  File "c:\users\daniel\dropbox\_gradschool\courses\sys6582\assignments\final_project\reprex\2022-4-22_swmmio_infiltrationparams\reprex.py", line 4, in <module>
    infiltration = mymodel.inp.infiltration

  File "C:\Users\Daniel\anaconda3\envs\SYS6582Uncrtnty\lib\site-packages\swmmio\core.py", line 860, in infiltration
    self._infiltration_df = dataframe_from_inp(self.path, "infiltration")

  File "C:\Users\Daniel\anaconda3\envs\SYS6582Uncrtnty\lib\site-packages\swmmio\utils\dataframes.py", line 148, in dataframe_from_inp
    df = pd.read_csv(StringIO(s), header=None, delim_whitespace=True,

  File "C:\Users\Daniel\anaconda3\envs\SYS6582Uncrtnty\lib\site-packages\pandas\util\_decorators.py", line 311, in wrapper
    return func(*args, **kwargs)

  File "C:\Users\Daniel\anaconda3\envs\SYS6582Uncrtnty\lib\site-packages\pandas\io\parsers\readers.py", line 680, in read_csv
    return _read(filepath_or_buffer, kwds)

  File "C:\Users\Daniel\anaconda3\envs\SYS6582Uncrtnty\lib\site-packages\pandas\io\parsers\readers.py", line 581, in _read
    return parser.read(nrows)

  File "C:\Users\Daniel\anaconda3\envs\SYS6582Uncrtnty\lib\site-packages\pandas\io\parsers\readers.py", line 1254, in read
    index, columns, col_dict = self._engine.read(nrows)

  File "C:\Users\Daniel\anaconda3\envs\SYS6582Uncrtnty\lib\site-packages\pandas\io\parsers\c_parser_wrapper.py", line 271, in read
    values = data.pop(self.index_col[i])

IndexError: list index out of range

@lassiterdc apologies for the delay, but thank you for documenting this issue! I was unable to download the file from Dropbox - can you please share that file again so that we can reproduce your issue?

Thanks for revisiting this, the link should be working now!

Thanks @lassiterdc! I've just reproduced the error and (hopefully) identified a solution.
After looking into the inp file, I noticed that you are using GREEN_AMPT for infiltration, as configured in the [OPTIONS] section. Further down in the file, we can see what your [INFILTRATION] section looks like:
[INFILTRATION]
;;Subcatchment   Param1     Param2     Param3     Param4     Param5
;;-------------- ---------- ---------- ---------- ---------- ----------
S10              4.33       0.43       0.368      0          0
S11              4.33       0.43       0.368      0          0
S116_2           4.33       0.43       0.368      0          0
S116_3           4.33       0.43       0.368      0          0
S12              4.33       0.43       0.368      0          0
S13              4.33       0.43       0.368      0          0

Since Green-Ampt requires just three parameters (Suction, HydCon, IMDmax), swmmio parsers are expecting there to be 3 values in the [INFILTRATION] section in addition to the Subcatchment name. After modifying your inp file slightly to omit the two zeros in each row, as shown below, I was able to parse the infiltration section without any problems.
[INFILTRATION]
;;Subcatchment   Param1     Param2     Param3     Param4     Param5
;;-------------- ---------- ---------- ---------- ---------- ----------
S10              4.33       0.43       0.368
S11              4.33       0.43       0.368
S116_2           4.33       0.43       0.368
S116_3           4.33       0.43       0.368
S12              4.33       0.43       0.368
S13              4.33       0.43       0.368
S14              4.33       0.43       0.368

Can you give this a try on your end and see if this solves your problem?
I wonder why the two trailing zeros were there in the first place. Did you enter them manually? If not, did you switch the infiltration model your model is using in the EPA SWMM user interface?

The SWMM5 GUI does not add zeroes if you change infiltration type from the two HORTONS

@lassiterdc FYI this issue should be resolved when we merge #137 and make the next release!


[v3][UAvatar] UAvatar breaks when using @nuxt/image with custom provider

Environment
Operating System: Darwin
Node Version: v22.11.0
Nuxt Version: 3.14.1592
CLI Version: 3.16.0
Nitro Version: 2.10.4
Package Manager<EMAIL_ADDRESS>Builder: -
User Config: default
Runtime Modules<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>Build Modules: -
Is this bug related to Nuxt or Vue?
Nuxt
Version
v3.0.0-alpha.9
Reproduction
https://github.com/makvv4/nuxtui3-avatar-bug-reproduction
Description
In the markup we see the correct link to the image, but in the avatar component only a fallback is displayed.
In the Network tab, you can see that there are multiple requests made at the same time: one with the correct link, and another request links to the localhost.
The provider is located in /providers/my-img-provider.ts
And config looks like:
export default defineNuxtConfig({
  devtools: { enabled: true },
  modules: ['@nuxt/ui', '@nuxt/eslint', '@nuxt/image'],
  css: ['~/assets/css/main.css'],

  future: {
    compatibilityVersion: 4,
  },

  compatibilityDate: '2024-11-27',

  image: {
    providers: {
      myImgProvider: {
        provider: '~~/providers/my-img-provider.ts',
      },
    },
    provider: 'myImgProvider',
  },
})

Additional context

Logs

Does this work with ipx provider? 🤔


openssl: Disable TLS compression [1.10]

High Level Description
This is a backport of https://github.com/dcos/dcos/pull/2073
Backport JIRA: https://jira.mesosphere.com/browse/DCOS-19452
The TLS compression is vulnerable to MITM attack known as CRIME. This PR disables support for TLS compression in openssl library. None of the components using the openssl will be able to run TLS compressed connection.
Related Issues

DCOS-19390 Disable TLS compression for mesos TLS interface

Checklist for all PR's

[ ] Included a test which will fail if code is reverted but test is not. If there is no test please explain here:
[ ] Read the DC/OS contributing guidelines
[ ] Followed relevant code rules Rules for Packages and Systemd

Checklist for component/package updates:
If you are changing components or packages in DC/OS (e.g. you are bumping the sha or ref of anything underneath packages), then in addition to the above please also include:

[ ] Change log from the last version integrated (this should be a link to commits for easy verification and review): example
[ ] Test Results: [link to CI job test results for component]
[ ] Code Coverage (if available): [link to code coverage report]

@mesosphere-mergebot label [Ready For Review]

@mesosphere-mergebot bump-ee

@mesosphere-mergebot pr-status-checks

@mesosphere-mergebot pr-status-checks


Add Write Multiple Coils feature

Added ModbusRTU Function 0x0F (15) to ModbusRtuClient
Added WriteMultipleCoils() method to ModbusRTU Serial Client.
Tested on physical RS485 Modbus RTU IO Module that supported function 0x0F.
Added Unit Test for WriteMultipleCoils() to check Modbus message generation & expected return.
Also confirmed this using this online message generation tool
Using this a protocol reference
Did not add to TCP Client as found issues with message construction for TCP message that require further work.

cherry picked into the rtu-server branch.  Will be in next release.  Thanks!


[Wallet] Comment request from new build to pre-comment encryption build shows cypher text

Expected Behavior
Comment unavailable is shown the same way it is handled in the transaction feed
Current Behavior
Unreadable cypher text appears in the comment request text area if a request is sent from a build with comment encryption enabled to an older build

I believe this has been addressed


[Autocomplete] Listen for click on border

closes https://github.com/mui/material-ui/issues/36364
working video
https://user-images.githubusercontent.com/60743144/222042780-ca4a4da2-81de-4354-b14b-aef95e392f99.mov

[ ] I have followed (at least) the PR section of the contributing guide.

@sai6855 Your changes have introduced another bug:
https://user-images.githubusercontent.com/100380515/222171596-d7eedc5a-42f8-442f-abe6-a4f541577a47.mov

@sai6855 Your changes have introduced another bug:

Nice catch, I'll check


Cannot resolve imports with subpaths

I cannot get it working with any subpath imports, e.g.
some-file.tsx:
import { item } from 'package/subpath'

leads to an error:
ESLint: Unable to resolve path to module 'package/subpath'.(import/no-unresolved)

At the same time, TypeScript works and doesn't find any issues.
ESLint config:
.eslintrc.js:
module.exports = {
  parser: '@typescript-eslint/parser',
  parserOptions: {
    ecmaVersion: 'latest',
    sourceType: 'module',
  },
  settings: {
    'import/extensions': ['.ts', '.tsx', '.mts', '.js', '.jsx', '.mjs'],
    'import/resolver': {
      typescript: true,
    },
  },
  plugins: ['@typescript-eslint', 'react-hooks', 'only-warn'],
  extends: ['airbnb', 'plugin:@typescript-eslint/recommended', 'plugin:react-hooks/recommended', 'prettier'],

This is a part of package.json of package:
  "exports": {
    "require": "./dist/cjs/index.js",
    "import": "./dist/mjs/index.js",
    "default": "./dist/mjs/index.js"
  },
  "main": "./dist/cjs/index.js",
  "module": "./dist/mjs/index.js",
  "types": "./dist/types/index.d.ts",

ESLint: 8.x

That's because we don't support exports yet - since resolve also doesn't. When resolve does, so will we.
Separately, your exports field there HAS no subpaths, so nothing should resolve a subpath anyways.

Just a question - I get similar error, but related to package imports:
import/no-unresolved, Unable to resolve path to module '#lib/result'.

Seems that package imports also not supported by the node resolve?

@zdm yes, imports uses and depends on exports.

Webpack uses https://github.com/webpack/enhanced-resolve.
It highly configurable and fully supports all possible features.
Maybe it can replace current node resolver.

Or use built-in possibilities:
This will work for node projects.
const { createRequire } = require( "node:module" );
const url = require( "node:url" );

function resolve ( name, from ) {
    try {
        return createRequire( url.pathToFileURL( from ) ).resolve( name );
    }
    catch {
        return;
    }
}

@ljharb hey! So would you recommend simply disabling the rule locally for those imports until exports is supported?

@dahaca if you can't persuade the package maintainer to add main and be backwards compatible, then yes.

@ljharb appreciate such a swift reply! Understood! ✌
Although I've checked the package.json of the library causing the lint error and it seems to be backwards compatible :/ Will disable the rule for those imports for now but out of curiosity would be glad if you are able to provide any more insight! I suppose it could also be caused by the fact that I am importing from a .mjs file...

what subpath? that package doesn't have any subpaths available anyways - so you can't import anything but @pandacss/eslint-plugin or its package.json.

@ljharb  Yes, this is an unrelated error. I thought this have happened due to there being an another package under the @pandacss domain installed.
Including .mjs files in settings like so made the error go away! Thanks for your time :)
      "import/resolver": {
        typescript: {
          typescript: true,
          node: true,
          project: "./tsconfig.json",
        },
        node: {
          extensions: [".js", ".jsx", ".mjs"],
        },
      },


enable using AR to modify archiving behavior on windows

Fixes #384.

Thanks! Since the two are now being interpreted as basically the same, could this msvc branch be updated to call get_archiver? That should naturally pick up the usage of AR (and any future changes to that). The current code using windows_registry would then just need to move into there as well as a fallback case where the target contains msvc

Since the two are now being interpreted as basically the same, could this msvc branch be updated to call get_archiver?

Good call!  I tried keeping the unwrap_or_else logic, but eventually had to admit that match was much nicer here.

Thanks!


[SPARK-23582][SQL] StaticInvoke should support interpreted execution

What changes were proposed in this pull request?
This pr added interpreted execution for StaticInvoke.
How was this patch tested?
Added tests in ObjectExpressionsSuite.

Test build #88028 has started for PR 20753 at commit 0790dea.

Test build #88028 has finished for PR 20753 at commit 0790dea.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
      throw new RuntimeException(\"The static class cannot be null.\")

Merged build finished. Test FAILed.

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

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/1336/
Test PASSed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/1337/
Test PASSed.

Merged build finished. Test PASSed.

Test build #88029 has started for PR 20753 at commit f570692.

ping @hvanhovell

Test build #88029 has finished for PR 20753 at commit f570692.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

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

@hvanhovell Is it better to implement method handler approach, too?

@kiszk I think we should benchmark it. My rational for considering method handles is that they seem to be made for this purpose, and they should become more performant with newer versions of java.

Which use case is typical? The same method is called many times. Are different method called?
If the same method is called, reflection can also improve performance by creating custom bytecode.

Ok, let's go with reflection then.
cc @rednaxelafx

and cc @viirya

Sure

@hvanhovell @kiszk Yes, the old school JDK reflection does perform bytecode generation to speed it up, since the JDK1.4 era. But the advantage of fully optimized MethodHandle versus reflection Method.invoke is that the former performs privilege checks at MethodHandle creation time, whereas the latter is required to perform privilege checks at every invocation (and that's not covered by the generated bytecode). So theoretically the MethodHandle version can be faster.
But note that even in OpenJDK8, the HotSpot VM is still exploring ways to optimize MethodHandle performance, and it's somewhat picky about the shape of the MethodHandles, so it's not like we will always get better performance just by sticking it in place of reflection. It'll need some tuning / trial-and-error. We don't have to get it right in the first cut.

Build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/1395/
Test PASSed.

Test build #88089 has started for PR 20753 at commit f9f5701.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/1396/
Test PASSed.

Test build #88090 has started for PR 20753 at commit 9a36442.

Test build #88090 has finished for PR 20753 at commit 9a36442.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/1397/
Test PASSed.

Test build #88091 has started for PR 20753 at commit 7d107a6.

Test build #88091 has finished for PR 20753 at commit 7d107a6.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

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

Merged build finished. Test FAILed.

Test build #88093 has started for PR 20753 at commit 91a454c.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/1399/
Test PASSed.

Test build #88093 has finished for PR 20753 at commit 91a454c.

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

Merged build finished. Test FAILed.

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

Test build #88097 has started for PR 20753 at commit eb6171a.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/1403/
Test PASSed.

Test build #88097 has finished for PR 20753 at commit eb6171a.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

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

Merged build finished. Test FAILed.

Test build #88089 has finished for PR 20753 at commit f9f5701.

This patch fails Spark unit tests.
This patch does not merge cleanly.
This patch adds no public classes.

Build finished. Test FAILed.

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

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/1406/
Test PASSed.

Merged build finished. Test PASSed.

Test build #88100 has started for PR 20753 at commit f74d48e.

Test build #88100 has finished for PR 20753 at commit f74d48e.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

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

ping @hvanhovell

ping @hvanhovell

Test build #88581 has started for PR 20753 at commit 7c52201.

Test build #88584 has started for PR 20753 at commit 42a5fca.

Test build #88585 has started for PR 20753 at commit 1e3aa0f.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/1748/
Test PASSed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/1751/
Test PASSed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/1752/
Test PASSed.

Test build #88581 has finished for PR 20753 at commit 7c52201.

This patch fails to build.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

Test build #88585 has finished for PR 20753 at commit 1e3aa0f.

This patch fails to build.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

Test build #88584 has finished for PR 20753 at commit 42a5fca.

This patch fails to build.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

Test build #88589 has started for PR 20753 at commit c7f3c22.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/1758/
Test PASSed.

Test build #88589 has finished for PR 20753 at commit c7f3c22.

This patch fails to build.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/1761/
Test PASSed.

Test build #88592 has started for PR 20753 at commit d828f46.

Test build #88592 has finished for PR 20753 at commit d828f46.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

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

Test build #88629 has started for PR 20753 at commit d7352a9.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/1785/
Test PASSed.

Test build #88629 has finished for PR 20753 at commit d7352a9.

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

Merged build finished. Test FAILed.

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

retest this please

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/1788/
Test PASSed.

Merged build finished. Test PASSed.

Test build #88633 has finished for PR 20753 at commit d7352a9.

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

Merged build finished. Test FAILed.

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

Test build #88648 has started for PR 20753 at commit 09cdf5e.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/1792/
Test PASSed.

Merged build finished. Test PASSed.

Test build #88648 has finished for PR 20753 at commit 09cdf5e.

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

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

Merged build finished. Test FAILed.

retest this please

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/1794/
Test PASSed.

Test build #88651 has finished for PR 20753 at commit 09cdf5e.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

retest this please

Test build #88656 has started for PR 20753 at commit 09cdf5e.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/1799/
Test PASSed.

Test build #88656 has finished for PR 20753 at commit 09cdf5e.

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

Merged build finished. Test FAILed.

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

retest this please

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/1804/
Test PASSed.

Merged build finished. Test PASSed.

Test build #88663 has started for PR 20753 at commit 09cdf5e.

Test build #88663 has finished for PR 20753 at commit 09cdf5e.

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

org.apache.spark.sql.execution.streaming.sources.RateSourceSuite.overflow is not a problem for this PR.
Other PRs also fails due to this test.

retest this please

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/1818/
Test PASSed.

Merged build finished. Test PASSed.

Test build #88687 has finished for PR 20753 at commit 09cdf5e.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

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

retest this please

Test build #88822 has started for PR 20753 at commit 09cdf5e.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/1906/
Test PASSed.

Test build #88822 has finished for PR 20753 at commit 09cdf5e.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

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


Training device and time

Thank you for open source your implementation, I'm curious about what Training device and how much time is required to train the model.

After installing the required packages, you can run accelerate config from your terminal and set up your run configuration by answering the questions asked. Here, you can specify the devices to use for training.
Then, the accelerate launch command specified for training will run the code on your specified devices.
We trained our various models on 4-8 GPUs. @Dapwner can provide more details about the training time.

Hello! Naturally, training time depends on the effective batch size used and available GPU resources.
In our case, we trained the Tango (not Mustango) baseline models on 4 Nvidia Tesla V100 GPUs (32GB memory) with an effective batch size of 32 (batch=2, devices=4, accumulation steps=4) which resulted in roughly 2 hours for 1 epoch of MusicBench.
For Mustango, since it is bigger, we used 8 RTX8000 and an effective batch size of 32 (batch=2, devices=8, accumulation steps=2), but this time it took longer than expected, which could be due to the use of different GPUs, or other settings and issues which we haven't managed to figure out yet. The speed was about 5 hours per 1 epoch of MusicBench.


I wish modules would be self-contained

I was looking to use workbox-google-analytics but it seems I can’t without a good amount of buy-in and manual fiddling. This seems to apply to a lot of the modules, but I’ll use workbox-google-analytics as an example:
What I expected

I can get a minified/bundled version of just the workbox-google-analytics code and put it in my project
The module provides 2 functions.

The first function tells me if a Request should be handled by this module
The second function handles the request (it’s basically an fetch event handler)

What I got

A module that depends on other modules outside it’s scope (log-helper and idb-helper)
No (obvious) way to build just this module as a self-contained package
Code that - as a side-effect - registers a top-level fetch handler. I need to manually figure out which requests are being handled by the module and not handle those requests in my code.

@surma agreed that this isn't good and @philipwalton had the same problems. Could you do me a HUGE favor and look at the doc referenced in #699 which outlines a rethink of our current module setup.

On it!

Left a few comments, my point from this issue wasn‘t quite covered, so I started a discussion. Might be worth continuing it here if y’all like, because the GDocs comments can get quite crammed. LMK ;)

@surma It's totally valid feedback that we don't provide self-contained builds that are easy to just drop-in for offline-analytics. We should fix that bug. Our npm packages could include this, but it still wouldn't address this piece of feedback:

Code that - as a side-effect - registers a top-level fetch handler. I need to manually figure out which requests are being handled by the module and not handle those requests in my code.

Did you find that our current DEV/debugging story helped understand what requests were handled by the module? Would better docs or logging have helped here vs. the "The module provides 2 functions." part of your feedback?

No, this is def. not a docs problem. The analytics module code is actually pretty simple to read, but I’d have to duplicate some code to make sure my code doesn’t handle requests that are already handled by the analytics module.
Explicitly having the developer dispatching events to the module (and providing a function to determine whether an even should be dispatched to the module) seems both more readable and most importantly scalable to me.

@surma, re: this comment:

I need to manually figure out which requests are being handled by the module and not handle those requests in my code.

Is this not a docs issue? If a service worker is already handling the fetch event for a particular route, subsequent fetch handlers won't event see that event, so they won't have to handle it or write code to ignore it.
The only issue I see with this is not knowing whether a particular module is already handling a fetch event, and that can be solved by both better docs as well as better logging.
FWIW, once we update the GA module to work with the existing router and background sync modules, you'll get the latter for free.

The updated (WIP) code for this can be found here:
https://github.com/GoogleChrome/workbox/blob/offline-analytics-sync/packages/workbox-google-analytics/src/index.js#L64-L163
Re: all your other comments about modularity, I agree 100% and have expressed this concern to the rest of the team many times. I think the v3 proposal addresses all of these issues.

If a service worker is already handling the fetch event for a particular route, subsequent fetch handlers won't event see that event

Currently, the analytics module adds it’s own fetch event handler, no? So both the module’s handler and my handler would be called. Or am I misunderstanding the code?
This seems to be addressed in the new code, although looking at the code: Analytics uses Router and Router attaches itself to the fetch event globally, which is the same issue just in another module.

If a service worker is already handling the fetch event for a particular route, subsequent fetch handlers won't event see that event

Sorry, I said this wrong.

Currently, the analytics module adds it’s own fetch event handler, no? So both the module’s handler and my handler would be called. Or am I misunderstanding the code?

Yes, they would both receive the fetch event. What I was trying to say (poorly) is if one of them responded with its own fetch() call, the other one wouldn't receive notification of that happening. Is that your concern?
If not, I guess I'm not sure what the concern is.

Can we not make use to stopPropagation() or whatever the method is to capture analytics events and then let other requests fall through?
I did this in FCM and it worked a treat.

The model used for multiple fetch handlers in that they're called one at a time, in the order in which they're registered via addEventListener(), and the first one the synchronously call event.respondWith() "wins".
So stopPropagation() in your example with notifications is roughly equivalent to calling event.respondWith(), and the fall-through to the next fetch handler happens whenever event.respondWith() isn't called by the previous fetch handler.
(I wrote up a longer explanation of how this works for an unrelated question: https://stackoverflow.com/questions/45257602/sharing-fetch-handler-logic-defined-across-multiple-service-workers/45285119#45285119)

and the first one the synchronously call event.respondWith() "wins".

I did not know that. That changes the situation a little bit, but it feels like something very brittle to rely on.
I guess this reduces my complaint to: I’d strongly prefer to have this explicit rather than implicit (because to what extent can we make sure that workbox’ fetch handler is before the user’s code?)

(because to what extent can we make sure that workbox’ fetch handler is before the user’s code?)

You can't make sure of that. The best you can do probably is to include examples that encourage initializing the library very early on in the process.
Or if you had a guarantee that the rest of the user's code also used Workbox, you could bake in some coordination in the underlying workbox-routing level, where special routes that had higher priorities were always given precedence, regardless of which order in which they were registered.
That would break down if developers just called self.addEventListener('fetch', () => {}), though.

The best you can do probably is to include examples

What about the option that I suggested? Don’t do any implicit, side-effecty handler registrations and move that responsibility to the developer. Maybe we can embrace a pattern similar to this:
// my-service-worker.js
import wbAnalytics from 'workbox-google-analytics.min.js'

/* ... */
addEventListener('fetch', event => {
  // Handler returns true if it handled the event.
  if(wbAnalytics.handler(event)) return;
  // user code
})

A developer who's writing their own fetch handler can just as easily respond by accident to a Google Analytics request before Workbox got a chance to create a response. You can't force developers to call the Workbox code at the start of their own fetch event handler.
// my-service-worker.js
import wbAnalytics from 'workbox-google-analytics.min.js';

addEventListener('fetch', event => {
  // Oops, the user's accidentally written code that executes before the Workbox code...
  if (event.request.mode === 'POST') {
    event.respondWith(/* my custom POST logic */);
  }

  if(wbAnalytics.handler(event)) return;
  // User code *ideally* would go here in your suggestion,
  // but there's no guarantee that it actually will...
});

I did not know that. That changes the situation a little bit, but it feels like something very brittle to rely on.

Coming back to this: I don't see how using multiple fetch handlers is more (or less) brittle than what you're suggesting. In both cases, the order in which code is run matters, and examples and documentation is needed to ensure that developers get that order right.

The model used for multiple fetch handlers in that they're called one at a time, in the order in which they're registered via addEventListener(), and the first one the synchronously call event.respondWith() "wins".

Thanks Jeff. This what I was trying to say above, but then when I tested multiple fetch handlers they were all called, so I was second-guessing what I thought I knew and why we were recommending putting the GA code first.
Now I see that multiple fetches were running in my tests because none of them were calling event.respondWith().

You can't force developers to call the Workbox code at the start of their own fetch event handler.

This is a feature. The developer can opt out of workbox handling the request on a per-request basis. With the implicit register, I have no way to do that.

I kinda hoped that this would operate a bit like express middleware, eg:
import Workbox from 'workbox';
import { networkFirst } from 'workbox/strategies';
import analytics from 'workbox-analytics';

const router = new Workbox();

router.use(analytics());
router.get('/schedule', networkFirst);

addEventListener('fetch', router.fetchHandler);

But a more advanced user could do:
import Workbox from 'workbox';
import { networkFirst } from 'workbox/strategies';
import analytics from 'workbox-analytics';

const router = new Workbox();

router.use(analytics());
router.get('/schedule', networkFirst);

addEventListener('fetch', event => {
  event.respondWith(async function() {
    // Maybe respond if I know I don't need workbox here, else:
    const workboxResponse = await router.handle(event);
    // Now I can do stuff with workboxResponse before returning it.
  }());
});

I can see why someone familiar with Express might want Workbox to match that syntax, but that's not the interface we went for.

This is a feature. The developer can opt out of workbox handling the request on a per-request basis. With the implicit register, I have no way to do that.

So I'm a bit lost—the way you opt out of Workbox handling Google Analytics requests is to not use the library. The current implicit code is opaque, yes, but it doesn't impact non-Google Analytics requests. What's the use case for using the library, but having the library ignore some Google Analytics requests? (I'm not being facetious—I'd like to know!)
There's nothing stopping us from exporting various internal bits—both the Handler and the Route—that are used implicitly by the library so that they could be used explicitly by developers who don't want Workbox doing too much under the hood. It adds noise to the public interface, but that's not the end of the world. (You're still going to end up pulling in the weight of some of the libraries we're using, like the IDB wrapper and soon the Background Sync library, because they play a critical role with the core Handler code.)
But, other than empowering developers to continue using their own fetch handlers, I'm trying to understand if there's an overlooked use case that this would enable. Because if there is, we should focus on solving that use case for everyone who's using the library, perhaps through additional configuration.

So I'm a bit lost—the way you opt out of Workbox handling Google Analytics requests is to not use the library.

That’s an all-or-nothing approach. I’m looking for a dynamic escape hatch. Maybe I want only some requests to be handled by Workbox (this goes beyond the Analytics example). Another thing that I have done is to mangle/augment request data (mostly headers or CORS modes) before handing it off to a module.
Additionally, with the “auto-register” approach, Workbox will always be the top-level library. If I am already using some other, 3rd party SW library that approach will most likely make it impossible to use both. If we keep dispatch and invocation explicit, I can compose multiple libraries.
For me, this is not really about the syntax (although I do like Jake’s example code), but about the fact that he explicitly invokes the router in his own fetch handler, allowing him add pre- or post-processing.
I am not arguing against a “Get Workbox running quickly” API, but I strongly recommend adding an escape hatch that allows me to have the full functionality but with more manual control (see Jake’s “Beginner” vs “Advanced”).

That’s an all-or-nothing approach. I’m looking for a dynamic escape hatch. Maybe I want only some requests to be handled by Workbox (this goes beyond the Analytics example).

The Google Analytics library, if you choose to use it, registers a fetch handler that will only respond to Google Analytics-related requests.
If you're using workbox-sw, then there's another instance where there's not-entirely-obvious registration of a fetch handler—when you call precache(), requests made for any of precached URLs will be handled using a cache-only strategy. There's some background on the precache() naming choice at https://github.com/GoogleChrome/workbox/issues/370, including a rejected possibility of naming it precacheAndRoute() to make that implicit route clearer.

Additionally, with the “auto-register” approach, Workbox will always be the top-level library. If I am already using some other, 3rd party SW library that approach will most likely make it impossible to use both. If we keep dispatch and invocation explicit, I can compose multiple libraries.

In both of the exceptional cases mentioned above, the developer has actively opted-in to doing something that causes Workbox to respond to a subset of fetch events. Even if you use Google Analytics or precache(), other fetch events are yours to respond to, either by explicitly using Workbox's routing + handling code, your own fetch handler logic, another SW library's logic, or just not respond at all and let the network handle it.
The rules about the order in which fetch event handlers are called, and the first-to-call-respondWith()-wins nature of them means that in order to opt-in to using certain behavior, you do need to make sure that they get registered before other fetch handlers which might otherwise respond to them.
I'm open to suggestions about renaming the Google Analytics initialization method, or precache(), to make it clearer that there's implicit fetch event registration going on that needs to take place before your own fetch handlers that respond to everything is called. We could use this issue to track that if that sounds like a reasonable outcome.
The other concerns that you bring up, about opting-in to using some parts of Workbox meaning that you lose control over all of your fetch handling, requiring an escape hatch, doesn't match the reality of what Workbox is doing. I'm not sure what the takeaway is there.

Would be good to circle back to this once V3 is released as this makes big steps forward in this direction.

Workbox Modules are actually in a much better state for V3.
Workbox-sw now actually used the modules global namespace and demos are self contained as much as possible. See: https://workbox-demos.firebaseapp.com/
We've also created a policy that event listeners will only be added for the default exports meaning if you use the classes directly - you get full control.
I think there will be more to do here but will need actual library usage to call out specific uses, so going to close and will nag for v3 feedback once it's out.


Incorect display when useing VS-15 text selector

Maybe need a build-test for this?
Noto Emoji Medium v3.0030060	(2024-08-10)
🙂↔ 🙂↔ 🙂↔ Head Shaking Horizontally
🙂↕ 🙂↕ 🙂↕ Head Shaking Vertically

Clear as mud. 🙂.
Have to see what is happening in the application being used.
Which I am guessing is a browser.
Noto Emoji only has black (text) emojis, so not sure what the variation selector should do.
Maybe you know more about emoji fonts than I do.
And/or can guess better.

But if it is just a black font, does that make sense?

https://www.unicode.org/reports/tr51/#Emoji_Variation_Sequences
The first collum should render in a word processor, text editor, terminal, ect. the same as in the second collum!
With recent updates to this font these two code points added in UNICODE 15 the ↕ and ↔ are FALLBACK diplayed in the second collum.


FFM-7217: Adds note recommending no nested prereqs

Preview environment: https://hdh.pr.harness.io/pr-1008


iDRAC not ready for discover_nodes

@cdearborn @digambar15 Please review the code. Invoke made using is_idrac_ready() method in discover_nodes module.

Tested the code changes with the suggested approach.
Case-1:  Ran is_idrac_ready.py successfully, when node is in life-cycle controller setup.
Case-2: Ran discover_nodes.py successfully, when node is in life-cycle controller setup.
Case-3: Ran config_idrac.py successfully, when node is out of life-cycle controller setup.


Support max-line-length in organize imports

Referenced in https://github.com/Microsoft/TypeScript/issues/22974

By the way, I ran "organize imports" on about 800 files. Works really well other than this problem and it puts imports that were previously on multiple lines onto one... so that will break my linting rule for "max-line-length". Luckily it's easy to write a script to investigate and break them back onto multiple lines 😄

This would be awesome.
So that this:
import { AfterContentInit, Component, ContentChildren, Directive, EventEmitter, HostBinding, Input, ModuleWithProviders, NgModule, OnInit, Optional, Output, QueryList, ViewEncapsulation, forwardRef } from '@angular/core';

becomes this:
import {
  AfterContentInit,
  Component,
  ContentChildren,
  Directive,
  EventEmitter,
  HostBinding,
  Input,
  ModuleWithProviders,
  NgModule,
  OnInit,
  Optional,
  Output,
  QueryList,
  ViewEncapsulation,
  forwardRef
} from '@angular/core';

Thus, respecting max-line-length (tslint).

The auto-importer also breaks the ordered-imports TSLint rule, which specifies how imports should be broken up into groups and how they should be sorted. It would be nice if it were possible to enable/disable various parts of this organize imports command; in my case I want to disable everything except removing unused imports, because everything else is covered by TSLint.

@pelotom that is tracked by https://github.com/Microsoft/TypeScript/issues/23366

@mhegazy That issue seems to be specifically about the ordering of named imports within a single statement, but doesn't cover

ordering of different import statements relative to one another
groups of imports

or am I missing something?

which part you are saying conflict with the tslint rule? i thought the problem is that within the same import declaration, named import bindings are ordered differently by tslint (case insensitive) and by tsserver (case sensitive). are there other issues?

I see, thanks for sharing. i do not think such level of configurability will be in in organize imports the server supports. i think the best solution here is to not use organizeImports, and instead have tslint-vscode-plugin fix your lint errors on save.

@mhegazy

i think the best solution here is to not use organizeImports, and instead have tslint-vscode-plugin fix your lint errors on save.

Unfortunately that's not viable for removing unused imports, because the vscode plugin for TSLint can't apply rules which require type checking. Besides that, the TSLint rule for no-unused-variables has myriad problems and @egamma has advised people to use TypeScript's native noUnusedLocals and noUnusedParameters instead. See https://github.com/Microsoft/vscode-tslint/issues/185, https://github.com/Microsoft/vscode-tslint/issues/70.
Is there any chance that a "remove unused imports" command could be added to the language server?

apply rules which require type checking

that has nothing to do with type checking. the organize imports does not require full type-checking, nor does it require semantic state outside the current file, it uses the find-all-refs logic.

Besides that, the TSLint rule for no-unused-variables has myriad problems and @egamma has advised people to use TypeScript's native noUnusedLocals and noUnusedParameters instead.

i think we are talking about two different things here. 1. what APIs needed from the TypeScript language service to make tslint better, and 2. what level of configuration is needed in organize imports feature
For 1, we would be happy to add additional APIs to enable tslint to be faster/more efficient. for 2, as i noted, the value of adding more configuration drops fairly quickly vs the value added.
I would say start a tslint issue, and we will talk o the tslint core team about what APIs we can enable to simplify this scenario.

Is there any chance that a "remove unused imports" command could be added to the language server?

There is already a suggestion for that, that is marked as unused (see https://github.com/Microsoft/TypeScript/pull/22361), and it comes with a quickfix to remove it, with quickFix all option on it. so an IDE could query for suggestions, and apply all fixes on save if that is needed. not specific to imports though, all declarations.

that has nothing to do with type checking. the organize imports does not require full type-checking, nor does it require semantic state outside the current file, it uses the find-all-refs logic.

I'm talking about the TSLint no-unused-variables rule. I have no idea why it claims to require type checking, but it does, and type checking rules cannot be run inside VSCode (see the issues I linked). My point is just that there's no way as of right now to remove unused imports in VSCode with TSLint, which is why I was hoping to be able to use Organize Imports feature :)

There is already a suggestion for that, that is marked as unused (see #22361), and it comes with a quickfix to remove it, with quickFix all option on it. so an IDE could query for suggestions, and apply all fixes on save if that is needed. not specific to imports though, all declarations.

Great, looks like exactly what I want!

Are there any workarounds for this issue?

@Rush nothing I know of that doesn't require a small investment of scripting. I use saved vim macros to run the organize imports function and then do a second pass to fix anything that's too long and break it up according to regex rules. This works for one off files while editing.
I imagine you could do something similar in the scripting language of your choice over the entire project.

Our team has the same issue. We had to turn off the organize import feature. We are using Prettier which suit us well for formatting the code, however, it gets in conflict with the organize import when it is used to be fired when a file is saved.
The idea of having the organize import on save it to automatically have the unused import taken out without having human interaction. However, having the organize import and Prettier make the code to be on a single line once organized, and on multiple lines when Prettier is cleaning its part of the code. I haven't investigated why, but prettier seems to be executed first, which cause the code to be formatted correctly but then VsCode organizes and put back into a single line the import, hence causing issues of consistency.

I'm sad that I just had to turn off organize imports. My team doesn't want a lint rule for the imports, but I like them to be organized. They are ok with me organizing them, but they don't want to be bothered with it. I was depending on this feature until I couldn't get multi-line imports to be happy.

Seems like this quickly got off the topic of line length and moved on to ordering of imports :(
There was a similar item that was marked as a duplicate of this one, but is there still attention here for just the concern over being able to limit line length when using organize imports? Line length and ordering of the imports seems like they should be two separate topics.

I'm for the clear separation.
For me, I can't use the feature at all because the it breaks my linter line
length rule (I use 120 typically). Providing a setting where we could
adjust that number would allow me to use it without creating a linter error
most of the time.
The custom ordering for me would be icing on the cake, but waaaay less
priority as the line length as far as feature usability. (at least for my
typical use cases).
On Thu, Mar 21, 2019, 8:45 AM crashmstr<EMAIL_ADDRESS>wrote:

Seems like this quickly got off the topic of line length and moved on to
ordering of imports :(
There was a similar item that was marked as a duplicate of this one, but
is there still attention here for just the concern over being able to
limit line length when using organize imports? Line length and ordering of
the imports seems like they should be two separate topics.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/TypeScript/issues/22991#issuecomment-475214404,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEGYaXuUSq-_yRrCe9Q-24Xf3swHykrjks5vY372gaJpZM4TAwli
.

tslint has an option to ignore max line in imports
you guys must be joking all around

you scare me people:

https://palantir.github.io/tslint/rules/max-line-length/

@aleksey-bykov do you confuse tslint rule with typescript language service feature?

@aleksey-bykov it's certainly in the domain of the language service's formatter, but not necessarily a feature that will be implemented. No need to be so spooked out.
(IMO, time would probably be better spent leaving this to other code formatters)

let me say this:

we are still talking about the max-length problem (as the title suggest), don't we?
if so, then this problem simply does not exist, since tslint can ignore it
if no, i personally don't want any formatting to the imports, because:

i have tons of them, and each line counts, so i wish they were as flat as they can be
i stopped caring about imports about 2 years ago since

auto imports
auto imports cleanup
auto imports sorting
... so i simply don't look at them and i am glad i don't have to, and it will be a bad day if they start getting nicely formatted

@aleksey-bykov When we look at issues with no thumbs up, you go into those issues and complain about it, but when we look at issues with 27 thumbs ups, you go into those issues and poo-poo their value too. This doesn't feel like good-faith engagement and I think it'd be best if you were more intentional about where you choose to weigh in on things.

@aleksey-bykov I don't want to remove or make exceptions for the tslint rule if at all possible, but I appreciate that I could and that for some, that may be their preferred solution.
I would like if VS Code could accommodate a tsline line length rule (or rule specified in VS Code) that does not have exceptions for imports, because for now I manually run the command to organize imports then edit for length (as that would not work for organize on save unless I do make exceptions for the tslint rule).

@RyanCavanaugh i apologize for being a stink bug, this is what i am, this is what i do, didn't mean to pick on you

@aleksey-bykov you've made your preference clear. Some other peoples' preference is for all code to fit within their screen's width to prevent needing to horizontally scroll regardless of whether they are using tslint—having the import statements automatically format would make the editing experience a little nicer for those people because they wouldn't need to fix this every time they run organize imports.
If anything, I think it would be more productive to ask for this to be configurable (which it likely will be if implemented) so you can turn it off.

@dsherret i see, ok, although it's not what the original problem is about, but i buy it

@aleksey-bykov I think it's related to the original problem (I'm the one quoted in it). This isn't really tslint related... think about what the motivation for that tslint rule is and transitively that's what the original post is about.
Additionally, the API and tsserver don't care about tslint. This feature if implemented would likely be a setting specified on FormatCodeSettings or its base (see here). Then vscode and other editors can provide that value however they please.

I've found a workaround in VSCode that's been working very well for me. The key is to use eslint-plugin-import. It solves all my problems:  setting max line length, and auto-organizing imports on save, as well as automatically breaking imports into multiple lines on save (so that prettier doesn't complain).
Run yarn add --dev eslint eslint-plugin-import eslint-config-prettier eslint-config-typescript eslint-plugin-prettier eslint-plugin-react @typescript-eslint/parser @typescript-eslint/eslint-plugin then add this to your .eslintrc:
{
  "parser": "@typescript-eslint/parser",
  "extends": [
    "typescript",
    "typescript/react",
    "typescript/prettier",
    "typescript/prettier-react",
    "plugin:prettier/recommended"
  ],
  "plugins": ["import"],
  "rules": {
    // Max line length is configured here
    "max-len": ["error", { "code": 80 }],
    "import/order": ["error"]
  }
}

Then in .vscode/settings.json for your project:
    "[javascript]": {
      "editor.formatOnSave": false
    },
    "[javascriptreact]": {
      "editor.formatOnSave": false
    },
    "[typescript]": {
      "editor.formatOnSave": false
    },
    "[typescriptreact]": {
      "editor.formatOnSave": false
    },
    "editor.codeActionsOnSave": {
        "source.organizeImports": false,
        "source.fixAll.eslint": true
    },

I spent so much time getting it right (and failed!)... Thank for sharing your config @bduffany! Your solution seems to work perfectly!

I haven't read through everything and don't get why there isn't an option for this yet. I'm not using prettier (So I think I'm using the default formatter? It's all a bit confusing when you're not completely into this kind of stuff) but es-lint with the typescript plugin. Couldn't we just say that we make a setting (for example: "source.organizeImportsMaxLen": 100) and break imports into one per line? Just provide the option and people can turn it on or off if they please.
Additionally, I'd suggest if you want something different like filing the line and only breaking when the import doesn't fit on it, you should have to use a custom formatter.
What I mean:
import {bla, bla, bla, bla
    bla, bla, bla, bla, bla,
    bla} from './bla';

This is also affecting exports. My multi-line export statement is being turned into one line:
export {
	Core,
	TokenKeyword,
	TokenSymbol,
	Token,
};

is being turned into a single line. Funny thing, export default {...}; does not have the same issue.
I'm also using "source.fixAll": true" if that makes a difference. Hopefully, I got everything correct and didn't make a complete fool of myself :D

Hi, for those who is still struggling on those issues, please try JS/TS Import Sorter which I believe covers all following topics discussed here:

Max-line-length
TSLint/prettier compatible
Groups of imports
Removal of unused imports

If you do find bugs or features not supported, I'm happy to accept open issues as a maintainer.
Thanks!

@daidodo Works like a treat well done! It's also really configurable.
Question is, maybe this should work out of the box but it's not up to me to decide this.

Any updates on this?

We ended up just using both organize imports and prettier on save.

I vote for support "one import/export statement per line with trailing comma", like:
import {
  AfterContentInit, <-- one statement per line
  Component,
  ContentChildren,
  Directive, <-- trailing comma, so additions after this line doesn't affect this line
} from '@angular/core';

instead of max-line-length property. This plays nicely with diffing, merging and code review.

Clearly one size doesn't fit all so why even vote? :)


Publish 1.0.6 to npm

Hi, could you please publish 1.0.6 version to npm?

Same ask here - could you publish the latest version by any chance?
Thank you!

@EugeneDraitsev FYI in the meantime you can install the latest commit by adding this dependency line to your package.json:
"redux-storage-engine-reactnativeasyncstorage": "git://github.com/react-stack/redux-storage-engine-reactnativeasyncstorage.git#5acf34b2e14ad59889bfd063cd7e6891d53158ba",

Published as 1.0.7 https://www.npmjs.com/package/redux-storage-engine-reactnativeasyncstorage

Amazing, thank you!


Confused by this project and the icons included in ionic2

The icons we see in the new ionic2 documentation are different from this icons, there are less icons and different for any mobile device (md, ios, windows) which is all okay.
But I don't know what is the difference between this project and the other icons. In the ionic2 documentation there is now hint to this icons.
But if I create a new project with the ionic-cli there is a npm package included "ionicons" i version 3.0.0
which should be this npm packge https://www.npmjs.com/package/ionicons
On the page there is the link for the github project which is still this project here!
In this project you link to this page http://ionicons.com/
But there is the problem, the icons included in my ionic2 project are not the same as I can see in your linked page!
So now I'm a little bit confused!
Can we use or can we not use this icons in ionic2 project? Is your readme wrong?
What are the difference between this icons and which are the ideas of the ionic team about the icons?
This is my ionic forum post
https://forum.ionicframework.com/t/difference-from-included-icons-and-http-ionicons-com/79448/4

This project is the one they use for ionic2. Just not the master branch but 3.0 branch

Yea I saw the 3.0 branch and the included icons which are the one in the ionic2 documenation.
But also in branch 3.0 the readme is talking about the http://ionicons.com where you can see the icons in action, which is completely wrong, so  that confused me.
I think the icon set for 2.0.1 is much better and also there are so many icons we can, the 3.0.0 are also beautiful but we need a lot more of symbols?
Is there a way to include some icons from 2.0.1 in project to use also with  or buttons or something else? We don't need ios icons we need only md icons.
thx

Ionicons.com has not yet been updated w/ Ionicons v3, which Ionic2 uses.
You can browse the v3 icons at http://ionicframework.com/docs/v2/ionicons/


resolves #93 implement the other optimizers

Implement the following optimizers:

[x] Gradient Descent Deep Learning Optimizer
[x] Stochastic Gradient Descent Deep Learning Optimizer
[x] Stochastic Gradient Descent With Momentum Deep Learning Optimizer
[x] Mini Batch Gradient Descent Deep Learning Optimizer
[x] Adagrad (Adaptive Gradient Descent) Deep Learning Optimizer
[x] RMS Prop (Root Mean Square) Deep Learning Optimizer
[x] AdaDelta Deep Learning Optimizer

Reference: https://www.analyticsvidhya.com/blog/2021/10/a-comprehensive-guide-on-deep-learning-optimizers/

Looks good, but we don't need to add ndarray to workspace dependencies since we only use it in delta library. I only added workspace dependencies that is also used in examples. If we add more libraries in the future in this repo we should add shared dependencies in workspace Cargo.toml file.
But I will merge it for now, we can change it later.

Oh dangit, that was my bad. For some reason my editor wasn't recognizing ndarray and I tried to reinstall it, but I must have been in the wrong directory.


Windows final cli tests

@Anton-4 all cli tests should pass (a couple are ignored) on this PR. Could we run those (or perhaps a subset) on CI?

Sure, I'll update the workflow file :)

The windows exit code<PHONE_NUMBER> appears to be for STATUS_ACCESS_VIOLATION; requesting access for memory without proper authority. I'll see if I can reproduce this locally.

ok if you run things locally, maybe you can also see if the cli formatting tests work? I think they depend on your git settings for line endings.

looks like there are a couple of issues still

the formatting tests fail. But if you run the formatter once on the files, there are no changes in git and after that the tests pass. That makes   me believe that it is a whitespace issue. Not sure how to fix that, maybe just remove all \r characters before doing the "did formatting change anything" check?
the benchmarks and several others return a bad status (but we don't print which status code they return)
-for building the more advanced rust platforms we now need the nightly toolchain on windows:  rustup toolchain install nightly

but also, 18 tests are already passing, good progress!

Yeah, I expected some failures, I'll try to finish this up today :)
btw nightly is already being installed with rustup install nightly-2022-08-06

@folkertdev all cli_run tests pass locally now, this also means I can't reproduce the<PHONE_NUMBER> error.
I should be able to set up a windows CI machine next week, so I propose we merge this (assuming all checks pass now) and enable all cli_run tests when the CI machine is ready.
I've currently enabled a subset of cli_run tests that worked.

sounds good. I added a helper that should print the command in a more readable way (that can be copy-pasted into a shell, too)

Neat :+1:


feat(Input): add autoCorrect to Input props

Fixes #1572.

Codecov Report

Merging #1573 into master will decrease coverage by 0.08%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1573      +/-   ##
==========================================
- Coverage   99.74%   99.66%   -0.09%
==========================================
  Files         141      141
  Lines        2381     2381
==========================================
- Hits         2375     2373       -2
- Misses          6        8       +2

Impacted Files
Coverage Δ

src/modules/Search/Search.js
98.96% <0%> (-1.04%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 68b08a6...304eeb3. Read the comment docs.

Thanks @layershifter - this works for me.

Released in<EMAIL_ADDRESS>


Script execution truncated

System information:

Windows 10 Pro
DBeaver  <IP_ADDRESS>009201907
Additional extensions

Connection specification:

Driver: Oracle OJDBC10.jar

Describe the problem you're observing:
I'm trying to execute an SQL script (Alt+X) file which is supposed to create an Oracle SQL package (with Oracle driver). The script execution is resulting in an SQL execution error and when I look at the execution log, I can see that the real text taken into account is missing chars at the end.
Steps to reproduce, if exist:
Here is an example of Oracle SQL script file (grammatically correct in PL-SQL)
CREATE OR REPLACE PACKAGE BODY my_package AS

procedure my_proc as
begin
null;
end my_proc;

END my_package;

And here is what's really executed (Alt+X)
CREATE OR REPLACE PACKAGE BODY my_package AS

procedure my_proc as
begin
null;
end my_proc;

Here the last line «END my_package;» is missing...

Thank you for the report.

I have a similar issue using DBeaver IDE <IP_ADDRESS>010041557 in Eclipse 2020-09 (4.17.0) with HSQLDB as database.
CREATE TRIGGER TRI_CODE_SYSTEM
BEFORE INSERT ON CODE_SYSTEM
REFERENCING NEW AS NEWROW FOR EACH ROW
BEGIN ATOMIC
IF TRUE THEN
SIGNAL SQLSTATE '45000';
END IF;
END;
The "execute SQL script" command skips the last END; when sending the code to the database.  The "execute SQL statement" command works, but I have to run each statement in the script one by one.
Cheers
/Robert

As a workaround you can use Ctrl+Enter on the selected area instead of Alt+X

Close as duplicate: https://github.com/dbeaver/dbeaver/issues/8095


Correct a typo in a person's name in the ligature module readme

Throughout the readme in the ligatures module there were two different spellings of the name Mitsuharu Yamamoto who maintains emacs-mac.

Thanks for the PR, but I must refuse it. There is nothing wrong with your PR, but it comes at a bad time: I'm about a week away from pushing a rework of all our documentation, which also reworks documentation for each module, including this one (which includes the correct spelling of Mitsuharu's name). As this indirectly fixes this issue and would swallow up your PR anyway, I'll simply wait for that update instead. In any case, thanks for your help!


Add TextField

Currently, it seems that changing the text binding doesn’t actually affect the rendered input. I’m not sure why this happens, but I’m guessing it’s because the value attribute isn’t being set as <input>.value.

Looks like Danger is failing at least because it can’t access the GitHub token since this PR comes from a fork.

Thanks for the PR, I'll have a look a bit later today! danger-lint failing is a known issue, I'll turn it off in main so that this doesn't confuse anyone anymore.

I think the text binding issues may be caused by bugs in the State/Binding code, investigating now...

Turns out it's not a state/binding issue, but a more prosaic oversight that's fixed in #117.

Is there a way to hook into the update function? I need to update the actual value property of the input element, not the value attribute.

Is there a signifcant difference? I've tested your branch locally with #117 applied on top of it and it worked, or am I missing something?

If you type in both fields they will stop updating.

huh, good point, on it...

I updated #117 to update properties, not attributes, so should work now when combined with this PR.

Is it intentional that VStack can have a max of 10 children?

Updated. Note that the newly added text field is still editable despite that not being the intention.

@j-f1 This is a limitation of the ViewBuilder, and is present in SwiftUI as well. ViewBuilder takes in arguments and builds a TupleView which is generated to have up to 10 children. If you use ForEach or a Group you can go past that limit.

OK cool I reviewed native SwiftUI and the text field’s behavior is the same there 🤷

I tried to implement the other TextField initializer but it looks like Foundation (and therefore the required Formatter) are not yet available?

I dislike the way the SecureField is largely a copy-paste of TextField but I can’t think of a better way since you can’t extend structs.

Could you do a protocol that has all the fields and a isSecure flag?

Foundation is available if you build the package in a special way, but I'd like to avoid it as much as possible. It's a huge dependency, and I'm afraid that even when SwiftWasm has dead code elimination working properly, I'm not sure we'll be able to strip out unused bits of Foundation cleanly, especially due to how big it is and how it also proxies a lot of stuff to CoreFoundation. On the other hand, without Foundation we won't get the Date type, which would be frustrating.
We need to tweak carton so that it links Foundation automatically, but I think for now, please leave out the bits that require Foundation, and maybe add a comment about what's missing.

Could you do a protocol that has all the fields and a isSecure flag?

I gave that a try and it didn’t cut down on the duplication a ton.

SwiftUI doesn't use a protocol, and if it's good enough for Apple then it's good enough for me 😄


Moving the face in rendering window

Hi
I hope you are doing well.
I have a question about that why the face is moving when the speaker starts to talk, I mean the rendered face is moving not just the lips. Could you answer me, please?
Regards

Hi,
I'm not sure what you mean. The head is rotating, yes. But the translation is set to zero.

Hi
Thanks for replying. What I meant is that the rendered mesh is moving not just the lips (all the head is moving according to the lips movements. ), I mean it is not as the speaker do when start talking, in usual the head is static, but the lips is moving.
Regards

Ok, I think I maybe see what you mean now. You could use draw_wireframe(...) on the original image to verify the fitting results.
I think what you want is maybe better blendshapes, that don't just model expressions, but lip movements.

Thanks. I used draw_wireframe(...), but I still have the same problem.

draw_wireframe(...) is only for inspecting, obviously. As mentioned above you may want to use some blendshapes that model lip movements.

My model contains different lip shapes already, so I do not need to add them separately.

Ok, cool! Well, then I guess you need to find out why it happens? ;-)


Should we use using the AzureAz module?

As the subject? This is now release and preferred to Azure AD

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

 Do you need to run AzureAD and AzureAZ side-by-side? Is that even possible?

Ok the above is relate to #765 as you stated that "PS version 5.1 or higher" should be use, but PS 6/7 is not supported :(
Still, I guess Azure Az will be the future here?

Article updated to include installing the AzureAz module as an alternative to the separate Azure Active Directory PowerShell for Graph. Thanks for letting us know.


why Big Sur only?

Any reasoning behind this? How hard is to compile it for lower OS(rhetorical question)

Yes, the SwiftUI features it uses are only available on Big Sur.

Which features exactly, I just want to understand why are those so crucially important to use over Millions of potential Mojave and Catalina users.

@foxnoodles SwiftUI features, bruh

@foxnoodles SwiftUI features, bruh

Well Bruh... what exactly stops him from compiling for Mojave or Catalina bruh? SwiftUI runs fine on those... if you mean the development side (previews and canvas) you could do it on Catalina too so what's the deal Bruh? Enlighten me Bruh...

There is so many things in the SwiftUI version of Big Sur that I can't even begin to list them. There is toolbar support, proper NavigationView support, all the new SF Symbols and so on. It's a bleeding edge app for the most updated version of macOS. I have 0 incentive to make or maintain an app for an older version of it. Deal with it.

Dude your 8 yr old or something? Deal with it?  At least 50% of Mac users to be exact so chill you haven't even made it yet.

In German I would ask: Kann das sein, dass du dumm bist?
This is an open source project, done in @Dimillian's free time. It is a project to demonstrate SwiftUI on Mac OS (read the README.md). I don't know why there is a dude blaming an other dude for not supporting what he wants.
I've an advise for you: develop your own version of the app matching your needs.

@foxnoodles feel free to open a PR targeting lower macOS versions, we’ll be waiting.

what exactly stops him from compiling for Mojave

if I recall correctly you can run SwiftUI in the iOS 13 simulator (and so you could use Previews too) in Xcode 11 on Mojave, but SwiftUI on macOS targets 10.14 Catalina. So I don't think this is an option at all.

or Catalina

As the author already mentioned, there is a bunch of new API in SwiftUI on Big Sur, as well as behaviour changes. I'm not sure if you've done any SwiftUI development yet, but the API and behaviour has changed a lot on all of the platforms (much more than most Apple APIs do) since it was first released. This is good, because a lot of bugs are being fixed and improvements are being made, but also bad because it takes a lot of work as a developer to keep up, let alone also maintain backwards compatibility. For a project like this, I would imagine that means the difference between the project existing at all or not. It is not simply a matter of flipping the Catalina switch to on.

@foxnoodles, I really hope you can take a step back and reconsider how you're talking to other people in this thread. This project is one of the few open source examples of an entire SwiftUI app on macOS. I'm not involved with it at all, but I've been referencing it as I work on my own SwiftUI on macOS project (which also targets Big Sur, for the same reason). It's been provided free of charge, and you're not owed anything. If you genuinely want to discuss how to handle backwards compatibility with SwiftUI on macOS, or learn how you can contribute to this project to improve something, now's your chance. Otherwise it would save everyone here a lot of time if you just dropped it.

Kann das sein, dass du dumm bist?

In Georgian I would reply: "მოგიტყან ნაცისტი დედის მუტელი" ...as nobody cares about your language here
Speaking of stupidity, I'm no asking to support what I want mr. braindead. I'm rhetorically implying that no matter what this project is trying to achieve it does not make any sense when it ignores the majority of user-base. And btw "make your own" "code your own" answers are like from 2000s... You should really grow up. I don't have nor will I code anything to prove my point lol.  Right.. also downvotes are for morons who think that actual living human beings care about them. You being one of those. Now square.

what exactly stops him from compiling for Mojave

if I recall correctly you can run SwiftUI in the iOS 13 simulator (and so you could use Previews too) in Xcode 11 on Mojave, but SwiftUI on macOS targets 10.14 Catalina. So I don't think this is an option at all.

or Catalina

As the author already mentioned, there is a bunch of new API in SwiftUI on Big Sur, as well as behaviour changes. I'm not sure if you've done any SwiftUI development yet, but the API and behaviour has changed a lot on all of the platforms (much more than most Apple APIs do) since it was first released. This is good, because a lot of bugs are being fixed and improvements are being made, but also bad because it takes a lot of work as a developer to keep up, let alone also maintain backwards compatibility. For a project like this, I would imagine that means the difference between the project existing at all or not. It is not simply a matter of flipping the Catalina switch to on.
@foxnoodles, I really hope you can take a step back and reconsider how you're talking to other people in this thread. This project is one of the few open source examples of an entire SwiftUI app on macOS. I'm not involved with it at all, but I've been referencing it as I work on my own SwiftUI on macOS project (which also targets Big Sur, for the same reason). It's been provided free of charge, and you're not owed anything. If you genuinely want to discuss how to handle backwards compatibility with SwiftUI on macOS, or learn how you can contribute to this project to improve something, now's your chance. Otherwise it would save everyone here a lot of time if you just dropped it.

Thanks for the actual explanation. I was actually wondering if there are any major additions to the newest SwiftUI that lead to the decision of targeting the 1 month old OS (which has arguably the worst adoption rate since Yosemite) and completely losing any traction before even having a stable release. The reason behind my curiosity is to determine how serious the author is about his intentions to develop and maintain an actual product and judging by the audience and authors attitude and product design vision I pretty sure this won't get anywhere big.
As for "something being free on github so nobody should complain about it " - I certainly disagree with that mindset and trust me once you get traction with your project you as a product owner are morally obligated to listen to your user-base. Or else you will lose them.  That's why stuff like Blender exists and BigSur only Reddit Clients don't.
Also as you probably noticed I can change my tone of voice freely at any time, it just depends who and how replies back.
That being said not that I care about "bruh deal with it and here's the thumbs down" kind of infantile beta males time but I do care about yours and mine so Imma close this one. Happy new year btw.


Broken vocabulary creation

When building vocabulary (by calling bblock.main, RAM usage shoots up and consumes all memory, forcing me to close down vocabulary creation.
It happens after all the documents are loaded and saving is about to happen.
After investigating the underlying issue it seems that the problem is conversion of Entry dataclass into dict. More specifically Entry dataclass contains reference to its Vocabulary as a property which I think creates a problem because it copies the Vocabulary object somewhere, causing an explosion of usage in memory.
I propose removing the reference to Vocabulary object in the Entry dataclass entirely and adapting the code where the entry's reference to its vocabulary is used (which seems to be two idf methods in token.py) OR creating a custom class (not dataclass) which wouldn't return dictionary with the reference to the vocabulary.

Is this for development branch ?
Hüsnü Şensoy / VLDB Expert
<EMAIL_ADDRESS>[image: Global Maksimum Data & Information Tech]
Global Maksimum Data & Information Tech
+902162506637 / +902162506600
Acıbadem Mah. Çeçen Sk. Akasya Kule A-3
No:25 Kat:14 34660 Üsküdar, İstanbul Türkiye
[image: LinkedIn] https://htmlsig.com/t/0000001BRGEK6 [image: Instagram]
https://htmlsig.com/t/000001DZYDYM [image: Github]
https://htmlsig.com/t/000001DDAY0N
On Mon, Oct 26, 2020 at 8:00 PM Askar Bozcan<EMAIL_ADDRESS>wrote:

When building vocabulary, RAM usage shoots up and consumes all memory,
forcing me to close down vocabulary creation.
After investigating the underlying issue it seems that the problem is
conversion of Entry dataclass into dict. More specifically Entry dataclass
contains reference to its Vocabulary as a property which I think creates a
problem because it copies the Vocabulary object somewhere, causing an
explosion of usage in memory.
I propose removing the reference to Vocabulary object in the Entry
dataclass entirely and adapting the code where the entry's reference to its
vocabulary is used (which seems to be two idf methods in token.py) OR
creating a custom class (not dataclass) which wouldn't return dictionary
with the reference to the vocabulary.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/GlobalMaksimum/sadedegel/issues/156, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJVFRSZOSQWSSDUZMSJIYDSMWTJLANCNFSM4S7UZP7A
.

Yes.

Haven't tested yet but I will.
Hüsnü Şensoy / VLDB Expert
<EMAIL_ADDRESS>[image: Global Maksimum Data & Information Tech]
Global Maksimum Data & Information Tech
+902162506637 / +902162506600
Acıbadem Mah. Çeçen Sk. Akasya Kule A-3
No:25 Kat:14 34660 Üsküdar, İstanbul Türkiye
[image: LinkedIn] https://htmlsig.com/t/0000001BRGEK6 [image: Instagram]
https://htmlsig.com/t/000001DZYDYM [image: Github]
https://htmlsig.com/t/000001DDAY0N
On Mon, Oct 26, 2020 at 11:29 PM Askar Bozcan<EMAIL_ADDRESS>wrote:

Yes.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/GlobalMaksimum/sadedegel/issues/156#issuecomment-716804312,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJVFRXEBN3TBZ4GM3H5W73SMXL3BANCNFSM4S7UZP7A
.

We now build 3 vocabularies without an issue.


added half-stars and rounding to closest half

I need to have half-starts for some average of ratings and they exist in font awesome.
I modified the bundle to round to the closest half and show half-stars.
Comments welcome!

@pije76  sorry for the delay.  I'll review this pull request tomorrow and see if i can fix some of the conflicts with the current branch.


UMLS:C1562036 is not resolving

In the BTE results linked here, (https://arax.ncats.io/?r=5f949fee-e4aa-4200-97e1-29e573e158ba), the second result is not resolving. It's UMLS:C1562036.

This is "Calcineurin Inhibitors".  It looks like should merge with MESH:D065095.  @gaurav does this resolve in the dev build?

It does resolve in the dev build, but only as one of the leftover UMLS IDs (https://nodenormalization-dev.apps.renci.org/1.3/get_normalized_nodes?curie=UMLS%3AC1562036&conflate=true). Strangely, although MESH:D065095 exists in NameRes (POST https://name-resolution-sri.renci.org/lookup?string=Calcineurin Inhibitors&offset=0&limit=10), it does not exist in the prod NodeNorm (https://nodenorm.transltr.io/1.3/get_normalized_nodes?curie=MESH%3AD065095&conflate=true). I will investigate this further.


gsub is not working correctly

jq works as I expected from bash:
$ jq '.name|gsub("\\s+";"-")' <<< '{"name": "sample json"}'
"sample-json"

but not the same from ruby-jq:
> require 'jq/extend'
> {name: 'sample json'}.jq('.name | gsub("\\\\s+";"-")')
 => ["-"]

Please use jq 1.6 shared library.
ver 1.7 automatically downloads jq 1.6. see https://github.com/winebarrel/ruby-jq/pull/7
irb(main):007:0> JQ::VERSION
=> "0.1.7"
irb(main):008:0> {name: 'sample json'}.jq('.name | gsub("\\\\s+";"-")')
=> ["sample-json"]
``