Tracing without performance

Continuation from #752

The thing I feel wrong about is that I don't get the traces nested. Am I doing something wrong here?

The thing I feel wrong about is that I don't get the traces nested. Am I doing something wrong here?
The parent span ID is set properly.

@ribice can I see the code to repro this one?

The thing I feel wrong about is that I don't get the traces nested. Am I doing something wrong here?
The parent span ID is set properly.

@ribice can I see the code to repro this one?

https://gist.github.com/ribice/2c583f9c1edc3084d3572e2ea5065419

The thing I feel wrong about is that I don't get the traces nested. Am I doing something wrong here?
The parent span ID is set properly.

@ribice can I see the code to repro this one?

https://gist.github.com/ribice/2c583f9c1edc3084d3572e2ea5065419

I think your sentry.ContinueTrace is conflicting with the ones from here on the sentryhttp middleware
https://github.com/getsentry/sentry-go/blob/9f80641c4ca2b23ee254170e164556cf91e4ef07/http/sentryhttp.go#L113-L122
The sentry.ContinueFromRequest should acquire the Sentry-related headers and append it to the span options. Try to remove that part from the middleware and see if everything works, maybe?

Got time to finally come back to this, made a repro on Nodejs, nothing wrong about it not being nested. But I wonder why it got the same parent span id though. It should only got 2-3 captured events

Repro https://gist.github.com/aldy505/90354abc6877071dec601c8ddabca092

Hmm, seems you're right. Capturing it first time works properly (same as in node snippet above), but every subsequent request appends to that trace which is weird. I'll investigate now.
First:

Second:

I was able to resolve it by creating a new Scope/Hub in every request. This way it generates new traceID/spanID.
https://gist.github.com/ribice/2c583f9c1edc3084d3572e2ea5065419 (service1-updated.go).
Not sure if this is the intended way.

On the JS SDK, the ContinueTrace is a function that accepts a callback. I think on the callback, it creates a new scope internally, Not sure if this should also be done on Go though.


refactor: better usage of fragment_cache

After have a close look at https://github.com/hexojs/hexo/issues/2164, I have realized something.
Although configuration file (both site's _config.yml and theme's _config.yml) is loaded only once, but the value has to be readed from parsed config (inside Locals) every time when meets in layout. So it is important to wrap config value inside fragment_cache.
I have ran through a benchmark with same setup I used in https://github.com/hexojs/hexo/issues/3663. Before https://github.com/hexojs/hexo-theme-landscape/pull/152/commits/c8d5d1628711a7d4bc8646becd9c4e58498ddfed, is takes about 6.16 seconds to generate a site with 300 posts, After https://github.com/hexojs/hexo-theme-landscape/pull/152/commits/c8d5d1628711a7d4bc8646becd9c4e58498ddfed, it drops to about 5.9 seconds, which is about 4% less.
This PR is a PoC that we should wrap <%= config.xxx %> or <%= theme.xxx %> inside fragment_cache as much as possible.

Is it ready to merge?

Fragment Cache is not the best way to do this. We need to use a lower-level of caching.


fix: upgrade to version 3.0.737

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign abayer
You can assign the PR to them by writing /assign @abayer in a comment when ready.
The full list of commands accepted by this bot can be found 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

/approve

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: rawlingsj
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 [rawlingsj]

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

@jenkins-x-bot-test: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

vault
706b0583003d71b52c28032057a09ff327ff4769
link
/test vault

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jenkins-x-bot-test: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

vault
706b0583003d71b52c28032057a09ff327ff4769
link
/test vault

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jenkins-x-bot-test: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

vault
706b0583003d71b52c28032057a09ff327ff4769
link
/test vault

gsm
706b0583003d71b52c28032057a09ff327ff4769
link
/test gsm

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jenkins-x-bot-test: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

vault
706b0583003d71b52c28032057a09ff327ff4769
link
/test vault

gsm
706b0583003d71b52c28032057a09ff327ff4769
link
/test gsm

kube
706b0583003d71b52c28032057a09ff327ff4769
link
/test kube

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jenkins-x-bot-test: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

vault
706b0583003d71b52c28032057a09ff327ff4769
link
/test vault

gsm
706b0583003d71b52c28032057a09ff327ff4769
link
/test gsm

kube
706b0583003d71b52c28032057a09ff327ff4769
link
/test kube

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jenkins-x-bot-test: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

vault
706b0583003d71b52c28032057a09ff327ff4769
link
/test vault

kube
706b0583003d71b52c28032057a09ff327ff4769
link
/test kube

gsm
706b0583003d71b52c28032057a09ff327ff4769
link
/test gsm

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

/retest

@jenkins-x-bot-test: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

vault
706b0583003d71b52c28032057a09ff327ff4769
link
/test vault

kube
706b0583003d71b52c28032057a09ff327ff4769
link
/test kube

gsm
706b0583003d71b52c28032057a09ff327ff4769
link
/test gsm

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jenkins-x-bot-test: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

kube
706b0583003d71b52c28032057a09ff327ff4769
link
/test kube

gsm
706b0583003d71b52c28032057a09ff327ff4769
link
/test gsm

vault
706b0583003d71b52c28032057a09ff327ff4769
link
/test vault

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jenkins-x-bot-test: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gsm
706b0583003d71b52c28032057a09ff327ff4769
link
/test gsm

vault
706b0583003d71b52c28032057a09ff327ff4769
link
/test vault

kube
706b0583003d71b52c28032057a09ff327ff4769
link
/test kube

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

/retest

@jenkins-x-bot-test: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gsm
706b0583003d71b52c28032057a09ff327ff4769
link
/test gsm

kube
706b0583003d71b52c28032057a09ff327ff4769
link
/test kube

vault
706b0583003d71b52c28032057a09ff327ff4769
link
/test vault

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jenkins-x-bot-test: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

kube
706b0583003d71b52c28032057a09ff327ff4769
link
/test kube

vault
706b0583003d71b52c28032057a09ff327ff4769
link
/test vault

gsm
706b0583003d71b52c28032057a09ff327ff4769
link
/test gsm

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

GraphQL error: Could not clone: Name already exists on this account


Provide a meaningful issue title

Provide a detailed explanation of the issue in English.

Error 200: The Power BI Desktop Analysis Services instance does not contain any databases. Try to connect to the report using the Bravo icon in the External Tools of Power BI Desktop.
Version: 0.9.0 (0.9.8121.26944)

Can you describe the action you performed to see this error? Thanks!

The error explains what you are trying to do - did you try to connect Bravo to an empty PBIX file, or to a PBIX report connected to an external dataset?

This should be fixed with version 0.9.2, feel free to reopen if the issue still exists.


testWorkflowDefJson failure on dev and master branches

We are trying to contribute conductor project but testWorkflowDefJson test fails without interacting to our code. After running the master branch we found out that it fails either way(both on dev and master branches). Can you fix this problem? Test is on SubWorkflowParamsTest.java class.

Thank you @azb96. This test failure is causing the build to fail.

Thank you @azb96. This test failure is causing the build to fail.

@mehmet-islamoglu @azb96 I couldn't reproduce this. I've also merged one of your PR's, for which the build has passed in both the branch and devint. I'm closing this, but please feel free to re-open this issue, if you continue to see this.

@mehmet-islamoglu @azb96 I couldn't reproduce this. I've also merged one of your PR's, for which the build has passed in both the branch and devint. I'm closing this, but please feel free to re-open this issue, if you continue to see this.


Reduce potential merge conflicts

This PR makes some significant changes to the repository. With these changes, the code in the repository will no longer compile, and it will also not define an R package. Instead, there is now an R script (module_library_setup.R) that will generate a few missing module-library-specific files for a user. Instructions can be found in README_skeleton.md. With the script, a user only needs to specify the new package name once.
There are a few things I am a little unsure about, and I think @gsrohde and @justinmcgrath probably know more about them than me.

One point is that I made the customization script using R code. This seemed like a decent choice to me, since it should work on any operating system, and presumably any potential users of the skeleton package will know how to run an R script. At minimum, they will have R installed. Nevertheless, maybe there is a better way to implement this script.
The other point is that I needed to define two C macros: R_PACKAGE_NAME and R_INIT_FUNC. It seems like it should be possible to generate R_INIT_FUNC from R_PACKAGE_NAME, but I don't know how to do it. I'm not very familiar with preprocessor directives.
Is there a reason to have an R-package-style DESCRIPTION file for the skeleton repository? It would be nice to have something that clearly specifies the authors, but it doesn't have to be done the same way as in DESCRIPTION_skeleton. I left it in the repository as-is, but maybe it could be improved.

While working on this, I realized a few other advantages of having an incomplete R package and a customization script:

Any forked / customized package derived from this one will include a record of the version of skelBML that was used (via DESCRIPTION_skeleton and NEWS_skeleton.md), as long as the new package maintainer doesn't delete them.
It should be possible to enable other customizations in the future if they become necessary; we can just modify module_library_setup.R and any package maintainers can rerun it.

Yufeng sent a link earlier that seems to indicate that we can't tell the web version to display README_skeleton.md: https://stackoverflow.com/questions/69188881/rename-readme-md-to-custom-name-and-use-as-a-project-description. Maybe there is an order of precendence, so the skeleton repo could have a README and then if a README.md is added, the "fancier" version would be displayed instead? Not sure if this would be confusing, or if it would even work.
Let me know what you think.

Script

A script to create the files that contain the package name seems like a good idea. I think that if they're at the point of making one of these packages, they probably have R. If you wanted to avoid scripts, you could provide the templates and the user could change the names manually.

Macros

I never remember the rules for macro expansion. There's a description here: https://stackoverflow.com/questions/5256313/c-c-macro-string-concatenation. I think this would work.
#define PPCAT_NX(A, B) A ## B
#define PPCAT(A, B) PPCAT_NX(A, B)

#define R_PACKAGE_NAME MyPack
#define R_INIT_FUNC PPCAT(R_init_, R_PACKAGE_NAME)

Then "MyPack" is only in one place in that file, but since a script is writing this, what you have also seems fine since there's already a single place that the name gets entered.
I think it would make more sense to use include guards around the entire file as is typically done with header files, rather than having guards around each definition.

DESCRIPTION file

A file is probably useful, but what's in it could be confusing if people keep it. Maybe it could be written in the past tense, like "This library was created from skelBML ...", but then it's kind of confusing in the skelBML repository.
I can't think of anything for the README. Maybe this would help overall? https://docs.github.com/en/repositories/creating-and-managing-repositories/creating-a-template-repository

I don't know whether the include guards in module_library should be package specific. If someone wanted to compile this into a single C++ program, rather than talking through R, it wouldn't work with the new changes.

I don't know whether the include guards in module_library should be package specific. If someone wanted to compile this into a single C++ program, rather than talking through R, it wouldn't work with the new changes.

I was a bit unsure about this. I didn't think I would be able to define the header guard with macros, so I just set it to something more generic. However, now I see that the startup script could probably generate module_library.h with a package-specific header guard since it's a pretty small file. On the other hand...
I think it would be possible for a C++ user to compile the modules as a dynamic library, and then include that library with their other code. I think in that case the header guard wouldn't matter anymore. Even with a package-specific header guard, I think there would be other issues with trying to compile multiple module libraries in one C++ project because each project would want to have its own definition of the R_PACKAGE_NAME macro. If the libraries end up using the same value of R_PACKAGE_NAME and each have a module with the same base name, the module classes will no longer be properly namespaced.

I'm not sure what all it would entail. It could probably be done with macros, and I suspect the R_PACKAGE_NAME macro wouldn't be an issue since each library would include only one package name header file. With dynamic or static linking to compiled libraries, I think there'd need to be header files to know what functions are in the library, and then it's back to conflicts. However, since there are no plans for this, and someone would need to try it to sort out the details, there's no point implementing guesses. If it creates conflicts later, we can rethink things.

I'm still looking at this, but for what it's worth, in case you haven't read this already, here's the GitHub scoop on READMEs: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-readmes

Yufeng sent a link earlier that seems to indicate that we can't tell the web version to display README_skeleton.md: https://stackoverflow.com/questions/69188881/rename-readme-md-to-custom-name-and-use-as-a-project-description. Maybe there is an order of precendence, so the skeleton repo could have a README and then if a README.md is added, the "fancier" version would be displayed instead? Not sure if this would be confusing, or if it would even work.

Regarding this specific question:
It is possible to have a plain README in the top-level directory, which will get rendered on GitHub if README.md doesn't exist.  The problem with this solution is that any Markdown in the plain README won't be rendered as Markdown.
A better solution might be to use docs/README.md for biocro/skelBML's README.  The user browsing to the biocro/skelML repository will see this on the repository home page.  (They definitely should see some information on the home page so they know what the repository is about.)  The user fleshing out the skeleton can then override this by supplying a top-level README.md file, which will then be given precedence by GitHub.
Another possible solution might be to use a plain README for biocro/skelBML which simply tells the user to browse to some Markdown file (INFO.md?) which contains the real information.  Again, the user fleshing out the skeleton would supply their own README.md file to override this and give information about their package.

Yufeng sent a link earlier that seems to indicate that we can't tell the web version to display README_skeleton.md: https://stackoverflow.com/questions/69188881/rename-readme-md-to-custom-name-and-use-as-a-project-description. Maybe there is an order of precendence, so the skeleton repo could have a README and then if a README.md is added, the "fancier" version would be displayed instead? Not sure if this would be confusing, or if it would even work.

Regarding this specific question:
It is possible to have a plain README in the top-level directory, which will get rendered on GitHub if README.md doesn't exist. The problem with this solution is that any Markdown in the plain README won't be rendered as Markdown.
A better solution might be to use docs/README.md for biocro/skelBML's README. The user browsing to the biocro/skelML repository will see this on the repository home page. (They definitely should see some information on the home page so they know what the repository is about.) The user fleshing out the skeleton can then override this by supplying a top-level README.md file, which will then be given precedence by GitHub.
Another possible solution might be to use a plain README for biocro/skelBML which simply tells the user to browse to some Markdown file (INFO.md?) which contains the real information. Again, the user fleshing out the skeleton would supply their own README.md file to override this and give information about their package.

I like the docs/README.md option. I think it's nicer than the first option you mentioned because we can still use markdown for it. And it's easier for a user than the third option since the user doesn't need to follow a link. The startup script will automatically produce a top-level README.md for the new package that will be displayed instead of the skeleton README.md.

There would be conflicts with the package name file since that's included in module_library.h, and it can't be included in the namespace, since the namespace name comes from the package name. A program would need to include module_library.h from each library, so the package names would conflict. I think the only solution is defining unique names for the include guards in that file.

I modified the startup script so it now uses package-specific header guards in src/module_library/module_library.h and src/R_PACKAGE_NAME.h. I also changed R_PACKAGE_NAME.h to only use one guard around the entire file as you suggested.

I modified DESCRIPTION_skeleton so it doesn't look exactly like an R package DESCRIPTION file. I also referenced it in the auto-generated README.md to indicate that it describes the skeleton module library, not whatever new library was forked from it. While doing this, I also realized that we should probably have a separate license file for the skeleton library in case the new package uses a different license. (Although that would be difficult to do with our current GPL license.)

One point is that I made the customization script using R code. This seemed like a decent choice to me, since it should work on any operating system, and presumably any potential users of the skeleton package will know how to run an R script. At minimum, they will have R installed. Nevertheless, maybe there is a better way to implement this script.

I agree that for portability reasons, R scripts are the way to go. But because I hate having to drop into an R session just to run a script (and because I enjoy writing scripts), I made a revised script that is runnable either using Rscript or in R using source. I put it on the branch revised_script for your perusal. It would have been considerably simpler to have it be "command line only", but I was afraid you'd balk at my taking away the ability to run it using source, plus I enjoy a challenge. (Also, I'm not absolutely sure that the code to make the script interactive when run from the command line works in Windows. Perhaps you can test this.)

Thanks, this is very nice. It seems easier to maintain and update than my version, and more robust. I tried running the script from the command line in Windows, and it worked for me without any issues.
I'm glad you didn't take away the ability to run the script with source. In the interest of accessibility, I would prefer to make minimal assumptions about what the user is familiar with. We are require some degree of familiarity with R in order to use BioCro, so it's nice to have an option that doesn't require any additional familiarity with running things from the command line outside of R. I think many Windows users (such as myself) don't use the command line very often and would find it more natural to stay inside R.

Note that this script is based on the version of things before your latest changes. I didn't want to spend any more time on it before getting some feedback.

I can work on updating it to accommodate the more recent changes to this branch.

Note also that I enforce some rules on package names that you don't.

I think these new rules are helpful. However, they need to be changed a little:

We should not allow periods in the package name. They are permissible in R package names, but not in R packages that use C code with registered routines. For such packages, there must be a C function called R_init_NAME, where NAME must exactly match the name of the R package. (See src/init.cpp.) If there is a period in NAME, this will not be a valid C function name, and the package will not compile. I tested this out and confirmed that periods are a problem.
The name length limit needs to be 7 characters. If it is any longer, R CMD check will complain about path lengths that exceed the limit for tarballs. This is due to the presence of the boost library. I think it is also helpful to explain why this limit is in place, rather than just saying "overly long names are not recommended."

The script also removes all of the complicated cobbling together of strings in favor of using template files, where the user-supplied package name is simply plugged in at the appropriate places. This seems much clearer and much more maintainable to me.

This is great!

And just to prove that it can be done, I use C macros to define the init function from the package name. But I strongly recommend avoiding the use of C macros (except for header guards), and simply revising the script to write all files that depend on the package name. This recommendation I base on what Bjarne Stroustrup (the creator of C++) has to say about them:

Macros are very important in C but have far fewer uses in C++. The first rule about macros is: don’t use them unless you have to. Almost every macro demonstrates a flaw in the programming language, in the program, or in the programmer. Because they rearrange the program text before the compiler proper sees it, macros are also a major problem for many programming support tools. So when you use macros, you should expect inferior service from tools such as debuggers, cross-reference tools, and profilers. If you must use macros, please read the reference manual for your own implementation of the C++ preprocessor carefully and try not to be too clever. Also, to warn readers, follow the convention to name macros using lots of capital letters.

[Stroustrup, Bjarne. The C++ Programming Language . Pearson Education. Kindle Edition. ]

The original reason to use macros was to reduce the number of times the user needed to type the package name. But, as you point out, the startup script makes this less important, since the user only needs to type the name once regardless of how many times it is used throughout the package source code.
There may be other benefits of using macros though. For example, suppose we make a change to src/R_module_library.cpp in the skeleton module library repository, perhaps to the R_get_all_modules function's internal code. How will maintainers of other module library packages update their repositories to include the changes? If src/R_module_library.cpp uses a macro to specify the library (via using library = R_PACKAGE_NAME::module_library;), then maintainers just need to use git to update R_module_library.cpp to the latest version. If instead R_module_library.cpp is generated from a template via the script and has a hard-coded package name (like using library = myLib::module_library;), then maintainers will need to use git to get the latest version of the template and then re-run the startup script to update their repositories.
Maybe the extra step when updating isn't a big deal, and it might be better to avoid the macros. It's good to consider all the angles, though.

I agree that for portability reasons, R scripts are the way to go. But because I hate having to drop into an R session just to run a script (and because I enjoy writing scripts), I made a revised script that is runnable either using Rscript or in R using source. I put it on the branch revised_script for your perusal. It would have been considerably simpler to have it be "command line only", but I was afraid you'd balk at my taking away the ability to run it using source, plus I enjoy a challenge. (Also, I'm not absolutely sure that the code to make the script interactive when run from the command line works in Windows. Perhaps you can test this.)

This is nice. I have only the smallest of comments, which is that I like to front-load branches, so I might have done this instead somewhere at the top level.
smartReadLines <- if (interactive()) {
    readline
} else {
    function() {
        input <- file("stdin")
        answer <- readLines(input, 1)
        on.exit(close(input))
        return(answer)
    }
}

I like to front-load branches

What does this mean?

I think these new rules are helpful. However, they need to be changed a little

Since the restriction on periods and the length limit are hard-and-fast rules, that will simplify things—we can get rid of the run_addl_checks function, which I didn't like much anyway.

I added a version of Scott's script to this branch, where I updated it to include the recent changes I made here. It still uses C macros and the run_addl_checks function, though, so it's probably not final.

The name length limit needs to be 7 characters. If it is any longer, R CMD check will complain about path lengths that exceed the limit for tarballs. This is due to the presence of the boost library. I think it is also helpful to explain why this limit is in place, rather than just saying "overly long names are not recommended."

I didn't understand that the 7-character limit was due to the problem with long path names and couldn't understand why you were being so restrictive when many CRAN packages have considerably longer names.
It sure would be nice not to have to include the Boost library. I don't remember the reasons given for not just using BH. Maybe it doesn't include all of portions of the library that we need?

If BH is used instead of Boost, then compiling with SimRoot won't work. Would it help to change 'boost_1_71_0' to something shorter, or are only the paths under that the problem? We could call it 'include' and include the version number in a file in that directory.

The name length limit needs to be 7 characters. If it is any longer, R CMD check will complain about path lengths that exceed the limit for tarballs. This is due to the presence of the boost library. I think it is also helpful to explain why this limit is in place, rather than just saying "overly long names are not recommended."

I didn't understand that the 7-character limit was due to the problem with long path names and couldn't understand why you were being so restrictive when many CRAN packages have considerably longer names.
It sure would be nice not to have to include the Boost library. I don't remember the reasons given for not just using BH. Maybe it doesn't include all of portions of the library that we need?

If BH is used instead of Boost, then compiling with SimRoot won't work.

What is SimRoot?

Boost also doesn't guarantee backwards compatibility, so updates could break BioCro.

Is this more true of Boost than, say, R itself, or for that matter, C++ and the other C++ libraries we use?

Would it help to change 'boost_1_71_0' to something shorter, or are only the paths under that the problem? We could call it 'include' and include the version number in a file in that directory.
Possibly the 'boost' directory could be at the top level. I don't remember the details so maybe that's not allowed though.

I'm actually more concerned about needlessly requiring users to have multiple copies of Boost if, say, they are working on multiple BioCro libraries at once.

What is SimRoot?

It's called OpenSimRoot now, and it's a root model that has been coupled with BioCro: https://gitlab.com/rootmodels/OpenSimRoot. Progress is stilted with this project, but people are still pursuing it. R isn't and cannot be used. Thus, BioCro is treated like a library and compiled directly with OpenSimRoot.

Boost also doesn't guarantee backwards compatibility, so updates could break BioCro.

Is this more true of Boost than, say, R itself, or for that matter, C++ and the other C++ libraries we use?

I think backwards compatibility is an unattainable Valhalla, but lots of projects strive for it. It looks like the R authors try to do it, but I haven't seen an official policy. The Boost authors explicitly state that they do not try to maintain backwards compatibility though.

I'm actually more concerned about needlessly requiring users to have multiple copies of Boost if, say, they are working on multiple BioCro libraries at once.

I see libraries as a way to ease code reuse, and making things smaller can be a benefit, but is often not important. BioCro has about 50 MB of Boost files, which is certainly not small, but compared to most software today and the size of hard drives, it's hardly worth considering. If we ever take out Boost Units, it will be a bit smaller. If we want to use one copy, then every BioCro developer would need to do a site-wide installation of Boost, which is tedious. Maintenance and installation are both much easier if the necessary files are packaged with BioCro, and the cost of some hard drive space is very low.
Tangentially, since backwards compatibility is impossible, multiple copies of libraries are the way this has been handled. Windows SXS is an example. I also found this project yesterday that keeps multiple versions of R packages: https://groundhogr.com/. It seems like a good idea, but I tried it and it needs some work.

What is SimRoot?

It's called OpenSimRoot now, and it's a root model that has been coupled with BioCro: https://gitlab.com/rootmodels/OpenSimRoot. Progress is stilted with this project, but people are still pursuing it. R isn't and cannot be used. Thus, BioCro is treated like a library and compiled directly with OpenSimRoot.

Do you mean OpenSimRoot is compiled  with the BioCro.so or BioCro.dll library file, or do you mean "library" in a more general sense—a bunch of source files which must be compiled with the OpenSimRoot source files (similar to the way one must use the Boost library)?  I'm guessing the latter, since with the former, Boost is already included, so it's not an issue.  I guess I don't really understand the issue here.

Boost also doesn't guarantee backwards compatibility, so updates could break BioCro.

Is this more true of Boost than, say, R itself, or for that matter, C++ and the other C++ libraries we use?

I think backwards compatibility is an unattainable Valhalla,

[and considering what happened to Valhalla, one probably wouldn't want to attain it in any case :).]

but lots of projects strive for it. It looks like the R authors try to do it, but I haven't seen an official policy. The Boost authors explicitly state that they do not try to maintain backwards compatibility though.

What they actually say, if we're reading from the same place, is "backward compatibility with prior version [sic] isn't always possible," something which is, if software vendors were being honest, generally the case.  "Isn't always possible" at least suggests that they do try for it when it is possible.
Still, they do take pains to say "Deal with this by freezing the version of the Boost libraries used by your project. Only upgrade at points in your project's life cycle where a bit of change will not cause problems", which suggests maybe you are right to be cautious.
Since the maintainer of BH is associated with the tinyverse (as opposed to tidyverse) initiative, you would think he would be particularly aware of and sensitive to dependency and versioning concerns.  Perhaps I'll get in touch with him—perhaps he has a solution to this problem that I haven't considered.
(The only solution that occurred to me was forking a release of BH corresponding to a suitable release of Boost, then renaming the package to include the version number (so if users already have a copy of BH, there wouldn't be a conflict), and making it publicly available.  It seems unlikely we could put such a package on CRAN, though, and if you complained that this solution was a tad messy, I'd probably have to agree.)

I'm actually more concerned about needlessly requiring users to have multiple copies of Boost if, say, they are working on multiple BioCro libraries at once.

I see libraries as a way to ease code reuse, and making things smaller can be a benefit, but is often not important. BioCro has about 50 MB of Boost files, which is certainly not small, but compared to most software today and the size of hard drives, it's hardly worth considering. If we ever take out Boost Units, it will be a bit smaller. If we want to use one copy, then every BioCro developer would need to do a site-wide installation of Boost, which is tedious.

Are you speaking from the perspective of a developer who is not using R?  In R, all one has to do is install.packages('BH') , and it just works (assuming that after removing Boost from BioCro source we add BH to the DESCRIPTION file's LinkingTo field).

I will probably have something to say about this boost discussion later, but for now, can we pause this discussion or move it elsewhere? Let's not allow it to derail this PR, since 99% of it is independent of how the boost library is accessed.

I will probably have something to say about this boost discussion later, but for now, can we pause this discussion or move it elsewhere? Let's not allow it to derail this PR, since 99% of it is independent of how the boost library is accessed.

I've made an issue for it.

I modified the startup script so it now uses package-specific header guards in src/module_library/module_library.h and src/R_PACKAGE_NAME.h.

Have you checked that this actually does what you want it to?
I seem to remember there being problems with compiling multiple libraries together, and using unique header guards didn't solve the problem.  But I may be misremembering, or maybe this was only a problem with a previous version of the code and it has changed in such a way that this is no longer an issue.
In any case, I recommend not using package-specific header guards unless they actually serve the purpose you intend, even though they may otherwise be harmless.  Going against the filename.h --> FILENAME_H convention is confusing and misleading unless it is actually serving some useful purpose.

I also found this project yesterday that keeps multiple versions of R packages: https://groundhogr.com/. It seems like a good idea, but I tried it and it needs some work.

My impression is that renv is more mature and thus likely more reliable.  But as @eloch216 suggested, further discussion of this can go elsewhere.

I modified the startup script so it now uses package-specific header guards in src/module_library/module_library.h and src/R_PACKAGE_NAME.h.

Have you checked that this actually does what you want it to?
I seem to remember there being problems with compiling multiple libraries together, and using unique header guards didn't solve the problem. But I may be misremembering, or maybe this was only a problem with a previous version of the code and it has changed in such a way that this is no longer an issue.
In any case, I recommend not using package-specific header guards unless they actually serve the purpose you intend, even though they may otherwise be harmless. Going against the filename.h --> FILENAME_H convention is confusing and misleading unless it is actually serving some useful purpose.

I think it's not so unusual to include the name of a namespace in a header guard to better ensure that it is unique to that file: https://softwareengineering.stackexchange.com/questions/330987/namespaces-and-header-guards-with-naming-conflicts

I think it's not so unusual to include the name of a namespace in a header guard to better ensure that it is unique to that file: https://softwareengineering.stackexchange.com/questions/330987/namespaces-and-header-guards-with-naming-conflicts

Remind me—does one need to use this header file in order to use a corresponding BioCro library's .dll or .so file?  Is the the only header file needed (per library)?  And is this only needed when one is working in C++ directly rather than via the R interface?  Did we get this working smoothly?

Remind me—does one need to use this header file in order to use a corresponding BioCro library's .dll or .so file? Is the the only header file needed (per library)? And is this only needed when one is working in C++ directly rather than via the R interface? Did we get this working smoothly?

Here is my understanding of the situation:

For an R package that defines a single module library, the considerations are pretty simple. In that case, it's just necessary to have header guards that are unique within the src directory. It's not even necessary to have the modules and library inside a namespace. Then an R user can access multiple module libraries via the R package for each library. I think this problem is sufficiently solved.
These questions about header guards and namespaces are relevant for a C++ user who wants to use modules from multiple libraries. In this case I think there are two strategies for doing it.

One is to separately compile each library into its own .dll or .so file, and link to those in a C++ project. In this case, I think each module library (and its associated module classes) needs to be in its own namespace. But header guards probably only need to be unique within each module library.
The other is to include all the files from each module library and compile it once as a single C++ project. In this case, I think each module library must be namespaced, and the header guards need to be unique across the project as a whole.
In both of these scenarios, the R-specific functions in R_module_library.h, R_module_library.cpp, and init.cpp will not be used for anything.

We would like for all of these scenarios to be possible, so I was thinking it would be good to have unique header guards for files in src/module_library that include the namespace name.

Following Scott's earlier comments, I changed the script again to generate files that no longer use C macros or the R package name string. Instead, these things are now hard-coded. I also used header guards that include the namespace in a few places. One possible downside is that module_library.cpp is now created by the script from a template, so if a module library repository maintainer needs to rerun the script following changes to the skeleton library, their module table will get overwritten.

I'm not sure about putting boost at the top level. I have a hazy recollection of trying it and running into some problem, but I don't remember what it was.

For what it's worth—and I probably should have done so sooner—I tried this out, and I didn't have any problem.  I tried it in two different ways, and they both worked.
The first was simply to change the PKG_CPPFLAGS line in the Makevars files to read
PKG_CPPFLAGS+=-I.. -DR_NO_REMAP

after renaming inc/boost to boost.  I was somewhat dubious about making the top-level BioCro directory an include directory, but it didn't really seem to be a problem.
The second way was to change the PKG_CPPFLAGS line to read
PKG_CPPFLAGS+=-I../boost -DR_NO_REMAP

and then change all the includes of the form
#include <boost/[subdirs]/[boostfile].hpp>

to
#include <[subdirs]/[boostfile].hpp>

At first this seemed like a better solution, but then I decided that there is some documentary value in having "boost" in the #include path, and for this reason I don't really like this solution.
I'm not advocating changing anything, just showing that we could.

One is to separately compile each library into its own .dll or .so file, and link to those in a C++ project. In this case, I think each module library (and its associated module classes) needs to be in its own namespace. But header guards probably only need to be unique within each module library.
The other is to include all the files from each module library and compile it once as a single C++ project. In this case, I think each module library must be namespaced, and the header guards need to be unique across the project as a whole.

The conclusion is the same, but I thought I'd point out that even is a library is dynamically linked, you include a header file for it, so the header guards need to be unique in both of these  cases.

For what it's worth—and I probably should have done so sooner—I tried this out, and I didn't have any problem. I tried it in two different ways, and they both worked.

I agree that not having "boost" in the include path doesn't seem great. I'm also not sure what I think about including the entire directory. It's not an ideal way to organize things. There's probably a compile-time cost, but I think it's negligible. It does seem that the benefit of handling longer path names outweighs the odd organization.

Maybe this is too complicated, but there is probably a way to avoid overwriting the user modified module_library.cpp. All of the include directives would need to be in a separate file, and the table of modules would be in a separate file. Then module_library.cpp would look something like this:
#include "module_library.h"
#include "../framework/module_creator.h"  // for create_mc

// Include all the header files that define the modules.
#include "user_defined_list_of_module_headers.h"

creator_map %1$s::module_library::library_entries =
{
    #include "user_defined_module_table.h"
};

I don't love this, but maybe it sparks some better ideas from someone else.

Maybe the parts that are generated could be surrounded with some identifying comments. Then the script would only modify those places. Instead of replacing %1$s in the namespace, it would write the entire line.
// HEADER_START. Do not modify this comment. It's needed to automatically propagate updates.
// Do not modify anything between HEADER_START and HEADER_END, as changes will be removed when updating.
#include "module_library.h"
#include "../framework/module_creator.h"  // for create_mc
// HEADER_END. Do not modify this comment. It's needed to automatically propagate updates.

// Include all the header files that define the modules.
#include "example_module.h"

// NAMESPACE_START. Do not modify this comment. It's needed to automatically propagate updates.
// Do not modify anything between NAMESPACE_START and NAMESPACE_END, as changes will be removed when updating.
creator_map package_name::module_library::library_entries =
// NAMESPACE_END. Do not modify this comment. It's needed to automatically propagate updates.
{
    {"example_module", &create_mc<example_module>}
};

This seems a little better than separate files, but I still don't love it.

Maybe this is too complicated, but there is probably a way to avoid overwriting the user modified module_library.cpp.

As of now, the script backs up any existing version of the file if it differs from what would be written by the script.  I think this is good enough for now—I don't think it imposes too big of a burden on the user to require merging in anything from the backup they may want to keep.  If you come up with an alternative solution you really do love, then maybe we can revisit this.


Made a hat

Description
tried making a hat
Fixes #47
Insert the image of the art below

Checklist:
To fill the checklists, put x inside the brackets. [x]

[x] My code follows the guidelines of this project
[x] I have tested my code and it works properly
[x] I have added just one folder that includes my Art files (jsx and css)
[x] I have not edited App.js file
[] I have commented my code, particularly in hard-to-understand areas
[x] My changes generate no new warnings
[x] This is my original code and I have NOT copied the code from anywhere else.

Hi. Why were you not able to check the art? Need any help with it?

I am new to github so i got confused. Do i have to make another PR?

Good job @apoorva567


Different CompletionItemKind value during test run

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

VS Code Version: 1.68.1
OS Version: macOS 12.4

Steps to Reproduce:

Generate a completion list using kind CompletionItemKind.Value.
Write a test case expecting kind CompletionItemKind.Value.

We are testing our language server protocol extension. The kind's value is coming back as value 11 instead of the expected 12, even though the stringified completion item shows Value.
      console.log(JSON.stringify(actualItem));
      console.log(JSON.stringify(actualItem.kind?.valueOf()));

{"label":"$workitem.bp-iks-vpc-gen2-cluster.outputs.cluster_id","kind":"Value","detail":"Module-level output","documentation":{},"sortText":"10001","preselect":true,"insertText":"$workitem.bp-iks-vpc-gen2-cluster.outputs.cluster_id"}
11

In the test cases, the import is
import { CompletionItemKind } from "vscode-languageclient";

However, the LSP uses import vscode-languageserver/node. Are these kind values different in each import?

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.68.1. Please try upgrading to the latest version and checking whether this issue remains.
Happy Coding!

Sorry, can you provide a more minimal, yet complete, sample?

Figured it out... using this import { CompletionItemKind } from "vscode-languageclient"; results in a different value for the kind as opposed to import { CompletionItemKind } from "vscode-languageclient";. Perhaps these should be in sync.

Perhaps these should be in sync.

I generally like that idea but the challenge is that vscode-dts cannot change (since we don't break the API) and LSP does this on purpose to avoid enums starting offset zero.
fyi @dbaeumer


Update classpathCmd for the static value retriever

Default classpath command doesn't work for Dragonfly because the pom.xml is in src/supernode.

I find this a bit fiddly. Wouldn't it be better to have a way to tell platform where to run these commands?

(sorry I didn't mean to close the PR, my aim is rubbish)


Persisting Parallel State Machines Fails

Description
I'm trying to repeatedly externally step a parallel state machine with persistence.  I have set up a simple linear machine that goes a -> b -> c -> d and notes entry and exit.
The base machine is
    states: {
      a: {
        entry: ["doEntry"],
        exit: ["doExit"],
        on: { TRIGGER: { target: "b" } }
      },
      b: {
        entry: ["doEntry"],
        exit: ["doExit"],
        on: { TRIGGER: { target: "c" } }
      },
      c: {
        entry: ["doEntry"],
        exit: ["doExit"],
        on: { TRIGGER: { target: "d" } }
      },
      d: { type: "final" }
    }

In the code sandbox I set up 4 tests.
I create a parallel machine which uses two instance of the base machine.

Simple Linear works as expected.
Simple Parallel also works as expected.  You see two entrys to a, two exits of a.. etc
Step Linear Works, but complains about Warning: No implementation found for action type
I would like to know why that is the case, but the output looks correct
Step Parallel does not work.

For quick reference, the serialize/deserialize code is snipped below:
function step(machine, jsonState) {
  const service = interpret(machine);

  if (jsonState === null) {
    service.start();
  } else {
    var restoredState = State.create(JSON.parse(jsonState));
    service.start(restoredState);
    service.send("TRIGGER");
  }

  var retVal = JSON.stringify(service.state);
  service.stop();
  return retVal;
}

function parallelStepTest (machine) {
  console.log('start')
  jsonState.b = step(machine, null)
  console.log('step 1')
  jsonState.c = step(machine, jsonState.b)
  console.log('step 2')
  jsonState.d = step(machine, jsonState.c)
}

Expected Result
Step Parallel
start
entry a
entry a
step 1
exit a
exit a
entry b
entry b
step 2
exit b
exit b
entry c
entry c
step 3
exit c
exit c

Actual Result
Step Parallel
start
entry a
entry a
step 1
entry a
entry a
exit a
entry b
exit a
entry b
step 2
step 3

Reproduction

https://codesandbox.io/s/xstate-parallel-machine-persist-cmh7k

Additional context

Just a quick question so I get a better understanding of the reported issue - you want to rehydrate your child machines' states, right?

Hello @Andarist, thanks for following up.
Yes, I would expect to be able to serialize the complex machine at any state and then resume it at a later point.
Thanks for the tip there.  I didn't realize that capturing the state of a machine wouldn't include the child states.  I would expect it would do so.  Is there a case where you might want to save a parent state without capturing the child states?
Either way, I will investigate recursively descending into child properties to save/restore state.  If you or anyone else has an example of this, I would appreciate it very much.
Thanks again!

Has anyone successfully achieved this?  I'm having a lot of trouble restoring child states correctly.
I created a new version of the code sandbox which captures the issue I'm having here:
https://codesandbox.io/s/xstate-parallel-machine-persist-ktjtw
It appears to correctly restore the state for step 1.. however on step 2 and further it hits
console.log('no service for ' + name) because the call to  service.start(resolvedState) does not create the service.children map.
If anyone has a simple example of recursive machine re-hydration, or a suggestion as to why service.start isn't creating the children I'd greatly appreciate it.
Thanks.

Any updates on how to persist/restore whole state of complex machine, including states of children sub machines?

Would love to hear the recommended approach as well.

I have to write official docs on this, but you would want to use an event sourcing pattern: https://github.com/davidkpiano/xstate/discussions/1217#discussioncomment-23219

@davidkpiano by event sourcing do you mean replaying each event in the machine's history on top of the starting state?
The use case I'm building for will have hundreds and probably into the thousands of events with many side-effects to calculate subsequent contexts, as well as dozens of sub machines in a complex hierarchy. I feel an event sourcing pattern, if I'm understanding it correctly, would be very slow for such a machine once the history builds up.

The use case I'm building for will have hundreds and probably into the thousands of events with many side-effects to calculate subsequent contexts, as well as dozens of sub machines in a complex hierarchy. I feel an event sourcing pattern, if I'm understanding it correctly, would be very slow for such a machine once the history builds up.

This is a good concern; a lot of event-sourcing tools today have snapshotting for that reason, where instead of replaying e.g., 1000 events, you would replay a snapshot of the first 900 events + the remaining 100 events.
Still trying to figure this out, and because of how actors are being simplified in v5, it's likely that this will be a v5 feature.

Snapshotting, that's an interesting idea.
I'm persisting the state in the onTransition event, so if there was an easy way to hook into that event on the child services as well, then we'd at least be able to persist the children manually. Similarly, restoring state occurs when starting the services, so an interface for accessing the child services would help there as well.
I'm looking into using the existing invoke interface to achieve something similar, for example directly providing an instance of Interpreter to invoke a child service. If that is possible, then the above would be doable already. I'll be trying that and a few other things out in the next wee while.

I have to write official docs on this, but you would want to use an event sourcing pattern: #1217 (comment)

Thanks David, Event sourcing fails when you have some details you persisted in context through user journey. it may be solved if we save complete event object which contains type and its payload content for transition, there also happens to scenario where we don't want to persist some specific event payloads e.g global error messages which are handled from context and they are removed after number of seconds, if we use event sourcing technique it will populate context again with the error payload.
also i notice i often encounter multiple same events logging even after checking state.changed condition

can you brief difference in between (from xstate internal perspectives)
state.changed === true & state.changed !== undefined

state.changed === undefined signifies the initial state.
state.changed === true signifies any changed state after the initial state.

This should be fixed in v5 beta in #3743 - please try it out and let us know if it doesn't work as expected.


Typescript broken in latest release ElementType requires between 0-1 type arguments

Steps to reproduce
yarn install && yarn tsc --skipLibCheck=false
Current behavior
node_modules/@mui/base/Unstable_Popup/Popup.d.ts:13:70 - error TS2707: Generic type 'ElementType' requires between 0 and 1 type arguments.

13 declare const Popup: React.ForwardRefExoticComponent<Omit<PopupProps<React.ElementType<any, keyof React.JSX.IntrinsicElements>>, "ref"> & React.RefAttributes<Element>>;
                                                                        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

node_modules/@mui/material/Popper/Popper.d.ts:46:17 - error TS2707: Generic type 'ElementType' requires between 0 and 1 type arguments.

46     component?: React.ElementType<any, keyof React.JSX.IntrinsicElements> | undefined;
                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

node_modules/@mui/material/Popper/Popper.d.ts:53:16 - error TS2707: Generic type 'ElementType' requires between 0 and 1 type arguments.

53         Root?: React.ElementType<any, keyof React.JSX.IntrinsicElements> | undefined;
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Found 3 errors in 2 files.

Errors  Files
     1  node_modules/@mui/base/Unstable_Popup/Popup.d.ts:13
     2  node_modules/@mui/material/Popper/Popper.d.ts:46

Expected behavior
No typescript errors
Context
looks like this error started from the release yesterday.
Your environment

npx @mui/envinfo
   System:
    OS: macOS 14.2.1
  Binaries:
    Node: 18.16.1 - ~/.nvm/versions/node/v18.16.1/bin/node
    Yarn: 1.22.18 - /opt/homebrew/bin/yarn
    npm: 9.5.1 - ~/.nvm/versions/node/v18.16.1/bin/npm
  Browsers:
    Chrome: 120.0.6099.129
    Edge: 120.0.2210.91
    Safari: 17.2.1
  npmPackages:
    @emotion/react:  11.11.3
    @emotion/styled:  11.11.0
    @mui/base:  5.0.0-beta.30
    @mui/core-downloads-tracker:  5.15.3
    @mui/material:  5.15.3
    @mui/private-theming:  5.15.3
    @mui/styled-engine:  5.15.3
    @mui/system:  5.15.3
    @mui/types:  7.2.12
    @mui/utils:  5.15.3
    @types/react:  17.0.74
    react:  17.0.2
    react-dom:  17.0.2
    typescript: ~5.2.0 => 5.2.2

Search keywords: Typescript tsc GenericType

We're seeing the same issue, and have pinned to @mui/material: "5.15.2" and "@mui/base": "5.0.0-beta.28" as a workaround.
Order ID 72484
`npx @mui/envinfo`

 ```
System:
    OS: macOS 14.2.1
  Binaries:
    Node: 18.15.0 - ~/.nvm/versions/node/v18.15.0/bin/node
    Yarn: 1.22.21 - ~/.nvm/versions/node/v18.15.0/bin/yarn
    npm: 9.5.0 - ~/.nvm/versions/node/v18.15.0/bin/npm
  Browsers:
    Chrome: 120.0.6099.199
    Edge: 120.0.2210.91
    Safari: 17.2.1
  npmPackages:
    @emotion/react:  11.11.1
    @emotion/styled:  11.11.0
    @mui/base:  5.0.0-beta.30
    @mui/core-downloads-tracker:  5.15.3
    @mui/lab:  5.0.0-alpha.159
    @mui/material:  5.15.3
    @mui/private-theming:  5.15.3
    @mui/styled-engine:  5.15.3
    @mui/system:  5.15.3
    @mui/types:  7.2.12
    @mui/utils:  5.15.3
    @mui/x-charts:  6.18.3
    @mui/x-data-grid:  6.18.6
    @mui/x-data-grid-pro:  6.18.6
    @mui/x-date-pickers:  6.18.6
    @mui/x-date-pickers-pro:  6.18.6
    @mui/x-license-pro:  6.10.2
    @types/react: 18.2.42 => 18.2.42
    react: ^18.2.0 => 18.2.0
    react-dom: ^18.2.0 => 18.2.0
    typescript: 5.2.2 => 5.2.2
```

Same here

i have the same problem but just when i build the app in a docker container

Same problem here.

I temporarily bypassed the error by changing <React.ElementType<any, keyof React.JSX.IntrinsicElements> with React.ElementType<any> in Popper and Popup declarations.
React.ElementType is being given two arguments: any and keyof React.JSX.IntrinsicElements. However, React.ElementType is designed to take only one argument or none at all.
In your MUI package, go to the following files :

<EMAIL_ADDRESS>

<EMAIL_ADDRESS>

and update the declarations in both files
This may be related to this PR on  @Types/react :
https://github.com/DefinitelyTyped/DefinitelyTyped/pull/67430

I fixex it updating the typescript.
On Wed, Jan 10, 2024, 18:29 Mohamed Chedli Ben Yaghlane <
@.***> wrote:

I temporarily bypassed the error by changing <React.ElementType<any,
keyof React.JSX.IntrinsicElements> with React.ElementType in Popper
and Popup declarations.
React.ElementType is being given two arguments: any and keyof
React.JSX.IntrinsicElements. However, React.ElementType is designed to take
only one argument or none at all.
In your MUI package, go to the following files :

@.***/material/Popper/Popper.d.ts
@.***/base/Unstable_Popup/Popup.d.ts
and update the declarations in both files
This may be related to this PR on @Types/react :
DefinitelyTyped/DefinitelyTyped#67430
https://github.com/DefinitelyTyped/DefinitelyTyped/pull/67430
—
Reply to this email directly, view it on GitHub
https://github.com/mui/material-ui/issues/40427#issuecomment-1885294809,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKH6DEMKPD76KBPY2D67GCTYN3FWXAVCNFSM6AAAAABBMWXM2CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBVGI4TIOBQHE
.
You are receiving this because you commented.Message ID:
@.***>

@jonystn could you please specify from which version to which version did you update? thanks!

@raphaelbp12
"typescript": "^5.3.3"
"@mui/base": "5.0.0-beta.30",
"@mui/lab": "^5.0.0-alpha.159",
"@mui/material": "^5.15.3",
"@mui/system": "^5.15.3",
"@mui/x-data-grid": "^6.18.6",
"@mui/x-date-pickers": "^6.18.6",
"date-fns": "^2.30.0",
"@date-io/date-fns": "^2.17.0",

As of the current version v5.15.4 the typescript version is already ^5.3.3: https://github.com/mui/material-ui/blob/v5.15.4/package.json#L182
However we also changed the package manager to pnpm... does pnpm tsc work for anyone?

Same problem here. Workaround not working. I get this error after enabled techdoc mermaid addon.

Also with the same issue!

Likewise.

Hi, some information regarding this topic?

Any updates on this issue? Running yarn tsc in our projects pre-commit is causing pre-commit to consistently fail and no work-around has solved the problem for us.

Hi, not being able to find a solution. Is there any idea how to solve this?

@raphaelbp12 This worked for me as a temporary fix. Hopefully mui will resolve the issue soon.

The workaround targeting older versions of @mui/material & @mui/base isn't working for me

I couldn't reproduce this, here were my steps:

Cloned this example repo https://github.com/mui/material-ui/tree/master/examples/material-ui-vite-ts (all deps have versions set to 'latest')
yarn install (using yarn v1.22.19)
No issues:

[ 2024-Mar-14 17:44:05 ][ ~/../mui/material-ui-vite-ts ]
$ yarn tsc --skipLibCheck false
yarn run v1.22.19
$ /Users/mj12albert/mui/material-ui-vite-ts/node_modules/.bin/tsc --skipLibCheck false
✨  Done in 4.38s.

Update: Downgrading @mui/x-data-grid to version 6.19.1" helped resolved the types issue

This issue happens to start at<EMAIL_ADDRESS>- type ElementType<P = any> =
+ type ElementType<P = any, Tag extends keyof JSX.IntrinsicElements = keyof JSX.IntrinsicElements> =

I wonder why our build process replaces the use of declared PopperProps with its value.
See the implementation:
type PopperProps = Omit<BasePopperProps, 'direction'> & {
  /**
   * The component used for the root node.
   * Either a string to use a HTML element or a component.
   */
  component?: React.ElementType;
  /**
   * The components used for each slot inside the Popper.
   * Either a string to use a HTML element or a component.
   * @default {}
   */
  components?: {
    Root?: React.ElementType;
  };
  /**
   * The props used for each slot inside the Popper.
   * @default {}
   */
  componentsProps?: BasePopperProps['slotProps'];
  /**
   * The system prop that allows defining system overrides as well as additional CSS styles.
   */
  sx?: SxProps<Theme>;
};

const Popper = React.forwardRef() as React.ForwardRefExoticComponent<PopperProps & React.RefAttributes<HTMLDivElement>>;

Here is the build result:
declare const Popper: React.ForwardRefExoticComponent<Omit<BasePopperProps, "direction"> &
// the object below should just be PopperProps
{
    /**
     * The component used for the root node.
     * Either a string to use a HTML element or a component.
     */
    component?: React.ElementType<any, keyof React.JSX.IntrinsicElements> | undefined;
    /**
     * The components used for each slot inside the Popper.
     * Either a string to use a HTML element or a component.
     * @default {}
     */
    components?: {
        Root?: React.ElementType<any, keyof React.JSX.IntrinsicElements> | undefined;
    } | undefined;
    /**
     * The props used for each slot inside the Popper.
     * @default {}
     */
    componentsProps?: BasePopperProps['slotProps'];
    /**
     * The system prop that allows defining system overrides as well as additional CSS styles.
     */
    sx?: SxProps<Theme> | undefined;
} & React.RefAttributes<HTMLDivElement>>;

This issue happens to start at<EMAIL_ADDRESS>
I wouldn't pay too close attention to that. I've been experiencing this with @types/react 17.0.65

This issue happens to start at<EMAIL_ADDRESS>
I wouldn't pay too close attention to that. I've been experiencing this with @types/react 17.0.65

It's related. Because we build with the latest @types/react, the *.d.ts got the new React.ElementType<any, ...>. However, your project's @types/react does not receive 2 arguments that's why it causes an error.
This will fix the issue including future proof if the build process does not use the generic. In meanwhile, how about reverting the https://github.com/mui/material-ui/pull/40146 back to<EMAIL_ADDRESS>cc @mui/code-infra

We are blocked on this for future updates.

@benjdlambert @antoniocanelas Can you try this fix?
// package.json
  "@mui/material": "https://pkg.csb.dev/mui/material-ui/commit/738da163/@mui/material",
  …

This solution didn't fix. :(

This solution didn't fix. :(

Did you tested the version shared in https://github.com/mui/material-ui/issues/40427#issuecomment-1999272714?

Error testing it

I can confirm there's still an issue with Popper:


Could not install on Windows Anaconda

Operating system, environment, python version
Windows 10, anaconda, python3.8.5
What you tried
pip install pyportfolioopt
Error message
ERROR: Command errored out with exit status 1: 'C:\Users\guna3\anaconda3\python.exe' 'C:\Users\guna3\anaconda3\lib\site-packages\pip_vendor\pep517_in_process.py' prepare_metadata_for_build_wheel 'C:\Users\guna3\AppData\Local\Temp\tmptl_ro7gy' Check the logs for full command output.
Copy paste the terminal message here
   Preparing wheel metadata ... - ** On entry to DGEBAL parameter number  3 had an illegal value
 ** On entry to DGEHRD  parameter number  2 had an illegal value
 ** On entry to DORGHR DORGQR parameter number  2 had an illegal value
 ** On entry to DHSEQR parameter number  4 had an illegal value
error
    ERROR: Command errored out with exit status 1:
     command: 'C:\Users\guna3\anaconda3\python.exe' 'C:\Users\guna3\anaconda3\lib\site-packages\pip\_vendor\pep517\_in_process.py' prepare_metadata_for_build_wheel 'C:\Users\guna3\AppData\Local\Temp\tmptl_ro7gy'
         cwd: C:\Users\guna3\AppData\Local\Temp\pip-install-0h6jf_hf\cvxpy
    Complete output (55 lines):
    running dist_info
    creating C:\Users\guna3\AppData\Local\Temp\pip-modern-metadata-b15pkg6e\cvxpy.egg-info
    writing C:\Users\guna3\AppData\Local\Temp\pip-modern-metadata-b15pkg6e\cvxpy.egg-info\PKG-INFO
    writing dependency_links to C:\Users\guna3\AppData\Local\Temp\pip-modern-metadata-b15pkg6e\cvxpy.egg-info\dependency_links.txt
    writing requirements to C:\Users\guna3\AppData\Local\Temp\pip-modern-metadata-b15pkg6e\cvxpy.egg-info\requires.txt
    writing top-level names to C:\Users\guna3\AppData\Local\Temp\pip-modern-metadata-b15pkg6e\cvxpy.egg-info\top_level.txt
    writing manifest file 'C:\Users\guna3\AppData\Local\Temp\pip-modern-metadata-b15pkg6e\cvxpy.egg-info\SOURCES.txt'
    Traceback (most recent call last):
      File "C:\Users\guna3\anaconda3\lib\site-packages\pip\_vendor\pep517\_in_process.py", line 280, in <module>
        main()
      File "C:\Users\guna3\anaconda3\lib\site-packages\pip\_vendor\pep517\_in_process.py", line 263, in main
        json_out['return_val'] = hook(**hook_input['kwargs'])
      File "C:\Users\guna3\anaconda3\lib\site-packages\pip\_vendor\pep517\_in_process.py", line 133, in prepare_metadata_for_build_wheel
        return hook(metadata_directory, config_settings)
      File "C:\Users\guna3\AppData\Local\Temp\pip-build-env-axm357oe\overlay\Lib\site-packages\setuptools\build_meta.py", line 161, in prepare_metadata_for_build_wheel
        self.run_setup()
      File "C:\Users\guna3\AppData\Local\Temp\pip-build-env-axm357oe\overlay\Lib\site-packages\setuptools\build_meta.py", line 253, in run_setup
        super(_BuildMetaLegacyBackend,
      File "C:\Users\guna3\AppData\Local\Temp\pip-build-env-axm357oe\overlay\Lib\site-packages\setuptools\build_meta.py", line 145, in run_setup
        exec(compile(code, __file__, 'exec'), locals())
      File "setup.py", line 57, in <module>
        setup(
      File "C:\Users\guna3\AppData\Local\Temp\pip-build-env-axm357oe\overlay\Lib\site-packages\setuptools\__init__.py", line 153, in setup
        return distutils.core.setup(**attrs)
      File "C:\Users\guna3\anaconda3\lib\distutils\core.py", line 148, in setup
        dist.run_commands()
      File "C:\Users\guna3\anaconda3\lib\distutils\dist.py", line 966, in run_commands
        self.run_command(cmd)
      File "C:\Users\guna3\anaconda3\lib\distutils\dist.py", line 985, in run_command
        cmd_obj.run()
      File "C:\Users\guna3\AppData\Local\Temp\pip-build-env-axm357oe\overlay\Lib\site-packages\setuptools\command\dist_info.py", line 31, in run
        egg_info.run()
      File "C:\Users\guna3\AppData\Local\Temp\pip-build-env-axm357oe\overlay\Lib\site-packages\setuptools\command\egg_info.py", line 298, in run
        self.find_sources()
      File "C:\Users\guna3\AppData\Local\Temp\pip-build-env-axm357oe\overlay\Lib\site-packages\setuptools\command\egg_info.py", line 305, in find_sources
        mm.run()
      File "C:\Users\guna3\AppData\Local\Temp\pip-build-env-axm357oe\overlay\Lib\site-packages\setuptools\command\egg_info.py", line 536, in run
        self.add_defaults()
      File "C:\Users\guna3\AppData\Local\Temp\pip-build-env-axm357oe\overlay\Lib\site-packages\setuptools\command\egg_info.py", line 572, in add_defaults
        sdist.add_defaults(self)
      File "C:\Users\guna3\anaconda3\lib\distutils\command\sdist.py", line 228, in add_defaults
        self._add_defaults_ext()
      File "C:\Users\guna3\anaconda3\lib\distutils\command\sdist.py", line 311, in _add_defaults_ext
        build_ext = self.get_finalized_command('build_ext')
      File "C:\Users\guna3\anaconda3\lib\distutils\cmd.py", line 299, in get_finalized_command
        cmd_obj.ensure_finalized()
      File "C:\Users\guna3\anaconda3\lib\distutils\cmd.py", line 107, in ensure_finalized
        self.finalize_options()
      File "setup.py", line 23, in finalize_options
        import numpy
      File "C:\Users\guna3\AppData\Local\Temp\pip-build-env-axm357oe\overlay\Lib\site-packages\numpy\__init__.py", line 305, in <module>
        _win_os_check()
      File "C:\Users\guna3\AppData\Local\Temp\pip-build-env-axm357oe\overlay\Lib\site-packages\numpy\__init__.py", line 302, in _win_os_check
        raise RuntimeError(msg.format(__file__)) from None
    RuntimeError: The current Numpy installation ('C:\\Users\\guna3\\AppData\\Local\\Temp\\pip-build-env-axm357oe\\overlay\\Lib\\site-packages\\numpy\\__init__.py') fails to pass a sanity check due to a bug in the windows runtime. See this issue for more information: https://tinyurl.com/y3dm3h86
![2020-11-25](https://user-images.githubusercontent.com/73594582/100315245-588fdb00-2fde-11eb-88a0-817521b72ad3.png)

Do you have C++ installed?

Yes I have C++ installed I followed the instructions correctly

I have the same problem. I installed Visual Studio Build Tool 2019 correctly I believe. I have uploaded a screenshot.
(env4) C:\Users\25del\Python Projects>pip install PyPortfolioOpt
Collecting PyPortfolioOpt
Using cached PyPortfolioOpt-1.2.7-py3-none-any.whl (48 kB)
Collecting scipy<2.0,>=1.3
Using cached scipy-1.5.4-cp38-cp38-win_amd64.whl (31.4 MB)
Collecting cvxpy<2.0,>=1.0
Using cached cvxpy-1.1.7.tar.gz (1.0 MB)
Installing build dependencies ... done
Getting requirements to build wheel ... done
Preparing wheel metadata ... \ ** On entry to DGEBAL parameter number  3 had an illegal value
** On entry to DGEHRD  parameter number  2 had an illegal value
** On entry to DORGHR DORGQR parameter number  2 had an illegal value
** On entry to DHSEQR parameter number  4 had an illegal value
error
ERROR: Command errored out with exit status 1:
command: 'C:\Users\25del\Anaconda3\envs\env4\python.exe' 'C:\Users\25del\Anaconda3\envs\env4\lib\site-packages\pip_vendor\pep517_in_process.py' prepare_metadata_for_build_wheel 'C:\Users\25del\AppData\Local\Temp\tmpv3atyfpr'
cwd: C:\Users\25del\AppData\Local\Temp\pip-install-t9xw9m8w\cvxpy
Complete output (55 lines):
running dist_info
creating C:\Users\25del\AppData\Local\Temp\pip-modern-metadata-nekw02hr\cvxpy.egg-info
writing C:\Users\25del\AppData\Local\Temp\pip-modern-metadata-nekw02hr\cvxpy.egg-info\PKG-INFO
writing dependency_links to C:\Users\25del\AppData\Local\Temp\pip-modern-metadata-nekw02hr\cvxpy.egg-info\dependency_links.txt
writing requirements to C:\Users\25del\AppData\Local\Temp\pip-modern-metadata-nekw02hr\cvxpy.egg-info\requires.txt
writing top-level names to C:\Users\25del\AppData\Local\Temp\pip-modern-metadata-nekw02hr\cvxpy.egg-info\top_level.txt
writing manifest file 'C:\Users\25del\AppData\Local\Temp\pip-modern-metadata-nekw02hr\cvxpy.egg-info\SOURCES.txt'
Traceback (most recent call last):
File "C:\Users\25del\Anaconda3\envs\env4\lib\site-packages\pip_vendor\pep517_in_process.py", line 280, in
main()
File "C:\Users\25del\Anaconda3\envs\env4\lib\site-packages\pip_vendor\pep517_in_process.py", line 263, in main
json_out['return_val'] = hook(**hook_input['kwargs'])
File "C:\Users\25del\Anaconda3\envs\env4\lib\site-packages\pip_vendor\pep517_in_process.py", line 133, in prepare_metadata_for_build_wheel
return hook(metadata_directory, config_settings)
File "C:\Users\25del\AppData\Local\Temp\pip-build-env-gm7m10wb\overlay\Lib\site-packages\setuptools\build_meta.py", line 161, in prepare_metadata_for_build_wheel
self.run_setup()
File "C:\Users\25del\AppData\Local\Temp\pip-build-env-gm7m10wb\overlay\Lib\site-packages\setuptools\build_meta.py", line 253, in run_setup
super(BuildMetaLegacyBackend,
File "C:\Users\25del\AppData\Local\Temp\pip-build-env-gm7m10wb\overlay\Lib\site-packages\setuptools\build_meta.py", line 145, in run_setup
exec(compile(code, file, 'exec'), locals())
File "setup.py", line 57, in
setup(
File "C:\Users\25del\AppData\Local\Temp\pip-build-env-gm7m10wb\overlay\Lib\site-packages\setuptools_init.py", line 153, in setup
return distutils.core.setup(**attrs)
File "C:\Users\25del\Anaconda3\envs\env4\lib\distutils\core.py", line 148, in setup
dist.run_commands()
File "C:\Users\25del\Anaconda3\envs\env4\lib\distutils\dist.py", line 966, in run_commands
self.run_command(cmd)
File "C:\Users\25del\Anaconda3\envs\env4\lib\distutils\dist.py", line 985, in run_command
cmd_obj.run()
File "C:\Users\25del\AppData\Local\Temp\pip-build-env-gm7m10wb\overlay\Lib\site-packages\setuptools\command\dist_info.py", line 31, in run
egg_info.run()
File "C:\Users\25del\AppData\Local\Temp\pip-build-env-gm7m10wb\overlay\Lib\site-packages\setuptools\command\egg_info.py", line 298, in run
self.find_sources()
File "C:\Users\25del\AppData\Local\Temp\pip-build-env-gm7m10wb\overlay\Lib\site-packages\setuptools\command\egg_info.py", line 305, in find_sources
mm.run()
File "C:\Users\25del\AppData\Local\Temp\pip-build-env-gm7m10wb\overlay\Lib\site-packages\setuptools\command\egg_info.py", line 536, in run
self.add_defaults()
File "C:\Users\25del\AppData\Local\Temp\pip-build-env-gm7m10wb\overlay\Lib\site-packages\setuptools\command\egg_info.py", line 572, in add_defaults
sdist.add_defaults(self)
File "C:\Users\25del\Anaconda3\envs\env4\lib\distutils\command\sdist.py", line 228, in add_defaults
self._add_defaults_ext()
File "C:\Users\25del\Anaconda3\envs\env4\lib\distutils\command\sdist.py", line 311, in add_defaults_ext
build_ext = self.get_finalized_command('build_ext')
File "C:\Users\25del\Anaconda3\envs\env4\lib\distutils\cmd.py", line 299, in get_finalized_command
cmd_obj.ensure_finalized()
File "C:\Users\25del\Anaconda3\envs\env4\lib\distutils\cmd.py", line 107, in ensure_finalized
self.finalize_options()
File "setup.py", line 23, in finalize_options
import numpy
File "C:\Users\25del\AppData\Local\Temp\pip-build-env-gm7m10wb\overlay\Lib\site-packages\numpy_init.py", line 305, in
win_os_check()
File "C:\Users\25del\AppData\Local\Temp\pip-build-env-gm7m10wb\overlay\Lib\site-packages\numpy_init.py", line 302, in _win_os_check
raise RuntimeError(msg.format(file)) from None
RuntimeError: The current Numpy installation ('C:\Users\25del\AppData\Local\Temp\pip-build-env-gm7m10wb\overlay\Lib\site-packages\numpy\init.py') fails to pass a sanity check due to a bug in the windows runtime. See this issue for more information: https://tinyurl.com/y3dm3h86
----------------------------------------
ERROR: Command errored out with exit status 1: 'C:\Users\25del\Anaconda3\envs\env4\python.exe' 'C:\Users\25del\Anaconda3\envs\env4\lib\site-packages\pip_vendor\pep517_in_process.py' prepare_metadata_for_build_wheel 'C:\Users\25del\AppData\Local\Temp\tmpv3atyfpr' Check the logs for full command output.

Could it be that there is a bug in the Visual Studio 2019 concerning numpy and scipy? Apparently, the workaround is to

pip uninstall numpy

and

pip install numpy==1.19.3

https://developercommunity.visualstudio.com/content/problem/1207405/fmod-after-an-update-to-windows-2004-is-causing-a.html
However, after doing this, when I try to

pip install PyPortfolioOpt

To a new environment with Python 3.8.5, I get the same error as above. This started as soon as I switched to a new computer and tried to install all my usual packages to a new environment. This is a HUGE problem as I use this for work.

Duplicate of #223
This workaround solution worked for me. Created new environment with conda create -n myenv python=3.6 numpy=1.19.3. Hopefully Microsoft fixes the fmod bug soon.

Sorry I can't be of assistance here as I'm on macOS. It sounds like some thorny issue related to C++ interacting with some python libraries. Glad you have a workaround!

Hello, I wanted to update everyone on my work dealing with this issue. Here is an update from Microsoft's developer team regarding their upcoming fix to one of their Windows updates breaking numpy==1.19.4 on python 3.8, thereby making PyPortfolioOpt impossible to pip install PyPortfolioOpt on python 3.8 on Windows 10. They estimate a fix coming out at the end of January but you can test the fix. Below I post the message from the Senior Software Engineer. https://tinyurl.com/y3dm3h86.
Hey everyone,

An Insider Preview Windows build with the fix is now available. Build 20270 is now in the Dev Channel: https://blogs.windows.com/windows-insider/2020/12/03/announcing-windows-10-insider-preview-build-20270/. If you are affected by this issue and want to test against the fix that will come via Windows Update, you can use this build. This is an insider build with other changes included, of course, so it is not entirely representative of the version that will be serviced, but it can be used to test for specific cases where the bug used to reproduce.

We are still on schedule for servicing Windows build 19041 (the current release version) at the end of January 2021.

Thanks!

Steve Wishnousky
Senior Software Engineer - Visual C++ Libraries
<EMAIL_ADDRESS>
I've been using the current workaround python==3.6 with numpy==1.19.3 solution for a few weeks now and frankly, it's not satisfactory. Python 3.6 and compatible packages have bugs and issues that have since been resolved in subsequent updated versions Python 3.7 and currently Python 3.8 with compatible packages. I've found myself encountering these bugs and having to manually fix them by searching for solutions and having to edit code in various dependencies where I encounter these bugs. Everything was working great before Microsoft broke numpy, so all I can really do is wait for them to come out with the update and keep using an inferior version of Python and compatible dependencies.

@x829901 Appreciate the analysis – will keep this issue open until resolved!

until PyPortfolioOpt becomes compatible with python 3.7<= and numpy 1.19.3<=

Is there anything I can do on my end to fix this? In the requirements.txt, I have numpy>=1.17 so in principle PyPortfolioOpt should be compatible with python 3.7<= numpy 1.19.3<=?

Found a workaround. Instead of:
pip install PyPortfolioOpt
I installed dependencies manually the used:
pip install --no-dependencies PyPortfolioOpt

I had tried "pip install PyPortfolioOpt" and received error for "m.lib".
Then I made "pip install --no-dependencies PyPortfolioOpt" - successfully.
Executed "pip install cvxopt" that gave me error "pip's dependency resolver does not currently take into account all the packages that are installed..." - etc.
Executed "pip uninstall cvxopt" - successfully.
Executed "conda install -c conda-forge cvxopt" - successfully.
Executed "pip install PyPortfolioOpt" - result "Requirement already satisfied".

@yordan-bankov just to clarify, is it working now?

Yes PyPortfolioOpt works, but:
RuntimeError: "module compiled against API version 0xe but this version of numpy is 0xd"

Executed "pip uninstall numpy" - successfully.
Executed "pip install numpy" - installed and reported "tensorflow 2.3.1 requires numpy<1.19.0,>=1.16.0, but you have numpy 1.20.1 which is incompatible"

So now functions from  PyPortfolioOpt are OK, but I assume if I try to use something from TensorFlow, it will not work.
This below is relevant for Windows / Anaconda only:
The Anaconda is an additional level of abstraction above Python. In this respect Anaconda provides a set of modules which are maintained by conda. For example, Anaconda for Windows have numpy 1.19.0 in the Anaconda modules list. To have working PyPortfolioOpt it is required to have numpy 1.20.1.  This numpy is not supported by Anaconda set of modules. The numpy 1.20.1 can be installed using pip, and this will make PyPortfolioOpt working. On the other hand, other modules will also need manual update using pip.

dear all,  the problem is not from  PyPortfolioOpt, It's from installing the dependecy cvxpy, before installing cvxpy you need install numpy+mkl not numpy.
Here is the solution:
NumPy+mkl: https://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy
SCIPY: https://www.lfd.uci.edu/~gohlke/pythonlibs/#scipy
CVXOPT: https://www.lfd.uci.edu/~gohlke/pythonlibs/#cvxopt
SCS: https://www.lfd.uci.edu/~gohlke/pythonlibs/#scs
ECOS: https://www.lfd.uci.edu/~gohlke/pythonlibs/#ecos
OSQP: https://www.lfd.uci.edu/~gohlke/pythonlibs/#osqp
CVXcanon: https://www.lfd.uci.edu/~gohlke/pythonlibs/#cvxcanon
Fastcache: https://www.lfd.uci.edu/~gohlke/pythonlibs/#fastcache
Multiprocess: https://www.lfd.uci.edu/~gohlke/pythonlibs/#multiprocess
CVXPY：https://www.lfd.uci.edu/~gohlke/pythonlibs/#cvxpy
remember install the wheel one by one and following the order please.


Having an issue with formdata requests

Version or commit hash:
4.0.0-beta.0
Explanation of issue:
So after a bit of messing about with this I've just about given up trying to make it work, I have a request I need to send formdata with and trying everything from the docs seems to return nothing I can get to work.
I've tried
.send({ "field-1": "value", "field-2": "value" })
('url', { data: { "field-1": "value", "field-2": "value" } })
Plus I've tried adding it directly to the url using
URL?field-1=value&field-2=value
All of these methods work in postman and my install of curl also with the npm module request.
This seems to be an issue with form names that have a hyphen in them, because I have another request that does not contain hyphens to the same api and it works just fine with the .send option.
Example code to reproduce:
snek.post('url').send({ "field-1": "value", "field-2": "value" }).then((body) => {
  console.log(resp.body);
});

[ ] Issue occurs in browser
[x] Issue occurs in node

.send isn't for form data, use .attach

I know you closed this, but something tells me this is not my wrong doing as I'm logging into the same website with .send here
snek.post('https://solder.tetranite.com/login', { redirect: false }).send({
    email: config.solder.email,
    password: config.solder.pass
})

And that above code works as intended and it's also done with formdata.
But it doesn't have hypens in the url or the formdata.
I tried this below code and all of it doesn't contain formdata once it reaches the api.
snek.post('https://solder.tetranite.com/mod/add-version?mod-id=163&mod-version=1.2.4').set('x-requested-with', 'XMLHttpRequest')

snek.post('https://solder.tetranite.com/mod/add-version).set('x-requested-with', 'XMLHttpRequest').send({ 'mod-id': '163', 'mod-version': '1.2.4' })

snek.post('https://solder.tetranite.com/mod/add-version').set('x-requested-with', 'XMLHttpRequest').attach('mod-id', '163').attach('mod-version', `1.2.4`)

None of these actually contain formdata once they reach the api. Even the URL with the formdata at the end of it works in the request module and also postman. Something makes me think that something is up with urls and/or formdata containing hypens

send will send either a JSON or x-www-form-urlencoded body (if you explicitly set the content type to application/x-www-form-urlencoded)
attach will send a "Form Data" (multipart/form-data) body
please be more explicit about your issue.

Alright, thanks for the info. I tested all the methods again with that url and it seems they're all detected, so it's just oddly not working with snekfetch for some reason. Thanks for your time.

please paste a short snippet which i can run without changing anything that will demonstrate this bug

The request requires authentication, I can DM it to you on Discord if you'd rather.

if you can't reproduce it with httpbin then it isn't a bug with snekfetch


Add some fixes and improvements

This commit includes the following changes:

Add command line option to prefer the language that's associated with the used Apple Music account
Strip time and timezone from date in tagged metadata (now the date is formatted as YYYY-MM-DD)

These two features are very useful! Thank you very much!


chore : Use uv to resolve dependencies

https://github.com/astral-sh/uv
And another Makefile, for extra fast and efficient updates,

Sur pipeline: time make upgrade all
Before
real    0m55,193s
user    0m42,995s
sys     0m2,214s

After
real    0m2,613s
user    0m2,064s
sys     0m0,465s

Corrigé les points que tu avais soulevé.


#315 - Add new lint for nested form groups

Resolves #315

Add E050 to check for nested form groups.
Add new fixtures to test the new lint
Update bootlint_test to call new fixtures

Hi @cvrebert would you be okay merging this PR in?

Hi @cvrebert are you comfortable merging this PR? Thank you!

Hi @cvrebert would you be okay merging this PR in? Thank you!

Hi @XhmikosR are you comfortable merging this PR in? Thank you!!

Thanks!


Fix bug with runner status and API status update

Codecov Report

Merging #380 (5e32068) into main (ee29bc5) will decrease coverage by 20.10%.
The diff coverage is 21.42%.

@@             Coverage Diff             @@
##             main     #380       +/-   ##
===========================================
- Coverage   85.11%   65.02%   -20.10%
===========================================
  Files          27       27
  Lines         927      932        +5
===========================================
- Hits          789      606      -183
- Misses        138      326      +188

Flag
Coverage Δ

api
65.02% <21.42%> (-0.36%)
:arrow_down:

unit
?

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

Files Changed
Coverage Δ

runner_manager/models/runner_group.py
60.36% <0.00%> (-32.09%)
:arrow_down:

runner_manager/models/runner.py
67.44% <37.50%> (-30.24%)
:arrow_down:

... and 8 files with indirect coverage changes


Compage gpt

Hi  @mahendraintelops
I have developed the backend code for compage-gpt using Python and langchain. The code takes code language and code topic as input from the user through API.  User's openai key has been transferred through the header. The backend code fetches relevant information from chatGPT .

Can you please add the dockerfile and other required tools to this subproject?

The docker file has been generated. What are the other tools? Can you explain me?

LGTM, with minor suggestions. If you could change the directory name to llm_backend, it would be nice.

The folder name has been changed as per your suggestion.


Feature request - transfer options ( e.g. primary <=> clipboard )

I am constantly selecting something in one application and pasting into another, only to paste something that I selected long ago.
I would like to have a settable config option for clipmenud to:

when there is a new value in clipboard immediately copy in into primary also
when there is a new value in primary immediately copy in into clipboard also

whether the above is 2 separate options, or one option, doesn't matter to me, I will always want both.
This could be written as a separate application, but I'm not sure that having 2 applications watching these changes would co-exist properly.  Therefore, I would like to see it added to clipmenud.  I made a couple of attempts at adding it myself, but they ended in failure.
If you would except such a patch, I will try again, and provide a PR.

We already have support for primary -> clipboard: https://github.com/cdown/clipmenu/blob/develop/clipmenud#L217-L219
clipboard -> primary is more problematic: on the primary selection, clearing it usually clears the visual selection itself. That poses a problem if there is (for example) culmulative addition towards the final selection content.

Thank you @cdown !
Works great!


Allows the specification of nginx configruation options.

What this PR does / why we need it:
Allows the specification of nginx configruation options.
Which issue this PR fixes:
fixes; #72
Special notes for reviewer:
Based from #69 where the migration to ingress-nginx has been made.
Checklist:

[x] Added relevant notes to WIP-CHANGELOG.md
[x] Proper commit message prefix on all commits
[ ] Updated the public facing documentation
Is this changeset backwards compatible for existing clusters? Applying:

[x] is completely transparent, will not impact the workload in any way.
[ ] requires running a migration script.
[ ] will create noticeable cluster degradation.
E.g. logs or metrics are not being collected or Kubernetes API server
will not be responding while upgrading.
[ ] requires draining and/or replacing nodes.
[ ] will change any APIs.
E.g. removes or changes any CK8S config options or Kubernetes APIs.
[ ] will break the cluster.
I.e. full cluster migration is required.

I have not mentioned that .. the configration has changed and you need to run init... I think we should just add that statement in general in the changelog before we release.


Recipe Model & Controller

FoodPad App || Recipe Model & Controller
Project Description
Create Model and Controller for Recipe.
Feature Description

Created Model for Recipe.
Created Controller for Recipe.
Created Views for Recipe
Created Controller for Public_Recipe.
Created Views for Public_Recipe

Happy Reviewing!!

Thanks so much @Paul-js-hub for the amazing review!


Click comes out long press

In multiple incidences, we've noticed that a simple el.click() results in long press, messing up tests. Witnessed on Nexus 4 and Nexus 7.
The cause isn't clear.

Closing this for the following reasons:

Upgraded OS to Lollipop and doesn't happen anymore.
Did not get this complaint from others at all.

Plz reopen if this reoccurs.


redux-actions: Add support for nested reducers

redux-actions supports nested reducers in handleActions, just like createActions supports nested actions

mmhh..... looks like for some reason
    // $ExpectError
    'REQUIRERS_REDUCER_VALUE': {},

This is valid?? Because the logs says
  34:     // $ExpectError
            ^^^^^^^^^^^^^^^ Error suppressing comment. Unused suppression


Click expose and open - Update comment - Fiori app ABAP

Hello,
Scenario URL: https://developers.sap.com/tutorials/abap-environment-deploy-cf-production.html
Step 5.3: Click Open in New Tab.
Please mention: "expose and open" instead of "open in new tab" ( You can also check the screenshot provided is correct which says expose and open).
Also, ADD A STEP -  "please press enter to use default port" after clicking expose and open.

Labels to be added:
Sprint Label: SCPTest-2011A
Landscape label: trail1, trail2
Scenario label: SCPTest-fabap
Prio: low-prio
Thanks,
Shubham

Hi @i353590 ,
I created following pull request: #6347 for this issue.
@MichaelCzcz  we can close this ticket.
Best regards,
Merve


document that udev + network_mode: host causes modem issues

It seems that the combination of udev and network_mode: host causes cellular modems to be replugged after a container restart, which often will result in the modem never reconnecting.
The recommendation for modem based applications is to use a microservices application type and add a docker-compose.yml that looks as follows:
version: '2.1'
networks: {}
volumes:
  resin-data: {}
services:
  main:
    build:
      context: .
    privileged: true
    restart: always
    # network_mode: host
    volumes:
      - 'resin-data:/data'
    labels:
      io.resin.features.kernel-modules: '1'
      io.resin.features.firmware: '1'
      io.resin.features.dbus: '1'
      io.resin.features.supervisor-api: '1'
      io.resin.features.resin-api: '1'

the reason has to do with https://github.com/systemd/systemd/issues/6713 and the way udev in the container handles network namespaces.

Interesting. on the other hand, for in-container udev events I found that network_mode: host might be needed....

Need to investigate this further, if it works now or not before adding a fix for it.


Header does not fit on phones

Description

The end-side of the header is cut off on smaller widths such as phones.
Reproduction

Visit Openverse from a smaller width device.
See error.

Expectation

The Search bar could possibly shrink to accommodate the content.
Screenshots

Environment

Device: iPhone Xr
OS: iOS 15.3
Browser: Safari
Version: 15.3
Other info: viewport width = 414px

Resolution

[ ] 🙋 I would be interested in resolving this bug.

Is this new? Which version of the front-end is this?
Just for context, when I open the currently deployed site at wordpress.org/openverse in Firefox or Chrome on my Android phone, I don't have a problem with the header not fitting.

@obulat I believe it referrers to the header after scrolling on the search results (which only seems to change on ssr-rendered pages, interesting bug). I'm able to view this on android chrome + ff.

The iPhone I used has just 414px of width so that might be one of the reasons for the header getting cropped.

Is this and #845 related?


mwc-select does not dispatch input event

Based on this page: https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/input_event, a select should dispatch an input event when its value changes. Currently mwc-select only dispatches a change event. This causes problems for our forms which detect changes using the input event. This is especially relevant in the shadow dom because the input event is composed but the change event is not. So you can capture input events across shadow boundaries.
Steps to reproduce the behavior:

List for the 'input' event on a mwc-select component
Select a value

Expected behavior
An input event and a change event should be dispatched.
Browser Version (please complete the following information):

OS: OSX
Browser Chrome
Version 86.0.4240.111 (Official B

The behavior I was looking for can be implemented by dispatching an input event whenever the mwc-menu dispatches an action event.

it's been a while since I've worked with select; does it still fire the change event? It may simply be undocumented

It fires a change event but not an input event. The change event isn't composed, so doesn't cross shadow boundaries.

It does now!
https://github.com/material-components/material-web/blob/6aa42f3399e9b8433a6920a6e6779d16a0c55cce/select/internal/select.ts#L572


Isolate/spawn_A04_t04 is failing

co19/LibTest/isolate/Isolate/spawn_A04_t04 went from flaky to consistently failing on vm-dartkb-linux-release-x64. It's also failing on other configurations.
Due to flakiness, the culprit CL is not clear.

Duplicate of https://github.com/dart-lang/co19/issues/1003