bug: npm install fails, eslint 9 not supported by eslint-plugin-import

Provide environment information
System:
OS: Windows 10 10.0.19045
CPU: (8) x64 Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
Memory: 2.28 GB / 15.89 GB
Binaries:
Node: 18.17.0 - C:\Program Files\nodejs\node.EXE
Yarn: 1.22.4 - ~\AppData\Roaming\npm\yarn.CMD
npm: 9.6.7 - C:\Program Files\nodejs\npm.CMD
pnpm: 9.1.3 - ~\AppData\Local\pnpm\pnpm.EXE
Describe the bug
npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! While resolving<EMAIL_ADDRESS>npm ERR! Found<EMAIL_ADDRESS>npm ERR! node_modules/eslint
npm ERR!   dev<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!   tooling/eslint
npm ERR<EMAIL_ADDRESS>npm ERR!     node_modules/@pitchpal/eslint-config
npm ERR!       workspace tooling\eslint from the root project
npm ERR!       9 more (@pitchpal/api, @pitchpal/auth, @pitchpal/db, ...)
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer eslint@"^2 || ^3 || ^4 || ^5 || ^6 || ^7.2.0 || ^8" from<EMAIL_ADDRESS>npm ERR! node_modules/eslint-plugin-import
npm ERR<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!   tooling/eslint
npm ERR<EMAIL_ADDRESS>npm ERR!     node_modules/@pitchpal/eslint-config
npm ERR!       workspace tooling\eslint from the root project
npm ERR!       9 more (@pitchpal/api, @pitchpal/auth, @pitchpal/db, ...)
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
Link to reproduction
reproduce.com
To reproduce
run npx create-turbo@latest -e https://github.com/t3-oss/create-t3-turbo
Additional information
No response

Ignoring peerDep range (npm i --legacy-peer-deps), have you noticed the plugin failing?

no, didn't try, but I think the repo should have the dependencies versions sorted out. Did you try to re-lock the pnpm lock file? Cos I also got to change the react version for compatibility between two deps (can't recall now).

no, didn't try, but I think the repo should have the dependencies versions sorted out. Did you try to re-lock the pnpm lock file? Cos I also got to change the react version for compatibility between two deps (can't recall now).

That's unfortunately quite hard and would stale development, especially now with React 19 coming out there'll be a bunch of peer dep warnings for libs that doesn't update their peer dep range even when it could work without issues


Update auth, dynamodb, s3, sqs to 2.17.134

Updates

software.amazon.awssdk:auth
software.amazon.awssdk:dynamodb
software.amazon.awssdk:s3
software.amazon.awssdk:sqs

from 2.17.66 to 2.17.134.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "software.amazon.awssdk" } ]

labels: library-update, early-semver-patch, semver-spec-patch, commit-count:1

Superseded by #839.


Broken version 1.1.1?

I installed version 1.1.1, and I'm getting an error compiling: "File to import not found or unreadable: _nameOfPartial.scss", when I'm using syntax like this:
@import "components/*";

Uninstalled 1.1.1 and installed 1.1.0, and worked nice. Using compass
sass (3.3.7, 3.3.4, 3.2.19, 3.2.12)
compass (0.12.6)
compass-core (1.0.0.alpha.19)
compass-import-once (1.0.4)

Fixed in 1.1.3


feat: remote index stats

BREAKING CHANGE: the return value of index_stats method has changed and all index_stats APIs now take index name instead of UUID. Also several deprecated index statistics methods were removed.

Removes deprecated methods for individual index statistics
Aligns public IndexStatistics struct with API response from LanceDB Cloud.
Implements index_stats for remote Rust SDK and Python async API.

@wjones127 btw do you want to add num_indices in the resp?
lance's index_stats return value contains it, it could be useful for some compact/reindex policy

btw do you want to add num_indices in the resp?

Good idea @BubbleCal. I've added that field as well. It will be missing from remote tables for now until we plumb that through in Phalanx.

A general question, how would a user know the index name? Do we have some message to indicate that it iscol name_idx?

Right now they have to call list_indices() and find the index they created. You can see us doing that in some of the unit tests.
In Lance, users can pass down the name of the index they want. We could eventually do the same in LanceDB.


Mutiny Uni.createFrom().converter(UniRxConverters.fromSingle(), single) has exceptions wrapped in java.util.concurrent.ExecutionException when used in a chain or flatmap

Could not find docs or reference to this. so assuming it is a bug unless there is a nuance to usage here.  Consider the following

@GET
fun getTheValue(): Uni<Something> {
    return someParentFun()
}

fun someParentFun(): Uni<Something>{
   return someFun()
}

fun someFun(): Uni<Something>{
      return getUser(userId) // a Uni
            .flatMap {
                callSomeOtherUni(it)
            }.chain { result ->
                val single = someRxJavaSingleMethod(result)
                Uni.createFrom().converter(UniRxConverters.fromSingle(), single)
                    .onFailure().transform { t -> t.cause } // This is required to make the parent Uni get the actual error
            }.flatMap {
                callSomeOtherOtherUni(it)
            }
}

when the someRxJavaSingleMethod() method fails it throws as a java.util.concurrent.ExecutionException with the real issue in the cause.  I have to add the onFailure.transform to get the cause.
Why is the actual issue not bubbled?
Thanks!

That's interesting. I agree with you, it looks like a bug. I will have a look.

What does someRxJavaSingleMethod do? I'm not able to reproduce the issue with a single method returning a failed single.

To be clear the only place where Mutiny uses ExecutionException is when it creates a Uni from a Future, which, because of the underlying blocking behavior, needs to catch ExecutionException. However, even in this case, the exception is unwrapped.

@cescoffier I was wrapping this https://github.com/digital-asset/daml/blob/main/language-support/java/bindings-rxjava/src/main/java/com/daml/ledger/rxjava/grpc/UserManagementClientImpl.java#L47

Based on your comment above, should it still not be unwrapped/bubbled ?

Yes, mutiny receives the ExecutionException. The issue is in Single.fromFuture which does not unwrap the exception.

Not really. Mutiny cannot know if the ExecutionException comes from a Single.fromFuture which does not unwrap or if it's an intentional usage.

@cescoffier Thank you for the detailed response!


Problems view: Sort by message

Working with the problems tab in the panel, issues are grouped by file. Although this is useful, certain dev workflows require dealing with one problem type (EDIT: by problem type here we mean the problem message) at a time and therefore grouping problems by type would be useful. Current view for comparison

Note that this feature had been requested before https://github.com/microsoft/vscode/issues/41114 and while the moderator has closed it with the argument that filtering functionality can meet this requirement, I am reopening the discussion here, more than 2 years down the line, for reconsideration. Where filtering alone fails is allowing for wider analysis of the number of occurrences of different problems across the solution i.e. is it a widespread problem with say 10-20 occurrences or is it just a single instance. This is essential when performing large refactoring or code upgrades where we have to deal with tens or even hundreds of problems at a time.
Additionally in support of this I am attaching a screenshot of how Visual Studio problems panel displays which many of us coming from the Enterprise are used to with writing C#. Currently all those capabilities are present in VS Code except for the default grouping of problems we get.

Where filtering alone fails is allowing for wider analysis of the number of occurrences of different problems across the solution i.e. is it a widespread problem with say 10-20 occurrences or is it just a single instance. This is essential when performing large refactoring or code upgrades where we have to deal with tens or even hundreds of problems at a time.

We provide above filters and can you please explain how above filters is not helping your requirement and how grouping is helpful.

I was talking about code changes where there are potentially tens of problems reported across many files. Sorting by error type allows us to understand how widespread each compile error is and prioritise those in order of number of occurrences for example. The filtering only allows us to get that information one error type at a time which is only useful when you know what you want to fix next.

Sorting by error type allows us to understand how widespread each compile error is and prioritise those in order of number of occurrences for example.

I am not saying that this is the right way but I think you can also get this information by toggling the filters and get the numbers and prirotize what type to fix ?
I am actually looking for a strong use case to get this feature.

This means searching for each error type one by one, analyse occurrences of each then summing it all up to decide where to start from. The effort grows exponentially with number and variety of problems reported. When https://github.com/microsoft/vscode/issues/13953 is implemented, I feel it will be even more of a problem as we'll have to be filtering through much larger problems output by default.

There are only 4 types and Problems view shows only 3 types. Mostly 2 types are more prominent (errors and warnings).

analyse occurrences of each then summing it all up to decide where to start from.

Not able to figure out the issue here to decide where to start among 2 types (max 3) ?

Yes I see where the confusion is. Let me use an example from the actual problems list output here (Solidity compilation result for Ethereum):
{
	"resource": "/contracts/legacy/TokenPriceProvider.sol",
	"owner": "_generated_diagnostic_collection_name_#0",
	"severity": 8,
	"message": "Source file requires different compiler version (current compiler is 0.6.8+commit.0bbfe453.Emscripten.clang) - note that nightly builds are considered to be strictly less than the released version",
	"startLineNumber": 17,
	"startColumn": 1,
	"endLineNumber": 17,
	"endColumn": 24
}
{
	"resource": "/contracts/modules/storage/GuardianStorage.sol",
	"owner": "_generated_diagnostic_collection_name_#0",
	"severity": 4,
	"message": "security/no-block-members: Avoid using 'now' (alias to 'block.timestamp').",
	"startLineNumber": 134,
	"startColumn": 49,
	"endLineNumber": 134,
	"endColumn": 5146
}
{
	"resource": "/lib/maker/jug.sol",
	"owner": "_generated_diagnostic_collection_name_#0",
	"severity": 8,
	"message": "Source file requires different compiler version (current compiler is 0.6.8+commit.0bbfe453.Emscripten.clang) - note that nightly builds are considered to be strictly less than the released version",
	"startLineNumber": 1,
	"startColumn": 1,
	"endLineNumber": 1,
	"endColumn": 24
}

In this abbreviated case, I would like to be able to sort by the message string so the first and third errors are grouped together and I can fix at once.

I see you want to see problems sorted by message and you can go through them. But why do you need grouping by type?

Define "type" here pls as we're probably talking about different things.

By type I mean severity. Sorry for not being clear.

Thanks for clarifying, then I wasn't talking about the severity at all here. I was referring to grouping by the problem message as given in the example above.

I assume by grouping you mean sorting by message?

Yes

I agree with the Visual Studio example given above by @elenadimitrova.  A table (with filedir, filename, severity, message) sortable by any number of columns, would be a great help.  Especially if each column was individually filterable by regex.  More info like error position could be added but I don't see that as useful when looking at a list of problems.
Initially I thought being able to toggle between the current Problems tree-view (file node + message leaf) and a table would be perfect but I'm struggling to understand what the advantage is of having a tree-view (or the ability to collapse it) at all compared to having a table.  Is there any workflow where the tree-view is better?  It takes up an additional line on the screen for every file which having a table wouldn't need and, when collapsed, any knowledge of what the problems are is lost, except for the file and number per file which I don't see as very useful without the message.  It's not sortable by field (i.e. severity, message, filename). So I'd propose ditching the treeview completely for a table.
The times where I run into this issue is in cases of large refactorings where some changes (e.g. an upgrade of a major library version) can cause thousands of messages and being able to sort them and scroll down through the different messages can give a good overview of the ramifications i.e. whether there are any show-stoppers that might result in having to rollback, roughly how much time fixing those issues might take, whether other coders need to be involved etc.

@sandy081 As far as I understand it, solving this issue would let the user have a Problems pane flat, with no grouping of any sort. By default, can we have this flat list of problems, be sorted in the order the task output generated it? This is a huge necessity in C++!
Multiple issues already have been posted here about that problem. The one that could have saved C++ devs from this nightmare of finding the first error in task output was #18685. Never made it because never got enough support and was automatically closed. I am thinking about recreating an issue, but found this one here, thought I would ask before doing anything.

be sorted in the order the task output generated it?

If we support sorting, then the default would be to show in the order how extensions/tasks have contributed it.

As I can see this feature is being worked on, I would like to share a thought.
When there is no sorting column defined by the user, because I got confirmation that the order will be the one the different extensions and tasks have contributed to it, the following situation came to my mind.
When I run my C++ build, I get my problems in a very specific order from my task. I want (need) to keep it like that. But, there is also the Intellisense that contributes to the list of problems dynamically. Like for example, when I am opening a file, reading it. Then, a list of problems can pop up in my Problems pane. When I close the file, the problems disappear. There are two things here.

As this is inherently dynamic, and supposed to be useful, they shouldn't be added at the end of the problem list. Because they came up after I ran a task for example. In the C++ case, it's very easy to have thousands of problems when building a very basic piece of code, it is a very common situation. So adding the Intellisense problems would automatically mean, we never gonna see them sometimes. Because in C++ we are always interested in the top of the list of problems from our build task.
The list of problems generated by Intellisense can be different from the one the build task has generated for the same file. It won't make sense to merge them all blindly. As an example, in C++ only the build problems are guaranteed to be interesting to fix my compilation, the Intellisense is very useful to give me hints on very probable problems on the other hand. (Having both matching exactly is not easy.)

Where then? where to add these dynamic problems?

Probably in a separate group of problems (grouping by source?)
Or maybe having a column to push in front of (or at the end of) the list the problems we are interested in (or not) while still keeping the order of the problems for the same source the same as they have been pushed by it
Something else?

So, to sum it up. I am very excited to see that, soon, I gonna have my list of problems sorted the way they have been pushed by my task!! But, probably don't merge problems from different sources without letting the user know and choose what to display.

For example: ./p.py --pebble_id 00:11:22:33:44:55:66 --lightblue get_time
The --pebble_id can also be the 4 letter friendly name of your pebble but this require that the Pebble is broadcasting.

Today when problems view shows all problems from different sources. For example you could see lot of problems in a java workspace. Problems from java LS, Sonar LS and Maven LS (redhat xml) all will be shown in the list. It would be nice if the problems can be grouped so it will be easy to focus on each problem type. Another alternative for grouping is add the same support into filtering which will also solve the above use-case.

The latest Insiders release have a new action in the toolbar of the "Problems View" that allows users to toggle between seeing the problems in a tree view or a table. The table has a dedicated column for the source of the problem, so after switching to the table view, you can use the existing filter capabilities to filter the problems by source.

Thank you very much for you work @lszomoru. I just tried your work on the insiders branch. I like the direction it is taking. It is a great improvement to know from which source a problem comes from. But on a C++ point of view, it remains unusable as long as the problems are not displayed in the same order they have been found in task / extension output. I guess this is something that could come soon, but the nice things always take time.

@bbalp, thanks for trying out the new visualization and thanks for your feedback. I will review your feedback so that I get more context on your comment: "But on a C++ point of view, it remains unusable as long as the problems are not displayed in the same order they have been found in task / extension output.". I am planning on adding more sorting options probably next milestone.

@lszomoru Great! To give you more context, here is the situation.
In C++ there are situations where you get "cascading errors". Particularly when you are using templates. Meaning you missed something, and the compilers continue to try to do its job with the rest of the code, but when errors are the consequence of the first error, you may get a lot of false positives ... like a LOT. Even with the easiest and simplest program, using templates from the standard library itself, forgetting a semi-colon ; in you program could cause like 700 errors ... but only the first one is relevant.
In this case it's pretty easy to just ignore those false-positives coming from files you don't own (standard library headers), but in a complex project you easily get many false-positives from your own code. And it's not always obvious there are false-positives ... So you are doomed to solve the errors in the order the compiler output them. Because the first error, is the only one guaranteed to not be the consequence of another one ...
That's why grouping the problems by files like does the tree-view is absolutely unuseful in this context. And if we get a table-view that doesn't keep the order the errors are discovered from the build task output ... it is not useful either.
So what is needed to fulfil the requirements regarding C++ use cases? Keeping the order of problems (errors, warnings, etc.) found in the build task.
What about sorting? (table-view)

Yes, it is useful to sort the table-view clicking on column headers. It can be useful to sort by source in particular. Even though filtering would fulfil the same goal in this situation.
It would be absolutely fantastic to keep the order within a group ... like if I sort by source 700 problems and there are only 2 sources, keeping the order within the same source.
It is absolutely necessary that we can "remove" any sorting settings to get back to the original order of problems.
If we get dynamic entries ... from the Intellisense for example when clicking on files to view them. Without any sorting set by the user, it is probably expected to get the problems appear first in the list, not after the 700 errors from the previous build task. The user could sort/filter the column by source I guess to get what matters. But it raises the question of which criteria can be used to define an ideal ordering of the problems by default, without any sorting set by the user, when mixing tasks problems and Intellisense problems! And I don't know if currently the problems are added one by one, or in batch, and if it may play a role in the situation ... But the case I have in mind is, running a build task, having 700 errors sorted correctly, so the oldest to the newest, but then getting Intellisense errors, so there are newer, but not at the end of the list ... Maybe adding an error from a source, bring back on top all the problems from this same source? Useful in C++, very specific, maybe not that useful in other languages, or even disturbing to have by default? I don't have a perfect solution.

What about grouping? (tree-view)

Only one situation where it is useful in C++, contextual information about the error can be nested into the error node itself. It seems the CMake extension currently does that with the tree-view, errors are still grouped by file, but also some errors are grouping their own contextual info. Grouping by file is still not useful, but grouping any contextual info is nice. But if we just list the contextual info like any problem in table-view and keep the order, it's fine! Because they appear just after the error they are related to. So grouping is nice, but it's not a requirement in any way.

To sum up, there is only one priority regarding the C++ use case, somehow being able to keep the original ordering of problems from the build task ... and it implies we have a way to know the source, but this part is already done! :) Everything else is an extra.

Clicking on table headers to sort problems would absolutely be useful in my workflow. Pretty much every HDL tool generates hundreds if not thousands of warnings, most of which are useless, but some of which are critical. Each warning has a code associated with it that a problem matcher can extract.
It would be very useful to sort these problems by their error/warning code in order to pick out the relevant bits. The alternative would be to incrementally hide useless error codes, but the problem filter doesn't currently support multiple negative expressions.
As an aside, the "code" column of the table shows "-" for everything, even though copying the JSON from the table shows the code field as defined. Maybe it's expecting a purely numeric value?

As an aside, the "code" column of the table shows "-" for everything, even though copying the JSON from the table shows the code field as defined.  Are you able to reproduce this issue in the latest Insiders release? If so, could you please provide me with the sample project and repro steps so that I can reproduce and investigate the issue. Thank you!

@lszomoru I have ran into the problem described by @darsor recently and made a simple repro: https://github.com/matefriedl/vscode-problem-code-repro

Is this planned at all?
Would someone know if this is able to be worked around in an extension?
I wouldn't mind even simply hardcoding the sorting by my preferred column for now, but I do not wish to be rebuilding code for it each update.
I am sure people have demonstrated enough as to why column sort is required, but let me add my bit anyway.
Simply being able to go by groups of issues without having to constantly create and disable filters would be insanely helpful:

The error/warning view needs an overhaul to improve the DX. I would request to make this "problems view" a combination of table and tree views. Then make the group by, sort by and filter by options controllable by the user. And each of these "_ by" operations should support multiple parameters. Then one may group the problems by source extension and file, then filter by source path and then sort by the message. Or any other way that suits the user.

I think this issue is crucial for a good DX. Please reconsider.

AGREE

There have been GitHub Issues about enhancing the problems in the problem pane before this issue, and they all got closed. This one survived because enough persons managed to gather to support it and avoid automatic closing. If now Microsoft itself closes it. I think it's cooked. 🫡
Microsoft seems to think it's more important to focus on GitHub Copilot to figure out what to do with the problems, instead of making them usable. 😁
Anyway, I love VSCode, I thank Microsoft for this great software, but it seems their priorities will lead me to consider alternatives... Having a good, functional, useful problem pane is something I consider of high value for such software. I thought it was obvious for any dev, but it seems it isn't. Good luck Microsoft with your new priorities for VSCode, beware of Enshittification.


Confirm Ending Is Not Clear for One Test

Challenge [Confirm the Ending])
User Agent is: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36.
My code passes all tests for this challenge except  the string and target in bold below. According to my understanding the code  should pass. So I am not asking for help, but I want an explanation why my code passess all tests except the string below. If not, it seems like there may be a bug in the test.
My code:

function confirmEnding(str, target) {
    var last = str.substring(-1);
  var last2 = target.substring(-1);
  if (last == last2) return true;
  else if (last !== last2) return false;
}

**confirmEnding("Walking on water and developing software from a specification are easy if both are frozen", "specification") )****

When I run your code, it doesn't pass multiple tests.

If you get stuck or have questions with a challenge in the future, please first ask questions to the Help Room. Happy coding!

Thats interesting cause when I ran it I was only missing the first . Anyway I have chnaged it now. Yo can close this issue


nixStatic: make relocatable

Motivation for this change
Keep pushing to make the static nix binary more easily relocatable. This makes it easier to "install" nix by throwing a binary around.
Related work:

https://github.com/DavHau/nix-portable
https://github.com/nix-community/docker-nixpkgs/pull/29

This PR includes the changes from https://github.com/NixOS/nixpkgs/pull/159459 to remove a reference to libunistrings' character table.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Maybe it's better to do this in the nix-static package in the nix flake? Because that's what we release.

Maybe it's better to do this in the nix-static package in the nix flake? Because that's what we release.

The majority of changes here seem to fix static packages in nixpkgs, not the nix package itself. Also should we not have nixpkgs's nix aligned with the flake anyway?

Maybe it's better to do this in the nix-static package in the nix flake? Because that's what we release.

I'm happy to do it both ways. I noticed that the package definitions have diverged quite a bit between both repos. Maybe it makes sense to merge them again?

The audit package is currently broken in staging, which prevents building nixStatic.

I'm happy to do it both ways.

Then it's better to do it upstream, because then we can start releasing the static binary as part of the Nix release process (so for instance people could download a single file https://nixos.org/static-nix pointing to the latest release).

I want to retract my statement. I had a look at the nixos/nix flake.nix and there is too much code in there for me to be productive in it. I agree in principle but I would have to first refactor the flake.nix and that really feature-creeps my effort. I would rather have this merged, get something out, and then port the effort upstream in a second phase.

We still need https://github.com/NixOS/nixpkgs/pull/159459 to be merged first.

You can grab unstable releases from https://github.com/nix-community/nix-unstable-installer/releases


Added support for clib ( https://github.com/clibs/clib ).

Please consider this PR for clib support! Let me know if there are any questions :+1:!
Thanks!
- Jonathan

+1

I'm not really willing to maintain yet-another-package-manager, so I won't include this here.
Thanks for work anyway.


Slow tests

Hi, my team came across with slow test with playwright and nodejs.
Do you have any way of debugging the reason why the speed is low?

@swood at least you can add DEBUG=pw:* to Playwright command and check which operations are slow:
DEBUG=pw:* node index.js

Also I would check that you have all necessary firewall rules to access tested webapp from Moon cluster.

@vania-pooh  thank you for your suggestions. I will come back soon after my team try the debug.

Im having the same problem but with moon v1 and protractor tests , does someone have the same issue with moon v1 ?

@pgonzTest are browser sessions being started slowly or overall test execution is slow after browser has started?

Hi @vania-pooh , overall test execution is slow after browser has started.

@pgonzTest could be then related to computing resources assigned to browser pods. Try to increase them.


Update ZAP installation description

Update ZAP installation description:

Add link to platforms that CIPD downloads
Remove statement about arm since it is done automatically since https://github.com/project-chip/connectedhomeip/pull/26636

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

@farshidtz please also fix restyle errors - I believe restyler wants to re-align things a bit in the md file. You can run ./scripts/helpers/restyle-diff.sh or apply the patch that you get by clicking Details on the restyled CI check:

@bzbarsky-apple could you please take another look? I've addressed your feedback.


Undefined symbol when importing github.com/klauspost/compress/flate package

The following program snippet triggers an error:
$ yaegi
> import "github.com/klauspost/compress/flate"
1:22: import "github.com/klauspost/compress/flate" error: /home/marc/go/src/github.com/klauspost/compress/flate/huffman_bit_writer.go:104:11: undefined: literalCount

When checking the imported source, the symbol seems to be well defined.

update, as of now, the error seems to be:
run: ./issues/865/sample.go:3:8: import "github.com/klauspost/compress/flate" error: /Users/mpl/src/github.com/klauspost/compress/flate/deflate.go:615:10: cannot use type *github.com/klauspost/compress/flate.compressor as type


Telegram notification [returning 500 Server Error]

Is your feature request related to a problem? Please describe.
I was trying to get the telegram notification to work, but it was always returning a 500 Server Error…
I had the correct token in the correct ".env" variable plus the chat ID, so what was going on?
Well, I mistakenly added the "BOT chat ID" rather than "MY chat ID"..
Bots can't send messages to bots, ergo the 500 Server Error.
Describe the solution you'd like
Perhaps a clear notification about which "chat ID" should be added as the recipient?
Or not, maybe I was the problem 😅
Thanks

Not really a bug but maybe somewhere where the docs could be clarified. Did you follow these directions and got hung up? https://docs.speedtest-tracker.dev/settings/notifications/telegram#setting-up-telegram

done


Saved Events Visible

Saved Events Visible
User Story
AS AN employee with a busy schedule
I WANT to add important events to a daily planner
SO THAT I can manage my time effectively
Acceptance Criteria
GIVEN I am using a daily planner to create a schedule
WHEN I refresh the page
THEN the saved events persist

This has been completed


How do I do company-complete?

What are you trying to achieve?
When given a list of options from company mode, I want to select one. Tab does company-complete-common, taking you up to the point where they diverge, but further hitting of tab just cycles through the options.
Obviously, I can redefine the keymap myself (probably adding RET as 'company-complete, but I feel like I must be missing something since surely completing is the whole point of company mode. Seems a bit weird if the flow is to type something further then press complete again, ad nausea.
So I think I just haven't worked out what the workflow is, or what keybinding to press. Any pointers?
System information

emacs   version    26.3
        features   XPM JPEG TIFF GIF PNG RSVG SOUND DBUS GSETTINGS GLIB NOTIFY LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD
        build      Apr 21, 2020
        buildopts  (--prefix=/nix/store/l0fqjrzdbhhdyh18jnqf34sr4zp6msqh-emacs-26.3 --disable-build-details --with-modules --with-x-toolkit=gtk3 --with-xft CFLAGS=-DMAC_OS_X_VERSION_MAX_ALLOWED=101200)
        windowsys  x
        daemonp    daemon
doom    version    2.0.9
        build      HEAD -> develop 3a5ef316f 2020-04-19 22:04:12 -0400
        dir        ~/.doom.d/
system  type       gnu/linux
        config     x86_64-pc-linux-gnu
        shell      /nix/store/v2d465r8lvdlzl5dnz81b7199lhqngcl-zsh-5.8/bin/zsh
        uname      Linux 5.6.2 #1-NixOS SMP Thu Apr 2 06:02:32 UTC 2020 x86_64
        path       (/usr/local/bin/ /sbin/ ~/bin/ ~/.npm-packages/bin/ ~/ben/bin/ /run/wrappers/bin/ ~/.nix-profile/bin/ /etc/profiles/per-user/ben/bin/ /nix/var/nix/profiles/default/bin/ /run/current-system/sw/bin/ ~/go/bin/ ~/.emacs.d.doom/bin/ /nix/store/l0fqjrzdbhhdyh18jnqf34sr4zp6msqh-emacs-26.3/libexec/emacs/26.3/x86_64-pc-linux-gnu/)
config  envfile    envvar-file
        elc-files  0
        modules    (:completion company (helm +fuzzy) :ui doom doom-dashboard doom-quit hl-todo modeline nav-flash neotree ophints (popup +all +defaults) pretty-code unicode vc-gutter vi-tilde-fringe window-select workspaces :editor (evil +everywhere) file-templates fold multiple-cursors rotate-text snippets :emacs (dired +icons) electric vc :term eshell :tools debugger direnv eval :checkers syntax spell :tools gist (lookup +docsets) macos magit (pass +auth) rgb upload :lang clojure data emacs-lisp markdown nix (org +dragndrop +ipython +pandoc +present) python racket rest ruby scheme sh web :email (mu4e +gmail) :app calendar (rss +org) :config (default +bindings +smartparens))
        packages   ((org-super-agenda) (org-gcal) (emojify) (org-alert) (google-maps) (helm-spotify-plus) (git-link) (org-superstar))
        unpin      (n/a)
        elpa       (n/a)

probably adding RET as 'company-complete

Are you implying that RET does not already do this? Because it should, and I can confirm this is the case in vanilla Doom and Emacs. Check your config, in case you've bound your own key to RET on company-active-map.

Huh. It definitely is bound in company-active-map (and I've not changed that). I had assumed it was overridden here due to a quick grep in the code base, but that's only related to company-tng which I'm not using.
On further testing it's only happening in Clojure buffers. RET works fine in emacs lisp buffers. I can't check right now, but I'll poke at it a bit further later.

I am having same issue in clojure buffers. Three days ago I doom up and that's when it all started. Before that, every thing worked as expected.
C-j inserts new line instead of moving.

C-n: seems to pick something common and complete it, another press does nothing

tab: when pressing multiple times only moves sometimes, and not in any specific way.

I had a similar issue and fixed it by applying https://github.com/hlissner/doom-emacs/issues/1335#issuecomment-605706363
I can know navigate across completion propositions with up/down or ctrl + j/k
Thanks @thiagokokada

Thanks  @bcachet  and @thiagokokada . That helped.
I added a more inclusive workaround snippet for those interested https://github.com/hlissner/doom-emacs/issues/1335#issuecomment-619022468


Fix broken links in Rusoto STS docs

For issue #817. I created a PR yesterday but closed it accidentally.

👍 thank you!


server.sh error

Using the current main branch, running server.sh produces an error:
% ./server.sh db upgrade
ERROR: No container found for server_1

Resolved; not a bug. This was because database username/password were incorrect.
Added a Troubleshooting section to the README, in my local branch.

Resolved; not a bug. This was because database username/password were incorrect.
Added a Troubleshooting section to the README, in my local branch.


Add Xcode project

It was not trivial to open Swifton in Xcode.
Add Xcode project (built with swift build --generate-xcodeproj), so it is easier
to contribute for Xcode users.

@weby thanks!


Dockerizing vagrant deploy

Have you ever thought of moving the vagrant deploy to a docker image? Building and hosting the image would probably make the deployment of the dev environment a bit quicker. I would be happy to throw up a PR if you're interested.

I am not familiar with Docker and the terminology, so unfortunately I can't comment on whether your idea makes sense and will be valuable for other people. But if you can provide a change that covers your use case and doesn't break anything for other people, you can send a PR.

I am not familiar with Docker and the terminology, so unfortunately I can't comment on whether your idea makes sense and will be valuable for other people. But if you can provide a change that covers your use case and doesn't break anything for other people, you can send a PR.

If someone wants to build the firmware with docker - I already did it here:
https://github.com/eh2k/eurorack/tree/main/braids_tht
You can take the dockerfile, and modify the last lines.
The dockerfile is basically a copy of the 0_install-oolchain.sh script.
@pichenettes, with docker, you could easily set up a ci/cd pipeline with GitHub Actions - so you could provide fresh built bin/hex/wav files automatically everytime you pushing to the git repo.

If someone wants to build the firmware with docker - I already did it here:
https://github.com/eh2k/eurorack/tree/main/braids_tht
You can take the dockerfile, and modify the last lines.
The dockerfile is basically a copy of the 0_install-oolchain.sh script.
@pichenettes, with docker, you could easily set up a ci/cd pipeline with GitHub Actions - so you could provide fresh built bin/hex/wav files automatically everytime you pushing to the git repo.

@pichenettes @byndcivilization you can take a look here: https://github.com/archont94/mutable-env :).


nn-converter: add support for "numeric dates"

The neural network might decide to generate "new Date ( number )"
because that's valid syntax. Later, when we normalize we fail
because there is no DATE token. The syntax generated by the neural
network is incorrect, but we don't want to crash.

This is only necessary to evaluate recent Thingpedia models, so it's not a huge priority.

Pull Request Test Coverage Report for Build 1032

3 of 7 (42.86%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.03%) to 80.403%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

lib/nn-syntax/tonn_converter.js
3
7
42.86%

Totals

Change from base Build 1030:
-0.03%

Covered Lines:
8770

Relevant Lines:
10502

💛  - Coveralls


typo on page 165

In the text below the orange box, the second sentence ends with "You can find see this with:"
I guess this is a typo

Thanks, added to the errata.


Disconnect colab after 5-10 minutes

Why does colab stop after 5-10 minutes?
Is this problem solvable?
Will this problem be solved by buying the pro version?
Or does it not matter what version it is, it is against the rules and policies of colab?

Why does colab stop after 5-10 minutes? Is this problem solvable? Will this problem be solved by buying the pro version? Or does it not matter what version it is, it is against the rules and policies of colab?

https://github.com/RVC-Project/Retrieval-based-Voice-Conversion-WebUI/issues/1123


installbreakup

Based on Gabriel's installbreakup branch
DESKTOP-4376
@keybase/react-hackers

Can we do a hangout to explain this code maybe? I have no idea how to review this

Sure, anyone else or just us?

@cjb Just rebased again

@keybase/react-hackers


Installing Python library with pip requires Bazel

Describe the bug
Installing Tink with pip leads to an error which requires that Bazel is required in the build environment, however, this is not documented in the README section about installing with pip: https://github.com/google/tink/blob/master/docs/PYTHON-HOWTO.md#setup-instructions
To Reproduce
see: https://github.com/GoogleCloudPlatform/python-docs-samples/pull/5554
build logs: https://source.cloud.google.com/results/invocations/4fd9109f-6d12-439b-8cd9-184c6c148bf3/targets/cloud-devrel%2Fpython-docs-samples%2Fpython3.6%2Fpresubmit/log
Error messages, stack traces, etc.
Collecting tink==1.5.0
  Downloading tink-1.5.0.tar.gz (132 kB)
    ERROR: Command errored out with exit status 255:
     command: /workspace/cloud-sql/mysql/client-side-encryption/.nox/py-3-6/bin/python -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-4d32fzby/tink_abe5aa1dcbfb43c1be75080f6727880b/setup.py'"'"'; __file__='"'"'/tmp/pip-install-4d32fzby/tink_abe5aa1dcbfb43c1be75080f6727880b/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' egg_info --egg-base /tmp/pip-pip-egg-info-9vsrzphv
         cwd: /tmp/pip-install-4d32fzby/tink_abe5aa1dcbfb43c1be75080f6727880b/
    Complete output (1 lines):
    Could not find bazel executable. Please install bazel tocompile the Tink Python package.

Version information

Language: Python
Version: 1.5.0
Environment: Python3, Ubuntu 20.04(in docker container)

It looks like you are using Python 3.6, which is not supported, as Tink relies on some features which available only starting in Python 3.7. There are binary releases available for Python 3.7 and 3.8 available, which will not require to install Bazel.

We are seeing this issue in Cloud Shell (https://shell.cloud.google.com), even when using python 3.7.
You can repro this by navigating to https://shell.cloud.google.com and then running sudo pip3 uninstall -y tink && pip3 install tink.
Note that bazel will be run, and a build error will result.

Would it be possible to upgrade the pip version on Cloud shell? Upgrading pip (pip3 install --upgrade pip), fixed the error for me and allows to install the binary wheels.

Unfortunately, we've looked at upgrading the version of pip3, and that causes other issues.
This appears to be an issue with the OS we are using. We are currently running debian:buster (current stable debian release) and install pip3 using the standard debian repos. There are numerous warnings about the older supported version of pip3 in debian around the web [1][2][3], and that manually upgrading pip is a bad idea and may cause issues.  Instead, the recommended workaround to upgrade pip3 is to use virtualenv.
The version of pip3 should be updated with the stable release of debian:bullseye, but that may be a few months off.
[1] https://cryptography.io/en/latest/installation/#rust
[2] https://pip.pypa.io/en/stable/installing/#installing-with-get-pip-py
[3] https://pythonspeed.com/articles/upgrade-pip/

This issues has not been resolved as of now

Getting the same error - MBP M1 Python 3.8.13 = pip-22.3.1

Note that Tink 1.7.0 for Python has now been released, see https://pypi.org/project/tink/.
Is this still an issue?
I have tried to install tink on https://shell.cloud.google.com/ and it works.

I'll close this now. Please re-open if there is still an issue.

@juergw I still see this issue even in 1.7.0. Would you mind reopen this while we are collecting info?


add a code execution feature

Add functionality: send a POST request, execute code, and render the execution result onto the webpage.
I'm trying to add a functionality to run code on a webpage. I've already added a code input box and an execute button, but I'm unclear why I can't retrieve the values entered in the input box.

Quartz is a static site generator, it doesn't evaluate code. You can use third party tools for this


Incorrect S3 bucket name

I have a serverless service with a semi-long name. For illustration let's call it serverless-my-long-name.
When I deployed, the S3 bucket that was created was named something like serverless-my-long-name-serverlessdeploymentbuck-1234567890123. Note that the last two letters in bucket are missing. As a result, the generated IAM policy that included arn:aws:s3:::serverless-my-long-name*serverlessdeploymentbucket* didn't work. It looks like the max length for an S3 bucket name is 63 characters, so I guess the CloudFormation template is truncating the name to be able to add the random characters on the end.

Good point. I'll need to dig into how serverless is handling this

Unfortunately, I think this is a consequence of https://github.com/serverless/serverless/issues/2791
I'm not going to modify this until serverless have figured out what they are going to do with their bucket names...


Update DrawerView.java

Compile the demo app with two profiles and one draweritem, compile with the version 2.2.0 and the library in this repo just compare it. You 'll see the issues

Please describe what this pull request is for. You make two very unclear code changes...

Watch these videos https://drive.google.com/file/d/0B90o7iqpIsEsTm0xWVpULVpwZGM/view?usp=docslist_api and https://drive.google.com/file/d/0B90o7iqpIsEsOV9YM3pFV3NYMms/view?usp=docslist_api .
My pull request fix that.

profiles do not change.

What I don't understand is this change:
-    private boolean profileListOpen = false;
+	//Before
+//--private boolean profileListOpen = false;
+	//After Salvador Montiel
+    private boolean profileListOpen = true;

That is unlogical since the profile list is closed initially.

I'll most likely merge this by hand as there are some unneeded comments in your pull request. Thanks for working on this annoying bug! I'll leave the first change as it is now:
private boolean profileListOpen = false;

Thanks!. No problemas.

Thanks! No problem.

If you don't change this line
private boolean profileListOpen = false;

to
private boolean profileListOpen = true;

the error is this:
https://drive.google.com/file/d/0B90o7iqpIsEsOV9YM3pFV3NYMms/view

when switching between profiles, the profile list is shown down of DrawerItems


perf: ensure same hidden class for OperatorSubscriber

Description:
See the comments within the change. This PR should help realise one of the advantages of replacing operator-specific subscribers with a general-purpose subscriber - reducing/eliminating megamorphic property accesses within Subscriber.
I've not done any micro optimization/analysis, yet. I'll look at doing that after the version 7 release. However, I think that what's in this PR makes sense and shouldn't be controversial. 🤞
Related issue (if exists): None

I don't understand this CI failure. It seems to have something to do with side effects? I ran test:side-effects:update, but it seemed to generate a surprising number of changes, so ... 🤷♂

So the CI errors are from the side-effects checker. However, I think if you implement the change I'm suggesting (which is to use super._next, super._error, etc), then you won't have those declarations at the top level, and the side-effects checker will be happy again.

So the CI errors are from the side-effects checker.

Yeah, I can see that it's related to that: the checker has no way of knowing (with absolute certainty) that the property accesses are not calls to getters. I was mostly concerned about the diff after running the update script. It seemed to be unnecessarily large. I'll have another look at it after #5898 is merged/addressed, as that problem is now breaking the build.

Sorry, this one almost fell off my radar, @cartant. Thanks for the work!

Sorry, this one almost fell off my radar, @cartant. Thanks for the work!


fix: signedIn event will not fire for passwordRecovery event

What kind of change does this PR introduce?
Currently, signedIn event fires for every passwordRecovery event, which is not so intuitive. This PR prevents from signedIn event from firing for a passwordRecovery event.
Copied over from this js PR https://github.com/supabase/gotrue-js/pull/629/files

The Session recovery succedes after retries test runs infinitely. The expect is run and the test itself finishes, but the vscode test tab shows an infinity running tearDownAll test. That's strange, because the last commit didn't have this issue. Maybe a dependency?

Oh, so the tests are now passing huh? Thanks for re-running them @Vinzent03 !

@dshukertjr No, I pushed a fix to this pr.

Ah, missed it! Thanks for that!


InvalidProjectFileException after upgrading VS2017 to 15.8.0 with Microsoft.Build NuGet 15.6.82

Steps to reproduce
Using Microsoft.Build package (from NuGet in version 15.6.82) added as NuGet reference to a project.
Calling constructor of: Microsoft.Build.Evaluation.Project(projectFile) in one of methods.
Results in throwing Microsoft.Build.Exceptions.InvalidProjectFileException
Stack Trace:
[ERROR] Invalid static method invocation syntax: "[Microsoft.Build.Utilities.ToolLocationHelper]::GetPathToStandardLibraries($(TargetFrameworkIdentifier), $(TargetFrameworkVersion), $(TargetFrameworkProfile), $(PlatformTarget), $(TargetFrameworkRootPath), $(TargetFrameworkFallbackSearchPaths))". Method 'Microsoft.Build.Utilities.ToolLocationHelper.GetPathToStandardLibraries' not found. Static method invocation should be of the form: $([FullTypeName]::Method()), e.g. $([System.IO.Path]::Combine(`a`, `b`)).   C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets
   at Microsoft.Build.Shared.ProjectErrorUtilities.ThrowInvalidProject(String errorSubCategoryResourceName, IElementLocation elementLocation, String resourceName, Object[] args)
   at Microsoft.Build.Shared.ProjectErrorUtilities.ThrowInvalidProject[T1,T2](IElementLocation elementLocation, String resourceName, T1 arg0, T2 arg1)
   at Microsoft.Build.Evaluation.Expander`2.Function`1.Execute(Object objectInstance, IPropertyProvider`1 properties, ExpanderOptions options, IElementLocation elementLocation)
   at Microsoft.Build.Evaluation.Expander`2.PropertyExpander`1.ExpandPropertyBody(String propertyBody, Object propertyValue, IPropertyProvider`1 properties, ExpanderOptions options, IElementLocation elementLocation, UsedUninitializedProperties usedUninitializedProperties)
   at Microsoft.Build.Evaluation.Expander`2.PropertyExpander`1.ExpandPropertiesLeaveTypedAndEscaped(String expression, IPropertyProvider`1 properties, ExpanderOptions options, IElementLocation elementLocation, UsedUninitializedProperties usedUninitializedProperties)
   at Microsoft.Build.Evaluation.Expander`2.PropertyExpander`1.ExpandPropertiesLeaveEscaped(String expression, IPropertyProvider`1 properties, ExpanderOptions options, IElementLocation elementLocation, UsedUninitializedProperties usedUninitializedProperties)
   at Microsoft.Build.Evaluation.Expander`2.ExpandIntoStringLeaveEscaped(String expression, ExpanderOptions options, IElementLocation elementLocation)
   at Microsoft.Build.Evaluation.Evaluator`4.EvaluatePropertyElement(ProjectPropertyElement propertyElement)
   at Microsoft.Build.Evaluation.Evaluator`4.EvaluatePropertyGroupElement(ProjectPropertyGroupElement propertyGroupElement)
   at Microsoft.Build.Evaluation.Evaluator`4.PerformDepthFirstPass(ProjectRootElement currentProjectOrImport)
   at Microsoft.Build.Evaluation.Evaluator`4.EvaluateImportElement(String directoryOfImportingFile, ProjectImportElement importElement)
   at Microsoft.Build.Evaluation.Evaluator`4.PerformDepthFirstPass(ProjectRootElement currentProjectOrImport)
   at Microsoft.Build.Evaluation.Evaluator`4.EvaluateImportElement(String directoryOfImportingFile, ProjectImportElement importElement)
   at Microsoft.Build.Evaluation.Evaluator`4.PerformDepthFirstPass(ProjectRootElement currentProjectOrImport)
   at Microsoft.Build.Evaluation.Evaluator`4.EvaluateImportElement(String directoryOfImportingFile, ProjectImportElement importElement)
   at Microsoft.Build.Evaluation.Evaluator`4.PerformDepthFirstPass(ProjectRootElement currentProjectOrImport)
   at Microsoft.Build.Evaluation.Evaluator`4.EvaluateImportElement(String directoryOfImportingFile, ProjectImportElement importElement)
   at Microsoft.Build.Evaluation.Evaluator`4.PerformDepthFirstPass(ProjectRootElement currentProjectOrImport)
   at Microsoft.Build.Evaluation.Evaluator`4.Evaluate(ILoggingService loggingService, BuildEventContext buildEventContext)
   at Microsoft.Build.Evaluation.Project.Reevaluate(ILoggingService loggingServiceForEvaluation, ProjectLoadSettings loadSettings)
   at Microsoft.Build.Evaluation.Project.ReevaluateIfNecessary(ILoggingService loggingServiceForEvaluation, ProjectLoadSettings loadSettings)
   at Microsoft.Build.Evaluation.Project.Initialize(IDictionary`2 globalProperties, String toolsVersion, String subToolsetVersion, ProjectLoadSettings loadSettings)
   at Microsoft.Build.Evaluation.Project..ctor(String projectFile, IDictionary`2 globalProperties, String toolsVersion, String subToolsetVersion, ProjectCollection projectCollection, ProjectLoadSettings loadSettings)
   at Microsoft.Build.Evaluation.Project..ctor(String projectFile)

Unfortunately, because product is already released it's hard to fix existing issue. Users who updated their VS2017 to version 15.8.0+ will suffer from not being able to use product.
Is there any workaround?
Expected  behavior
Using this constructor should be backward compatible even if user has Microsoft.Build in version older than 15.8.X
Actual behavior
Throws an exception because usage of newly added method which was not present in older version.
Environment data
MSBuild version:
Microsoft (R) Build Engine version 15.8.166+gd4e8d81a88 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.
<IP_ADDRESS>604
VS2017 version:
Version 15.8.1

We recommend that you use the Microsoft.Build.Locator package to avoid this and other mismatched-engine-and-targets problems. There is documentation available at https://docs.microsoft.com/en-us/visualstudio/msbuild/updating-an-existing-application.
The only workaround I can think of is to copy the higher version of MSBuild assemblies over the lower version redistributed with your application. That's a pain but has worked before.

I am experiencing the same issue. Isn't it a problem with versioning policy that minor releases are introducing breaking changes? It makes Microsoft.Build API not reliable. Currently, there are many updates for VS which are released really often, should I expect that each of them can break my integration with Microsoft.Build?
@rainersigwald Microsoft.Build.Locator has limitations - strongest of them is lack of compability with Microsoft.Build.* assemblies (older version of them required by my solution which has some projects targeted to pre-4.6 .NET Framework). Also, to my best knowledge Microsoft.Build.Locator works properly only with VS/BuildTools 15.x. Requirement for me is version 11.0+.
Also, copying assemblies is not the case as well, because there are conflicts between dependant assemblies versions (e.g. System.Collections.Immutable is commonly used as a reference in my pre-4.6 projects).
Is there any other solution?
Is there at least a way to downgrade to 15.7 after 15.8 was installed?

@tobyash86: See https://docs.microsoft.com/en-us/visualstudio/productinfo/installing-an-earlier-release-of-vs2017. This does not cover the Express edition.

Thanks @chm-tm, although I had hope that there is an easier way to do this.

Since I only depend on Visual Studio 15.8, a.k.a latest-greatest, I could resolve the issue by updating the NuGet packages from from 15.6.82 to 15.8.166.
There is still a pit-fall here: We use Professional and Express, which led to different binding redirects. In my case of a project targeting .NET 4.6.1, for System.IO.Compression and System.Runtime.InteropServices.RuntimeInformation.
So, this is clearly less robust than the recommended Microsoft.Build.Locator way.

So the lesson here is do not trust Visual Studio upgrade!?


Vanilla JS - failed to resolve @threlte/core

I tried adding three-inspect to an existing project I have that is written using vanilla js in Vite and ThreeJS
Unfortunately, I run into this error when I try to run dev.
[ERROR] Failed to resolve entry for package "@threlte/core". The package may have incorrect main/module/exports specified in its package.json: No known conditions for "." specifier in "@threlte/core" package [plugin vite:dep-pre-bundle]
node_modules/three-inspect/dist/internal/context.js:1:32:
1 │ import { currentWritable } from '@threlte/core';

Hi @jmschrack ,
I am using Vite with R3F.
I have fixed the issue by installing @sveltejs/vite-plugin-svelte with updating vite.config.js :
import { svelte } from '@sveltejs/vite-plugin-svelte';
export default defineConfig({
  plugins: [...,  svelte()],
})

Thanks for reporting! The vanilla export has been fixed in 0.5.0. Check out the docs for setup or this stackblitz example: https://stackblitz.com/edit/vitejs-vite-pxodhz?file=src%2Fmain.ts


Update docs with default serializer change

@Peque Also, serialization.rst states that we use pickle by default. Is that right?

@ocaballeror That is correct. Currently we use pickle by default for communication between agents. Not the most capable, but it is the fastest (and usually between agents you pass pickable data).


Trumbowyg editor

It would be nice with this editor:
https://alex-d.github.io/Trumbowyg/
What do you think about ?

I do like this editor so its a +1 from me. I do hope this gets added.

It's simple to add Trumbowyg in a simple cms, but unfortunately, code of wondercms seems special. I would like to use markdown too. but I can't figure out how to use in wondercms. If you know someone who is best than me ... cheers

+1 here too
On Jun 10, 2015 21:28, "Seann"<EMAIL_ADDRESS>wrote:

I do like this editor so its a +1 from me. I do hope this gets added.
—
Reply to this email directly or view it on GitHub
https://github.com/robiso/wondercms/issues/5#issuecomment-110973312.

Or something like: http://nicedit.com/
We have to find a way to have a nice editor as a plugin, which would also base64 encode images, making it easier of not having to upload them to a specific directory.
I would also love to see if someone developed something like this. Any takers?

Trumbowyg is nicer than nicedit.

@spencerthayer I agree, it'll be provided as a plugin after releasing the stable version.

WonderCMS 1.0.0 stable is now released, along with it, Trumbowyg is now available as a standalone plugin. You can get in from the forum over here.
I'm marking this as closed, any issues with the editor from now on should be addressed at the plugins repository over here. Special thanks to Yassine Addi for making this possible.


Add tutorial for MASE

I am interested in this one!

Deliverables for MASE tutorial:

Problem Statement — why MASE
How does MASE work in general
How is MASE implemented specifically in GraSpy
At least 1 example using MASE with generative models
At least 1 example using MASE with a  real-world network
At least 1 example of specifying each MASE parameter (Note, this should be included in (4) and (5) ).

How is MASE implemented specifically in GraSpy

This is less important in a tutorial. It is great to have, but may want it to be part of a separate "advanced tutorial" or an appendix to the main tutorial

Hmm, well I wasn't planning on going into too much detail.  Just like a 1-2 sentence summary.

Also, is there any reason why the class called MultipleASE in Graspologic rather than MASE (as it is in the literature)?


Add support for proper lambdas

let a = (
    this: "This",
    that: "That",
    random: MustacheLambda { Bool.random() ? "{{this}}" : "{{that}}" }
)

let template = try MustacheTemplate(string: "{{random}}")
let output = template.render(a)
print(output)

Results in either
This

or
That

@MahdiBM would be interested in your thoughts


Fixed logout problem #3547

When User clicks logout it should go to the Logout screen.
Fixes #3547
What changes did you make and why?
Added updateDatabaseAll method in another Thread.

Codecov Report

Merging #3649 into master will decrease coverage by 0.00%.
The diff coverage is 0.00%.

@@             Coverage Diff             @@
##             master   #3649      +/-   ##
===========================================
- Coverage      6.97%   6.97%   -0.01%
  Complexity      292     292
===========================================
  Files           256     256
  Lines         11740   11742       +2
  Branches        960     960
===========================================
  Hits            819     819
- Misses        10850   10852       +2
  Partials         71      71

Impacted Files
Coverage Δ
Complexity Δ

...n/java/fr/free/nrw/commons/CommonsApplication.java
1.07% <0.00%> (-0.03%)
1.00 <0.00> (ø)

Continue to review full report at Codecov.

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


Fix canvas items being drawn outside clip rects

Fixes #36164

I can confirm it fixes the issue.

Thanks!


Laravel 11.x Compatibility

This is an automated pull request from Shift to update your package code and dependencies to be compatible with Laravel 11.x.
Before merging, you need to:

Checkout the l11-compatibility branch
Review all comments for additional changes
Thoroughly test your package

If you do find an issue, please report it by commenting on this PR to help improve future automation.

:warning: Shift detected a dependency for the laravel/framework. Unless you have a special requirement for depending on the entire Laravel framework, it's recommended to add dependencies for the specific illuminate packages instead.

:warning: Shift detected GitHub Actions which run jobs using a version matrix. Shift attempted to update your configuration for Laravel 11. However, you should review these changes to ensure the desired combination of versions are built for your package.

:alembic: Using this package? If you would like to help test these changes or believe them to be compatible, you may update your project to reference this branch.
To do so, temporarily add Shift's fork to the repositories property of your composer.json:
{
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/laravel-shift/arcanist.git"
        }
    ]
}

Then update your dependency constraint to reference this branch:
{
    "require": {
        "laravel-arcanist/arcanist": "dev-l11-compatibility",
    }
}

Finally, run: composer update


proposal: Go 2: cmd/go: allow relative imports

I think this is a useful feature for library writers, sometimes dependency can not be avoided for a lib.
eg. a proxy lib may use a sql parser written by third party.
The library package layout may look like follows:
myproxy: host on github or sth
  main.go
  └── import "github.com/xxx/sqlparser"
  └── import "github.com/yyy/sometcppoolpackage"

If I want to make the dependency invisible to lib endusers, currently I have to move the dependencies to internal package, and manually change the import path to, maybe:
import "github.com/myname/dbproxy/internal/github.com/xxx/sqlparser"

It's quite ugly and inconvenient.
If internal can be imported easily, then import path will be,
import "internal/github.com/xxx/sqlparser"

quite clear
I noticed that some libs also have inner package, and they currently layout their project like the following:
mqtool is hosted on github.com/xxx/mqtool

mqtool/
  main.go
   └─ import "github.com/xxx/mqtool/cli"
  otherfile.go
  └─ import "github.com/xxx/mqtool/cli"
  └─ import "github.com/xxx/mqtool/logutil"
  ... many many file
  otherfileend.go
  └─ import "github.com/xxx/mqtool/bytes2"

If someone wants to fork this mqtool lib to fix bugs or maintain it as his own, then he will meet a lot problems (to modify endless import paths).
Someone may say that he can git clone this project to the correct path, but go get can not support such case, which is really weird (because go get will put this project to the forked path, not the original path).
If internal package can be found in relative path, I think things can go much better :-)
Then the above project may become like this:
mqtool is hosted on github.com/xxx/mqtool

mqtool/
  main.go
   └─ import "internal/cli"
  otherfile.go
  └─ import "internal/cli"
  └─ import "internal/logutil"
  ... many many file
  otherfileend.go
  └─ import "internal/bytes2"

This is not really about internal at all, since you could have the same situation with non-internal subdirectories you want to import. For better or worse we've decided that having fully-qualified paths is useful for being able to understand imports when you see them. It's not clear we want to break that now.

Can this be reopened as a proposal for Go 2 or should I create another proposal?
I'm especially asking for something similar to this:
mqtool is hosted on github.com/xxx/mqtool

mqtool/
  main.go
   └─ import "internal/cli"
  otherfile.go
  └─ import "internal/cli"
  └─ import "internal/logutil"
  ... many many file
  otherfileend.go
  └─ import "internal/bytes2"

It doesn't make sense to hard-code the platform / domain I'm going to host my code on inside the code itself.

I'll reopen for Go 2.

While I'm not a fan of internal/.., something like this ("project-relative imports") should be considered for Go 2. internal could be a package name, can it? So this could potentially break existing code.
Instead, I'd prefer import "/x/y" (leading slash indicates project-relative import, / is the root of the project)
Hard-coding the platform / domain one intends to host code under should not be part of the code itself, moving code between different hosting providers (or even renaming the project) should be easier and should not require a.) changes to the source code itself (s/old-domain/new-domain/) b.) the use of a self-hosted go-import-providing server: example which gets the source from diverse hosting platforms but uses a single, static custom domain name.
This proposal basically is a requirement for proposal: incrementally modify the Go toolchain to work without GOPATH

I would discourage relative imports to begin with. They can lead to unexpected results. The current model of paths being GOPATH dependent works really well and can be adapted towards a package oriented workflow rather easily.

This proposal basically is a requirement for proposal: incrementally modify the Go toolchain to work without GOPATH

I would disagree about that.

I would discourage relative imports to begin with. They can lead to unexpected results

For example?

I would disagree about that.

Why? How else would the Go compiler toolchain know if an import should be retrieved from $GOPATH / vendor/ (i.e. external packages) or from the current project?

I'd share another example where this could be useful. Let's assume there is a project with the following structure:

github.com/janeRoe/myapp

main.go - imports models, handlers, and routes:

import (
	"github.com/janeRoe/myapp/handlers"
	"github.com/janeRoe/myapp/models"
	"github.com/janeRoe/myapp/routes"
)

handlers/

models/

routes/

I want to fork the project and make a few changes to, say, routes. I click GH "Fork" button and get a copy of the project that now lives under github.com/johnAnonDoe/myapp. But the main.go's imports still point to the old "github.com/janeRoe/myapp/...". That means the following requirements cannot be satisfied at the same time:

Changes to the routes/ subpackage must affect my fork (which, in case of absolute import paths, requires update of the main.go).
My fork should be go getable.
It should be easy to merge the changes back to the initial repo.

Because currently Go packages are distinguished by import paths, support for relative import paths would mean that very early on in the build process the relative imports would have to be converted to full paths.
As far as I can see the only time it is useful to have a relative import path is when you are going to move a set of packages around.  That seems to happen relatively rarely, and it would be straightforward to write a tool to move a set of packages while rewriting the import paths.  I'm not aware of any such tool today, but if we had one would there still be a need for relative import paths?

@ianlancetaylor , if I fork other people's project on github, and want to contribute back to this project.It  seems there is still no way to keep the forked project go gettable and the import paths inside this forked project to be same with the original's.
If I want to use it as my own, I have to rewrite the import path, and if I want to contribute, I have to rewrite the import path again.

@cch123 Seems like you may be assuming that the other person's project is already using relative imports, which it most likely is not.

@ianlancetaylor ，for example，I forked etcd project，this file https://github.com/coreos/etcd/blob/master/discovery/discovery.go contains imports of the same project's paths:
	"github.com/coreos/etcd/client"
	"github.com/coreos/etcd/pkg/transport"
	"github.com/coreos/etcd/pkg/types"

After forked to my own repo, the import path should be:
	"github.com/cch123/etcd/client"
	"github.com/cch123/etcd/pkg/transport"
	"github.com/cch123/etcd/pkg/types"

If I don't change the import paths and then execute
go get github.com/cch123/etcd

Then the project will appear at $GOPATH/src/github.com/cch123/etcd
But the import paths inside this project are not correct. I'm not assuming other people is using relative imports, but I mean if we could support some way(eg.relative import? or some way of internal usage) to unbind the import path with the host address, I will not be forced to change the import paths back and forth.

@cch123 I recommend you read http://blog.sgmansfield.com/2016/06/working-with-forks-in-go/ on how to work with forks if you want to contribute changes to a project. If you want to use your fork instead of the original place, dep supports this (and I think vgo may support this at some point, if not already).
Relative import paths is something I would love to see gone in Go2 as they are a constant source of pain.

@dlsniper, use git remote can solve this fork problem. But your forked project cannot exist the same with the original in your $GOPATH.

I agree with @cch123 forking packages with subpackages in them is a huge pain.
Changing origins is not a solution (you can't go get them). Dep's support for forks is a band-aid.
You can actually abuse the vendor system to solve this problem. Just put your subpackages into vendor, and you've got project-relative imports, you can fork the package easily without having to rewrite everything. Obviously that's an ugly hack, but I'd like to see something like that as a solution to this problem, maybe not full relative imports.

I agree with @cch123 forking packages with subpackages in them is a huge pain.
Changing origins is not a solution (you can't go get them). Dep's support for forks is a band-aid.

@nkovacs this is not a band-aid, nor would relative import paths solve anything in this case. dep allows something that's considered basic functionality for package managers. There is nothing new or different for Go compared to other languages.

Just put your subpackages into vendor, and you've got project-relative imports, [...]  We have it for reproducible builds. It allows guaranteed that, if committed, everyone gets the same identical source code regardless of environment.

but I'd like to see something like that as a solution to this problem, maybe not full relative imports.

I don't understand how relative imports solve any problem that you have.

If I fork a go package with subpackages, I have to change all the imports to its subpackages in it if I want people to go get it, or govendor fetch it, or dep ensure it, or whatever.
Both composer and npm allow you to specify a temporary fork instead of the canonical package.  You can't do that in go.

This is not why we have the vendor directory. We have it for reproducible builds. It allows guaranteed that, if committed, everyone gets the same identical source code regardless of environment.

Of course not. I said you can abuse it to fix the problem.

I don't understand how relative imports solve any problem that you have.

I wouldn't have to do this: https://github.com/nkovacs/ifacemaker/commit/c327e8df5f99e0ba97fda4acde3ca972d36963d1

If I fork a go package with subpackages, I have to change all the imports to its subpackages in it if I want people to go get it, or govendor fetch it, or dep ensure it, or whatever.

Which, compared to the effort of forking, modifying and maintaining a project, takes absolutely zero effort.

 You can't do that in go.

To give you the counter-point for the PHP example. You would have to override the autoload process to tell it that your project provides now the reference for the namespace you want to use, rather than the original package, see https://github.com/Seldaek/monolog/blob/master/composer.json#L46-L48
Now Go being different than PHP is is allowed to behave in a different way. If you ask me, instructing dep to fetch the source from a different place is a lot more cleaner and obvious than digging in the package.json and figuring out where the autoloader will perform the operation for loading certain package.
And even in PHP or in Go world, allowing relative import paths suffer greatly when introducing symlinks into play (which at least for me in the PHP world have been a source of needlessly spent hours of debugging why something doesn't work in a particular setup of a developer / environment or in bug reports that I had to handle).
As far as I can tell, the whole argument is: please allow relative import paths so we don't have to run a search & replace operation for forks we want to use as main source but we don't want to use dep and we don't want to have a commit for that operation and we'll never backport changes to upstream (due to the import path change). Would this be an accurate depiction of the case?

@dlsniper , if the official vgo can support publish and get a forked library without manually replace the imports, I think it's ok. But before vgo, you cannot control your user's package management tool, maybe some people choose godep or some other tool which doesn't support such compile time import search. They'll be in trouble.

@dlsniper , if the official vgo can support publish and get a forked library without manually replace the imports, I think it's ok.

@cch123 that's what dep can do today (and I think glide as well).

But before vgo, you cannot control your user's package management tool, maybe some people choose godep or some other tool which doesn't support such compile time import search. They'll be in trouble.

dep, which is the recommended solution for package management until vgo matures, supports this. Much like gofmt or other tools, people can either use it or not, but if the majority of the community uses that, then the problem is on the users that choose to ignore it, not on the rest.
I hope this helps understanding where my point of view comes from and why I think it's important to address the underlying issue that causes the need for this change as well, not just agreeing to do the change.

Ok, let's take npm as an example.
You have a library called awesome-package, which contains a subdirectory utils. In your code, you can just use require("awesome-package") or require("awesome-package/utils").
 No confusion there. But I don't have to change the code in super-awesome-package, because it uses require("./utils").
The same thing could work with go. You would import github.com/user/awesome-package or github.com/user/awesome-package/utils, and if you want to use the fork,
github.com/anotheruser/super-awesome-package or github.com/anotheruser/super-awesome-package/utils.

If you ask me, instructing dep to fetch the source from a different place is a lot more cleaner and obvious than digging in the package.json and figuring out where the autoloader will perform the operation for loading certain package.

I don't think it's any better (or worse) to have to dig into dep's lockfile (or wherever it stores this info) to find out that it's not actually importing github.com/user/awesome-package, but github.com/anotheruser/super-awesome-package.
I would much prefer it if my code actually imported github.com/anotheruser/super-awesome-package.

And even in PHP or in Go world, allowing relative import paths suffer greatly when introducing symlinks into play

What do symlinks have to do with relative imports? You can use symlinks with absolute imports too.

As far as I can tell, the whole argument is: please allow relative import paths so we don't have to run a search & replace operation for forks we want to use as main source but we don't want to use dep and we don't want to have a commit for that operation and we'll never backport changes to upstream (due to the import path change). Would this be an accurate depiction of the case?

No, I think that's a bit of a loaded question. Maybe I don't want to use dep because it's slow or not mature yet or because it can't be used for installing tools. Also, instructing it to use a fork is an extra step and makes it not obvious that you're importing the fork (see above).
Maybe I do want to backport changes upstream, but the upstream project is inactive, or they don't agree with the direction I've taken and I have to fork.
Sure, I can run a search & replace, but it feels like I'm working around a deficiency in the language.

@ianlancetaylor - I just happened upon this issue to add my weight to the argument for removing relative imports in Go 2.
As this issue stands, I think the title is somewhat confusing because there doesn't appear to be the context referenced anywhere that the current plan is to remove them (unless I'm missing something).
Can I suggest we tweak the title to proposal: Go 2: cmd/go: continue to allow relative imports? Because:

it's currently possible (yet very much discouraged, with good reason) to use relative imports
the plan as things stand is to remove them for Go 2

Relative imports barely work today.  They don't work inside of GOPATH.  They only really work when compiling individual files.  I think this proposal is about allowing relative imports inside of GOPATH.
I'm not myself aware of any particular plan regarding relative imports in Go 2.  Perhaps there has been some discussion of them in the vgo context, I don't know.

Relative imports barely work today.  They don't work inside of GOPATH.  They only really work when compiling individual files.  I think this proposal is about allowing relative imports inside of GOPATH.
I'm not myself aware of any particular plan regarding relative imports in Go 2.  Perhaps there has been some discussion of them in the vgo context, I don't know.

Since the functionality is already available via the vendor directory, it would be sufficient to allow the import of vendor/internal/...'. As of Go2 the vendor` directory could then be renamed to something more matching (maybe just 'r' for 'relative').

It is inexcusable that the golang devs didn't think about the impact of forcing absolute imports on the fork/branch/pull-request github workflow.

I, too, ran into the issues pointed out by @johnDoe2018 and @cch123 recently. I tried the proposed solution involving dep ensure, but I could not get it to work for internal packages. I tend to agree with @cch123 that this dep functionality is a bit of a band-aid. From the documentation:

source rules are generally brittle and should only be used when there is no other recourse.

I am convinced that there are good reasons to completely remove relative paths from Go and so I'll leave that discussion to people more familiar with Go. On the other hand I think that forking repositories, creating pull requests and validating them on CI systems are part of daily developer life. The current need to adress packages inside my own project by their full repository path seems to conflict with that workflow.

The underlying problem seems to be solved by go modules and their support for "github-forking etcd", with a git clone fetching whatever clone you want, while avoiding all the downsides of relative imports. And writing code using forked libraries is supported with replace directive in go.mod.

How about treating import paths that start with / to be relative to the root of module? So the following code blocks are equivallant?
	"github.com/coreos/etcd/client"
	"github.com/coreos/etcd/pkg/transport"
	"github.com/coreos/etcd/pkg/types"

With module relative import
	"/client"
	"/pkg/transport"
	"/pkg/types"

Since the module name is present from go.mod, this will not require any significant changes to the import machinery.

I would say relative paths are extremely important whenever developing an application.  If my understanding is correct from this conversation any "module" I create needs to be moved to the go PATH rather than simply referencing it from "./myModule" or "./myModule.go".  This seems extremely inconvenient and while not being able to auto-fork or pull down from a github repository as my goal, but rather just use modules I make locally - it seems relative pathing would make life so much easier.  (IE:  Look at JS)

With our current module ecosystem, our use of replace directives in go.mod files, the introduction of go.work files, the existence of the gomvpkg command, we're at a point where it's clear that are not going to start supporting relative imports.  Closing this issue.

It feels to me as though the proposal to use import paths starting with slash as same-module imports would be amenable to Go 1, at the very least by providing a suitable directive in go.mod if necessary. I don't see why this needs to be deferred to Go 2.
One would then have 3 styles of import:

import pkg // standard Go library
import domain/path/module/pkg // external module
import /pkg // relative to root of current module

The module fork-then-PR use-case (or even fork without PRs) is the most persuading of the need for such functionality.
Renaming or relocating a module may be unusual in some patterns of use but overall, not sufficiently unusual that the pain need not be alleviated.


[CI] Archive config.log from ICON builds in case of failure

Not relevant enough. Too icon specific.


Add the new batched linear solver sample

Adding a New Sample(s)
Description
This sample shows how to solve batched linear systems using oneMKL and OpenMP target offloading. The example codes are written in Fortran, but the concepts generalize to C and C++. They have been reviewed by oneMKL developers (Sarah Knepper, Louise Huot) and Fortran compiler TCEs (Shiquan Su, Ron Green).
Checklist
Administrative

[X] Review sample design with the appropriate Domain Expert: Sarah Knepper, Louise Huot
[ ] If you have any new dependencies/binaries, inform the oneAPI Code Samples Project Manager

Code Development

[ ] Implement coding guidelines and ensure code quality. see wiki for details
[X] Adhere to readme template
[ ] Enforce format via clang-format config file
[X] Adhere to sample.json specification. https://github.com/oneapi-src/oneAPI-samples/wiki/sample-json-specification
[ ] Ensure/create CI test configurations for sample (ciTests field) https://github.com/oneapi-src/oneAPI-samples/wiki/sample-json-ci-test-object
[ ] Run jsonlint on sample.json to verify json syntax. www.jsonlint.com

Security and Legal

[ ] OSPDT Approval (see Project Manager for assistance)
[ ] Compile using the following compiler flags and fix any warnings, the falgs are: "/Wall -Wformat-security -Werror=format-security"
[ ] Bandit Scans (Python only)
[ ] Virus scan

Review

[ ] Review DPC++ code with Paul Petersen. (GitHub User: pmpeter1)
[ ] Review readme with Tom Lenth(@tomlenth) and/or Project Manager
[X] Tested using Dev Cloud when applicable

Does this sample needs to use double precision? It is not supported on gen12

The header of both source files says to add -DSP to use single precision.