System header included from header not found due to missing .clangd CompileFlag Adds

I believe this issue is similar to #1100 but with the twist that I'm using a .clangd file to add the paths to the system headers
If i include the system header from a .cpp file it finds it:

But if another system header include it it does not find it:

In the clangd log you can see the command to process the system header (_stdint.h in this example) is missing the -isystem flags from my .clangd file:
I[11:54:03.095] ASTWorker building file /Users/max_thrun/.espressif/tools/xtensa-esp32s3-elf/esp-2022r1-11.2.0/xtensa-esp32s3-elf/xtensa-esp32s3-elf/include/sys/_stdint.h version 1 with command inferred from /Users/max_thrun/projects/repo/main/src/imu.cpp
[/Users/max_thrun/projects/repo/build/esp-idf/main]
/Users/max_thrun/.espressif/tools/xtensa-esp32s3-elf/esp-2022r1-11.2.0/xtensa-esp32s3-elf/bin/xtensa-esp32s3-elf-g++ --driver-mode=g++ -DJSON_NOEXCEPTION -mlongcalls -fdiagnostics-color=always -ffunction-sections -fdata-sections -Wall -Werror=all -Wno-error=unused-function -Wno-error=unused-variable -Wno-error=deprecated-declarations -Wextra -Wno-unused-parameter -Wno-sign-compare -Wno-enum-conversion -gdwarf-4 -ggdb -Og -fmacro-prefix-map=/Users/max_thrun/projects/repo=. -fmacro-prefix-map=/Users/max_thrun/projects/repo/esp-idf=/IDF -fstrict-volatile-bitfields -Wno-error=unused-but-set-variable -fno-jump-tables -fno-tree-switch-conversion -DconfigENABLE_FREERTOS_DEBUG_OCDAWARE=1 -fno-exceptions -fno-rtti -D_GNU_SOURCE "-DIDF_VER=\"v5.0\"" -DESP_PLATFORM -D_POSIX_READER_WRITER_LOCKS -fconcepts -Wfloat-conversion -Wno-error=restrict -Wno-missing-field-initializers -Wunused -c -resource-dir=/opt/homebrew/Cellar/llvm/15.0.6/lib/clang/15.0.6 -isysroot /Applications/XcodeInternal.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.5.sdk -x c++-header -std=gnu++20 -- /Users/max_thrun/.espressif/tools/xtensa-esp32s3-elf/esp-2022r1-11.2.0/xtensa-esp32s3-elf/xtensa-esp32s3-elf/include/sys/_stdint.h

But the command the compile main.cpp has the -isystem flags added correctly
I[11:57:06.908] ASTWorker building file /Users/max_thrun/projects/repo/main/src/main.cpp version 1 with command
[/Users/max_thrun/projects/repo/build/esp-idf/main]
/Users/max_thrun/.espressif/tools/xtensa-esp32s3-elf/esp-2022r1-11.2.0/xtensa-esp32s3-elf/bin/xtensa-esp32s3-elf-g++ --driver-mode=g++ -fdiagnostics-color=always -ffunction-sections -fdata-sections -Wall -Werror=all -Wno-error=unused-function -Wno-error=unused-variable -Wno-error=deprecated-declarations -Wextra -Wno-unused-parameter -Wno-sign-compare -Wno-enum-conversion -gdwarf-4 -ggdb -Og -fmacro-prefix-map=/Users/max_thrun/projects/repo=. -fmacro-prefix-map=/Users/max_thrun/projects/repo/esp-idf=/IDF -Wno-error=unused-but-set-variable -fno-jump-tables -DconfigENABLE_FREERTOS_DEBUG_OCDAWARE=1 -std=gnu++20 -fno-exceptions -fno-rtti -D_GNU_SOURCE "-DIDF_VER=\"v5.0\"" -DESP_PLATFORM -D_POSIX_READER_WRITER_LOCKS -Wfloat-conversion -Wno-error=restrict -Wno-missing-field-initializers -Wunused -std=gnu++20 -o CMakeFiles/__idf_main.dir/src/main.cpp.obj -c -D__XTENSA__ -D_POSIX_THREADS -D_POSIX_TIMEOUTS -D_UNIX98_THREAD_MUTEX_ATTRIBUTES -fno-blocks --target=aarch64-unknown-linux-gnu -isysroot/Users/max_thrun/.espressif/tools/xtensa-esp32s3-elf/esp-2022r1-11.2.0/xtensa-esp32s3-elf -isystem/Users/max_thrun/.espressif/tools/xtensa-esp32s3-elf/esp-2022r1-11.2.0/xtensa-esp32s3-elf/xtensa-esp32s3-elf/include/c++/11.2.0 -isystem/Users/max_thrun/.espressif/tools/xtensa-esp32s3-elf/esp-2022r1-11.2.0/xtensa-esp32s3-elf/xtensa-esp32s3-elf/include/c++/11.2.0/xtensa-esp32s3-elf -isystem/Users/max_thrun/.espressif/tools/xtensa-esp32s3-elf/esp-2022r1-11.2.0/xtensa-esp32s3-elf/xtensa-esp32s3-elf/include -isystem/Users/max_thrun/.espressif/tools/xtensa-esp32s3-elf/esp-2022r1-11.2.0/xtensa-esp32s3-elf/xtensa-esp32s3-elf/sys-include -resource-dir=/opt/homebrew/Cellar/llvm/15.0.6/lib/clang/15.0.6 -isysroot /Applications/XcodeInternal.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.5.sdk -- /Users/max_thrun/projects/repo/main/src/main.cpp

.clangd:
  CompileFlags:
      Add: [
          -D__XTENSA__,
          -D_POSIX_THREADS,
          -D_POSIX_TIMEOUTS,
          -D_UNIX98_THREAD_MUTEX_ATTRIBUTES,
          -fno-blocks,
          --target=aarch64-unknown-linux-gnu,
          -isysroot/Users/max_thrun/.espressif/tools/xtensa-esp32s3-elf/esp-2022r1-11.2.0/xten...,
          -isystem/Users/max_thrun/.espressif/tools/xtensa-esp32s3-elf/esp-2022r1-11.2.0/xten...,
          -isystem/Users/max_thrun/.espressif/tools/xtensa-esp32s3-elf/esp-2022r1-11.2.0/xten...,
          -isystem/Users/max_thrun/.espressif/tools/xtensa-esp32s3-elf/esp-2022r1-11.2.0/xten...,
          -isystem/Users/max_thrun/.espressif/tools/xtensa-esp32s3-elf/esp-2022r1-11.2.0/xten...,
    ]
      Remove: [
          -mlongcalls,
          -fstrict-volatile-bitfields,
          -fno-tree-switch-conversion,
          -fconcepts,
      ]

System information
Output of clangd --version:
Homebrew clangd version 15.0.6
Features: mac+xpc
Platform: arm64-apple-darwin21.6.0

Editor/LSP plugin:
nvim coc-clangd
     2 I[11:31:31.070] Homebrew clangd version 15.0.6
     3 I[11:31:31.070] Features: mac+xpc
     4 I[11:31:31.070] PID: 38666
     5 I[11:31:31.070] Working directory: /Users/project/repo
     6 I[11:31:31.070] argv[0]: /opt/homebrew/opt/llvm/bin/clangd
     7 I[11:31:31.070] argv[1]: --background-index
     8 I[11:31:31.070] argv[2]: --clang-tidy
     9 I[11:31:31.070] argv[3]: --suggest-missing-includes
    10 I[11:31:31.070] argv[4]: --compile-commands-dir=build
    11 I[11:31:31.070] argv[5]: --log=verbose

Operating system:
ProductName:    macOS
ProductVersion: 12.5.1

Where is the .clangd file? Is it above _stdint.h?

Where is the .clangd file? Is it above _stdint.h?

They share a common ancestor director (my home folder)

Hmm, sounds very strange. Can you run clangd --check=/path/to/_stdint.h --verbose and report all the lines with "config" in them as well as the "compile command from CDB"?

Where is the .clangd file? Is it above _stdint.h?

They share a common ancestor director (my home folder)

Just to clarify, .clangd is located at /Users/max_thrun/.clangd? Otherwise, if it's located at e.g. /Users/max_thrun/projects/repo/.clangd or somesuch, it will not apply to headers in /Users/max_thrun/.espressif/...

Can you run clangd --check=/path/to/_stdint.h --verbose and report all the lines with "config" in them

max_thrun@thrun ~/projects/repo/ % clangd --log=verbose --check=~/.espressif/tools/xtensa-esp32s3-elf/esp-2022r1-11.2.0/xtensa-esp32s3-elf/xtensa-esp32s3-elf/sys-include/sys/_stdint.h 2>&1 | grep -i config
V[11:17:53.766] User config file is /Users/max_thrun/Library/Preferences/clangd/config.yaml

My .clangd file is in ~/projects/repo/
If I check one of the cpp files in my project:
max_thrun@thrun ~/projects/repo % clangd --compile-commands-dir=build --log=verbose --check=main/src/main.cpp 2>&1 | grep "config"
V[11:20:01.458] User config file is /Users/max_thrun/Library/Preferences/clangd/config.yaml
V[11:20:01.458] config note at /Users/max_thrun/projects/repo/.clangd:1:0: Parsing config fragment
V[11:20:01.458] config note at /Users/max_thrun/projects/repo/.clangd:1:0: Parsed 1 fragments from file

as well as the "compile command from CDB"?

No match for _stdint.h
For the cpp file in my repo:
max_thrun@thrun ~/projects/repo % clangd --compile-commands-dir=build --log=verbose --check=main/src/main.cpp 2>&1 | grep "CDB"
I[11:21:26.285] Compile command from CDB is: /Users/max_thrun/.espressif/tools/xtensa-esp32s3-elf/esp-2022r1-11.2.0/xtensa-esp32s3-elf/bin/xtensa-esp32s3-elf-g++ --driver-mode=g++ <more flags snipped>

Where is the .clangd file? Is it above _stdint.h?

They share a common ancestor director (my home folder)

Just to clarify, .clangd is located at /Users/max_thrun/.clangd? Otherwise, if it's located at e.g. /Users/max_thrun/projects/repo/.clangd or somesuch, it will not apply to headers in /Users/max_thrun/.espressif/...

It's located at /Users/max_thrun/projects/repo/.clangd, so maybe that explains it, although slightly surprising behavior imo. I am running clangd from /Users/max_thrun/projects/repo/ so I would expect the config to apply to any file it processes.
I can solve this problem by using --query-driver and removing the -isystem from my .clangd config but I don't want to have to have my whole team set their --query-driver. I was hoping to solve the issue for this repository specifically.

.clangd files apply to files within their directory scope as documented here: https://clangd.llvm.org/config#files
If you want config to apply to all files, put it in ~/.config/clangd/config.yaml.
Configs checked into a repo can only affect how files in that repo are processed, by design.


[AIRFLOW-4132] Set default connection ID for all operators

Make sure you have checked all steps below.
Jira

https://issues.apache.org/jira/browse/AIRFLOW-4132

Description
Some operators do not have a default connection ID set, which makes their use more difficult. This PR introduces the default ID for all operators.
Tests

[ ] My PR adds the following unit tests OR does not need testing for this extremely good reason:

Commits

[ ] My commits all reference Jira issues in their subject lines, and I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message":

Subject is separated from body by a blank line
Subject is limited to 50 characters (not including Jira issue reference)
Subject does not end with a period
Subject uses the imperative mood ("add", not "adding")
Body wraps at 72 characters
Body explains "what" and "why", not "how"

Documentation

[ ] In case of new functionality, my PR adds documentation that describes how to use it.

When adding new operators/hooks/sensors, the autoclass documentation generation needs to be added.
All the public functions and the classes in the PR contain docstrings that explain what it does
If you implement backwards incompatible changes, please leave a note in the Updating.md so we can assign it to a appropriate release

Code Quality

[ ] Passes flake8

Done by community


Respect max_header_tokens option

Ref #4, thanks to @iamdustan who correctly pointed out that we should respect the max_header_tokens options of the .flowconfig.
Something like
const flowconfig = await danger.github.utils.fileContents('.flowconfig')
// TODO: Figure out how to parse .flowconfig somehow (why isn't it JSON ugh)

We are not proud of our custom format and plan to support a better format in the future. GitHub issue #153 tracks this.

https://github.com/facebook/flow/issues/153 :hurtrealbad:

https://repl.it/@kevinSuttle/Parsing-flowconfig-to-find-maxheadertokens

PR please? :angel:

Do you have suggestions for local testing?

Mocking the Danger method, see the existing tests: https://github.com/withspectrum/danger-plugin-flow/blob/master/src/index.test.ts

Yep, saw those. I haven't tested a Danger plugin before—in other words, how do I test it against a set of files as if it's a PR? Is that possible?

We don't have that kind of fancy mocking in place, I'd just check whether the requested filename is .flowconfig and return the contents of that.


Extract shell tester

Extract shell test to run/test command in multiple shells

Basically done here https://github.com/matejkosiarcik/azlint


EUR requests returning strings and others returning floats

Is it intended for requests with base="EUR" return a rate with a value as a string while all other bases return floats? It seems to make more sense for all bases to return the same rate type. If this should be changed, I can try and write up a PR. If it was intentional, you can disregard and close this issue. Thanks!

Thanks for knowing.Issue is fixed

The problem still persists in historical data, see e.g. https://theforexapi.com/api/2021-06-01/?base=EUR


[Deep Dive] [States - Total cases] Able to select and de-select all states

Is your feature request related to a problem? Please describe.
It would be great if I am able to select a state in faster way, I am frustrated when I have to go and strike-out (disable) all the other states except the one I want to see.
Describe the solution you'd like
Probably a button with Select all (enabled by default), Select none, when clicked upon striking out all the states
Describe alternatives you've considered
-- None --
Additional context
It would be easier to compare two or more states in more convenient way

#duplicate of #836


Frequent API changes really hurting us downstream

Hello—
I write not to ask you to stop changing API's, as such a request is impossible, but to document the changes better when you do, and to please not change them so frequently, for example, currently master is being called 0.8.1, that's not correct, you've changed many API's already since September, really in truth you're already on 0.9.
Just look at the size of this changeset: https://github.com/MFEK/glif/pull/128
We're struggling to keep up with you, which is quite a problem. Also, no release was made after the fix to the freetype feature, so that's why in that PR, which I hope to be able to finally merge, I'm referring directly to HEAD.

Hmm. What's the reason you're tracking HEAD? It might be better for us to adjust that. There's a combination of things we're doing deliberately here, and that I don't know that we want to change.

A lot of the imgui-rs APIs are believed to not be particularly nice to use by most of the current maintainers. Unfortunately, this means the next releases are likely to contain more breaking changes.
I guess in some cases I also think we probably can let APIs go through a deprecation cycle prior to removal where possible, to reduce breakage downstream. I've tried to do this where possible but not very aggressively.

The CHANGELOG is pretty good for documenting changes: https://github.com/imgui-rs/imgui-rs/blob/main/CHANGELOG.markdown. If you think we should do a better job at the updates in full releases, I think we'd take it seriously...
... But I don't think we can honor a request to keep it fully up to date as we go during development.
Sorry. This might be a pain, but it is the tradeoff of tracking HEAD/`main/unreleased versions. You get changes sooner, but they don't have as much polish.

I'm unsure about bumping local dev version in advance of the public release. Generally, doing this will break patch.crates-io for anybody who wants to use it, wheras if we don't bump, if a user needs to make an update, they can patch it.
That said, nobody will want to use patch.crates-io in the case where there are breaking changes, so is it a good idea to bump the version in advance of the release? No. Doing things this way becomes extremely easy to get wrong.
Consider the situation of long-lived WIP outstanding branches. If we change to a flow where we bump version numbers in patches that make breaking changes, the question of "does the patch update the version number to the correct version" no longer is a question that solely[^1] takes the contents of the patch into account. It also has to take into account the last version released on crates.io, and whether or not the bump has already been made on a patch thats been merged into main branch.
Admittedly, development in imgui-rs is not so rapid that this is as problematic as it would be in other repos, but I'd still be against it. It falls into what I said above about "the tradeoff of tracking HEAD/`main/unreleased versions"

[^1]: If this is unintuitive, consider that we need to prevent old branches that downgrade the major version, and bumping the major version twice between releases.

Anyway, of all of these I'm by far the most positive towards reducing the number of breaking changes by keeping old APIs around longer as #[doc(hidden)] #[deprecated], where possible. This would also do the most to address the other problems, while also not requiring extra work on our part, or changes to our development workflows.
Of course, note that its definitely not always possible for us to do this. I think it might be more important to do some cases than others.
And, sorry, but I suspect we don't want to make promises about what happens in main in-between versions. (Sometimes it's much better for us to land changes in multiple phases, addressing issues in follow-ups, for example)

I'm tracking main at present only due to build failures in the imgui/freetype feature when I don't. See e.g. https://github.com/MFEK/glif/runs/4128961546?check_suite_focus=true , could not find "misc/freetype/imgui_freetype.h". I have a feeling something is messed up on crates.io, perhaps the file is not even in the zip there, I do not know.

Hm, yeah, that's a bug. Surprised it's not covered in CI too. I'm not sure exactly what's wrong, but will look into it. I guess it probably works with a git checkout because it will pull the submodule rather than a .crate file.
If the fix's patch is small and localized I can probably publish a hotfix for that cherry-picks it on top of 0.8 (ofc the timing for publishes is delayed by the need for review and such).

Good to know it's not my problem. MFEK/glif#128 is a very long-running PR due to many issues like this :sweat_smile:
I'll wait a few days for patches and see if I can go back to tracking crates.io, which I would of course prefer to do.

Good to know it's not my problem

FWIW please file issues you see in the future, even if unsure. It's better to file when in doubt, since you're probably not alone in having it, and we'd rather know that something is error-prone to use, or if there's build configuration you can't use together or on some target, etc.

Chiming in as someone who is using the crates.io-published version of this crate, I am having to make far too many changes to widget invocations between versions. I do appreciate some of the recent API fixes, such as removing the reliance on ImString and using DrawData to do rendering which should theoretically fix #210. But I really wish that the API would pick a style of widget creation and stick to it. Previously the API was moving away from ui.widget_name() to imgui::WidgetName::new() (for some widgets), and is now reversing course. I am also having to constantly switch where the imgui::Ui parameter goes. Many functions are having ui removed from their build() and put into new(). But some objects have a different argument ordering in new() so we have both imgui::Window::new(ui, label) and imgui::MenuItem::new(label, ui). Which is probably going to get modified again in a future release, leading to even more breakage, etc. I even saw an instance where ui was moved into a build() function. Please please please stop flip-flopping and just decide on a consistent API, fix it once across all widget types and just leave it like it is.

I agree with everything @cosmicchipsocket wrote. If you look at the size of MFEK/glif#128 it's primarily me fixing the issues they describe, back and forth. It's why we've had to stick to imgui 0.7.0 for so long. The nuclear option for our project would be forking, which we unfortunately do for a few of our dependencies that have…difficult…maintainers, I don't see that here yet but yes it is annoying how often things move for seemingly no reason. Although, I do understand that this project has changed hands multiple times, and each new maintainer has their own idea of how to do it. I think that in Rust libraries it's still far too accepted to drastically change API's, while such changes would be anathema in C/C++ code.

@cosmicchipsocket @ctrlcctrlv Hi guys, I'm the primary maintainer and the driver of these breaking changes. I really appreciate the feedback, and especially your noting of inconsistent build order between Window::new and MenuItem::new. For that problem specifically, and for most issues, it's mostly a question of inertia and time -- the Window::new changes happened earlier during this version cycle and will be changed before release. This is an unfortunate problem about being on HEAD in any project which sees significant changes of course -- not only are our changes significant, they're not even in a releasable state at all times!
I can see how frustrating this must be. For you, and for most people, imgui is just a tool, and well, sure it's nicer, but you just want it to work, you know? Especially if your work with the tool has already been DONE, you're mostly just updating code for well, no real reason, right? Compounding that with #564, you can't even stick to release right now. I'll comment more on that issue there on that specific issue, but I can see how this would be a frustration point.
My only real solution for you isn't a very nice one -- we keep a tracking issue here #531 where most of these changes were discussed. Equally, the repo is the source for all discussions that we have, so all the decisions are happening here in text. I know that's cold comfort, since I'm effectively saying "put in a lot of effort to be immersed in an upstream dependency, and you'll be less surprised!" but, as you've both noted, these are good changes. The switch from dedicated structs to methods, imo, is the correct one, along with removing the Ui lifetime, and deprecating/removing ImStr/ImString, along with a host of other changes. We try hard to meticulously document them in the CHANGELOG, but, unfortunately, I can only promise that the changelog is in a 100% valid state on release. I spend a few hours going through all the commits between releases and updating that log. Ideally, each change would notate it for themselves, but we get a reasonable amount of contributors who don't feel comfortable editing the public facing documents, and so it sometimes slips (and of course, we're all volunteers here, after all).
Thom and I will talk about cherry picking in the free-type and the input buffer fixes, as you aren't the only who have found those unfortunate problems (sorry about that!), but beyond that, we'll try our best to make sure to document these changes, both in code and outside of code!

MFEKglif is still quite far from "done," but of all the projects under the MFEK org, it's the most done; perhaps 85%. But it is part of a series of planned tools, so primarily the calculus going on right now for me is whether or not the stack I chose for MFEKglif is going to persist for the other programs in the collection. I'd say that anyone starting a large project right now, and who chooses Rust, instead of one of the "tried and true" languages, is already willing to put up with some stability. For example, we actually appreciated the deprecation of ImString, it simplified things for us a lot, and made this crate more appealing, not less.
I can't speak for @cosmicchipsocket's project, I don't know what it is. But for MFEK, essentially there are multiple directions we can go in. I could decide that MFEKufo is to use gtk(4)-rs, for example, and consider the skulpin/imgui stack in use by MFEKglif “deprecated” or at the very least MFEKglif-only.
I hope that helps describe my position in all this.

I can't speak for @cosmicchipsocket's project, I don't know what it is.

I'm the sole developer and maintainer of Keeshond Game Engine.
https://gitlab.com/cosmicchipsocket/keeshond
I created Keeshond after being frustrated with most of the popular engines (Unity, Clickteam Fusion, Game Maker). It's my first major Rust project, and so far my most successful attempt at making my own engine. Much like this crate, my engine is currently in a bit of flux as I'm reworking and fixing issues with old code. Right now I don't have many users (I'm aware of maybe one or two), though that might change once I add more features and start promoting it.
Keeshond's imgui integration is fairly thin. Essentially it's a crate feature that runs a user-defined method where you write your own imgui UI code, and the backend handles the timing, input, and rendering behind the scenes. There's also two small examples that make light use of imgui.
The Keeshond Editor on the other hand is significantly more dense. There's a lot of nested code (and rightward drift ;) ), and of course direct use of the imgui widget APIs since imgui by its nature tends to couple together the view and business logic. The editor features several subeditors for different resources, including a visual level editor, along with wizard dialogs for new resources and a UI for configuring auto-import.
Despite the occasional hairiness I'd say that imgui is one of the more pleasant GUI frameworks I've worked with. I'm able to get a functional UI up and running much faster than other frameworks that require the data to be in two places which can easily become desynced and add a lot of boilerplate, not to mention callback/change notification soup.
I think API breakage is cool but it should be done with purpose. Right now it's hard to see the overall purpose of changing the style of widget constructors. And I also worry that a removed API might take away functionality without a suitable replacement, leaving me unable to port code to the next release. At the very least I would like the maintainers here to be conscious about whether the changes made to the API will cause friction with the borrow checker, since I often use style/color/window tokens and make function calls while inside a window as a means of abstraction. Not every imgui program is as simple as Hello World.

Not every imgui program is as simple as Hello World.

I'd agree with that, and maybe also say that we should perhaps take this as a positive sign, that Rust GUI projects are maturing beyond demos/throwaway toy programs into very large applications.
MFEKglif for example—just MFEKglif, not including glifparser/math.rlib/ipc.rlib/other libraries I and others wrote to support it, already totals over 10,000 lines of Rust code according to tokei. It has some features that aren't even found in proprietary OpenType font editors, and is already used in my production fonts.
The struggle we're having here is primarily a struggle with maturity, which shouldn't be seen as a negative at all, but just a consequence of Rust itself maturing. For example, just this past week, with the new Rust release I was able to switch all MFEK modules and libraries to building with the stable compiler, which I saw as an important milestone. I even registered mfek.org because I've become very sure of the project's future; I even already have users other than myself.


KeyError when optional key config not provided

The readme says that key is not required but without it I got a KeyError. So we could either make key required and update the doc along with adding a required field in the tap schema or leave it optional and add .get("key") instead of '["key"]'.
line 55, in get_url_params
    "key": self.config["key"],

@pnadolny13 you're right. Sending in a fix for this to make it truly optional


Password Encryption

Passwords are stored unencrypted. This is a security concern. Noted by schanna

Is that true? I haven't looked into this but the admin section of the site says they are encrypted

Oh, interesting! I neglected to check. Stephen mentioned it, so I'll ask him to clarify.


[Fixed] Critical Build Errors

I tried building for x64 Windows, but got 7 Errors that would prevent it.
The error message was always a variation of this:
Library\PackageCache\com.av.smart-hierarchy@94113c3d21\Base\HierarchySettingsProvider.cs(8,26): error CS0234: The type or namespace name 'EditorGUI' does not exist in the namespace 'UnityEditor' (are you missing an assembly reference?)
After removing Smart Hierarchy the build process did complete as it should.
Screenshot of the Console:

I wrote in pull request the reasoning behind this problem.

I wrote in pull request the reasoning behind this problem.

Here's a little nasty, temporary workaround for it:

I hope noone builds games for x32 machines these days, eh?

Oh freak, it actually doesn't work, because Unity always builds for x32 :(
I guess I'll have to make it even nastier:


Fix OSX inconsistency in bloodhound-server

Apparently OSX doesn't have readlink -{f,e} or a comparable tool without rolling your own. In an attempt to avoid that, concatenating with "${PWD}" should suffice for almost all use-cases I can think of.
Unfortunately I don't have an OSX box to test on so I've been working blind on cross-compatibility; completely relying on bug reports :cold_sweat: Will merge on confirmation.

Should be good now :+1:

Whoops, this introduced a race condition by bringing readlink before the download jobs are joined. Fixed in latest


set maximal z-index to 3

A very high z-index can cause a conflict with CMS like Concrete5 that put overlays on content when editing. I don't see any disadvantage in just setting it lower here.

This makes no sense.

Hi schjetne,
I'm not sure if you mean you don't get what I mean or you think this
change just doesn't make sense for Orbit. However I've uploaded a
screenshot of the issue that I have in mind:
http://patrickheck.de/shared/c5_overlays.PNG
This shows the Orbit addon for Concrete5 that I am just developing. As
you see the control elements of Orbit are floating above the popup
window because the default z-index for popups is just 99 in Concrete5.
My thought was just that Orbit might also be used in other contexts
where people would like to put elements over it (like lightboxes) and it
can't really harm to keep the z-index lower for that reason. But maybe I
also forgot about problems that this might cause on the other hand...
What do you think?
Best
Patrick
Patrick Heck
/Dipl. Kommunikationsdesigner
Fachinformatiker für Anwendungsentwicklung/
Thebäerstraße 55
54292 Trier
Tel: +49<PHONE_NUMBER>
Fax: +49<PHONE_NUMBER>3
<EMAIL_ADDRESS>Am 18.12.2011 03:15, schrieb schjetne:

This makes no sense.

Reply to this email directly or view it on GitHub:
https://github.com/zurb/foundation/pull/177#issuecomment-3192803

We'll need to run through and verify none of the plugins (like Reveal) require higher z-indices - we weren't aware high values could conflict with CMSs. Thanks for this, we'll pull it into a release in very early January.

I'm not sure that 3 is sufficient, but it seems that anything under ~50 would be acceptable.

Okay, so 3 was a little...aggressive :) but we've tooled everything to be lower than 50 in the base Foundation (in fact the highest is 41, for Reveal). 7ce9f678c0a03de074d2f02707f9fb593da69dff


Doesn't connect

The app does connect to the i3s, but nothing happens afterwards on chrome / mac.
On WebBLE on Ipad there is thrown an error message: "console.time is not a function" and
console.time("scrambo.initialize took")... is undefined...

any news why the "new 2019 version" can't connect?


Create generic API document

Create a generic API introduction that discusses how to send/receive messages to the simulator. This should focus on emphasizing that only messaging is required to actually control the simulation in any language.

This was closed with #116


Lazy Routes Fail To Load, but Only with ng serve -prod

Please provide us with the following information:

OS?  Windows 7, 8 or 10. Linux (which distribution). Mac OSX (Yosemite? El Capitan?)

Windows 10

Versions:

angular-cli: 1.0.0-beta.6
node: 6.1.0
os: win32 x64

Repro steps. Was this an app that wasn't created using the CLI? What change did you
do on your code? etc.

Fresh install of a new project, when using version 3.0.0-alpha.6 of @angular/router, lazy routes are not able to load when using "ng serve -prod". The normal routes work fine under prod mode, and both lazy routes and normal routes work fine with just "ng serve"

The log given by the failure. Normally this include a stack trace and some
more information.

 EXCEPTION: Error: Uncaught (in promise): Error: Error: XHR error (404 Not Found) loading http://<IP_ADDRESS>:4200/app/lazy/lazy.js 	    at XMLHttpRequest.wrapFn [as _onreadystatechange] (http://<IP_ADDRESS>:4200/vendor/zone.js/dist/zone.js:769:30) 	    at ZoneDelegate.invokeTask (http://<IP_ADDRESS>:4200/vendor/zone.js/dist/zone.js:356:38) 	    at Object.onInvokeTask (http://<IP_ADDRESS>:4200/main.js:23:29322) 	    at ZoneDelegate.invokeTask (http://<IP_ADDRESS>:4200/vendor/zone.js/dist/zone.js:355:43) 	    at Zone.runTask (http://<IP_ADDRESS>:4200/vendor/zone.js/dist/zone.js:256:48) 	    at XMLHttpRequest.ZoneTask.invoke (http://<IP_ADDRESS>:4200/vendor/zone.js/dist/zone.js:423:34) 	Error loading http://<IP_ADDRESS>:4200/app/lazy/lazy.js zone.js:461 Unhandled Promise rejection: Error: XHR error (404 Not Found) loading http://<IP_ADDRESS>:4200/app/lazy/lazy.js 	    at XMLHttpRequest.wrapFn [as _onreadystatechange] (http://<IP_ADDRESS>:4200/vendor/zone.js/dist/zone.js:769:30) 	    at ZoneDelegate.invokeTask (http://<IP_ADDRESS>:4200/vendor/zone.js/dist/zone.js:356:38) 	    at Object.onInvokeTask (http://<IP_ADDRESS>:4200/main.js:23:29322) 	    at ZoneDelegate.invokeTask (http://<IP_ADDRESS>:4200/vendor/zone.js/dist/zone.js:355:43) 	    at Zone.runTask (http://<IP_ADDRESS>:4200/vendor/zone.js/dist/zone.js:256:48) 	    at XMLHttpRequest.ZoneTask.invoke (http://<IP_ADDRESS>:4200/vendor/zone.js/dist/zone.js:423:34) 	Error loading http://<IP_ADDRESS>:4200/app/lazy/lazy.js ; Zone: angular ; Task: Promise.then ; Value: Error: Error: XHR error (404 Not Found) loading http://<IP_ADDRESS>:4200/app/lazy/lazy.js(…)consoleError @ zone.js:461_loop_1 @ zone.js:490drainMicroTaskQueue @ zone.js:494ZoneTask.invoke @ zone.js:426 zone.js:463 Error: Uncaught (in promise): Error: Error: XHR error (404 Not Found) loading http://<IP_ADDRESS>:4200/app/lazy/lazy.js(…)

Closed as obsolete following #1455. We are working on updating routes though, and the async scenario is one of our top priority following the build system change.


Respond to message to go FullScreen from Window Manager

On Pi, the window manager adds close, iconize and full-screen buttons to window descorations.
Close Works
Iconize works
Full-screen does not work. I assume this sends a message to Iced, which we need to respond to in some way, or it's part of app settings via Iced when creating App.
Desired Behaviour

User can click full-screen and piggui will go full screen
User can click again ("restore") and window returns to original place and size

will find a way to implement that

Consider reviewing layouts when doing this?
Have the window it "shrink to fit" the content, and avoid a fixed size. It would change size depending on the layout selected, and get narrower and higher on BCM layout, and avoid big black spaces on all layouts

This now seems to work on macOS @sundaram123krishnan

I'd check Linux, and maybe it's fixed?

It goes full-screen in macos, linus and pi.
So I think this is fixed and I will close it.
The problem is, as we are using fixed layouts, we don't take advantage of that extra space in any way, and the version text ends up floating in the middle, not pressed against the bottom.
Once we have a more complete UI, and we know all the things we want on screen and how they resize, then maybe it will be time to use more Fill/Shrink sizes for parts of the UI and revisit that.


Saving result in a diff file ?

Would it be possible to save the in a .diff file ? So it's possible to with git apply foo.diff to apply the change ?
If not, could you give a few pointers on which part of the code I should look at to add this feature ?

Well, there's a DirectoryPatcher struct whose job is to find the source files, and a FilePatcher struct to compute and apply patches to each file one by one. I guess we could split main() and either re-use the FilePatcher or write a new struct to write the replacements to a .diff file.
Not sure what's your use case, though. I usually use ruplacer like this:
$ git status
# Make sure no change neds to be committed
$ ruplacer foo bar
# Make sure the diff looks ok
$ ruplacer foo bar --go
$ git add .
$ git commit -m "Replace foo with bar"

In your case, you could replace the git add . command with git diff HEAD~1 > foo.diff and that would produce the file you want, so I'm not sure the feature you're asking is useful.
Do tell me if I missed something, though.

By the way, I can add something about #44 - I guess you could achieve the "selection feature" by using git add -p instead of git add.
In other words, let ruplacer write changes to the file system, and let git handle the diffs :)


[EXT-SEC-AUDIT] Error checking before charging Tx for gas is inconsistent

Issue transferred from an external security audit report.

Severity: Informational
Difficulty: Undetermined
Type: Denial of Service
Finding ID: TOB-OL-106
Target: go/consensus/tendermint/apps/staking/transactions.go
Description
reclaimEscrow() transaction does not charge the sender any gas if
reclaim.Shares.IsZero() is true. All other transaction types
( transfer/burn/addEscrow/amendCommissionSchedule ) charge the transaction for gas
before any executing any logic, including error checking.

Figure TOB-OL-106.1 shows https://github.com/oasislabs/oasis-core/blob/f331a877721f44cc2412b4248d66e95f83f4cf9c/go/consensus/tendermint/apps/staking/transactions.go#L220-L317

Exploit Scenario
An attacker calls reclaimEscrow forcing a node to perform additional work for no cost.
Recommendation
Move reclaim.Shares.IsZero() error checking to after charging gas, similar to other
transaction method implementations.

reclaimEscrow() transaction does not charge the sender any gas if reclaim.Shares.IsZero() is true

Yeah but it also fails immediately (even in CheckTx) before any other processing is done. An IsZero check seems pretty lightweight.


Is it similar to ProphetNet, ProphetNet-Ads and BANG?

https://arxiv.org/abs/2001.04063
ProphetNet, a looking head strategy for parallel decoding,
and
https://arxiv.org/abs/2010.10789
ProphetNet-Ads, a deployment of this looking ahead generation model.

Hi, thanks for your interest!
I just read your paper and found it is quite different.


Multi-server state and recovery

What's the expected result of partially deploying to a multi-server environment? So far what I'm getting is that completing a release on server 1 then stopping it, re-deploying will always fail on server 2 where it can't change to the release directory and errs out.
Should there be inline recovery? Manual recovery? I'd love to know which way Rocketeer is heading so I can design around that (either automating a manual recovery or working extra steps into an inline recovery). For now I'm working out a separate task that does some validation and state matching for this particular project and that's working alright.

I'm not sure I get it, why would server 2 fail if you stopped server 1?

In this example: On the second deploy, Rocketeer tries to change into an invalid release directory. I feel like its getting all its state information from the first server only (but haven't looked yet!)

Yes that sounds like it, will try to push a fix

Should work on develop now, can you give it a shot?

This works much better, thank you!  It is recommended to update it by running "/www/sites/www.c.com/releases/20150120085908/composer.phar self-update" to get the latest version.
<EMAIL_ADDRESS>(local-full) Loading composer repositories with package information
<EMAIL_ADDRESS>(local-full) Installing dependencies (including require-dev) from lock file
<EMAIL_ADDRESS>(local-full) Nothing to install or update
<EMAIL_ADDRESS>(local-full) Generating autoload files
$ [ -e "/www/sites/www.c.com/current/package.json" ] && echo "true"
local-full/0/dev   |------ Dependencies/Npm (Installs dependencies with NPM)
$ cd /www/sites/www.c.com/releases/20150120091400
$ /usr/local/bin/npm install
<EMAIL_ADDRESS>(local-full<EMAIL_ADDRESS>node_modules/karma-webdriver-launcher
└──<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>$ [ -e "/www/sites/www.c.com/current/bower.json" ] && echo "true"
local-full/0/dev   |=> Setting permissions for /www/sites/www.c.com/releases/20150120091400/
local-full/0/dev   |=> Setting permissions for /www/sites/www.c.com/releases/20150120091400/
local-full/0/dev   |-- Directories (Sets up directories) fired by deploy.before-symlink [~0.1s]
local-full/0/dev   |===> Creating directories
$ cd /www/sites/www.c.com/releases/20150120091400
$ mkdir -p app/{cache,logs}
local-full/0/dev   |-- Parameters (Sets up parameters) fired by deploy.before-symlink [~0.11s]
local-full/0/dev   |===> Creating an empty parameters.yml
$ cd /www/sites/www.c.com/releases/20150120091400
$ touch app/config/parameters.yml
local-full/0/dev   |-- Cache (Clears and warms caches) fired by deploy.before-symlink [~35.16s]
local-full/0/dev   |===> Clearing and warming caches
$ cd /www/sites/www.c.com/releases/20150120091400
$ php -dmemory_limit=-1 app/console cache:clear --env=dev
<EMAIL_ADDRESS>(local-full) Clearing the cache for the dev environment with debug true
<EMAIL_ADDRESS>(local-full) PHP Warning:  filemtime(): stat failed for /www/sites/www.c.com/releases/20150120091400/app/../htdocs//bundles/web/css/tinymce-content.css in /www/sites/www.c.com/releases/20150120091400/src/project/WebBundle/DependencyInjection/Web/WebExtension.php on line 100
local-full/0/dev   |-- Assets (Sets up assets) fired by deploy.before-symlink
local-full/0/dev   |===> Not an "asset" node, skipping
local-full/0/dev   |-- Permissions (Sets permissions) fired by deploy.before-symlink [~0.13s]
local-full/0/dev   |===> Setting permissions
$ cd /www/sites/www.c.com/releases/20150120091400
$ chmod -R 777 app/cache
$ chmod -R 777 app/logs
$ [ -e "/www/sites/www.c.com/releases/20150120091400" ] && echo "true"
$ [ -e "/www/sites/www.c.com/current" ] && echo "true"
$ rm -rf /www/sites/www.c.com/current
$ ln -s /www/sites/www.c.com/releases/20150120091400 /www/sites/www.c.com/current
local-full/0/dev   |=> Successfully deployed release<PHONE_NUMBER>1400
local-full/0/dev   |-- Fpm (Reloads FPM) fired by deploy.after
local-full/0/dev   |===> Not a "worker" node, skipping
local-full/0/dev   |-- Nginx (Updates the site root and reloads nginx) fired by deploy.after
local-full/0/dev   |===> Not a "balance" node, skipping
local-full/0/dev   | Cleanup (Clean up old releases from the server)
$ rm -rf /www/sites/www.c.com/releases/20150120084737
local-full/0/dev   |=> Removing 1 release from the server
local-full/1/dev   | Deploy (Deploys the website) [~140.45s]
$ [ -e "/www/sites/www.c.com/current" ] && echo "true"
local-full/1/dev   |-- Primer (Run local checks to ensure deploy can proceed)
local-full/1/dev   |-- CreateRelease (Creates a new release on the server) [~87.2s]
local-full/1/dev   |---- Deploy/CopyRole (Copies the previously cloned instance of the repository and update it, with roles)
local-full/1/dev   |===> Copying previous release "/www/sites/www.c.com/releases/20150120090908" in "/www/sites/www.c.com/releases/20150120091400"
$ [ -e "/www/sites/www.c.com/releases" ] && echo "true"
$ cp -a /www/sites/www.c.com/releases/20150120090908 /www/sites/www.c.com/releases/20150120091400
<EMAIL_ADDRESS>(local-full) cp: /www/sites/www.c.com/releases/20150120090908: No such file or directory
Pulling changes
$ cd /www/sites/www.c.com/releases/20150120091400
$ git reset --hard
$ git pull -v
<EMAIL_ADDRESS>(local-full) bash: line 0: cd: /www/sites/www.c.com/releases/20150120091400: No such file or directory
local-full/1/dev   |-- Dependencies (Installs or update the dependencies on server) [~8.85s]
local-full/1/dev   |---- Dependencies/Polyglot (Runs all of the above package managers if necessary)
$ [ -e "/www/sites/www.c.com/current/Gemfile" ] && echo "true"
$ [ -e "/www/sites/www.c.com/current/composer.json" ] && echo "true"
local-full/1/dev   |------ Dependencies/Composer (Installs dependencies with Composer)
$ cd /www/sites/www.c.com/releases/20150120091400
$ composer install --no-interaction --prefer-source
<EMAIL_ADDRESS>(local-full) bash: line 0: cd: /www/sites/www.c.com/releases/20150120091400: No such file or directory
local-full/1/dev   |=====> An error occured: "Composer could not install dependencies"
local-full/1/dev   |-- Fpm (Reloads FPM) fired by deploy.after
local-full/1/dev   |===> Not a "worker" node, skipping
local-full/1/dev   |-- Nginx (Updates the site root and reloads nginx) fired by deploy.after
local-full/1/dev   |===> Not a "balance" node, skipping
The tasks queue was canceled by task "Deploy"
Execution time: 147.5482s
Saved logs to /Users/shonm/Sites/Com/deploy/.rocketeer/logs/local-full-dev-20150120_09:14:00.log
Saved logs to /Users/shonm/Sites/Com/deploy/.rocketeer/logs/local-full-dev-20150120_09:16:26.log
bin/rocketeer deploy --on=local-full -vvv  1.42s user 0.11s system 1% cpu 2:27.93 total
➜  deploy git:(deploy-next)

This is after maybe 5 cancelled deploys. Working on various different things at once, it's easy to start, cancel, make some changes, repeat.

Not sure I'm decyphering correctly what is happening in the log, what is the main issue here?

To keep your issue sink clean I'll close this and open a fresh one with fresh details about the stack including the much improved logs!


NodeJS PoC

Description
Small PoC that modifies our perf execution to add perf inject --jit - making it automatically handle processes that support perf's "JIT" protocol, such as node --perf-prof.
This is less nice because it requires modifying code / configuration, unlike other profilers which require no changes at all (and besides async-profiler, truly non-intrusive to the app).
But... it just works :)
TODOs:

[x] Add better explanation in README
[ ] Add coloring for Node frames / builtins (perhaps color all frames that come from /tmp/jitted-*.so?)
[x] Clean up jitted leftovers? After perf inject --jit or when gProfiler goes down?
[x] Run perf inject --jit only if needed (to avoid overhead); or prove its overhead when there are no jitdump map entries is null
[ ] Think about making this automatic (i.e, enabling --perf-prof in runtime)
[ ] Possibly -k 1 is not supported on all systems; in which case, don't use it and don't run perf inject --jit. Test it on some 2.6 kernel
[x] Add sanity tests

Motivation and Context
NodeJS profiling support :)
How Has This Been Tested?
Local sanity on docker run -it --rm node:14 --perf-prof --interpreted-frames-native-stack which runs while (1) { }
Screenshots

Checklist:

[x] I have read the CONTRIBUTING document.
[ ] I have updated the relevant documentation.
[ ] I have added tests for new logic.

Since (for now) this ain't automatic and requires the user to pass --perf-prof in their app, I decided to also require the user to pass --nodejs-mode perf in order to enable the perf inject --jit part (avoiding it when not needed, for performance reasons)

@michelhe , now it will pass

Merged https://github.com/Granulate/gprofiler/pull/113 into here

Tests still failing

Kill me why, but doesn't work when Node runs on the host. Well, the inject --jit part does work:
node;__libc_start_main;node::Start;node::NodeMainInstance::Run;node::LoadEnvironment;node::StartExecution;node::StartExecution;node::ExecuteBootstrapper;v8::Function::Call;v8::internal::Execution::Call;v8::internal::(anonymous namespace)::Invoke;Builtin:JSEntry;Builtin:JSEntryTrampoline;InterpretedFunction: internal/main/run_main_module.js:1;InterpretedFunction:executeUserEntryPoint internal/modules/run_main.js:69;InterpretedFunction:Module._load internal/modules/cjs/loader.js:725;InterpretedFunction:Module.load internal/modules/cjs/loader.js:938;InterpretedFunction:Module._extensions..js internal/modules/cjs/loader.js:1094;InterpretedFunction:Module._compile internal/modules/cjs/loader.js:1039;[/tmp/perf-91190.map];[/tmp/perf-91190.map];[/tmp/perf-91190.map];[/tmp/perf-91190.map];[/tmp/perf-91190.map];[/tmp/perf-91190.map];[/tmp/perf-91190.map];[/tmp/perf-91190.map];[/tmp/perf-91190.map];[/tmp/perf-91190.map];[/tmp/perf-91190.map];[/tmp/perf-91190.map];[/tmp/perf-91190.map];[/tmp/perf-91190.map];[/tmp/perf-91190.map];[/tmp/perf-91190.map];[/tmp/perf-91190.map];[/tmp/perf-91190.map];[/tmp/perf-91190.map];[/tmp/perf-91190.map];[/tmp/perf-91190.map];[/tmp/perf-91190.map];asm_sysvec_hyperv_stimer0_[k];sysvec_hyperv_stimer0_[k];irq_exit_rcu_[k];do_softirq_own_stack_[k];asm_call_sysvec_on_stack_[k];__softirqentry_text_start_[k]

but our fibonacci functions remains an unknown entry.
Possibly a difference in versions between the Node installed on the host vs the one we run in container...

Possibly a difference in versions between the Node installed on the host vs the one we run in container...

Pfft, seems like this was the problem. I'm not even sure which version did it have installed. I'll test other LTS versions (12.x, 14.x) and post here; possibly will also add them as tests

Possibly a difference in versions between the Node installed on the host vs the one we run in container...

Pfft, seems like this was the problem. I'm not even sure which version did it have installed. I'll test other LTS versions (12.x, 14.x) and post here; possibly will also add them as tests

Ran the tests Dockerfile with node:12 and node:14. They both exhibit the same results as https://github.com/Granulate/gprofiler/pull/126#issuecomment-882128624. I don't understand Node's "jitdump policy" (why does my fibonacci has no symbol in that case ....?) but that's out of scope for the PR, I guess.
@michelhe can review


Refactor ParseNode to be plain objects

Original brainstorm in https://github.com/Khan/KaTeX/issues/892.
This will just change class ParseNode<TYPE> to type ParseNode<TYPE> = ... which would be a union of all possible ParseNode types. To avoid needing to do this all at once, will require some type indirection so that we don't refer to the Class version of ParseNode all over the place. If that doesn't end up working out, we might have to do an all-at-once style change.

Yea...I think it might have to be done all at once to avoid getting into "this type is not compatible with that type" style errors which provide not additional insight and dramatically progress.

I wonder if we should introduce an AtomNode to encapsulate bin, close, op etc. but inside of something that looks like:
{|
   type: "atom",
   family: "bin" | "close" | "op" | ...,
   nucleus?: ParseNode,
   subscript?: ParseNode,
   superscript?: ParseNode,
|}

This makes our ParseNode type more regular and should make flattening ParseNode,  getting rid of value, easier (I assume this is what was meant by "plain objects").

Oh yes, thanks for the reminder. That should be done first.

And indeed, I mean plan objects.

Sorry, should've read the original post more carefully.  Changing class ParseNode<TYPE> to type ParseNode<TYPE> = ... seems pretty safe.

@kevinbarabash It's worth noting that the "atom" refactor requires merging the various src/functiosn/symbols*.js into one.

Actually, I can keep them in separate files and import them all into a new symbol.js that dispatches to these handlers.

@kevinbarabash Before I go further (I've already gone pretty far, actually), do you think there should be separate "atom" types for "mathord", "textord", "op", and "spacing"?
Also, we don't have any HTML/MathML builder handlers for "accent-token" and "op-token". I'm not 100% certain (haven't done a deep audit) how precisely those are handled and whether we should do anything about separating them. Any insights would be appreciated.

I'm cool with either approach.  I don't think there should be any issues with mathord, textord, or spacing.  It seems like op (or should I say op-token) might be a little cumbersome.  Maybe leave that one out of the initial change.

🎉 Amazing stuff! 🎉


Replaced deprecated log_retention spec with new one

Hi,
according to the concourse bosh release, the used specs are deprecated (https://github.com/concourse/concourse-bosh-release/blob/master/jobs/web/spec#L1383-L1392). Therefore I adjusted them to use the recommended specs.

Thanks!


enable readonly access to controller UI for users without table restrictions

This PR aligns the web UI authentication process with the reasonable expectation of read-only users to have access to the web UI.
The controller UI currently checks for full (aka "admin") access permissions before showing the web interface when basic auth is enabled. Users with blanket READ access (aka "no table restrictions") cannot currently use the web UI, even though they can still access read-only information by hitting the APIs directly.

Codecov Report

Merging #10329 (95b73d3) into master (69420af) will decrease coverage by 21.41%.
The diff coverage is 0.00%.

@@              Coverage Diff              @@
##             master   #10329       +/-   ##
=============================================
- Coverage     35.16%   13.75%   -21.41%
+ Complexity      245      221       -24
=============================================
  Files          2027     1973       -54
  Lines        109957   107493     -2464
  Branches      16713    16418      -295
=============================================
- Hits          38665    14785    -23880
- Misses        67955    91531    +23576
+ Partials       3337     1177     -2160

Flag
Coverage Δ

integration1
?

integration2
?

unittests2
13.75% <0.00%> (-0.01%)
:arrow_down:

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

 Learn more


ActionModeHelper.onLongClick() requires AppCompatActivity but we only have FragmentActivity

No, you must provide AppCompatActivity which extends FragmentActivity in order to perform startSupportActionMode().


Added most of actives in Phishtank, and it's start working.

https://www.phishtank.com/user_submissions.php?username=seki
Added about 250 and the first half is well accepted and marked as phishes.
Here's some suggestion -

Within my pilot, I saw Google safe browsing flagged some of the site. It worth than seemed to be.
risk.iq and xforce have linkage to it.
Phishtank accepts only URL as input and no additional info like Etherscan of shown Ethereum address that may prove the fake behavior of the site.  Link to Phishtank from ESDB may help.
Don't know what incentives drive the Mturk like operation.

Hi Seki,
Awesome - do you know if there's an API where we can automate this? I'll look into it tonight! 👍

Yes, please look at history of my id.  I tried to stimulate the service and connections, and it might be succeeded around 100th.

Looked around 322 submissions so far, and 184 are verified as phish.
https://www.phishtank.com/user.php?username=seki
For the domain URLs listed in ESDB, Either one of red in safe browsing, Virus Total flagging or domain parking would be desirable state results and active domains have priority.
Those are 18 submitted ids May 27th and still active, but not verified, out of 54 total and 20 verified in the day.  If you have id, please verify them.
Need some cross reference on ESDB
Most of them are the QR code giveaway scams, probably driven by this http://free-ethereum.us/
https://www.phishtank.com/phish_detail.php?phish_id=5677852
https://www.phishtank.com/phish_detail.php?phish_id=5677853
https://www.phishtank.com/phish_detail.php?phish_id=5677859
https://www.phishtank.com/phish_detail.php?phish_id=5677862
https://www.phishtank.com/phish_detail.php?phish_id=5677863
https://www.phishtank.com/phish_detail.php?phish_id=5677864
https://www.phishtank.com/phish_detail.php?phish_id=5677887
https://www.phishtank.com/phish_detail.php?phish_id=5677889
https://www.phishtank.com/phish_detail.php?phish_id=5677893
https://www.phishtank.com/phish_detail.php?phish_id=5677896
https://www.phishtank.com/phish_detail.php?phish_id=5677897
https://www.phishtank.com/phish_detail.php?phish_id=5677907
https://www.phishtank.com/phish_detail.php?phish_id=5677908
https://www.phishtank.com/phish_detail.php?phish_id=5677913
https://www.phishtank.com/phish_detail.php?phish_id=5677915
https://www.phishtank.com/phish_detail.php?phish_id=5677920
https://www.phishtank.com/phish_detail.php?phish_id=5677925
https://www.phishtank.com/phish_detail.php?phish_id=5677928

Two ids within above are not yet verified/ 16 verified /18 total
https://www.phishtank.com/phish_detail.php?phish_id=5677908
https://www.phishtank.com/phish_detail.php?phish_id=5677928

Thanks Seki
I'll try dedicate some time this week to do some integration with phishtank

Hello! My respects! Help me please, my site got to the list of phishing sites. Although I just have a website about blockchain and ICO. Still Wake references to Airdrop which I already deleted. Please help us to find out what is wrong with the site. I checked all the antivirus software and they show that the site is clean. My site is my only earnings, please help.

@coinzzzpro
please go to https://github.com/MetaMask/eth-phishing-detect/pull/1886
as suggested in https://medium.com/@danfinlay/you-were-reported-as-hosting-a-fake-aragon-giveaway-here-a0694a108206

@sekisanchi Thanks mr. Kazunori Seki for the information! I have already deleted everything and will check every link published on my website. What should I do now? How to disappear from the list of these sites? Most of which are real phishing sites aiming to steal money. We are to blame, published a drop that was scam. But we are an information site, and there is no one do not want to be like. Please help! Thanks.

@sekisanchi please look this comment https://github.com/MetaMask/eth-phishing-detect/issues/1921#issuecomment-400276144

@sekisanchi Hello! Our site https://coinzzz.pro/ is excluded from the list of eth-phishing-detect
https://github.com/MetaMask/eth-phishing-detect/commit/5802be01c06dddff18d8077dd6f3cecf80dde9f5
Please, remove it from database https://www.phishtank.com/phish_detail.php?phish_id=5719803

@coinzzzpro  Looks like the site is clean at phishtank now, but anyway I flagged it as false positive.
These scans also say no bad in phishtank.
https://phishcheck.me/86089/details
https://phishcheck.me/86092/details


Name for git repos

Hi,
I am using a multi-root workspace which has some repo folders with the same name, e.g. "test-project".
The built-in git plugin shows the repos by folder names, and in this case it makes it harder to understand which repo is which.
It could be nice (whether there is no current way -- I did not found one...) to set a specific name for each repo,
in order to easily distinguish the two folders with the same name.
For example, by using the name associated into the workspace configuration file (but also any other setting is fine too).
Regards.

#40548


Could this be used as a satellite instead of a Raspberry Pi Zero w v2

Could this be used as a satellite instead of a Raspberry Pi Zero w v2

Could this be used as a satellite instead of a Raspberry Pi Zero w v2

Sorry, I don't understand what you mean by satellite.

Oh right lol. I mean could this be used to run Picovoice wake word and then send instructions to voice AI.

Yes, that's a possibility, since there's TensorFlow Lite support for RP2040 now.

Yoy wrote you are producing them. Where can thet be ordered and for hpw much euros/dollars?

You wrote that you are producing them right now. Where can they be ordered and for how much euros/dollars?

I am preparing for crowdfunding production of Mico. Please follow me on twitter for updates: https://twitter.com/mkvenkit

I am also interested .
messaged you on tweeter for some other things related to the project.


⚠ SceneTime has degraded performance

In e46a0c2, SceneTime ($ST) experienced degraded performance:

HTTP code: 200
Response time: 1472 ms

Resolved: SceneTime performance has improved in cfde8f0 after 6 minutes.


I fixed a bug in the ! cut

I fixed two bugs in the ! cut. Besides this, I added a few predicates, such as cputime(X), which can be useful for benchmarks.
A third bug remains to be fixed. I still canot use a cut as the last element of a clause body. When the cut appears in the last position of the body, E or B become large negative numbers. I added predicates that check whether E or B are negative to prevent the execution of the cut in this case. However, this is a temporary solution:
;;; Temporary solution: turn the cut off, when *B* or *E* are negative
   (cut (let ( (y (cadr inst)) )
			  (when (and *B* *E* (>= *B* 0) (>= *E* 0)
				     (addr< (stack (addr+ *E* 2 y)) *B*))
			    (setf *B* (stack (addr+ *E* 2 y)))
			    (tidy-trail))
			  (setq *P* (cdr *P*))))

Thank you for fixing some bugs and improvements!


Adding support for testing if a local file has changed #2

Adding support to the solid edit command: updating a remote file that has not been changed will result in a warning:

Update without changes? [y/N]

Love it, thanks alot :D


[Snyk] Upgrade @contentstack/cli-utilities from 1.5.1 to 1.5.8

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to upgrade @contentstack/cli-utilities from 1.5.1 to 1.5.8.
As this is a private repository, Snyk-bot does not have access. Therefore, this PR has been created automatically, but appears to have been created by a real user.
:sparkles: Snyk has automatically assigned this pull request, set who gets assigned.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 7 versions ahead of your current version.
The recommended version was released 22 days ago, on 2023-12-04.

The recommended version fixes:

Severity
Issue
PriorityScore (*)
Exploit Maturity

Cross-site Request Forgery (CSRF) SNYK-JS-AXIOS-6032459
462/1000  Why? Proof of Concept exploit, CVSS 7.1
Proof of Concept

Cross-site Request Forgery (CSRF) SNYK-JS-AXIOS-6032459
462/1000  Why? Proof of Concept exploit, CVSS 7.1
Proof of Concept

(*) Note that the real score may have changed since the PR was raised.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:
🧐 View latest project report
👩💻 Set who automatically gets assigned
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

version already bumped to 1.5.8


Set page slugs

Docs are helpful here.
Use page slugs so that there aren't any weird cases with page titles and their paths.

Closing, just change the post's file name to get a better slug.


Calling super without args fails with keyword args

The following code:
class Foo
  def foo(*, a)
  end
end

class Bar < Foo
  def foo(*, a)
    super
  end
end

Bar.new.foo(a: 1)

Fails with: Error: read before assignment to local variable ''

Manually forwarding it raises a different error:
class Foo
  def foo(*, a)
  end
end

class Bar < Foo
  def foo(a)
    super a: a # Error: no overload matches 'Foo#foo' with types Int32, a: Int32
  end
end

Bar.new.foo(1)

Also, even without double splats, named arguments to super can trigger another error:
class Foo
  def foo(a)
  end
end

class Bar < Foo
  def foo(a)
    super a: a # Error: argument 'a' already specified
  end
end

Bar.new.foo(1)

Closely related is that double splats aren't implicitly forwarded:
class Foo
  def foo(**opts)
    opts
  end
end

class Bar < Foo
  def foo(**opts)
    super        # => {}
    super **opts # => {a: 1}
  end
end

Bar.new.foo(a: 1)


Getting all of my boards

I created a object of class TrelloObject t. I called get_boards_json with base_uri as empty '' but I'm getting resource unavailable. How do I get names of all of my boards with their id? I also tried calling the generated api url using postman res client but get resource unavailable. Can you please tell what's the correct method for this purpose.

I got it had to call member api not boards


Add startSlides prop to FadingSlides component to prevent memory leak

@chagasaway - I figured out the issue that was causing the bug. I added a startSlides prop to FadingSlides to be able to stop the animation. Starting the animation on componentDidMount was triggering the memory leak error because the component would start calling this.setState({}) even thought it wasn't ready and mounted. Once FadingSlides would get unmounted then Fading slides would continue call this.setState({}). This might be an edge case particular to my project but adding a way to stop the animation would take care of this problem. Please review the pull request to see the changes I'm suggesting. I'm sure they will need improvement and more testing.

Hey @jqn, thanks for the PR, now I figured out what was the issue.
Now, looking into your PR, I was thinking here... what about changing the startSlides property to something like startAnimation or animate?

@chagasaway both sound great, but I think startAnimation sounds a lot better. I've updated the pull request to reflect that.

Merged 👍

Hey @jqn, I had to change the defaultValue of startAnimation to maintain the compatibility of the component since the previous versions the component it was rendering with the loop animation started.
I just launched an 0.3.1 version on npm with this upgrade, and again, thanks for contributing.


Window.fetch(); does not appear to be polyfilled in Safari 8

We've experienced a few issues while using fetch(); through the Polyfill service, in that it does not appear to be defined in Safari 8, both on mobile and on desktop.  In every other browser this appears to work fine, but whenever attempting to use fetch(); in Safari 8 we run into javascript errors.
> window.fetch();
< TypeError: undefined is not a function (evaluating 'window.fetch()')

We chatted on Slack - turns out the polyfill was not included in your features list.


Handling topojson point layer loaded via omnivore

[ ] I'm reporting a bug, not asking for help
[ ] I'm sure this is a Leaflet.MarkerCluster code issue, not an issue with my own code nor with the framework I'm using (Cordova, Ionic, Angular, React…)
[x] I've searched through the issues to make sure it's not yet reported

How to reproduce

Leaflet version I'm using:1.3.0
Leaflet.MarkerCluster version I'm using:1.4.1
Browser (with version) I'm using: Chrome 69)
OS/Platform (with version) I'm using: Window 7 and WordPress 4.8
step 1: Enqued scripts and css files to be loaded on page load
step 2: Created a layer for Topojson Point file using Omnivore
step 3: Added the layer to Cluster group and added to map

var mySitesLayer = L.geoJson(null, {

    pointToLayer: function (feature, latlng) {
        return L.circleMarker(latlng, SitesMarkerOptions);
    },
});
var siteUrl = '/wp-content/uploads/Maps/Data/sites.topo.json';
var sur_layer = omnivore.topojson(siteUrl, null, mySitesLayer);

var markers = L.markerClusterGroup();
markers.addLayer(sur_layer);
mymap.addLayer(markers);

What behaviour I'm expecting and which behaviour I'm seeing
The point are loaded and clustered
The clustered layer is not loaded. I can load the layer using the Leaflet addlayer and it shows up but cannot be clustered.
The clustering works with FeatureCollection type but not with Topology Type.
Any help will be appreciated.

Hi,
leaflet-omnivore plugin loads your data asynchronously.
See https://stackoverflow.com/questions/35897147/clustering-markers-from-csv-with-leaflet-and-omnivore/35898047#35898047

Hi @ghybs,
Thanks for the response. It now works beautifully. Cheers!


Upstream the changes from the PR #3580

Rebased #3580 with the main branch.

Notes:

There were few issues with the dynamic type checking for error, I am getting the following error -
errs, ok := unwrappedErr.(errutil.MultiError)
unwrappedErr (variable of type error) cannot have dynamic type errutil.MultiError (missing method Error)

Fixed it by creating another method for multierror - Error(). Let me know if the above makes sense.
Would love some reviews on this.
cc @brancz

I have updated the changes, take a look whenever free 🤗 @yeya24

I wonder if this suggestion is helpful in make lint -
/home/yash/golib/src/github.com/thanos-io/thanos/pkg/route/handler_test.go:234:31: declaration "NewCounterVec" from package "github.com/prometheus/client_golang/prometheus" shouldn't be used, suggested: "github.com/prometheus/client_golang/prometheus/promauto.{NewCounter,NewCounterVec,NewCounterVec,NewGauge,NewGaugeVec,NewGaugeFunc,NewHistorgram,NewHistogramVec,NewSummary,NewSummaryVec}"
/home/yash/golib/src/github.com/thanos-io/thanos/pkg/route/handler_test.go:240:28: declaration "NewCounterVec" from package "github.com/prometheus/client_golang/prometheus" shouldn't be used, suggested: "github.com/prometheus/client_golang/prometheus/promauto.{NewCounter,NewCounterVec,NewCounterVec,NewGauge,NewGaugeVec,NewGaugeFunc,NewHistorgram,NewHistogramVec,NewSummary,NewSummaryVec}"
/home/yash/golib/src/github.com/thanos-io/thanos/pkg/route/handler_test.go:246:33: declaration "NewGauge" from package "github.com/prometheus/client_golang/prometheus" shouldn't be used, suggested: "github.com/prometheus/client_golang/prometheus/promauto.{NewCounter,NewCounterVec,NewCounterVec,NewGauge,NewGaugeVec,NewGaugeFunc,NewHistorgram,NewHistogramVec,NewSummary,NewSummaryVec}"

because a similar issue was reported here after applying the suggestion - https://github.com/prometheus/client_golang/issues/716

Any idea to get the tests fixed? 🤔 cc @brancz @kakkoyun

I don't have time for this right now, but what I'm a bit confused about is that

There seem to be commits missing compared to the other PR
The e2e tests were passing on the last state of the other PR

I will do some investigation today.

Can you please fix the Circle CI test and linting tests?

Fixed the failing tests as we were using MultiError type assertion instead of NonNilMultiError assertion. Now the tests are passing.
cc @kakkoyun @squat can you review if the current changes make sense in accordance to the main branch?

TODO:

[ ] Traverse PRs and add anything missing to this PR. - Need to be taken care in this PR
[ ] Make sure documentation for the new command exists. - Enable autogeneration of documentation for receive-router
[ ] Make sure dashboards and alerts work with the new command. - We can create an issue to track the shortcomings related to dashboards and alerts

As promised, the modification of the proposal is ready: https://github.com/thanos-io/thanos/pull/4036 🤗  PTAL!

Deprecated by https://github.com/thanos-io/thanos/pull/4231


⚠ Minecraft has degraded performance

In 7f059a7, Minecraft (https://www.minecraft.net) experienced degraded performance:

HTTP code: 200
Response time: 1422 ms

Resolved: Minecraft performance has improved in 521af60.


Provide migration guide from Translatable to Fluent 4.0

Related: https://github.com/tractorcow/silverstripe-fluent/issues/278
As an important part of the migration process for CWP 1.x users to using CWP 2.x, they'll be switching from using Translatable to Fluent. We need to ensure that we have a comprehensive documentation guide for users that outlines the architectural differences between the two modules, as well as the changes for common public API methods (like getting the current language/locale, and the list of what's available).
We should also ensure that the BuildTask to assist with migrating from Translatable to Fluent (in this module) is working as expected (issue: https://github.com/tractorcow/silverstripe-fluent/issues/278). We can assume at this point that Translatable will be SilverStripe 3 only, and Fluent would be SilverStripe 4, that the Translatable code is most likely gone but the data in the DB is still available (?).

Finished with #339


Arity length explicitly defined

PR for the issue #2459
I tried to revert 07ecdac, but it was also removed by dead-code elimination.
So the best solution I found is to use Object.defineProperty as @CrossEye suggested. And It works fine. (I kept property attributes same as the specs.)
I discovered that the mocha will not run tests in subdirectories, so the internal tests were not loaded. I've added --recursive flag to the runner. Then there was an old test test.examplesRunner.js with outdated functions, so I just skip it.
closes #2459

Build failed on node.js 0.12. This version of node has no support for configuring the property length.
http://node.green/#ES2015-misc-miscellaneous-function--length--is-configurable

First of all, if this is the only technique that will work, we should probably mark this for a post-v1.0 release, as until then, we expect to be able to run in older environments. Is there an annotation to allow us to skip dead-code elimination in a block or a file?

Unfortunately I didn't find any annotation or the way how to skip the file. I will try to find some more compatible solution.

I thought we'd gotten rid of these. But if not, we probably should. Ramda has taken the stand that only the public API should have unit tests. Internal is just that, internal. We offer no contracts on it and can replace or eliminate any part of that whenever we choose.

Ok, no problem I dropped the commits

To revist after v1.0


ENH: Implement RotationSpline

I decided to finish up #9024
I used a self-written reference for the implementation
attitude_interpolation.pdf Which is more clear than what can be found in the original reference.
@adbugger --- would be very cool if you could review/participate in this PR.

I used a self-written reference for the implementation
attitude_interpolation.pdf Which is more clear than what can be found in the original reference.

Nice. I was going to suggest to put that somewhere public/permanent, but then I saw that the link is to somewhere within this repo (https://github.com/scipy/scipy/files/2873382/attitude_interpolation.pdf). How did you get that file there?

@rgommers
Well, I just dragged-and-drooped the file while editing the text 😃I agree that it's helpful to make these notes publicly available, I'm going to clean them up a little bit.

@rgommers, could you suggest how we can proceed with this PR? I'm happy with the code overall.

I decided to finish up #9024

You rewrote from scratch right, rather than continuing that PR? (asking because of author attribution)

@rgommers, could you suggest how we can proceed with this PR? I'm happy with the code overall.

It looks pretty good at first sight. I was hoping @adbugger was still interested to review/participate. Aditya, please let us know - also if you're not interested or simply have no time at the moment, would be good to hear from you.
Otherwise I'll try and make time to review soon. Marking it for the next release for now.

You rewrote from scratch right, rather than continuing that PR? (asking because of author attribution)

I have mostly rewritten it, but used some structure from @adbugger version.
I'm going to update the file above (very minor cleanup) and reference it in the docstring.

Apologies for the delay, I'm working on a few other research projects at the moment so saw the notifications now.
Looks good to me upon review. Only the structure of the RotationSpline class is loosely based on my original code. The rest is expanded and re-written in a much clearer way, and using scipy.linalg.solve_banded to do some of the heavy lifting is great. I should've looked into other helpful scipy functions sooner.
Thanks @nmayorov for finishing this. Once again, I apologize for the delayed replies.

@adbugger no worries, good to hear from you. come look us up when you have time!

I'll bump the milestone. I really should review this in more detail myself beyond the coverage comments above since it is in spatial, but for a 600 line diff we may also not want to rush it before Thursday.

@tylerjereddy
I improved the coverage to 100%.

I'll bump the milestone. I really should review this in more detail myself beyond the coverage comments above since it is in spatial, but for a 600 line diff we may also not want to rush it before Thursday.

It's a bit unfortunate, but OK, if you think it is necessary this way.

It's still Thursday. I'm comfortable merging this as is for 1.3.0, it's in good shape and @adbugger who worked on this before has also reviewed.

@tylerjereddy if you're not in the middle of branching yet, can you comment or press the green button?

alright done; I'm polishing release notes & mailmap at the moment

Thanks @nmayorov & reviewers


use tmp_path for test_override_newline

Follow up to https://github.com/jazzband/pip-tools/pull/1652
Contributor checklist

[x] Provided the tests for the changes.
[x] Assure PR title is short, clear, and good to be included in the user-oriented changelog

Maintainer checklist

[x] Assure one of these labels is present: backwards incompatible, feature, enhancement, deprecation, bug, dependency, docs or skip-changelog as they determine changelog listing.
[x] Assign the PR to an existing or new milestone for the target version (following Semantic Versioning).

weird CI failure: https://github.com/jazzband/pip-tools/issues/1697


i cant download it

when i press the download link it says "Not Found"
pls fix i need it!

@1sonic20 Fixed.


[Bug] auto_focus => true in a field located in a "closed" tab, does not work

Bug report
What I did
Tried to auto-focus a field that is not in the primary tab
What I expected to happen
Change tabs and focus the field I want
What happened
Nada.
What I've already tried to fix it
Nada.
Is it a bug in the latest version of Backpack?
After I run composer update backpack/crud the bug... is it still there?
Yes
Backpack, Laravel, PHP, DB version
When I run php artisan backpack:version the output is:
on the edge!

closing in favor of #5561


Raw type usage

IItem currently has this method:
void bindView(VH holder, List payloads);

The second parameter is a raw type, because no generic type parameter is given. This is bad practice, and will also result in warnings when compiling with -Xlint:all flag. The method signature should be this, like [the method](https://developer.android.com/reference/android/support/v7/widget/RecyclerView.Adapter.html#onBindViewHolder(VH, int, java.util.List<java.lang.Object>)) in RecyclerView.Adapter:
void bindView(VH holder, List<Object> payloads);

will be fixed in the next method

Thanks! However there are still lots if places where you should fix this. Most importantly, IItem and its subtypes (i was actually referring to those in the OP).

Fid you try v2?

@Rainer-Lang i did, but i do not understand why are you asking this here?

In v2 there are really a lot of changes. I don't know exactly which ones.

Yes, i know, and my comment is valid.

@WonderCsabo OK. Then let's wait for Mike. :)

@WonderCsabo I will have to take a closer look at all of them. but yeah you may be right.
I also prepare for the release of 2.1 which will introduce a even smaller core dependency.
You may also open a PR to change this?

Yep, I can implement this.

However i can only start on Wednesday, i do not know when do you want to release 2.1.


make fail on cygwin64

make fail on cygwin64 when I have changed the file 'opencl/openclwrapper.h'  on line 67 : #define PERF_COUNT_VERBOSE 3,
Then I change the file 'opencl/openclwrapper.h' on line 13: defined( CYGWIN ),  more problems come.

Do not change source code unless you are willing to fix consequences by yourself.
Make sure that cygwin64 is supported by your opencl provider.
Opencl is experimental feature. It was tested on linux and partially on VS2010. Other compilers are not supported - but you can try tesseract user forum for support.

Thanks.  But  in cygwin, The define of CYGWIN32 is no longer used, replaced by CYGWIN

Thank. Changed

Excuse me, I had met a problem when I used the cmake
pkg_check_modules(Leptonica REQUIRED lept)       this package didn't found, How can I solved it?
By the way, I have installed the lib leptonica already, and  I finished making the tesseract by ' configure && make '.
Thanks.

follow instrustruction for cmake ;-)

Thanks, I have solved this problem.


mpvi-open ---> error in process filter: ... (Windows)

When I run mpvi-open I've got:
Waiting c:/Users/path/file.mp4...
error in process filter: condition-case: ERR: (json-readtable-error 69)
error in process filter: ERR: (json-readtable-error 69)
error in process filter: condition-case: ERR: (json-readtable-error 43)
error in process filter: ERR: (json-readtable-error 43)
error in process filter: condition-case: ERR: (json-readtable-error 69)
error in process filter: ERR: (json-readtable-error 69)
error in process filter: condition-case: ERR: (json-end-of-file)
error in process filter: ERR: (json-end-of-file)

Do all video playback have this error?

Yes, it appears for all videos. Also, EMMS, which previously worked with mplayer, stopped working for me.
But I have to add the following. I love the legendary Windows 7 and so I didn't use this "winget install mpv yt-dlp ffmpeg Tesseract-OCR". I already had EMMS installed. Also I've installed mpv using MSYS2 (https://github.com/mpv-player/mpv/blob/master/DOCS/compile-windows.md).
The same error messages appear when starting EMMS.
After that, I tried mpvi on two other Windows 10 and Debian 11 machines. Everything works great! However, on Windows 10 I used this procedure: "winget install mpv yt-dlp ffmpeg Tesseract-OCR".
Here https://github.com/lorniu/mpvi/blob/master/mpvi.el I see links to PowerShell. But how does it (emacs + PowerShell) work? On Windows 7 I have PowerShell 7.1.0, and on Windows 10 PowerShell 7.3.4. Can it influence?
Thanks a lot!

It could be influenced by MPV's compile options, or powershell version, I'm not sure. I don't have Windows 7 at hand to debug it.
Powershell is used to connect to MPV daemon by named pipe, the code is simple:
https://github.com/lorniu/mpvi/blob/master/mpvi.el#L776
Can you try to debug it yourself? Or anyone else can provide a PR?

I can't upgrade to the latest powershell on Windows 7. But an interesting thing is that when I run mpv --input-ipc-server=\\.\pipe\mpvsocket --no-video video.mp4 in powershell I can control the player from another console (cmd) using commands like this echo seek -13 >\\.\pipe\mpvsocket. The same principle is used in mpvi. So verything should work?

Most likely the problem is with powershell version.

But I found the reason. Powershell needed a newer .NET Framework. After I installed the .NET Framework 4.8 Developer Pack everything worked!
Thanks a lot!

It's great to have this problem solved.
Maybe I should improve the display of error message, it's a bit too simple at the moment.


Enhance/add description

Why are these changes needed?

Enhance backend to return the description and examples.
Related issue number
Backend part of #75

Checks

[x] I've included any doc changes needed for https://github.com/pingcap/LinguFlow/.
[ ] I've added tests (if relevant) corresponding to the changes introduced in this PR.
[ ] I've made sure all auto checks have passed.

@lucklove @shhdgit PTAL
@lilyjazz You can add the fields like here.


feat: release 0.15

@opichals added replacement for http to https

@opichals I get security warnings that I made fixes into this PR too.


Gitea  action not working whenever gitea instance running under subpath

Description
My repo located at https://giteainstance.com/git/user/repo. Checkout action for gitea action failed with error
fatal: repository 'https:///giteainstance.com/user/repo/' not found
Gitea Version
1.21.0
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Screenshots
No response
Git Version
No response
Operating System
No response
How are you running Gitea?
Behind nginx under subpath
Database
None

reference https://github.com/actions/checkout/issues/1242
IMO it's not a bug of Gitea

That seems the case.  However just forking action/checkout doesn't seems to fix. Service prefix even being ignored in gitea action runner. Remote gitea action not being handled properly.
- name: Check out repository code with subpath
   uses: https://giteainstance.com/git/repo/checkout.git@v3

I'm not saying forking this repo on your Gitea instance. I mean you may find someone may fork this repo and modify it to support the suburl feature.

Yes thank you. Checkout action got working with 'uses: ischanx/checkout@06c611454073903c9d44641d7e085b21115d3dcf'
I will raise a separate issue for https://gitea.com/gitea/act_runner to support 'uses' command with subpath.

For any ones reference: This code is responsible for ignoring subpath in  action. (Search for newRemoteAction) https://gitea.com/gitea/act/src/branch/main/pkg/runner/step_action_remote.go

Agree. I am planning to remove subpath in gitea instance or  make it work via redirecting in nginx. There seems no other solution.


LAB_06-Implement_Network_Traffic_Management.md.pdf

English:
Subnet
Current Translation:
Subnet
Suggested Translation:
Sous-réseau
Description:
Serveral occurrences

Hello contributor,
Thank you for your contribution! We are processing your suggestions and we will update you shortly.
Kind regards,
Microsoft Worldwide Learning Team

Run bugfix tool and waiting for result.


Reduce stack usage of try_accounts

I have been investigating complaints about invalid stack accesses in the compiler toolchain that happen with Anchor contracts. Most problems occur with function try_accounts, whose constraints expansion eats up a lot of stack space.
https://github.com/coral-xyz/anchor/blob/5f1f72c511102ad49b0f4b9361efd714b6187e13/lang/syn/src/codegen/accounts/try_accounts.rs#L121
I also have found some items that you may be aware of:

The compiler has been missing stack errors. This is why sometimes you don't see a build error, but your contract fails during tests. This is going to be fixed in the next compiler release.
As for the problems access violations may cause, we are considering not emitting binaries for contracts that access invalid memory. This is going to be for future releases, because tools would need time to adapt.
There will be a refactor of the error message, making it clearer and easier to debug.

The try_accounts function is the only one that gets into the contract binary, so it advisable to break it in small methods (I had a look myself but found it very intricate).
Functions linearize and parse_account_field also have compiler errors, but they are not put into the contract binary. Perhaps, we are building them for Solana unnecessarily. We could also decrease their stack usage, but this case is simpler than try_accounts and should be less priority.
https://github.com/coral-xyz/anchor/blob/ca7fcee6b8269b732b66536f72ff3fb48cf1b5f9/lang/syn/src/codegen/accounts/constraints.rs#L71
https://github.com/coral-xyz/anchor/blob/ca7fcee6b8269b732b66536f72ff3fb48cf1b5f9/lang/syn/src/parser/accounts/mod.rs#L293

Thank you for creating this issue and giving a thorough explanation.

The compiler has been missing stack errors. This is way sometimes you don't see a build error, but your contract fails during tests. This is going to be fixed in the next compiler release.

Awesome! This has been very inconsistent in my experience.

2. As for the problems access violations may cause, we are considering not emitting binaries for contracts that access invalid memory. This is going to be for future releases, because tools would need time to adapt.

Are you able to tell whether that code path is going to be used? It currently shows the stack errors even if that code path is unreachable the compiled program.

The try_accounts function is the only one that gets into the contract binary, so it advisable to break it in small methods (I had a look myself but found it very intricate).

Yeah, the biggest offender is the init constraint as mentined in https://github.com/coral-xyz/anchor/issues/2920. I find splitting a function into multiple functions (or even using a closure like in https://github.com/coral-xyz/anchor/pull/2939) to reduce stack usage weird. Do you think it would eventually be possible for the compiler to do this optimization automatically?

Functions linearize and parse_account_field also have compiler errors, but they are not put into the contract binary. Perhaps, we are building them for Solana unnecessarily. We could also decrease their stack usage, but this case is simpler than try_accounts and should be less priority.
https://github.com/coral-xyz/anchor/blob/ca7fcee6b8269b732b66536f72ff3fb48cf1b5f9/lang/syn/src/codegen/accounts/constraints.rs#L71
https://github.com/coral-xyz/anchor/blob/ca7fcee6b8269b732b66536f72ff3fb48cf1b5f9/lang/syn/src/parser/accounts/mod.rs#L293

What's the point of reducing their stack usage if they are only being used in compile-time? As you pointed out, they don't exist in programs, and they are only being used inside macros.

Are you able to tell whether that code path is going to be used? It currently shows the stack errors even if that code path is unreachable the compiled program.

Rust should tell you that you have unreachable code. I am not sure if it works with macros, though. This is a good case to investigate. I'd be happy if you can provide a reproducible example.

Do you think it would eventually be possible for the compiler to do this optimization automatically?

We may look into promoting items to the heap, but this would overshadow the programming language. Rust already let developers choose where to allocate (e.g. by using Box).

What's the point of reducing their stack usage if they are only being used in compile-time?

If we end up blocking compilation of functions that access memory outside their frames, this case would show up because it is going through the Solana backend. Maybe we can just investigate why it is being compiler for Solana then.

What's the point of reducing their stack usage if they are only being used in compile-time? As you pointed out, they don't exist in programs, and they are only being used inside macros.

I just removed some functions from the Solana target and these extra errors go away. There are still other parts being built for Solana. Hopefully, the fix is very simple.
https://github.com/coral-xyz/anchor/pull/3062

Rust should tell you that you have unreachable code. I am not sure if it works with macros, though. This is a good case to investigate. I'd be happy if you can provide a reproducible example.

It's not general unreachable code, but rather unreachable code from one's program. For example, if you were to add anchor-syn to your dependency list, you'd get the stack errors even though that code never executes (like in https://github.com/coral-xyz/anchor/pull/3062).

We may look into promoting items to the heap, but this would overshadow the programming language. Rust already let developers choose where to allocate (e.g. by using Box).

Isn't the optimization here (or in https://github.com/coral-xyz/anchor/pull/2939) only for the stack? We're not really trying to improve stack usage by moving things to heap, just using a different stack frame instead. It seems to me that the compiler has enough information about the potential stack usage and can do optimizations in a more general way.


Clean up system tests

[ ] In AddressBookGuiTest, EventsCenter.clearSubscribers(); is called in setup() which is annotated as @Before. It's more intuitive to shift it to a method that is annotated @After, as clearing the subscribers seem like a tear down method rather than a set up method.

[ ] GuiRobot's access modifiers are wrong. (PAUSE_FOR_HUMAN_DELAY_MILLISECONDS, DEFAULT_WAIT_FOR_EVENT_TIMEOUT_MILLISECONDS, waitForEvent)

Closing this; merging with #559


Notify tile done loading when ion response can't be parsed

We forget to notify tile done loading when ion response can't be parsed, which makes the tileset unable to be destructed

Thanks @baothientran!


Feature Request: Collapsible chained methods.

Many times I use chained methods in javascript. For example:
var m = new Map()
    .set("apple", "red")
    .set("banana", "yellow")
    .set("grapes", "purple")

The problem is that bigger chians take up a lot of space on the screen, and it would be much move convenient if they were collapsible. With how the current collapsible things look, I imagine it would look like this when collapsed:
> var m = new Map()...
  )

This feature is powered by the TypeScript project. Please file a feature request upstream

I opened an issue upstream: https://github.com/microsoft/TypeScript/issues/39825.


File extension incorrectly parsed

I'm not sure if this is a problem of this library, Down or Shrine itself.
I have a url that has query params, something like this: https://google.com/image.jpg?test.w23fs The problem is that the extension is incorrectly parsed as .w23fs instead of .jpg. This makes my image processor (vips) to throw an error.

I think I ran into something like this once too, but am having trouble remenbering the details.
Can you provide more details to reproduce your problem, perhaps the smallest possible Uploader source code example that will reproduce the problem?  That would make it easier  folks to consider a possible fix or workaround suggestion.

I'll make the example with Rails.
In the intializer I have:
Shrine.storages = {
  cache: Shrine::Storage::Url.new,
  store: Shrine::Storage::FileSystem.new('public', prefix: 'uploads')
}

Then I can create a record with record = Model.create!(image_data: { id: 'https://myurl.com/image.jpg?test.w23fs', storage: 'cache' })
And the error happens when promoting: record.image_attacher.atomic_promote. After promoting, record.image_data is something like this:
id: '3f4b7c6a0b23e2498098f683af8234b2.w23fs',
storage: 'store'

Then I get this error Vips::Error: No known saver for '/tmp/image_processing20210714-16206-13qgy7t.w23fs'. I don't know in which part of the process the error occurs, but I'm pretty sure it's because of the filename. If I could change the filename to have the correct extension this wouldn't happen.

This seems to be a bug in Shrine. Shrine::UploadedFile#download uses UploadedFile#extension for the tempfile extension, which in this case wrongly returns w23fs instead of jpg. The #extension method does have some logic for handling URLs, but it doesn't handle URLs of this type, so it will need to be fixed.
As a workaround, probably this monkey patch would work:
class Shrine::UploadedFile
  def extension
    if storage.is_a?(Shrine::Storage::Url)
      path = URI.parse(id).path
      result = File.extname(path)[1..-1]
      result.downcase
    else
      super
    end
  end
end


ZooKeeper configuration changes

Changes  in this PR includes

Change export ZOO_LOG_DIR to use node attribute so that it is configurable. Currently it is hardcoded.
Add dataLogDir ZooKeeper config and ideally this need to point to a dedicated disk for performance.

LGTM


Updated release docs for alternate user identity support in execute resources

Description
Release docs for https://github.com/chef/chef/pull/5764
Check List

[ ] New functionality includes tests
[ ] All tests pass
[x] RELEASE_NOTES.md, has been updated if required (not required for bugfixes, required for API changes)
[x] All commits have been signed-off for the Developer Certificate of Origin. See https://github.com/chef/chef/blob/master/CONTRIBUTING.md#developer-certification-of-origin-dco

@NimishaS this needs a note added that for this feature the user that Chef runs as needs the 'SE_ASSIGNPRIMARYTOKEN_NAME' or 'SeAssignPrimaryTokenPrivilege' user right, which by default only LocalSystem and NetworkService has.

BTW: It may be worth mentioning how to do that in a recipie:
chef::ReservedNames::Win32::Security.add_account_right('vagrant', 'SeAssignPrimaryTokenPrivilege')

And here is how you would view the current right:
Chef::ReservedNames::Win32::Security.get_account_right('vagrant').include?('SeAssignPrimaryTokenPrivilege')

One of these days we'll create a account_right resource.

Replaced by https://github.com/chef/chef/pull/5796


add and remove selinux ports for proxy access

The test proxy uses non-standard ports which are not in the default
SELinux policy, so add them for the test, and remove them at the
end of the test.

[citest]

@richm Hmm policycoreutils-python-utils needs to be installed for using semanage - can you please add the task for it in tests_proxy?

Instead, I'll just use the selinux role


Logging driver leaks a key generated by ovpn_getclient when used through "logspout"; a warning

If you generate a key by running a command in a container, and if that container is set up to log data to some central logging system, then it can be possible to set up a situation where private keys leak out through the logs.
The command is ovpn_getclient, which puts data out to standard out:
% docker run -v ovpn-data-t2:/etc/openvpn --rm kylemanna/openvpn ovpn_getclient USER > USER.ovpn

The logging system I'm using is gliderlabs/logspout, which is configured to send stdout and stderr for running containers into a central syslog system. Since ovpn_getclient does its thing through stdout, that data is logged through the standard Docker logging driver.
The simple fix I can see is to run the command in some way with logging disabled for that run, e.g.
docker run -v ovpn-data-t2:/etc/openvpn --log-driver=none --rm kylemanna/openvpn ovpn_getclient USER > USER.ovpn

of course that's also substandard because you're really wanting to generate some kind of a log when the client file is generated, but I can confirm that this didn't exit unwanted data to syslog.
The word of warning is that ovpn_getclient might generate some logs somewhere, and it would be good to look carefully to make sure they don't go somewhere unwanted.

the source code includes a "combined-save" option that writes a file, but I don't readily see how to invoke it that way.

The stdout observation would be a good addition to the docs/paranoid.md.  The combined-save is documented under docs/clients.md.

Yup, I see a mention of combined-save at https://github.com/kylemanna/docker-openvpn/blob/master/docs/clients.md#client-configuration-mode - an example command line would be useful.
I'll send in a PR for the stdout observation.


Fix multiple extensions

Fix to allow Android to select multiple file extensions

@darklight365 thanks the fix was already done and released

@farfromrefug - Am I missing something?  The most recent release in npm is version 1.1.13 which still has the bug.

@darklight365 indeed something went wrong. let me fix that

@darklight365 should all be good to go now. THanks for your PR!