Security issue in dependencies

<EMAIL_ADDRESS>is vulnerable to CVE-2018-3728
for node-sass the problem comes from requiring<EMAIL_ADDRESS>in the package.json
dependency tree is as follow for 4.8.3
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>
and is the same for 4.9.0:
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>
Fix
To fix this<EMAIL_ADDRESS>or superior is required.
Context

NPM version (npm -v): 5.8.0
Node version (node -v): v9.11.1
Node Process (node -p process.versions):

{ http_parser: '2.8.0',
  node: '9.11.1',
  v8: '6.2.414.46-node.23',
  uv: '1.19.2',
  zlib: '1.2.11',
  ares: '1.13.0',
  modules: '59',
  nghttp2: '1.29.0',
  napi: '3',
  openssl: '1.0.2o',
  icu: '61.1',
  unicode: '10.0',
  cldr: '33.0',
  tz: '2018c' }

Node Platform (node -p process.platform): linux
Node architecture (node -p process.arch): x64
node-sass version (node -p "require('node-sass').info"):

node-sass	4.9.0	(Wrapper)	[JavaScript]
libsass  	3.5.4	(Sass Compiler)	[C/C++]

npm node-sass versions (npm ls node-sass):

├─┬<EMAIL_ADDRESS>│ └──<EMAIL_ADDRESS>deduped
└──<EMAIL_ADDRESS>
Related issues
request:
https://github.com/request/request/issues/2926
https://github.com/request/request/issues/2874
node-sass:
https://github.com/sass/node-sass/issues/2352
https://github.com/sass/node-sass/issues/2288
https://github.com/sass/node-sass/issues/2262
https://github.com/sass/node-sass/issues/2252
https://github.com/sass/node-sass/pull/2170
https://github.com/sass/node-sass/pull/2256
Problem
xzyfer in #2352

It cannot be fixed without break node < 4 support

I also see in #2288 that the problem is solved in node-sass v5.
So this ticket need to stay opened until v5 is released. Please don't close it.

i see the fix is on master :) is there a timeline on when the next major or minor release will be with this change?

@samrispaud
That's what I said ;-)

I also see in #2288 that the problem is solved in node-sass v5.
So this ticket need to stay opened until v5 is released. Please don't close it.

What about creating a 4.10.0 release that just bumps the request dependency ?

Bumping the dependency would break support for Node < 4
On Wed., 9 May 2018, 12:41 pm Daniel Jackson<EMAIL_ADDRESS>wrote:

What about creating a 4.10.0 release that just bumps the request
dependency ?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/sass/node-sass/issues/2355#issuecomment-387698434,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjZWPrx7wQEUkTqYNHbDloFb4PBwGhAks5twsfagaJpZM4Tq1z4
.

@cloakedninjas It's a wait and see for v5 release.

My understanding is that the engine property has no actual effect beyond
npm producing a warning. The install will still happen.
The way to resolve this error without breaking BC is to replace request all
together with something that's supports Node 0.10+
On Wed., 9 May 2018, 9:22 pm Chris Eppstein<EMAIL_ADDRESS>wrote:

As I understand it, you can change the node engine version requirement and
do a minor release. It doesn't violate semver for the people on the old
node versions because the new versions of the package are excluded from
that code's dependency version resolution.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/sass/node-sass/issues/2355#issuecomment-387847684,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjZWJUyGWTrunvxfUG5PIvAVtwZ4xNBks5tw0IQgaJpZM4Tq1z4
.

Node 4 became end of life on May 1st (source). Can you provide some background on the decision to continue supporting it after end of life rather than pushing out a security fix? I'm not disagreeing with any decision but rather seek to understand it. For example, are there a large number of Node 4 users?

Following this we should at least be under nodejs 6.x.
@ataylorme Personally I'm a archlinux user so it's nodejs 10.x for me :)

node-gyp, another dependency of node-sass, also uses the old version of the request library. I asked if they would update it, but the answer was no. Does that mean that the security issue will remain because both request dependencies will be loaded (the updated one from node-sass and the old one from node-gyp)?

node-gyp is targeting just "request": "2", which will match any version 2.x.x. It should use whatever version of request is pulled in by other dependencies (with deduplication) or the most recent 2.x.x release if nothing else in the tree requires it.

@xzyfer huh, I guess that's true now that engine-strict defaults to false and engineStrict is no longer supported in package.json. that's super irritating.

node-gyp is targeting just "request": "2", which will match any version 2.x.x. It should use whatever version of request is pulled in by other dependencies (with deduplication) or the most recent 2.x.x release if nothing else in the tree requires it.

Ah okay, did not understand that before (I got the info on the node-gyp repo, too), but now I got it, thanks! :)

so, is there a way to solve the issue github is warning me about?

@florianbrinkmann no worries, I was two sentences into a comment agreeing with you over on the node-gyp issue before my brain finished processing what a bare semver "2" meant

@lsimone current consensus I think is to wait for the v5 merge https://github.com/sass/node-sass/pull/2312 as @xzyfer mentioned

There is no version 4.7.0 published on npmjs.com, 4.6.9 and 4.7.1
https://www.npmjs.com/package/node-sass?activeTab=versions
There is a 4.7.0 tag here on GitHub though: https://github.com/sass/node-sass/tree/v4.7.0

hey, still confirmed we waiting v5 for this fix? aside of the 4.7.0 downgrade as a temporary workaround

Moderate        Prototype pollution
Package         hoek
Patched in      > 4.2.0 < 5.0.0 || >= 5.0.3
Dependency of   node-sass [dev]
Path            node-sass > request > hawk > boom > hoek
More info       https://nodesecurity.io/advisories/566
Moderate        Prototype pollution
Package         hoek
Patched in      > 4.2.0 < 5.0.0 || >= 5.0.3
Dependency of   node-sass [dev]
Path            node-sass > request > hawk > cryptiles > boom > hoek
More info       https://nodesecurity.io/advisories/566
Moderate        Prototype pollution
Package         hoek
Patched in      > 4.2.0 < 5.0.0 || >= 5.0.3
Dependency of   node-sass [dev]
Path            node-sass > request > hawk > hoek
More info       https://nodesecurity.io/advisories/566
Moderate        Prototype pollution
Package         hoek
Patched in      > 4.2.0 < 5.0.0 || >= 5.0.3
Dependency of   node-sass [dev]
Path            node-sass > request > hawk > sntp > hoek
More info       https://nodesecurity.io/advisories/566
Moderate        Memory Exposure
Package         tunnel-agent
Patched in      >=0.6.0
Dependency of   node-sass [dev]
Path            node-sass > request > tunnel-agent
More info       https://nodesecurity.io/advisories/598

Yarn users could use "resolutions" in package.json for temporary workaround.
 "resolutions": {
    "node-sass/**/request": "^2.82.0"
  }

https://yarnpkg.com/lang/en/docs/selective-version-resolutions/

Bumping the dependency would break support for Node < 4
In my opinion, fixing security vulnerabilities should be higher priority than supporting deprecated runtimes.
Now that Github sends out vulnerability reports, any project depending on node-sass has been looking pretty bad in the last 3 weeks.

non official response as an issue janitor on this project We appreciate that security checkers are flagging the dependency, and that concerns you. request is used to download the binaries for our package only, but because of the prototype pollution aspect that can still be a concern. We have fallback binary download options through https://github.com/sass/node-sass#binary-configuration-parameters, and our version of request shouldn't interfere with your production version that is pinned to a better version of request.
We are not going to break backwards compatibility in our v4, but we've already addressed this in the v5 branch. I only mop up issues, and @xzyfer is on a well deserved vacation, so chiming in that we need to address this isn't going to move this faster. I've tried to avoid ad hominem attacks, and I ask you all to do the same ❤ ❤ ❤

why hello everybody, i am the workaround fairy
update node-sass in your package.json to a commit in the v5 branch
"node-sass": "git+https://github.com/sass/node-sass.git#a8005ad3e34b3310536888c299a186623a178f80",

now the security warnings are gone, and i'm in the future :+1:

Hey @xzyfer & @nschonni,
How do you suggest we install 4.7.0, when that version is not published to NPM? See @ntwb's comment. We are unable to use the suggested downgrade workaround as that version just does not exist on NPM.

Look at the GitHub releases for one before we pinned the request package,
and use a version < that one.
On Thu., 7 Jun. 2018, 8:35 am Guido Bouman<EMAIL_ADDRESS>wrote:

Hey @xzyfer https://github.com/xzyfer & @nschonni
https://github.com/nschonni,
How do you suggest we install 4.7.0, when that version is not published to
NPM? See @ntwb https://github.com/ntwb's comment. We are unable to use
the suggested downgrade workaround as that version just does not exist on
NPM.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sass/node-sass/issues/2355#issuecomment-395309348,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjZWMLEvCKLAORn7ho3y10EN8D_KQ0Yks5t6MnKgaJpZM4Tq1z4
.

That would mean using 4.6.1, instead of 4.7.0, missing out on the memory fixes in 4.7.0, right?

@guidobouman Why not temporarily use the git tag? https://github.com/mollie/api-documentation/blob/master/package.json#L25

It would appear so. It's unfortunate but the request packing breaking
semver has left us little choice.
On Thu., 7 Jun. 2018, 11:41 am Vernon de Goede<EMAIL_ADDRESS>wrote:

@guidobouman https://github.com/guidobouman Why not temporarily use the
git tag?
https://github.com/mollie/api-documentation/blob/master/package.json#L25
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sass/node-sass/issues/2355#issuecomment-395359275,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjZWOfKixWmH_KRGKNvXsfQ8uQTwt4Pks5t6PVKgaJpZM4Tq1z4
.

Pushing 4.7.0 to npm would allow us to use the memory enhancements with the semver broken version of request, while default users will still get 4.7.1++.
@vernondegoede That means including an untagged, unstable version of the package. The package-lock.json can not lock this in properly, preventing predictable builds on our CI. On the other hand, I could use the 4.7.0 tag from git...
"node-sass": "git+https://github.com/sass/node-sass.git#4.7.0",

If 4.7.0 is no longer published then it was unpublished for a reason. Also
an unpublished version cannot be republished.
On Thu., 7 Jun. 2018, 12:52 pm Guido Bouman<EMAIL_ADDRESS>wrote:

Pushing 4.7.0 to npm would allow us to use the memory enhancements with
the semver broken version of request, while default users will still get
4.7.1++.
@vernondegoede https://github.com/vernondegoede That means including an
untagged, unstable version of the package. The package-lock.json can not
lock this in properly, preventing predictable builds on our CI. On the
other hand, I could use the 4.7.0 tag from git...
"node-sass": "git+https://github.com/sass/node-sass.git#4.7.0",
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sass/node-sass/issues/2355#issuecomment-395378560,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjZWG_N_Q-myQHRZQhKvPZu_jsw2rAiks5t6QX4gaJpZM4Tq1z4
.

With keeping 4.7.1 published I don't see why one would unpublish 4.7.0. Especially if this is the diff: https://github.com/sass/node-sass/compare/v4.7.0...v4.7.1 I guess it was because 4.7.0 broke semver along with request 2.81.0. Sure, but that's what v4.7.1 is for.
Anyhow, I'm using the git tag for now, please do not unpublish that as well.

In line with the comments about node-gyp above, I'd been able to pull in the latest version of request by specifying an earlier version of node-sass. However, node-gyp version 3.6.3 and on, released a week ago, pins request to <2.82.0, which means that I've had to pin node-gyp to 3.6.2 in addition to specifying an earlier version of node-sass. That's working well, but I'm wondering if that has any implications for node-sass v5. Is it possible that v5 would pin node-gyp or would wait on node-gyp v4, which will use the latest version of request?
The issue in the node-gyp repo is here: https://github.com/nodejs/node-gyp/issues/1439.

node-gyp maintainer here.  I'd recommend dropping the explicit dependency on node-gyp in your package.json and instead use the node-gyp is bundled with npm and is implicitly available.

We've needed to bump the minimum version a couple times to work around
node-gyp issues. I'm not sure we can safely rely on what is bundled with
npm.
I can try digging up the specific issues when I'm back from vacation next
week.
On Thu., 14 Jun. 2018, 8:33 pm Ben Noordhuis<EMAIL_ADDRESS>wrote:

node-gyp maintainer here. I'd recommend dropping the explicit dependency
on node-gyp in your package.json and instead use the node-gyp is bundled
with npm and is implicitly available.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sass/node-sass/issues/2355#issuecomment-397395712,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjZWDZ2e_qwXSYH-hwo8B_SaCgFW-7Vks5t8qyOgaJpZM4Tq1z4
.

I don't believe we have tests for the scripts. We also cannot rely on
Travis because it out tests the latest release of each version. So an older
release of Node 4 might fail to install for instance.
I'll dig up an example issue.
On Thu., 14 Jun. 2018, 9:26 pm Rohit Hazra<EMAIL_ADDRESS>wrote:

@xzyfer https://github.com/xzyfer do the tests cover the issues you are
mentioning? removing node-gyp gave me
6101 passing (1m)
580 pending
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sass/node-sass/issues/2355#issuecomment-397410803,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjZWPVPJTpFnIzpkpb1NFR1uCt3lP4Hks5t8rjpgaJpZM4Tq1z4
.

Actually it looks like it's been two years since we've had issue. It's probably safe to remove the node-gyp dependency. We'll give it a shot in the release, thanks

Ill make a PR.

@bnoordhuis removing node-gyp from dependencies is causing build failure, so is it possible that node-gyp is not installed with some node installations?

It'll be related to how we call node-gyp in scripts/build.js

@xzyfer ill try and update the script.

Sorry but can someone explain to me if there is a workaround for this currently?
Is there a specific way those of us using the latest version of node can use v5 currently or is this just a sit and wait type scenario?

@xzyfer the script is working, but i had to do npm install -g node-gyp once.
var globalBinPath = spawn.sync('npm', ['bin', '-g'], { stdout: 'inherit' }).stdout.toString().trim();

  var args = [require.resolve(globalBinPath+'/node-gyp'), 'rebuild', '--verbose'].concat(
    ['libsass_ext', 'libsass_cflags', 'libsass_ldflags', 'libsass_library'].map(function(subject) {
      return ['--', subject, '=', process.env[subject.toUpperCase()] || ''].join('');
    })).concat(options.args);

@xzyfer i was thinking of something like this
/**
 * find node-gyp
 */

function getNodeGyp(){
  var globalBinPath = spawn.sync('npm', ['bin', '-g'], { stdout: 'inherit' }).stdout.toString().trim();
  var localBinPath = spawn.sync('npm', ['bin'], { stdout: 'inherit' }).stdout.toString().trim();
  var nodeGypExec = null;

  try{
    nodeGypExec = require.resolve(globalBinPath+'/node-gyp');
  }catch(errorGlobal){
    console.error('unable to resolve node-gyp globally!`');
  }
  if(!nodeGypExec){
    try{
      nodeGypExec = require.resolve(localBinPath+'/node-gyp');
    }catch(errorGlobal){
      console.error('unable to resolve node-gyp locally!`');
    }
  }

  if(!nodeGypExec){
    console.error('unable to resolve node-gyp. Try running `npm install node-gyp -g`.');
  }
  return nodeGypExec;
}

@xzyfer node-gyp is required to be installed either locally or globaly. see https://travis-ci.org/sass/node-sass/jobs/393589241

Can someone give us an update on when the upgrade or drop of node-gyp will happen? When the new release is expected? Currently many people are getting this security issue and confused I think.

@marbuser & @izelnakri I would suggest using a git tag for the time being;
"devDependencies": {
  "node-sass": "git+https://github.com/sass/node-sass.git#v4.7.0"
}

@guidobouman node-sass v4.7.0 still requires request ~2.79.0, which in turn requires hawk ~3.1.3 which brings us again to hoek v2.x.x. So not a fix for the security issue.

@guidobouman that doesn't work:
└─┬<EMAIL_ADDRESS>(git+https://github.com/sass/node-sass.git#a51eca7f8bafdc9bafab76d2305fedc64503304c)
  └─┬<EMAIL_ADDRESS>    └─┬<EMAIL_ADDRESS>      ├─┬<EMAIL_ADDRESS>      │ └──<EMAIL_ADDRESS>deduped
      ├──<EMAIL_ADDRESS>      └─┬<EMAIL_ADDRESS>        └──<EMAIL_ADDRESS>deduped

Not sure if it will help anyone but I ended up forking node-sass and updating dependencies, then using my fork in projects. When node-sass v5 comes out I'll need to update them anyway and can move away from my fork then.

@bra1n Then you have a different package limiting the request version to 2.79.0

@guidobouman Good point. I actually do have another package like that... it's<EMAIL_ADDRESS>from gulp-sass. Argh. Seems like they're aware of this issue.

Request v2.79.0 also includes another low severity issue according to Snyk.
https://snyk.io/vuln/npm:is-my-json-valid:20180214
✗ Low severity vulnerability found on<EMAIL_ADDRESS>- desc: Regular Expression Denial of Service (ReDoS)
- info: https://snyk.io/vuln/npm:is-my-json-valid:20180214
- from: [...] ><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>

Still no progress on this issue?

Node <= 4 is no longer getting security updates. I find not improving security because it would affect people running EOL versions of Node a very weak argument.

+1 security issues should be fixed ASAP

Why do you keep deleting comments from people? Is there guidelines on how to comment an issue that we're breaking? I never saw anyone do this. a bit disrespectful.

@adamvaughan i don't support on deleting the comments but I am not seeing any point in the further discussions on this topic.
The reason why the current major version (4.x) of node-sass cannot fix these security issues is because node-sass uses node-gyp v3.3.1 and request v2.79.0.
If we upgrade these packages, then we are removing the support for node < 4.
now there are many people saying why do we support node < 4, well the answer is we do.
best way is to wait for node-sass v5

Any plans when node-saas v5 is planing to be released?

The point of commenting on an open source project is to voice our concerns towards a feature request, or an issue, in this case: lack of security. There's probably more people commenting here asking you guys to fix a critical security issue than people using node < 4. We're now way over node 8.
You're choosing to continue to release code that has a critical security issue in order to support a minority of people using node < 4 - which is fine as you're entitled to manage your project the best you can, but you're also choosing to silence a community that supports and uses your tool in both personal and commercial projects just because you consider "there is no point on discussing further", and that's just in poor taste.

Why do you keep deleting comments from people?

"mee too" and "+1" comments add no practical value. They only add noise.

Is there guidelines on how to comment an issue that we're breaking

Comments should add some new information to the issue at hand. Otherwise they're just adding more work for people trying to the useful information in the issue.
In most cases the (now deleted) comments showed no indication the OP had made any effort to read the existing discussion.

The point of commenting on an open source project is to voice our [..]

You can use GitHubs to emoji reactions to add support for an issue, or subscribe for updates.

to support a minority of people using node < 4

Please don't make baseless generalisations. We still get a lot of install for Node < 4. Even a minority of users at our install volume is a lot of installs.
For v5 we made the hard to call to drop support for Node < 6.

We've explained multiple times in this issue why this is blocked, however hidden by GitHub due to the high volume of "me too" comments.
As a summary:

we are unable to upgrade without breaking things Node < 4 users
v5 updates our dependency on request

but node-gyp is still locked the same version for the same reason

After some investigation from @Rohithzr in #2417 there isn't a path for us to drop our dependency on node-gyp at this time. So npm audit will continue to complain (as far as we've been informed).
We will be moving forward with v5 in the coming weeks, but at this point in time it's unclear whether the request update will quiet the warning.

Update
<EMAIL_ADDRESS>removed the dependency on hoek (request/request#2943)
two weeks ago. This restores support for Node < 4. This means we bump
to the latest request which hopefully resolves npm audit warnings.
Should we need to address node-gyp warning we'll track that in a
different issue.

@xzyfer thats a great news i suppose, I shall run some tests and make a PR

Is there any alternative package I can use if V5 if taking to release?

@Rohithzr see https://github.com/sass/node-sass/pull/2435
I've tested locally and it looks positive. We'll see what CI thinks.

@vishnugupta20 not really, you are welcome to try v5 (method described in above comments)

@vishnugupta20 if #2435 passes I'll release a v4.9.1 with request updated.

@xzyfer @Rohithzr  See this structure ├─┬<EMAIL_ADDRESS>│ └─┬<EMAIL_ADDRESS>│   └─┬<EMAIL_ADDRESS>│     └─┬<EMAIL_ADDRESS>│       ├─┬<EMAIL_ADDRESS>│       │ └──<EMAIL_ADDRESS>│       ├──<EMAIL_ADDRESS>│       └─┬<EMAIL_ADDRESS>│         └──<EMAIL_ADDRESS>└─┬<EMAIL_ADDRESS> ├──<EMAIL_ADDRESS>  └─┬<EMAIL_ADDRESS>   └──<EMAIL_ADDRESS>deduped
<EMAIL_ADDRESS>is giving me venerability issue. How is resolve it, can you suggest me?

@vishnugupta20 wait for the 4.9.1 release.
It will be great if you keep reading the comments and discussions actively.

@xzyfer @Rohithzr when we can expect a request 4.9.1 and node -saas V5 release?
Thanks for your quick reply.

One thing to note is that this security issue is mainly irrelevant to node-sass. GitHub is flagging this as a security vulnerability, but node-sass never sees any exposure to your live code. The attack vector is when a request from the outside world can trigger a node-sass build with custom data. CSS is (usually) precompiled during a build stage, whether on a CI or a local machine. It runs on machines you protect from the outside world, it's never really exposed on a network.
Anything opening node-sass to the outside world is a highly specific case. The only use case I can currently think of is something like CodePen / JSFiddle. And even then my best guess is that node-sass is not vulnerable because nor they nor request use methods that could lead to remote code execution.

You're totally correct. There is no actual security issue to node-sass
users.
Unfortunately npm@6 makes noise simply if a flagged package is in the
dependency tree regardless of context.
Lots of people just want to quieten npm regardless of any risk.
On Thu., 5 Jul. 2018, 1:08 am Guido Bouman<EMAIL_ADDRESS>wrote:

One thing to note is that this security issue is mainly irrelevant to
node-sass. GitHub is flagging this as a security vulnerability, but
node-sass never sees any exposure to your live code. The attack vector is
when a request from the outside world can trigger a node-sass build with
custom data. CSS is (usually) precompiled during a build stage, whether on
a CI or a local machine. It runs on machines you protect from the outside
world, it's never really exposed on a network.
Anything opening node-sass to the outside world is a highly specific case.
The only use case I can currently think of is something like CodePen /
JSFiddle. And even then my best guess is that node-sass is not vulnerable
because nor they nor request use methods that could lead to remote code
execution.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sass/node-sass/issues/2355#issuecomment-402505201,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjZWPtyJFDjslJ1cJe5lf5Ju8p21_PWks5uDNprgaJpZM4Tq1z4
.

Not every project has the luxury to update their build environment to the latest stack. Some people are stuck with node versions below 4.
The node-sass team has decided to support node < 4 when they started their v4. At the same time they respect the semver guidelines. This means they are stuck with those node versions for v4. This package is downloaded 1.6 million times a week. That means that even with a 1% usershare with node < 4, you'd still be breaking builds for 16.000 downloads a week. That's a lot of people left in the cold just to remove a warning that did not affect this package anyhow.

Does the entire developer community not have a responsibility to discourage use of EOLed platforms, specifically because they are no longer getting security updates?

Sure, it might be a lower risk due to the use case of sass but making the blanket assumption that such an extremely highly used package runs on machines protected from the outside world that are never exposed on a network is a dangerous attitude for maintainers of a open source code to have.
By that argument maybe you could say who cares about the half a million people on v4 potentially having to upgrade, since it’s only ever used on dev machines right?
Telling millions of people to ignore security warnings is negligence really.
Although some people might want to just quiet warning messages I would say a significant portion of people actually don’t want to run software with known security vulnerabilities.
That attitude, combined with your deleting and hiding comments that are critical of your process and then passing them off as “me too and 1+ comments” (especially when there are other comments on the opposite side of the same topic that aren’t hidden) is the reason people are getting a bit frustrated here.
For me personally, I was frustrated and a little confused that a solution couldn’t have been found already, but I was still on your side, until you started deleting the comments.
Initially when it was said that v4 couldn’t break backwards compatibility, v5 was said to be right around the corner, but since that turned out not to be the case we really should have been trying to either find another solution or do something more to try to get v5 out. From the outsider perspective it has seemed a bit like you stopped focusing on this issue.

Update
Resolved in<EMAIL_ADDRESS>Upgrade to quiet npm.

Re-opening till https://github.com/nodejs/node-gyp/pull/1471 lands, but keeping locked

node-gyp 3.8.0 was released with a bump in their request version https://github.com/nodejs/node-gyp/blob/master/CHANGELOG.md#v380-2018-08-09.
Clearing your lockfile and re-installing may resolve your issues now. PR to update the minimum version in this repo has been submited.

Update
Resolved in<EMAIL_ADDRESS>Upgrade to quiet npm.


Appears to need Java 8

I tried using this plugin, but it appears to require Java 8 underneath.  Is that correct?

I doubt it.

Yeah, you're right.  I was chasing a wild goose.  Thanks anyway, and thanks for the plugin!


tortoise-tts: init at 2.3.0

Description of changes
tortoise-tts is "A multi-voice TTS system trained with an emphasis on quality".
rotary-embedding-torch is a python module needed by tortoise-tts.

Things done

Built on platform(s)

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

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

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

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

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

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 176924 run on x86_64-linux 1

1 package failed to build:

tortoise-tts (python39Packages.tortoise-tts)

1 package built:

python39Packages.rotary-embedding-torch (python310Packages.rotary-embedding-torch)

Result of nixpkgs-review pr 176924 run on x86_64-linux 1
1 package failed to build:
* tortoise-tts (python39Packages.tortoise-tts)

1 package built:
* python39Packages.rotary-embedding-torch (python310Packages.rotary-embedding-torch)

tortoise-tts requires a NVIDIA gpu, so maybe that's why it fails building on your machine?

I assume this package bundles the weights of a pretrained model. Those are often a couple of megabytes. What is our policy on including that in nixpkgs?

Last time I tested, this tool downloaded the compiled models on the first run


HHH-13675 HHH-13651 (5.3)

https://hibernate.atlassian.net/browse/HHH-13675
https://hibernate.atlassian.net/browse/HHH-13651

Created against master by mistake.


Fix inconsistent naming in the dummy key hash structs

Also derive Default for DummyHash and all of its hash types since they are all empty structs.

CI failure is a broken dependency, fixed in a commit of #461

I cherry-picked Sanket's commit and rebased on top of it

FTR, we plan to remove the DummyKey* types in the future. You should be able to test everything with MiniscriptKey = String type.


fix: create permissions on DB import

SUMMARY

A few bugs related to catalogs and permissions:

When a database is imported, catalog and schema permissions are not created. Ideally we should have the import functionality call the corresponding command (CreateDatabaseCommand in this case) to prevent duplicate logic (the import/export flow was created before the introduction of commands). For now this PR just adds the logic manually.
When a database is updated, datasets and charts are not having their catalog_perms updated.
Databricks has a weird behavior where get_default_catalog() ⊈ get_catalog_names(), so I fixed it.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

N/A
TESTING INSTRUCTIONS

Added and updated tests.
ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Required feature flags:
[ ] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[ ] Introduces new feature or API
[ ] Removes existing feature or API

@supersetbot label 4.1


Update eslint and eslint-config-stylelint dependancies

When in Rome, as they say, updates stylelint-config-cssrecipes to use AVA for tests (This brings this repo to the same configuration for tests for the other stylelint-config-standard, stylelint-config-suitcss, and stylelint-config-wordpress repos)

It also fix the failing tests :smirk:

:+1: Thanks !

Nice, thanks


refactor(directives.js): restrict default AC -> AE

let's be honest, no one uses Class directives in Angular1 and this will be more inline with Angular2. I can also change it to 'AEC' for the defaults to be backwards compatible.

Hi @gdi2290, thanks for the PR. This is a breaking change that can cause too many headaches, so I think it is best not to change this

The default has been changed to AE already some time in the past (that's also what the $compile docs say). I assume compile will overwrite this restriction defintion somwhere. Maybe we should clean this up, then.

This is not about the global default. It is the default of the internal ngDirective function which is used for creating directives such as ngCloak, ngInit, ngNonBindable, ngStyle, ngSwitchDefault/When etc.
For most of them E wouldn't make sense, so I think it is fine (although it would be fine for some of them).


Resolves #495: Fixed dead anchors in links

According to @edewit, document-attributes.adoc is included in all transformations

@tradej @gastaldi For some reason i thought that was still an issue. Sorry for the confusion. Updated based on this info.

LGTM now.

merging

merged: 2bc4a138f1968b7dc415fffc0e63313bbdab660b


Add GPS Tracking

Add gps tracking #258

Is this stable enough to push to my build?

@Mickey32111 , with the latest bug fix it should be. Working fine for me. Tested everything I could think of.

what it does?
nice to see you here pokeadvisor guy.

@herculys, Hi! This implements Location tracking as described in https://github.com/favll/pogom/issues/258
When enabled, it will follow you around with a little blue dot.
Unfortunately, you will need to set up SSL or run from localhost since most modern browsers will not allow Geolocation on unsecured connections.

@lax20attack So, from a user stand point I will say that I was super frustrated with PokemonGo-Map having geolocation capability but it not working.  Now that I know geo-location is disabled on non-ssl connections maybe the config page can "offer" geolocation as an option to be enabled with the disclaimer of "you need a secure connection or to be on localhost for this to work" and a link on how to setup something like nginx... ?

@PhDeez Setting up nginx + SSL isn't something an amateur can do with a guide. That's part of the reason why I'm bearish on the whole geolocation thing. Too much hassle for little benefit.

@nborrmann Agreed, however I do think setting up an ssh tunnel is much easier and most people could handle that.  Furthermore, making it an option to enable/disable (with it disabled by default) makes it so not everyone even has to use it...

I just wanted to jump in here for those people looking for something like this...
I just started using the PogomBOT yesterday and when you receive a location you can click on the map which then shows your geolocation compared to where the coordinates are of the notified Pokemon (and can also hit drive there to open in your map application).
Point is... if you don't want to have to deal with connecting to localhost for the map and don't want to set up SSL using Telegram is a good option.

@nborrmann I was looking into using docker-compose with this nginx container: https://hub.docker.com/r/jwilder/nginx-proxy/ to add ssl capabilities easily. This is the current docker-compose file I've been working on: compuguy/719745fcc89b20476150678174f00cd7

Thank you for your work, but as @nborrmann said this would make the setup too complex.


[RESOLVED] S100-Santiago has been restarted (uptime < 10m)

Problem started at 20:51:49 on 2023.07.19
Problem name: S100-Santiago has been restarted (uptime < 10m)
Host: S100-Santiago
Severity: Warning
Operational data: 00:00:46
Original problem ID: 32856
Event details in Zabbix: http://<IP_ADDRESS>/tr_events.php?triggerid=23522&eventid=32856

Problem has been resolved in 9m 43s at 21:01:32 on 2023.07.19
Problem name: S100-Santiago has been restarted (uptime < 10m)
Host: S100-Santiago
Severity: Warning
Original problem ID: 32856


Issues Tab - Editing Fixes

The New update button should have the ability to set a date
the edit button should just bring up the same new update modal (with date)
create a new edit button on the accordion which will bring up the Edit Issue modal which controls Title, Active, Priority, start date, & resolution date.
implement a character limit on the issue text box of 500 char

As a (type of user)
I want (goal)
so that (reason/ why/ value)
Acceptance Criteria
Scenario 1:
GIVEN ... (you or your condition)
WHEN ... (what you do)
THEN ... (what you see)
Scenario 2:
xxxxxx
Validation Rules?
(If yes, list here)
Screenshot
(Link above will always be the most up-to-date version.)

@jadmsaadaot half this card has been completed. are we able to get the modal fixes done this sprint?


Reduce collaborative revert reliance on ChannelManager

Fixes #1546.
In situations where the collaborative revert protocol might be useful, it is likely that the channel will have been erased from the ChannelManager.
Before this patch we had unavoidable dependencies on the ChannelManager, but with this patch we are able to perform the protocol without looking for the relevant ChannelDetails via the ChannelManager.

Currently untested beyond the automatic test! Maybe @bonomat wants to give this a go since he created the original issue and implemented the feature.

A large chunk of the diff is formatting and style fixes. I should have split it up, but too late now 😞

Relevant diff here, @holzeis.

Manually tested the following scenarios

Collab revert of healthy ln and healthy dlc channel (position open): works
Collab revert of healthy ln and unhealthy dlc channel (position stuck at processing CloseConfirm): fails, see logs below.

2023-11-20 13:45:07  INFO collaborative_revert: coordinator::collaborative_revert: Proposing collaborative revert channel_id="9355173cd320ff0db683bfd35868bd4368c75d7b13c0b56b2731a6cf0f5997e0" coordinator_address=bcrt1q3g2z9f283zm7q9jt87qhq7jm9k5nmrk9553azf coordinator_amount=197664 trader_amount=1664
2023-11-20 13:45:07  INFO collaborative_revert: coordinator::admin: Proposed collaborative revert channel_id="9355173cd320ff0db683bfd35868bd4368c75d7b13c0b56b2731a6cf0f5997e0"
2023-11-20 13:45:07  INFO coordinator::message: Sending trader message: CollaborativeRevert { channel_id: [147, 85, 23, 60, 211, 32, 255, 13, 182, 131, 191, 211, 88, 104, 189, 67, 104, 199, 93, 123, 19, 192, 181, 107, 39, 49, 166, 207, 15, 89, 151, 224], coordinator_address: bcrt1q3g2z9f283zm7q9jt87qhq7jm9k5nmrk9553azf, coordinator_amount: Amount(0.00197664 BTC), trader_amount: Amount(0.00001664 BTC), execution_price: 35396, funding_txo: OutPoint { txid: e097590fcfa631276bb5c0137b5dc76843bd6858d3bf83b60dff20d33c175593, vout: 0 } } trader_id=03ea287dd9081b7945a94525410075afd1b976a6cbae75f5c2bb139e71131078b8
2023-11-20 13:45:07  INFO collaborative_revert_confirm: coordinator::routes: Confirming collaborative channel revert channel_id="9355173cd320ff0db683bfd35868bd4368c75d7b13c0b56b2731a6cf0f5997e0"
2023-11-20 13:45:07  INFO collaborative_revert_confirm: coordinator::collaborative_revert: Confirming collaborative revert channel_id="9355173cd320ff0db683bfd35868bd4368c75d7b13c0b56b2731a6cf0f5997e0" txid="6460e7779573c11c85db2e99951b16c0c475b1a19708f1543dec3782e7ad22ea"
2023-11-20 13:45:07  INFO collaborative_revert_confirm: coordinator::collaborative_revert: Broadcasting collaborative revert transaction txid="6460e7779573c11c85db2e99951b16c0c475b1a19708f1543dec3782e7ad22ea"
2023-11-20 13:45:07  INFO collaborative_revert_confirm: ln_dlc_node::ldk_node_wallet: Broadcasting transaction txid=6460e7779573c11c85db2e99951b16c0c475b1a19708f1543dec3782e7ad22ea raw_tx=020000000001019355173cd320ff0db683bfd35868bd4368c75d7b13c0b56b2731a6cf0f5997e00000000000ffffffff0220040300000000001600148a1422a54788b7e0164b3f81707a5b2da93d8ec5800600000000000016001435904b3292c46ad0a6dffd5f154a51b57b4712e6040047304402202dfa39ed4f600d3cc5e17bc37acb2a4b18ec010f43292e8f44dec205391408bb02201054a916e137d0fb401ec1222b8832e100b7e8413150629d7e05397e946c5ce801473044022036b3c7a3e3b7a10b2317dcfe436eb3ce17450a4a0dbebd13a5fbe78132ba601602206a3c2f61f38e9f677d161b86ca883ad3ef3ce0e6dac230d4c18a5304503d461201475221033e80a2dc5f99a4626e23bfd5bd42610e139eec8dd4ddf9f00d5504d2235296c92103a42c769bca373d1e782cbf288b8a1b546fbf162154aeb11237fc5246a185f12452ae00000000
2023-11-20 13:45:07 ERROR collaborative_revert_confirm: coordinator::routes: Could not confirm collaborative revert: Could not broadcast transaction: Failed to broadcast transaction 6460e7779573c11c85db2e99951b16c0c475b1a19708f1543dec3782e7ad22ea. Esplora client error: HttpResponse(400) channel_id="9355173cd320ff0db683bfd35868bd4368c75d7b13c0b56b2731a6cf0f5997e0"
2023-11-20 13:45:07 ERROR collaborative_revert_confirm: coordinator::routes: error=InternalServerError("Could not confirm collaborative revert")

It appears the amounts are calculated incorrectly
    "outputs": [
        {
            "addresses": [
                "bc1q3g2z9f283zm7q9jt87qhq7jm9k5nmrk9umnrwn"
            ],
            "script": "00148a1422a54788b7e0164b3f81707a5b2da93d8ec5",
            "script_type": "pay-to-witness-pubkey-hash",
            "value": 197664
        },
        {
            "addresses": [
                "bc1qxkgykv5jc34dpfkll4032jj3k4a5wyhxrz6mud"
            ],
            "script": "001435904b3292c46ad0a6dffd5f154a51b57b4712e6",
            "script_type": "pay-to-witness-pubkey-hash",
            "value": 1664
        }
    ],

Manually tested the following scenarios
* Collab revert of healthy ln and healthy dlc channel (position open): works

* Collab revert of healthy ln and unhealthy dlc channel (position stuck at processing CloseConfirm): fails, see logs below.

Thanks for testing, @holzeis! I'll look into it locally. It would be nice if we could write better tests for this feature, but it's hard in the context of the current e2e tests.

Note, I am not sure how we can test a scenario, where the ln channel is deleted, but the transaction has not been broadcasted.

I think the easiest way would be to prevent the nodes from broadcasting a transaction. Still a bit fiddly as some transactions need to be broadcast so there needs to be some hacky logic involved.

@holzeis: Yet another version! Unfortunately I messed up the diff, so you'll have to review the whole thing again :(

LGTM 🚀
Thanks for iterating over it so many times 🙂


Migrate from cadl to Typespec for the following services

Quick search the whole repo, the following services are still using CADL, we need to move them into typespec.
https://github.com/Azure/azure-rest-api-specs/blob/6b992c049ed7d6a95465d5c0a2234fc54c87b9bf/specification/newrelic/NewRelic.Management/main.cadl
https://github.com/Azure/azure-rest-api-specs/blob/903a8802a13b5f3c05cdceea9ba4716aaee5de45/specification/liftrqumulo/Qumulo.Management/main.cadl
https://github.com/Azure/azure-rest-api-specs/blob/74b23e211143b3c8abed4bced1cd10fc3000bb46/specification/voiceservices/resource-manager/Microsoft.VoiceServices/cadl/main.cadl
https://github.com/Azure/azure-rest-api-specs/blob/0e13373c80d638f9e0370877aee0ffe5c3101f5d/specification/containerstorage/resource-manager/Microsoft.ContainerStorage/cadl/main.cadl
https://github.com/Azure/azure-rest-api-specs/blob/3a2c320161b3576c6282189535602cb541a254b9/specification/servicenetworking/resource-manager/Microsoft.ServiceNetworking/cadl/TrafficController.cadl

cc @mikekistler  @allenjzhang


[OPPRO-797] Support to load the libparquet.so.1000 when we use Gluten with Velox backend.

What changes were proposed in this pull request?
https://github.com/oap-project/gluten/issues/797
How was this patch tested?
(Please explain how this patch was tested. E.g. unit tests, integration tests, manual tests)
(If this patch involves UI changes, please attach a screenshot; otherwise, remove this)

ping @jinchengchenghh @zhejiangxiaomai  PTAL.


New json ld context generator

The current LD context generator only generates type-scoped contexts with the assumption that incoming LD documents will always advertise the type of every node using a @type property. For instance, take the following TreeLDR schema:
base <https://example.com>;

type Foo {
  bar: Bar
}

type Bar {
  foo: Foo
}

using the command tldrc -i example.tldr json-ld-context https://example.com/Foo https://example.com/Bar, the following LD context is generated:
{
  "Foo": {
    "@id": "https://example.com/Foo",
    "bar": "https://example.com/Bar"
  }
  "Bar": {
    "@id": "https://example.com/Bar",
    "foo": "https://example.com/Foo"
  }
}

This is correct for an input LD document such as this:
{
  "@type": "Foo",
  "bar": {
    "@type": "Bar",
    "foo": {}
  }
}

Note how each node contains a @type entry, which is not specified in the original TreeLDR schema. So we want to be able to handle documents where no type is specified, such as
{
  "bar": {
    "foo": {}
  }
}

However it is not possible to specify the type of all the nodes using the JSON-LD context (specifying a @type entry inside the context only apply for value objects).
The purpose of the PR is to create a new LD context generator algorithm without this limitation. Type scoped contexts are useful to avoid conflicts and ambiguities between term definitions, so they should be generated whenever possible. Otherwise, terms should be defined globally, or inside property scoped contexts to avoid clashes whenever possible (if there is no cycle).
For the above example, the following context should be generated:
{
  "bar": "https://example.com/Foo/bar",
  "foo": "https://example.com/Bar/foo"
}

Ambiguous terms
Without type scoped contexts, ambiguities can arise when two layouts define fields with the same name.
type Foo {
  bar: Bar,
  prop: A
}

type Bar {
  foo: Foo,
  prop: B
}

Here there is an ambiguity on the prop term definition. These ambiguities should be detected by the LD context generator.
To solve this ambiguity, we could define some "main" layout (the expected layout of the input documents) and some included secondary layouts. Then the prop term of the main layout is defined globally while the prop term of the secondary layout is defined in a property-scoped context.
Type scoped contexts
Type scoped contexts can still be generated at the condition that the TreeLDR layout explicitly contains a required field holding its type.
type Foo {
  required rdf:type as myType,
  bar: Bar
}

Then the following context can be generated:
{
  "myType": "@type",
  "Foo": {
    "bar": "https://example.com/Foo/bar"
  }
}

Note: we should allow @type to be a valid field name so we can write:
type Foo {
  required rdf:type as @type,
  bar: Bar
}

which would generate the following context without @type alias:
{
  "Foo": {
    "bar": "https://example.com/Foo/bar"
  }
}

External contexts
Sometimes contexts are loaded alongside other contexts. For now, the context generator assumes the generated context will be the only one loader and should include all the term definitions. Instead, it would be nice to specify a list of contexts that will be loaded before the generated one. The generator can then omit the definitions already present in the input contexts.
Implementation status

[x] json-ld refactor
[x] Simple implementation without caring for ambiguities
[x] Ambiguities detection
[x] Ambiguities resolution using primary/secondary layouts and property scoped contexts
[x] Type scoped contexts
[ ] External contexts

I discuss here some current limitations for the generation of type scoped contexts. Consider the following TreeLDR document:
base <https://example.com>;
use <http://www.w3.org/1999/02/22-rdf-syntax-ns#> as rdf;
use <http://www.w3.org/2000/01/rdf-schema#> as rdfs;

type Foo {
	bar: Bar,
	rdf:type: required &rdfs:Class
}

type Bar {
	foo: Foo,
	rdf:type: required &rdfs:Class
}

We want to generate the following JSON-LD context, with two type scoped contexts:
{
  "type": "@type",
  "Foo": {
    "@id": "https://example.com/Foo",
    "bar": "https://example.com/Foo/bar"
  },
  "Bar": {
    "@id": "https://example.com/Bar",
    "foo": "https://example.com/Bar/foo"
  }
}

This should be doable with the command:
tldrc -i example.tldr json-ld-context https://example.com/Foo https://example.com/Bar

Anonymous layouts cause ambiguous term definitions
In this example, each type define a type field for the rdf:type property with the same layout required &rdfs:Class. However because this layout is defined inline, it is anonymous and is given a blank node identifier. One blank node identifier for each occurrence, which means that the two fields in fact refer to two different layouts with different blank node identifiers. This causes the LD context generator to detect an ambiguity for the type term.
This can be solved by generating a unique blank node identifier for structurally equivalent anonymous layouts. This is already the case for references.
Type scoped context term name
In this example, we expect the type scoped context to be defined with the term Foo and Bar, extracted from the layout names. However this is completely inconsistent with the semantics of TreeLDR. The layout of the type field is required &rdfs:Class. The current semantics of TreeLDR dictates that the expected value for this field is hence an IRI, not Foo nor Bar.
One solution to this problem would be to allow the definition of custom reference layouts. One could specify what values the reference can take, and how it maps to actual IRIs. For instance with an enumeration layout (not yet implemented):
layout MyReference [ "Foo" = Foo, "Bar" = Bar ];

This states that a value of the layout MyReference is either the string Foo referring to https://example.com/Foo or Bar referring to https://example.com/Bar. Custom references are a power tool that can be useful outside the scope of simply generating type scoped contexts.

Until custom references are implemented, the generation of type scoped contexts is enabled only with the --rdf-type-to-layout-name option that explicitly asks for the value of the rdf:type property to be interpreted as the layout name. Once they are implemented, the option will be deprecated in favor of custom layouts.
tldrc -i example.tldr json-ld-context --rdf-type-to-layout-name https://example.com/Foo https://example.com/Bar

External contexts implementation is deferred (I'll probably need to harmonize the way vocabulary is handled before I can do that).


Diacritic characters

Hiya,
My issue is that the diacritic characters are not being converted properly. When tabula extracts data from the .pdf, the extraction works beautifully. However, upon conversion into a .csv document, the diacritic characters are not translated and are instead replace with mismatching symbols.
I understand that this is an issue your team has faced before but I could not find a solution embedded within the GitHub issues or on the website. Please let me know if there is a worked solution to this problem.
Cheers,
Paul-Eric

Hiya Paul-Eric,
The problem is likely with Microsoft Excel, opening the CSV file with the
wrong "encoding". If you check in our Github issues or just Google around
with these terms, you should be able to find instructions on how to open a
CSV in your version of Excel using the UTF-8 encoding -- which should make
Excel display the diacritics correctly.
Jeremy B. Merrill
Sent from my mobile device
On Tue, Nov 19, 2019, 5:15 PM prayner96<EMAIL_ADDRESS>wrote:

Hiya,
My issue is that the diacritic characters are not being converted
properly. When tabula extracts data from the .pdf, the extraction works
beautifully. However, upon conversion into a .csv document, the diacritic
characters are not translated and are instead replace with mismatching
symbols.
I understand that this is an issue your team has faced before but I could
not find a solution embedded within the GitHub issues or on the website.
Please let me know if there is a worked solution to this problem.
Cheers,
Paul-Eric
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/tabulapdf/tabula/issues/1074?email_source=notifications&email_token=AAEF3GQJMLATI7FDPNDEXUDQURQQHA5CNFSM4JPKFEO2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4H2POCCA,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEF3GWO2XNEH23K4BVWUSLQURQQHANCNFSM4JPKFEOQ
.

Fantastic, I was using the CSV in R but all I had to do was specify:
read.csv("tabula_file.csv", encoding = "UTF-8")
Thanks for the prompt reply Jeremy.


Base Type Rework (Entity, Interface)

Pull Request Description
What issue does this change request address? (Use "#" before the issue to link it, i.e., #42.)
Works towards #1486 by differentiating base types
What are the significant changes in functionality due to this change request?
Splits BaseType into two more specific bases:

BaseEntity, for entities in RAVEN (handlers of interfaces, e.g. Models.ROM, OutStreamBase)
BaseInterface, for algorithms/strategies/implementations of entities (e.g. SupervisedLearning, PostProcessors)
Everything in RAVEN should now inherit from either BaseEntity or BaseInterface, not BaseType. Note that there's a lot of overlap between BaseEntity and BaseInterface until we decide who is what for non-interface-using Entities such as Samplers and Distributions.

Also more clearly defines the following base types:

InputUser, for objects that make use of the input specs through input specifications and reading
MessageUser, for objects that make use of the RAVEN message handler

Also, when MessageHandler.py is imported, adds the getMessageHandler(name) to the builtins so it can be accessed generally, as is done with the Python Logging module. This could pave the way to consider using that module instead of our own custom-rolled message handler.
These changes resulted in pushing for the use of factories to instantiate objects within RAVEN rather than directly instantiating them.

For Change Control Board: Change Request Review
The following review must be completed by an authorized member of the Change Control Board.

[x] 1. Review all computer code.
[x] 2. If any changes occur to the input syntax, there must be an accompanying change to the user manual and xsd schema. If the input syntax change deprecates existing input files, a conversion script needs to be added (see Conversion Scripts).
[x] 3. Make sure the Python code and commenting standards are respected (camelBack, etc.) - See on the wiki for details.
[x] 4. Automated Tests should pass, including run_tests, pylint, manual building and xsd tests. If there are changes to Simulation.py or JobHandler.py the qsub tests must pass.
[x] 5. If significant functionality is added, there must  be tests added to check this. Tests should cover all possible options.  Multiple short tests are preferred over one large test. If new development on the internal JobHandler parallel system is performed, a cluster test must be added setting, in  XML block, the node <internalParallel> to True.
[x] 6. If the change modifies or adds a requirement or a requirement based test case, the Change Control Board's Chair or designee also needs to approve the change.  The requirements and the requirements test shall be in sync.
[x] 7. The merge request must reference an issue.  If the issue is closed, the issue close checklist shall be done.
[x] 8. If an analytic test is changed/added is the the analytic documentation updated/added?
[x] 9. If any test used as a basis for documentation examples (currently found in raven/tests/framework/user_guide and raven/docs/workshop) have been changed, the associated documentation must be reviewed and assured the text matches the example.

Thanks for your review, @wangcj05
I have pushed an update addressing your comments.

Job Test CentOS 7 on bd6568c : invalidated by @joshua-cogliati-inl
restarted civet

Job Test CentOS 8 on 0851e67 : invalidated by @joshua-cogliati-inl
The syntax error should be impossible.

Checklist passed...
PR can be merged


'Get Services' Icon Link height is smaller than other two boxes; hover over is smaller as a result

Resolves once the user logs in due to the 4th bike making the boxes all be the same size. Issue only occurs if not logged in.

There is no log-in on the site, I'm assuming you're referring to something else?

Wow, I just found this. Yes, definitely the wrong repo.


Inequality test fails in custom check

Check file:
checks for my_dataset:
  - custom_check != 1:
      custom_check query: |
        SELECT 1

Scan result:
      custom_check != 1 [FAILED]
        check_value: 1.0

SODA-1022


expand arbitrary pane

is there a way to expand an arbitrary pane?
imagine the following scenario:
<script lang="ts">
  import { Splitpanes, Pane } from 'svelte-splitpanes';
</script>

<Splitpanes>
  <!-- pane1 -->
  <Pane size={25} snapSize={18}>
    ...
  </Pane>

  <!-- pane2 -->
  <Pane size={75}>
    ....
  </Pane>
</Splitpanes>

i would like to add a button on the page, which when clicked, would expand pane1 to its set size (25).
is this possible?
perhaps a way of doing this would be to export the IPane instance from the Pane, so that the consumer could bind to it, and use the setSz function (im not sure if this function means setSize, just taking my chances lol)

Please check this demo https://orefalo.github.io/svelte-splitpanes/examples/prog-resize and see if it fits your requirements.
Please close this ticket once confirmed
Thank you

perhaps a way of doing this would be to export the IPane instance from the Pane, so that the consumer could bind to it, and use the setSz function (im not sure if this function means setSize, just taking my chances lol)

@orefalo, the submitter pointed out something I was worry about - we share too much data internal in IPane for the user.
We shell modify the events of this library, and export only a limited part of IPane to the user (maybe only export the Pane component to the user, and not the IPane one). (Breaking change)

Please check this demo https://orefalo.github.io/svelte-splitpanes/examples/prog-resize and see if it fits your requirements.
Please close this ticket once confirmed Thank you

@demetrius-mp, please notice that your case is much more simple - you don't need to use the Svelte bind directive, as in the example.

Agreed, the events could be simplified.

@demetrius-mp, notice please that even when you change one pane size, this axiom must hold:(some panes have (user-)defined sizes, and some not)

The defined min sizes sum is not greater than 100.
The defined sizes sum is not greater than 100.
If all the panes have a defined size, then the defined size sum must be equal to 100.

If you don't do this, bad things will happen.
@orefalo we need to doc it

the demo worked perfectly! so sorry for not reading the documentation and noticing that there was an example.
perhaps you could add on that props table, which properties are "reactive". probably dumb, but my initial thought was that the size prop was only used on the initialization of the component.
anyways, thanks so much, im going to close the issue!


multiclass val accuracy during training

Changes:

remove sampling for validation splits
update validation accuracy to support multi-label (previously we support only two-label tasks)

Refactored code such that instead of using different break mode for calculating validation accuracy, data reading way is changed.

Wait no. I didn't want this merged.

Oh this wasn't merging into Main. Okay no worries.


BBD testing for Graph and Sort

BDD Testing with Gherkin in Pycharm using Behave. Algorithms need to be tested.

Initialize Cucumber.js in Pycharm

Install behave for pycharm


Is there a way to add a pipeline middleware for every route without using via?

Yes, you can use the raw middleware


RFC: derived BEq should come with an API

Proposal
While many derived type classes are mostly relevant for programming only (Repr) or inherently need no API besides the instance (DecidableEq), for BEq users may expect to perform proofs about, but have a hard time because the precise definition is hard to see.
The SizeOf derived instance follows the pattern of creating a Ty.con.sizeOf_spec theorem.
For BEq, it would make sense to follow the pattern, and create either

A singleTy.beq_spec (x y : Ty) : x == y = …`

or
manyTy.beq_spec (…) : con1 … == con2 … = …`

lemmas (which arguably could be @[simp])

or both, or both unless the data type has too many constructors, and the n×n combinatoric explosion is too large, in which case maybe omit the per-constructor ones.
Another aspect of having a good BEq API would be to be deriving LawfulEq (always with BEq? always when possible? when asked to?).
Community Feedback
This was brought to me by @TwoFX.
Ideas should be discussed on the Lean Zulip prior to submitting a proposal. Summarize all prior discussions and link them here.
Impact
Add :+1: to issues you consider important. If others benefit from the changes in this proposal being added, please ask them to add :+1: to it.

RFC accepted!


Clarification of token import instructions

Just FYI, most people will have different servers than this https://s54-fr.ikariam.gameforge.com

@pecataToshev Thank you for pointing this out


Fix typos

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

entity-framework/core/miscellaneous/logging.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

@tomRedox thanks for the fix.


Feat: missing style attrs of Node

Style attrs missing fixed

Converts style attr object to html string
adds string to html tag

Adds logic to maintain version number in one place

@nadeem-cs Few GH workflows are failing in this PR, can you please resolve them?


Create reusable components

This is a parent and does not need its own branch.
Components:

[x] #84
[x] #53
[x] #54
[x] #85
[x] #98
[x] #28
[x] #130
[x] #134
[x] #82
[x] #83
[ ] #103
[x] #138
[x]  #139
[ ] Calendar
[x] #235
[x] #363
[x] #379

Add more here as we discover them...

Vil si mesteparten av dette er gjort nå


InputMap.action_has_event should capture TouchScreenButton actions

Godot version
3.4
System information
Windows 10
Issue description
I found it to be unexpected that InputMap.action_has_event("action", event) doesn't capture TouchScreenButton InputEventAction events.
I believe that it's because the project InputMap doesn't directly include the button as an action trigger, but given that the button is firing off the same event, shouldn't it be captured by this method?
Would it make sense for TouchScreenButtons with action set to be automatically added to the InputMap?
Steps to reproduce
Create a valid TouchScreenButton with "button" as the action, create the action in the InputMap, and try this code:
func _input(event):
	if event is InputEventAction:
		print("InputEventAction {%s, %s} ✓" % [event.action, event.pressed])
	if InputMap.action_has_event("button", event):  # <-- not fired.
		print("InputMap.action_has_event ✓")

Minimal reproduction project
Demo project showing the handling of a InputEventAction (compared to action_has_event): touch-mrp.zip

TouchScreenButton is not a type of InputEvent, so I don't see how this could be made to work. How could the source of the InputEventAction be distinguished this way?

I'm not sure I understand what you mean - can you a provide an example of what you're referring to?
Thinking about it more, it's very possible that the documentation doesn't capture the true purpose of this method. After I filed this issue, I found the event_is_action method which helped me fix my issue. That being said, I still really don't understand the distinction between the two other than that the latter ignores modifiers (irrelevant in my case) and captures TouchScreenButton actions for some reason.


Installer installs unnecessary (other platform files)

regression (#513 ), same thing again, unnecessary files in installation
@ffmpeg-installer
@ffprobe-installer
Note  I run "npm clean-install" before the build

I've changed nothing -- it might be something that happens on your end (unsure why).
When I try, my installer for Windows is around 66mb and for Mac it's around 107mb 🤷♂
Are they differently sized when you create your .exe or .dmg installer?

Possibly. Could be on my side, unsure why boris. I've cleaned all (I hope), clean checkout of main. If your build is ok, please ignore me.
Video Hub App 3 Setup 3.0.0.exe is 220MB
in this path, there are all platform files, not win32-x64 only as I would expect
... \release\win-unpacked\resources\app.asar.unpacked\node_modules@ffmpeg-installer\darwin-x64
... \release\win-unpacked\resources\app.asar.unpacked\node_modules@ffprobe-installer\ ...
build output:
Robert@lighthunt-xps MINGW64 ~/Work/Video-Hub-App (main)
$ npm run electron

<EMAIL_ADDRESS>electron C:\Users\Robert\Work\Video-Hub-App
npm run build:prod && electron-builder build && npm run buildsize

<EMAIL_ADDRESS>build:prod C:\Users\Robert\Work\Video-Hub-App
npm run build -- -c production

<EMAIL_ADDRESS>build C:\Users\Robert\Work\Video-Hub-App
npm run electron:serve-tsc && ng build --base-href ./ "-c" "production"

<EMAIL_ADDRESS>electron:serve-tsc C:\Users\Robert\Work\Video-Hub-App
tsc -p tsconfig-serve.json

WARNING: Zone.js does not support native async/await in ES2017.
These blocks are not intercepted by zone.js and will not triggering change detection.
See: https://github.com/angular/zone.js/pull/1140 for more information.

WARNING: Using differential loading with targets ES5 and ES2016 or higher may
cause problems. Browsers with support for ES2015 will load the ES2016+ scripts
referenced with script[type="module"] but they may not support ES2016+ syntax.
Generating ES5 bundles for differential loading...
ES5 bundle generation complete.
chunk {0} runtime-es2020.409e6590615fb48d139f.js (runtime) 1.45 kB [entry] [rendered]
chunk {0} runtime-es5.409e6590615fb48d139f.js (runtime) 1.45 kB [entry] [rendered]
chunk {2} polyfills-es2020.a0f23dec1ae343454a15.js (polyfills) 36.1 kB [initial] [rendered]
chunk {3} polyfills-es5.532dbc91238b27d811ad.js (polyfills-es5) 129 kB [initial] [rendered]
chunk {1} main-es2020.a6d13b7ba05672ad4c4a.js (main) 1.6 MB [initial] [rendered]
chunk {1} main-es5.a6d13b7ba05672ad4c4a.js (main) 1.72 MB [initial] [rendered]
chunk {4} styles.a6e0c8e0f5426dfdffc4.css (styles) 1.45 kB [initial] [rendered]
Date: 2020-10-14T15:52:00.092Z - Hash: 9b6bb75839dee513ff03 - Time: 99384ms
WARNING in C:\Users\Robert\Work\Video-Hub-App\src\app\components\views\file-path.service.ts depends on path. CommonJS or AMD dependencies can cause optimization bailouts.
For more info see: https://angular.io/guide/build#configuring-commonjs-dependencies
WARNING in C:\Users\Robert\Work\Video-Hub-App\node_modules\path\path.js depends on util. CommonJS or AMD dependencies can cause optimization bailouts.
For more info see: https://angular.io/guide/build#configuring-commonjs-dependencies
WARNING in C:\Users\Robert\Work\Video-Hub-App\node_modules\ngx-virtual-scroller_ivy_ngcc_\fesm2015\ngx-virtual-scroller.js depends on @tweenjs/tween.js. CommonJS or AMD dependencies can cause optimization bailouts.
For more info see: https://angular.io/guide/build#configuring-commonjs-dependencies
ΓÇó electron-builder  version=22.7.0 os=10.0.18363
ΓÇó loaded configuration  file=C:\Users\Robert\Work\Video-Hub-App\electron-builder.json
ΓÇó packaging       platform=win32 arch=x64 electron=8.3.0 appOutDir=release\win-unpacked
ΓÇó downloading     url=https://github.com/electron/electron/releases/download/v8.3.0/electron-v8.3.0-win32-x64.zip size=71 MB parts=8
ΓÇó downloaded      url=https://github.com/electron/electron/releases/download/v8.3.0/electron-v8.3.0-win32-x64.zip duration=2m22.908s
ΓÇó downloading     url=https://github.com/electron-userland/electron-builder-binaries/releases/download/winCodeSign-2.6.0/winCodeSign-<IP_ADDRESS>z size=5.6 MB parts=1
ΓÇó downloaded      url=https://github.com/electron-userland/electron-builder-binaries/releases/download/winCodeSign-2.6.0/winCodeSign-<IP_ADDRESS>z duration=21.426s
ΓÇó building        target=nsis file=release\Video Hub App 3 Setup 3.0.0.exe archs=x64 oneClick=false perMachine=true
ΓÇó downloading     url=https://github.com/electron-userland/electron-builder-binaries/releases/download/nsis-<IP_ADDRESS>/nsis-<IP_ADDRESS>.7z size=1.3 MB parts=1
ΓÇó downloaded      url=https://github.com/electron-userland/electron-builder-binaries/releases/download/nsis-<IP_ADDRESS>/nsis-<IP_ADDRESS>.7z duration=7.956s
ΓÇó downloading     url=https://github.com/electron-userland/electron-builder-binaries/releases/download/nsis-resources-3.4.1/nsis-resources-<IP_ADDRESS>z size=731 kB parts=1
ΓÇó downloaded      url=https://github.com/electron-userland/electron-builder-binaries/releases/download/nsis-resources-3.4.1/nsis-resources-<IP_ADDRESS>z duration=6.754s
ΓÇó building block map  blockMapFile=release\Video Hub App 3 Setup 3.0.0.exe.blockmap

<EMAIL_ADDRESS>buildsize C:\Users\Robert\Work\Video-Hub-App
sh ./bin/buildSizeCheck.sh

WARNING: build may be larger than desired

I think, one option is to manually delete the irrelevant files from the node_modules/@ffmpeg-installer before creating the exe 🤔

If the problem is on my side only, than I see no issues, I can always delete it from installation etc. But it's good to verify the actual release for the crowd. build size warning worked after-all ;-)


Use abbreviation element for small caps

Changes from <span class="caps"> to <abbr class="caps">
Updates tests accordingly
Adds font-feature-settings and .caps example

I rebased this, just in case you change your mind. :) I can see not wanting to change the span, but I still think abbr is the tag that makes more sense for this feature.

Not merging this was the right call! It’s unnecessarily prescriptive.


[WIP] Pull in the real power_state column off of service

@AparnaKarve - This is just a start - Wanted you to take a look at what  I was thinking.
dependent on https://github.com/ManageIQ/manageiq/pull/12963

cc - @gmcculloug

@miq-bot add_label wip

@miq-bot remove_label wip


Update to 1.8.1 of OpenTelemetry dependencies

Microsoft Reviewers: Open in CodeFlow

/backport to release/8.0

/azp run


Pressing Ctrl+Backspace in data viewer filter clears active cell

System information:

Ubuntu 20.04
DBeaver 7.0.4

Describe the problem you're observing:
If I press Ctrl+Backspace to delete a word in the filter of the data viewer it clears the active cell and does not delete the word
Steps to reproduce, if exist:

Right click on a table and select view data
Enter some text in the filter input

Press Ctrl + Backspace

The active cell gets cleared

But I expected this:

thanks for the bug report

It is not a bug. ctrl+backspace for "Set default value" action.
You can change it in Preferences->Keys.

Oh I see, though I think is a little contra-intuitive that it clears the cell when the filter is focused.

Fixed in version 7.1.2


Unable to run model.fit() in WSL environment

Click to expand!
Issue Type
Bug
Have you reproduced the bug with TF nightly?
Yes
Source
binary
Tensorflow Version
2.12.0
Custom Code
Yes
OS Platform and Distribution
Windows 11 installed with WSL Ubuntu
Mobile device
No response
Python version
python=3.9 and 3.11.3
Bazel version
No response
GCC/Compiler version
No response
CUDA/cuDNN version
cudatoolkit=11.8.0, nvidia-cudnn-cu11==<IP_ADDRESS>
GPU model and memory
NVIDIA GeForce RTX 3070 Laptop GPU and 32GB memory
Current Behaviour?
A bug happened!
I have no issue running the same code under windows environment (IDE: Jupyter Notebook).
However, I have problem to run the same code in WSL environment (IDE: Jupyter Notebook).
The code below is the root cause of the error message. (Note: train_set and validate_set is the output from imagedatagenerator flow_from_directory)
history = model.fit(train_set, validation_data = validate_set, epochs = 10, verbose = 2)
Error message:
2023-05-09 01:04:47.558215: I tensorflow/core/common_runtime/executor.cc:1210] [/device:CPU:0] (DEBUG INFO) Executor start aborting (this does not indicate an error and you can ignore this message): INVALID_ARGUMENT: You must feed a value for placeholder tensor 'Placeholder/_0' with dtype int32
[[{{node Placeholder/_0}}]]
Standalone code to reproduce the issue
import os
import csv
import time
import numpy as np
import pandas as pd
import tensorflow as tf
import matplotlib.pyplot as plt

from keras import regularizers
from keras.models import Sequential, load_model
from keras.layers import Dense, Conv2D, MaxPooling2D, Flatten, Dropout
from keras.callbacks import EarlyStopping
from keras.preprocessing.image import ImageDataGenerator
from sklearn.model_selection import GridSearchCV
from scikeras.wrappers import KerasClassifier

# Get list of physical GPU devices
gpu_list = tf.config.list_physical_devices('GPU')

if len(gpu_list) > 0:
    # Check Number of GPUs
    print('number of GPUs available:', len(gpu_list))
    print('\nGPU name:')

    # Check GPU Name
    for i in range(len(gpu_list)):
        print(str(i + 1) + '.', gpu_list[i].name.split(':', 1)[1])

    # Set memory growth for the GPU
    tf.config.experimental.set_memory_growth(gpu_list[0], True)

    # Set visible devices to only use the first GPU
    tf.config.experimental.set_visible_devices(gpu_list[0], 'GPU')

    # Verify that the GPU is being used
    print('\nUsing GPU:', gpu_list[0])

# Set attribute variable
attr = 'gender'

# Set directories
root_dir = '/mnt/c/Users/Ang/Desktop/11 DL/Assignment/DeepFashion/images'
data_dir = os.path.join(root_dir, 'data')
label_path = os.path.join(data_dir, attr + ' label.csv')
model_path = os.path.join(data_dir, attr + ' model.h5')

# Set data augmentation for train set
train_generator = ImageDataGenerator(
    rescale = 1./255,         # Normalize the data
    rotation_range = 0,       # Randomly rotate images by up to certain degrees
    width_shift_range = 0,    # Randomly shift images horizontally by up to certain percentage of the width
    height_shift_range = 0,   # Randomly shift images vertically by up to certain percentage of the height
    shear_range = 0,          # Randomly apply shear transformation with a max shear of certain percentage
    zoom_range = 0,           # Randomly zoom in/out of images by up to certain percentage
    horizontal_flip = True,   # Randomly flip images horizontally
    vertical_flip = False,    # Do not randomly flip images vertically
    fill_mode = 'nearest'     # Fill any newly created pixels with the nearest pixel value
)

# Data augmentation not applicable to validate and test set
validate_test_generator = ImageDataGenerator(rescale = 1./255)

# Set directories
train_dir = os.path.join(data_dir, 'train', attr)
validate_dir = os.path.join(data_dir, 'validate', attr)
test_dir = os.path.join(data_dir, 'test', attr)

# Set variables
target_size = (110, 75)
batch_size = 10

# Import and generate the image data for train set
train_set = train_generator.flow_from_directory(
    train_dir,
    target_size = target_size,
    color_mode = 'rgb',
    class_mode = 'categorical',
    batch_size = batch_size,
    shuffle = True,
    seed = 0
)

# Import and generate the image data for validate set
validate_set = validate_test_generator.flow_from_directory(
    validate_dir,
    target_size = target_size,
    color_mode = 'rgb',
    class_mode = 'categorical',
    batch_size = batch_size,
    shuffle = True,
    seed = 0
)

# Import and generate the image data for test set
test_set = validate_test_generator.flow_from_directory(
    test_dir,
    target_size = target_size,
    color_mode = 'rgb',
    class_mode = 'categorical',
    batch_size = batch_size,
    shuffle = True,
    seed = 0
)

# Save the label code to csv file
label_dict = train_set.class_indices

with open(label_path, 'w', newline = '') as csv_file:
    writer = csv.writer(csv_file)
    writer.writerow(['code', 'label'])

    for label, code in label_dict.items():
        writer.writerow([code, label])

# Get the classes for all sets
train_classes = train_set.num_classes
validate_classes = validate_set.num_classes
test_classes = test_set.num_classes

# Get the shape for all sets
train_shape = train_set.image_shape
validate_shape = validate_set.image_shape
test_shape = test_set.image_shape

# Print the classes and shape for all sets
print()
print(label_dict)
print()
print('train classes:', train_classes)
print('validate classes:', validate_classes)
print('test classes:', test_classes)
print()
print('train shape:', train_shape)
print('validate shape:', validate_shape)
print('test shape:', test_shape)

# Set variables
c1 = 16
c2 = 32
h1 = 64
activation = 'relu'

# Build model
model = Sequential()
model.add(Conv2D(c1, (3, 3), input_shape = train_shape,
                 padding = 'same', activation = activation))
model.add(Conv2D(c2, (3, 3), input_shape = train_shape,
                 padding = 'same', activation = activation))
model.add(MaxPooling2D((2, 2)))
model.add(Flatten())
model.add(Dense(h1, activation = activation))
model.add(Dense(train_classes, activation = 'softmax'))

# Compile the model
model.compile(optimizer = 'adam', loss = 'categorical_crossentropy', metrics = ['accuracy'])

# Show the model summary
model.summary(line_length = 80)

# Train the model
print('\nModel Training:')
history = model.fit(train_set, validation_data = validate_set, epochs = 10, verbose = 2)

Relevant log output
2023-05-09 01:04:47.558215: I tensorflow/core/common_runtime/executor.cc:1210] [/device:CPU:0] (DEBUG INFO) Executor start aborting (this does not indicate an error and you can ignore this message): INVALID_ARGUMENT: You must feed a value for placeholder tensor 'Placeholder/_0' with dtype int32
	 [[{{node Placeholder/_0}}]]

@TP066335,
I was facing a different error while executing the given code. Kindly find the gist of it here and provide complete dependencies to analyse the issue and complete error as well.
Also if you are trying to execute the code on multi-gpu, Usually when you run the multi GPU distributed training in the eager mode, for each GPU it creates a new session and these sessions will not be synchronized since these are running in the eager mode and executes immediately.
Even though tf.distribute.Srategy works well with both eager and tf.function, it works best with tf.function and eager mode is recommended for debug mode.

I was getting same error on my single GPU also while trying model.fit(). However it worked perfectly on my cpu and google collab GPU. Not really sure why I was getting that error.

Hi @tilakrayal ,
I check your gist, actually you can remove that code because Google Colab needs to install scikeras separately. My issue is not with Google Colab, it is related to WSL in my own machine.
Besides, I'm using single gpu, not multi-gpu.
Steps:

I setup my GPU for tensorflow according to this video, you may refer to this video for all my dependecies. https://www.youtube.com/watch?v=KinTNHO-6IY
You may get the complete error from my attached IPNYB file.
I also attached a small dataset for your debugging.

data.zip
Hi @eimiss, yes, I'm having the same problem as yours.

Hi @tilakrayal,
Fyi, you may use my IPNYB file (data.zip) for debugging because I had simplified the codes to help your debugging.

@TP066335,
I request you to take a look at this issue and comment from the developer where users are facing similar error and the issue is still open.Also I request to follow the similar issue which has been proposed to have the updates on the similar issue.Thank you!

@tilakrayal,
If you read their error message, you will notice their case is different from mine case. Besides, they are not using GPU.
Please ignore the rest of the alerts in my IPNYB file, because those aleart messages are common when using GPU.
The only problem is the last error message which stop my training.
2023-05-09 01:04:47.558215: I tensorflow/core/common_runtime/executor.cc:1210] [/device:CPU:0] (DEBUG INFO) Executor start aborting (this does not indicate an error and you can ignore this message): INVALID_ARGUMENT: You must feed a value for placeholder tensor 'Placeholder/_0' with dtype int32
[[{{node Placeholder/_0}}]]
Please take not that I have no issue running the same code using my CPU in windows environment, the error message prompted when I'm using GPU to train the model in WSL environment.
Below is the statemetn from Tensorflow. In other words, we have no choice but to use WSL in order to use GPU.
Starting with TensorFlow 2.11, you will need to install TensorFlow in WSL2.
If you follow the same stesps to setup WSL, most like you will get the same error when running my Python code in WSL environment.
https://www.tensorflow.org/install/pip#windows-wsl2

Yeah I also fixed it, thanks.

@eimiss,
It would be greatly appreciated if you could share with me the steps on how to fix the issue.

I uninstalled everything and followed this guide:
https://www.youtube.com/watch?v=ttxtV966jyQ
then I isntalled tensorflow as it's shown in the tensorflow page

Thanks @eimiss.
The method to uninstalled everything not feasible for my machine.
Maybe I will wait for @tilakrayal for solution on WSL.

Hi @SuryanarayanaY,
Thank you so much for your kind attention to this issue.
Please find the attached screenshot as per requested.
Doc1.docx

Hi. I am having the same issue as @TP066335. I get the same result running model.fit() as shown in the screenshot. I also followed the same instructions from tensorflow.org about how to install for Windows WSL2.
I am submitting screenshots since my GPU and drivers are not quite the same. It appears to be a problem with running a GPU under WSL2.

Hope this helps. Thank you for your attention to this. I look forward to running TensorFlow on this GPU.

Hi @TP066335 ,
Could you please try to import keras  as a backend to Tensorflow .
import tensorflow as tf
from tensorflow import keras
from tensorflow.keras import layers

Let us know the outcome. Thanks!

Hi @sachinprasadhs ,
Thank you so much for your kind assistance, I really appreciate it.
It appears that the issue is still stuck at the model.fit() step.
I have attached the ipynb file for yor reference.
Thank you.
GPU.zip

Hi @TP066335 Are you still stuck. Search "WSL libcuda is not a symbolic link"

Hi @forthmedia,
Thanks for the suggestion.
I follow the instructions from this link  with regards to "WSL libcuda is not a symbolic link". I replaced the libcuda.so and libcuda.so.1 from C:\Windows\System32\lxss\lib.
I'm pleased to share that I've made significant progress, as I am now able to execute the model.fit() function. However, an unfortunate challenge remains - the GPU is not being utilized during the process, as depicted in the attached screenshot.
In conclusion, I am still unable to leverage the GPU for efficient model training.
Thank you.
GPU Screenshot.zip

Hello All,
I have successfully resolved the issue by following the comprehensive steps provided by KGP Talkie in their tutorial on YouTube, which was posted two weeks ago.
Additionally, to enhance the solution, I executed the command "conda install -c conda-forge cudatoolkit=11.2 cudnn=8.1.0". As a result, my CNN training can run perfectly within the WSL environment.
Last but not least, thanks a lot for your kind assistance and support.


ScrollView's onScrollKeyDown doesn't fire in template

Environment

react-native -v:
npm ls react-native-macos<EMAIL_ADDRESS>node -v:
npm -v:
yarn --version:
xcodebuild -version:

Issue
In the RNTester app you can use the up and down arrows to navigate between items in a SectionList. In Messenger Desktop's SectionList selecting an element in a ScrollView and then using the up and down arrows doesn't select next items.
Tracking through the code the up and down arrow keys are handled with onScrollKeyDown on ScrollView. This isn't firing in Messenger Desktop, and appears to not be firing in a new template app either.
I set a breakpoint in this code:
https://github.com/microsoft/react-native-macos/blob/9232ace99d095a793bddf00ffda3238cc7078820/React/Views/ScrollView/RCTScrollView.m#L1418-L1422
In RNTester, up/down go into the if statement. In the new app template the call goes into the else.

From the new app:
(lldb) po [[self window] firstResponder]
<RCTView: 0x10383a790; reactTag: 97; frame = {{24, 1}, {432, 90.000999450683594}}; layer = <_NSViewBackingLayer: 0x600000cfe790>>

(lldb) po self
<RCTScrollView: 0x10184ea00; reactTag: 213; frame = {{0, 0}, {480, 270}}; layer = <_NSViewBackingLayer: 0x600000d0cfc0>>

From RNTester:
(lldb) po [[self window] firstResponder]
<RCTScrollView: 0x102022a00; reactTag: 319; frame = {{0, 55}, {769, 539}}; layer = <_NSViewBackingLayer: 0x600000cbc570>>

(lldb) po self
<RCTScrollView: 0x102022a00; reactTag: 319; frame = {{0, 55}, {769, 539}}; layer = <_NSViewBackingLayer: 0x600000cbc570>>

So the issue is that self == [[self window] firstResponder] is false in the new app but true in RNTester. I'm not sure yet why the scrollview isn't the firstResponder in the new app.
Steps to Reproduce

Add console.log to _handleKeyDown in ScrollView.js
Open the new app screen
Hit down, expect the callback to be called.

Hi @TheSavior.   The onScrollKeyDown event was added for the special case of Lists.   The SectionList in RNTester resembles a native NSOutlineView, NSTableView, or NSContainerView so we made it behave like one.  Such native lists are themselves first responders but the items in these views are typically not first responders.
In the case of RNTester the SectionList can become first responder and is a stop in the key loop.   The items in the list are not first responders and individually are not part of the key loop.   While the List is first responder self == [[self window] firstResponder] and onScrollKeyDown events fire as you observed.   The RNTester app logic interprets these events as "change the selected row in the list" which it does.
In the template app, the <ScrollView> contains stuff including the <LearnMoreLinks> component that renders a bunch of <TouchableOpacity/> items which by default can be first responder.   So when one of the links is first responder [[self window] firstResponder] is returning that RCTView and the parent <ScrollView> does not fire onScrollKeyDown events.    I can force the template app's <ScrollView> to be first responder by modifying LearnMoreLinks.js and adding acceptsKeyboardFocus={false} to the <TouchableOpacity>.
As I said, the onScrollKeyDown was made especially for this List scenario and is the reason i named it onScrollKeyDown instead of something generic like onKeyDown.   If/when we add a generic onKeyDown we could make it bubble up and fire without the first responder condition.

Thanks for the explanation, that is consistent with my understanding as well.
The issue we are having in Messenger is that we have a SectionList with items that are TouchableWithoutFeedback. Tab will go through each element in the section list (which it sounds like it shouldn't from your description). The up and down arrow keys don't do anything.
I was debugging and got into the scroll view handler which was having a similar behavior as the template app which is why I used that as my minimal repro. Perhaps I need a different minimal repro.

On SectionList you have to add:
acceptsKeyboardFocus={true}
enableSelectionOnKeyPress={true}
And on TouchableWithoutFeedback items add
acceptsKeyboardFocus={false}

Ah, I got those on sectionlist but didn’t put that prop on the touchable. Okay, I’ll give that a try. I’ll close this out. Thanks for the guidance. It would be great to have some kind of documentation on the Windows / Mac website with this info.

Yay, that helped!
It looks like every time I hit enter on an item and then use up and down again it starts over from the top of the list. I'd expect it would continue from the selected item in the list. Is there something else I'm missing?


type of 'Microsoft.Storage/storageAccounts/fileServices/shares' not recognized

Hello -
I wanted to report that the above listed 'type' isn't recognized by this plugin.  Neither is the simpler version of 'Microsoft.Storage/storageAccounts/fileServices'.
If I run my ARM template using fileServices or fileServices/shares to create my share, it does work fine so I know there isn't a mistake there.
Just wanted to pass this along.
Charles

Thanks for letting us know!  We're currently working on this and related issues.

This is a schema issue and was reported here: https://github.com/Azure/azure-resource-manager-schemas/issues/793


no details about virtual table permisisons

It appears users of apps with virtual tables require additional permissions but these are not documented in the page.
IT would save a massive amount of troubleshooting time to include information on necessary permissions for using virtual tables.

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 42ae2cb6-ce2a-21c7-cb81-b60e7b026753
Version Independent ID: 5a3cb7c0-6881-1d96-0dc3-639324a4568c
Content: Get started with virtual tables (entities) (Microsoft Dataverse) - Power Apps
Content Source: powerapps-docs/developer/data-platform/virtual-entities/get-started-ve.md
Service: powerapps
Sub-service: dataverse-developer
GitHub Login: @NHelgren
Microsoft Alias: nhelgren

Thanks for your comment, @FintanGuihen. This issue has been assigned to the doc author for review.

@FintanGuihen
Thanks for your feedback.
This article is within our content for developers and focuses on how developers can create their own data providers.
Did you find this more general article Create and edit virtual tables that contain data from an external data source?
I think your question applies to virtual tables in general, and the other topic would be the place where the information you are looking for should be found. Do you feel this information should be presented only for developers?

@FintanGuihen Closing this issue. If you still have questions, open a new issue.


Identify and address issues with VCP documentation on StorageHub

https://storagehub.vmware.com/#!/vsphere-storage/kubernetes-vsphere-cloud-provider
If there are none then we can close this issue.

Links on the https://storagehub.vmware.com/#!/vsphere-storage/kubernetes-vsphere-cloud-provider/faqs needs to be fixed.
The disk.EnableUUID parameter must be set to “TRUE” for each Node VM. Please refer this section. Link on the section is broken.

Tushar will take care of this along with other VCP documentation issues on StorageHub.


Modify code type to shell

Modify code type to shell

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

Thank you