Godot 3.0 support?

Does Escoria supports Godot 3.0, or are there plans to do so?
Thanks for your great work!

Of course, yes :) . We will try to release it on Asset Store once Godot 3.0 is released.

Well it probably doesn't support Godot 3.0 out of the box right now, so reopening this issue to keep track of the porting effort. The current master should likely be branched off to a 2.x branch, and we can update master for 3.x.

Godot 3.0 alpha1 just released. Any progress about this issue?

We need to make more tests since modifications have been made on TSCN format. Issue godot#8465 is still open, we need to have it fixed first.

Job's done! Closing.

Great!


chore(deps): upgrade dependencies

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-k8s-24-main" workflow

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 2095

Questions ?
Please refer to the Backport tool documentation


Vulnerability roundup 101: subversion-1.10.6: 1 advisory [7.5]

search, files

[ ] CVE-2020-17525 CVSSv3=7.5 (nixos-20.09, nixos-unstable)

Scanned versions: nixos-20.09: c7e905b6a97; nixos-unstable: f5e8bdd07d1.
Cc @edolstra
Cc @lovek323

See also: #91001

Fixed with update to 1.10.7: https://github.com/NixOS/nixpkgs/commit/b660a15ba8845592942589f4d5d215134d8bd7b2 (is backported)


transformPage

Describe the problem
Until recently, the way to manipulate HTML was to do something like this in handle:
export async function handle({ request, resolve }) {
  const rendered = await resolve(request);

  if (rendered.headers['content-type'] === 'text/html') {
    rendered.body = rendered.body.replace(/old/g, 'new');
  }

  return rendered;
}

With #3384, we're now dealing with Response objects meaning that you'd now do this:
export async function handle({ event, resolve }) {
  let response = await resolve(event);

  if (response.headers.get('content-type') === 'text/html') {
    const body = await response.text();
    response = new Response(body.replace(/old/g, 'new'), {
      status: response.status,
      headers: response.headers
    });
  }

  return response;
}

For all the advantages brought by using Request and Response, this does not feel like an improvement. Verbosity aside, doing await response.text() and creating a new response feels like a lot of overhead.
Describe the proposed solution
We could do this:
export async function handle({ event, resolve }) {
  return await resolve(event, {
    transformPage: ({ html }) => html.replace(/old/g, 'new')
  });
}

Then this line... https://github.com/sveltejs/kit/blob/0cca67063a4f38806eb4428b76548b8d948035ca/packages/kit/src/runtime/server/page/render.js#L218 ...would become something like
const html = options.transformPage(options.template({ head, body, assets }));

Alternatives considered
The alternative is to do nothing. It depends on whether we consider manipulating the HTML response to be 'supported' — if it's a rarely-used hack, perhaps it's not necessary, but if we consider it to be a valid and common use case then the API probably pays for itself.
Minification is one use case; injecting the correct <html lang="..."> attribute is another (albeit one that Kit will eventually have full support for anyway). I've seen it be used for other stuff — here's a snippet from the NYT covid tracker that allows multiple Kit apps to exist on the same page...
/** @type {import('@sveltejs/kit').Handle} */
export async function handle({ request, resolve }) {
  const rendered = await resolve(request);

  if (typeof rendered.body === 'string') {
    rendered.body = rendered.body
      .replace(/start\({([\s\S]+?)}\);/, (match, $1) => {
        const opts = $1.replace(/target: .+?,/, 'target,');
        return `const target = document.querySelector('#__covidtracker__');\n\t\t\ttarget.removeAttribute('id');\n\t\t\tstart({${opts}});`;
      })
      .replace(/__covidtracker__/g, `svelte-${hash(request.path)}`);
  }

  return rendered;
}

...and there are doubtless other uses we can't anticipate. So I vote for its inclusion, but others might feel differently.
Importance
nice to have
Additional Information
No response

Thank you for pointing out how it can be done after #3384!
Yes, please. This would allow for a better way to handle templating of app.html.
Here's what it would look like to allow ejs syntax templating in app.html:
export async function handle({ event, resolve }) {
  return await resolve(event, {
    transformPage: ({ html }) => ejs.render(html, { foo: 'bar' }))
  });
}

I also think this would be useful. I have to do these kinds of operations in almost every SK app I build and this syntax is concise while making the intent clearer.

Definitely very useful for my use case as well. Thanks 👍


Reconsider CodeAnalysis for EF6

The code in EF6 now has many CodeAnalysis suppressions. The most recent especially suppressed a lot of code of the form:
Debug.Assert(x is ClassXyz);
DoSomething(x as ClassXyz);

but there are many suppressions of many different types throughout both the runtime and the tools.
This issue is to reanalyze the costs and benefits we are getting from CodeAnalysis, and to decide a) whether to continue running it, b) if so how should we approach common situations where suppressions are often necessary, c) revisiting the code to apply these rules.
Bear in mind that we still run CodeAnalysis against Dev11, Dev12, Dev14 and Dev15 - and that both the CodeAnalysis DLLs and the way the rules are applied have changed since Dev11. Also bear in mind CodeAnalysis often produces different results for release builds versus debug builds.

I saw a comment in the PR from @ajcvickers saying that in the past we used not to do CodeAnalysis on debug builds because that resulted in a lot of noise. Did we start at some point doing it? Or are all these issues popping up because of some other change in VS?

Actually its the release builds that tend to cause more noise - e.g. because code which uses variables is no longer there - and maybe also because most developers are generally working in debug mode - so it's the debug mode errors they see. We currently skip CodeAnalysis when doing CI release builds (and we are still doing that even after my PR) for the same reason.

@lajones @divega Issues on release builds are always valid in the sense that FxCop is flagging something that is happening in the actual code that we ship. (We may disagree that what it is flagging is something that should be changed, but that is true of any code analysis.) On the other hand, issues on debug views can be entirely an artifact of debug code--as is the case in the example in the description of this bug. This is why historically we have only run FxCop on release builds--because we care about what we ship, and we don't care if debug code introduces artifacts that have no impact on what we ship.
While it is true that FxCop can flag issues in code we release because of code we have for debugging, that is actually a good thing. It indicates that debug code is impacting what we ship, and this is something we should fix.

We decided not to do anything right now.


Content harvester derivative creation subprocess errors do not cause job to fail

At the moment, rikolti.content_harvester.derivatives.sub_process_exception handler returns None if a subprocess runs into an error. The error is ignored, and the content harvest task succeeds, even though the file has not been converted.

Closing as this is a duplicate of https://github.com/ucldc/rikolti/issues/969


Fixed #34242 -- Doc'd that primary key is set to None when deleting objects.

…ect to some other data field, after deletion of an object the data will be lost since primary key will be set to None. Corrected it in Deleting objects and primary_key section of docs.

@mron03 Thanks :+1: Welcome aboard :boat:


[BrokenLinksH2] Fix path in link

Fixing external broken link

Docs Build status updates of commit 83f03ce:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

dynamics-nav-app/LocalFunctionality/Spain/how-to-create-report-340.md
:bulb:Suggestion

Details

dynamics-nav-app/LocalFunctionality/Spain/how-to-create-report-340.md

Line 58, Column 1: [Suggestion: docs-link-absolute - See documentation] Absolute link 'https://docs.microsoft.com/dynamics365/business-central/' will be broken in isolated environments. Replace with a relative link.

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit 5cff05d:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

dynamics-nav-app/LocalFunctionality/Spain/how-to-create-report-340.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Introduce ROCK automations for building and pushing ROCKs

What needs to get done
Similarly to what we have in kubeflow-rocks repo

A workflow for building ROCKs on each PR
https://github.com/canonical/kubeflow-rocks/blob/main/.github/workflows/on_pull_request.yaml
A workflow for automatically building/publishing a ROCK
https://github.com/canonical/kubeflow-rocks/blob/main/.github/workflows/build_and_publish_rock.yaml

Why it needs to get done
To reduce the manual work required of testing that images can be built and published

I'm holding off on this task until https://github.com/canonical/seldonio-rocks/issues/58 is well reviewed since they'll be very similar


BuildHack autofix

This PR fixes vulnerabilities discovered in the docker image built from the repo Dockerfile

Closing. There will be more of these as we test the flow more rigorously


Images

When I run the prompts, I need to input relative filepaths for the images I want to use, then I need that file COPIED to the new images directory within the generated project.
When I input an image, it MUST be in .png format.

drag and drop images with matching file names within the created images directory


✨ Masking sensitive information in lang/emb requests

Requirements

Mask PHI, PII, and PCI information in lang/embedding requests
Unmask all masked values before returning LLM chat responses back
Unmask masked tokens in streaming chat requests
Allow to enable the functionality per router
consider using the middleware-like approach to the architecture and that there may be more pre/post processing logic to include in the future

Use Case

I want to be able to mask sensitive information (PHI, PII, and PCI) before sending it to LLM providers, so I'm not leaking it. If model returns masked placeholders, I want it to be unmasked automatically and seamlessly

cc @mkrueger12


Build path in docker-compose

Currently build in docker compose file is expected to be relative path.
We also need support absolute path, urls, and context with dockerfile options.
see: https://docs.docker.com/compose/compose-file/

@kadel it will be a good addition to libcompose itself

libcompose supports that

So should we work on this or wait till we get the libcompose support?

swapping to upstream libcompose won't help

from my investigation it seems that this is actually intentional and it is how openshift import has been written.  look at this: https://github.com/redhat-developer/henge/blob/master/pkg/transformers/openshift/generate.go#L145,L178

@kadel one finding openshift's libcompose code itself will expand the Build variable, so after p.Parse() if you look for p.Configs[svc_name].Build it will be changed from relative path to absolute path.
I checked with libcompose, it worked with both absolute path and relative path.

Using absolute path for build in docker-compose file

```
$ cat docker-compose.yml
version: "2"
services:
mariadb:
image: centos/mariadb
ports:
- "3306"
environment:
MYSQL_ROOT_PASSWORD: etherpad
MYSQL_DATABASE: etherpad
MYSQL_PASSWORD: etherpad
MYSQL_USER: etherpad
etherpad:
build: "/home/vagrant/compose-lib/etherpad/myphp"
ports:
- "80:9001"
depends_on:
- mariadb
environment:
DB_HOST: mariadb
DB_DBID: etherpad
DB_PASS: etherpad
DB_USER: etherpad
$ ~/work/src/github.com/docker/libcompose/libcompose up
WARN[0000] Note: This is an experimental alternate implementation of the Compose CLI (https://github.com/docker/compose)
INFO[0000] [0/2] [mariadb]: Starting
INFO[0000] Recreating mariadb
INFO[0001] [1/2] [mariadb]: Started
INFO[0001] [1/2] [etherpad]: Starting
WARN[0001] Error while reading .dockerignore (/home/vagrant/compose-lib/etherpad/myphp/.dockerignore) : open /home/vagrant/compose-lib/etherpad/myphp/.dockerignore: no such file or directory
INFO[0001] Building etherpad_etherpad...
Sending build context to Docker daemon 79.36 kB
Step 1 : FROM somefoo
Pulling repository docker.io/library/somefoo
Error: image library/somefoo not foundERRO[0006] Failed Starting etherpad : Status: Error: image library/somefoo not found, Code: 1
ERRO[0006] Failed to start: etherpad : Status: Error: image library/somefoo not found, Code: 1
Status: Error: image library/somefoo not found, Code: 1
</details>

Using relative path in docker compose file
<details>

$ cat docker-compose.yml
version: "2"
services:
mariadb:
image: centos/mariadb
ports:
- "3306"
environment:
MYSQL_ROOT_PASSWORD: etherpad
MYSQL_DATABASE: etherpad
MYSQL_PASSWORD: etherpad
MYSQL_USER: etherpad
etherpad:
build: "./myphp"
ports:
- "80:9001"
depends_on:
- mariadb
environment:
DB_HOST: mariadb
DB_DBID: etherpad
DB_PASS: etherpad
DB_USER: etherpad
$ ~/work/src/github.com/docker/libcompose/libcompose up
WARN[0000] Note: This is an experimental alternate implementation of the Compose CLI (https://github.com/docker/compose)
INFO[0000] [0/2] [mariadb]: Starting
INFO[0000] Recreating mariadb
INFO[0001] [1/2] [mariadb]: Started
INFO[0001] [1/2] [etherpad]: Starting
WARN[0001] Error while reading .dockerignore (myphp/.dockerignore) : open myphp/.dockerignore: no such file or directory
INFO[0001] Building etherpad_etherpad...
Sending build context to Docker daemon 79.36 kB
Step 1 : FROM somefoo
Pulling repository docker.io/library/somefoo
Error: image library/somefoo not foundERRO[0005] Failed Starting etherpad : Status: Error: image library/somefoo not found, Code: 1
ERRO[0005] Failed to start: etherpad : Status: Error: image library/somefoo not found, Code: 1
Status: Error: image library/somefoo not found, Code: 1
</details>

Reported issue in origin https://github.com/openshift/origin/issues/9815

Doing deeper research on libcompose's way of handling the parsed config is quite different, so libcompose stores path to build directory as is given by user. And build information is stored in object of type Build.
(dlv) b /home/vagrant/work/src/github.com/docker/libcompose/project/project.go:178
(dlv) c
(dlv) p serviceConfigs["etherpad"]
*github.com/docker/libcompose/config.ServiceConfig {
	Build: github.com/docker/libcompose/yaml.Build {
		Context: "./myphp",
		Dockerfile: "",
		Args: map[string]string [],},
	CapAdd: []string len: 0, cap: 0, [],
	CapDrop: []string len: 0, cap: 0, [],
	CPUSet: "",
[SNIP]

While openshift's libcompose will only store absolute path to build path.
(dlv) b /home/vagrant/work/src/github.com/redhat-developer/henge/pkg/transformers/openshift/generate.go:63
(dlv) c
(dlv) p p.Configs["etherpad"]
*github.com/redhat-developer/henge/vendor/github.com/openshift/origin/third_party/github.com/docker/libcompose/project.ServiceConfig {
	Build: "/home/vagrant/compose-lib/etherpad/myphp",
	CapAdd: []string len: 0, cap: 0, [],
[SNIP]


Remove blobStartIndex from PFBs

Overview
CIP about removing the blobstartIndex from the Wrapped Transaction

is my understanding correct that to point to the actual blob you intend to in the square you have to use index + height + commitment? without index, there could be 2 blobs with identical commitments submitted by 2 different accounts where 1 is malicious and 2 is honest?

I think this needs a description based on CIP-1: https://github.com/celestiaorg/CIPs/blob/main/cips/cip-1.md#cip-header-preamble


Version 4

This PR tries to closes #9 and update the code style using Python type hints.

Preview

TO DO

fix schema
add security
add html response
add yaml response
update tests
update docs
...

Alright this is ready.
I added the OpenAPI implementation which adds 3 defaults routes to get the docs. We can remove thoses default routes when initializing the app with add_docs=False

/openapi.json: print OpenAPI JSON definition

/docs: swagger html UI

/redoc: Redoc html UI

I'm going to release a 4.0rc0 version on pypi


Rust crate builder ignores cargo:rustc directives from build.rs

Describe the bug
Originally filed on https://github.com/kolloch/crate2nix/issues/180
Let's say we have a build.rs that looks a bit like this:
fn main() {
  …
  println!("cargo:rustc-link-lib=static=foo");
  …

When we run cargo build on this package, it's going to first build the build.rs file and run it. It will then build the rest of the project.
However, in this case, cargo sees the cargo:rustc-link-lib=static=foo and when building the rest of the project, it's going to pass -l static=foo to rustc.
The builder from crate2nix however just ignores it.
We can't work-around it with something like extraRustcOpts as those will apply during build of build.rs too: if we're creating the foo static library in build.rs however, it is not available.
To Reproduce
Steps to reproduce the behavior:

Create a basic crate
Make build.rs and in main emit any of the https://doc.rust-lang.org/cargo/reference/build-scripts.html#outputs-of-the-build-script directives
See that it doesn't get applied when the rest of the crate gets built

Expected behavior
We should detect and honour directives from build.rs stage.
Additional context
I was able to work-around via hard-coding with something like
extraLinkFlags = [ "-l" "static=foo" ];

though this obviously only works in very limited set of circumstances.
Notify maintainers
@danieldk
Metadata
 - system: `"x86_64-linux"`
 - host os: `Linux 5.10.26, NixOS, 21.05.git.83c63225fed (Okapi)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.10`
 - channels(root): `"nixos-17.09.3269.14f9ee66e63"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

The channel above is unrelated, I'm using very recent nixpkgs w.r.t. this ticket.
Maintainer information:
# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module:

I stumbled upon the following in configure-crate.nix:
grep -P "^cargo:(?!(rustc-|warning=|rerun-if-changed=|rerun-if-env-changed))" target/build/${crateName}.opt \
       | awk -F= "/^cargo:/ { sub(/^cargo:/, \"\", \$1); gsub(/-/, \"_\", \$1); print \"export \" toupper(\"DEP_$(echo $CRATENAME)_\" \$1) \"=\" \$2 }" > target/env
     set -e

so it possibly seems like it should work

It looks like the issue is that we only respect cargo:rustc-link-lib in https://github.com/NixOS/nixpkgs/blob/c7e7f90108ff7bb7924e6f70136dd72c0f916954/pkgs/build-support/rust/build-rust-crate/lib.sh#L48, not https://github.com/NixOS/nixpkgs/blob/c7e7f90108ff7bb7924e6f70136dd72c0f916954/pkgs/build-support/rust/build-rust-crate/lib.sh#L9-L30
This makes sense in a way, linking external stuff is usually saved for the end with static linking. The wrinkle is that Rust has traditionally added these to intermediate static libs, defying expectations. Now Rust also has "static linking without bundling", the latest iteration of which is defined in https://github.com/rust-lang/rfcs/pull/2951/files. It is unclear to me what cargo:rustc-link-lib is supposed to do in that case.

Hmm upon further snooping the -l ... was getting to the final compilation somehow.
The issue for me was in that in a cross build, https://github.com/NixOS/nixpkgs/commit/ae3b4655a4a7d8692dab3ba46a40b7daabcb1208/pkgs/build-support/rust/build-rust-crate/build-crate.nix#diff-a75e274915d57315cddb877950f327f74574eb3967d2ad7170bdf535d5001686R70 prevents the use of lld. The matters because per https://lld.llvm.org/NewLLD.html LLD doesn't care about -l order so much, in order to make cyclic linking easier.
I am surprised I got a smaller binary and not missing symbol errors, but unquestionably getting rid of the linker override to just use lld per the default caused everything to be picked up.

Presumably still an issue unless explicit fix is made.


more comments on the asyncsgd example ?

Hello
thanks a lot for your example.
I want to use MPI for multi nodes but I do not know how can I set the configure.
Would you please add some explanation of the content in "local conf" and how can I set for multi node environment?  That would be very useful for many people who want to use this package.
Thanks a lot!

hi, you may look at the header of pclient.lua and pserver file, which reads
the local conf.
you are flexible to modify it as you needs. use hostfile in mpi to setup
multi node enviroment.
function pClient:__init(conf)  self.state = {}  self.rank = conf.rank or -1
self.sranks = conf.sranks or {} -- server ranks  self.cranks = conf.cranks
or {} -- client ranks   self.plong = conf.plong or 0 -- size of whole
parameter  self.pstorage = conf.pstorage or torch.Storage()  self.gstorage =
conf.gstorage or torch.Storage()  self.emptys = torch.Storage()  self.sinfo
= {}  self.mtype = mpiT.FLOAT  self.mworld = conf.world or mpiT.COMM_WORLD
self.coq = Queue() -- coroutine queue  self.maxsec = conf.maxsec or 60  self
.ss = conf.ss or './pcstate.th'  self.conf = conf  end
function pServer:__init(conf)  self.state = {}  self.rank = conf.rank or -1
self.cranks = conf.cranks or {} -- client ranks  self.mtype = mpiT.FLOAT
self.mworld = conf.world or mpiT.COMM_WORLD
self.offset = -1 -- offset of param grad  self.size = -1 -- size of param
grad  self.tensor = {} -- tensor from storage  self.storage = {} -- param
gradient storage  self.emptys = torch.Storage()
self.on = false  self.coq = Queue() -- coroutine queue
self.lr = conf.lr or 1e-2
self.conf = conf  end
On Fri, Jul 24, 2015 at 11:43 AM, shuzi<EMAIL_ADDRESS>wrote:

Hello
thanks a lot for your example.
I want to use MPI for multi nodes but I do not know how can I set the
configure.
Would you please add some explanation of the content in "local conf" and
how can I set for multi node environment? That would be very useful for
many people who want to use this package.
Thanks a lot!
—
Reply to this email directly or view it on GitHub
https://github.com/sixin-zh/mpiT/issues/2.


Trying to access a non-existing resource returns an empty body

when trying to access a resource that does not exist with GET or PROPFIND, the correct HTTP code (404) is returned but the body of the response is empty
curl -X PROPFIND http://localhost:9140/remote.php/dav/files/does-not-exist -u user0:123456 -v
*   Trying <IP_ADDRESS>:9140...
* TCP_NODELAY set
* Connected to localhost (<IP_ADDRESS>) port 9140 (#0)
* Server auth using Basic with user 'user0'
> PROPFIND /remote.php/dav/files/does-not-exist HTTP/1.1
> Host: localhost:9140
> Authorization: Basic dXNlcjA6MTIzNDU2
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 404 Not Found
< Access-Control-Allow-Origin: *
< Vary: Origin
< X-Access-Token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJyZXZhIiwiZXhwIjoxNTg4NTc1NTkxLCJpYXQiOjE1ODg1NzE5OTEsImlzcyI6Imh0dHBzOi8vbG9jYWxob3N0OjkyMDAiLCJ1c2VyIjp7ImlkIjp7ImlkcCI6Imh0dHBzOi8vbG9jYWxob3N0OjkyMDAiLCJvcGFxdWVfaWQiOiJ1c2VyMCJ9LCJ1c2VybmFtZSI6InVzZXIwIiwibWFpbCI6InVzZXIwQGV4YW1wbGUub3JnIiwiZGlzcGxheV9uYW1lIjoiVXNlciBaZXJvIn19.7idBBYb4GuSQB3LQxZIMf4JmWz-teFBzpKZX1_PVIiU
< Date: Mon, 04 May 2020 05:59:51 GMT
< Content-Length: 0
<
* Connection #0 to host localhost left intact

vs oC 10
curl -X PROPFIND http://localhost/owncloud-core/remote.php/dav/files/does-not-exist -u uu1:uu1 -v
*   Trying <IP_ADDRESS>:80...
* TCP_NODELAY set
* Connected to localhost (<IP_ADDRESS>) port 80 (#0)
* Server auth using Basic with user 'uu1'
> PROPFIND /owncloud-core/remote.php/dav/files/does-not-exist HTTP/1.1
> Host: localhost
> Authorization: Basic dXUxOnV1MQ==
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 404 Not Found
< Date: Mon, 04 May 2020 06:00:26 GMT
< Server: Apache/2.4.43 (Ubuntu)
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< X-Robots-Tag: none
< X-Frame-Options: SAMEORIGIN
< X-Download-Options: noopen
< X-Permitted-Cross-Domain-Policies: none
< Set-Cookie: oc4kyqahfanl=c9jffpv2t69jkun4u618srq9m0; path=/owncloud-core; HttpOnly
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate
< Pragma: no-cache
< Set-Cookie: oc_sessionPassphrase=RrXPBYcZINaSYO%2FyXa0KD1Dk55%2BXVzUBt0En2u8OR6%2BFmFh5snEXGHK6OubihNmB0d98QfYx4K0WvxmObZizlYzxvOC4rMwhCrCuyrJTVeC8YIZHMJWFyD8mM%2FDw8AMc; path=/owncloud-core; HttpOnly
< Content-Security-Policy: default-src 'none';
< Set-Cookie: oc4kyqahfanl=62cob6c4pgbiat956s91o31t79; path=/owncloud-core; HttpOnly
< Set-Cookie: cookie_test=test; expires=Mon, 04-May-2020 07:00:26 GMT; Max-Age=3600
< Vary: Brief,Prefer
< DAV: 1, 3, extended-mkcol, 2
< Content-Length: 236
< Content-Type: application/xml; charset=utf-8
<
<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
  <s:exception>Sabre\DAV\Exception\NotFound</s:exception>
  <s:message>Principal with name does-not-exist not found</s:message>
</d:error>
* Connection #0 to host localhost left intact

can confirm it still happens with the latest master.

can confirm it still happens with the latest master.

fixed as a side effect of https://github.com/cs3org/reva/pull/1849

fixed as a side effect of cs3org/reva#1849

Then close and remove from expected failures?

@dpakach please check if there are still any expected-failures related to this issue. Hopefully this is fixed and we can close the issue.

@sakshamgurung is working on this issue

oc10 is replaying with following response body

OC10: curl -X PROPFIND http://localhost/core/remote.php/dav/files/does-not-exist -u admin:admin -v
...
<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
  <s:exception>Sabre\DAV\Exception\NotFound</s:exception>
  <s:message>Principal with name does-not-exist not found</s:message>
</d:error>
* Connection #0 to host localhost left intact

ocis is responding with following response body

OCIS :  curl -k -X PROPFIND https://localhost:9200/remote.php/dav/files/does-not-exist -u admin:admin -v
...
<?xml version="1.0" encoding="UTF-8"?>
* Connection #0 to host localhost left intact
<d:error xmlns:d="DAV" xmlns:s="http://sabredav.org/ns"><s:exception>Sabre\DAV\Exception\NotFound</s:exception><s:message>Resource /users/does-not-exist not found</s:message></d:error>%

Is is expected to have different message structure for oc10 and ocis because drone is failing with this error message:

@phil-davis the PR that adjusts the tests for this issue has been merged https://github.com/owncloud/core/pull/39113.
I think we can close this issue.

The response body exists now, and has the same exception. The message text is different - but that is OK and we have adjusted the tests so that they know to expect the different message text from oCIS. Closing.


Fix bug with deploy job when .git directory doesn't exist

I was attempting to use this orb by building my frontend app in another job and just attaching the dist/ directory via the workspace. In doing so, I discovered that the default message relies on an existing git repository when it runs git rev-parse. This change updates the setup logic to check for the existence of the .git directory before using rev-parse so the job doesn't crash in the absence of a git repo.

@emanguy Hi, thank you for your contribution. I set up CI settings to run builds for pull requests from forks. So could you commit again?

Sure, I just force pushed an amended commit to trigger CI

@emanguy I did publish it as version 1.0.1. https://circleci.com/developer/ja/orbs/orb/sugarshin/gh-pages?version=1.0.1
Thank you.


Add Mini Calender

issue #503
https://github.com/user-attachments/assets/963e8fb6-3093-48bd-95a3-e85165334bf1

@iamrahulmahato  pls merge it

@iamrahulmahato pls merge it

@iamrahulmahato CONFLICT IS RESOLVED


Introduce ClassValue as a representation of class-es in database. Thi…

…s fixes the issue when during a rollback some class disappears from the application the flow engine can handle it gracefully.
See detailed description in the commit message.

Sorry, could you please add the relevant Jira ticket number if available?


Rootless 'podman exec' stopped working somewhere between 1b2f8679b864b882 (good) and 9b21f14eefae8ab7 (bad)

/kind bug
Description
Rootless podman exec stopped working somewhere between 1b2f8679b864b882 (good) and 9b21f14eefae8ab7 (bad) as can be seen when using the Silverblue toolbox. Starting from a clean state (ie., no images or containers present), this is what happens:
$ toolbox create
$ toolbox -v enter
...
...
toolbox: trying to exec /bin/bash in container fedora-toolbox-rishi:29
Error: cannot read conmon PID file "/run/user/1000/overlay-containers/36d44874d168fedf8effb849f28b2338e0916d960f1026f660a44e582a3536f4/userdata/conmon.pid": open /run/user/1000/overlay-containers/36d44874d168fedf8effb849f28b2338e0916d960f1026f660a44e582a3536f4/userdata/conmon.pid: permission denied

Note that in case you are running the toolbox script directly from Git, make sure that you have a /run/media directory. The toolbox RPM takes care of this.
drwxr-xr-x. 2 root root 40 Mar 15 17:18 /run/media

The command that's failing is:
$ podman --log-level debug exec -it fedora-toolbox-rishi:29 /bin/bash
INFO[0000] running as rootless
DEBU[0000] Initializing boltdb state at /home/rishi/.local/share/containers/storage/libpod/bolt_state.db
DEBU[0000] Using graph driver overlay
DEBU[0000] Using graph root /home/rishi/.local/share/containers/storage
DEBU[0000] Using run root /run/user/1000
DEBU[0000] Using static dir /home/rishi/.local/share/containers/storage/libpod
DEBU[0000] Using tmp dir /run/user/1000/libpod/tmp
DEBU[0000] Using volume path /home/rishi/.local/share/containers/storage/volumes
DEBU[0000] Set libpod namespace to ""
DEBU[0000] Not configuring container store
ERRO[0000] cannot read conmon PID file "/run/user/1000/overlay-containers/36d44874d168fedf8effb849f28b2338e0916d960f1026f660a44e582a3536f4/userdata/conmon.pid": open /run/user/1000/overlay-containers/36d44874d168fedf8effb849f28b2338e0916d960f1026f660a44e582a3536f4/userdata/conmon.pid: permission denied

Output of podman version:
Version:            1.2.0-dev
RemoteAPI Version:  1
Go Version:         go1.11.5
OS/Arch:            linux/amd64

Output of podman info --debug:
debug:
  compiler: gc
  git commit: ""
  go version: go1.11.5
  podman version: 1.2.0-dev
host:
  BuildahVersion: 1.7.1
  Conmon:
    package: podman-1.2.0-12.dev.git9b21f14.fc29.x86_64
    path: /usr/libexec/podman/conmon
    version: 'conmon version 1.12.0-dev, commit: 90658d9dc6cbe4b23fd1c453a92405aac2ecb3e9'
  Distribution:
    distribution: fedora
    version: "29"
  MemFree: 315166720
  MemTotal:<PHONE_NUMBER>
  OCIRuntime:
    package: runc-1.0.0-68.dev.git6635b4f.fc29.x86_64
    path: /usr/bin/runc
    version: |-
      runc version 1.0.0-rc6+dev
      commit: ef9132178ccc3d2775d4fb51f1e431f30cac1398-dirty
      spec: 1.0.1-dev
  SwapFree:<PHONE_NUMBER>
  SwapTotal:<PHONE_NUMBER>
  arch: amd64
  cpus: 4
  hostname: kolache
  kernel: 4.20.13-200.fc29.x86_64
  os: linux
  rootless: true
  uptime: 2h 26m 3.16s (Approximately 0.08 days)
insecure registries:
  registries: []
registries:
  registries:
  - docker.io
  - registry.fedoraproject.org
  - quay.io
  - registry.access.redhat.com
  - registry.centos.org
store:
  ConfigFile: /home/rishi/.config/containers/storage.conf
  ContainerStore:
    number: 1
  GraphDriverName: overlay
  GraphOptions:
  - overlay.mount_program=/usr/bin/fuse-overlayfs
  GraphRoot: /home/rishi/.local/share/containers/storage
  GraphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  ImageStore:
    number: 2
  RunRoot: /run/user/1000
  VolumePath: /home/rishi/.local/share/containers/storage/volumes

Bisecting further with the actual Git tree, instead of the RPM snapshots, I think this was caused by PR #2569:
commit 4a02713c57d874c404539047ccc5c5ff5c1958fc
Author: Giuseppe Scrivano<EMAIL_ADDRESS>Date:   Thu Mar 7 08:14:22 2019 +0100
rootless: exec join the user+mount namespace

it is not enough to join the user namespace where the container is
running.  We also need to join the mount namespace so that we can
correctly look-up inside of the container rootfs.  This is necessary
to lookup the mounted /etc/passwd file when --user is specified.

Closes: https://github.com/containers/libpod/issues/2566

Signed-off-by: Giuseppe Scrivano<EMAIL_ADDRESS>

thanks for the bisect.  The patch helped to find the issue, which is a different one:
https://github.com/containers/libpod/pull/2675

also, fedora-toolbox is a very interesting use case and it is stretching rootless containers to their limits :-)
once we have dedicated rootless tests, @debarshiray would you be interested to write some tests for Podman for the features you are using in fedora-toolbox?  So we will avoid to introduce regressions in the future

thanks for the bisect. The patch helped to find the issue, which is a different one:
#2675

Nice.
Although, if I am not mistaken, doesn't this mean that rootless containers created with earlier versions of podman can no longer be used with podman exec?
I wonder if we can soften the blow somehow. One option that came to my mind was to not hard depend on the ConmonPidFile. Maybe we can fallback to getting the PID of the container's PID 1 through ctr.PID(), and then walking back up the process tree to find the conmon process using some heuristics? Although, I don't know what could happen if someone tricks the heuristics into a false positive.

also, fedora-toolbox is a very interesting use case and it is stretching rootless
containers to their limits :-)
once we have dedicated rootless tests, @debarshiray would you be interested to
write some tests for Podman for the features you are using in fedora-toolbox? So
we will avoid to introduce regressions in the future

Sure, I will be happy to. :)

Shouldn't break existing containers - we store the path in the database, so
older containers should still use the old default they were created with,
while new containers get the new, fixed default.
On Mon, Mar 18, 2019, 06:49 Debarshi Ray<EMAIL_ADDRESS>wrote:

also, fedora-toolbox is a very interesting use case and it is stretching
rootless
containers to their limits :-)
once we have dedicated rootless tests, @debarshiray
https://github.com/debarshiray would you be interested to
write some tests for Podman for the features you are using in
fedora-toolbox? So
we will avoid to introduce regressions in the future
Sure, I will be happy to. :)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/containers/libpod/issues/2673#issuecomment-473896458,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHYHCM0TtZtBu0i3fBEuUbnYz5BOgv04ks5vX4togaJpZM4b3GLN
.

Shouldn't break existing containers - we store the path in the database,
so older containers should still use the old default they were created with,
while new containers get the new, fixed default.

Umm... but this isn't about the presence of the path to the conmon.pid file. The problem is that (the old path to) the conmod.pid file inside XDG_RUNTIME_DIR has permissions that are awkward for the current code, which leads to EPERM. The new default doesn't have this problem, but it's only going to take effect for freshly created containers.
I had earlier checked with the last known good snapshot from master (ie. commit 1b2f8679b864b882), and now confirmed that it's true with the 1.1.2 release too. :)
If we can't soften the blow, then it would be good to have a narrower exit code that stands for "container needs to be re-created" so that scripts like the Silverblue toolbox can throw a less generic error message. Maybe we should even standardize such an exit code across all commands that work with an already created container?

Ahhh. I would have called that not fixing existing containers instead of breaking them, but you're 100% correct.
I don't know how we can easily detect this specific case; it could just as easily be someone accidentally running chown -r on a directory we use.

One could try to guess the cause of the failure by checking if the EPERM was a for the known-not-to-work path.
Is it possible to find out the path to the conmon.pid file from outside Podman? If yes, then the toolbox could try to do that itself. It should be reasonably OK because it knows that it doesn't override the path, so the combination of a path inside XDG_RUNTIME_DIR and EPERM would be a decent heuristic.

If we're not already reporting it in exec I would be fine with adding Conmon pidfile path there

And by exec I meant inspect. Need more coffee...

Ok, submitted #2698 to export ConmonPidFile in podman inspect for containers.

I added a more targetted hint to the error message from toolbox enter (see https://github.com/debarshiray/toolbox/pull/82) but I still wish people didn't have to throw away their existing containers. If nothing else, this would make it difficult to land podman-1.2.0 in stable Fedoras like 29 and 28.

Ahhh. I would have called that not fixing existing containers instead of breaking them, but you're 100% correct.

It seems precisely like breaking existing containers to me - as I understand the status after #2675 , if you create a container with podman <= 1.2.0, then unless this is resolved, upgrading to 1.2.0 makes this working container no longer work properly.

I don't know how we can easily detect this specific case; it could just as easily be someone accidentally running chown -r on a directory we use.

What about simply recreating ConmonPidFile when starting a stopped container?

I don't know how we can easily detect this specific case; it could just as easily be someone accidentally running chown -r on a directory we use.

What about simply recreating ConmonPidFile when starting a stopped container?

The problem is that #2675 writes the default ConmonPidFile path to the container's configuration if the user hadn't explicitly specified one. That makes things a bit difficult in terms of falling back to softer recovery modes.
I wonder if we can avoid writing the default path to the configuration when the user hadn't specified one explicitly, and keep plugging it in dynamically at run-time? If we can do that, then it might open up some possibilities that aren't as extreme as "re-create the container and start afresh". :)
I don't know if it will work, but something like "you have to re-start the container" is a lot nicer.

Not keeping the default in the database is arguably worse - we won't even
be able to find the file for running containers that haven't restarted.
This at least preserves consistency, in that we know where the file is with
certainty, even if the location has incorrect permissions.
On Mon, Mar 18, 2019, 14:19 Debarshi Ray<EMAIL_ADDRESS>wrote:

I don't know how we can easily detect this specific case; it could just as
easily be someone accidentally running chown -r on a directory we use.
What about simply recreating ConmonPidFile when starting a stopped
container?
The problem is that #2675 https://github.com/containers/libpod/pull/2675
writes the default ConmonPidFile path to the container's configuration if
the user hadn't explicitly specified one. That makes things a bit difficult
in terms of falling back to softer recovery modes.
I wonder if we can avoid writing the default path to the configuration
when the user hadn't specified one explicitly, and keep plugging it in
dynamically at run-time? If we can do that, then it might open up some
possibilities that aren't as extreme as "re-create the container and start
afresh". :)
I don't know if it will work, but something like "you have to re-start the
container" is a lot nicer.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/containers/libpod/issues/2673#issuecomment-474084437,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHYHCLmKhVqma_zYOE-DgUOX-IlhLK77ks5vX_TUgaJpZM4b3GLN
.

@owtaylor This changes nothing for containers created for previous versions of Podman - the new default only applies to new containers. Previous containers will use the old path. I don't see how that breaks old containers - if they are broken, they were broken before the patch.

@owtaylor This changes nothing for containers created for previous versions of Podman - the new default only applies to new containers. Previous containers will use the old path. I don't see how that breaks old containers - if they are broken, they were broken before the patch.

As I understand it, since #2569 the old path doesn't work any more -  #2675 fixes that for new containers, but old containers keep using the conmon default location (in the CWD of the conmon execution)
Putting the new default directly into the args passed to conmon rather than writing them into the config file would seem better... then it would work for any container.

Putting the new default directly into the args passed to conmon rather than writing them into the config file would seem better... then it would work for any container.

Ah, I guess that wouldn't help locate the pid file for an existing running container instance - but I still think that a) the current code state will break the ability of people to keep using rootless containers they created with older versions of podman b) with some rearrangement of code, that isn't necessary.

I'm still convinced that's a bad idea - we risk losing track of where the PID file lives. It also won't fix your old containers - their configs will still have the old default path, so we'll still use it. We can't rewrite existing container configs, either - that's a limitation of libpod's immutable container model. Our best bet might be trying to make the c/storage rundir accessible (chown the rundir to a group we can access?) - that would let us fix things with a container restart, at least...
The bigger takeaway from this is that our rootless testing is massively inadequate, because this snuck in and nobody realized until toolbox started hitting it. I see two PRs open right not to run the full test suite as rootless, which is a good start.

It also won't fix your old containers - their configs will still have the old default path, so we'll still use it.

The old path was only written into the config since 1.1.0 - but yeah, 1.1.2 did end up in Fedora stable two weeks ago :-( so that makes it hard to handle all old containers. You could just check if the pidfile in the config file is inside the runtime dir...
The upgrade issue wouldn't be caught by more testing in the test suite, but certainly that would be a great start!

It seems precisely like breaking existing containers to me - as I understand the status after #2675 , if you create a container with podman < 1.2.0 [edit, fixed comparison], then unless this is resolved, upgrading to 1.2.0 makes this working container no longer work properly.

it changes only the default value.  Existing containers will keep using their configuration that was created with the older podman version.

It seems precisely like breaking existing containers to me - as I understand
the status after #2675 , if you create a container with podman < 1.2.0 [edit, fixed comparison],
then unless this is resolved, upgrading to 1.2.0 makes this working container no longer work properly.

it changes only the default value. Existing containers will keep using their configuration that
was created with the older podman version.

Yes, containers created with podman <= 1.1.2 will keep using their existing configurations
but one cannot use podman exec on them after PR #2569 or commit 4a02713c57d874c4 if the containers were created with --uidmap but without --conmon-pidfile.

Given the permissions issues with conmon pidfiles from 1.1.x, I'm going to reopen this. We have a fix for new containers, but we need something to prevent regression on older containers.

we can add a workaround to fallback to the previous behaviour when we cannot read the conmon pid file.  It is still broken with --user, but it is not a regression since it was already broken in the previous version.
What do you think?

PR for the workaround: https://github.com/containers/libpod/pull/2762

we can add a workaround to fallback to the previous behaviour
when we cannot read the conmon pid file. It is still broken with
--user, but it is not a regression since it was already broken in the
previous version.

Makes sense to me!


add about section with edited icons

You can ignore vercel thing. THat wont cause any merge conflicts.


Not compatible with Flutter 3.11.x

Version
8.0.1
Platforms
dart
Device Model
All
flutter info
It looks like this is incompatible with 3.11.x Beta channel.  I have a feeling 3.11 will goto stable rather quickly since it has some important fixes to 3.10 that will need to be pushed out

How to reproduce?
Run application with 3.11 Flutter
Logs
No response
Example code (optional)
No response
Contact
No response

only support stable

That's not true, as stable has the API marked as deprecated and so the library is not currently using supported API, that's why it doesn't work with the the beta channels. This package maintainer isn't supporting the stable channel correctly and is not making it easier for developers who rely on it. I'm thinking I might create and publish a fork that is correctly supporting stable. Thoughts?

That's not true, as stable has the API marked as deprecated and so the library is not currently using supported API, that's why it doesn't work with the the beta channels. This package maintainer isn't supporting the stable channel correctly and is not making it easier for developers who rely on it. I'm thinking I might create and publish a fork that is correctly supporting stable. Thoughts?

It's happy to hear that. But we will never know the finnal result of deprecated api before it had removed. Flutter team always change api frequently in beta/ master branch and also roll back them. It's kind of you can maintenance it base on beta or master branch if you have a time.

The code in painting.dart of extended_image is using a workaround fix that was introduced by the flutter team (and copied by you) that has now been deprecated. The reason your code breaks in beta is that the code you're relying on was only implemented to solve a problem with performance that has since been fixed and reverted. Again, it is a shame you can't take a moment to look ahead rather than racing around on the day that Beta turns into Stable, and the entire package breaks countless apps as a result of not being compatible with the upcoming API. Looks like a fork is the only way I can continue to use this package.

The code in painting.dart of extended_image is using a workaround fix that was introduced by the flutter team (and copied by you) that has now been deprecated. The reason your code breaks in beta is that the code you're relying on was only implemented to solve a problem with performance that has since been fixed and reverted. Again, it is a shame you can't take a moment to look ahead rather than racing around on the day that Beta turns into Stable, and the entire package breaks countless apps as a result of not being compatible with the upcoming API. Looks like a fork is the only way I can continue to use this package.

We are delighted to see more people joining the Flutter open-source community and contributing to its maintenance. We eagerly anticipate your future open-source projects.

The code in painting.dart of extended_image is using a workaround fix that was introduced by the flutter team (and copied by you) that has now been deprecated. The reason your code breaks in beta is that the code you're relying on was only implemented to solve a problem with performance that has since been fixed and reverted. Again, it is a shame you can't take a moment to look ahead rather than racing around on the day that Beta turns into Stable, and the entire package breaks countless apps as a result of not being compatible with the upcoming API. Looks like a fork is the only way I can continue to use this package.

we are experience similar issue, have you created a fork already?

Yes, use this... it works with Flutter Beta 3.11
dependency_overrides:
  extended_image:
    git:
      url: https://github.com/gslender/extended_image
      ref: support-flutter-beta-3.11

8.1.0 is ready


As a developer, why are you interested in the contributor program?
Specifically, what are you looking for that is addressed by the program and what you are looking for that is currently not addressed by the contributor program?

As a developer, why are you interested in the contributor program?
Specifically, what are you looking for that is addressed by the program and what you are looking for that is currently not addressed by the contributor program?

This Question came from Tribe. Please respond and tag @ashleynear to get the answer crossposted back to Tribe!

@ashleynear seems like this came through again for some reason


Add IO to IMP++

IO for IMP++, using the temporary <stdin/> and <stdout> interface. Also works around the list subsorting issues. Examples such as lesson_1/tests/io.imp work. @andreistefanescu, @daejunpark please review.

lgtm. I'll change it back to the original style of IO, once I fix #1668

The list stuff is only intended to work around #1705.

lgtm


wrong path resolution for relative path

https://github.com/gobuffalo/packr/blob/master/v2/box.go#L55
_, filename, _, _ := runtime.Caller(2)
filename points to box.go itself, which is not intended ?

There's a pending fix for this in #127

Thank you
So I will close the issue.


Implement TRIM function

Implement TRIM function
This function is multibyte safe
Implementing this feature allows to perform the following actions

Remove whitespaces from prefixes and suffixes

If only str parameter
rust/std/str/trim
In the example above, consideration of \t should also be considered

If the specifier is BOTH, Remove the specifier parameter to the prefix and suffix

@panarch Please check the contents below
SELECT TRIM(BOTH 'xyz' FROM 'xyzybarxzxxz');
The result values for this query are different and which method do you want to adopt?

PostgreSQL

bar

MySQL

ybarxzxxz

If the specifier is LEADING, Remove the specifier parameter to the prefix

SELECT TRIM(LEADING 'xyz' FROM 'xyzybarxzxxz');

PostgreSQL

barxzxxz

MySQL

ybarxzxxz

If the specifier is TRAILING, Remove the specifier parameter to the suffix

SELECT TRIM(TRAILING 'xyz' FROM 'xyzybarxzxyz');

PostgreSQL

xyzybar

MySQL

xyzybarxz

A point of caution

If none of the specifiers BOTH, LEADING, or TRAILING is given, BOTH is assumed
Which adopt, PostgreSQL or MySQL

Example
PostgreSQL
trim(both 'xyz' from 'yxTomxx') → Tom

This is a non-standard syntax for trim()

@panarch Don't have to support?

trim(both from 'yxTomxx', 'xyz') → Tom

MySQL
SELECT TRIM('  bar   ')  -> bar
SELECT TRIM(LEADING 'x' FROM 'xxxbarxxx') -> barxxx
SELECT TRIM(BOTH 'x' FROM 'xxxbarxxx') -> bar
SELECT TRIM(TRAILING 'xyz' FROM 'barxxyz') -> barx

Reference

PostgreSQL

MySQL

If adopted, I will also fill out the remaining std functions for 2,3,4 features

Unfortunately, "specifier" of "sqlparser-rs" was not implemented. Let's just implement feature 1, which is a function of TRIM(str).

I'll add it to MySQL action.
MySQL can't perform multiple operations at once.
example
SELECT TRIM(BOTH 'x' FROM 'xxxbarxxx  ') -> `barxxx`
SELECT TRIM(BOTH 'x' FROM '     xxxbarxxx  ') -> `xxxbarxxx `
SELECT TRIM(BOTH 'x' FROM 'xxxbarxxx') -> `bar `

If exits whitespaces, string can't be erased.

Thank you for opening it up again.
Check List

[x] Remove whitespaces from prefixes and suffixes
[ ] If the specifier is BOTH, Remove the specifier parameter to the prefix and suffix
[ ] If the specifier is LEADING, Remove the specifier parameter to the prefix
[ ] If the specifier is TRAILING, Remove the specifier parameter to the suffix

fyi. while I was just checking SUBSTRING behavior, I found that how FROM keyword is supported by sqlparser-rs

https://github.com/ballista-compute/sqlparser-rs/blob/e5991f3ae50ee3ee90ef3ddde9b4cb3a0914d85a/src/parser.rs#L628-L647
https://github.com/ballista-compute/sqlparser-rs/blob/e5991f3ae50ee3ee90ef3ddde9b4cb3a0914d85a/src/parser.rs#L347-L367

    pub fn parse_substring_expr(&mut self) -> Result<Expr, ParserError> {
        // PARSE SUBSTRING (EXPR [FROM 1] [FOR 3])
        self.expect_token(&Token::LParen)?;
        let expr = self.parse_expr()?;
        let mut from_expr = None;
        let mut to_expr = None;
        if self.parse_keyword(Keyword::FROM) {
            from_expr = Some(self.parse_expr()?);
        }
        if self.parse_keyword(Keyword::FOR) {
            to_expr = Some(self.parse_expr()?);
        }
        self.expect_token(&Token::RParen)?;

        Ok(Expr::Substring {
            expr: Box::new(expr),
            substring_from: from_expr.map(Box::new),
            substring_for: to_expr.map(Box::new),
        })
    }

I didn't know enough about the internal sqlparser-rs parsing codes, I was just using it.
Now, I also get motivated by that you are getting interested on adding new features to sqlparser-rs, thanks :)
At a glance, it seems quite straightforward though number of lines are above 3,000..

Wow, thank you for motivating me, too.
Let me double check.

ref. https://github.com/ballista-compute/sqlparser-rs/pull/331

There are currently two problems.

sqlparser does not support non-standard.
1.1 This should be supported according to the respective dialect.
1.2 However, implementation is put on hold by too many dialects.

[ LEADING | TRAILING | There is no dependency between BOTH ] <-> [ characters text ].
2.1 This also needs to be fixed in sqlparser. Proceed with revision 1.


Error building ruby gem on Docker via Apple Silicon

What version of gRPC and what language are you using?
Ruby 2.7 and latest gRPC (1.38 and latest master)
What operating system (Linux, Windows,...) and version?
Linux via docker on Apple Silicon
What runtime / compiler are you using (e.g. python version or version of gcc)
build error for ruby gem
What did you do?
Using a minimalistic Docker File to build the ruby gem, using these files:
Dockerfile
FROM ruby:2.7

# throw errors if Gemfile has been modified since Gemfile.lock
RUN bundle config --global frozen 1

WORKDIR /usr/src/app

COPY Gemfile Gemfile.lock ./
RUN bundle install

Gemfile (tried both variants)
source 'https://rubygems.org'

gem 'grpc'
# gem 'grpc', github: 'grpc/grpc', submodules: true

Gemfile.lock
GEM
  remote: https://rubygems.org/
  specs:
    google-protobuf (3.17.3)
    googleapis-common-protos-types (1.1.0)
      google-protobuf (~> 3.14)
    grpc (1.38.0)
      google-protobuf (~> 3.15)
      googleapis-common-protos-types (~> 1.0)

PLATFORMS
  ruby

DEPENDENCIES
  grpc

BUNDLED WITH
   2.1.4

What did you expect to see?
A successful build
What did you see instead?
Long error log:
[ ... log shortened ... ]
#9 143.9 g++: fatal error: Killed signal terminated program cc1plus
#9 143.9 compilation terminated.
#9 143.9 make: *** [Makefile:823:
#9 143.9 /usr/local/bundle/gems/grpc-1.38.0/src/ruby/ext/grpc/objs/opt/src/core/ext/filters/client_channel/client_channel.o]
#9 143.9 Error 1
#9 143.9 make: *** Waiting for unfinished jobs....
#9 143.9 g++: fatal error: Killed signal terminated program cc1plus
#9 143.9 compilation terminated.
#9 143.9 make: *** [Makefile:823:
#9 143.9 /usr/local/bundle/gems/grpc-1.38.0/src/ruby/ext/grpc/objs/opt/src/core/ext/filters/client_channel/lb_policy/grpclb/grpclb.o]
#9 143.9 Error 1
#9 143.9 src/core/ext/filters/client_channel/lb_policy/weighted_target/weighted_target.cc:
#9 143.9 In member function ‘virtual
#9 143.9 grpc_core::RefCountedPtr<grpc_core::LoadBalancingPolicy::Config>
#9 143.9 grpc_core::{anonymous}::WeightedTargetLbFactory::ParseLoadBalancingConfig(const
#9 143.9 grpc_core::Json&, grpc_error**) const’:
#9 143.9 src/core/ext/filters/client_channel/lb_policy/weighted_target/weighted_target.cc:56:10:
#9 143.9 warning:
#9 143.9 ‘child_config.grpc_core::{anonymous}::WeightedTargetLbConfig::ChildConfig::weight’
#9 143.9 may be used uninitialized in this function [-Wmaybe-uninitialized]
#9 143.9    struct ChildConfig {
#9 143.9           ^~~~~~~~~~~
#9 143.9 src/core/ext/filters/client_channel/lb_policy/weighted_target/weighted_target.cc:657:45:
#9 143.9 note:
#9 143.9 ‘child_config.grpc_core::{anonymous}::WeightedTargetLbConfig::ChildConfig::weight’
#9 143.9 was declared here
#9 143.9          WeightedTargetLbConfig::ChildConfig child_config;
#9 143.9                                              ^~~~~~~~~~~~
#9 143.9 make: Leaving directory '/usr/local/bundle/gems/grpc-1.38.0'
#9 143.9 *** extconf.rb failed ***
#9 143.9 Could not create Makefile due to some reason, probably lack of necessary
#9 143.9 libraries and/or headers.  Check the mkmf.log file for more details.  You may
#9 143.9 need configuration options.
#9 143.9
#9 143.9 Provided configuration options:
#9 143.9 	--with-opt-dir
#9 143.9 	--without-opt-dir
#9 143.9 	--with-opt-include
#9 143.9 	--without-opt-include=${opt-dir}/include
#9 143.9 	--with-opt-lib
#9 143.9 	--without-opt-lib=${opt-dir}/lib
#9 143.9 	--with-make-prog
#9 143.9 	--without-make-prog
#9 143.9 	--srcdir=.
#9 143.9 	--curdir
#9 143.9 	--ruby=/usr/local/bin/$(RUBY_BASE_NAME)
#9 143.9
#9 143.9 extconf failed, exit code 1
#9 143.9
#9 143.9 Gem files will remain installed in /usr/local/bundle/gems/grpc-1.38.0 for
#9 143.9 inspection.
#9 143.9 Results logged to
#9 143.9 /usr/local/bundle/extensions/aarch64-linux/2.7.0/grpc-1.38.0/gem_make.out
#9 143.9
#9 143.9 An error occurred while installing grpc (1.38.0), and Bundler cannot continue.
#9 143.9 Make sure that `gem install grpc -v '1.38.0' --source 'https://rubygems.org/'`
#9 143.9 succeeds before bundling.
#9 143.9
#9 143.9 In Gemfile:
#9 143.9   grpc

just FYI - running the same as docker build --platform x86_64 -t my-app . works fine.

Please consider bumping the priority to P1. Since grpc is used by most of google cloud gems (via google-gax https://github.com/googleapis/google-cloud-ruby/search?q=google-gax&type=code), any project using google cloud ruby cannot be built natively on apple M1 macs using docker.

I'm not sure what's changed, but this is suddenly resolved for me (all the same steps as the OP, installs successfully with Docker For Mac Version 3.5.2 (<IP_ADDRESS>) and also with Version 3.6.0 (<IP_ADDRESS>87))

can't confirm. It's still broken for me if I build from scratch without the explicit platform linux/amd64 change.

I'm a bit confused. Is this about building arm64 grpc linux gems or x86_64 linux grpc gems?
if this is about building arm64 linux gems, we do have an issue filed for that: https://github.com/grpc/grpc/issues/26391 (and last time I checked it was blocked on rake-compiler-dock not supporting arm64 darwin)
If this is about building x86_64 gems, that seems unnecessary since we already publish precompiled linux native gems with each grpc release (so I don't see why you would need to build your own, and why you would want to do that under docker on mac).
The "building under docker on mac" part of this issue seems irrelevant. Since docker on Mac is backed by a linux VM under the hood, the behavior should really be exactly the same as if you're trying to build under docker on a linux machine or simply trying to build the gem on a linux machine.

@jtattermusch I do not want to build x86_64 gems, no. I want to use whatever Docker decides is the best architectur for my Apple Silicon. I need to explicitly pass a platform to have the gem build, and I don't want to pass a platform.

@jtattermusch I do not want to build x86_64 gems, no. I want to use whatever Docker decides is the best architecture for my Apple Silicon. I need to explicitly pass a platform to have the gem build, and I don't want to pass a platform.

ok, so you're basically saying you want to be able to build arm64 linux ruby gems. That's currently not supported, but it's tracked by https://github.com/grpc/grpc/issues/26391.  IIUC, Docker has nothing to do with this and this issue is basically a duplicate of that issue.
Closing this issue as dupe of https://github.com/grpc/grpc/issues/26391.

I'm not sure, but giving more memory (say 8GB instead of default 2GB) to Docker for mac may resolve some of build problem....

I'm not sure, but giving more memory (say 8GB instead of default 2GB) to Docker for mac may resolve some of build problems....

Confirmed! Not sure why......

Thanks @hiroshi for tip with memory allocation!
So basically, I've had a problem that previously working configuration stopped installing via bundler. Didn't know whats wrong, but grpc stopped to install, giving me HUGE >1MB log that something wrong.
Setting RAM >6GB helped. After installation in my case was totally fine to get RAM back. I hope, that will be fixed, that we need bigger RAM allocation on MacOS using Apple Silicon.
tags for search from google: In file included from third_party/boringssl-with-bazel grpc macos m1 issue

actually problems still remains and im not sure why ticket is closed 😢

I've passed this step with --platform=linux/amd64. amd64 - is to emulate x86 processors, so its not as good in performance terms, but at least it works.

same here. osx m1 catalina.
tried numerous combinations of ruby with specific versions of grpc.
1.45.0 is the only one building in a reasnoable amount of time on my machine.
1.5.x's just hangs forever.
Then, same machine, docker context : any versions hangs FOREVER. alpine, debian, various combo of ruby/grpc...
The most puzzling part is that this dockerfile builds relatively fine on ci or other laptops not running in osx m1
this gem is a fundamental for anything rubygoogle related; auch behaviours are really an issue. browsed all possible issues here, wirhout success


install.sh line 24 $1 independant variable

Hi thanks for the maintenance. After you closed #48, I tried a fresh Fedora 35 server and faced the issue in the title right after hitting "y" for install confirmation.
OT: To be honest, when I create one purpose VM, or CT, I do not really care which OS is under the hood. CentOS, Fedora, Debian ... it does not matter for me :)

Oh right, one sec and I'll fix it.

Should be fixed by #3e12841e91f8153e18af3f34fc74c91235539b70
Please let me know how it goes.

Some warnings at the start:
[WARNING]: Unable to parse /home/kf/killinuxfloor/hosts as an inventory source [WARNING]: No inventory was parsed, only implicit localhost is available [WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all'
and it crashes on:
TASK [install : Obtain SteamCMD] *********************************************** fatal: [<IP_ADDRESS>]: FAILED! => {"changed": false, "msg": "Aborting, target uses selinux but python bindings (libselinux-python) aren't installed!"}

Ah thanks.
Please paste the output of
sestatus

and
cat /etc/os-release

[kf@fedora killinuxfloor]$ sestatus
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Memory protection checking:     actual (secure)
Max kernel policy version:      33
[kf@fedora killinuxfloor]$ cat /etc/os-release
NAME="Fedora Linux"
VERSION="35 (Thirty Five)"
ID=fedora
VERSION_ID=35
VERSION_CODENAME=""
PLATFORM_ID="platform:f35"
PRETTY_NAME="Fedora Linux 35 (Thirty Five)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:35"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f35/system-administrators-guide/"
SUPPORT_URL="https://ask.fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=35
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=35
PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"

Thanks a lot. 99f05eda75b476643b757ae1421d57d286038019 should fix both. Could you please retry?

It fixed those Warnings, but the script still crashes on:
TASK [install : Obtain SteamCMD]
fatal: [<IP_ADDRESS>]: FAILED! => {"changed": false, "msg": "Aborting, target uses selinux but python bindings (libselinux-python) aren't installed!"}
The libselinux-python is not in repository nor installed.

Unfortunately I cannot reproduce this. I just did a fresh install on a brand new Fedora 35 VPS on Vultr. With SELinux enabled.
The error you're receiving doesn't make much sense TBH, since the SteamCMD part doesn't do anything SELinux-related. At least normally. Unless you explicitly prohibit downloads for users via SELinux or something, that is. That part simply downloads a tarball from the Internet.
The other possible explanation is a messed up Ansible installation from some weird source other than the official Fedora repos. Or a messed up Python installation.
Do you think any of those applies?

Actually, I have an idea, brb.

git pull, then one more try please!

I did a new fresh install and snapshot right after yum upgrade to have clean installation ready for tests.
The crash is replaced by:
TASK [install : Create folder for SELinux deployment script] *******************
fatal: [<IP_ADDRESS>]: FAILED! => {"changed": false, "gid": 0, "group": "root", "mode": "0755", "msg": "chown failed: failed to look up user steam", "owner": "root", "path": "/home/steam/selinux", "secontext": "unconfined_u:object_r:user_home_t:s0", "size": 6, "state": "directory", "uid": 0}

:D well yeah. One more try please. We'll get there! I know.

The crash is moving further:
TASK [install : Extract SteamCMD] **********************************************
[WARNING]: Unable to use /home/steam/.ansible/tmp as temporary directory,
failing back to system: [Errno 13] Operation denied: '/home/steam/.ansible'
changed: [<IP_ADDRESS>]
TASK [install : Add Steam to PATH] *********************************************
fatal: [<IP_ADDRESS>]: FAILED! => {"changed": false, "msg": "Path /home/steam/.bashrc does not exist !", "rc": 257}
I have to go to sleep, another test in 16 hours :)

Alright. I guess now it should work after restoring to snapshot.

Unfortunately:
TASK [install : Install Killing Floor 2 Retail (be patient, 26 GB+)] ***********
fatal: [<IP_ADDRESS>]: FAILED! => {"changed": true, "cmd": ["/home/steam/Steam/steamcmd.sh", "+login", "anonymous", "+force_install_dir", "./KF2Server", "+app_update", "232130", "+exit"], "delta": "0:00:16.809795", "end": "2021-12-17 21:37:21.187440", "failed_when_result": true, "rc": 0, "start": "2021-12-17 21:37:04.377645", "stderr": "", "stderr_lines": [], "stdout": "WARNING: setlocale('en_US.UTF-8') failed, using locale: 'C'. International characters may not work.\nRedirecting stderr to '/home/steam/Steam/logs/stderr.txt'\n[  0%] Checking for available updates...\n[----] Verifying installation...\nSteam Console Client (c) Valve Corporation - version<PHONE_NUMBER>\n-- type 'quit' to exit --\nLoading Steam API...OK\n\nConnecting anonymously to Steam Public...OK\nWaiting for client config...OK\nWaiting for user info...OK\n\u001b[33;1mPlease use force_install_dir before logon!\n\u001b[0m Update state (0x3) reconfiguring, progress: 0.00 (0 / 0)\n Update state (0x3) reconfiguring, progress: 0.00 (0 / 0)\n Update state (0x5) verifying install, progress: 71.56<PHONE_NUMBER>0 /<PHONE_NUMBER>5)\nError! App '232130' state is 0x202 after update job.", "stdout_lines": ["WARNING: setlocale('en_US.UTF-8') failed, using locale: 'C'. International characters may not work.", "Redirecting stderr to '/home/steam/Steam/logs/stderr.txt'", "[  0%] Checking for available updates...", "[----] Verifying installation...", "Steam Console Client (c) Valve Corporation - version<PHONE_NUMBER>", "-- type 'quit' to exit --", "Loading Steam API...OK", "", "Connecting anonymously to Steam Public...OK", "Waiting for client config...OK", "Waiting for user info...OK", "\u001b[33;1mPlease use force_install_dir before logon!", "\u001b[0m Update state (0x3) reconfiguring, progress: 0.00 (0 / 0)", " Update state (0x3) reconfiguring, progress: 0.00 (0 / 0)", " Update state (0x5) verifying install, progress: 71.56<PHONE_NUMBER>0 /<PHONE_NUMBER>5)", "Error! App '232130' state is 0x202 after update job."]}
(I use cs_CZ.UTF-8 if this causes the problem?)
I tried updating the "old" KF2 server, runs OK.

https://github.com/GameServerManagers/LinuxGSM/issues/1656
Do you have enough disk space?

As for the locale warning, please try installing langpacks-en first, and tell me if it eliminates that warning. But it shouldn't cause fatal errors I think.

The langpacks-en solved the warning.
I suspected the disk space, but I am not sure, what is wrong. The VM is 60 GB, the KF2 allocation seems to be ~27.4 GB.
I tried to restart server to get rid of possible not-discarded disk space after playing with 60GB VMs, but no effect.
lsblk
NAME                   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda                      8:0    0   60G  0 disk
├─sda1                   8:1    0    1G  0 part /boot
└─sda2                   8:2    0   59G  0 part
└─fedora_fedora-root 253:0    0   15G  0 lvm  /
zram0                  252:0    0  3,8G  0 disk [SWAP]
I can try different setup, but it will take time. Or do you have any idea? :)

Alright, please let me know if it works with a bigger disk.
The warning is fixed via 5a897f5b9a876407129d9a5d305da84b51cac72e

PLAY RECAP *********************************************************************
<IP_ADDRESS>                  : ok=59   changed=36   unreachable=0    failed=0    skipped=6    rescued=0    ignored=0
Success.
Clean Fedora Server 35 minimal install.
The steam installer takes a lot of RAM, I allocated 10 GB and it would still go higher :O
I faced an error 0x402 which seems to be connected with comm to steam servers. So I ran the script again and all good.
Mutators changed ID (they had to reupload them), I suggest change them in default My-Mutators file:
Maxplayers Mutator
2143104493
Classic Scoreboard
1132884083
Display Damage
2625647922

Indeed, updated my internal files already but forgot to do the same with the installer. Fixed in aab3e620b04c6c478ca1358e7b98b1d999c2f9de
Happy to see it succeeded. The 10G RAM usage is weird, I'm usually installing this on comps with 1-2G RAM with sucess.
In any case, can we close this ticket now?

It could install on 2 GB machines, I was just curious, how high that would go. When I create a server, it can eat up to 3-4 GB on some maps with lot of Zeds and players.
I replaced this version over my old server and going to test it. And sure we can close this. Thank you!

Thanks a lot for all the testing and feedback!


Intellisense does not show suggestions

MVC Core applpication
dotnet --info output:
VS Code version:
C# Extension version:
Steps to reproduce
I create a simple model class with attributes, the intellisense do not suggest add the using class and cannot detect the error
Expected  behavior

Actual behavior

Could you provide the information from the issue template?
dotnet --info output:
VS Code version:
C# Extension version:
In addition, in your first screenshot, it looks like there was an exception in the OmniSharp Log that is only partially visible. Could you copy and paste the content of your OmniSharp Log here?

@DustinCampbell can you help me to find the OmniSharp Log, because I don't have Idea where its

It's in your first screenshot above. Here are explicit instructions:

In VS Code, select View->Output to bring up the Output pane.
In the Output pane, select "OmniSharp Log" from the combobox in the top-right corner.
With the mouse, select the whole OmniSharp Log in the Output pane, right-click and choose "Copy".

@DustinCampbell  Ohhh I got it:
Starting OmniSharp server at 6/7/2017, 1:00:43 PM
Target: c:\inetpub\wwwroot\vega\Vega.sln
OmniSharp server started
Path: C:\Users\Carlos-M.vscode\extensions\ms-vscode.csharp-1.10.0\bin\omnisharp\OmniSharp.exe
PID: 14608
OmniSharp: -s c:\inetpub\wwwroot\vega\Vega.sln --hostPID 15160 --stdio DotNet:enablePackageRestore=false --encoding utf-8 --loglevel information formattingOptions:useTabs=false formattingOptions:tabSize=4 formattingOptions:indentationSize=4
info: OmniSharp.Startup
Omnisharp server running using Stdio at location 'c:\inetpub\wwwroot\vega' on host 15160.
info: OmniSharp.DotNet.DotNetProjectSystem
Initializing in c:\inetpub\wwwroot\vega
info: OmniSharp.DotNet.DotNetProjectSystem
Auto package restore: False
info: OmniSharp.DotNet.DotNetProjectSystem
Update workspace context
info: OmniSharp.DotNet.DotNetProjectSystem
Resolving projects references
info: OmniSharp.MSBuild.MSBuildProjectSystem
MSBuild will use local Visual Studio installation.
info: OmniSharp.MSBuild.MSBuildProjectSystem
Detecting projects in 'c:\inetpub\wwwroot\vega\Vega.sln'.
info: OmniSharp.MSBuild.MSBuildProjectSystem
Loading project: c:\inetpub\wwwroot\vega\Vega.csproj
[fail]: OmniSharp.MSBuild.ProjectFile.ProjectFileInfo
The "FindAppConfigFile" task could not be instantiated from the assembly "Microsoft.Build.Tasks.Core, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a". Please verify the task assembly has been built using the same version of the Microsoft.Build.Framework assembly as the one installed on your computer and that your host application is not missing a binding redirect for Microsoft.Build.Framework. Unable to cast object of type 'Microsoft.Build.Tasks.FindAppConfigFile' to type 'Microsoft.Build.Framework.ITask'.
[fail]: OmniSharp.MSBuild.ProjectFile.ProjectFileInfo
The "FindAppConfigFile" task has been declared or used incorrectly, or failed during construction. Check the spelling of the task name and the assembly name.
[warn]: OmniSharp.MSBuild.MSBuildProjectSystem
Failed to load project file 'c:\inetpub\wwwroot\vega\Vega.csproj'.
c:\inetpub\wwwroot\vega\Vega.csproj
    Detecting CSX files in 'c:\inetpub\wwwroot\vega'.

    Could not find any CSX files

    Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.CSharpWorkspaceOptionsProvider

    Configuration finished.

Thanks for the log, that helps a bit. Is there any chance that you could share your project?

dotnet –info
PS C:\inetpub\wwwroot\vega> dotnet --info
.NET Command Line Tools (1.0.4)
Product Information:
Version:            1.0.4
Commit SHA-1 hash:  af1e6684fd
Runtime Environment:
OS Name:     Windows
OS Version:  10.0.15063
OS Platform: Windows
RID:         win10-x64
Base Path:   C:\Program Files\dotnet\sdk\1.0.4
Starting OmniSharp server at 6/7/2017, 12:09:31 PM
Target: c:\inetpub\wwwroot\vega\Vega.sln
OmniSharp server started
Path: C:\Users\Carlos-M.vscode\extensions\ms-vscode.csharp-1.10.0\bin\omnisharp\OmniSharp.exe
PID: 12080
OmniSharp: -s c:\inetpub\wwwroot\vega\Vega.sln --hostPID 9604 --stdio DotNet:enablePackageRestore=false --encoding utf-8 --loglevel information formattingOptions:useTabs=false formattingOptions:tabSize=4 formattingOptions:indentationSize=4
info: OmniSharp.Startup
Omnisharp server running using Stdio at location 'c:\inetpub\wwwroot\vega' on host 9604.
info: OmniSharp.DotNet.DotNetProjectSystem
Initializing in c:\inetpub\wwwroot\vega
info: OmniSharp.DotNet.DotNetProjectSystem
Auto package restore: False
info: OmniSharp.DotNet.DotNetProjectSystem
Update workspace context
info: OmniSharp.DotNet.DotNetProjectSystem
Resolving projects references
info: OmniSharp.MSBuild.MSBuildProjectSystem
MSBuild will use local Visual Studio installation.
info: OmniSharp.MSBuild.MSBuildProjectSystem
Detecting projects in 'c:\inetpub\wwwroot\vega\Vega.sln'.
info: OmniSharp.MSBuild.MSBuildProjectSystem
Loading project: c:\inetpub\wwwroot\vega\Vega.csproj
[warn]: OmniSharp.MSBuild.MSBuildProjectSystem
Failed to load project file 'c:\inetpub\wwwroot\vega\Vega.csproj'.
c:\inetpub\wwwroot\vega\Vega.csproj(1,1)
Microsoft.Build.Exceptions.InvalidProjectFileException: The tools version "15.0" is unrecognized. Available tools versions are "12.0", "14.0", "2.0", "3.5", "4.0".  c:\inetpub\wwwroot\vega\Vega.csproj
at Microsoft.Build.Shared.ProjectErrorUtilities.ThrowInvalidProject(String errorSubCategoryResourceName, IElementLocation elementLocation, String resourceName, Object[] args)
at Microsoft.Build.Evaluation.Project.Data.InitializeForEvaluation(IToolsetProvider toolsetProvider)
at Microsoft.Build.Evaluation.Evaluator4..ctor(IEvaluatorData4 data, ProjectRootElement projectRootElement, ProjectLoadSettings loadSettings, Int32 maxNodeCount, PropertyDictionary1 environmentProperties, ILoggingService loggingService, IItemFactory2 itemFactory, IToolsetProvider toolsetProvider, ProjectRootElementCache projectRootElementCache, BuildEventContext buildEventContext, ProjectInstance projectInstanceIfAnyForDebuggerOnly, SdkResolution sdkResolution)
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(IDictionary2 globalProperties, String toolsVersion, String subToolsetVersion, ProjectLoadSettings loadSettings)    at Microsoft.Build.Evaluation.Project..ctor(String projectFile, IDictionary2 globalProperties, String toolsVersion, String subToolsetVersion, ProjectCollection projectCollection, ProjectLoadSettings loadSettings)
at Microsoft.Build.Evaluation.ProjectCollection.LoadProject(String fileName, IDictionary2 globalProperties, String toolsVersion)    at OmniSharp.MSBuild.ProjectFile.ProjectFileInfo.LoadProject(String filePath, String solutionDirectory, String sdksPath, ILogger logger, MSBuildOptions options, ICollection1 diagnostics, ImmutableArray1& targetFrameworks)    at OmniSharp.MSBuild.ProjectFile.ProjectFileInfo.Create(String filePath, String solutionDirectory, String sdksPath, ILogger logger, MSBuildOptions options, ICollection1 diagnostics)
at OmniSharp.MSBuild.MSBuildProjectSystem.LoadProject(String projectFilePath)
    Detecting CSX files in 'c:\inetpub\wwwroot\vega'.

    Could not find any CSX files

    Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.CSharpWorkspaceOptionsProvider

    Configuration finished.

From: Dustin Campbell<EMAIL_ADDRESS>Sent: Wednesday, June 7, 2017 12:13 PM
To: OmniSharp/omnisharp-vscode<EMAIL_ADDRESS>Cc: Carlos Mac Beath<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [OmniSharp/omnisharp-vscode] Intellisense does not show suggestions (#1552)
Could you provide the information from the issue template?
dotnet --info output:
VS Code version:
C# Extension version:
In addition, in your first screenshot, it looks like there was an exception in the OmniSharp Log that is only partially visible. Could you copy and paste the content of your OmniSharp Log here?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/OmniSharp/omnisharp-vscode/issues/1552#issuecomment-306845100, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AF-vxcGt9TVlDJ9qGavq-qNYZVv3GFvDks5sBswTgaJpZM4Ny6GA.

Is there any chance that you could share your project?

Or, at least, the project file. I have a suspicion of what I think the issue is, but I'd like to verify.

One more ask: Could you increase the OmniSharp logging level and provide the log again?
Grab the OmniSharp Log again.

Thanks!

testing the code on a zip

vega code with vscode error

Thanks! I received the project via email.
Out of curiosity, do you also have Visual Studio installed on the same machine? If so, what version?

Yes, I have Visual Studio Professional 2015 version 14.0.25431.01 Update 3
And Visual Studio Community Edition 2017 (2)
From: Dustin Campbell<EMAIL_ADDRESS>Sent: Wednesday, June 7, 2017 1:48 PM
To: OmniSharp/omnisharp-vscode<EMAIL_ADDRESS>Cc: Carlos Mac Beath<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [OmniSharp/omnisharp-vscode] Intellisense does not show suggestions (#1552)
Thanks! I received the project via email.
Out of curiosity, do you also have Visual Studio installed on the same machine? If so, what version?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/OmniSharp/omnisharp-vscode/issues/1552#issuecomment-306872255, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AF-vxaTsWPoe4gU68SuZtClY6GkAgJ9sks5sBuJDgaJpZM4Ny6GA.

OK. I'm trying to understand why the two OmniSharp Logs you sent have different errors. The first shows this:
[fail]: OmniSharp.MSBuild.ProjectFile.ProjectFileInfo
        The "FindAppConfigFile" task could not be instantiated from the assembly "Microsoft.Build.Tasks.Core, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a". Please verify the task assembly has been built using the same version of the Microsoft.Build.Framework assembly as the one installed on your computer and that your host application is not missing a binding redirect for Microsoft.Build.Framework. Unable to cast object of type 'Microsoft.Build.Tasks.FindAppConfigFile' to type 'Microsoft.Build.Framework.ITask'.
[fail]: OmniSharp.MSBuild.ProjectFile.ProjectFileInfo
        The "FindAppConfigFile" task has been declared or used incorrectly, or failed during construction. Check the spelling of the task name and the assembly name.

However, the second log above shows this:
[warn]: OmniSharp.MSBuild.MSBuildProjectSystem
        Failed to load project file 'c:\inetpub\wwwroot\vega\Vega.csproj'.
c:\inetpub\wwwroot\vega\Vega.csproj(1,1)
Microsoft.Build.Exceptions.InvalidProjectFileException: The tools version "15.0" is unrecognized. Available tools versions are "12.0", "14.0", "2.0", "3.5", "4.0".  c:\inetpub\wwwroot\vega\Vega.csproj
   at Microsoft.Build.Shared.ProjectErrorUtilities.ThrowInvalidProject(String errorSubCategoryResourceName, IElementLocation elementLocation, String resourceName, Object[] args)
   at Microsoft.Build.Evaluation.Project.Data.InitializeForEvaluation(IToolsetProvider toolsetProvider)
   at Microsoft.Build.Evaluation.Evaluator`4..ctor(IEvaluatorData`4 data, ProjectRootElement projectRootElement, ProjectLoadSettings loadSettings, Int32 maxNodeCount, PropertyDictionary`1 environmentProperties, ILoggingService loggingService, IItemFactory`2 itemFactory, IToolsetProvider toolsetProvider, ProjectRootElementCache projectRootElementCache, BuildEventContext buildEventContext, ProjectInstance projectInstanceIfAnyForDebuggerOnly, SdkResolution sdkResolution)
   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.ProjectCollection.LoadProject(String fileName, IDictionary`2 globalProperties, String toolsVersion)
   at OmniSharp.MSBuild.ProjectFile.ProjectFileInfo.LoadProject(String filePath, String solutionDirectory, String sdksPath, ILogger logger, MSBuildOptions options, ICollection`1 diagnostics, ImmutableArray`1& targetFrameworks)
   at OmniSharp.MSBuild.ProjectFile.ProjectFileInfo.Create(String filePath, String solutionDirectory, String sdksPath, ILogger logger, MSBuildOptions options, ICollection`1 diagnostics)
   at OmniSharp.MSBuild.MSBuildProjectSystem.LoadProject(String projectFilePath)

Did you try changing your csproj to include "15.0" in between attempts?

Yes I changed the version of : The tools version "15.0" on Vega.csproj from 15 to 14 and them I added the configuration that you suggest me
From: Dustin Campbell<EMAIL_ADDRESS>Sent: Wednesday, June 7, 2017 1:57 PM
To: OmniSharp/omnisharp-vscode<EMAIL_ADDRESS>Cc: Carlos Mac Beath<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [OmniSharp/omnisharp-vscode] Intellisense does not show suggestions (#1552)
OK. I'm trying to understand why the two OmniSharp Logs you sent have different errors. The first shows this:
    The "FindAppConfigFile" task could not be instantiated from the assembly "Microsoft.Build.Tasks.Core, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a". Please verify the task assembly has been built using the same version of the Microsoft.Build.Framework assembly as the one installed on your computer and that your host application is not missing a binding redirect for Microsoft.Build.Framework. Unable to cast object of type 'Microsoft.Build.Tasks.FindAppConfigFile' to type 'Microsoft.Build.Framework.ITask'.

    The "FindAppConfigFile" task has been declared or used incorrectly, or failed during construction. Check the spelling of the task name and the assembly name.

However, the second log above shows this:
    Failed to load project file 'c:\inetpub\wwwroot\vega\Vega.csproj'.

c:\inetpub\wwwroot\vega\Vega.csproj(1,1)
Microsoft.Build.Exceptions.InvalidProjectFileException: The tools version "15.0" is unrecognized. Available tools versions are "12.0", "14.0", "2.0", "3.5", "4.0".  c:\inetpub\wwwroot\vega\Vega.csproj
at Microsoft.Build.Shared.ProjectErrorUtilities.ThrowInvalidProject(String errorSubCategoryResourceName, IElementLocation elementLocation, String resourceName, Object[] args)
at Microsoft.Build.Evaluation.Project.Data.InitializeForEvaluation(IToolsetProvider toolsetProvider)
at Microsoft.Build.Evaluation.Evaluator4..ctor(IEvaluatorData4 data, ProjectRootElement projectRootElement, ProjectLoadSettings loadSettings, Int32 maxNodeCount, PropertyDictionary1 environmentProperties, ILoggingService loggingService, IItemFactory2 itemFactory, IToolsetProvider toolsetProvider, ProjectRootElementCache projectRootElementCache, BuildEventContext buildEventContext, ProjectInstance projectInstanceIfAnyForDebuggerOnly, SdkResolution sdkResolution)
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.ProjectCollection.LoadProject(String fileName, IDictionary`2 globalProperties, String toolsVersion)
at OmniSharp.MSBuild.ProjectFile.ProjectFileInfo.LoadProject(String filePath, String solutionDirectory, String sdksPath, ILogger logger, MSBuildOptions options, ICollection1 diagnostics, ImmutableArray1& targetFrameworks)
at OmniSharp.MSBuild.ProjectFile.ProjectFileInfo.Create(String filePath, String solutionDirectory, String sdksPath, ILogger logger, MSBuildOptions options, ICollection`1 diagnostics)
at OmniSharp.MSBuild.MSBuildProjectSystem.LoadProject(String projectFilePath)
Did you try changing your csproj to include "15.0" in between attempts?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/OmniSharp/omnisharp-vscode/issues/1552#issuecomment-306874812, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AF-vxRsGjLLIwh-MBq53Sg4Mf5Mhpq2Lks5sBuRbgaJpZM4Ny6GA.

OK. Don't change the ToolsVersion in your csproj. :smile:

If you have VS 2017 Community edition installed, could you try the following?

Close Visual Studio Code
From the Windows Start Menu, launch Developer Command Prompt for VS 2017.
In the Developer Command Prompt, type code . to launch VS Code.
Open your project.

Do you still get the same error?

Ok , I don’t know if that help I used yo aspnetcore-spa generator
From: Dustin Campbell<EMAIL_ADDRESS>Sent: Wednesday, June 7, 2017 2:03 PM
To: OmniSharp/omnisharp-vscode<EMAIL_ADDRESS>Cc: Carlos Mac Beath<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [OmniSharp/omnisharp-vscode] Intellisense does not show suggestions (#1552)
OK. Don't change the ToolsVersion in your csproj. 😄
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/OmniSharp/omnisharp-vscode/issues/1552#issuecomment-306876664, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AF-vxSsQDrpIge6o4QR5IgZ2qi6s3BTsks5sBuXRgaJpZM4Ny6GA.

To be clear, your project is working on my machine, so I'm trying to help you workaround the issue. :smile:

They have to show suggestions like this image ☹
<EMAIL_ADDRESS>From: Dustin Campbell<EMAIL_ADDRESS>Sent: Wednesday, June 7, 2017 2:08 PM
To: OmniSharp/omnisharp-vscode<EMAIL_ADDRESS>Cc: Carlos Mac Beath<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [OmniSharp/omnisharp-vscode] Intellisense does not show suggestions (#1552)
To be clear, your project is working on my machine, so I'm trying to help you workaround the issue. 😄
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/OmniSharp/omnisharp-vscode/issues/1552#issuecomment-306877928, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AF-vxVjsQ9MNEaz8iOD7n1Xa2ynqJTk-ks5sBubqgaJpZM4Ny6GA.

@DustinCampbell You can do this???

Yes, this works for me:

It's something wrong on my machine :( :( :(

Did you try my suggestion above?

If you have VS 2017 Community edition installed, could you try the following?

Close Visual Studio Code
From the Windows Start Menu, launch Developer Command Prompt for VS 2017.
In the Developer Command Prompt, type code . to launch VS Code.
Open your project.

Do you still get the same error?

Yes it work like a charm , but only using Visua Studio 2017 Command Promt
From: Dustin Campbell<EMAIL_ADDRESS>Sent: Wednesday, June 7, 2017 3:18 PM
To: OmniSharp/omnisharp-vscode<EMAIL_ADDRESS>Cc: Carlos Mac Beath<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [OmniSharp/omnisharp-vscode] Intellisense does not show suggestions (#1552)
Did you try my suggestion above?
If you have VS 2017 Community edition installed, could you try the following?

Close Visual Studio Code
From the Windows Start Menu, launch Developer Command Prompt for VS 2017.
In the Developer Command Prompt, type code . to launch VS Code.
Open your project.

Do you still get the same error?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/OmniSharp/omnisharp-vscode/issues/1552#issuecomment-306897426, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AF-vxSB3yvhJ8Qx15daenyYlbU374cymks5sBvd3gaJpZM4Ny6GA.

When I click over the red error does not work only work when I click on the yellow icon
From: Dustin Campbell<EMAIL_ADDRESS>Sent: Wednesday, June 7, 2017 3:18 PM
To: OmniSharp/omnisharp-vscode<EMAIL_ADDRESS>Cc: Carlos Mac Beath<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [OmniSharp/omnisharp-vscode] Intellisense does not show suggestions (#1552)
Did you try my suggestion above?
If you have VS 2017 Community edition installed, could you try the following?

Close Visual Studio Code
From the Windows Start Menu, launch Developer Command Prompt for VS 2017.
In the Developer Command Prompt, type code . to launch VS Code.
Open your project.

Do you still get the same error?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/OmniSharp/omnisharp-vscode/issues/1552#issuecomment-306897426, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AF-vxSB3yvhJ8Qx15daenyYlbU374cymks5sBvd3gaJpZM4Ny6GA.

Yes it work like a charm , but only using Visual Studio 2017 Command Prompt

OK. So it sounds like things are working for you.
By launching VS Code from a VS 2017 Command Prompt, that provides enough context that to initialize an MSBuild build environment. This can be necessary to handle situations where there are several versions of Visual Studio installed. The VS 2017 Command Prompt sets two environment variables that can help MSBuild "find" itself:

VSINSTALLDIR: The path to VS, which could be something like C:\Program Files (x86)\Microsoft Visual Studio\Preview\Enterprise\. This will depend on where VS 2017 is on your machine.
VisualStudioVersion: Set to 15.0.

If you like, you can set these environment variables to correct values before launching VS Code.

When I click over the red error does not work only work when I click on the yellow icon

Note that VS Code's editor experience is not identical to Visual Studio. It's not clear to me exactly what you're describing, but it sounds like you may have encountered one of the differences between the products.

Let me know if you have anymore trouble.

Thank You @DustinCampbell you have been pretty helpfully


ModuleNotFoundError: No module named 'torch.cuda'

I am using pythion 3.7 on Win10, Anaconda Jupyter. I have successfully installed torch-1.10.0+cu113 torchaudio-0.10.0+cu113 torchvision-0.11.1+cu113.
When trying to import torch , I get ModuleNotFoundError: No module named 'torch.cuda'
Detailed error:
ModuleNotFoundError                       Traceback (most recent call last)
<ipython-input-1-bfd2c657fa76> in <module>
      1 import numpy as np
      2 import pandas as pd
----> 3 import torch
      4 import torch.nn as nn
      5 from sklearn.model_selection import train_test_split

~\AppData\Roaming\Python\Python38\site-packages\torch\__init__.py in <module>
    603
    604 # Shared memory manager needs to know the exact location of manager executable
--> 605 _C._initExtension(manager_path())
    606 del manager_path
    607

ModuleNotFoundError: No module named 'torch.cuda'

I found posts for similar error No module named 'torch.cuda.amp'. However, any of the suggested solutions worked. Please advise.

Please use pytorch >=1.6.0, the amp function is released in torch=1.6.


Reproducibility of experiments

Everytime that I run experiments I obtain different metric values. SVGP has a stochasticity component in the selection of mini-batches, where the seed is fixed so the estimated parameters and metrics values like accuracy are always the same. Here, in the doubly stochastic I found this problem to me for doing reproducibility research.
I found how to solve it. In the reparametrization trick, we can fix a seed in the sample of the unit normal (where the propagation through the layers starts). But this is not enough, I also have to set a numpy seed on my script. I do not understand where the numpy seed affects to the doubly stochastic code. Could someone tell me why?
So I would like to know how to modify the code of this package so it would be not necessary to fix numpy seed in every script (because sometimes I forget). I also hope that this could be of help to some people.

Setting seeds in tensorflow is always a bit tricky and counterintuitive: https://www.tensorflow.org/api_docs/python/tf/random/set_random_seed. The DGP code wasn't written with seed reproducibility in mind (though I admit that it should have been), and tensorflow may have changed a bit since this code was written. Thanks for your observations though, and I'd welcome a PR. Regarding the numpy seed it might be for k-means or for some other initialization from numpy.


⚠ Mobitopup has degraded performance

In c8f57bb, Mobitopup (https://napcard.voz.tech) experienced degraded performance:

HTTP code: 200
Response time: 4604 ms

Resolved: Mobitopup performance has improved in ac94892 after 16 minutes.


Update renovatebot/github-action action to v34.48.0

This PR contains the following updates:

Package
Type
Update
Change

renovatebot/github-action
action
minor
v34.47.0 -> v34.48.0

Release Notes

renovatebot/github-action
v34.48.0
Compare Source
See the the changelog for changes in all releases.
34.48.0 (2022-12-02)
Bug Fixes

deps: update renovate/renovate docker tag to v34.48.0 (58187aa)

v34.47.1
Compare Source
See the the changelog for changes in all releases.
34.47.1 (2022-12-02)
Bug Fixes

deps: update renovate/renovate docker tag to v34.47.1 (6e00c73)

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

Branch automerge failure
This PR was configured for branch automerge. However, this is not possible, so it has been raised as a PR instead.


How to enable the grid layout in grafana-reporter

Where to do changes to enable grid layout format like dashboard.

From the readme (also if you run reporter --help):

-grid-layout
Enable grid layout (-grid-layout=1)

Hi @IzakMarais ,
I am using it as pod. So how should i pass this query param.
my podman command is : podman run -d -p 8686:8686 --network=host izakmarais/grafana-reporter
Can you please share some example how should update the grid layout in my pod.