Cmake, no dependencies, windows support and more.

Hey,
I love this project and appreciate it deeply. I truly believe this project is a great way to build compiler frontends easily and extensively.
However I believe it is crucial for this project to be easy to integrate into existing projects and use in any OS - both langcc and the created parsers.
I've changed a few things:

Removed dependency on llvm and gperf, I appreciate the dump_stack feature but it doesn't do much on Release builds anyway as that should be the default for production usage, for development any debugger will break on exception which should be the best method for debugging, I believe the dependency on llvm and gperf will hurt adoption with little benefit. Also regarding tcmalloc I believe the performance is great even without it and most developers would rather not have it as a dependency,  of course - thanks to Cmake if one chooses they want to build with tcmalloc they can easily do with with 1 Cmake config line.
Supports any compiler - tested on gcc, clang, msvc, clang-cl but any other compiler should be supported as the code was changed to be pure c++
Switched build system to Cmake - makefiles can still be generated from Cmake but the build system mostly used by c++ developers is Cmake and it supports cross-compilation much better than makefiles. Also as you can see below, it allows for seamless integration with other projects.
Created CI targets for Ubuntu,MacOS,Windows current and last versions to check for support
Switch .sh scripts with .py scripts as it is the standard cross-platform scripting language
Switched testing system to gtest - it removes a lot of boilerplate code and allows for parallel testing easier and without cross platform problems, I also moved the tests to a different folder so it's easier see what is the actual source of the program.
Switched gnu attributes for c++ attributes to support any compiler
removed using namespace std - the using namespace std in langcc_util pollutes the namespace of any including application.
const reference - Added a ton of consts where relevant to improve const safety and a ton of references where relevant to reduce copying
Switched path args to std::filesystem::path - again to improve cross platform support seeing as how the project requires c++17 and filesystem support anyways
Many fixes regarding clang-tidy errors which should reduce bug prone behavior

Integration in other projects with Cmake:
include(FetchContent)

FetchContent_Declare(
  langcc
  GIT_REPOSITORY https://github.com/danlapid/langcc.git
  GIT_TAG        cmake
)
FetchContent_MakeAvailable(langcc)
add_custom_command(
    COMMAND $<TARGET_FILE:langcc> mylang.lang gen
    DEPENDS langcc mylang.lang
    OUTPUT gen/mylang__gen.cpp gen/mylang__gen.hpp
    COMMENT "Generating language code."
)
include_directories(
    PRIVATE   gen
    SYSTEM   ${langcc_SOURCE_DIR}/src
)
add_executable(MyCompiler main.cpp gen/mylang__gen.cpp)

No public api was broken and no changes were made to how to code actually operates.
From all of my tests performance is improved for any given compiler, largely thanks to enabling IPO and replacing copies with const references.
I realize this is a big diff and it may seem daunting, it started out as a personal project to improve the build system so I can use it and kinda grew from there. But I in my opinion this is a great change that will drive broader adoption.
A large part of the diff is formatting changes, I tried to find the most similar style to your current one to reduce the whitespace diff, if you could attach your .clang-format file I would gladly attach it to the repo and reformat all the files accordingly thus hopefully reducing the diff size.

Hi -- Thanks for your interest in the project, and for this work! Unfortunately, there are a few problems, some procedural and some having to do with content.
First, I can't accept a PR of this size, especially not one that includes generated code. It would need to be split up into individual contributions for individual features, with each being easily able to be rebased onto main (no merge commits), and with any codegen commits easily reproducible.
Second, before you engage in the effort of splitting up the PR, you should be aware that I have a somewhat unusual style of writing C++ (and of organizing the project), which unfortunately would lead me to reject many of the proposed changes. There are some changes I would consider accepting; when in doubt, I would encourage you to propose each change in isolation before implementing it in a PR, as that may save a lot of effort in the future. Specifically, for the changes described herein:

Removed dependency on llvm and gperf, I appreciate the dump_stack feature but it doesn't do much on Release builds anyway as that should be the default for production usage, for development any debugger will break on exception which should be the best method for debugging, I believe the dependency on llvm and gperf will hurt adoption with little benefit.

Part of my approach in this project is to write in "C++ as it should be", not "C++ as it is". There is no good reason for C++ not to provide stack traces, even for release builds. This massively improves the experience of debugging crashes, especially in the wild. So I do not support disabling this functionality entirely. However, I would note that langcc does not actually have a hard dependency on llvm. If you build it and llvm is not detected, then it will still produce stack traces, albeit ones without source line information.

Also regarding tcmalloc I believe the performance is great even without it and most developers would rather not have it as a dependency, of course - thanks to Cmake if one chooses they want to build with tcmalloc they can easily do with with 1 Cmake config line.

tcmalloc makes a significant difference in the benchmarks as I measure them (and as they are reported in the accompanying publications), and it is important that the default configuration of the project reflect these figures.

Supports any compiler - tested on gcc, clang, msvc, clang-cl but any other compiler should be supported as the code was changed to be pure c++

I would have to look at the specific code changes to judge whether to accept this type of PR. However, one thing to note is that Windows and MSVC are definitely out of scope. It is simply too much upkeep burden to maintain Windows support indefinitely for a project at this stage.

Switched build system to Cmake - makefiles can still be generated from Cmake but the build system mostly used by c++ developers is Cmake and it supports cross-compilation much better than makefiles. Also as you can see below, it allows for seamless integration with other projects.

CMake is also out of scope (and has been addressed in previous GitHub issues). People have different opinions on build systems, but every build system comes with its caveats, and for langcc's purposes, ordinary Makefile is working just fine.

Created CI targets for Ubuntu,MacOS,Windows current and last versions to check for support

As discussed above, Windows is out of scope. I wouldn't be opposed to adding "last version" CI targets for Ubuntu and macOS, provided that this doesn't significantly increase the (sequential) time to pass CI.

Switch .sh scripts with .py scripts as it is the standard cross-platform scripting language

I don't see any particular reason to do this. Shell scripts are working fine. (And, as discussed above, Windows is out of scope.)

Switched testing system to gtest - it removes a lot of boilerplate code and allows for parallel testing easier and without cross platform problems, I also moved the tests to a different folder so it's easier see what is the actual source of the program.

I would have to evaluate this change in isolation, but would generally be inclined to reject it. It introduces another dependency, and moreover, the testing framework I have implemented works in a specific way that I expect, it's working fine as-is, and I am not sure that gtest would satisfy all of the desired properties.

Switched gnu attributes for c++ attributes to support any compiler

This is probably reasonable, although possibly unnecessary given that Windows is out of scope.

removed using namespace std - the using namespace std in langcc_util pollutes the namespace of any including application.

The "using namespace std" is guarded by namespace langcc, so it doesn't pollute the global namespace, only the langcc namespace. However, if you're willing to replace it by dozens of lines of "using std::X", "using std::Y", etc., that might be reasonable. My personal philosophical view is that the full standard library is ubiquitous enough that it should be bound in the global namespace, but I realize this is a minority view.

const reference - Added a ton of consts where relevant to improve const safety and a ton of references where relevant to reduce copying

I am generally avoiding broad use of many modern C++ features, such as const-correctness (because it makes code more burdensome to write) and move semantics (because it is error-prone, in addition to being burdensome). However, if you can point to specific places where introducing references significantly improves benchmark performance, I'd be open to this.

Switched path args to std::filesystem::path - again to improve cross platform support seeing as how the project requires c++17 and filesystem support anyways

I'd have to review this change in isolation; it might be reasonable.

Many fixes regarding clang-tidy errors which should reduce bug prone behavior

Again, would have to review each change in isolation.
Hopefully these comments make sense. I really appreciate your interest in the work, and your efforts in suggesting these changes. Unfortunately, langcc is an early project with limited manpower, and I need to confine the accepted PRs to those that are really necessary, and are streamlined for adoption.
Joe

First I would like to note that I really appreciate your thorough review.
I understand we have differing opinions on many of the above notes and I accept that.
I help maintain other open source c++ code projects and above are a many things I have seen to be ubiquitous/standard among those.
Of course this is your work and project and your prerogative to decline sweeping changes to it.
It is however disappointing seeing as how I truly believe these changes will be able to drive this incredible tool to a more production/commercial use case.
Especially seeing as how the above is not suggestions but rather a completed working pull request.
If you believe at good majority of the above work might indeed be relevant I am not opposed to removing the changes to the generated code as requested leaving them to be regenerated by you and reformatting the code according to a clang format file so that the diff will be significantly smaller.
However for very specific parts of the above I don’t have much interest in splitting into many different RFCs and separate pull requests as I have already put much effort into this. Rather I would probably prefer to maintain my own fork with these changes as they are required for my relevant application of this work.
Thanks again for your time and consideration, I hope some of it will end up being useful to you.

Thanks for your consideration -- hope langcc will be useful to you.


add version compat checks to JS

Similar to how we check for the min & maj version globals in the SDK for compatibility in Rust and Go (if instrumented automatically via the compiler) we should implement it in JS.

JS SDK now has checks on observe API interface. We decided to remove checks based on wasm-instr version from rust and go though may later add advisory checks on wasm-instr version in the producers section of modules.


General Issue: Review vignettes and templates for deprecated functions

Background Information
Go through the templates and vignettes to ensure that all of the functions and/or parameters that were deprecated are following the deprecation process outlined in the programming strategy (screenshot below)

Definition of Done

[ ] Functions and/or parameters with deprecated_stop() from previous release are no longer in any vignettes or templates
[ ] Vignette sections with the deprecated function and/or parameters are updated with their respective replacements

Actions required for specific functions

[ ] Following functions need to throw an error for release Q1-2023 admiral version 0.10.0 because they were deprecated in version 0.8.0 with phase 1, but haven't gone through Phase 2 which is to throw an error OR the deprecation process started in admiral version 0.9.0
derive_vars_merged_dt()
derive_vars_merged_dtm()
derive_var_agegr_ema()
derive_var_agegr_fda()
derive_param_first_event()

[ ] Remove the following parameters
smq_select() and sdg_select() function
meddra_version, whodd_version, get_smq_fun and get_sdg_fun from the create_query_data() function

[ ] Following programs and their associated test in /test-deprecations.R need to be removed since they were deprecated with Phase 2 in admiral version 0.8.0 or early
R/derive_var_ady.R
R/derive_var_aendy.R
R/derive_var_astdy.R
R/derive_var_atirel.R

Many thanks @sadchla-codes for putting this together.  @pharmaverse/admiral are there any others missing from this list?

@bms63 I went through the changelog and search the vignettes/templates to generate the list above. I'm already deprecating some functions, I'll update the issue if i found other function/parameters that I missed.


【Error】does not look like a character body file from the game.

First of all, I'm not good at English.
Thank you for providing this wonderful tool.
However, I found a problem that I couldn't solve by myself, so I will share it.
If you try to use body data starting with "cb_sra", the tool will say "[cb_sraxxx] does not look like a character body file from the game".
"cb_sra" Is definitely body data, but I didn't see any difference from "cb_sr" or "cb_ss".
Is there a way to solve this problem?

The process proceeded by rewriting "cb_sra" to "cb_sr". The problem has been resolved.


admin-on-rest generator

Q
A

Bug fix?
no

New feature?
yes

BC breaks?
no

Deprecations?
no

Tests pass?
yes

License
MIT

It will double the work and the maintenance with api-platform/admin...

I needed it so created due to some custom endpoints that api-platform/admin couldn't serve

@mauchede please review this PR

there is another solution to get all imports at once would be
import  * as resources from "resource-import";
...
  <Admin
     ...
   >
     {Object.keys(resources).map( (key) => resources[key])}
  </Admin>

@mauchede WDYT ?

It seems good!


Don't send last calls during weekends

Fixes #15.

I think it would be better to set this in the cron jobs in src/server.js at the bottom


Undetected Chrome

Hello. I have a problem with Selenium. Please add undetectedchrome. Selenium is constantly detected.

Hi, thank you for your report, I have not worked on the sw anymore, due to lack of time, but I will try to do this in the next update. Thanks.

Hi, thank you for your report, I have not worked on the sw anymore, due to lack of time, but I will try to do this in the next update. Thanks.

Thank you for your feedback! :)


Utility for converting v14 to v13

In order to ease the transition for any clients in the ecosystem which depend on the existing v13 metadata format, provide a utility to convert between v14 and v13 metadata.

How should this work? If someone needs to update the crate, they already get v14? Why should they downgrade that to v13 then?

It's for any downstream consumers who depend on v13 metadata, at least to allow them to continue to work while they update to v14.
I'm not aware of the whole ecosystem of metadata consumers, I'm just wary that they have not spotted my PR and suddenly their stuff will break. It may not be needed to ease the transition, but at least it is available.
Also allows comparisons between runtimes with v13 and v14 metadata, just run the conversion and compare v13 against v13, which could be useful for diffing tooling that @chevdor is working on.

How should downstream projects use this? I would argue that most downstream projects are using js anyway :P
Maybe we should find out who are our downstream users.

How should downstream projects use this?

I'll provide a CLI tool which takes the encoded v14 bytes/json and returns the v13 bytes/json. If I make it no-std it could even be incorporated into api-sidecar, but I don't think we want to support that.

I would argue that most downstream projects are using js anyway :P

That is my impression too, and I really hope so. Let's call this an insurance policy. Happy to throw this away if it is not needed,
In the end I can run it as a one off verification for my PR by comparing master (v13) with metadata produced by my PR branch.

I'll provide a CLI tool which takes the encoded v14 bytes/json and returns the v13 bytes/json. If I make it no-std it could even be incorporated into api-sidecar, but I don't think we want to support that.

Ahh nice. Okay. I don't have seen this. Fine :P I shut up :D

Ecosystem has already transitioned to V14 and been on it for a while so this is probably not required now.


Very slow s3 connection after 0.16.1

Environment
Delta-rs version: 0.16.1
Binding: python

Bug
What happened:
I am using s3 compatible storage, and after trying to upgrade to 0.16.1, I noticed very slow calls to DeltaTable, with the following warning:
[2024-04-03T13:37:12Z WARN  aws_config::imds::region] failed to load region from IMDS err=failed to load IMDS session token: dispatch failure: timeout: error trying to connect: HTTP connect timeout occurred after 1s: HTTP connect timeout occurred after 1s: timed out (FailedToLoadToken(FailedToLoadToken { source: DispatchFailure(DispatchFailure { source: ConnectorError { kind: Timeout, source: hyper::Error(Connect, HttpTimeoutError { kind: "HTTP connect", duration: 1s }), connection: Unknown } }) }))
This warning gets logged 3 times before the call to DeltaTable finishes, and it takes ~3 seconds, whereas on delta-rs 0.16.0 it takes 0.1 seconds.
I assume it may be happening due to this PR: https://github.com/delta-io/delta-rs/pull/2243, it's the most relevant change I could find.
These are the storage options I'm passing in:
    storage_options={         "AWS_ALLOW_HTTP": "true",          "AWS_ENDPOINT_URL": AWS_ENDPOINT_URL,         "AWS_REGION": "custom",         "AWS_ACCESS_KEY_ID": AWS_ACCESS_KEY_ID,         "AWS_SECRET_ACCESS_KEY": AWS_SECRET_ACCESS_KEY     }

@mightyshazam or @rtyler should be able to provide more details on this one

I'll take a look.  Prior to that, we did not implement them all, so it would've never tried the metadata endpoint.

@echai58 can you run your code with the environment variable AWS_EC2_METADATA_DISABLED set to true.
@rtyler Assuming this is an IMDS issue, do you think we should treat this as a breaking change with the above remediation, or should we introduce a setting to turn it on and off for the s3 logstore?

@mightyshazam Yes, running with that env var set seems to work. It would be nice if we could pass that in as part of storage_options, that would make this a lot easier to deal with.

@mightyshazam Yes, running with that env var set seems to work. It would be nice if we could pass that in as part of storage_options, that would make this a lot easier to deal with.

Thanks for confirming. I'll put together an update.

@mightyshazam Yes, running with that env var set seems to work. It would be nice if we could pass that in as part of storage_options, that would make this a lot easier to deal with.

Thanks for confirming. I'll put together an update.

thank you!

Hi @mightyshazam, i left a comment (https://github.com/delta-io/delta-rs/pull/2385#issuecomment-2050096933) on the PR - seems like passing in the variable as a config is not working

Hi @mightyshazam, i left a comment (#2385 (comment)) on the PR - seems like passing in the variable as a config is not working

I just tried this with the latest main. I modified an additional integration test test_roundtrip_s3_direct. I updated the config as such
    with pytest.raises(IOError):
        anon_storage_options = {
            "AWS_ENDPOINT_URL": s3_localstack_creds["AWS_ENDPOINT_URL"],
            # Grants anonymous access. If we don't do this, will timeout trying
            # to reading from EC2 instance provider.
            "AWS_ACCESS_KEY_ID": "",
            "AWS_SECRET_ACCESS_KEY": "",
+            "AWS_EC2_METADATA_DISABLED": "true",
        }
        write_deltalake(
            table_path,
            sample_data,
            storage_options=anon_storage_options,
        )

Then I ran the integration tests with python -m pytest -m '(s3 and integration)' --durations=0
Running the test with the setting is an order of magnitude faster than without. Are you experiencing something different or setting it another way? If you're setting it as an environment variable, it should also work with the Rust AWS SDK

@mightyshazam I'm doing the following:
DeltaTable(
    f"s3a://{AWS_BUCKET_NAME}/{path}",
    storage_options={
        "AWS_ALLOW_HTTP": "true",
        "AWS_ENDPOINT_URL": AWS_ENDPOINT_URL,
        "AWS_ACCESS_KEY_ID": AWS_ACCESS_KEY_ID,
        "AWS_SECRET_ACCESS_KEY": AWS_SECRET_ACCESS_KEY,
        "AWS_EC2_METADATA_DISABLED": "true"
    },
)

It seems like it's only the first time it connects it runs, it takes ~3 seconds, even with the AWS_EC2_METADATA_DISABLED flag passed in via storage_options.
When I run it a subsequent time, I don't see the warning anymore and it takes ~0.05 seconds, which is expected (and the runtime of the first run when running with the env var set)

@echai58 I found a few more places in the AWS SDK where we need to override the behavior. I prefer that AWS allow us to pass through this setting, but it only works as an environment variable unless we setup everything manually.

@echai58 #2442 changes the default behavior for DynamoDb locking using the AWS SDK. The default value for AWS_EC2_METADATA_DISABLED is true, so you shouldn't have to set it anymore.

@mightyshazam thank you! will test it out later, appreciate the help

Hi @mightyshazam, are there any docs on how to enable this for use with IMDS? I've tried passing the 'AWS_EC2_METADATA_DISABLED':'false' argument into the python wrapper and continue to get a Generic S3 error: Error after 10 retries in 4.740948202s, max_retries:10, retry_timeout:180s, source:error sending request for url type error despite being able to access the target s3 url using aws cli

@herlma Do you have any other settings that you are passing? Given that you are getting that error, I suspect it is using IMDS since it should fail much faster. Do you have any other log messages?


Updates the deployment process and the version check associated with it

This commit supports steps 1 and 2 in the new workflow:

Change the logic in the daemon to check the github api for the latest release that is not a pre release
Change travis to mark all releases as pre release
When we are ready to stage a release we push a tag to master. Travis builds the packages and releases them
We manually check them
Remove the pre release mark when we are happy

untested LGTM

Rebased and tested locally:
2016-07-25 11:11:52,535 INFO     requests.packages.urllib3.connectionpool:758: Starting new HTTPS connection (1): api.github.com
2016-07-25 11:11:52,821 INFO     lbrynet.lbrynet_daemon.LBRYDaemon:592: remote lbrynet 0.3.10 > local lbrynet 0.3.10 = False
2016-07-25 11:11:53,531 INFO     lbrynet.lbrynet_daemon.LBRYDaemon:579: remote lbryum <IP_ADDRESS> > local lbryum <IP_ADDRESS> = True


Re-intoduce skipped test CallingSyncFromUpdatesStartHashAccordingly

Re-introduces the skipped test CallingSyncFromUpdatesStartHashAccordingly.

I think we should actually comment out all this test class until the BlockNotification is reused again.


Water Spout / Eruption errors out; adding better error handling

One of the updates as part of the #154 setup the calculations for Water Spout and Eruption to use variable power, instead of ">HP". This PR fixes that error.
NLua.Exceptions.LuaScriptException: ironmon_tracker/Utils.lua:320: attempt to perform arithmetic on a nil value
Also including some updates to the Main Tracker script for better error handling.

Ninjafriend discovered a bug with the new ability read information I added, included that fix in here as well.


bug: SERVER_PORT env not working when installing attu using helm

Describe the bug:
Deploying the attu 2.3.8 version to Kubernetes via helm does not apply the SERVER_PORT option; deploying via zilliz/attu:dev image, conversely, the SERVER_PORT option works well.
apiVersion: apps/v1
kind: Deployment
metadata:
  name: release-name-milvus-attu
  labels:
    helm.sh/chart: milvus-4.1.25
    app.kubernetes.io/name: milvus
    app.kubernetes.io/instance: release-name
    app.kubernetes.io/version: "2.3.12"
    app.kubernetes.io/managed-by: Helm
    component: "attu"

spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: milvus
      app.kubernetes.io/instance: release-name
      component: "attu"
  template:
    metadata:
      labels:
        app.kubernetes.io/name: milvus
        app.kubernetes.io/instance: release-name
        component: "attu"

    spec:
      containers:
      - name: attu
        image: zilliz/attu:v2.3.8
        imagePullPolicy: IfNotPresent
        ports:
        - name: attu
          containerPort: 7800
          protocol: TCP
        env:
        - name: MILVUS_URL
          value: http://release-name-milvus:19530
        - name: SERVER_PORT
          value: "7800"
        resources:
          {}

user@123 repository % k logs gpd-milvus-attu-665cfbcb54-8gxr2
yarn run v1.22.19
$ node dist/src/app.js
Attu server started: http://<IP_ADDRESS>:3000

Steps to reproduce:

deploy zilliz/attu:v2.3.8
set env SERVER_PORT=7800

Attu version:
2.3.8

@shanghaikid thanks for your works!
Can you please take a look at this bug? If there's anything I did wrong, please comment even briefly

@shanghaikid thanks for your works!
Can you please take a look at this bug? If there's anything I did wrong, please comment even briefly

I think the issue has been addressed in the https://github.com/zilliztech/attu/pull/434 . I might release new version soon.
Btw, You can try the dev version.

@shanghaikid Thank you so much for your quick response, and may I know the approximate schedule if it will be released?

@shanghaikid Thank you so much for your quick response, and may I know the approximate schedule if it will be released?

maybe the next week. I hope this week. :)

https://github.com/zilliztech/attu/releases/tag/v2.3.9
Hi, new attu has been released, you can try and tell if this is fixed, if it is not , I will take a look at this.

thank you, i checked the new release works well without the previous bug


Fix Mysql2Adapter superclass.

Is there any reason not to use class_eval? that would save having to know the exact superclass.

I can't think of why we couldn't use class_eval... that sounds like a nice approach.


[add] function identifier for C/C++ and Python

Adds the identifier.function subgroup for C/C++ and Python. I like to have different highlight color for function calls.

NACK. Not everyone wants functions to be highlighted at all, whereas with this PR they will be forcefully highlighted: even if there is no identifier.function in the colorscheme, they will be highlighted with the default identifier color.

Functions are special objects, for me not having a highlight is very strange.

add is an identifier in both scenarios, I don't see why highlght would have to be different.

Different highlighting here actually makes sense, if you think about it: there is a difference between a function declaration/definition and a function call.
Also, this PR will not help with your example: the 2nd add will still not be highlighted (as you may have noticed if you tried using this PR), since for some reason this PR highlights only functions starting with a capital letter (in Python and C++; in C it highlights all functions; I've no idea what's the logic behind that).
Skipping endless discussions about semantics and personal preferences, the fact is that this PR drastically changes the look-and-feel of all the built-in colorschemes: the identifier colors, which used to only scarcely occur in the code highlighting (macros in C/C++, function definitions and built-in functions in Python), are now almost everywhere.  (Although in C++ and Python it does not become as colorful as it does in C, since only capitalized functions are highlighted. But then again, it isn't clear what's the point of highlighting capitalized functions only.)
So, I would be fine with adding the ability to highlight function calls, as long as it is truly optional, i.e. one can highlight function calls in his/her custom colorscheme if he/she likes to, but the behavior of the built-in colorschemes remains intact. I.e.:

either rename identifier.function to something like function or function.call, so that it doesn't mess with identifier in the built-in colorschemes
or add identifier.function definition to all the built-in colorschemes, with the same colors as default, i.e. not highlighted by default

Last but not least, this is how C code looks like with this PR with the default (!) colorscheme:

Functions are highlighted with the same color as types. This alone is enough reason to avoid merging this PR in its present form. (Yeah, in this case the cause is that the default colorscheme uses the same colors for both type and identifier. But the user wouldn't care what is the cause.)

[A-Z] really doesn't make sense as this would only match function calls that start with capital letters.
So what we could do is leave it as is and the emphasis is only on those who reimplement the syntax locally for these files. Ok for me, that's what I do today.

All that being said, highlighting <> includes would be a nice improvement. Although I would try and do it in a smarter way, so that strings like <foo.h> are highlighted only after #include, not everywhere else. It should be possible with something like:
    - preproc:
        start: "#include"
        end: "$"
        rules:
            - identifier.include: "[\"<].*[\">]"


Vue project - ENTRYPOINT is undefined

Hello,
I'm trying to use api platform from a SF flex installation.
It's working great but I've an issue with the client side in Vue.
My issue is related to the API endpoint. I don't have the api suffix.
I see a import { ENTRYPOINT } from '../config/entrypoint'; in the src/utils/fetch.js but this is not working.
Do I miss something or the code is broken?

It's probably my fault, because of the latest changes I made in the lib.
Does the file ../config/entrypoint exists? If yes can you paste its content please?

It exists:
export const ENTRYPOINT = 'http://<IP_ADDRESS>:8000/api';
It seems okay, but when it's executed in the fetch.js (new URL(id, ENTRYPOINT).toString()) it has no value


#5946 broke ability to update istio if ExposureClasses are used

How to categorize this issue?

/area networking
/kind bug
What happened:
Updating istio does no longer work after https://github.com/gardener/gardener/pull/5946 if ExposureClasses are used. There is only one managed resource for the istio resources, but the istio-ingress resources should be deployed into several namespaces, one for each exposure class.
Looking into the managed resource, you can see that only one set of istio-ingress resources are included. Hence, the other exposure class namespaces are not updated properly.
What you expected to happen:
If istio is updated this should be reflected in all exposure class namespaces.
How to reproduce it (as minimally and precisely as possible):

Create an exposure class, e.g. by adding the following to your gardenlet config:

exposureClassHandlers:
  - name: internet-config
    loadBalancerService:
      annotations:
        loadbalancer/network: internet
  - name: internal-config
    loadBalancerService:
      annotations:
        loadbalancer/network: internal
    sni:
      ingress:
        namespace: ingress-internal
        labels:
          network: internal

Afterwards, simply update istio, e.g. by incrementing the minor version in charts/images.yaml.
Watch only one istio-ingress gateway being updated.

Anything else we need to know?:
Environment:

Gardener version:
Kubernetes version (use kubectl version):
Cloud provider or hardware configuration:
Others:

/cc @dkistner @acumino @rfranzke

@acumino can you please check and follow up?

/assign


HTML Editor - please add CTRL-K to Insert Hyperlink

Issue: When I use the HTML Editor I often want to insert URL hyperlinks.  However, currently I have to mouse to the icon which produces a dialog to "INSERT LINK" then I also have to use the mouse cursor to set focus into the web address text box.
Suggestion:  Enable a keystroke command like CTRL-K which opens the high-lighted text in the same INSERT LINK dialog box.  An added benefit is if we could put focus on the "web address" text field so you could hit CTRL-K then CTRL-V (to paste URL from clipboard) and then ENTER (or CTRL-S) to save the hyperlink.
Thanks for considering this!

Recently implemented


Provide better feedback when adding new tool definitions to Obot

Problem
It's hard to tell when and why registering a new tool -- both a custom tool via the Obot UI, and in the tool's index.yaml -- fails. We need a better feedback mechanism to let users and devs detect and identify the problem.

I'm going to be a little harsher and call this a bug.

@njhale -  this is a weird nuance but I'd like issues to have the admin-ui label if they are purely UI issues. If they require backend issues, they dont get this label. ...And I believe this is a backend thing.


Always all refresh_metadata on form submission

Right now, refresh_metadata is only called when remote_metadata_url is present. This means that expiration datetimes aren't parsed out of locally provided metadata. Additionally, error logging has been added if metadata has expired but there's no remote url, and if metadata can't be fetched from remote

@mhindery any changes I should make on this?

Hi @askvortsov1 , regarding your comment above Additionally, error logging has been added if metadata has expired but there's no remote url, and if metadata can't be fetched from remote This isn't in this PR's changes, should I wait for something? I was also thinking that it might be better to only display a warning to the user if it fails to fetch remote metadata instead of blocking a save entirely. That way you could make unrelated changes to the config, and as long as you do have a local copy of the metadata saved which is still valid, it should still work.

Closing in favor of new PR to Master


Progress Bar doesn't have classNames applied

This may be something with the way I'm importing things here but I'm basically following the documentation exactly
import ProgressBar from 'react-toolbox/lib/progress_bar'

return (
        <div>
          <ProgressBar type='circular' mode='indeterminate' multicolor />
        </div>
      )

When this renders, no classes are applied to the outer div or any sub-elements. For reference I'm using version 2.0.0-beta.7. I was struggling with my getting my webpack config to work with this library so here's the relevant portion of that. Any help is appreciated.
{
          test: /\.css$/,
          ['style-loader', 'css-loader',
            {
              loader: 'postcss-loader',
              options: {
                plugins: function () {
                  return [
                    require('precss'),
                    require('autoprefixer')
                  ]
                }
              }
            }
          ]
        }

Ok after finding the example setup (https://github.com/react-toolbox/react-toolbox-example/blob/master/webpack.config.js) I was able to get it working. I feel like the documentation doesn't quite specify all the steps you need to configure Webpack to work with this library.


CacheRequest onFailure should take a closure that throws

This way every cache can throw specific errors without using NSErrors and without the need for error transformers

Canceled, instead the closure fails passing a ErrorType.


Added support for laravel 5.8

added support for laravel 5.8
added tests for php versions 7.1, 7.2, 7.3

could we add the implemented changes from here: https://github.com/dimsav/laravel-translatable/pull/550

sounds good


[vcpkg] Mark ARM and x86 on ARM64 and x86 on ARM as supported architectures when searching for toolchains on Windows

When searching for visual studio toolchain files which can satisfy the host, target pair of {ARM, ARM64} X {x86, x64, arm, arm64} we should allow the x86_{x86, x64, arm, arm64} toolchain files to be selected because of the Windows x86 emulation on ARM.

/azp run

/azp run

/azp run

/azp run

LGTM


feat: add py.typed for mypy library stubs

With lancedb as a dependency, running mypy on a project complains with the following error:
error: Skipping analyzing "lancedb": module is installed, but missing library stubs or py.typed marker  [import-untyped]

@eduardjbotha  I would like to support this. However, we do not check LanceDB Python's annotations in CI yet, so I don't think many of them are event correct at the moment. Therefore, I'm reticent to turn this on until we start validating our codebase with mypy. I've filed https://github.com/lancedb/lancedb/issues/1117 to do that first. If you would like, you are welcome to open a PR for that.


Add ESLint Rule to Github Pull Requests Board

Hey, I just made a Pull Request!
Adds the no-top-level-material-ui-4-import ESLint rule to the github-pull-requests-board plugin to aid with the migration to Material UI v5.

Issue: #23467

[x] A changeset describing the change and affected packages. (more info)
[x] All your commits have a Signed-off-by line in the message. (more info)

Hi! Sorry but this has been moved to https://github.com/backstage/community-plugins


chore: bdd-ghfjxy-1568885046 to 0.0.1

chore: Promote bdd-ghfjxy-1568885046 to version 0.0.1

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
If they are not already assigned, you can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Make ALWAYS_SHOW_DIGITAL_CLIMATE_STRIKE to override other iframe display contion options.

Fixes Issue #88

Sorry for the massive delay in this -- it was crazy during strike week and then I had a vacation :) But looks good, merged down.

@dtoakley all good. Our company went to the strike as well. Thank you for approving!


Test to check if all cluster names are properly parsed in generated constants

Description
Write unit tests to check the generated files are valid.
Add the below test just before https://github.com/konveyor/move2kube/blob/8c23e21d0f57928d6af63d5f06015a5981aea5e6/internal/metadata/clustermdloader_test.go#L52
	t.Run("check if all clusters in constant were loaded", func(t *testing.T) {
		p := plantypes.NewPlan()
		loader := metadata.ClusterMDLoader{}
		cmMap := loader.GetClusters(p)
                //TODO: Read all .yaml files in internal/metadata/clusters, and find the value in metadata.name using say a regex
		for clustername := range <ALL NAMES IDENTIFIED IN ABOVE STEP> {
			if _, ok := cmMap[clustername]; !ok {
				t.Fatal("Missing builtin "+clustername+" cluster metadata. The returned cluster info:", cmMap)
			}
		}
	})

@pabloloyola Please take a look into this issue.


Fix a bug: missing rds and endpoints when a new service created

What type of PR is this?
/kind bug

What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes  https://github.com/kmesh-net/kmesh/issues/437
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:
:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.

Flag
Coverage Δ

unittests
37.17% <100.00%> (+5.16%)
:arrow_up:

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

Files
Coverage Δ

pkg/controller/ads/ads_processor.go
80.45% <100.00%> (+0.94%)
:arrow_up:

... and 6 files with indirect coverage changes

/lgtm
/approve


Allow files in debug/share

There are dynamic libraries that need to locate files based on its path.
For example, lib/fbclient.so will locate the file in <path of itself>/../share/firebird/firebird.msg.
The problem is that debug/lib is in a different hierarchy level in relation to share than lib.
It does not feel right to recompile debug and release with different logic to locate others files, as debug files may land in a standard tree later (i.e., vcpkg_installed/triplet/debug/lib/* may go to install-prefix/lib.
So I propsoe the this warning is removed and files are allowed in debug/share.
warning: /debug/share should not exist. Please reorganize any important files, then use
file(REMOVE_RECURSE "${CURRENT_PACKAGES_DIR}/debug/share")
error: Found 1 post-build check problem(s). To submit these ports to curated catalogs, please first correct the portfile:

Could you workaround by using a symlink from debug/share to share?

Maybe in the client, but when I'm going to add the embedded version of Firebird database, i.e., the engine running as a library, then symlinks is problematic.
But are you suggesting to create symlink outside of vcpkg? Because I don't see a sense in vcpkg allowing a symlink but not a file.
Anyway, it looks hack for me and symlinks in Windows is not always available.

BTW, this is not a question (as labeled) for me. It's a feature request.

debug files may land in a standard tree later (i.e., vcpkg_installed/triplet/debug/lib/* may go to install-prefix/lib.)

...or it may land in an arbitrary tree. You really need to make it configurable (https://github.com/microsoft/vcpkg/discussions/35720#discussioncomment-7870278)

debug files may land in a standard tree later (i.e., vcpkg_installed/triplet/debug/lib/* may go to install-prefix/lib.)

...or it may land in an arbitrary tree. You really need to make it configurable (#35720 (comment))

That would be if vpkg is an inherent inflexible and unmaitained tool that people should always fight with it.

I just hit this problem in https://github.com/microsoft/vcpkg/pull/36176
I'm still thinking is a completely nonsense thing.

It is debatable if it makes sense to a have a nearly identical copy of share in debug/share.
And there are indications that deployment to the app location is more relevant than location in the installed tree.

BTW the problems of https://github.com/microsoft/vcpkg/pull/36176 should be discussed there. Not a typical case ATM.

As labelled as question, it's not going to be discussed by vcpkg core team.


Scoreboard Issue.

TDM: No records the points | https://gyazo.com/6f7f88430d69bf7455776a0cb8b8acd2
NAMES: No updates the names on the scoreboard|
https://gyazo.com/30923fd78c9a68465b0371b92fef9025
https://gyazo.com/35a2dd7f8d224301bf5b291a55014cf7
cardinal -v | https://gyazo.com/11fdbcdefcb05ccc446855bb4543445b

From my quick testing, the problem seems to be here.

@Alfalik only 262 lines away from the actual error

you are welcome


CuPy v12 Release Plan

Planned Features

Use cuSPARSE generic API in cupyx.scipy.sparse (#3513) (v12.0.0b1)
Explore possibility of distributed ndarray support (v12.0.0a2)

Pseudo ndarray (subclass of cupy.ndarray) that has elements across multiple GPUs
Elementwise/reduction operation

https://github.com/cupy/cupy/issues/4831 (v12.0.0b2)
https://github.com/cupy/cupy/issues/4290 (v12.0.0a2)

cupy.apply_along_axis
elementwise kernel with JIT

https://github.com/cupy/cupy/issues/6011 (v12.0.0a1)
https://github.com/cupy/cupy/issues/7082 (to be scheduled)
https://github.com/cupy/cupy/issues/6965
Deprecations (under discussion, may subject to change)

CUDA: Keep current supported versions
ROCm: Drop ROCm 5.0
Python: Keep current supported versions
NumPy:  Follow NEP29
SciPy: TBD

Internal Tasks:

GitHub Action-based wheel build https://github.com/cupy/cupy-release-tools/issues/272
https://github.com/cupy/cupy/issues/6561 (due: September 2022)

Schedule & Release Manager

[x] v12.0.0a1 (v11.1.0) (2022-09-01) @emcastillo
[x] v12.0.0a2 (v11.2.0) (2022-10-06) @kmaehashi
[x] v12.0.0b1 (v11.3.0) (2022-11-10) @asi1024
[x] v12.0.0b2 (v11.4.0) (2022-12-08) @takagi & @emcastillo
[ ] v12.0.0b3 (v11.5.0) (2022-01-19) @kmaehashi
[ ] v12.0.0rc1 (v11.6.0) (2023-02-16) @asi1024
[ ] v12.0.0 (2023-03-16) @emcastillo

Notes:

The schedule and listed features are tentative and may be subject to change depending on the progress.
The code will be frozen around 15:00 on 2 days before the release date for QA. Dates are in JST.
v11.x.x releases will only contain backported pull-requests (mainly bug-fixes) from the v12 (master) branch.

Past Release Plans

v9: https://github.com/cupy/cupy/issues/3891
v10: https://github.com/cupy/cupy/issues/5049
v11: https://github.com/cupy/cupy/issues/6246

update: filled date and release manager for each release.

Python: Keep current supported versions

I noticed that Python 3.7 will be EOL within the v12's stable lifecycle. I guess it's ok to drop Python 3.7 support in v12?

Sounds good to me, conda-forge has dropped PY37 for a while too.

Thanks for the catch! We'll publish a plan for CuPy v13 soon 😃


DRILL-7313: Use Hive schema for MaprDB native reader when field was empty

For problem description please see DRILL-7313.

+1, LGTM.


Number of arguments of TimestampSub()

Since BigQuery's TIMESTAMP_SUB() has two arguments, I assume that TimestampSub() also has two arguments. However, the following predicate will result in an error.
A(t: TimestampSub(CurrentDate("Asia/Tokyo"), SqlExpr("INTERVAL 9 HOUR",{})));

Compiling:
A(t: TimestampSub(CurrentDate("Asia/Tokyo"), SqlExpr("INTERVAL 9 HOUR",{})))

[ Error ] Built-in function TimestampSub takes (3, 3) arguments, but 2 arguments were given.

Yes, there was a bug with the time arithmetic arity.
Thanks for pointing it out!
I've updated the functions in the codebase and released pypi.
Tested with:
A1(t: DatetimeSub(CurrentDatetime("Asia/Tokyo"), SqlExpr("INTERVAL 9 HOUR",{})));
A1(t: DatetimeAdd(CurrentDatetime("Asia/Tokyo"), SqlExpr("INTERVAL 9 HOUR",{})));
A2(t: DateSub(CurrentDate("Asia/Tokyo"), SqlExpr("INTERVAL 9 day",{})));
A2(t: DateAdd(CurrentDate("Asia/Tokyo"), SqlExpr("INTERVAL 9 day",{})));
A3(t: TimestampSub(CurrentTimestamp(), SqlExpr("INTERVAL 9 day",{})));
A3(t: TimestampAdd(CurrentTimestamp(), SqlExpr("INTERVAL 9 day",{})));
A4(t: TimeSub(CurrentTime("Asia/Tokyo"), SqlExpr("INTERVAL 9 hour",{})));
A4(t: TimeAdd(CurrentTime("Asia/Tokyo"), SqlExpr("INTERVAL 9 hour",{})));

Please let me know if you see further issues.

I have confirmed that it has been fixed.
By the way, is there a better way to write the SqlExpr("INTERVAL 9 hour",{}) part?

Great! Thank you!
If such expression is used a lot, then factoring it out into a function, as follows, helps readability.
IntervalHours(x) = SqlExpr("INTERVAL {x} HOUR", {x:});

A4(t: TimeSub(CurrentTime("Asia/Tokyo"), IntervalHours(9)));
A4(t: TimeAdd(CurrentTime("Asia/Tokyo"), IntervalHours(9)));


failed to save

my files are not saving it is giving me "insufficient permission"
Version: 1.87.2
Commit: 863d2581ecda6849923a2118d93a088b0745d9d6
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.6099.109 Safari/537.36 WebCatalogPhoton/42.1.1
Embedder: vscode.dev

We closed this issue because it is a question about using VS Code rather than an issue or feature request. Please search for help on StackOverflow, where the community has already answered thousands of similar questions. You may find their guide on asking a new question helpful if your question has not already been asked. See also our issue reporting guidelines.
Happy Coding!


Workaround for Add-Migration command failure

Added a workaround note to reopen Visual Studio in case if Package Manager fails to recognize Add-Migration command. This is a tested behaviour of Package Manager

Hi @NageshAndani, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. Real humans will now evaluate your PR.

TTYL, DNFBOT;

@NageshAndani Can you clarify what you meant by "This is a tested behaviour of Package Manager"?  I've verified that the 'Add-Migration' command is available without restart when following the tutorial steps. Do you have the latest tooling installed?   cref https://docs.efproject.net/en/latest/platforms/aspnetcore/new-db.html#prerequisites

@natemcmaster I mean, when I followed this doc to setup a sample app to work on Entity Framework, I got an error due to Add-Migration command was not recognized. From StackOverflow threads, I got to know the workaround of restarting VS.
The same workaround is mentioned in EF's other doc too (Database First page).
I am using VS 2015 with ASP.NET Core 1.0 + Tools Preview 2

Thanks for the contribution!


Adjustments

Adjust to newest Hecke version
Add Manifest.toml for reproducibility

It makes the tests and the examples run.


apply PR504 for website-migration

applying the change from the referenced PR.  @uidoyen It looks like we may have missed this change in website-migration branch - can you confirm?  https://github.com/debezium/debezium.github.io/pull/504

@mdrillin You are right. We have missed it. It looks good now. Thanks.


Fix dead-lock when loading a new map in synchronous mode.

Description
It seems we forgot to reset the settings after a new world is loaded, the intended behaviour was to reload the map with default settings because a fresh new map is created, and in fact the new world had the settings reloaded but the engine was not properly notified thus creating inconsistent state.
The following works now (also without ticking in between).
client = carla.Client('localhost', 2000)
client.set_timeout(2.0)

world = client.get_world()

while True:
    print('new world: enable sync mode.')
    world.apply_settings(carla.WorldSettings(synchronous_mode=True))

    for _ in range(0, 10):
        time.sleep(1)
        world.tick()
        world.wait_for_tick()
        print('tick!')

    world = client.reload_world()

Fixes #1412.

This change is

What do you think about extending tests in https://github.com/carla-simulator/carla/blob/master/PythonAPI/test/smoke/test_sync.py with related with issue cases?

@pawel-ziecina good call, I'll do that.


Add a posibility to disable an input in the Busola extentions

Description
As a Kyma developer who writes a Busola extension I would like to be able to make certain inputs disabled. There is already a similar behaviour in the Subscription tab:

Hi @VladislavPaskar
We introduce readOnly flag for widget: Text
https://github.com/kyma-project/busola/blob/main/docs/extensibility/form-section.md#text
Changes are actually on dev, on following days we will push it to stage and prod.


Wrong screenshot of Mouse Properties "Wheel" tab

microsoft.ui.input/mousewheelparameters_chartranslation.md
microsoft.ui.input/mousewheelparameters_pagetranslation.md

These two pages contains wrong screenshot that shows "Pointer options" tab instead of "Wheel" tab:

Please update screenshot with proper one.

Here is proper screenshot from Windows 11:

Image has been updated in both the UWP WinRT API docs and the WinApp SDK WinRT docs. Thanks!


Pyright (VS code) chokes on typing_extensions.TypeAlias

https://github.com/pydantic/pydantic/blob/ac61c071822d7418f1bab2450e8b2ab0438b2f84/pydantic/main.py#L50
I am overriding default model_dump_json in a custom model class to include indentation, exclude null values, and always use alias.
    def model_dump_json(
        self,
        *,
        indent: int | None = 4,
        include: IncEx = None,
        exclude: IncEx = None,
        by_alias: bool = True,
        exclude_unset: bool = False,
        exclude_defaults: bool = False,
        exclude_none: bool = True,
        round_trip: bool = False,
        warnings: bool = True,
    ) -> str:
        return super().model_dump_json(
            indent=indent,
            include=include,
            exclude=exclude,
            by_alias=by_alias,
            exclude_unset=exclude_unset,
            exclude_defaults=exclude_defaults,
            exclude_none=exclude_none,
            round_trip=round_trip,
            warnings=warnings,
        )

As is, I get the following warning from VS code:
"IncEx" is not definedPylancereportUndefinedVariable
(function) IncEx: Unknown
The code executes normally when run by the interpreter - it's just an IDE issue.
I can get rid of this warning by adding the following code at the top of my file:
import typing

IncEx: typing.TypeAlias = (
    "set[int] | set[str] | dict[int, IncEx] | dict[str, IncEx] | None"
)

I've noticed that the existing code uses "typing_extensions" rather than "typing" for this alias, even though it uses "typing" for everything else in the block. I'm not sure if this is intentional, or an error.
Selected Assignee: @adriangb

Pylance can't know about the IncEx type if it is not imported and thus not present in your current module.
Unfortunately, IncEx is defined in a if TYPE_CHECKING block, meaning everything enclosed in this block will not be available at runtime. So to be able to import it and make it available to the type checker/IDE:
from typing import TYPE_CHECKING

if TYPE_CHECKING:
    from pydantic.main import IncEx

class YourModel(BaseModel):
    def model_dump_json(
        self,
        *,
        indent: int | None = 4,
        include: IncEx = None,
        exclude: IncEx = None,
        ...

More info is available here: https://docs.python.org/3/library/typing.html#typing.TYPE_CHECKING
Regarding typing_extensions, it is a module which contains backports of the new typing related Python features, so that they can be used in older versions of the language (e.g. TypeAlias was introduced in 3.10).
So using typing_extensions or typing is equivalent (except in some edge cases).

Unfortunately, IncEx is defined in a if TYPE_CHECKING block, meaning everything enclosed in this block will not be available at runtime. So to be able to import it and make it available to the type checker/IDE:

This is right, thank you for looking into this @Viicos. I don't know that I'd call it "unfortunate": the rationale for doing this is that these types aren't needed at runtime, so we can put them in a TYPE_CHECKING block to avoid executing them when the module is imported, reducing import time and consequently startup time for a FastAPI app, etc.
@RS-Credentive if this solved your problem please go ahead and close this issue

I don't know that I'd call it "unfortunate"
I wouldn't either, started my sentence thinking there was no way at all to import IncEx, but then remembered you could still enclose the import statement in a if TYPE_CHECKING block as well 😅

Thanks for the informative response. This has addressed my issue.


I don't have an unbox version in my truffle

I have truffle 3.2.4 and not managing to update to newer version

It was just cause I had two versions of truffle and the default wasn't the one in npm-global\bin


[Summer 2021] SAPP Feature Request - Support edit status code in Issue UI

Issue model has a status field which defaults to uncategorized we should support updating it from the UI through a dropdown showing the supported Statuses

Claiming this :)

@r0rshark what are your thoughts on adding filter support as well?

Yes that would be ideal

@r0rshark sorry it took a while, but yeah, did it: https://github.com/facebook/sapp/pull/30

Closed via https://github.com/facebook/sapp/commit/c59f5833ede65c5f6b7ddb66a2dfade686313a06


pm: add bsp power management support for ish

Adds bsp level power management support for Intel ISH.

ALL PM code are for ISH only. put all of them into bsp_sedi/soc/intel_ish.


Is this API right for me?

I'm trying to create a bot that listens to all public channels and every time anyone says anything  on a public channel, regardless if it includes an @mention, I want to send to a channel called *notifications" the following
Username
channel name
the message itself, including a link to the message.
Is this doable with this API?  Does it have to be hosted somewhere, or can it "live" on the slack servers?

Yes, it is doable. I don't really have the time to go into how right now, so I apologize on that note.
It has to be hosted by you, Slack won't host the bot for you.
I do, however, want to ask you why you want to do this? I don't see any purpose, but I may just be missing something.

I get extremely frustrated when I see or hear a notification and then I
can't find out what caused the action. When you have dozens of channels and
red dots galore, slack becomes overwhelming. I'd just like to see a log of
all recent public events that I can jump too and see what caused the ding.
I've looked for slack user forums, but haven't seen anything useful. I wish
slack would create a forum. I don't like it when companies don't have one,
because it isolates their customers.
On Thu, Jun 23, 2016 at 02:27 Everesty<EMAIL_ADDRESS>wrote:

Yes, it is doable. I don't really have the time to go into how right now,
so I apologize on that note.
It has to be hosted by you, Slack won't host the bot for you.
I do, however, want to ask you why you want to do this? I don't see any
purpose, but I may just be missing something.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/slackhq/node-slack-sdk/issues/236#issuecomment-227961261,
or mute the thread
https://github.com/notifications/unsubscribe/AF4MU_frt7pc2qZrt9--OzPr3KKqASvYks5qOidQgaJpZM4I8Iaq
.

Uh, there is a feature that shows you a list of times you've been mentioned (with basically everything you just asked for)
In fact, there's even a Slack Help Center article on it.
On Desktop
'Tis simple, there's a little @ button in the upper right corner of a chat:

It should show you a list of times you've been mentioned. If you'd like, there's also an option to include @channel mentions.
On Mobile
(sorry for no images, too tired atm)

In the upper left you should see your team's icon, tap that.
Again, in the upper left of the drawer that slides out you should see "Home".
Tap it and one of the options will be "Mentions".

Again, 'tis simple.

As for other issues you may have in the future, consider looking at the Help Center or (if you can't find the resolution to a slack issue on the Help Center) consider opening a support request.

Closing, as this is a general Slack help request, rather than something specific to the project. You might also consider joining the Dev4Slack Slack team (sign up at dev4slack.xoxco.com), channel #sdk-node-slack-sdk


Use Go Mock

Problem
Mocks used for testing are currently written manually using testify/mock. While this provides necessary functionality for testing, it doesn't scale well for the addition of new testing mocks and regeneration of existing ones.
Problem Solution
GoMock provides mock autogeneration capabilities using embed instructions within Go files.
Acceptance Criteria
I. All current mocks (i.e, EthClientInterface) are regenerated using mockgen and stored as independent files in an internal/mocks package
II. All current mocks have embedded gomock instructions at the top of the code files which declare the interface that we'd like to mock. For example, to mock EthClientInterface, we add the following line to the top of internal/client/eth_client.go:
//go:generate mockgen -package=mocks -destination=../mocks/eth_client.go github.com/base-org/pessimism/internal/client EthClientInterface

III. Mock generation should be possible using a make command. (e.g, make mock-gen)

Hello, I would like to work on this task. Please assign it to me.


Menu bar not visible when using Ubuntu 19.04 Yaru theme

Prerequisites

[ ] Put an X between the brackets on this line if you have done all of the following:

Reproduced the problem in Safe Mode: https://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
Followed all applicable steps in the debugging guide: https://flight-manual.atom.io/hacking-atom/sections/debugging/
Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description
[Description of the issue]
Steps to Reproduce

In Ubuntu 19.04, set the system UI theme to be Yaru
Open Atom editor

Expected behavior: The menu bar should be using white text color
Actual behavior: The menu bar uses black color instead on a black background, thus totally unreadable
Reproduces how often: [What percentage of the time does it reproduce?]
Versions
1.37.0 x64
Additional Information
Any additional information, configuration or data that might be necessary to reproduce the issue.

Do you still see this if you disable GPU rendering?

If that ☝ doesn't help, I also wonder if you're hitting https://github.com/atom/atom/issues/18535?  Can you try the 1.39 beta and see how things look there?

Do you still see this if you disable GPU rendering?

Yes, problem still exists.

Can you try the 1.39 beta and see how things look there?

One more thing to try 😉

It's working 1.39.beta2 it's mentioned in #18535 thanks guys :)

Same issue for me with Atom 1.38 on a fresh default Ubuntu 19.04 install. After checking the 1.39 beta2 the menu bar appears properly.

Working in 1.39


Generated UID thorugh CLI tool can be longer than 63 characters

If you will use --url parameter with url that is around 63 characters long (without the scheme), the generated CRD will use UID which will be longer than that, since it also appends the url, and it will be rejected as a valid label for service.
Example:

oc exec -n istio-system $(oc get po -n istio-system -o jsonpath='{.items[?(@.metadata.labels.app=="3scale-istio-adapter")].metadata.name}') -it -- ./3scale-config-gen --url="https://3scale-admin.extremely.long.url.with.sixtythree.characters.com" --service="10" --token="access-token"
This will generate UID like this
3scale-admin.extremely.long.url.with.sixtythree.characters.com-10, which is longer than 63 characters and wont be accepted as a valid label.

Thanks @pehala! Will have it fixed for the next release, probably out of the work in #93, but if that does not finally make it in then we'll have a specific fix for this.

@unleashed, ok to close this?

This will no longer apply in the next release, but I prefer for @pehala to close it once he has worked with it.


sitelinks_languages: update

basically just ran the script.
Im not sure why the list wasnt alphabetically before as the script just returns the website which is alphabetically?
also see #72

@EdJoPaTo it could simply be that it wasn't alphabetically sorted on the website before ^^

patch published in v7.6.1


SWA has no tests

We should have unit test coverage for SWA.

Closing. Tracking elsewhere as low pri


fixes #1270 - adding utils.plot_prune_fifo()

In several issues (https://github.com/bluesky/bluesky-mpl/issues/4, https://github.com/APS-USAXS/ipython-usaxs/issues/309, and here in #1270), it has been noted that plotting too many traces in a LivePlot window causes the best effort callback to crash or the LivePlot window to become too small to view the plot.
Description
This PR introduces a utility function plot_prune_fifo() (not a bluesky plan) which the user calls at their choice to replot the LivePlot window with only the last n traces shown.
If the user has chosen to display peak centers (pressing P in the plot window) as lines, this function will work around those lines.  If there is no plot window that matches the given axes, the function will return silently.
For this function to work, it is necessary for the user to pass in the BestEffortCallback object and the objects for y and x axes, in addition to the non-negative number of traces to keep when replotting.
Motivation and Context
fixes #1270
How Has This Been Tested?
This has been tested programmatically while repeating a set of lineup scans, seeking the position of some simulated diffraction peak.  Before each pass through the loop, a call to plot_prune_fifo(bec, 4, noisy, m1) is used to limit the number of graphs shown to a number known not to cause the problems reported.
In the testing loop, the peak parameters are first randomized, then a bp.scan() is run (over an absolute range known to contain the peak somewhere, typical of a beam line search) to assess bec.peaks["cen"] and adjust the positioner.  A second bp.rel_scan() is run between +/- bec.peaks["fwhm"] to refine the bec.peaks  findings.
Screenshots:
during continuous running:

then, later:

and then even later, still looping while True:

This travis-ci failure is for some other problem not in this PR since the PR has not introduced any new tests nor should it influence any existing tests.

Actually, the failure is not with TravisCI, but rather with the slight reduction of the test coverage.

Isn't that from codecov?  Four out of five travis-ci workers were green.  This one was red: https://travis-ci.org/bluesky/bluesky/jobs/620856501?utm_medium=notification&utm_source=github_status

We seem to ignore the nightly failures as they can be caused by various unrelated changes in Python itself or other libraries.

I think testing this functionality with pytest is still possible, so we would at least hit the leftover n variable name.

As for the order of arguments, y before x, that was my second choice and it was to match the same order when calling bp.scan().  I'll switch that back since x before y is more natural.

still, this deserves at least some attention from unit testing ... working on that (while waiting for XPCS instrument)

While writing the unit test, the editor says the arguments to bec.plot_prune_fifo() must be specified by name.  I object to this, strongly.  We must not make this verbose.  I will revert back to the simpler named arguments by removing the *.

The new tests must be checked.  Every test in test_bec.py fails on my workstation.  I'm new to using pytest.

I don't understand why the Y axis is named different than expected.  Can anyone explain?
Here's where the unit test fails in travis-ci
        # get reference key for our detector
        det_name = next(iter(bec._live_plots[uuid]))
        # should be same as hw.ab_det.name, prove it now
>       assert det_name == hw.ab_det.name
E       AssertionError: assert 'det_a' == 'det'
E         - det_a
E         ?    --
E         + det

This was the line that started the scan
RE(bps.repeater(num_pruned, scan, [hw.ab_det], hw.motor, 1, 5, 5))

and the name det_a is shown in the LiveTable output:
Transient Scan ID: 1     Time: 2019-12-05 19:22:54
Persistent Unique Scan ID: '466e42eb-6916-488a-aa56-b89fc9d8c03c'
New stream: 'primary'
+-----------+------------+------------+------------+
|   seq_num |       time |      motor |      det_a |
+-----------+------------+------------+------------+
|         1 | 19:22:54.2 |      1.000 |      0.734 |
|         2 | 19:22:54.3 |      2.000 |      0.538 |
|         3 | 19:22:54.3 |      3.000 |      0.653 |
|         4 | 19:22:54.4 |      4.000 |      0.935 |
|         5 | 19:22:54.4 |      5.000 |      0.967 |
+-----------+------------+------------+------------+
generator scan ['466e42eb'] (scan num: 1)

I don't understand why the Y axis is named different than expected. Can anyone explain?
Here's where the unit test fails in travis-ci
        # get reference key for our detector
        det_name = next(iter(bec._live_plots[uuid]))
        # should be same as hw.ab_det.name, prove it now
>       assert det_name == hw.ab_det.name
E       AssertionError: assert 'det_a' == 'det'
E         - det_a
E         ?    --
E         + det

I don't know where the _a is appended to the name of the detector, defined in https://github.com/bluesky/ophyd/blob/6414a0673793309ad7cd2a55d736e3bc49a8b6cb/ophyd/sim.py#L1355:
    ab_det = ABDetector(name='det', labels={'detectors'})

@danielballan, @tacaswell, do you have any hint about it?

Ah, I see now, it the name of the first read_attr:
$ ipython
Python 3.6.7 |Anaconda, Inc.| (default, Oct 23 2018, 14:01:38)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.5.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: from ophyd.sim import hw

In [2]: hw = hw()

In [3]: hw.ab_det
Out[3]: ABDetector(prefix='', name='det', read_attrs=['a', 'b'], configuration_attrs=[])

In [4]: hw.ab_det.name
Out[4]: 'det'

In [5]: hw.ab_det.read_attrs
Out[5]: ['a', 'b']

OK, seems a special case for this signal.  Thanks for the mining.

It's not a special case, it seems to be a general construction method of the field names corresponding to the "hinted" component names used in the live plots/tables. Continuing the demo:
In [6]: hw.ab_det.kind
Out[6]: <Kind.config|normal: 3>

In [7]: hw.ab_det.a.kind
Out[7]: <Kind.hinted: 5>

In [8]: hw.ab_det.b.kind
Out[8]: <Kind.normal: 1>

That's why we don't see the det_b in the table.

For the unit test, I'm going to add the .a.  Is this a practice the prune method should consider?  I avoided using str as parameters, instead taking the str from the signal.name because deciding what string to provide (dotted, underlined, something else) was one of the early, hard stumbles I had when learning ophyd.

It seems like an off-by-one bug. I reproduced it locally with pytest -vvvv -x --pdb, and seeing the following:
X: motor
Y: det_a
before: [<matplotlib.lines.Line2D object at 0x127dc9208>, <matplotlib.lines.Line2D object at 0x127c80be0>, <matplotlib.lines.Line2D object at 0x127d75ba8>, <matplotlib.lines.Line2D object at 0x12805a278>]
Limiting LivePlot(det_a) to 2 lines.
after: [<matplotlib.lines.Line2D object at 0x127c80be0>, <matplotlib.lines.Line2D object at 0x127d75ba8>, <matplotlib.lines.Line2D object at 0x12805a278>]

Right.  But how is it off by one?  Time for temporary diagnostics in the plot_prune_fifo()

This diagnostic show that the LivePlot.remove() method has not been successful for one of the traces (0x7f532810f7b8) to be removed:
keepers: [<matplotlib.lines.Line2D object at 0x7f5328199e80>, <matplotlib.lines.Line2D object at 0x7f53281406d8>]
after: [<matplotlib.lines.Line2D object at 0x7f532810f7b8>, <matplotlib.lines.Line2D object at 0x7f5328199e80>, <matplotlib.lines.Line2D object at 0x7f53281406d8>]

Do it, thanks for following along.
On Thu, Dec 5, 2019, 4:01 PM Maksim Rakitin<EMAIL_ADDRESS>wrote:

@mrakitin commented on this pull request.
In bluesky/callbacks/best_effort.py
https://github.com/bluesky/bluesky/pull/1272#discussion_r354570125:

       # pick out only the lines that contain plot data,

       # skipping the lines that show peak centers

       lines = [

           tr

           for tr in lp.ax.lines

           if len(tr._x) != 2

               or len(tr._y) != 2

               or (len(tr._x) == 2

                   and tr._x[0] != tr._x[1])

       ]

       print(f"found these lines: {lines}")

       if len(lines) > num_lines:

           print(f"Limiting LivePlot({y_signal.name}) to {num_lines} lines.")

           keepers = lines[-num_lines:]

           print(f"keepers: {keepers}")

           for tr in lp.ax.lines:

I changed it locally, and now it's passing!
$ pytest -vvvv -x --pdb bluesky/tests/test_bec.py::test_plot_prune_fifo
================================================= test session starts ==================================================
platform darwin -- Python 3.6.7, pytest-4.5.0, py-1.7.0, pluggy-0.12.0 -- /Users/mrakitin/anaconda3/envs/bluesky/bin/python
cachedir: .pytest_cache
benchmark: 3.2.2 (defaults: timer=time.perf_counter disable_gc=False min_rounds=5 min_time=0.000005 max_time=1.0 calibration_precision=10 warmup=False warmup_iterations=100000)
rootdir: /Users/mrakitin/src/mrakitin/DAMA/bluesky
plugins: faulthandler-1.6.0, benchmark-3.2.2
collected 1 item
bluesky/tests/test_bec.py::test_plot_prune_fifo PASSED                                                           [100%]
=============================================== 1 passed in 4.62 seconds ===============================================
I can push my change to your PR branch if you wish.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/bluesky/bluesky/pull/1272?email_source=notifications&email_token=AARMUMCFJYDELHD46LSDCTLQXF237A5CNFSM4JVQF7PKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCOFRNGY#discussion_r354570125,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AARMUMFKK5IM462ELTBWDL3QXF237ANCNFSM4JVQF7PA
.

As an aside, here's what happens when I try to run pytest locally:
(db-test) mintadmin@mint-vm:~/.../eclipse/bluesky$ pytest -vvvv -x --pdb bluesky/tests/test_bec.py::test_plot_prune_fifo
=========================================================== test session starts ============================================================
platform linux -- Python 3.7.5, pytest-5.3.1, py-1.8.0, pluggy-0.13.1 -- /home/mintadmin/Apps/anaconda/envs/db-test/bin/python
cachedir: .pytest_cache
rootdir: /home/mintadmin/Documents/eclipse/bluesky
collected 1 item

bluesky/tests/test_bec.py::test_plot_prune_fifo ERROR                                                                                [100%]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> traceback >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

tmpdir = local('/tmp/pytest-of-mintadmin/pytest-3/test_plot_prune_fifo0')

    @pytest.fixture(scope='function')
    def hw(tmpdir):
        from ophyd.sim import hw
>       return hw(str(tmpdir))
E       TypeError: hw() takes 0 positional arguments but 1 was given

bluesky/tests/conftest.py:31: TypeError
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> entering PDB >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> PDB post_mortem (IO-capturing turned off) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> /home/mintadmin/Documents/eclipse/bluesky/bluesky/tests/conftest.py(31)hw()
-> return hw(str(tmpdir))
(Pdb)

Yep, I had this problem as well. Reinstalling the latest pre-release of ophyd solved the issue.

Looks like I'll want a bluesky-pytest environment

Yup.  Over. A. Barrel.
On Thu, Dec 5, 2019, 4:33 PM Maksim Rakitin<EMAIL_ADDRESS>wrote:

@mrakitin commented on this pull request.
In bluesky/callbacks/best_effort.py
https://github.com/bluesky/bluesky/pull/1272#discussion_r354582358:

       # pick out only the lines that contain plot data,

       # skipping the lines that show peak centers

       lines = [

           tr

           for tr in lp.ax.lines

           if len(tr._x) != 2

               or len(tr._y) != 2

               or (len(tr._x) == 2

                   and tr._x[0] != tr._x[1])

       ]

       print(f"found these lines: {lines}")

       if len(lines) > num_lines:

           print(f"Limiting LivePlot({y_signal.name}) to {num_lines} lines.")

           keepers = lines[-num_lines:]

           print(f"keepers: {keepers}")

           for tr in lp.ax.lines:

[image: image]
https://user-images.githubusercontent.com/13209176/70279840-3f669c80-1785-11ea-84ed-75bfcfb63983.png
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/bluesky/bluesky/pull/1272?email_source=notifications&email_token=AARMUMH3SXTWPOYHRE5N6JDQXF6T5A5CNFSM4JVQF7PKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCOFVFHY#discussion_r354582358,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AARMUMAYDQVJ5BOYOT2OVOTQXF6T5ANCNFSM4JVQF7PA
.

It seems to be passing now (slowly...). I think the diagnostics/debugging prints can be removed now.

all diagnostics removed and travis passes four of five workers (nightly fails but not for this code)
Looks ready to merge.

Thanks a bunch for pushing this upstream, @prjemian.


Move and ignore docker-compose.yml

Wanted to allow users to run their server out of the local git repository without customizations unique to their servers trying to push back up.

Looks good to me :) Merging with thanks!


Cleanups and fixes medley

The biggest change in this is PR is, obviously, the removal of CBigNum and friends. The new boost::multiprecision implementation benchmarked ~7x faster.
The other changes are low-risk, either cleaning up long-standing JIRA issues or reducing unused code, with one exception:
The "Reject invalid message keys in SetAccount handler": it's conceptually simple - if the specified message key isn't a valid PublicKey we reject it. We may want to consider doing this as a separate PR, with a stricter check on key validity not only during preflight but during processing as well. Doing so would constitute a transaction-processing change.
Reviews: @scottschurr, @miguelportilla, @JoelKatz

Changes look good to me.
I'm holding off on the thumbs up until we talk through adding some real STAmount rounding tests.  Someone besides you could add them, but I think they should be added.

[Current coverage][cc-pull] is 67.63%

Merging [#1682][cc-pull] into [develop][cc-base-branch] will decrease coverage by -0.19%

4 files (not in diff) in src/ripple were modified. more

Misses -4
Hits +4

2 files (not in diff) in ...beast/websocket/impl were modified. more

Misses +20
Hits -21

2 files (not in diff) in ...ast/websocket/detail were modified. more

Misses +22
Hits -23

1 files (not in diff) in ...lude/beast/websocket were modified. more

Misses +6
Hits -9

File ...ol/impl/STAmount.cpp was modified. more

Misses -1
Partials 0
Hits +1

@@            develop      #1682   diff @@
==========================================
  Files           950        946     -4
  Lines         71284      70464   -820
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
- Hits          48360      47652   -708
+ Misses        22924      22812   -112
  Partials          0          0

Powered by Codecov. Last updated by [fbb5a75...d21d041][cc-compare]
[cc-base-branch]: https://codecov.io/gh/ripple/rippled/branch/develop?src=pr
[cc-compare]: https://codecov.io/gh/ripple/rippled/compare/fbb5a753b19a08daec3e8897a72559a6b2bfeb81...d21d041a9be160546aeb1b054097b10b49f94f70
[cc-pull]: https://codecov.io/gh/ripple/rippled/pull/1682?src=pr

Rebased

:neckbeard::+1:

@nbougalis: What are your thoughts on STAmount rounding unit tests?  Should this wait for them?  Or should they be added later?

LGTM :+1:

@scottschurr: it would be great to add more tests but I don't think they need to be included in this PR. If you feel strongly enough, then I'm open to adding some, but it will cause a delay on this, because I don't have the bandwidth available to add unit tests here.
Also, keep in mind, STAmount will become only a serialization class eventually. It's going to be replaced by IOUAmount, XRPAmount and all math operations involving scaling will be made against those classes and Rate or Quality as appropriate. So the tests, really, belong in that code.

@nbougalis: Thanks for your thoughts.  I appreciate the bandwidth issue.  :+1:

merged.


Column documentation typo correction

In column documentation isCentered should be IsChentered and isVCentered should be IsVCentered .
it is not breaking changes. If you are busy, I ll do it later on. You can keep it on my name. :)

Ah, yes I didn't fixed all the properties list in the docs.Thanks for the reminder


Add the XML LSP - lemminx

Container PR here - https://github.com/lspcontainers/dockerfiles/pull/96

Already merged dockerfiles PR and pushed to Docker Hub. This should be good to go now - thank you!


ci: mark CVE-2024-3154 as a false scan positive

This feels insane, I'm not quite sure what is going on here. There appear to be 2 separate vulnerability advisories, one in runc and one in cri-o (which doesn't seem to be available yet).
However, this issue definitely doesn't affect us - we don't use cri-o anywhere in our stack, we're not spawning pods in the dagger engine, etc.
There's also not a version of runc we can feasibly upgrade to - 1.2.0-rc1 (as suggested in https://github.com/advisories/GHSA-c5pj-mqfh-rvc3), is a minor release, and is also an RC, so we shouldn't depend on it.
We should keep an eye on what the status of these vulnerabilities are, since disclosure still seems ongoing, but we can at least stop CI going red on these.

Phewww, I genuinely for a moment thought I was going insane 😂


not an issue a update:

i just updated to latest jss-theme-reactor 0.11.1 on the v1-alpha
working good didn't see any problem with .. maybe should we to update it?

We are working on a major styling upgrade, we will no longer rely on jss-theme-reactor.


[SP-2777] Backport of PDI-13787 - Get Variables: Cannot convert String Variable value to Timestamp field (6.1 Suite)

Backport of https://github.com/pentaho/pentaho-kettle/pull/2652 + checkstyle

Build Completed
:x: This pull request has errors. They will need to be addressed before it can be accepted. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
ant -Dpentaho.resolve.repo=http://ivy-nexus.pentaho.org/content/groups/approved -Dtestreports.dir=bin/reports/unit-test -f engine/build.xml clean-all resolve jacoco && ant -Dpentaho.resolve.repo=http://ivy-nexus.pentaho.org/content/groups/approved -Dtestreports.dir=bin/reports/integration-test -f engine/build.xml jacoco-integration checkstyle publish-local

Cleanup Commands
rm -r ~/.ivy2/local || echo no publish local to remove

Changed files
  engine/src/org/pentaho/di/trans/steps/getvariable/GetVariableMeta.java
  engine/test-src/org/pentaho/di/trans/steps/getvariable/GetVariableMetaTest.java

Newly Fixed Tests:
org.pentaho.di.www.CarteTest.test:
:red_circle: junit.framework.AssertionFailedError
junit.framework.AssertionFailedError: expected:<1> but was:<2>
	at org.pentaho.di.www.CarteTest.test(CarteTest.java:75)

Unit test coverage change
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.
org.pentaho.di.core.auth.core.impl.DefaultAuthenticationConsumerFactory

Branch Change:  + 7.14%
Complexity Change:  + 7.69%

org.pentaho.di.repository.kdr.KettleDatabaseRepositoryCreationHelper

Branch Change:  + 1.64%
Complexity Change:  + .69%
Instruction Change:  + 2.43%
Line Change:  + 2.95%

org.pentaho.di.trans.step.StepMeta

Instruction Change: -.19%:small_red_triangle_down:
Line Change: -.27%:small_red_triangle_down:

org.pentaho.di.trans.steps.getvariable.GetVariableMeta

Branch Change:  + 22.50%
Complexity Change:  + 31.48%
Instruction Change:  + 21.55%
Line Change:  + 34.46%
Method Change:  + 44.12%

org.pentaho.di.trans.steps.replacestring.ReplaceStringMeta

Instruction Change: -.07%:small_red_triangle_down:

org.pentaho.di.trans.steps.sortedmerge.SortedMergeMeta

Instruction Change: -.18%:small_red_triangle_down:

org.pentaho.di.trans.steps.symmetriccrypto.symmetriccryptotrans.SymmetricCryptoTransMeta

Branch Change: -3.33%:small_red_triangle_down:
Complexity Change: -1.85%:small_red_triangle_down:
Instruction Change: -.28%:small_red_triangle_down:

org.pentaho.di.trans.steps.textfileinput.TextFileInputMeta

Branch Change: -.53%:small_red_triangle_down:

org.pentaho.di.www.DefaultWebServerShutdownHandler

Complexity Change:  + 50.00%
Instruction Change:  + 25.00%
Line Change:  + 50.00%
Method Change:  + 50.00%

org.pentaho.di.www.SlaveServerStatus

Complexity Change:  + 2.04%
Instruction Change:  + 2.55%
Line Change:  + 3.45%
Method Change:  + 2.78%

org.pentaho.di.www.WebServer

Branch Change:  + 2.78%
Complexity Change:  + 1.85%
Instruction Change:  + .38%
Line Change:  + .54%

org.pentaho.di.www.WebServer.new TimerTask() {...}

Instruction Change:  + 27.27%
Line Change:  + 33.33%

org.pentaho.di.www.WebServerShutdownHook

Branch Change: -50.00%:small_red_triangle_down:
Complexity Change: -20.00%:small_red_triangle_down:

Integration test coverage change
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.
org.pentaho.di.trans.step.BaseStep

Branch Change: -.30%:small_red_triangle_down:
Complexity Change: -.18%:small_red_triangle_down:
Instruction Change: -.13%:small_red_triangle_down:
Line Change: -.08%:small_red_triangle_down:

Checkstyle violations
The code submitted is not complying with one or more of our guidelines. To perform these checks locally, please use this tool.
/home/buildguy/project/engine/test-src/org/pentaho/di/trans/steps/getvariable/GetVariableMetaTest.java

:heavy_exclamation_mark: Using a static member import should be avoided - org.junit.Assert.assertEquals. at Line: 24

:heavy_exclamation_mark: Using a static member import should be avoided - org.junit.Assert.assertNotNull. at Line: 25

:heavy_exclamation_mark: Using a static member import should be avoided - org.junit.Assert.assertTrue. at Line: 26

@pamval , @mchen-len-son , could you please review this PR?


Split C5000+ warning list

Summary:

Split C5000+ warning range into 2 new articles (C5000-C5199 and C5200-C5399).
This standardizes the range of 200 warnings per article and fix the mismatch where compiler-warnings-c4800-through-c4999.md covers range C4800-C5999.

Note 1) One side effect include the new minor mismatch where compiler-warnings-c4000-c5999.md now only covers till C5399.

@TylerMSFT
Can you review the proposed changes?
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#sign-off

@TylerMSFT - because this PR contains new articles, we can't merge it here in the public repo. The commits will have to be moved to the private repo and reviewed there (where we have access to better tools). Can you move the commits and open a PR there? Let us know if you'd like assistance.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

Thank you for factoring these out! There is a bunch of editing going on in this general area by one of the compiler devs. I hope you don't run into a ton of merge conflicts merging this.

I am making my way up from the lower numbered warnings with my edits, so I don't expect to have much conflict up at the 5000+ level. This should make my changes a little easier when I get up there though.

[like]  Tyler Whitney reacted to your message:

From: Phil Christensen @.>
Sent: Thursday, April 18, 2024 10:00:43 PM
To: MicrosoftDocs/cpp-docs @.>
Cc: Tyler Whitney @.>; Mention @.>
Subject: Re: [MicrosoftDocs/cpp-docs] Split C5000+ warning list (PR #5023)
Thank you for factoring these out! There is a bunch of editing going on in this general area by one of the compiler devs. I hope you don't run into a ton of merge conflicts merging this.
I am making my way up from the lower numbered warnings with my edits, so I don't expect to have much conflict up at the 5000+ level. This should make my changes a little easier when I get up there though.
—
Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/cpp-docs/pull/5023#issuecomment-2065397213, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AC54FH2RLQLZ76F3ENCO7PDY6A7AXAVCNFSM6AAAAABGKNWFGCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRVGM4TOMRRGM.
You are receiving this because you were mentioned.Message ID: @.***>

I'll port the changes to the private repo and submit the PR that way.

Hey @Rageking8 , I ported your work, and did some SEO and description cleanup. PR #5555 just merged, so the work you did here is in and will be live on Monday.
Thanks again for improving the quality of life for C++ doc readers.


[dev branch]Cascading select does not work

Describe the bug
Cascading select does not work on dev branch, because the referenced variable name does not exists (as the variable created post-hoc with randomized name)

Hi, did you manage to solve this problem?
I'm using the 'load()' method but I can't get the data in the child form


Dockerized http pkhex (in progress)

Docker container works but sadly not on ARM64 :(. Also added a lot of general improvements so merging before this MR gets out of scope


refactor: remove unused database dir

I think it's needed for sqlite data file

OK, renamed to data.


compat: use timeit.default_timer instead of time.clock which is gone in Python 3.8

Python 3.8 has dropped the deprecated time.clock() function which makes mako fail
with an AttributeError on import on Windows.
The way time_func was defined (clock() on Windows and time() everywhere else) made it
return a high precision wall clock time without a defined reference. This is exactly
what timeit.default_timer() does for all versions of Python on all platforms,
so just use that instead.
Fixes #301

New Gerrit review created for change a706e952727337702692fd1d8369d259e1600d6e: https://gerrit.sqlalchemy.org/#/c/sqlalchemy/mako/+/1377

mike bayer (zzzeek) wrote:
Code-Review+2 Workflow+1

Gerrit review https://gerrit.sqlalchemy.org/1377 has been merged. Congratulations! :)

thanks!


Code language not supported or defined

VSCode Version:
OS Version:

Steps to Reproduce:

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

when you are using index.html file but you are running in this in this server then Error message will be show this

/needsMoreInfo including platform, version numbers, details of how to reproduce. Screenshots can be pasted here.

okay


Idea: "All Tech"

Not sure if you have a set up for all?   Meaning I have a Pandas DataFrame with the basic open close...  I have written code like this:
stock_df.ta(kind='ema',length=3,append=True)
But I would actually like to just add "ALL" technical key figures as columns to the data frame in one command?  Instead of coding them separately?   Is that possible?  then even if you add more, the program still works over time.
thanks
john

Hello John.
Sorry for responding so late.  To clarify, you would like: stock_df.ta(kind='all', append=True)
to run all the indicators?  Should be possible with the exception of a few indicators.  I will take
a look at it and try to incorporate it.

Kevin
It may require that you set up a bunch of defaults.
But imagine not knowing which one matters.
Easier to just pick all.   Then if you add like 5 more they will auto hit the stream.
Thanks
John
John Vaughan
757-256-8216

On May 13, 2019, at 11:54 AM, Kevin Johnson<EMAIL_ADDRESS>wrote:
Hello John.
Sorry for responding so late. To clarify, you would like: stock_df.ta(kind='all', append=True)
to run all the indicators? Should be possible with the exception of a few indicators. I will take
a look at it and try to incorporate it.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Hi,
From my side, using a code like the following one allow me to generate almost all cases, but I believe it should be better ways for that.
def generateTAFeatures(data, exclude_ind=[], args=None):
    # Indicators not posible to use 'short_run' and 'cross'
    not_ind = ['long_run', 'short_run', 'cross']
    not_ind.append('ichimoku') # Output has to be treaten different because is returning two DataFrames
    not_ind.append('trend_return') # Required trend column

    # Add exclude_ind
    not_ind += exclude_ind

    indicators = [ind for ind in data.ta.indicators(as_list=True) if ind not in not_ind]

    if args is None:
        basic_args = {'append': True, 'ewm': True, 'adjust': True}
        basic_args = dict(zip(indicators, [basic_args] * len(indicators)))

        args = basic_args

    n_args = len(args)
    for i, (ind, arg) in enumerate(args.items()):
        print(f'{i} out of {n_args} features', end='\r')
        data.ta(kind=ind, **arg)

    return data

Hi @lluissalord,
Looks like a start.  It's kinda how I imagined it but haven't gotten to code it yet.  Another for exclusion is vp as it does not return a time series but price buckets with volumes (but that's an easy exclusion to add).
I was contemplating the idea of saving indicator settings via json and using that to load and generate the DataFrame as well.  Any thoughts on that?
Thanks,
KJ

Hi @twopirllc,
I think that a json file is a good idea. It could be used a default values json file which could be used directly on each indicator module and also when used by ta(kind='all').
Besides, some ideas of features that it could have the ta(kind='all') are:

The arguments passed on the call would be good to be used for all the indicators (as it could be append=True or ewm=True).
List of indicators included on all be the ones which are compatible.
As we are on this work, could be interesting other groups base on the nature of the indicstor like: momentum, trend, etc. Other interesting groups could be based on range which is bound the indicator (as for example some indicators are bound between 0-100, others between 0-1, others around the price range and others which are not bound)

These are some idees that could be interesting, but probably there are more of them.

Hi @lluissalord,
All good points.  Perhaps the default json config contain at a minimum "all" and then they can edit the file and load/save separate strategies from there.

    }
]

Also, I don't want to feature creep pandas_ta too much.  But do simplify some tasks that are or can be more cumbersome
What do you think?
Thanks,
KJ

It seems a pretty good idea. Besides, I would think that the list inside kind node could be presented without arguments to take the default, but with the possibility of adding them (probably some indicators will have arguments and other no). In this way, if we want to modify the default values we only have to modify on the indicator function and not in two places.
Even, a better approach could be to have another default.json with the default values for each indicator to have all in one file.
What do you think?
Regards,
Lluis

Hello @twopirllc
Seeing how this thread has been a year underway now, may one ask when the add all technical indicators feature is going to launch? Manually coding all the indicators takes a while and takes focus off what's more important.
Cheers

Hello @sword134,
I do not have a time frame on when it will be completed, but I will make it a greater priority now that it has more requests.  I will implement a naive approach for the time being.  But be warned that using "all" will yield a Massive DataFrame.
Thanks,
KJ

Hello @kabonker & @sword134,
Here is the relevant README section covering the new Strategy Method:
Strategy is a new Pandas (TA) method to facilitate bulk indicator processing. By default, running df.ta.strategy() will append all
applicable indicators to DataFrame df.  Utility methods like above, below et al are not included.

The ta.strategy() method is still under development. Future iterations will allow you to load a ta.json config file with your specific strategy name and parameters to automatically run you bulk indicators.

# Runs and appends all indicators to the current DataFrame by default
# The resultant DataFrame will be large.
df.ta.strategy()
# Or equivalently use name='all'
df.ta.strategy(name='all')

# Use verbose if you want to make sure it is running.
df.ta.strategy(verbose=True)

# Maybe you do not want certain indicators.
# Just exclude (a list of) them.
df.ta.strategy(exclude=['bop', 'mom', 'percent_return', 'wcp', 'pvi'], verbose=True)

# Perhaps you want to use different values for indicators.
# This will run ALL indicators that have fast or slow as parameters.
# Check your results and exclude as necessary.
df.ta.strategy(fast=10, slow=50, verbose=True)

# Sanity check. Make sure all the columns are there
df.columns

Let me know if you run into any issues.  I will close this issue in a few days otherwise.
Thanks again for using,
KJ


Ctrl+G doesn't work as in vim

It shows labels on the UI like this:

I used to use 1Ctrl+G to print the full path of the file in vim, like here:

Hi,
Oni by default has its sneak-UI bound to Ctrl+g, which is those labels you are seeing. (Typing a label will select that item etc).
You can unbind that with oni.input.unbind("<c-g>") in your config.js, which is in the Ctrl+Shift+P menu as User config. That will tell Oni to stop capturing the input and to send it directly to neovim.
If you wanted to rebind sneak to another keybinding, you'd use something like:
    oni.input.bind("<s-c-g>", () => oni.commands.executeCommand("sneak.show"))
Which would bind it to Ctrl+Shift+G etc.

Ah, OK. Thanks for the fast response!

@ha7ilm @CrossR I created a page to document the configurations that make Oni closer to vim: https://github.com/onivim/oni/wiki/How-To:-Make-Oni-closer-to-bare-Vim-experience