DRM Protected

Udeler | Udemy Course Downloader
1.12.7
Account Type?
Personal
Steps to reproduce
when I try to download the videos I get the DRM Protected error.
I have tried with other versions where it appears that the problem is fixed but the error is the same,
✔ Expected Behavior
I was hoping that with some version it could be fixed
🔍 Additional context
No response

I have the same problem.

Tengo el mismo Problema

Guys, unfortunately this is not a tool error, Udemy has been encrypting their courses for some time, making it impossible for Udeler to download them.
The only known alternative is https://github.com/Puyodead1/udemy-downloader
Good luck


Can't check if refresh token is revoked

I've got this code
try {
    $session->refreshAccessToken($code);
} catch (SpotifyWebAPIAuthException $e) {
    echo 'Spotify API Error: ' . $e->getCode(); // Will be 404
}

but it doesn't work. When a refresh token has been revoked, I get an internal server error which states "Refresh token revoked", however, I cannot catch this error to do a specific action when this happens.

Nevermind


Docs: add a callout for $app global

I couldn't find the $app global and ended up asking in discord. I thought it might be nice to add a mention in the docs.

Closing since this exists elsewhere and should just be linked from here.


pull request for e2e test at 12/30/2016 14:45:08

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


NumberFormatException

Please enter the filepath to the first image
in sequence (.CR2 file including extension)
Path: C:\Users===\Pictures\2018\2018-07-08_MG_0006.CR2
Exception in thread "main" java.lang.NumberFormatException
: For input string: ":ns:meta/"
at java.lang.NumberFormatException.forInputString(Unknown Source)
at java.lang.Integer.parseInt(Unknown Source)
at java.lang.Integer.parseInt(Unknown Source)
at proRAW
.getImageData(proRAW.java:186)
at proRAW.retrieveData(proRAW.java:74)
at proRAW.(proRAW.java:41)
at proRAW.main(proRAW.java:387)

It seems to be getting this error when it's loading every image into the Image class.
 (It looks like it's getting the error on the first line of the first XMP file it has to load)

I'm having this same issue, has anyone been able to solve this? It would be greatly appreciated


cleanup harness code (part 2)

removed program from CompilationOutput since it is already available as in CompilerResult
dropped extra HarnessCompiler namespace so compileFiles and compileDeclarationFiles are directly in Compiler namespace
removed unused code.
defer initialization of line map in HarnessLanguageService since it showed up on perf traces

:+1:


[bug]: Test Suite Fails to Run due to Missing<EMAIL_ADDRESS>Module

Description
Hello,
I've encountered an issue when trying to run my test suite. The test suite fails to run, throwing an error that it cannot find the module<EMAIL_ADDRESS>The error message is as follows:
Test suite failed to run

Cannot find module<EMAIL_ADDRESS>from<EMAIL_ADDRESS>
Require stack:
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>  src/providers/wallet-connect-provider.tsx
  src/helpers/test-utils.tsx
  src/__tests__/example.tsx

Any help would be greatly appreciated. Thanks!
WalletConnect Modal SDK version
1.0.0-rc.6
Output of npx react-native info
System:
    OS: Windows 10 10.0.22621
    CPU: (8) x64 AMD Ryzen 5 3500U with Radeon Vega Mobile Gfx
    Memory: 1.26 GB / 6.94 GB
  Binaries:
    Node: 16.18.1 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.10 - ~\AppData\Roaming\npm\yarn.CMD
    npm: 8.19.2 - C:\Program Files\nodejs\npm.CMD
    Watchman: 20210110.135312.0 - C:\ProgramData\chocolatey\bin\watchman.EXE
  SDKs:
    Android SDK:
      API Levels: 28, 29, 30, 31, 33
      Build Tools: 28.0.3, 29.0.2, 29.0.3, 30.0.2, 30.0.3, 31.0.0, 32.0.0
      System Images: android-29 | Intel x86 Atom_64, android-30 | Google APIs Intel x86 Atom, android-30 | Google Play Intel x86 Atom, android-31 | Intel x86 Atom_64, android-31 | Google APIs Intel x86 Atom_64
      Android NDK: Not Found
    Windows SDK:
      AllowAllTrustedApps: Disabled
      Versions: 10.0.17763.0, 10.0.19041.0
  IDEs:
    Android Studio: Version  <IP_ADDRESS> AI-201.87<IP_ADDRESS>99119
    Visual Studio: Not Found
  Languages:
    Java: 11.0.15 - C:\Program Files\OpenJDK\openjdk-11.0.15_10\bin\javac.EXE
  npmPackages:
    @react-native-community/cli: Not Found
    react: 18.2.0 => 18.2.0
    react-native: 0.71.8 => 0.71.8
    react-native-windows: Not Found
  npmGlobalPackages:
    *react-native*: Not Found

Expo Version (if applies)
Expo: ~48.0.9
Steps to reproduce
This occurs when I run:
yarn jest --detectOpenHandles
Snack, code example, screenshot, or link to a repository
jest-setup.js:
import mockSafeAreaContext from "react-native-safe-area-context/jest/mock";

export * from "@react-native-async-storage/async-storage/jest/async-storage-mock";

jest.mock("@react-native-async-storage/async-storage", () =>
  require("@react-native-async-storage/async-storage/jest/async-storage-mock"),
);

jest.mock("react-native-safe-area-context", () => mockSafeAreaContext);

global.__reanimatedWorkletInit = () => {};
jest.mock("react-native-reanimated", () =>
  require("react-native-reanimated/mock"),
);

jest.mock("@react-native-firebase/analytics", () => {
  return {
    setUserId: jest.fn(),
    logScreenView: jest.fn(),
  };
});

jest.config.json
{
  "preset": "jest-expo",
  "moduleFileExtensions": ["ts", "tsx", "js", "jsx", "json", "node"],
  "transformIgnorePatterns": [
    "node_modules/(?!((jest-)?react-native|@react-native(-community)?)|expo(nent)?|@expo(nent)?/.*|@expo-google-fonts/.*|react-navigation|@react-navigation/.*|@unimodules/.*|@sentry/.*|unimodules|sentry-expo|native-base|react-native-svg|@react-native-firebase/.*|@walletconnect/.*)"
  ],
  "setupFiles": ["./jest-setup.js"],
  "setupFilesAfterEnv": ["@testing-library/jest-native/extend-expect"],
  "testMatch": ["**/__tests__/**/*.[jt]s?(x)", "**/?(*.)+(spec|test).[jt]s?(x)"]
}

package.json:
{
  ...,
  "dependencies": {
    "@expo-google-fonts/inter": "^0.2.2",
    "@expo/config-plugins": "~6.0.0",
    "@expo/metro-config": "^0.3.16",
    "@expo/vector-icons": "^13.0.0",
    "@flyerhq/react-native-link-preview": "^1.6.0",
    "@gorhom/bottom-sheet": "5.0.0-alpha.0",
    "@react-native-async-storage/async-storage": "^1.18.2",
    "@react-native-community/hooks": "^2.8.1",
    "@react-native-community/netinfo": "9.3.7",
    "@react-native-firebase/analytics": "^17.3.1",
    "@react-native-firebase/app": "^17.3.1",
    "@react-native-firebase/dynamic-links": "^17.3.1",
    "@react-native-firebase/storage": "^17.3.1",
    "@react-native-masked-view/masked-view": "^0.2.9",
    "@react-navigation/bottom-tabs": "^6.4.0",
    "@react-navigation/drawer": "^6.5.8",
    "@react-navigation/native": "^6.0.13",
    "@react-navigation/native-stack": "^6.1.0",
    "@react-navigation/stack": "^6.3.2",
    "@reduxjs/toolkit": "^1.8.1",
    "@rneui/base": "^4.0.0-rc.7",
    "@rneui/themed": "^4.0.0-rc.7",
    "@sentry/react-native": "4.9.0",
    "@shopify/flash-list": "1.4.0",
    "@walletconnect/jsonrpc-types": "^1.0.3",
    "@walletconnect/modal-react-native": "^1.0.0-rc.6",
    "@walletconnect/utils": "^1.8.0",
    "axios": "^0.27.1",
    "crypto-browserify": "^3.12.0",
    "eth-sig-util": "^3.0.1",
    "ethers": "^5.6.4",
    "expo": "~48.0.9",
    "expo-application": "~5.1.1",
    "expo-asset": "~8.9.0",
    "expo-av": "~13.2.1",
    "expo-barcode-scanner": "~12.3.1",
    "expo-blur": "~12.2.2",
    "expo-build-properties": "~0.5.1",
    "expo-camera": "~13.2.1",
    "expo-clipboard": "~4.1.1",
    "expo-constants": "~14.2.1",
    "expo-crypto": "~12.2.1",
    "expo-dev-client": "~2.1.3",
    "expo-device": "~5.2.1",
    "expo-file-system": "~15.2.2",
    "expo-font": "~11.1.1",
    "expo-haptics": "~12.2.1",
    "expo-image": "^1.2.3",
    "expo-image-manipulator": "~11.1.1",
    "expo-image-picker": "~14.1.1",
    "expo-linear-gradient": "~12.1.1",
    "expo-linking": "~4.0.1",
    "expo-media-library": "~15.2.2",
    "expo-notifications": "~0.18.1",
    "expo-splash-screen": "~0.18.1",
    "expo-status-bar": "~1.4.4",
    "expo-system-ui": "~2.2.1",
    "expo-task-manager": "~11.1.1",
    "expo-updates": "~0.16.3",
    "expo-video-thumbnails": "~7.2.1",
    "expo-web-browser": "~12.1.1",
    "immer": "^9.0.19",
    "jwt-decode": "^3.1.2",
    "lodash": "^4.17.21",
    "lottie-react-native": "5.1.4",
    "moment": "^2.29.3",
    "moment-timezone": "^0.5.40",
    "moti": "^0.18.0",
    "node-libs-react-native": "^1.2.1",
    "react": "18.2.0",
    "react-dom": "18.2.0",
    "react-native": "0.71.8",
    "react-native-blob-util": "^0.17.0",
    "react-native-collapsible-tab-view": "^6.1.4",
    "react-native-compressor": "^1.6.1",
    "react-native-controlled-mentions": "^3.0.0-alpha.4",
    "react-native-date-picker": "^4.2.13",
    "react-native-device-info": "^9.0.2",
    "react-native-draggable-flatlist": "^4.0.0",
    "react-native-gesture-handler": "~2.9.0",
    "react-native-get-random-values": "^1.9.0",
    "react-native-image-crop-picker": "^0.38.0",
    "react-native-image-viewing": "^0.2.2",
    "react-native-keyboard-aware-scroll-view": "^0.9.5",
    "react-native-modal": "^13.0.1",
    "react-native-pager-view": "^6.2.0",
    "react-native-reanimated": "^3.0.2",
    "react-native-root-siblings": "^4.1.1",
    "react-native-safe-area-context": "4.5.0",
    "react-native-screens": "~3.20.0",
    "react-native-share": "^8.0.1",
    "react-native-size-matters": "^0.4.0",
    "react-native-splash-screen": "^3.3.0",
    "react-native-svg": "^13.9.0",
    "react-native-tab-view": "^3.2.1",
    "react-native-toast-message": "^2.1.5",
    "react-native-web": "~0.18.11",
    "react-query": "^3.39.3",
    "react-redux": "^8.0.1",
    "react-string-replace": "^1.1.0",
    "redux": "^4.2.0",
    "redux-logger": "^3.0.6",
    "redux-persist": "^6.0.0",
    "redux-persist-transform-filter": "^0.0.20",
    "sentry-expo": "~6.0.0",
    "socket.io-client": "^4.5.0",
    "url-parse": "^1.5.10",
    "uuid": "^8.3.2",
    "vm-browserify": "^1.1.2",
    "with-rn-image-crop-picker": "^0.2.0"
  },
  "resolutions": {
    "react-native-svg": "13.9.0"
  },
  "devDependencies": {
    "@babel/core": "^7.20.0",
    "@react-native-community/eslint-config": "^3.0.1",
    "@testing-library/jest-native": "^5.4.2",
    "@testing-library/react-hooks": "^8.0.1",
    "@testing-library/react-native": "^12.1.2",
    "@types/jest": "^29.2.1",
    "@types/lodash": "^4.14.182",
    "@types/qs": "^6.9.7",
    "@types/react": "~18.0.27",
    "@types/react-dom": "~18.0.10",
    "@types/react-native": "^0.72.2",
    "@types/url-parse": "^1.4.8",
    "@types/uuid": "^8.3.4",
    "@typescript-eslint/eslint-plugin": "^5.23.0",
    "babel-plugin-module-resolver": "^4.1.0",
    "babel-plugin-transform-inline-environment-variables": "^0.4.4",
    "babel-plugin-transform-remove-console": "^6.9.4",
    "concurrently": "^8.1.0",
    "eslint": "^8.42.0",
    "eslint-config-airbnb": "19.0.4",
    "eslint-config-prettier": "^8.8.0",
    "eslint-config-universe": "^11.2.0",
    "eslint-plugin-import": "2.26.0",
    "eslint-plugin-jsx-a11y": "6.5.1",
    "eslint-plugin-react": "7.29.4",
    "eslint-plugin-react-hooks": "^4.6.0",
    "husky": "^8.0.0",
    "jest": "^29.2.1",
    "jest-expo": "^49.0.0",
    "lint-staged": "^13.0.4",
    "prettier": "^2.6.2",
    "react-query-native-devtools": "^4.0.0",
    "react-test-renderer": "18.2.0",
    "ts-jest": "^29.1.1",
    "tsc-files": "^1.1.3",
    "typescript": "^4.9.4"
  },
}

Hi @MBedy 👋 this should work now on 1.0.0-rc.13. If it doesn't work yet, please reach out


Support stability definitions from OTEP 232

Part of https://github.com/open-telemetry/semantic-conventions/issues/1096
We need to include new maturity levels formally defined in OTEP 232:

Development - new one that replaces experimental. We should support experimental, but treat it as developement
Alpha - new
Beta - new
Release Candidate - new
Stable - no change
Deprecated - no change (not a stability level from the semconv schema perspective)
Unmaintained - don't add for now

This would mean:

extending the stability enum to cover new members
update is_experimental filter to cover all maturity levels (i.e. return true for all levels except stable)
update schema definition to list all new possible values

@lmolkova - I can do this one. Set me as the assignee if you like??

@jerbly thank you, really appreciate your help!

Made #504 - hopefully this is what you had in mind. 🤞


Draggable element is not following the mouse when a parent element is scaled

When a draggable object is inside a scaled element (e.g. via css tranform scale) then the draggable element won't follow the mouse correctly during dragging.
https://codepen.io/anon/pen/mXKzdv

Thanks for reporting this issue. Yup! That will happen. Sorry, Draggabilly will not cover this use case.


Remove assumptions about course structure.

Just look for categories instead of making assumptions about depth
JIRA: https://openedx.atlassian.net/browse/MA-302
@BenjiLee please review

:+1:


CP437 "low ASCII" characters not working in the v2 console

Your Windows build number:

Microsoft Windows [Version 10.0.16299.371]

What you're doing and what's happening:

If you look at the full character set for code page 437, there are a number of useful symbols in the "control" range (for example, the symbols for card suits), which were commonly used in text-based games from the DOS era. I was just trying to use some of these recently, and noticed that they no longer work in the new console.
I thought at first this was a problem with the Consolas font, since they do work with the old Raster fonts, but I then tried using the Consolas font in the legacy console, and was surprised to find that they work there too. So there's obviously something the old console is doing to support those characters that is missing in the v2 console.
Below you can see a simple test case comparing the v2 console with Raster fonts (left), the legacy console with the Consolas font (middle), and the v2 console with the Consolas font (right).

In case it's not obvious, the characters being echoed are entered with the Ctrl key, i.e. Ctrl+B, Ctrl+D, etc.

What's wrong / what should be happening instead:

When code page 437 is selected (or one of the regional equivalents) I would expect the characters in the control range to display their correct symbol as defined by the code page (assuming of course that the character isn't actually functioning as a control character).

This is by-design. Legacy mode is required to run those old DOS things. The console team is trying to move away from that old stuff and get into the new such as getting UTF-8 vice UTF-16, somewhat implementing xterm, etc. due to the feedback they've gotten from the community. We don't want the old stuff so if you need it, that's what legacy mode is for.

I mean, as the person who pulled it out, it's by design at that point in time because it made my life more difficult in terms of the other changes I was trying to make to update the rest of the console code.
The way this worked was that it kept an in-memory display canvas of those symbols out of the raster font and tried to stitch them into every other font that used them.
If there were enough demand, we could theoretically re-add it somehow. Probably by attempting to remap them to a Unicode codepoint for each of those symbols behind a checkbox that lets you turn it on or off. But I'm pretty sure demand overall is low as this is the first report I've heard of this in the 3 to 4 years since I took it out. For now, I'd advise using the legacy mode to get at this behavior.
But to one extent, @DarthSpock is right. Implementing UTF-8 is currently a higher priority to us than maintaining or reimplementing support for this particular feature. If more people vocally want this than UTF-8, we can switch gears. :P But I doubt that.

@miniksa: Based on your response, I think you may not have understood the limited conditions under which I was expecting this to work. So just to clarify:

I wasn't expecting these characters to work when utf-8 was selected as the code page - I only expected them to work if the selected code page had actually defined symbols for those code points. They don't work in the legacy console when utf-8 is selected either.

I also wasn't expecting them to work with fonts that don't have those glyphs. But Consolas certainly does, and I expect most other fonts would too, considering all those characters are included in WGL4. So I wasn't expecting font fallback to the raster fonts - I assumed it was simply a matter of mapping those code points to existing symbols in the active font, much like you'd be doing for the rest of the characters in the code page.

That said, I can understand if you're just saying this isn't a priority at the moment. I can also accept that it may be a lot more complicated than it appears to an outsider. I just wanted to be sure you hadn't misinterpreted my request.

Sorry I think I'm miscommunicating or mixing the two things here. Let me try a bulleted list of things to see if that helps.

I didn't mean to imply that the low ASCII characters ever worked in UTF-8 or that you expected it. My apologies.
The console has never had true UTF-8 support. It still doesn't. There's a lot of pieces that still don't work right despite setting 65001 and using some of our APIs.
My description above is in relation to how the feature that used to exist was implemented. It was implemented in the arguably "wrong" way as a strange stitching of raster font glyphs into TrueType fonts. This happened before my time and was a headscratcher to stare down.
The arguably "right" implementation is what you describe: to remap the codepoints to where they already exist in the TrueType fonts. If they're in the fonts, use them. If they're not, the font can display its replacement character and the user can choose a font with them if they want to see them.
The "wrong" implementation itself was a liability in working on other features that we've added in the last several releases of Windows. So I took it out. We knew when I took it out that it would impact a few people and that the stated response would be "use legacy mode if you want that feature".
Replacing it with the "right" implementation ranks too low on our list of priorities to perform at this time.
I am giving "implementing proper UTF-8 support" as an example of a work item that is very high on our list of priorities and is currently being worked on. Completely orthogonal to this feature of "(re)implement drawing low ASCII characters in 437 by remapping them to the correct codepoints" which is very low on our priority list.
To raise it up on our priority list, we would need a massive outcry on Github, Feedback Hub, or through other channels to signal that we should raise the feature up on our list. We haven't seen any real signal at all that people noticed it was gone until this thread. We'll probably go bump the rank a few points in response to this thread, but it isn't really a "big" deal yet and has a simple workaround (versus some of our other ranked features).
It is a touch more complicated internally than it appears to an outsider. It would be way more clear to you what happened here if you could see the pile of source code and our task board ranking.

We'd love to have time to implement everything that people are concerned with, but the team and I do not. I just want to be honest: this was removed from the new console on purpose, we believe the legacy console is a sufficient workaround for now, fixing this exists on our backlog, we know about it, we have an idea of how we'd fix it, but it is currently ranked too low relative to other features.
I hope this helps clarify it.

I must admit that considering NTVDM isn't supported on x64 old DOS apps aren't supported anyway, and I don't see many Win32 CUI apps that would get impacted.
There is a workaround for impacted apps by using the Unicode (UTF-16) versions of the console API. Apps trying to render ANSI-art should simply #define UNICODE and use proper code-point anyway as box-drawings and block-elements might not map to the current user codepage either, instead of changing the user's codepage or expecting the whole world to use CP 437.
Codebase using CP 437 internally could stay as it and simply replace their print function by a combination of MultiByteToWideChar and WriteConsoleW to easily become console codepage independent.
Outputting these characters in the v2 console with CP 437 selected.

Codepage 437 is a superset of ASCII. It also includes an alternate mapping for the legacy PC glyphs, which you can get instead of ASCII control characters by specifying the MultiByteToWideChar flag MB_USEGLYPHCHARS.

This would be a lot less painful if the Legacy Console setting wasn't global!

While looking into another issue, I came across something in the code which I think is the reason why these characters aren't displaying "correctly". In the WriteCharsLegacy method in _stream.cpp, there is actually some code that tries to handle the conversion of control characters to their OEM glyphs (see here).  The problem is that the CharType returned by GetStringTypeW is a combination of bit flags - not a single value - so it can't be compared directly with C1_CNTRL. This can easily be fixed by changing that condition to a proper flag test:
if (WI_IsFlagSet(CharType, C1_CNTRL))

I'd love to provide a PR for this if nobody has any objections.

@miniksa knows best here, but that sounds like the right fix to me!

I'm only moderately terrified that it is, in fact, in WriteCharsLegacy. That function is ... one of the worst parts of conhost, and one of our biggest compatibility concerns. I'd wait for Michael to report on whether this is sane or insane, or whether that behavior is now codified and set in stone and can never be changed. :smile:

if (WI_IsFlagSet(CharType, C1_CNTRL))

In short, this is probably fine to fix.
However, I would personally feed a few characters through WriteCharsLegacy under the debugger and assert that your theory is correct first (that multiple flags coming back are what the problem is) before making the change.

In long, why is it fine to fix?
For reference, this particular segment of code https://github.com/microsoft/terminal/blob/9b92986b49bed8cc41fde4d6ef080921c41e6d9e/src/host/_stream.cpp#L514-L539 appears to only be used when the codepoint is < 0x20 or == 0x7F https://github.com/microsoft/terminal/blob/9b92986b49bed8cc41fde4d6ef080921c41e6d9e/src/host/_stream.cpp#L408 and ENABLE_PROCESSED_OUTPUT is off. https://github.com/microsoft/terminal/blob/9b92986b49bed8cc41fde4d6ef080921c41e6d9e/src/host/_stream.cpp#L320
I looked back at the console v1 code and this particular section had a divergence for "Western" countries and "Far East" countries (a geopolitically-charged term, but what it was, nonetheless.)
For "Western" countries, we would unconditionally run all the characters through MultiByteToWideChar with MB_USEGLYPHCHARS without the C1_CNTRL test and move the result into the buffer.
For "Eastern" countries, we did the C1_CNTRL test and then if true, we would run through MultiByteToWideChar with MB_USEGLYPHCHARS. Otherwise, we would just move the original character into the buffer and call it a day.
Note in both of these, there is a little bit of indirection before MultiByteToWideChar is called through some other helper methods like ConvertOutputToUnicode, but that's the effective conversion point, as far as I can tell. And that's where the control characters would turn into acceptable low ASCII symbols.
When we took over the console codebase, this variation between "Western" and "Eastern" countries was especially painful because conhost.exe would choose which one it was in based on the Codepage for Non-Unicode Applications set in the Control Panel's Regional > Administrative panel and it could only be changed with a reboot. It wouldn't even change properly when you chcp to a different codepage. Heck, chcp would deny you from switching into many codepages. There was a block in place to prevent going to an "Eastern" codepage if you booted up in a "Western" codepage. There was also a block preventing you from going between "Eastern" codepages, if I recall correctly.
In modernizing, I decided a few things:

What's good for the "Far East" should be good for the rest of the world. CJK languages that encompassed the "Far East" code have to be able to handle "Western" text as well even if the reverse wasn't true.
We need to scrub all usages of "Far East" from the code. Someone already started that and replaced them with "East Asia" except then they left behind the shorthand of "FE" prefixing dozens of functions which made it hard to follow the code. It took us months to realize "FE" and "East Asia" were the same thing.
It's obnoxious that the way this was handled was to literally double-define every output function in the code base to have two definitions, compile them both into the conhost, then choose to run down the SB_ versions or the FE_ versions depending on the startup Non-Unicode codepage. It was a massive pile of complex pre-compilation #ifdef and #elses that would sometimes surround individual lines in the function bodies. Gross.
The fact that the FE_ versions of the functions were way slower than the SB_ ones was unacceptable even for the same output of Latin-character text.
Anyone should be free to switch between any codepage they want at any time and restricting it based on a value from OS startup or region/locale is not acceptable in the modern world.
I concluded by all of the above that I was going to tank/delete/remove the SB_ versions of everything and force the entire world to use the FE_ versions as truth. I would fix the FE_ versions to handle everything correctly, I would fix the performance characteristics of the FE_ versions so they were only slower when things were legitimately more complicated and never otherwise, I would banish all usage of "Far East", "East Asia", "FE_", and "SB_" from the codebase, and codepages would be freely switchable.
Oh. Also, the conhost used to rewrite its entire backing buffer into whatever your current codepage was whenever you switched codepages. I changed that to always hold it as UTF-16.

Now, after that backstory. This is where the problem comes in. It looks like the code you're pointing to that didn't check flags and instead checked direct equality... is the way that it was ALWAYS done for the "Eastern" copy of the code. So it was ALWAYS broken for the "Eastern" codepages and country variants of the OS.
I don't know why the "Eastern" copy was checking C1_CNTRL at all in the first place. There is no documentation. I presume it has to do with Shift-JIS or GB-2312 or Unified Hangul or something having a conflict < 0x30 || == 0x7F. Or alternatively, it's because someone wrote the code naively thinking it was a good idea in a hurry and never tested it. Very possible and even probable.
Presuming CJK codepages have no conflict in this range for their DBCS codepages... we could probably remove the check with GetStringTypeW entirely and always run everything through ConvertOutputToUnicode. More risky than just the flag test change... but theoretically an option as well.

Thank you for taking the time to go into this in so much detail. I appreciate the amount of work that must have gone into refactoring that code, and I do understand your concern about breaking things. I have stepped through the function in the debugger to confirm that it was working the way I expected, but I'll try and do a lot more testing before I submit the PR.

Having now checked the character type for all the characters in the control range (0 to 31, and 127), I can confirm that they all have both the C1_CNTRL and C1_DEFINED flags set. A few also have C1_BLANK and/or C1_SPACE. So none of them would have matched on a direct comparison. That said, it seems that the C1_DEFINED flag didn't always exist (I believe it was added in XP), so it's possible a direct comparison with C1_CNTRL would actually have worked in the past (in most cases at least), so maybe that's the reason why this code was originally written the way it is.
Something that came up in testing, though, was that my suggested fix would actually change the behaviour of the null character. Because a null is now successfully matched as a C1_CNTRL, it would no longer fall through to the special-case handling that previously mapped it to a space, and that caused problems elsewhere in the code (see issue #1955). So to address that I've also had to reorder the code slightly - not quite the straightforward fix I'd thought it would be!
One other thing. You mention above that this only applies when ENABLE_PROCESSED_OUTPUT mode is off, but it's actually the other way around - it only applies when ENABLE_PROCESSED_OUTPUT mode is set. That seems wrong to me (I'd expect it to work in both cases), but that's the way the legacy console behaved as well, so if that's a bug it's a separate issue. And since the majority of code would be using the default mode (where ENABLED_PROCESSED_OUTOUT is set), I don't think it's that big a deal.

Having now checked the character type for all the characters in the control range (0 to 31, and 127), I can confirm that they all have both the C1_CNTRL and C1_DEFINED flags set. A few also have C1_BLANK and/or C1_SPACE. So none of them would have matched on a direct comparison. That said, it seems that the C1_DEFINED flag didn't always exist (I believe it was added in XP), so it's possible a direct comparison with C1_CNTRL would actually have worked in the past (in most cases at least), so maybe that's the reason why this code was originally written the way it is.
Something that came up in testing, though, was that my suggested fix would actually change the behaviour of the null character. Because a null is now successfully matched as a C1_CNTRL, it would no longer fall through to the special-case handling that previously mapped it to a space, and that caused problems elsewhere in the code (see issue #1955). So to address that I've also had to reorder the code slightly - not quite the straightforward fix I'd thought it would be!
One other thing. You mention above that this only applies when ENABLE_PROCESSED_OUTPUT mode is off, but it's actually the other way around - it only applies when ENABLE_PROCESSED_OUTPUT mode is set. That seems wrong to me (I'd expect it to work in both cases), but that's the way the legacy console behaved as well, so if that's a bug it's a separate issue. And since the majority of code would be using the default mode (where ENABLED_PROCESSED_OUTOUT is set), I don't think it's that big a deal.

Sorry, yes. I probably just mentally transposed the boolean state. And I agree. It's probably not that big of a deal.
Thank for catching and identifying the null issue as well!


tick offset by one character in common mark files

Describe the bug
Off by one underline in common mark / markdown files.
Works fine in rust files.
To Reproduce
Steps to reproduce the behaviour:

Run 'cargo run -- check README.md'
See error

<snip>
    --> /media/supersonic1t/projects/cargo-spellcheck/README.md:169
     |
 169 | Run an instance of the [LanguageTool server i.e. as container](https://hub.docker.com/r/erikvl87/languagetool).
     |                          ^^^^^^^^^^^^
<snip>

Expected behavior
Precisely underline the mistake.
Please complete the following information:

System: Fedora
Obtained: git

Additional context
Add any other context about the problem here.

It only happens with the sequence of  ```rust ` ```rust` as present in README.md

Actually that is wrong, 🌡 triggers this reproducibly


Store/cache the board hash as a board property?

Since more and more methods compare the board hash against itself after some changes have been made (to return the "board changed?" Boolean), this could help to make all of these methods linear time (at the cost of calculating it every time).

If we every delay the calculation of board properties until they are needed (lazy implementation), this would make it pointless as everything would be calculated.

maybe ascii() too, but string operations too slow, might affect performance


Update

Problem solved
Short description of the bug fixed or feature added

PR-Codex overview
This PR exposes ERC20Vote extensions, adds more Vote contract extensions, and enhances Vote-related functionalities.
Detailed summary

Added VoteType enum for voting types
Updated SplitContractParams extension to DEPLOY
Added functions for proposal existence, execution, and vote counts
Enhanced test coverage for Vote-related contracts and functions

The following files were skipped due to too many changes: packages/thirdweb/src/extensions/vote/write/executeProposal.ts, packages/thirdweb/src/extensions/vote/read/proposalExists.test.ts, packages/thirdweb/src/extensions/prebuilts/deploy-vote.ts, packages/thirdweb/src/extensions/prebuilts/__generated__/VoteERC20/write/initialize.ts

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#4132  👈
#4131
#4130
#4129
#4128
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @kien-ngo and the rest of your teammates on  Graphite


Could not modify Group with key

In 0.8.2 We create an app, marathon return success. But it never really create it. And it not in deployment nor in queue.
So we upgrade to 0.9.2
It shows error:
Could not modify Group with key: root:2015-07-31T08:50:18.342Z
We remove some zookeeper log/snapshot. It is ok.
But after we recover some apps, the error appear again.

Could you please provide some more information from the marathon logfile? There should be an exception logged with that message.

Aug 26 09:21:17 ip----* marathon[27448]: [2015-08-26 09:21:17,252] WARN  (mesosphere.marathon.api.MarathonExceptionMapper:30)
Aug 26 09:21:17 ip----* marathon[27448]: mesosphere.marathon.StoreCommandFailedException: Could not fetch AppDefinition with key: 5ecb8fba-afdf-4691-9f2f-f0111106b4ed
Aug 26 09:21:17 ip----* marathon[27448]: #011at mesosphere.marathon.state.MarathonStore$$anonfun$mesosphere$marathon$state$MarathonStore$$exceptionTransform$1.applyOrElse(MarathonStore.scala:75)
Aug 26 09:21:17 ip----* marathon[27448]: #011at mesosphere.marathon.state.MarathonStore$$anonfun$mesosphere$marathon$state$MarathonStore$$exceptionTransform$1.applyOrElse(MarathonStore.scala:74)
Aug 26 09:21:17 ip----* marathon[27448]: #011at scala.runtime.AbstractPartialFunction.apply(AbstractPartialFunction.scala:36)
Aug 26 09:21:17 ip----* marathon[27448]: #011at scala.util.Failure$$anonfun$recover$1.apply(Try.scala:215)
Aug 26 09:21:17 ip----* marathon[27448]: #011at scala.util.Try$.apply(Try.scala:191)
Aug 26 09:21:17 ip----* marathon[27448]: #011at scala.util.Failure.recover(Try.scala:215)
Aug 26 09:21:17 ip----* marathon[27448]: #011at scala.concurrent.Future$$anonfun$recover$1.apply(Future.scala:324)
Aug 26 09:21:17 ip----* marathon[27448]: #011at scala.concurrent.Future$$anonfun$recover$1.apply(Future.scala:324)
Aug 26 09:21:17 ip----* marathon[27448]: #011at scala.concurrent.impl.CallbackRunnable.run(Promise.scala:32)
Aug 26 09:21:17 ip----* marathon[27448]: #011at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
Aug 26 09:21:17 ip----* marathon[27448]: #011at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
Aug 26 09:21:17 ip----* marathon[27448]: #011at java.lang.Thread.run(Thread.java:745)
Aug 26 09:21:17 ip----* marathon[27448]: Caused by: mesosphere.marathon.StoreCommandFailedException: Could not load key app:5ecb8fba-afdf-4691-9f2f-f0111106b4ed
Aug 26 09:21:17 ip----* marathon[27448]: #011at mesosphere.util.state.zk.ZKStore$$anonfun$exceptionTransform$1.applyOrElse(ZKStore.scala:83)
Aug 26 09:21:17 ip----* marathon[27448]: #011at mesosphere.util.state.zk.ZKStore$$anonfun$exceptionTransform$1.applyOrElse(ZKStore.scala:82)
Aug 26 09:21:17 ip----* marathon[27448]: #011... 10 more
Aug 26 09:21:17 ip----* marathon[27448]: Caused by: org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode = ConnectionLoss for /marathon/state/app:5ecb8fba-afdf-4691-9f2f-f0111106b4ed
Aug 26 09:21:17 ip----* marathon[27448]: #011at org.apache.zookeeper.KeeperException.create(KeeperException.java:99)
Aug 26 09:21:17 ip----* marathon[27448]: #011at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
Aug 26 09:21:17 ip----* marathon[27448]: #011at com.twitter.zk.AsyncCallbackPromise$class.process(AsyncCallbackPromise.scala:18)
Aug 26 09:21:17 ip----* marathon[27448]: #011at com.twitter.zk.DataCallbackPromise.process(AsyncCallbackPromise.scala:53)
Aug 26 09:21:17 ip----* marathon[27448]: #011at com.twitter.zk.DataCallbackPromise.processResult(AsyncCallbackPromise.scala:56)
Aug 26 09:21:17 ip----* marathon[27448]: #011at org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:564)
Aug 26 09:21:17 ip----* marathon[27448]: #011at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
Aug 26 09:21:17 ip----* marathon[27448]: [2015-08-26 09:21:17,252] WARN Deployment failed for change: 2015-08-26T09:21:04.810Z (mesosphere.marathon.state.GroupManager:146)
Aug 26 09:21:17 ip----* marathon[27448]: mesosphere.marathon.StoreCommandFailedException: Could not modify Group with key: root:2015-07-30T00:07:26.834Z
Aug 26 09:21:17 ip----* marathon[27448]: #011at mesosphere.marathon.state.MarathonStore$$anonfun$mesosphere$marathon$state$MarathonStore$$exceptionTransform$1.applyOrElse(MarathonStore.scala:75)
Aug 26 09:21:17 ip----* marathon[27448]: #011at mesosphere.marathon.state.MarathonStore$$anonfun$mesosphere$marathon$state$MarathonStore$$exceptionTransform$1.applyOrElse(MarathonStore.scala:74)
Aug 26 09:21:17 ip----* marathon[27448]: #011at scala.runtime.AbstractPartialFunction.apply(AbstractPartialFunction.scala:36)
Aug 26 09:21:17 ip---**-* marathon[27448]: #011at scala.util.Failure$$anonfun$recover$1.apply(Try.scala:215)

we found this when the number of our containers is larger than 1000.
So did marathon have some unusual behaviour when it manages 1000+ containers.

I and @nashasha1 from same company. I post another logging with better format below.   The exception happened when App was created or updated. The exception says Can not create entity group:root:2015-07-31T08:50:18.342Z and Could not modify Group with key: root:2015-07-31T08:50:18.342Z.  App creating and updating happened on yesterday, that is 2015-08-26. It's very strange that Marathon tried to create and modify group with 2015-07-31 version.
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: [2015-08-26 10:05:09,210] WARN (mesosphere.marathon.api.MarathonExceptionMapper:30)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: mesosphere.marathon.StoreCommandFailedException: Could not modify Group with key: root:2015-07-31T08:50:18.342Z
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at mesosphere.marathon.state.MarathonStore$$anonfun$mesosphere$marathon$state$MarathonStore$$exceptionTransform$1.applyOrElse(MarathonStore.scala:75)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at mesosphere.marathon.state.MarathonStore$$anonfun$mesosphere$marathon$state$MarathonStore$$exceptionTransform$1.applyOrElse(MarathonStore.scala:74)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at scala.runtime.AbstractPartialFunction.apply(AbstractPartialFunction.scala:36)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at scala.util.Failure$$anonfun$recover$1.apply(Try.scala:215)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at scala.util.Try$.apply(Try.scala:191)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at scala.util.Failure.recover(Try.scala:215)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at scala.concurrent.Future$$anonfun$recover$1.apply(Future.scala:324)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at scala.concurrent.Future$$anonfun$recover$1.apply(Future.scala:324)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at scala.concurrent.impl.CallbackRunnable.run(Promise.scala:32)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at java.lang.Thread.run(Thread.java:745)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: Caused by: mesosphere.marathon.StoreCommandFailedException: Can not create entity group:root:2015-07-31T08:50:18.342Z
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at mesosphere.util.state.zk.ZKStore$$anonfun$exceptionTransform$1.applyOrElse(ZKStore.scala:83)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at mesosphere.util.state.zk.ZKStore$$anonfun$exceptionTransform$1.applyOrElse(ZKStore.scala:82)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011... 10 more
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: Caused by: org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode = ConnectionLoss for /marathon/state/group:root:2015-07-31T08:50:18.342Z
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at org.apache.zookeeper.KeeperException.create(KeeperException.java:99)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at com.twitter.zk.AsyncCallbackPromise$class.process(AsyncCallbackPromise.scala:18)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at com.twitter.zk.StringCallbackPromise.process(AsyncCallbackPromise.scala:23)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at com.twitter.zk.StringCallbackPromise.processResult(AsyncCallbackPromise.scala:25)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:605)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: [2015-08-26 10:05:09,210] WARN Deployment failed for change: 2015-08-26T10:04:58.043Z (mesosphere.marathon.state.GroupManager:146)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: mesosphere.marathon.StoreCommandFailedException: Could not modify Group with key: root:2015-07-31T08:50:18.342Z
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at mesosphere.marathon.state.MarathonStore$$anonfun$mesosphere$marathon$state$MarathonStore$$exceptionTransform$1.applyOrElse(MarathonStore.scala:75)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at mesosphere.marathon.state.MarathonStore$$anonfun$mesosphere$marathon$state$MarathonStore$$exceptionTransform$1.applyOrElse(MarathonStore.scala:74)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at scala.runtime.AbstractPartialFunction.apply(AbstractPartialFunction.scala:36)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at scala.util.Failure$$anonfun$recover$1.apply(Try.scala:215)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at scala.util.Try$.apply(Try.scala:191)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at scala.util.Failure.recover(Try.scala:215)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at scala.concurrent.Future$$anonfun$recover$1.apply(Future.scala:324)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at scala.concurrent.Future$$anonfun$recover$1.apply(Future.scala:324)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at scala.concurrent.impl.CallbackRunnable.run(Promise.scala:32)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at java.lang.Thread.run(Thread.java:745)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: Caused by: mesosphere.marathon.StoreCommandFailedException: Can not create entity group:root:2015-07-31T08:50:18.342Z
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at mesosphere.util.state.zk.ZKStore$$anonfun$exceptionTransform$1.applyOrElse(ZKStore.scala:83)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at mesosphere.util.state.zk.ZKStore$$anonfun$exceptionTransform$1.applyOrElse(ZKStore.scala:82)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011... 10 more
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: Caused by: org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode = ConnectionLoss for /marathon/state/group:root:2015-07-31T08:50:18.342Z
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at org.apache.zookeeper.KeeperException.create(KeeperException.java:99)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at com.twitter.zk.AsyncCallbackPromise$class.process(AsyncCallbackPromise.scala:18)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at com.twitter.zk.StringCallbackPromise.process(AsyncCallbackPromise.scala:23)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at com.twitter.zk.StringCallbackPromise.processResult(AsyncCallbackPromise.scala:25)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:605)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: #011at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: [INFO] [08/26/2015 10:05:09.214] [marathon-akka.actor.default-dispatcher-4] [akka://marathon/user/$b] POSTing to all endpoints.
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: [2015-08-26 10:05:09,215] INFO <IP_ADDRESS> - - [26/Aug/2015:10:04:58 +0000] "POST /v2/apps/ HTTP/1.1" 500 76 "-" "curl/7.37.1" (mesosphere.chaos.http.ChaosRequestLog:15)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: [2015-08-26 10:05:09,320] INFO Opening socket connection to server <IP_ADDRESS>/<IP_ADDRESS>:2181. Will not attempt to authenticate using SASL (unknown error) (org.apache.zookeeper.ClientCnxn:975)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: [2015-08-26 10:05:09,320] INFO Socket connection established to <IP_ADDRESS>/<IP_ADDRESS>:2181, initiating session (org.apache.zookeeper.ClientCnxn:852)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: [2015-08-26 10:05:09,322] INFO Session establishment complete on server <IP_ADDRESS>/<IP_ADDRESS>:2181, sessionid = 0x14f68ce878b000f, negotiated timeout = 1800000 (org.apache.zookeeper.ClientCnxn:1235)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: [2015-08-26 10:05:09,328] INFO Setting framework ID to 20150713-183426-1459822508-5050-27691-0000 (mesosphere.marathon.MarathonSchedulerService:86)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: [INFO] [08/26/2015 10:05:09.328] [pool-2-thread-1] [akka://marathon/user/$b] Sending POST to:http://<IP_ADDRESS>:8080/v1/apps/events/
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: [2015-08-26 10:05:09,328] INFO Setting framework ID to 20150713-183426-1459822508-5050-27691-0000 (mesosphere.marathon.MarathonSchedulerService:86)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: [INFO] [08/26/2015 10:05:09.329] [pool-2-thread-1] [akka://marathon/user/$b] Sending POST to:https://puck.alauda.club:8443/v1/slark
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: [INFO] [08/26/2015 10:05:09.329] [pool-2-thread-1] [akka://marathon/user/$b] Sending POST to:https://puck.alauda.club:8443/v1/mirana
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: [2015-08-26 10:05:09,330] INFO <IP_ADDRESS> - - [26/Aug/2015:10:05:08 +0000] "GET /v2/info HTTP/1.1" 200 977 "-" "ELB-HealthChecker/1.0" (mesosphere.chaos.http.ChaosRequestLog:15)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: [2015-08-26 10:05:09,330] INFO <IP_ADDRESS> - - [26/Aug/2015:10:05:09 +0000] "GET /v2/apps//c30495b3-bf6c-4693-a13a-a0805a78804f HTTP/1.1" 200 1625 "http://<IP_ADDRESS>:8080/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.89 Safari/537.36" (mesosphere.chaos.http.ChaosRequestLog:15)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: [2015-08-26 10:05:09,331] INFO <IP_ADDRESS> - - [26/Aug/2015:10:05:08 +0000] "GET /v2/info HTTP/1.1" 200 977 "-" "ELB-HealthChecker/1.0" (mesosphere.chaos.http.ChaosRequestLog:15)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: [2015-08-26 10:05:09,398] INFO <IP_ADDRESS> - - [26/Aug/2015:10:05:09 +0000] "GET /v2/deployments HTTP/1.1" 200 2 "http://<IP_ADDRESS>:8080/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.89 Safari/537.36" (mesosphere.chaos.http.ChaosRequestLog:15)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: [2015-08-26 10:05:09,429] INFO started processing 1 offers, launching at most 1 tasks per offer and 1000 tasks in total (mesosphere.marathon.tasks.IterativeOfferMatcher$:129)
Aug 26 10:05:09 ip-172-31-11-94 marathon[4884]: [2015-08-26 10:05:09,429] INFO Offer [20150720-062308-1577787308-5050-21885-O36819081]. Decline with default filter refuseSeconds (use --decline_offer_duration to configure) (mesosphere.marathon.tasks.IterativeOfferMatcher$:228)

Another odd thing is the group version is always 2015-07-13T20:47:41.034Z which query by /v2/groups. I look into the content of  Zookeeper node /marathon/state/group:root, the version indeed is 2015-07-13T20:47:41.034.  It's seem the version hadn't changes from first created.
If the problem is related to big group. we have thousand Apps in root group. The size of zookeeper node /marathon/state/group:root is more than 500K now. is this problem related to big group? actually we don't use Marathon's group feature. Should we create separate group for each app to prevent large group? thanks

any idea about this?

In general, 500k is not a size where I'd expect this kind of problem. See information on jute.maxbuffer in the ZooKeeper Admin Doc
But yes, we've run into problems with big node sizes – the problem, however, is not the size of the node itself, but the packet size when fetching the node. When trying to delete such a node via the zkCli, the output looks like this:
Welcome to ZooKeeper!
2015-08-13 10:47:41,229 [myid:] - INFO  [main-SendThread(localhost:2181):ClientCnxn$SendThread@975] - Opening socket connection to server localhost/<IP_ADDRESS>:2181. Will not attempt to authenticate using SASL (unknown error)
JLine support is enabled
2015-08-13 10:47:41,299 [myid:] - INFO  [main-SendThread(localhost:2181):ClientCnxn$SendThread@852] - Socket connection established to localhost/<IP_ADDRESS>:2181, initiating session
2015-08-13 10:47:41,308 [myid:] - INFO  [main-SendThread(localhost:2181):ClientCnxn$SendThread@1235] - Session establishment complete on server localhost/<IP_ADDRESS>:2181, sessionid = 0x14f25f4aa2200df, negotiated timeout = 30000

WATCHER::

WatchedEvent state:SyncConnected type:None path:null
[zk: localhost:2181(CONNECTED) 0] rmr /universe
2015-08-13 10:47:45,908 [myid:] - WARN  [main-SendThread(localhost:2181):ClientCnxn$SendThread@1102] - Session 0x14f25f4aa2200df for server localhost/<IP_ADDRESS>:2181, unexpected error, closing socket connection and attempting reconnect
java.io.IOException: Packet len4198383 is out of range!
    at org.apache.zookeeper.ClientCnxnSocket.readLength(ClientCnxnSocket.java:112)
    at org.apache.zookeeper.ClientCnxnSocketNIO.doIO(ClientCnxnSocketNIO.java:79)
    at org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:366)
    at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1081)

WATCHER::

WatchedEvent state:Disconnected type:None path:null
Exception in thread "main" org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode = ConnectionLoss for /universe/marathon-demo/state
    at org.apache.zookeeper.KeeperException.create(KeeperException.java:99)
    at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
    at org.apache.zookeeper.ZooKeeper.getChildren(ZooKeeper.java:1472)
    at org.apache.zookeeper.ZooKeeper.getChildren(ZooKeeper.java:1500)
    at org.apache.zookeeper.ZKUtil.listSubTreeBFS(ZKUtil.java:114)
    at org.apache.zookeeper.ZKUtil.deleteRecursive(ZKUtil.java:49)
    at org.apache.zookeeper.ZooKeeperMain.processZKCmd(ZooKeeperMain.java:703)
    at org.apache.zookeeper.ZooKeeperMain.processCmd(ZooKeeperMain.java:588)
    at org.apache.zookeeper.ZooKeeperMain.executeLine(ZooKeeperMain.java:360)
    at org.apache.zookeeper.ZooKeeperMain.run(ZooKeeperMain.java:323)
    at org.apache.zookeeper.ZooKeeperMain.main(ZooKeeperMain.java:282)
matthias@master-zuob ~ $

Note the Packet len4198383 is out of range! in the stack trace – I have not seen that in the one you provided, so I don't think that you're running into node size problems (at least not yet). However, it seems to be a zk-specific problem. From a marathon point of view, storing state fails, which means that deploying must fail.
Questions

Have you updated any AppDefinitions since the root group's version timestamp?
Can you try to manually (non-destructively) modify the zNode via the zkCli?

Any update/ideas on this? We are seeing a similar issue though our group size or packet size is not that big...
curl --silent -X GET http:///v2/groups | python -mjson.tool | wc
39871   65801 1626350

Hey @mingqi if the group reaches a size of more than 500KB, any update to any app or group will fail with a version of Marathon before 0.13.0. For every change of an AppDefinition we create and store a Deployment in ZK which stores the group before the change and the group after the change. If your group is greater than 500KB, the deployment object will be 2 times this size. The default jute.maxbuffer is 1MB and will exceed this threshold.
For that reason we introduced ZKCompression, which is available in Marathon 0.13. We successfully started  2000 Apps simultaneously with this version. Can you try, if this version solves your problem?

@aameek the group is stored as protobuf. The size of the json object is very different. Can you look into zk, how big the object is?

Just adding my :+1: to this issue. My team and I worked with @jgarcia-mesosphere over the last two weeks to narrow down a problem we were seeing in our dev cluster to this bug. The issue is that Marathon stores group defs in ZK, and the root group seems to store all the data for all child groups. When we got to a point where our /marathon/group:root znode went over about 500kb, Marathon wouldn't be able to process new deployments (we'd see either "conflicting deployment" or "futures timed out" errors in the logs). The max for any znode is 1mb, but Marathon is updating the znode with old group + deployment metadata + updated group, so the current znode doesn't even have to approach 1mb before you start seeing this problem.
Once we understood that Marathon was trying to update the group:root znode in a way that would surpass the hard limit of 1mb per znode, we were able to fiddle with our apps enough to destroy enough of them to get us below 500kb for that group:root znode. That got our dev cluster stable, but we have an upper limit on the number of app groups we can run concurrently now.
It looks like Marathon is scalable up to thousands of tasks, but those tasks need to have small definitions. We've built a "Heroku-like" system on top of Marathon for our devs, and that means that we've got a high number of apps per group, and each app has around 100 environment variables. So when your devs create multiple groups with this kind of configuration, you'll run into scalability issues sooner than you'd expect. For instance, we currently have 323 apps defined in our dev Marathon (only 120 of them actually running), but our group:root znode is over 400kb.
We're going to be rearchitecting our applications to fetch their environments themselves, instead of injecting them via the env section of the app definition. It would be good if Marathon would at least catch the exceptional case where it attempts to stuff more in the group:root znode than it can handle, and long-term to break up these potentially large znodes into parent/child znodes, or use a different data store, or something even more clever that I haven't thought of yet.
For anyone experiencing this issue: try deleting your smallest app or app group, then the next smallest, until you have control of your cluster again. That got us moving again.

@mcclurmc thanks for the info. We are very aware of this limitation.
We introduced a command line parameter --max_apps, so you get an error, if you try to create more apps than that number. This configuration is mostly bandaid to fail fast and does not take the zk node size into account (depending on how much data you store on the app level).
Step 1) we will refactor how the group is stored (only references to the app)
Step 2) we will support more capable persistent stores.

To check for this, pull Marathon statistics from http://<marathon>/metrics and check for the "service.mesosphere.marathon.state.MarathonStore.DeploymentPlan.write-data-size" key to see the largest deploy your Marathon has tried to write.

Is this fixed  ?

@kopax not yet

Will it be fixed ?

There is a new persistence layer in 1.4-SNAPSHOT that is currently enabled by default that stores in ZK in a much more scalable fashion. I was able to store 2,500 apps (easily scales more) with 450,000 tasks. The theoretical limit is about a million "objects" of a given type.

Fixed by #4178


http: flip runtime flag to disable route config searching downgrading

Commit Message: http: flip runtime flag to disable route config searching downgrading
Additional Description:
According to previous discussion, flip the runtime flag to true after Q4 release.
Risk Level: low.
Testing: n/a.
Docs Changes: n/a.
Release Notes: n/a.
Platform Specific Features: n/a.

The biggest impact of this PR is that the embedded filter of composite filter could not use the canonical filter name (e.g. envoy.filters.http.buffer) to get route level per filter config. And because the filter chain could only get the config name of composite filter itself, so all embedded filters in same composite filter will share same config name in current implementation, which may be unexpected.
A possible solution is to create a wapper of StreamFilterCallbacks to override mostSpecificPerFilterConfig method. Then the composite set this wrapper into its embedded filters. By this way, every embedded filter could use its own config name to get route level per filter config.
cc @tyxia @snowp

@wbpcode Thanks for letting us know. Composite filter is marked as stable and actively used in our released product.
So I think the desired behavior is implementing the related solution first before checking in breaking change.

/assign @tyxia
I will take a closer look at potential impact of composite filter and update here.

/wait

Thanks for waiting on this! @wbpcode
First of all, I am fully onboard with deprecating filter canonical name. That is just an opaque name which can be arbitrarily set in FactoryBase c'tor.  Keeping single source of truth is cleaner and more robust.
Second, your change will NOT break our product's use case because we have noticed this and always stuck with with filter config name, more specifically top-level filter config name. cc @htuch and @rshriram
Third, we do have an internal tracking bug to surface embedded filter's config name (not canonical name). We should have cycle to work on this in Q4 (cc @jstraceski)
Last, AFAIU your change only breaks the usage of canonical name envoy.filters.http.match_delegate as that is the top-level filter plugged in the filter chain. i.e., those embedded filter's canonical name is already not visible even in that fallback name.
I will add a integration test in composite filter integration test to validate the expected behavior.

Last, AFAIU your change only breaks the usage of canonical name envoy.filters.http.match_delegate as that is the top-level filter plugged in the filter chain. i.e., those embedded filter's canonical name is already not visible even in that fallback name.

Right, but anyway, those canonical name is already unavailable, this is more like a inherent problem of match_delegate. And at least, this PR won't make thing worse.

I am not in a hurry. So, cc @tyxia could you give a stamp when you think this PR is OK to you?


Google App Engine end point App V1 to V2 Migration issue

I have migrated my Google App Engine end point App. There is one jar and war file available in my V1 libs folder. But after I migrated, there is war file only available in my V2 libs folder. Without jar file I cannot proceed my work. Is anything I missed in the migration process ?
I am follow this document.
https://cloud.google.com/endpoints/docs/frameworks/java/migrating-android

Notice: this issue has been closed because it has been inactive for 378 days. You may reopen this issue if it has been closed in error.


Single (one-off) LVar call, outputs 0

Calling an LVar only once will always output 0. It seems we have to include the LVar call within a loop (i.e. while True: as in the example) in order to fill up a stack and obtain the wanted output, but this is not practical in many cases.
Not sure if I might be doing something wrong but I need to be able to do the following:
from simconnect_mobiflight import SimConnectMobiFlight
from mobiflight_variable_requests import MobiFlightVariableRequests

sm = SimConnectMobiFlight()
vr = MobiFlightVariableRequests(sm)
vr.clear_sim_variables()

ap1 = vr.get("(L:A32NX_AUTOPILOT_1_ACTIVE)")
print(ap1)

And obtain as output 1 or 0.

Wait with testing, at the moment it will work only starting with second run of the python client application. The callbacks behave differently whether the simconnect shared memory was in its initial state or whether it already was used in the past. I need to think whether there is a solution.

Wait with testing, at the moment it will work only starting with second run of the python client application. The callbacks behave differently whether the simconnect shared memory was in its initial state or whether it already was used in the past. I need to think whether there is a solution.

Thank you! I'll wait then for a potential solution.
And by the way, thank you for the alternative of working with LVars through Python. :)

Should work now. Please try and give feedback.
https://github.com/Koseng/MSFSPythonSimConnectMobiFlightExtension/blob/main/src/mobiflight_variable_requests.py

Should work now. Please try and give feedback. https://github.com/Koseng/MSFSPythonSimConnectMobiFlightExtension/blob/main/src/mobiflight_variable_requests.py

Hey! It works great now! I tried with continuously updated variables, such as EGT or N1 and works like a charm. The only thing I need to check is why I get the following exception:
WARNING:SimConnect.SimConnect:SIMCONNECT_EXCEPTION_ALREADY_CREATED
My guess is because during test, I am calling SimConnectMobiFlight once and again ... but will check and let you know. No biggy!
Thank you!

Hi,
that warning can be ignored, it is all fine.
Details:
Creation of the shared memory areas between the WASM-Simconnect-Client and the Python-Simconnect-Client is done on both sides, to be sure whoever is first, not tries to access a non existing shared memory.
Usually the WASM-Simconnect-Client is first, therefore the ALREADY_CREATED warning on the Python side. Probably WASM is always first and it can be safely removed on the Python side. Initially I just did it the same way as the mobiflight client.
So if you want to get rid of the warning, just remove the 3 CreateClientData code lines similar to.
self.sm.dll.CreateClientData(self.sm.hSimConnect, self.CLIENT_DATA_AREA_LVARS, 4096, self.FLAG_DEFAULT)


Removal of useExperimentalFileWatcher setting regresses file watching behavior

VSCode Version: 1.34.0 (1.34.0)
OS Version: OSX 10.14.4 (18E226)

After the removal of the files.useExperimentalFileWatcher setting (removed as part of https://github.com/microsoft/vscode/pull/71632), changes made to open files by tasks are not reflected in the editor until you leave and come back to the open file.
Previously, using the files.useExperimentalFileWatcher setting, changes were immediately reflected in vscode after a task wrote them to disk.
This appears to be a regression and is very frustrating and feels very clumsy (needing to switch away from your current file and back again)
Here is an example of running a task which applies Prettier and ESLint to the current file. However the changes are not reflected in the UI until the current file loses, and regains, focus.

Steps to Reproduce:

Create a task that writes to disk. For reference, here is the task I use which applies Prettier and ESLint to the current file
Have a .js file with formatting and/or linting errors
Run the task
Notice that the open file does not reflect the changes written by the task
Click away from the current file and back again
See the changes reflected in the file.

https://github.com/microsoft/vscode/pull/71632 appears to be the PR that removed the files.useExperimentalFileWatcher setting.

Does this issue occur when all extensions are disabled?: Yes

@cbrock It shouldn't be task specific because all tasks does is run your command. I want to confirm that this isn't task specific. Can you try running your task command from the integrated terminal and see if it does the same thing?

@cbrock on top of that question, can you also try to reproduce in our insiders build?  You can give our preview releases a try from: https://code.visualstudio.com/insiders/

@cbrock on top of that question, can you also try to reproduce in our insiders build? You can give our preview releases a try from: https://code.visualstudio.com/insiders/

@bpasero Per the issue template, I did attempt to reproduce using this insiders build:
version: 1.35.0
build: 6b081a9f0089062b2cd105e1f1ab366591291534

I tried again this morning using 1.35.0,e9c50663154c369a06355ce752b447af5b580dc3 with the same results.

@cbrock It shouldn't be task specific because all tasks does is run your command. I want to confirm that this isn't task specific. Can you try running your task command from the integrated terminal and see if it does the same thing?

Thanks for your response @alexr00.
I can confirm that the behavior is the same when running the aforementioned task via the integrated terminal. That is, the open file does not reflect changes until I move focus to a different file and click back again.

@cbrock
Please see if you can find any logged output that could help us find the source of the issue:

run code --verbose from the command line and attach the output
in Code select Help | Toggle Developer Tools and select the Console
attach any output you see in the Console you can find

Thanks!

Thanks for your response @bpasero.
This gist contains the logging output from just before I executed the task fmt, until the task completed - the same workflow that is illustrated in the gif in my original comment above (and just to be clear, I experienced the original issue again).
Here is a screenshot of the console output as well, just in case it's helpful:

@cbrock these entries are the ones to look at:

You can filter the console from the filter box to the top (e.g. type "watcher").
To start with: simply open a file, type and save. You should get an entry that the file changed from the watcher. Does that work? And if yes, can you see if you get an entry for when your task has finished to run?

@bpasero Apologies for the delay in responding.
Using your debugging advice, I noticed a lot of File Watcher entries in the logs. Inspecting the entries, I noticed the paths of most of them pointed to a tmp directory.
I'm currently working with an ember-cli project (ember-cli makes heavy use of a project-specific tmp directory which holds the app's compiled assets). At the time of this writing, the project's tmp directory is 330MB in size.
Somehow, I had not added tmp to the files.watcherExclude list:
  "files.watcherExclude": {
    "**/tmp/**": true
  }

Based on some initial testing, this appears to resolve the issue. My hypothesis is that as the project's tmp directory grew in size, the fmt task became slower and slower, eventually taking so long as to seem completely unresponsive.
I think this issue can remain closed. Thank you for your help!


docs: clarify use of second start

Clarifies usage of the second start() call; supersedes #36. Thanks!
cc/ @timwis

Coverage remained the same at 94.615% when pulling 0b30d2cf995c20776f0cf263d27b2c9e741369cb on clarify-second-start into d99ec6c0917fc57988b011a2ee6ffe21e1ef9c4e on master.

Coverage remained the same at 94.615% when pulling ae8ef17686f24d297693b97e7b5860258e5db6b5 on clarify-second-start into 90b7b967930bd30a89b0390e24e5ecc35eb24ae7 on master.


Response error

Everything seems to work fine until I run the code and get
Response Error: b')]}'\n\n38\n[["wrb.fr",null,null,null,null,[9]]]\n56\n[["di",113],["af.httprm",113,"-913832998693439861",7]]\n25\n[["e",4,null,null,131]]\n'.

I solved it by going to https://bard.google.com/ link and start a conversation first it asks for some permissions it's good to go then


loading image with mx.image.imdecode(, flag=0)

An error arised:
OpenCV Error: Assertion failed (scn == 3 || scn == 4) in cv::ipp_cvtColor, file C:\buildslave64\win64_amdocl\master_PackSlave-win64-vc14-shared\opencv\modules\imgproc\src\color.cpp, line 7341
How can I fix it
Environment info
Operating System: Ubuntu and Windows
Compiler:
Package used (Python/R/Scala/Julia): Python
MXNet version:0.9.5
Or if installed from source: yes
MXNet commit hash (git rev-parse HEAD):
If you are using python package, please provide
Python version and distribution: 2.7.12

your image is broken. opencv cannot recognize it

@piiswrong , Thank you. My image is fine, when I use flag=1, everything is ok.

@piiswrong. I'm afraid this is a bug.
https://github.com/dmlc/mxnet/blob/986b736b816018b96e9d1e2c358bb7665b80944d/src/io/image_io.cc#L94
In this function, setting param.flag = 0 makes cv::imdecode loading a grayscale image.
However following color conversion code
 if (param.to_rgb) {       cv::cvtColor(dst, dst, CV_BGR2RGB); }
didn't check this flag and may call cv::cvtColor on a CV_8UC1 image which triggers assertion

OpenCV Error: Assertion failed (scn == 3 || scn == 4) in cv::ipp_cvtColor

@poorfriend You may pass to_rgb=0 to imdecode when loading grayscale image to avoid this conversion.

This issue is closed due to lack of activity in the last 90 days. Feel free to ping me to reopen if this is still an active issue. Thanks!


awscli2: 2.15.12 -> 2.15.15

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for awscli2 is: Unified tool to manage your AWS services
meta.homepage for awscli2 is: https://aws.amazon.com/cli/
meta.changelog for awscli2 is: https://github.com/aws/aws-cli/blob/2.15.14/CHANGELOG.rst
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.15.14 with grep in /nix/store/da2wn6xbwrqh5q64igxdmnyl2qn0k49f-awscli2-2.15.14
found 2.15.14 in filename of file in /nix/store/da2wn6xbwrqh5q64igxdmnyl2qn0k49f-awscli2-2.15.14

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath
awscli2
liquidsoap

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/da2wn6xbwrqh5q64igxdmnyl2qn0k49f-awscli2-2.15.14 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A awscli2 https://github.com/r-ryantm/nixpkgs/archive/504e0f1c2e5194c5545700e27af9ffbb69527b6c.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/504e0f1c2e5194c5545700e27af9ffbb69527b6c#awscli2

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/da2wn6xbwrqh5q64igxdmnyl2qn0k49f-awscli2-2.15.14
ls -la /nix/store/da2wn6xbwrqh5q64igxdmnyl2qn0k49f-awscli2-2.15.14/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

2 packages built:

awscli2
liquidsoap

Maintainer pings
cc @bhipple @davegallant @bryanasdev000 @devusb @anthonyroussel for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for awscli2 is: Unified tool to manage your AWS services
meta.homepage for awscli2 is: https://aws.amazon.com/cli/
meta.changelog for awscli2 is: https://github.com/aws/aws-cli/blob/2.15.15/CHANGELOG.rst
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.15.15 with grep in /nix/store/181lryv4lyj9rrzv6ddy9wigbwvx2lx4-awscli2-2.15.15
found 2.15.15 in filename of file in /nix/store/181lryv4lyj9rrzv6ddy9wigbwvx2lx4-awscli2-2.15.15

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath
awscli2
liquidsoap

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/181lryv4lyj9rrzv6ddy9wigbwvx2lx4-awscli2-2.15.15 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A awscli2 https://github.com/r-ryantm/nixpkgs/archive/fac5fd82820fce7e71518c7fb0a459eb6be840c6.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/fac5fd82820fce7e71518c7fb0a459eb6be840c6#awscli2

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/181lryv4lyj9rrzv6ddy9wigbwvx2lx4-awscli2-2.15.15
ls -la /nix/store/181lryv4lyj9rrzv6ddy9wigbwvx2lx4-awscli2-2.15.15/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

3 packages built:

awscli2
awscli2.dist
liquidsoap

Maintainer pings
cc @bhipple @davegallant @bryanasdev000 @devusb @anthonyroussel for testing.


Rigidbodies squash and bounce off each other when restitution is zero

Rigidbodies seem to squash and bounce off other bodies despite restitution being disabled on everything. Increasing the density exacerbates this.
Here's a somewhat extreme example, where the yellow cube is very dense. The orientation doesn't matter, but I think it makes the effect more visible.
Dense cube example
The issue is also visible in the dynamic_character_2d example when jumping on top of the cube. It doesn't happen every time, but it seems to happen more often when jumping on or near the corner of the cube.
I've also attached the code used to reproduce the issue as in the video.
Show code
use avian2d::prelude::*;
use bevy::prelude::*;

fn main() {
	App::new()
		.add_plugins((DefaultPlugins, PhysicsPlugins::default().with_length_unit(10.0)))
		.add_systems(Startup, setup)
		.run();
}

fn setup(mut commands: Commands) {
	// Upper cube (yellow)
	commands.spawn((
		Sprite {
			color: Color::srgb(0.8, 0.8, 0.0),
			custom_size: Some(Vec2::new(3.0, 3.0)),
			..default()
		},
		Transform::from_xyz(5.0, 20.0, 0.0).with_rotation(Quat::from_rotation_z(std::f32::consts::PI / 4.)),
		RigidBody::Dynamic,
		ColliderDensity(1000.),
		Restitution::ZERO.with_combine_rule(CoefficientCombine::Min),
		Collider::rectangle(3.0, 3.0),
	));

	// Lower cube (blue)
	commands.spawn((
		Sprite {
			color: Color::srgb(0.0, 0.8, 0.8),
			custom_size: Some(Vec2::new(3.0, 3.0)),
			..default()
		},
		Transform::from_xyz(5.0, -15.0, 0.0),
		RigidBody::Dynamic,
		ColliderDensity(1.),
		Restitution::ZERO.with_combine_rule(CoefficientCombine::Min),
		Collider::rectangle(3.0, 3.0),
	));

	// Floor
	commands.spawn((
		Sprite {
			color: Color::srgb(0.7, 0.7, 0.8),
			custom_size: Some(Vec2::new(100.0, 5.0)),
			..default()
		},
		Transform::from_xyz(0.0, -20.0, 0.0),
		RigidBody::Static,
		Restitution::ZERO.with_combine_rule(CoefficientCombine::Min),
		Collider::rectangle(100.0, 5.0),
	));

	// Camera
	commands.spawn(Camera2d).insert(OrthographicProjection {
		scale: 0.1,
		..OrthographicProjection::default_2d()
	});
}

For reference, I'm using the latest main: commit c4840ddf4a3adb081bb21c992e524231df83e195

This is "expected" behavior, in that it's a known limitation. It is briefly mentioned in the docs under the Accuracy section here.
The issue here is the large mass ratio of 1:1000, which is something that the vast majority of physics engines and constraint solvers struggle with (specifically dual solvers, if you're interested). If you make the masses closer to each other, it should behave more like you'd expect.
The problem is essentially that the contact between the two dynamic boxes only "sees" their masses, while the contact between the lower box and ground only "sees" the mass of that one box. Each individual contact has no real awareness of any other interactions. Thus, the impulse applied by the high-density box will sort of "overpower" the impulse applied by the ground, and it can take many more solver iterations for the impulses to truly stabilize and converge on an accurate solution.
A similar phenomenon could be seen for a chain consisting of light segments connected by joints, and a heavy sphere at the bottom; the chain will stretch more and more the heavier the bottom sphere is.
Now, even with a mass ratio of 1:1, you might see a very small bounce when the upper box hits the lower box. There could be a few reasons for this, like how Avian (similarly to Box2D and Rapier) uses "soft constraints", which solve constraints "softly" and dampen constraint responses. This remaining bounce can be largely mitigated by tweaking some parameters in the SolverConfig resource; in this case, I noticed that e.g. reducing the contact_frequency_factor helped with this particular issue.


can it support Multi-Page features without show streamlit default multipage side - bar list?

can you add some support to multi pages app ?
I store pages follow auth's recommendation, like
and each file in pages have a function render() return streamlit component need to be painted,
-hello.py
-pages/
  - pages1.py
  - pages2.py

but I found,
1.
if I use some code like
if tabs =='Dashboard':
    pages1.render()

elif tabs == 'Corpus Demo':
    pages2.render()

there are no reaction when I click icon

suppress streamlit to show default multipage list in the upper part of side-bar

Hello, Apologies I took a while to respond, have been busy with other stuff.

Not sure how to add support for multipage, but a working solution can be derived from here. If this does not work then its probably best to go with the optional_menu_tabs component in the above example.
It seems doing it as per the example above should suppress the extra multipage list in the sidebar. In his post, he highlights how one should place the tabs (not directly under the st.sidebar) which conceals this.

If the above do not work for you, probably best to use the option_menu component.
Thanks!


Unsub module

Description of the change:
Reason for the change:
Link to original source:

Closes #
@ksigler7

Hello @Whatthefoxsays,Thanks again for the PR! We appreciate your contribution and look forward to                                              continued collaboration. Thanks!                                             Team SendGrid DX


What does this actually DO? There is no plain English intro about what it is and why I should use it

Everything assumes I already know what this is and why to use it. Can you please just add a short paragraph explaining what this is and why is helpful and what it will do for me? Not everyone is an expert who comes here you can't assume that people know everything that doesn't work in UX and it doesn't work and documentation

I'm not really an authority on this here, but my understanding is this is a collection of tools / packages for working with Vue files.
The README has a link to a website https://volarjs.github.io/ and it looks like documentation is WIP, which is where I'd expect to find the intro you're looking for.
There's also this from the README too, which highlights the key packages in this repo:
https://github.com/vuejs/language-tools/blob/24968e16eb2952cec6bcd247d6d6dc1eed13bf74/README.md?plain=1#L7-L18
Each of these packages have additional info in their READMEs linked in that excerpt I linked.
The two main ones IMO are the vscode extension "volar", and the cli tool for performing typescript checks on Vue SFC files "vue-tsc"


internal types package

Description of PR
This PR moves the generic stack implemenetation currently in the capabilities package to a more generic place the current proposal being a types
package under the internal package.

Fixes #278

Changes (required)

move generic stack implementation to internal/types package

Deprecations (optional)

Checklist (required)

[*] I have reviewed and followed the contribution guidelines
[*] I have performed a self-review of my code
[*] I have commented my code, particularly in hard-to-understand areas
[*] I have made corresponding changes to the documentation if needed
[*] I have checked that my changes pass all tests

References (optional)

/test all

Are you thinking that this will be uses somewhere other than the capability package? That's not clear here.
Not seeing it at the moment but potentially yes.

I'm not a fan of the 'types' package. If anything, I'd rather see this turn into a 'stack' package.
The types package would have both options and stack types for now.. could call it util or something more generic. options is needed by both reports and capability.

Stack on the other hand although used only in capability is generic by design and even though it's not used anywhere today could be used in the future ? But not seeing it being used anywhere else at the moment as you pointed out..

Are you thinking that this will be uses somewhere other than the capability package? That's not clear here.

Not seeing it at the moment but potentially yes.

Until we do, I think it's fine to stay where it is.

I'm not a fan of the 'types' package. If anything, I'd rather see this turn into a 'stack' package.

The types package would have both options and stack types for now.. could call it util or something more generic. options is needed by both reports and capability (#294 )

Util is worse. :) And as I pointed out in #294, options should stay where it is.

Stack on the other hand although used only in capability is generic by design and even though it's not used anywhere today could be used in the future ? But not seeing it being used anywhere else at the moment as you pointed out..

Let's not prematurely reorganize things if there is no immediate need to do so.

Let's not prematurely reorganize things if there is no immediate need to do so.

@bcrochet @skattoju I would vote for a list package. That thing mimics a little bit a Python list somehow and could be improved to have other features. And I think that can actually be put on an actual pkg folder and not internal. It is useful anywhere already. This is the reason I opened the issue. Besides that moving that won't harm the project in any way.

Let's not prematurely reorganize things if there is no immediate need to do so.

@bcrochet @skattoju I would vote for a list package. That thing mimics a little bit a Python list somehow and could be improved to have other features. And I think that can actually be put on an actual pkg folder and not internal. It is useful anywhere already. This is the reason I opened the issue. Besides that, moving it won't harm the project in any way.

I'm not sure that 'list' would be the right place either. list.Stack just seems... wrong.
Not a fan of 'pkg'. It's an artificial organization that a good swath of the Go community do not agree with.
Do we really want to start exposing things out of internal? That comes with having to maintain the API for external use. I'm not sure I want to go there.

This would still be internal and wouldn't really change things up too much. Open to alternative suggestions to types.Stack could also close this one and leave things as is lmk what y'all think.

Closing since there is no explicit need at this time.


robustness_eval.py:'list' object has no attribute 'keys'

commandline:python tools/robustness_eval.py /work/pycharmprojects/mmdetection-master/robust.pkl --dataset coco --task bbox
environment:python3.7
error:UserWarning: Distutils was imported before Setuptools. This usage is discouraged and may exhibit undesirable behaviors or errors. Please use Setuptools' objects directly or at least import Setuptools first.
"Distutils was imported before Setuptools. This usage is discouraged "
Traceback (most recent call last):
File "/work/mmdetection/tools/robustness_eval.py", line 256, in
main()
File "/work/mmdetection/tools/robustness_eval.py", line 252, in main
aggregate=args.aggregate)
File "/work/mmdetection/tools/robustness_eval.py", line 175, in get_results
aggregate=aggregate)
File "/work/mmdetection/tools/robustness_eval.py", line 68, in get_coco_style_results
num_distortions = len(list(eval_output.keys()))
AttributeError: 'list' object has no attribute 'keys'
how can i get AP of each class？:I have seen the primary coco_eval.py has been removd，and now the only way is to use robustness_eval.py?

AP for each class，I have referred to history about each class,and you mean we should take 5th example.But the question is that we don't have access to run .sh because it's on the remote server.Can you provide another solution？

Please refer to the 5th example in doc.


Hardware tests

Hi! I was thinking about unit tests and hardware.
It looks like a good idea to have number of tests that cover hal for most popular boards, like bluepill or discovery.
Is there any way to easily run unit test on the hardware? What hardware is needed in general to execute "full" suit of tests except test board?

This is something I've also been thinking about, but I have no idea how or if it is usually done. I have considered having one microcontroller or FPGA which would read the pins on the controller being tested, but I such a project would take quite a bit of effort I believe. Also, I'm not sure how one would program it

@TheZoq2 Have you seen platformio approach for remote tests?
I think it should not read pins, but check actual logic results in code. Or have a possibility to do tests with pins or with logic. If code is fine and hal is separated from logic, unit tests are easy to make.
But how to run them on hardware? system should have wrapper, that will prepare state of the MCU, run the test and store the result on the tests worker. Does this logic make sense?

(I'm just a newbie trying to learn about Rust and embedded programming.) Having worked some examples I have thought a few times that some sort of hardware unit testing would be pretty neat, but realized I am a long way from anything like that. If anyone figures it out I would really like to hear. However, I do see that there is still a need for some very doable CI testing for Rust stm32**-hal's. The code for hals seems very much in development mode, and some hals seem out-of-date or not in sync. So, I've tried to put together some simple examples in a repository with CI testing for the builds, and very manual less frequent checks to see if the examples actually run correctly on hardware. I would certainly appreciate comments and ideas from people with more experience than I have. A summary is at https://github.com/pdgilbert/eg_stm_hal#summary-of-examples. Scroll down a bit to see what works and doesn't. The CI results are at https://travis-ci.org/pdgilbert/eg_stm_hal. Expanding the CI for other hal's is pretty simple, I can do that if anyone would like. Actually checking that examples run will require hardware, so if you do that please leave details/results as an issue on the repository site.


💡 file usage in script folder

Summary
There are a few scripts in the script folder that I can't seem to find were they are used.  I have checked all the sway config file I can find in both ~/.config/sway and /etc/sway/ and the waybar config in both ~/.config/waybar and /usr/share/sway/templates/waybar.  Can anyone tell me where they are used?
The names are:
autoname-workspaces.py
inactive-windows-transparency.py
sbdp.py
Drawbacks
If we dont need the files why keep them.
Implementation idea
No response
Will you be able to contribute a PR for this?

[ ] Yes I will be able to get that feature a lot quicker.

sbdp.py

is being used to generate the help text
for the other two, they are packaged by upstream into the sway package:
$ pacman -Qo /usr/share/sway/scripts/autoname-workspaces.py
/usr/share/sway/scripts/autoname-workspaces.py is owned by sway 1:1.8.1-4
$ pacman -Qo /usr/share/sway/scripts/inactive-windows-transparency.py
/usr/share/sway/scripts/inactive-windows-transparency.py is owned by sway 1:1.8.1-4


Implement launching projectiles from ProjectileSources

Not every projectile is launched perfectly but it's good enough
Closes SpongePowered/SpongeForge#184

@SpongePowered/developers Any comments?

@simon816
This looks good. How about getting this merged?


Fixed layout scroll zoom behaviour

Description
set prop to invert direction (so it matches google maps) and added an event handler to the outer div which catches and re-emits the scroll event so it gives deltaY in pixels
(as per chrome/react-diagrams expects)
Testing instructions
Add a set up instructions describing how the reviewer should test the code

Review code
Check Travis build
Review changes to test coverage
npm start
navigate to localhost:3000/gui/PANDA/layout (using firefox)
try scrolling to zoom

Agile board tracking
connect to #305
closes #305

Codecov Report

Merging #356 into version1 will decrease coverage by 0.14%.
The diff coverage is 28.57%.

@@             Coverage Diff             @@
##           version1    #356      +/-   ##
===========================================
- Coverage     84.84%   84.7%   -0.15%
===========================================
  Files            76      76
  Lines          2573    2582       +9
  Branches        428     431       +3
===========================================
+ Hits           2183    2187       +4
- Misses          353     357       +4
- Partials         37      38       +1

Impacted Files
Coverage Δ

src/layout/layout.component.js
78.94% <28.57%> (-11.38%)
:arrow_down:

src/malcolm/actions/socket.actions.js
100% <0%> (ø)
:arrow_up:

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 fb51ff6...4c78f95. Read the comment docs.


Downloading dataset error with pyarrow.lib.RecordBatch

I am trying to download sentiment140 and I have the following error
/usr/local/lib/python3.6/dist-packages/nlp/load.py in load_dataset(path, name, version, data_dir, data_files, split, cache_dir, download_config, download_mode, ignore_verifications, save_infos, **config_kwargs)
    518         download_mode=download_mode,
    519         ignore_verifications=ignore_verifications,
--> 520         save_infos=save_infos,
    521     )
    522

/usr/local/lib/python3.6/dist-packages/nlp/builder.py in download_and_prepare(self, download_config, download_mode, ignore_verifications, save_infos, try_from_hf_gcs, dl_manager, **download_and_prepare_kwargs)
    418                 verify_infos = not save_infos and not ignore_verifications
    419                 self._download_and_prepare(
--> 420                     dl_manager=dl_manager, verify_infos=verify_infos, **download_and_prepare_kwargs
    421                 )
    422                 # Sync info

/usr/local/lib/python3.6/dist-packages/nlp/builder.py in _download_and_prepare(self, dl_manager, verify_infos, **prepare_split_kwargs)
    472             try:
    473                 # Prepare split will record examples associated to the split
--> 474                 self._prepare_split(split_generator, **prepare_split_kwargs)
    475             except OSError:
    476                 raise OSError("Cannot find data file. " + (self.MANUAL_DOWNLOAD_INSTRUCTIONS or ""))

/usr/local/lib/python3.6/dist-packages/nlp/builder.py in _prepare_split(self, split_generator)
    652         for key, record in utils.tqdm(generator, unit=" examples", total=split_info.num_examples, leave=False):
    653             example = self.info.features.encode_example(record)
--> 654             writer.write(example)
    655         num_examples, num_bytes = writer.finalize()
    656

/usr/local/lib/python3.6/dist-packages/nlp/arrow_writer.py in write(self, example, writer_batch_size)
    143             self._build_writer(pa_table=pa.Table.from_pydict(example))
    144         if writer_batch_size is not None and len(self.current_rows) >= writer_batch_size:
--> 145             self.write_on_file()
    146
    147     def write_batch(

/usr/local/lib/python3.6/dist-packages/nlp/arrow_writer.py in write_on_file(self)
    127             else:
    128                 # All good
--> 129                 self._write_array_on_file(pa_array)
    130             self.current_rows = []
    131

/usr/local/lib/python3.6/dist-packages/nlp/arrow_writer.py in _write_array_on_file(self, pa_array)
     96     def _write_array_on_file(self, pa_array):
     97         """Write a PyArrow Array"""
---> 98         pa_batch = pa.RecordBatch.from_struct_array(pa_array)
     99         self._num_bytes += pa_array.nbytes
    100         self.pa_writer.write_batch(pa_batch)

AttributeError: type object 'pyarrow.lib.RecordBatch' has no attribute 'from_struct_array'

I installed the last version and ran the following command:
import nlp
sentiment140 = nlp.load_dataset('sentiment140', cache_dir='/content')

When you install nlp for the first time on a Colab runtime, it updates the pyarrow library that was already on colab. This update shows this message on colab:
WARNING: The following packages were previously imported in this runtime:
  [pyarrow]
You must restart the runtime in order to use newly installed versions.

You just have to restart the runtime and it should be fine.
If you don't restart, then it breaks like in your message.

Yeah, that worked! Thanks :)


feat: Update the Code of Conduct to the latest version

Description

Update the Code of Conduct to the latest version

This PR fixes #
Notes for Reviewers:

Signed commits

[x] Yes, I am a Member of DEVSTRONS'

Discord ID (e.g.: DEVSTRONS'#0238)
Panquesito7#3723

@Panquesito7: Thanks for this update! LGTM :partying_face:


How to fix seeds and reproduce results?

My environments:
ubuntu14.04, python2.7, cuda8.0, cudnn, mxnet-cu80.
I can't reproduce results even set all random seeds. Here is the code:
import mxnet as mx
import numpy as np
import random

mx.random.seed(args.seed)
np.random.seed(args.seed)
random.seed(args.seed)

Reproduction is really important in my case.
How can I reproduce results within my environments?

Would you please pin down which function shows random behaviour with the same seeds? If you can provide a minimal code reproducing the problem, it would be the best.

Afaik mx.random.seed sets the seed also based on the device id. Do you happen to use different device ids across multiple runs?

@fhieber I just have a single GPU.

@asitstands Roughly, I build Resnet and load cifar10 dataset in main.py.
The data augment function is defined in utils.py which involves np.random and random.
I just set the random set in main.py.

@zzd1992 seem that you are using same seed, but the accuracy is still different, so this may not related to random seed? Could you provide a minimum reproducible example and more details like how many epoch did you test and what's the accuracy different? Thanks
@nswamy  could you help to add label Metric and Pending Requester Info? Thanks

@zzd1992 Can you update your findings with regards to inconsistent outputs with same seeds ?

Please feel free to reopen this issue if you found this issue has not been solved.