Error: spawn nx ENOENT

Overall the plugin-seed is working great.
However, I cannot publish the emoji-picker package, instead, the following error appears:
A:\_Source\nativescript-emoji-picker>npm run publish-packages

><EMAIL_ADDRESS>publish-packages A:\_Source\nativescript-emoji-picker
> nx g @nativescript/plugin-tools:publish

? Which packages � would you like to publish? [Type single name, comma separated list or hit enter for all]
? What � version would you like to publish? [Type specific version or hit enter to auto bump the patch version]
? Sanity check � Are you sure you have tested your local changes and want to publish? Yes

�  @schoolsquirrel/emoji-picker -- current: 1.0.0 > ⬆ bumping to: 1.0.1
build emitted error: Error: spawn nx ENOENT
    at Process.ChildProcess._handle.onexit (internal/child_process.js:267:19)
    at onErrorNT (internal/child_process.js:469:16)
    at processTicksAndRejections (internal/process/task_queues.js:84:21) {
  errno: 'ENOENT',
  code: 'ENOENT',
  syscall: 'spawn nx',
  path: 'nx',
  spawnargs: [ 'run', 'emoji-picker:build.all' ]
}
✅ Successfully built @schoolsquirrel/emoji-picker:1.0.1
build finished with code: -4058
spawn nx ENOENT
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR<EMAIL_ADDRESS>publish-packages: `nx g @nativescript/plugin-tools:publish`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>publish-packages script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR!      A:\npm-cache\_logs\2020-09-19T11_52_51_551Z-debug.log

You can have a look at my workspace for reference: https://github.com/SchoolSquirrel/nativescript-plugins . Just run npm run publish-packages, type in emoji-picker and hit Enter twice.
The debug log looks like this:
0 info it worked if it ends with ok
1 verbose cli [
1 verbose cli   'C:\\Program Files\\nodejs\\node.exe',
1 verbose cli   'C:\\Users\\Hannes\\AppData\\Roaming\\npm\\node_modules\\npm\\bin\\npm-cli.js',
1 verbose cli   'run',
1 verbose cli   'publish-packages'
1 verbose cli ]
2 info using<EMAIL_ADDRESS>3 info using<EMAIL_ADDRESS>4 verbose run-script [ 'prepublish-packages', 'publish-packages', 'postpublish-packages' ]
5 info lifecycle<EMAIL_ADDRESS><EMAIL_ADDRESS>6 info lifecycle<EMAIL_ADDRESS><EMAIL_ADDRESS>7 verbose lifecycle<EMAIL_ADDRESS>unsafe-perm in lifecycle true
8 verbose lifecycle<EMAIL_ADDRESS>PATH: C:\Users\Hannes\AppData\Roaming\npm\node_modules\npm\node_modules\npm-lifecycle\node-gyp-bin;A:\_Source\nativescript-emoji-picker\node_modules\.bin;C:\Python27;C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64_win\compiler;C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64_win\compiler;C:\Program Files (x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;C:\Windows\System32;C:\Windows;C:\Windows\System32\wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files (x86)\QuickTime\QTSystem\;C:\Qt\5.10.1\5.10.1\Src\qtbase\bin;C:\xampp\php;C:\Windows\System32\OpenSSH\;C:\Program Files (x86)\IVI Foundation\VISA\WinNT\Bin;C:\Program Files (x86)\GtkSharp\2.12\bin;C:\ffmpeg\bin;C:\Program Files\wkhtmltopdf\bin;C:\Program Files\Adobe\Adobe Photoshop CC 2017;C:\Users\Hannes\AppData\Local\Android\Sdk;C:\Program Files (x86)\Java\jre1.8.0_181\bin;C:\Program Files\Java\jdk1.8.0_191\bin;C:\Users\Hannes\AppData\Local\Android\Sdk\platform-tools;C:\ProgramData\chocolatey\bin;C:\Program Files\AdoptOpenJDK\jdk8u192-b12\bin;C:\Program Files\Java\jdk1.8.0_211\bin;C:\Users\Hannes\AppData\Local\Android\Sdk\tools;C:\Program Files\Microsoft Network Monitor 3\;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\dotnet\;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;C:\Windows\System32;C:\Windows;C:\Windows\System32\wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files (x86)\GnuPG\bin;C:\Program Files\PuTTY\;E:\Virtualbox;E:\Docker Toolbox;C:\Program Files\OpenSSL-Win64\bin;C:\Program Files (x86)\GnuWin32\bin;C:\Program Files\nodejs\;C:\Users\Hannes\AppData\Local\Programs\Python\Python38\Scripts;C:\Users\Hannes\AppData\Local\Programs\Python\Python38\Scripts\;C:\Users\Hannes\AppData\Local\Programs\Python\Python38\;C:\Users\Hannes\AppData\Local\Microsoft\WindowsApps;C:\Users\Hannes\AppData\Local\ComposerSetup\bin;C:\Users\Hannes\AppData\Roaming\Composer\vendor\bin;C:\Users\Hannes\AppData\Local\Programs\Git\cmd;C:\Users\Hannes\go\bin;C:\Users\Hannes\AppData\Local\Programs\Microsoft VS Code\bin;C:\Users\Hannes\AppData\Local\Microsoft\WindowsApps;C:\Users\Hannes\AppData\Roaming\npm;C:\Program Files (x86)\GitHub CLI\
9 verbose lifecycle<EMAIL_ADDRESS>CWD: A:\_Source\nativescript-emoji-picker
10 silly lifecycle<EMAIL_ADDRESS>Args: [ '/d /s /c', 'nx g @nativescript/plugin-tools:publish' ]
11 silly lifecycle<EMAIL_ADDRESS>Returned: code: 1  signal: null
12 info lifecycle<EMAIL_ADDRESS>Failed to exec publish-packages script
13 verbose stack Error<EMAIL_ADDRESS>publish-packages: `nx g @nativescript/plugin-tools:publish`
13 verbose stack Exit status 1
13 verbose stack     at EventEmitter.<anonymous> (C:\Users\Hannes\AppData\Roaming\npm\node_modules\npm\node_modules\npm-lifecycle\index.js:332:16)
13 verbose stack     at EventEmitter.emit (events.js:315:20)
13 verbose stack     at ChildProcess.<anonymous> (C:\Users\Hannes\AppData\Roaming\npm\node_modules\npm\node_modules\npm-lifecycle\lib\spawn.js:55:14)
13 verbose stack     at ChildProcess.emit (events.js:315:20)
13 verbose stack     at maybeClose (internal/child_process.js:1021:16)
13 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:286:5)
14 verbose pkgid<EMAIL_ADDRESS>15 verbose cwd A:\_Source\nativescript-emoji-picker
16 verbose Windows_NT 10.0.19041
17 verbose argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Users\\Hannes\\AppData\\Roaming\\npm\\node_modules\\npm\\bin\\npm-cli.js" "run" "publish-packages"
18 verbose node v12.18.2
19 verbose npm  v6.14.6
20 error code ELIFECYCLE
21 error errno 1
22 error<EMAIL_ADDRESS>publish-packages: `nx g @nativescript/plugin-tools:publish`
22 error Exit status 1
23 error Failed at the<EMAIL_ADDRESS>publish-packages script.
23 error This is probably not a problem with npm. There is likely additional logging output above.
24 verbose exit [ 1, true ]

As you can see, I'm using Windows 10. I also tried installing nx globally but this didn't change anything.

@NathanWalker any idea? Sorry for another ping, but this is really preventing me from publishing my plugin...

@hrueger thanks for this - appears could be a Windows difference with the node spawn handling. No worries though I'll look into that but here's what you can always do (the publish workflow is just a nicety but you can always do it directly):

npm start > build your plugin via it's command listed
cd dist/packages/{your-package} and then you can simply publish: npm publish --access public

The --access public flag is only needed when publishing a brand new package to npm. It can be omitted in subsequent versions.

@NathanWalker Thank you, publishing the package manually worked perfectly.

‘npm run publish-packages’ has been fixed for this case in latest version of the tools. As long as using a tilda ‘~’ on the tools version in your plugin workspace, will pick them up when running a ‘npm run setup’ to clean your workspace again.

@NathanWalker Thanks, but it's still not working, I get the same error. I have "@nativescript/plugin-tools": "~1.0.6", in my package.json and ran npm run setup. I also tried removing the whole project folder and cloning it again but it's still not working.

Ok thanks - let's reopen and if any Windows users out there can post a PR would be appreciated - probably path separator needs another adjustment.

@hrueger posted you PR which I believe will fix it for you. Could you merge and give a build on your Windows setup?
If this confirmed works I'll add a migration to update for other workspaces whom experience similar issue on Windows.
https://github.com/SchoolSquirrel/nativescript-plugins/pull/47

Sounds like that may not totally fix it for you - this is related to https://github.com/NativeScript/plugin-seed/issues/8 where some similar investigations are occurring from that reporter as well.

@NathanWalker Sorry for the late reply. Unfortunately, your PR doesn't change anything. I still get the same error message.

@hrueger a contributor just helped find the cause on Windows and Pr'd the fix. For you workspace just open workspace.json and find the "all" project and update "root" to have a trailing slash:
before:
"all": {
  "root": "packages",

after:
"all": {
  "root": "packages/",

I went ahead and pushed up to existing pr to include that final fix as well:
https://github.com/SchoolSquirrel/nativescript-plugins/pull/47

@NathanWalker thanks, I'll test and merge it tomorrow.

@NathanWalker https://github.com/SchoolSquirrel/nativescript-plugins/pull/47 did solve the build problem, but not this issue.
However, I have found a solution: According to this StackOverflow answer it is caused by some missing extension. Adding shell: true to the options of the spawn calls solves it for me.
I created a PR: https://github.com/NativeScript/plugin-tools/pull/1


Fixes deprecation for passing null in registry constructor

Fixes https://github.com/jschaedl/iban-validation/issues/75

It seems like there is some downtime at GitHub, which results in the Github Actions status checks not beeing started.
I hope you can start them when github is back online, because i don't see the option to do so

Closing in favour of https://github.com/jschaedl/iban-validation/pull/77


Repeated running of simpixel sometimes results in that port being permanently in use

If I do a lot of starting and stopping, I eventually run into this issue.
No other bp instances appear to be running, but I get this error:
Cached server 1337 on your machine is already in use.
Perhaps BiblioPixel is already running on your machine?

Even extreme measures like killall bp and killall python have no effect on this state.  Various forms of ps show nothing interesting, but netstat -anb does - the relevant parts are pasted below.
Eventually I have to reboot.
Any ideas?  This is beyond me...
Active Internet connections (including servers)
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)        rxbytes    txbytes
tcp4     542      0  <IP_ADDRESS>.1337         <IP_ADDRESS>.51406        CLOSE_WAIT         646          0
tcp4       0      0  <IP_ADDRESS>.51406        <IP_ADDRESS>.1337         FIN_WAIT_2           0        320
tcp4     542      0  <IP_ADDRESS>.1337         <IP_ADDRESS>.51404        CLOSE_WAIT         646          0
tcp4       0      0  <IP_ADDRESS>.51404        <IP_ADDRESS>.1337         FIN_WAIT_2           0        320
tcp4     542      0  <IP_ADDRESS>.1337         <IP_ADDRESS>.51402        CLOSE_WAIT         646          0
tcp4       0      0  <IP_ADDRESS>.51402        <IP_ADDRESS>.1337         FIN_WAIT_2           0        320
tcp4       0      0  <IP_ADDRESS>.51389   <IP_ADDRESS>.443     ESTABLISHED       1220       3341
tcp4     542      0  <IP_ADDRESS>.1337         <IP_ADDRESS>.51367        CLOSE_WAIT         646          0
tcp4       0      0  <IP_ADDRESS>.51367        <IP_ADDRESS>.1337         FIN_WAIT_2           0        440
tcp4     542      0  <IP_ADDRESS>.1337         <IP_ADDRESS>.51365        CLOSE_WAIT         646          0
tcp4       0      0  <IP_ADDRESS>.51365        <IP_ADDRESS>.1337         FIN_WAIT_2           0        440
tcp4       0      0  *.1337                 *.*                    LISTEN               0          0

That's pretty much a known thing with *nix systems. I've never found a way around it. If you don't give it time to cleanup it will eventually be unrecoverable.
One thing you could try is this:
sudo lsof -t -i tcp:1337 | xargs kill -9
or on regular linux (above for OS X)
sudo fuser -k 1337/tcp

All right!
I'm going to leave this open still until I get it into the documentation.

I can make it happen pretty well every time by running the release_tests and interrupting it during the MIDI test.
It's something to do with running bp as a subprocess.  I'll look into this further, it's sort of annoying when testing.


Fix site clone-env and site wipe when using interactive args

Noticed that when in interactive mode, these commands were not getting the interactively-set values.

@benbunk getValidEnvSite was actually ready for deprecation, so I just piggy-backed on this PR. Cool?


Cannot update textStyle in tooltip with formatter

Hi! I'm trying to customize tooltip in series with type: 'custom' using formatted function, but I'm not able to change styles of text
    type: 'custom',
    data: [7000],
    tooltip: {
      formatter: (params: CallbackDataParams) => {
        return `Data: ${params.data}`;
      },
      textStyle: {
        fontSize: 20,
      },
    },

The result:

Yes, this is a problem. tooltip in echarts uses html instead of svg, and html is not currently supported in wrn-echarts.
Alternatively, you can select svg rendering in the chart editor in echarts and locate if htm is used by the browser's review element.
We are also in the process of sorting out the relevant currently unsupported features.

is it possible to support this?

we will try it.

custom tooltip in echarts uses html instead of svg, and html is not currently supported in wrn-echarts.

This sentence is misrepresented

https://github.com/apache/echarts/issues/18339
It may be an issue of echarts.


Update the Azure Storage Emulator

I do according to the instructions, point Update the Azure Storage Emulator.
The following error occurs when executing the command:
C: \ Program Files (x86) \ Microsoft SDKs \ Azure \ Storage Emulator> AzureStorageEmulator.exe init -server unname
Windows Azure Storage Emulator <IP_ADDRESS> command line tool
Error: User-specified instance not found. Please correct this and re-run initialization.
tried another way
The error remains the same:
C: \ Program Files (x86) \ Microsoft SDKs \ Azure \ Storage Emulator> AzureStorageEmulator.exe init -sqlinstance "MSSQLSERVER"
Windows Azure Storage Emulator <IP_ADDRESS> command line tool
Error: User-specified instance not found. Please correct this and re-run initialization.

In all cases, the command line was run as administrator

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

ID: d830cc4d-4375-3d2a-65d2-5427d1e8acdd
Version Independent ID: cab504a7-d2d4-8722-5dd1-71ff1c39d04e
Content: Rename a local development (VHD) environment - Finance & Operations | Dynamics 365
Content Source: articles/fin-ops-core/dev-itpro/migration-upgrade/vso-machine-renaming.md
Service: dynamics-ax-platform
Product: ****
Technology: ****
GitHub Login: @MargoC
Microsoft Alias: tabell

@sinner83, thanks for contacting us. Unfortunately, we're unable to handle Support requests for the product here. To contact Support, consider one of the options described here: Support contact options. In particular, you might want to go to the Dynamics 365 community page to get help with your questions from the Dynamics community.
@tariqbell, please review.

Ok. Thank's for help.


uid2-794 invite team member

Required step

Re-import realm-export.json using scripts (This will recreate the realm)
or
manually assign manage-users, query-users and view-users to self_serve_portal_apis

Regenerate the secret for self-serve-portal-apis

Replace the secret in .env

Will regenerating the secret be required for everyone? It probably needs more than just a PR comment. Maybe something in readme?

The dialog closes if you click anywhere outside it - that would be really frustrating if someone was halfway through! e.g. they might be copy-pasting the name or email from another program, and if they click on the wrong place they lose all progress.


Proposal: Defining "JavaScript classes" in Scala.js

This has been the Achilles' heel of Scala.js: how to define, in Scala.js, a class inheriting from a JavaScript class. This essentially means defining a "JavaScript class" (extending js.Object or some other raw JS class) from Scala.js.
I have been thinking this through for about 2 years (!), and have finally, I think, come up with appropriate semantics for such a language feature. This proposal lays down an enhancement proposal for Scala.js that specifies all this.
The problem
I have a JavaScript class Foo, defined as follows (ES6 syntax):
class Foo {
  constructor(x, y) {
    this.x = x;
    this.y = y;
  }
  print() {
    console.log(`(${x},${y})`)
  }
}

A potential facade for this class could be:
class Foo(val x: Int, val y: Int) extends js.Object {
  def print(): Unit = js.native
}

I want to extend this class from a class Bar defined in Scala.js, to add a third value, and override the print method to also display the third value. (Please forgive me the contrived example which is even likely not to respect the LSP.) If I were to define it in JavaScript, I would write:
class Bar extends Foo {
  constructor(x, y, z) {
    super(x, y);
    this.z = z;
  }
  print() {
    console.log(`(${x},${y},${z})`)
  }
}

Ideally, I want to write something close to this:
class Bar(x: Int, y: Int, val z: Int) extends Foo(x, y) {
  override def print(): Unit =
    println((x, y, z))
}

Class notation
A class which extends js.Any and has the annotation js.annotation.JSScalaDefined is not a facade type, but a Scala.js-defined JavaScript class:
@JSScalaDefined
class Bar extends js.Object

Note: @JSScalaDefined is awkward. In the future, we might want to invert the meanings: no annotation means Scala.js-defined; and @js.native means facade. See later for details about that.
The type Bar is still a raw JS type, so accesses to members of that type are always done "the JS way" (no mangling of member names).
The declaration of this class does not define a "constructor function" accessible from JavaScript. The constructors of a Scala.js-defined JS class are only visible to Scala.js code.
@JSExport can be used to export constructors to JavaScript code, just like Scala.js Scala classes.
Rationale: these classes can be dead-code-eliminated if they are not instantiated. It also plays well with anonymous and nested such classes.
Method declaration
A Scala.js-defined JS class can define methods. All public and protected methods are always "exported" to JS with semantics close to @JSExport for methods in Scala classes.
@JSScalaDefined
class Bar extends js.Object {
  def foobar(a: Int, b: String): String =
    a.toString + b
}

Formally, parameters and result type are always erased/boxed in the visible type (like in exports).
Overloading is possible, and is resolved almost like @JSExport. Unlike exports, the runtime overloading logic will call the variants with static dispatch. To be clear, instead of calling this.foobar__I__T(a, b), it will call Bar.prototype.foobar__I__T.call(this, a, b). This is necessary for super calls coming from sublasses of Bar to deal correctly with combinations of overloading and overriding.
This also means that, when overriding an overloaded method, the runtime overloading logic must be reemitted, even if the set of alternatives does not change (contrary to how exports handle this).
References to this
References to members of this in the body of the methods (implicitly or explicitly) are dealt with just like any other raw JS type, which means that runtime overloading is always used, at the end of the day. This is necessary to have consistent behavior between this.foo(5) and { val self = this; self.foo(5) }.
Getter and setter declaration
Like in exports, a def without parentheses is visible as a getter in JavaScript. A def whose Scala name ends in _= is visible as a setter in JavaScript.
Field declaration
Unlike in exports, vals and vars are not implemented with getters and setters. They become direct fields of the object. This is necessary to have meaningful overriding of a field inherited from a parent class.
A val that implements or overrides an inherited def without parentheses will have the appropriate semantics as soon as the field exists on the object (since it will be seen before a getter/setter inherited from the prototype). However, when creating the field in the first place, we must bypass a potentially inherited getter/setter. We can do this with Object.defineProperty.
(This might not play well with strong mode, though. But we probably don't want Scala.js-defined JS classes to have strong mode semantics anyway.)
Compared to how this would work in Scala classes, this has surprisingly few caveats. The only semantic discrepancy I can foresee happens for val x: Int = 3, then override val x: Int = 5: after the superclass has initialized x and before the subclass has initialized x, on the JVM x would be seen as 0. On JS it would be seen as 3. But anyway reading x in that interval is probably a bug in the first place.
The Scala specification prevents to override a val or a val with getter/setter defs. This also reflects the JS limitation that "overriding" a field with getter/setters does not really work as expected (because getter/setters are on the prototype, which is checked after the object itself).
@JSName
It is of course invalid to @JSExport or @JSExportAll members of a Scala.js-defined JS class. It is however possible to use @JSName to change the name visible in JavaScript, just like for any raw JS type.
Private members
Private members are mangled in a way that, hopefully, will not clash with any JavaScript identifier. In ES6, we can use unique Symbols for that.
Open question: should overloading in private methods use compile-time dispatch or runtime-dispatch?
Backwards compatibility
As presented above, this is fully backwards source compatible with the current semantics of Scala.js. It can also probably be made backwards binary compatible.
Breaking backwards compatibility
As noted above, the @JSScalaDefined annotation is very awkward. In the future, I would like that @JSScalaDefined be the default. To get a facade type, one would need to annotate the class with @js.native.
The migration path would be:

In 0.6.x: have @JSScalaDefined and @js.native. A class with neither of those will be reported as a warning, saying @js.native should be added to future-proof it.
In the next major release: classes without the annotation would be Scala.js-defined. @JSScalaDefined becomes deprecated, and should be removed.

(Anonymous) nested classes
It is possible and valid to have Scala.js-defined JS classes nested in other classes (unlike facade types). In that case, it is not valid to @JSExport its constructors (unless @JSExport of nested classes is revived, see #354).
Since anonymous classes cannot have annotations, with the current state it is in fact not possible to declare an anonymous Scala.js-defined JS class, because it needs @JSScalaDefined. To overcome this, and since anonymous facades are invalid anyway and cause compile errors at the moment, an anonymous class inheriting from js.Any is automatically a Scala.js-defined JS class.
Extend a Scala.js-defined JS class from JavaScript
To close the circle, we would possibly want to be able to extend a Scala.js-defined JS class from a JavaScript-defined class. This is not an immediate requirement, but we should keep this use case in mind when devising the implementation.
Implementation concerns
A Scala.js-defined JS class would be a new ClassKind of ClassDef in the IR. It would be a raw JS type, but with member definitions.
All public and protected fields end up having String names, since they must be visible in JS. For methods, we probably want to emit private implementations of all methods, with static types and overloads, and have one dispatch and box/unbox bridge with a string name (thus similar to exports, except that the implementations are private).
The creation of the fields poses certain difficulties. They must be created (possibly with zeros) during the JS constructor executes, for performance reasons. As a first approximation, we can mimic the constructor architecture of Scala.js Scala classes (constructor creates the field + init method for the body). But this might become problematic if we want to extend such a class from JavaScript.
Open questions: traits and abstract members
Until now, I have carefully avoided discussing traits and abstract members.
Abstract members are currently forbidden in facade JS classes. They should be allowed, so that they can be forcefully implemented in Scala.js-defined JS classes inheriting from such facades.
In facades, members in traits are non-abstract and js.native, for convenience (so we don't have to repeat their definition in classes implemented these traits). This will not play well with Scala.js-defined JS classes inherited from raw JS traits. We should probably deprecate this pattern, and require that raw JS traits always be pure interfaces, with only abstract members; and, when compiling a Scala.js-defined JS class, check that no method is a bridge to (non-existing) impl class of a raw JS trait. There would be no way to declare "Scala.js-defined JS traits", so mixin composition is not available when writing Scala.js-defined JS classes. We should keep an eye out for mixins in upcoming ES, and make sure we can play well with those in the future.

Comments welcome!
Ready, set, go!

'@JSScalaDefined is awkward' Agreed, maybe a better name can be thought of? Even though it's seems to be a band-aid and switching facades over to requiring js.native seems the right path for consistency, it's still kind of ugly.
@JSExport can be used to export constructors to JavaScript code Does this just mean if that annotation is applied to the class then the constructor method is emitted? It seems that way just want to double check.

maybe a better name can be thought of?

Sure. Suggestions welcome. @JSScalaDefined was the least bad I found myself ^^

Does this just mean if that annotation is applied to the class then the constructor method is emitted?

It means exactly the same thing as @JSExport on a Scala.js Scala class: a JavaScript constructor is exposed in the exports namespace (typically the global scope) which allows to do new Stuff(a, b) from JS, and have that create an instance of that class.

Are references to super allowed? (how would you do that reliably in JS?)

Yes, with precisely the same mechanism that we use for super calls in scala classes, i.e., SuperClass.prototype.method.call(this, arg1, arg2)

Another thing: Will Scala.js leak members on these classes or are these safe to use in iteration (and such)?

much awaited feature for me  :+1:

There would be no way to declare "Scala.js-defined JS traits", so mixin composition is not available when writing Scala.js-defined JS classes. We should keep an eye out for mixins in upcoming ES, and make sure we can play well with those in the future.

does this mean
class Foo(val x: Int, val y: Int) extends js.Object {
  def print(): Unit = js.native
}
trait CommonCode {
 def common() = println("common")
}
class Bar extends Foo with CommonCode // not allowed ?

or its related to traits that extends js.Any ... ?

Will Scala.js leak members on these classes or are these safe to use in iteration (and such)?

For top-level classes, there will be no member other than the vals and vars declared explicitly in the code. So no there's no leak. Nested classes will have fields for captures, however.

@chandu0101 Your snippet is not valid for another reason: it is not possible for a class to extend both js.Any and something that does not itself extend js.Any. This is an existing restriction, which will be maintained.

@chandu0101 Your snippet is not valid for another reason: it is not possible for a class to extend both js.Any and something that does not itself extend js.Any. This is an existing restriction, which will be maintained.

oh ok :(

For top-level classes, there will be no member other than the vals and vars declared explicitly in the code. So no there's no leak. Nested classes will have fields for captures, however.

OK. But we will leak Scala.js specific members on the prototype I assume. Is there a way we can make these invisible? I'm thinking of something like defining them statically in a block which is private to the class definition and then calling them. This of course would come at the cost of having to do dynamic dispatch again when invoking a super call (now that I think of it, we might have to do this anyway for the semantics to be correct when invoking super).
Something like this:
var myCtor = function() {
  this.a = 1;
  this.b = 2;
};

(function() {
  var foo__I = function() { return 1; };
  var foo__I__I = function(i) { return i * 2; };
  myCtor.prototype.foo = function(i) {
    if (i == (void 0)) return foo__I.call(this);
    else return foo__I__I.call(this, i);
  };
})();

About visibility:

I think protected should be entirely disallowed. It does not make sense
What is the relationship with companions? (matters how we implement private methods)

I think for private methods we have two choices:
Make them pure helpers

Compile-time dispatch
Companion cannot call them (!)

Make them "normal"

Runtime dispatch
Companion can call them

I prefer option one, since having private methods at all is IMO already a stretch (but a useful one). I think we should not give an illusion of private methods if we cannot actually implement it that way in JS (and with fully static dispatch we can, just define them in an enclosing scope, no one sees them).

OK. But we will leak Scala.js specific members on the prototype I assume. Is there a way we can make these invisible?

Yes, I plan to move all the methods not visible to JS to static methods. They don't need to be shadowed with special JS syntax. They will just be static methods with identifier names (not strings), that are therefore protected by the giant anonymous function providing Scala.js' scope. The IR checker will verify that a Scala.js-defined JS class does not have non-exported member methods. The linking pipeline is already equipped to deal with static methods in arbitrary ClassKinds (even hijacked classes ^^).

This of course would come at the cost of having to do dynamic dispatch again when invoking a super call (now that I think of it, we might have to do this anyway for the semantics to be correct when invoking super).

Yes, runtime overloading dispatch is necessary on every super call. We call the JS-visible method on the superclass every time. Super calls should not behave any differently based on whether the super class is a native JS class or a Scala.js-defined JS class, so there's no choice here.

I think protected should be entirely disallowed. It does not make sense

I makes sense if you want to protect your Scala.js code from accidentally accessing those methods (and prevent them from showing up in auto-completion), but you still want to override them in subclasses.

I think we should not give an illusion of private methods if we cannot actually implement it that way in JS

Technically, it is possible to implement completely private instance methods. They just have to have names generated at random at runtime (or, better, be unique symbols) and added on the prototype with a defineProperty that makes them non-enumerable.

I think for private methods we have two choices:

Actually, my current preference is a third choice:

Forbid overloading of private methods altogether (including wrt. non-private methods with the same name)
This means compile-time or run-time dispatch is irrelevant
This means they can be called from the companion object, which is nice (preventing it might make some patterns of code impractical to implement)

The restriction on overloading of private methods is easily worked around with more specific names. Since they are private, the workaround does not leak into the API of the object.
I don't really like using compile-time dispatch for private methods because that means they don't behave like non-private methods in the same class (gurg!). And I don't really like using run-time dispatch either, because they should be overhead-free to really be usable as helpers. So disabling dispatch altogether came to me as the solution to my dilemma ^^

I agree with all of this.
Protected: Allow, but no difference on JS side (consistent with semantics in @JSExport)
Private methods: Disallow overload, give companion access (w/o overhead). (Good luck to properly dispatch this in the backend :P, but we'll manage...)

About fields: Couldn't we restrict what you are allowed to put in fields (or change the initialization semantics) so that on the JS-side, we are able to emit a normal ctor?

(Btw. I leave it up to you, @sjrd, to update the description at the top as this discussion goes, it's probably bettern than both of us fiddling with it)

About fields: Couldn't we restrict what you are allowed to put in fields (or change the initialization semantics) so that on the JS-side, we are able to emit a normal ctor?

The only thing that prevents us from emitting a normal JS constructor are overloaded constructors. If we disallow overloaded constructors, this becomes easy, and we even easily export the class for subclassing by JS.

Hum, no, that's not entirely true. You are right. The constructor a superclass could call a method overridden in a subclass, which tries to read a field of the subclass. At that time, the field would not exist yet. This would result in an undefined -> undefined behavior.

I think that is actually a very reasonable behavior: Think of it: In a JVM style class, the field will be null in the same case (except for early initializers which we should fully disallow). So it is very sensible, that the field is undefined in a JS class.

The only thing that prevents us from emitting a normal JS constructor are overloaded constructors

I think it is very reasonable to say the primary ctor is what is getting exported and inherited from (even in Scala this is the case).
Secondary constructors must call the primary ctor in Scala, so doing the same in JS is easy (but one could not inherit from them). So maybe we should disallow exporting of secondary ctors or disallow secondary ctors alltogether and tell people to use factories instead.

By the way: The proposal does not state default parameter and vararg calling convention. I assume these are just like @JSExport.

By the way: The proposal does not state default parameter and vararg calling convention. I assume these are just like @JSExport.

Indeed.

I think it is very reasonable to say the primary ctor is what is getting exported and inherited from (even in Scala this is the case).

No, it's not the case in Scala: when extending a class with secondary constructors, your primary constructor can call any of the superclass' secondary constructors.
If the primary constructor becomes the JS constructor, and it happens to have at least one parameter, it is not possible to call correctly any secondary constructor (whether from new or from a subclass).
So even disallowing exporting secondary constructors is not a viable option, unfortunately.

Another solution that would solve those problems, instead of brutally disallowing any secondary constructors, is to allow them but use, again, run-time dispatch of the appropriate overload. This would also allow to extend from such a class from JS easily.
In cases where there is no secondary constructor, this behaves the same as the variant where we disallow secondary constructors.
In that case, either all or none of the constructors are exported. This might prevent to export any of the constructors if one of them is private, though ^^

I like the run-time dispatch for the ctors. It makes sense and is consistent with the rest.
I have only one very ugly solution to solve the private ctors (which we should have): Each class has a static field that says whether we are calling a private ctor... Based on that, the ctor behaves differently... Call-site emits switches to the method before calling ctor. Since field is private, private ctor cannot be called.

I like the run-time dispatch for the ctors. It makes sense and is consistent with the rest.

Yes, the more I think about it, the more I like it as well.

I have only one very ugly solution to solve the private ctors (which we should have)

Ouch ^^ Fortunately, that would only be needed if both a) there is at least one private constructor and b) the constructors are exported. With the appropriate IR node, the decision of how to encode the call site can be done at link time, I believe.

Updated the text of the proposal to include all comments until now.

Implementation notes.
So, it seems I cannot manage to implement this specification (the part about overriding and overloading methods declared in super native classes) in a backward binary compatible way. To be more precise, I would need, in raw JS classes (and traits), to generate "exporter methods" depending on @JSName, just like we do for exports. This is so that I can have refchecks and erasure check for inheritance and overloading problems at the js-name level in my class hierarchy.
So, it would not be possible to extend a facade class or trait that was compiled with an earlier version of the compiler. We can detect this in PrepJSInterop if we add an arbitrary bit of data (as an annotation on the class symbol or something like that) somewhere in the symbols of raw JS types compiled with the new version of the compiler: we can check that this bit is present on all the ancestors of a Scala.js-defined JS class, and otherwise we issue a compile error. To fix this compile error, the ancestors would need to be recompiled with a new version of the compiler to get the "exporter methods", and the witness bit.
By the fact that this is a compile error, we somehow restore backward binary compatibility, since we make it impossible to write a code that would not be backward binary compatible. Hence, binary compatibility is up to par with source compatibility, and all is well.

Well, that strategy is much worse: it's not even source compatible, as it won't let this facade compile:
trait JQuery extends js.Object {
  def `val`(): Any
  @JSName("val") def value(): Any
}

which is a pretty valid use of facades. So no go for that.
Back to figuring something out that does not involve modifying the binary output of facades.

Ongoing PR at #1809.

I realized that not really considering traits is a mistake, because then there is no sensible way one could even implement a JS interface. Consider:
trait Foo extends js.Object {
  val bar: Int = js.native
}

and the candidate "implementation" of that interface in Scala.js:
@ScalaJSDefined
class FooImpl extends Foo {
  override val bar: Int = 3
}

That would not work in any sensible way, if only because the constructor of FooImpl will try and call the trait initializer of Foo, which is not emitted. Hence linking error.
So at the very least, we should emit a compile error if we try to mixin an (implicitly native) JS trait in a Scala.js-defined JS class.
But, we could also allow Scala.js-defined JS traits. Let's first restrict them not to have any implementation (they are pure interfaces):
@ScalaJSDefined
trait Foo extends js.Object {
  val bar: Int
  def foobar(x: Int): Int
}

There would be no trait impl class for this pure interface, and therefore it would be OK to mix it in:
@ScalaJSDefined
class FooImpl extends Foo {
  val bar: Int = 3
  def foobar(x: Int): Int = x + 1
}

And the anonymous class version would work as well:
new Foo {
  val bar: Int = 3
  def foobar(x: Int): Int = x + 1
}

Now, what happens if we try to remove the restriction that it has to be a pure interface?
@ScalaJSDefined
trait Foo extends js.Object {
  val bar: Int = 3
  def foobar(x: Int): Int = x + 1
}

Now we have an implementation class like this:
object Foo$class {
  def $init$($this: Foo): Unit = {
    $this.bar_=(3)
  }
  def foobar($this: Foo, x: Int): Int = x + 1
}

and we can try and mix it in:
@ScalaJSDefined
class FooImpl extends Foo {
  def babar(): Int = foobar(bar)
}

which will become something like this after mixin:
@ScalaJSDefined
class FooImpl extends Foo {
  private[this] var _bar: Int = _

  def this() = {
    super();
    Foo$class.$init$(this)
  }

  def bar: Int = _bar
  def bar_=(v: Int): Unit = _bar = v

  def foobar(x: Int): Int = Foo$class.foobar(this, x)

  def babar(): Int = foobar(bar)
}

The funny thing is, in principle, there's nothing wrong with this class definition. It is just like any other Scala.js-defined JS class, and some of its methods call Scala methods in the trait impl (which really has nothing special, it's just like a trait impl for any other Scala class). So we could in theory completely support this.
One tricky part, though, is to remember/detect, somehow, that _bar, bar, bar_= and foobar are exposed in FooImpl (they are already exposed in Foo, which is good, and not exposed in Foo$class, which is good too), so that this.foobar(this.bar) in babar() translates correctly to this["foobar"](this["bar"]) in the IR (for example).

I've been developing a Web Components framework recently, and it seems this feature could really benefit my project, if mixin composition was also supported.
When defining a custom element, the Web Components API expects a prototype object which inherits from HTMLElement, which I believe to be easily achievable once this feature is completed.
But providing a common functionalities would be problematic, since a component can inherit from any arbitrary sub type of Element prototype, so we can't define them in its parent class.
Using a trait would be an ideal approach, but as I read it won't be supported, I was about to let users to define a proxy component instance and wire it up to the 'real' JS prototype using macros.
So, I'm glad it's been reconsidered, and very eager try it as soon as it's available if it'll indeed be supported in future.

I think I found an awesome solution to the private overloaded exported constructors :-D That does not involve the hack with a global var.
First, let's recap the issues: if one declares several overloaded constructors, at least one of them is private, and wants to export the public and protected ones. Something like this:
@ScalaJSDefined
class Foo private (x: Int, y: String) extends js.Object {
  @JSExport
  def this(x: Int) = this(x, "default")
  @JSExport
  def this(s: String) = this(0, s)
}

when translating to the IR, which can only have 1 constructor for the entire class, the constructor must run-time dispatch against the overloads. But then, the constructor, being exported to JS, cannot hide the private constructors to JS while at the same time allow Scala.js code (in the class or its companion) to call it.
Now, we could actually decide to forbid this situation in the first place, on the grounds that this is a private "method" overloaded to other "methods" (constructor methods, but still). And that's fine, because if you're in this situation, you're probably better off using factories anyway.
Except that this prevents a very important idiom, which is the single private primary constructor aggregating all the possible ways that secondary constructors can be used (just like above). That cannot be emulated by factories. The primary constructor restriction of Scala makes it very important to be able to do that as well, otherwise the API of the above class cannot be exposed.
But in that idiom, you only need the call the primary constructor (or another private secondary constructor) from another constructor, in the same object. Does that ring a bell? How do you restrict a method to be accessed only from the same object? With private[this], of course!
But, uh, can you declare a private[this] constructor!? And can you actually call it from another constructor? Let's ask Scala:
$ scala
Welcome to Scala version 2.10.0 (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_39).
Type in expressions to have them evaluated.
Type :help for more information.

scala> :paste
// Entering paste mode (ctrl-D to finish)

class Bar private[this] (val x: Int) {
  def this() = this(3)
}

// Exiting paste mode, now interpreting.

defined class Bar

scala> new Bar(3)
<console>:9: error: too many arguments for constructor Bar: ()Bar
              new Bar(3)
              ^

scala> new Bar()
res1: Bar = Bar@54bec43f

Yes! You can! And, hum, does it actually prevent you from calling it with new from a method in the class or in the companion?
scala> :paste
// Entering paste mode (ctrl-D to finish)

class Bar private[this] (val x: Int) {
  def this() = this(3)

  def foo(x: Int): Bar = new Bar(x)
}

object Bar {
  def apply(x: Int): Bar = new Bar(x)
}

// Exiting paste mode, now interpreting.

<console>:11: error: too many arguments for constructor Bar: ()Bar
         def foo(x: Int): Bar = new Bar(x)
                                ^
<console>:15: error: too many arguments for constructor Bar: ()Bar
         def apply(x: Int): Bar = new Bar(x)
                                  ^

Yes! It does!
So, what we can do about constructors is this:

Private constructors cannot be overloaded, except if they are private[this]. (Or a variant: private constructors cannot be overloaded with non-private constructors, except if they are private[this].)
If you export a Scala.js-defined JS class, all public and protected constructors are exported, but not private[this] constructors.

It is then completely possible to implement the dispatch, because the code deciding which overload to select (see #1811) only takes into account public and protected signatures. Then the tree of ifs supports all constructors, including private[this] ones.
Isn't that beautiful?

Hum, Scala.js-defined JS traits with concrete members (i.e., that are not pure interfaces) actually have a lot of difficult implementation issues, even though they look good on paper.
I'll focus on the pure interface version in a first version. That will probably not cover @mysticfall's use case, but at least we'll be able to implement a JS interface.

I'm not sure if it is a good idea to force constructors to be private[this] it will essentially prevent mixing factories & secondary ctors. We must not forget that there is a fundamental difference between factories and secondary ctors w.r.t. to mixin. Even if we currently don't (fully) support it, we should not rule out the possibility.
Also, the proposal does not allow for immutable classes with copy methods that track some private state:
final class Avg private (private val sum: Int, private val count: Int) {
  def this() = this(0, 0) // ok
  def this(v: Int) = this(v, 1) // ok

  def acc(v: Int): Avg = new Avg(sum + v, count + v) // fails
  def avg(): Double = sum.toDouble / count
}

We must not forget that there is a fundamental difference between factories and secondary ctors w.r.t. to mixin.

Hum, how so?

Also, the proposal does not allow for immutable classes with copy methods that track some private state:

Aah, nope, indeed :-s

Ctors allow for mixin (and extension for that matter), factories don't
new Foo with Bar // ok
Foo with Bar // not ok

@sjrd Don't worry, I'm glad to see that the possibility is open for future improvements. Thanks!

So, back to this constructor thing ^^ Apparently it's impossible to get away without some means to call private constructors with a magic indicator.
There is still the problem of run-time vs compile-time overload dispatch.

We definitely want run-time dispatch for the exported constructor (no choice, actually)
Hence, we also want run-time dispatch for public and protected constructors
We more or less need compile-time dispatch when delegating from one constructor to another (the this() call). That's fine, this is internal.

But what about dispatch when calling a private constructor? One thing to note is that, if we call a public or protected constructor, even though we want run-time dispatch, we definitely don't want that to dispatch at run-time to a private constructor.
When calling a private constructor, there are three viable choices:

Compile-time dispatch
Run-time dispatch where all constructors are possible targets
Run-time dispatch where only private constructors are possible targets

The last one doesn't make any sense. The second one is super weird. It would actually make a lot of sense if we could generalize it as "when calling a ctor, run-time dispatch is used against all ctors that are visible from where I'm calling"; however that has virtually unbearable and unforeseen implementation consequences (yes, I can tell now that there will be consequences I cannot see now ^^).
After thinking a long time about this, I believe only the first time makes the least bit of sense, which gives:

When calling a public or protected constructor, run-time dispatch is used against all public and protected constructors
When calling a private constructor, compile-time dispatch is used

This means that all public and protected ctors live in the same "namespace", but each private constructor has its own bubble.
Now for exports, if we want to be a little bit consistent with non-ctor methods, I still believe that we should export all public and protected ctors or none. This is the only way we can give the same semantics to calling from JS or calling from another compilation unit in Scala.js, which is a property that is otherwise respected by the entire JS classes spec, and shared with facade types, so I think this is important.
Now but what if we call a private ctor from another compilation unit? That can happen for private[pkg] constructors. I would forbid this, or rather forbid the declaration of a private[pkg] ctor (private[EnclosingClassOrObject] is fine). This is also motivated by an implementation argument: with this restriction, from a different compilation unit (and hence under separate compilation), only public and protected constructors can be called, and hence only run-time dispatch is used, the same that JS would see -> can always emit a normal JSNew.
Summarizing the semantics:

It is forbidden to declare a private[pkg] ctor, where pkg is a package
When calling a public or protected constructor, run-time dispatch is used against all public and protected constructors
When calling a private constructor, compile-time dispatch is used
@JSExport exports all the public and private ctors. It is not possible to export a subset of those.

Implementation-wise, compile-time dispatch on private constructors is implemented with a magic flag. Note that the declaration and use of this flag is local to the compilation unit. We can also use a compilation-unit-local integer to identity the ctor to dispatch to.
Using a global variable is a nightmare to manipulate. Instead, I would use a normal parameter to the IR ctor. Or, to be precise, 2 params: one is a global object whose identity proves that you are allowed to call a private ctor (a private[runtime] object PrivateCtorCall will do), and the second is the integer identifier of the ctor to call. This implementation does not require any change to the IR, and hence no special knowledge from the linker, while still providing separate compilation :-)

Will @ScalaJSDefined support monkey patching? I think that would be an excellent use case if it's feasible.

@tannerezll What do you mean exactly? Everything is in the above spec.
In Scala.js we try to avoid monkey patching because we can use implicit classes instead, which are safer because they don't pollute the prototype on a global level.

@sjrd
I am getting linkage errors  when i add a new parm(callback) to a method(first jsSetState and setState)

@JSName("React.Component")
class ReactJSComponent[P, S] extends js.Object {

  @JSName("setState")
  def jsSetState(newState: JSState[S],callback : UndefOr[() => _] = js.undefined): Unit = js.native

  @JSName("setState")
  def jsSetState(func: js.Function2[JSState[S], JSProps[P], JSState[S]]): Unit = js.native

}

@ScalaJSDefined
abstract class ReactComponent[P, S] extends ReactJSComponent[P, S] {

  @JSName("sSetState")
  @inline
  def setState(newState: S,callback : UndefOr[() => _] = js.undefined): Unit = {
    jsSetState(JSState(newState),callback)
  }

  @JSName("sSetStateFunc")
  @inline
  def setState(func: js.Function2[S, P, S]): Unit = {
    jsSetState((s: JSState[S], p: JSProps[P]) => JSState[S](func(s.sstate, p.sprops)))
  }
}

Error :
[error] Referring to non-existent method O.setState$default$2__Lchandu0101_scalajs_ReactComponent__sjs_js_UndefOr
[error]   called from Lchandu0101_scalajs_ReactComponent.sSetState
[error]   exported to JavaScript with @JSExport
[error] involving instantiated classes:
[error]   Lchandu0101_scalajs_ReactComponent
//repeat above infinite times

If i remove second param (callaback ) from
def jsSetState(newState: JSState[S],callback : UndefOr[() => _] = js.undefined): Unit = js.native
def setState(newState: S,callback : UndefOr[() => _] = js.undefined): Unit
         ||
def jsSetState(newState: JSState[S]): Unit = js.native
def setState(newState: S): Unit

code compiles fine.
i tried to reproduce same in simple example , but no luck :(

Thanks for the report. Looks like an issue with default parameters.

@chandu0101 Should be fixed in the latest branch.

working perfect , thank you :)

What's the story going to be with Scala.JS-generated ES6 classes and browser compatibility? Is the plan to just spit out ES6 JS and then we run it through a ES5 transpiler if we want broad browser compatibility?

Depends on your scalaJSOuputMode. By default it's ECMAScript51Isolated, so we generate compliant ECMAScript 5.1 code, even for Scala.js-defined JS classes. They have the same "shape" and almost the same semantics as ES 6 classes, in that case. (semantics difference are only apparent if you "break the type system" from JS code - ES 5 "classes" are a bit more permissive than ES 6 classes)

@sjrd That's super cool. Thanks.


could you provide the multi-threaded code about the image generation

python image_generation_with_reference.py
--image_file "path/of/the/image/file or folder"
--model_weights weights/vec2face_generator.pth
--batch_size 5
--example 10
--name images-of-references

the generation of the images is far too slow

I have updated the code. It does not include the AttrOP process, so the speed is way faster but there is no guarantee for good image quality (it is due to the low image resolution in the training set).
You can further use DataParallel to use multiple gpus for faster inference.


Helm install unable to create admin account

A clear and concise description of what the bug is.
After installing superset (0.36.0) using helm chart (1.1.11), creating the admin account results in an exception
Expected results
User should be created
Actual results
An exception is produced and user is not able to log in
Screenshots
If applicable, add screenshots to help explain your problem.
How to reproduce the bug
Install superset with helm 1.1.11 with values:
superset:
enabled: true
persistence:
enabled: true
Environment
(please complete the following information):

superset version: superset version 0.36.0
python version: python --version 3.6.10 in pod
node.js version: node -v  node not found in pod
npm version: npm -v not found in pod

Checklist
Make sure these boxes are checked before submitting your issue - thank you!

[ ] I have checked the superset logs for python stacktraces and included it here as text if there are any.
[ ] I have reproduced the issue with at least the latest released version of superset.
[ ] I have checked the issue tracker for the same issue and I haven't found one similar.

Additional context
Add any other context about the problem here.
michael@michael:~$ sudo kubectl exec -it cog-superset-7c4c7d8594-ld2zt -- fabmanager create-admin --app superset
[sudo] password for michael:
fabmanager is going to be deprecated in 2.2.X, you can use the same commands on the improved 'flask fab '
Username [admin]: admin
User first name [admin]: admin
User last name [user]: admin
Email<EMAIL_ADDRESS><EMAIL_ADDRESS>Password:
Repeat for confirmation:
/usr/local/lib/python3.6/site-packages/psycopg2/init.py:144: UserWarning: The psycopg2 wheel package will be renamed from release 2.8; in order to keep installing from binary please use "pip install psycopg2-binary" instead. For details see: http://initd.org/psycopg/docs/install.html#binary-install-from-pypi.
""")
Traceback (most recent call last):
File "/usr/local/bin/fabmanager", line 8, in
sys.exit(cli())
File "/usr/local/lib/python3.6/site-packages/flask_appbuilder/console.py", line 422, in cli
cli_app()
File "/usr/local/lib/python3.6/site-packages/click/core.py", line 829, in call
return self.main(*args, **kwargs)
File "/usr/local/lib/python3.6/site-packages/click/core.py", line 782, in main
rv = self.invoke(ctx)
File "/usr/local/lib/python3.6/site-packages/click/core.py", line 1259, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/usr/local/lib/python3.6/site-packages/click/core.py", line 1066, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/usr/local/lib/python3.6/site-packages/click/core.py", line 610, in invoke
return callback(*args, **kwargs)
File "/usr/local/lib/python3.6/site-packages/flask_appbuilder/console.py", line 137, in create_admin
auth_type.get(_appbuilder.sm.auth_type, "No Auth method")
AttributeError: 'NoneType' object has no attribute 'auth_type'
command terminated with exit code 1

Instructions must have been out of date.  Using superset-init did work when exec into the pod.  I have yet to get the custom init file to work, but that is probably me.


decoding array with json objects results in 'invalid JSONB data format'

Version:
Vapor 3.3.3
PostgreSQL 1.5.0
I'm using a raw query to fetch all columns from User table plus all the users roles from the roles/ roles pivot table. Using this raw query directly inside the database shows me the correct values.
Raw Query
SELECT u.*, ARRAY_AGG(JSON_BUILD_OBJECT('name', r."name", 'isInternalRole', r."isInternalRole")) AS "roles"
FROM "User" u
JOIN "Role_User" ru ON u."id" = ru."userID"
JOIN "Role" r ON r."id" = ru."roleID"
GROUP BY u."id";

Here the roles column from my raw query. The roles column now holds an array with the two columns name and isInternalRole as json objects.
Picture1:

Now using this raw query with vapor
func getAllUsers() -> Future<APIUserResponse> {
        return db.withConnection{ conn in
            return conn.raw("""
            SELECT u.*, ARRAY_AGG(JSON_BUILD_OBJECT('name', r."name", 'isInternalRole', r."isInternalRole")) AS "roles"
            FROM "User" u
            JOIN "Role_User" ru ON u."id" = ru."userID"
            JOIN "Role" r ON r."id" = ru."roleID"
            GROUP BY u."id";
            """).all(decoding: UserRoleAgg.self).map{ userRoleAggCollection in
                let apiUserDataCollection = userRoleAggCollection.map{ userRoleAgg -> APIUserData in
                    let userPublic = userRoleAgg.convertToPublic()
                    let roles = userRoleAgg.roles.map{ Role(name: $0.name, isInternalRole: $0.isInternalRole) }
                    return APIUserData(user: userPublic, roles: roles)
                }
                return APIUserResponse(type: .full, source: apiUserDataCollection)
            }
        }
    }

The execution stops at the line """).all(decoding: UserRoleAgg.self).map{ userRoleAggCollection in with NIO-ELT-#1 (2): Assertion failed: invalid JSONB data format.
Picture2:

I'm using postgresql functions like array_agg to create the array and json_build_object to create the json objects inside the array. When examining Picture 1 it seems that the format is correct.
So I guess fetching the data is working, just decoding it into UserRoleAgg fails.
struct UserRoleAgg: Decodable, UserDefinition {
        var id: UUID?
        var firstName: String
        ...
        var roles: [Role]

        func convertToPublic() -> User.Public {
            return ...
        }
}

public final class Role: Codable {
    public var id: Int?
    public var name: String
    public var isInternalRole: Bool

    public init(name: String, isInternalRole: Bool) {
        self.name = name
        self.isInternalRole = isInternalRole
    }
}

Decoding into UserRoleAgg's role property of type [Role] is causing the issue.
As a side note:
At the beginning UserRoleAgg's roles property was of type [String], the raw query was a bit different (the first line -> SELECT "User".*, ARRAY_REMOVE(ARRAY_AGG("Role"."name"), NULL) AS "roles" FROM "User"). My Role model only had the properties ID and name. Decoding was working fine.

You have to always use jsonb, e.g. JSONB_BUILD_OBJECT

Oh lord, I was looking for JSONB_BUILD_OBJECT yesterday night, but couldn't find it in the postgresql docs, so I thought there is no such function. Maybe it was to late, I was to sleepy whatever. @MihaelIsaev thanks for the quick reply


Improve NavBar UI on Hovering

Hey @A-BMT02, I would like to improve the UI of navbar. Could you assign this to me?

Hello @dhrumishah
@Harsh3363 is working on the issue https://github.com/A-BMT02/snippets/issues/2 for the NavBar hover animation
If you have any other idea to improve the Navbar UI, i can assign this issue to you
Have a look at the design file https://www.figma.com/file/asYmiNQAfRLMNSvk5eecN6/Untitled?node-id=0%3A1
Thank you for taking your time

I want to create navbar somewhat like this. So if you are agreeing with this UI can I work on this?

Looks Good @dhrumishah.
Go ahead i'll assign the issue to you

Also, can you please add hacktoberfest label?

If the project has 'hacktoberfest' label on it, your pull request will still be counted. It doesn't have to be on the issue. But, I'll go ahead and add it here

If the project has 'hacktoberfest' label on it, your pull request will still be counted. It doesn't have to be on the issue. But, I'll go ahead and add it here

Oh okay!


Not working on my Xcode 6.4 (6E35b)

Any solution to this? The theme is still there but whole variable section is gone

Same


Fix Databricks shim build

Fixes #3271.
Updates the Databricks shim builds after #3259.

Manually testing the changes on Databricks, leaving in draft for now.

build

Build and window tests pass with this patch on Databricks 7.3 and 8.2.


ARROW-10042: [Rust] BufferData's equality should depend on its capacity; ArrayData's equality should not depend on its BufferDatas' capacities' equality

The tests added, unignored, and modified in this PR should illustrate the behavior I'm going for.
This gets 2 ignored Parquet -> Arrow roundtrip tests to pass because they were only failing due to differences in their ArrayData's BufferData capacities.
This leaves BufferData's PartialEq implementation as-is (that is, taking the equality of capacity into account) and does not modify any of the tests in rust/arrow/src/array/{array, builder, union}.rs or in rust/arrow/src/compute/{kernels/cast, kernels/filter, util}.rs that are testing the internal implementation of Buffer.
This does change PartialEq for ArrayData to not assert to fix the problems noted by @jorgecarleitao .
This has the downside of making test failures where ArrayDatas should be equal but aren't harder to interpret because the assert_eq!s aren't as granular. We can't use debug_assert_eq! either, because then we can't write tests that do assert_ne!(array_data1, array_data2) (I have included an example of such a test). I think to solve this downside, we should add a function only used in tests that does the more granular assertions. I am leaving that to a future PR.

Could you describe where do we need to compare buffers?
I am asking because I have worked on this problem before, and in my last iteration of this, I abandoned the idea of comparing buffers: a Buffer is purely a physical representation of data without any logical interpretation: two buffers from two different arrays can be equal and the arrays still be different (e.g. due to the nullability), and the opposite is also true: two arrays can be equal but have different buffers (e.g. if the child data is different, or if the datatype is different).
IMO the equality should be done via ArrayData, which contains all the relevant data and logical representation of that data -- DataType, to make it possible to logically compare two arrays. I fielded #8541 with that idea, which IMO will also help the parquet work. I think that @nevi-me also had some ideas in mind.

I can't find the reference now but this was discussed some time ago on a PR.  The thinking for taking capacity into account when comparing Buffer's was that array equality, etc. would be done at a higher level as @jorgecarleitao described.  I think that @sunchao, in particular, favored taking capacity into account when comparing Buffer's.  i.e. this is a more low-level equality check.

Here is the PR: #4331
See the comment about half way down (I'm can't seem to link to it directly)

If I remove the impl PartialEq for BufferData entirely, compiling then complains that the #[derive(PartialEq)] on Buffer can't work.  I am only trying to understand why would we would like to compare two Buffer and not take the ArrayData::offset into account in the equality. Without the offset, comparing buffers is basically comparing physical memory, and IMO has limited use-cases.

I do not think that we should remove impl PartialEq for BufferData. I am only trying to understand why would we would like to compare two Buffer and not take the ArrayData::offset into account in the equality. Without the offset, comparing buffers is basically comparing physical memory, and IMO has limited use-cases.

I was not proposing that we remove impl PartialEq for BufferData, I was only doing that to get the compiler to tell me about all the places we're using it.

Additional data to consider: I'm not confident the implementations are exactly comparable, but the C++ Buffer type does not take its capacity into account in its Equals implementations.

@jorgecarleitao @nevi-me @alamb I've just force pushed an alternative solution to this problem that doesn't change BufferData's PartialEq implementation, and I've added more tests to demonstrate the problems I'm trying to solve. I would appreciate another look and to know what you think!

Also, I very much agree with @carols10cents that we need a methodology to compare arrays with granularity :)

One idea:

Make the array comparison on the parquet tests be done using the PartialEq, like this PR is doing
Make PartialEq use the function equal being introduced on #8541
Remove both #[ignore]

I also like this approach, as #8541 now accounts for logical equality

Hi @carols10cents, with the IPC integration and logical equality PRs merged, this should be ready (the Parquet changes).
We can merge it in after you rebase :)

@nevi-me done! The only changes left here are in tests :) Thank you all for the work related to this!

@nevi-me  and @jorgecarleitao  I think we should merge this PR -- is there anything else that needs to be done before we do so?

(though the title may need to be updated)

(updated)

@nevi-me and @jorgecarleitao I think we should merge this PR -- is there anything else that needs to be done before we do so?

You may go ahead and merge it :) I was waiting for integration tests to complete, but I'm about to head to sleep now

The tests have passed:

I'll merge it


Create 2021-07-12-opensearch-general-availability-announcement.markdown

Description
Initial GA Announcement Draft
TODO

Add contributors (pending aggregation)
Review "as you see fit" language
Tone and flow
Validate min artifact status
Add post header in md

Issues Resolved
Not applicable
By submitting this pull request, I confirm that my contribution is made under the terms of the BSD-3-Clause License.

Duplicate.


grunt generating lots of new .css.map files for examples

not sure if this is specific to my setup on Windows, but: it seems that by default running grunt now generates map files for all the various css files in the examples. as these aren't in the current repo, they're all flagged all the time as new untracked files. any way to either disable this in explicitly in the grunt script, or alternatively to add the map files to the repo so they're at least only showing up as modified, rather than untracked?

I think #22045 may have fixed this?

Closed by https://github.com/twbs/bootstrap/pull/22477


Add vm command.

Fix libsecp256k1 not found issue when running .build/kevm-vm

@ehildenb This is the pull request for adding vm command. Please take a look. Thank you.

Jenkins: test this please

Closing, out of date.


Toolbar toggle to manually (temporarily) override time-based setting

Is your feature request related to a problem? Please describe.
I was actually looking for a way to quickly toggle the firefox/website theme, without having to go to Firefox' settings. This plugin seems quite cool in offering that based on time or sunset/-rise. However, sometimes I'd like to override this temporarily (e.g. I woke up early and already want the light theme).
Describe the solution you'd like
Have this plugin come with a toggle button, that can be dragged in the toolbar. When clicking the button, will toggle between the original (time-based) theme and the other option (e.g. dark if you're currently in light).
When the time-based process kicks in to set another theme, it will override the toggle-based value: If I woke up before sunrise & toggled the theme to light, upon sunrise the theme will stay light (because I was on light theme already). But in the night the theme will change to dark on sunset (because the toggle value doesn't prevent the time-based process to change the current state).
Additional context
Add any other context or screenshots about the feature request here.

+1 for this. I'd love it if it was present in the toolbar like every other Add-On I have.
Hopefully, the developer adds this.

+1. Would be great to have a clickable toolbar button to toggle mode. Maybe also an extension (revamp) in settings - Manual / Automatic / Follow the system, with change times for automatic.
P.S.: Thank you for the extension. It really works and does exactly what's needed. Just wish to have a bit of manual control for when it's needed.


White screen on start when ELECTRON_IS_DEV=1

The main window is white when starting Bruno while the ELECTRON_IS_DEV env variable is set to 1. Importing / trying to import collections has no influence on the main window.
Tested on:

MacOS @ v1.5.1

Preferences file is located at: /Users/<redacted>/Library/Application Support/bruno/preferences.json
2023-12-20 15:52:08.687 Bruno[51581:6167298] WARNING: Secure coding is not enabled for restorable state! Enable secure coding by implementing NSApplicationDelegate.applicationSupportsSecureRestorableState: and returning YES.
objc[51584]: Class WebSwapCGLLayer is implemented in both /System/Library/Frameworks/WebKit.framework/Versions/A/Frameworks/WebCore.framework/Versions/A/Frameworks/libANGLE-shared.dylib (0x23bbb9958) and /Applications/Bruno.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Libraries/libGLESv2.dylib (0x10a33e978). One of the two will be used. Which one is undefined.
(node:51581) electron: Failed to load URL:
http://localhost:3000/
with error: ERR_CONNECTION_REFUSED
(Use `Bruno --trace-warnings ...` to show where the warning was created)
Error: Failed to load URL: "
http://localhost:3000"
(Electron shows a blank screen because of this).
Original message: Error: ERR_CONNECTION_REFUSED (-102) loading '
[http://localhost:3000/'](http://localhost:3000/%27)
    at rejectAndCleanup (node:electron/js2c/browser_init:165:7506)
    at EventEmitter.failListener (node:electron/js2c/browser_init:165:7719)
    at EventEmitter.emit (node:events:527:28) {
  errno: -102,
  code: 'ERR_CONNECTION_REFUSED',
  url: '
[http://localhost:3000/'](http://localhost:3000/%27)
}
Could not connect to Next.Js dev server, is it running? Start the dev server using "npm run dev:web" and restart electron

Windows 10 @ v1.4.0 & v1.5.0 & v1.5.1

C:\Users\<redacted>\AppData\Local\Programs\bruno>set ELECTRON_IS_DEV=1 && Bruno.exe
Preferences file is located at: C:\Users\<redacted>\AppData\Roaming\bruno\preferences.json
(node:42884) electron: Failed to load URL: http://localhost:3000/ with error: ERR_EMPTY_RESPONSE
(Use `Bruno --trace-warnings ...` to show where the warning was created)
Error: Failed to load URL: "http://localhost:3000" (Electron shows a blank screen because of this).
Original message: Error: ERR_EMPTY_RESPONSE (-324) loading 'http://localhost:3000/'
    at rejectAndCleanup (node:electron/js2c/browser_init:165:7506)
    at EventEmitter.failListener (node:electron/js2c/browser_init:165:7719)
    at EventEmitter.emit (node:events:527:28) {
  errno: -324,
  code: 'ERR_EMPTY_RESPONSE',
  url: 'http://localhost:3000/'
}
Could not connect to Next.Js dev server, is it running? Start the dev server using "npm run dev:web" and restart electron

This is the relevant code:
https://github.com/usebruno/bruno/blob/d268b4786abe07861ffd41e636a19013804f5015/packages/bruno-electron/src/index.js#L64-L86
When starting in dev mode, Bruno tries to open http://localhost:3000. When run in production mode, Bruno opens the JavaScript bundle included in the app.
If you try to run Bruno from source, make sure to run npm run dev:web before starting electron.

Nice, straight to the point!
However, I would postulate that isDev isn't the right tool for this use case and should actually be app.isPackaged.
In the recent times when developing an Electron app - and having ELECTRON_IS_DEV permanently turned on - I leaned to expect many other apps opening the dev tools, which I understand - it basically flips them into debug mode. However, none of them straight up broke like Bruno did.
The decision to use the served dev-server isn't something that should be based on the debug flag. I'd say it should either be a run argument (like --useDevServer) or the above mentioned app.isPackaged check. Is Bruno ever expected to run not packaged in production?
I'm open to creating a PR for either of the fixes :)

Yeah, you're right, would totally be the better option here. You can create a PR for this, if you want, we would appreciate it.

#1260 is open :)

@Its-treason Any update on this? We develop an Electron based app for which we set Electron_is_dev to 1. This means we can't use Bruno at the same time.

@Its-treason Any update on this? We develop an Electron based app for which we set Electron_is_dev to 1. This means we can't use Bruno at the same time.

Hey, I just added my Approved to the PR, but I cannot give you an ETA on when this will be merged. But it is a small change, so probably soon. CC @sanjai0py for visibility.


Add guide for self hosting postgsail on AWS

This guide is for self hosting postgsail on an AWS EC2 instance, it's a work in progress.

thanks


Remove gametype related code

Removes all references to gametype-specific things in the mod code (with few exceptions).
Removed following stuff:

Removed all gametypes from the gameType_t enum except for WOLF_GT -> renamed to ETJUMP_GAMETYPE
Removed all server/client/ui cvars and variables that are only relevant to specific gametypes
Removed all functions/function code paths that are only used in specific gametypes
Removed all macros that are relevant to specific gametypes
Removed campaign and listcampaigns commands
Removed all references to single player and savegame support

Stuff that was still kept:

g_gametype cvar is still present for server browser functionality
MAX_GAMETYPES is still 16 for server browser functionality
Host Game menu still contains some LMS/Stopwatch specific cvars, only removed the LMS subwindow. Gametype can also still be changed, but the map feeder only functions on Objective mode

Should be all done now, updated the original PR message to detail what was removed.


Add support for WAPI / withdraw command.

Need to look this over tomorrow with fresh eyes, but this should add support for withdraw functionality as defined in the docs here: https://github.com/binance-exchange/binance-official-api-docs/blob/master/wapi-api.md#withdraw
I'll post up a note when it's ready for final review unless you've got any immediate feedback.
Thanks!

I have confirmed that this functions as expected. Please let me know if you have any commentary on it.
Thanks!


[Bus Protocol] Publishing metric to self duplicates the message?

Reproducible Scenario
package main

import (
	"time"

	"github.com/go-mangos/mangos/protocol/bus"
	"github.com/go-mangos/mangos/transport/ipc"
	"github.com/go-mangos/mangos/transport/tcp"
)

func main() {
	url := "tcp://<IP_ADDRESS>:55755"

	sock, _ := bus.NewSocket()
	sock.AddTransport(ipc.NewTransport())
	sock.AddTransport(tcp.NewTransport())

	sock.Listen(url)

	// Add self to dial
	sock.Dial(url)

	// print msg
	go func() {
		for {
			msgBytes, _ := sock.Recv()

			// Receive duplicates here
			msg := string(msgBytes)
			println("Received: " + msg)
		}
	}()

	for range time.Tick(2 * time.Second) {
		println("")
		println("Sent: hello")
		sock.Send([]byte("hello"))
	}
}

Is this expected behavior?
System Environment
OS X El Capitan 10.11.6
go version go1.7rc3 darwin/amd64
Latest master version of mangos

This is weird, in that you've connected the socket to itself -- and I think I understand what is happening.
By doing this, you're attaching two endpoints to the socket -- and thus creating (from mangos' point of view) two endpoints.  The system allocates a random port, say "1234", and you have requested port 55755.  Mangos thinks you have one pipe with local port number 1234, and another with local port 55755.  It does not realize that these are two ends of the same port, nor does it care.
Now when you send, it broadcasts to all connected pipes, so it sends a message out on the pipe with 1234, and again on the pipe to 55755.  Because these pipes are looped to each other, the message sent at 1234 is read back on 55755, and vice versa.  You get two messages.
All of this comes about because mangos does not realize you've created this back to back connection.  (In fact, with some protocols, like REQ/REP, or PUB/SUB, this type of connection would be impossible.  Arguably its a configuration error to create this in the first place.)
Upshot is, yes, given this misconfiguration, this is indeed what you'd expect to happen.
In theory we could add code to check and notice that the remote peer is connected to the same socket, but I won't be doing that -- I don't think the complexity and risk are worth the benefits.


Output Display

Hi There! I've a suggestion, place a output screen below the code. It will make more satisfaction to users who are trying to get their code besides output.

Hello @noorulameen17 ,
Thank you for your suggestion. Do you mean to have the output screen below the input screen? If that's the case, it was like this before, but we had to change this behavior to double advertising impressions (this project has a negative revenue which means the API we pay costs more than the revenue we are making )
Best Regards,
Jon


Reverse iterator over a log stream

The AsyncLogReader only provides forward iterator over a log stream. Sometimes, a reverse iterator is helpful.

@jderrickk I've created https://issues.apache.org/jira/browse/DL-9. let's move the work to apache. I am going to close this issue here. is that okay?


Huge bug in Thengascript 0.1.4 package

node simple.js

Lines 55 and 62 in the thengascript cause the program to throw error

.

I will do a PR tomorrow

This has been fixed. Please check it out and let me know.

This has been fixed. Please check it out and let me know.

Ok issue solved


xPendingReboot: post 'Invalid namespace' warning and doesn't reboot

Details of the scenario you tried and the problem that is occurring
I'm using xPendingReboot at the and of my configuration, but the logs suggest that:

xPendingReboot couldn't query CCM_ClientUtilities because it failed to find some needed namespace
Reboot is required anyway and it was not done.

Verbose logs showing the problem
VERBOSE: [ukwest000000]: LCM:  [ Start  Resource ]  [[xPendingReboot]AfterVmSetup]
VERBOSE: [ukwest000000]: LCM:  [ Start  Test     ]  [[xPendingReboot]AfterVmSetup]
WARNING: [ukwest000000]:                            [[xPendingReboot]AfterVmSetup] Unable to query CCM_ClientUtilities: Invalid namespace
VERBOSE: [ukwest000000]:                            [[xPendingReboot]AfterVmSetup] Pending file rename found.
VERBOSE: [ukwest000000]: LCM:  [ End    Test     ]  [[xPendingReboot]AfterVmSetup]  in 0.0470 seconds.
VERBOSE: [ukwest000000]: LCM:  [ Start  Set      ]  [[xPendingReboot]AfterVmSetup]
VERBOSE: [ukwest000000]: LCM:  [ End    Set      ]  [[xPendingReboot]AfterVmSetup]  in 0.0000 seconds.
VERBOSE: [ukwest000000]: LCM:  [ End    Resource ]  [[xPendingReboot]AfterVmSetup]
VERBOSE: [ukwest000000]:                            [] A reboot is required to progress further. Please reboot the system.
WARNING: [ukwest000000]:                            [] A reboot is required to progress further. Please reboot the system.
VERBOSE: [ukwest000000]: LCM:  [ End    Set      ]
VERBOSE: [ukwest000000]: LCM:  [ End    Set      ]    in  7.6100 seconds.
VERBOSE: Operation 'Invoke CimMethod' complete.
VERBOSE: Time taken for configuration job to complete is 8.157 seconds

Suggested solution to the issue
Fix it please =)
Or provide a workaround.
The DSC configuration that is used to reproduce the issue (as detailed as possible)
        # Check if a reboot is needed after we setup the VM
        xPendingReboot AfterVmSetup
        {
            Name = 'AfterVmSetup'
        }

The operating system the target node is running
OsName               : Microsoft Windows Server 2019 Datacenter
OsOperatingSystemSKU : DatacenterServerEdition
OsArchitecture       : 64-bit
WindowsVersion       : 1809
WindowsBuildLabEx    : 17763.1.amd64fre.rs5_release.180914-1434
OsLanguage           : en-US
OsMuiLanguages       : {en-US}

Version and build of PowerShell the target node is running
Name                           Value
----                           -----
PSVersion                      5.1.17763.316
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.17763.316
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>

Version of the DSC module that was used ('dev' if using current dev branch)
ModuleName                     Version
----------                     -------
xPendingReboot                 <IP_ADDRESS>

xPendingReboot is fickle :-)
CCM_ClientUtilities: Invalid namespace   can be avoided by specifying SkipCcmClientSDK = $True.   that's just the check to see if SCCM thinks a reboot is needed; and the class isn't available if you don't have the SCCM client.
As for the no actual reboot,  ensure the LCM is allowed to reboot the node
(Get-DscLocalConfigurationManager).RebootNodeIfNeeded   must be $true; if not set if before hand with set-DscLocalConfigurationManager

Thanks @brinkers

@brinkers
So, by default it doesn't check to see if the SCCM client is installed and just fails if it isn't?

This is related to #13. I will be addressing this when I move the resource to ComputerManagementDsc.
@b3nt0 - your suggestion is correct and will be addressed during the migration.
There is an issue where regardless of the SCCM state of the client a reboot will never be triggered. This is because there is no check for the status in the Test-TargetResource. I'll be addressing this during the migration.

This has been fixed over in the new PendingReboot in ComputerManagementDsc. @gaelcolas - can you close this one?


Added Best practices recommended

Added Best practices recommended when customer starts using Redis.

Cool to see such documents being written. It really brings evidence that the go-to people are the right people to ... go to. smile
I found one issue: Please check if all recommendations are truly something the user can do. If those recommendations are for platform engineers, then it would be confusing to list them here.
Also, for the future, you might want to re-read the public docs' CONTRIBUTING guide. Specifically:

Capitalize proper nouns, in particular, names of projects, companies, and products: Kubernetes, Amazon, Azure.
Write in plain English.

I suggested fixes for these in the present PR, so I hopefully lead by example. smile

Thanks @cristiklein My apologize , Fixed all your suggestions :). i will re-read CONTRIBUTING.md guide for future PR's :) . Much appreciated.


Error response 524 (timeout) when running dbt with ClickHouse

I am running some queries in clickhouse with dbt, but it is not working correctly. Sometimes works as expected, but sometimes fail with error response 524. Does somebody knows what is happening?
I tried to find something about this behavior, but i found nothing about that. I know that i need to configure some settings in clickhouse, but i tried set and continuous not working as expected.
PS: I am using GCS to store table data in ClickHouse
settings:
default/max_execution_time: 3600
default/send_timeout: 3600
default/http_send_timeout: 3600
default/http_receive_timeout: 3600
default/wait_for_async_insert_timeout: 3600
default/replication_wait_for_inactive_replica_timeout: 3600
default/lock_acquire_timeout: 3600
default/receive_timeout: 3600
default/timeout_before_checking_execution_speed: 600
default/max_insert_block_size: 10484490
default/max_compress_block_size: 10485760
error:
[2024-01-16T13:07:18.062+0000] {eventmgr.py:57} DEBUG - 13:07:18.061894 [debug] [Thread-1 (]: dbt_clickhouse adapter: Error running SQL: /* {"app": "dbt", "dbt_version": "1.4.7", "profile_name": "clickhouse", "target_name": "dev", "node_id": "model.data_db.chi_AccessLog"} */
      insert into analytics.chi_AccessLog__dbt_backup ("id", "isLogin", "created", "familia_sistema_operacional")

with source as (
select *
from prod_icv.chi_AccessLog
)
select * from source
[2024-01-16T13:07:18.063+0000] {eventmgr.py:57} DEBUG - 13:07:18.063603 [debug] [Thread-1 (]: Timing info for model.data_db.chi_AccessLog (execute): 2024-01-16 13:05:37.752748 => 2024-01-16 13:07:18.063447
[2024-01-16T13:07:18.082+0000] {eventmgr.py:57} DEBUG - 13:07:18.082336 [debug] [Thread-1 (]: Database Error in model chi_AccessLog (models/clickhouse/chi_AccessLog.sql)
:HTTPDriver for https://MY_HOST:8443 returned response code 524)
error code: 524
compiled Code at target/run/data_db/models/clickhouse/chi_AccessLog.sql
[2024-01-16T13:07:18.084+0000] {eventmgr.py:57} DEBUG - 13:07:18.084379 [debug] [Thread-1 (]: Sending event: {'category': 'dbt', 'action': 'run_model', 'label': '0ae1c317-e467-4864-b10b-e060e200cca1', 'context': [<snowplow_tracker.self_describing_json.SelfDescribingJson object at 0x7c80bf7e3910>]}
[2024-01-16T13:07:18.086+0000] {logging_mixin.py:154} INFO - 13:07:18  39 of 40 ERROR creating sql table model analytics.chi_AccessLog ................ [ERROR in 100.34s]
[2024-01-16T13:07:18.085+0000] {eventmgr.py:63} ERROR - 13:07:18  39 of 40 ERROR creating sql table model analytics.chi_AccessLog ................ [ERROR in 100.34s]
[2024-01-16T13:07:18.087+0000] {eventmgr.py:63} ERROR - 13:07:18.085688 [error] [Thread-1 (]: 39 of 40 ERROR creating sql table model analytics.chi_AccessLog ................ [ERROR in 100.34s]

524 seems to be a CloudFlare timeout, which defaults at 100 seconds for HTTP responses.  See https://community.cloudflare.com/t/increase-cloudflare-max-request-duration/482873, which has some possible solutions.   You might also try using the native driver in your configuration to get around the Cloudflare timeout, move your ClickHouse server to some other provider, or reduce the size of your materializations so they take less than 100 seconds.
If you are using incremental materializations and don't need updates (which are extremely expensive in ClickHouse via dbt), you might use append incremental strategy to improve performance.


Varnish failed to start because unable to resolve hostname web

ddev v1.19.1
Error:
Message from VCC-compiler:
Backend host '"web"' could not be resolved to an IP address:
Name or service not known
(Sorry if that error message is gibberish.)
('/etc/varnish/default.vcl' Line 8 Pos 11)
.host = "web";
----------#####-`
Do you have any idea how to solve this.
Thanks

Thanks @frostblogNet - Could you try

#2
You can just add

depends_on:
- web

Thanks @frostblogNet - Could you try

Make varnish not come up until web container is up, fixes #1 #2
You can just add

depends_on:
- web

Tested the Magento shop. Works on my machine with Varnish 6 and depends_on setting.

@rfay For M1 Mac I had to add platform: linux/x86_64, because there is no arm/v8 image available.

@rfay For M1 Mac I had to add platform: linux/x86_64, because there is no arm/v8 image available.

Found a arm/v8 image -> v6.6

6.0 is "stable" == 6.0.10 I think, and it has arm64, https://hub.docker.com/_/varnish?tab=tags&page=1&name=6.0

Followup for 6.0,

https://github.com/drud/ddev-varnish/pull/3

Hello @rfay
Thanks depends on works for us. There is still a problem with additional_fqdns but I have to invastigate to find out what is the root cause of this issue.

I'm not completely sure additional_fqdns has every worked with varnish... Did it work for you before? The problem is that ddev-router manages that and varnish injects itself in front.

Please open an issue or PR about additional_fqdns/additional_hostnames so it can be documented if that's the case.


Why not just child elements?

Not an issue. Just curious why function as child plus render prop. Why not just child elements?
Isn't this easier to write, and easier to separate components base on viewport width?
<Media query="(max-width: 599px)">

The document is less than 600px wide.

</Media>
<Media query="(min-width: 600px)">

The document is at least 600px wide.

 </Media>

Just wanted to see if there is any downside of child elements I am not aware of.
Thanks,
Richard

Hey @richardzcode, please see my answer to this question in a similar issue from a few weeks ago
Hope that helps!

I see. Thank you!


Refer to annotations when deleting GCE machines.

Don't rely on the project/zone from the providerConfig, or the object name (which now allows the VM name to differ from the machine name), except as a fallback for missing annotations, like during client-side deletion.

This change is


Remove dangling constant ops when importing non-optional-input ops.

constant unit is used for optional inputs.
This patch is to create constant unit ops for optional inputs only when we are importing ops with optional inputs. Hence, it avoids creating dangling constant unit ops in the other cases.

@tungld if we have multiple ops with optional inputs, will the usage of the none value be automatically shared between the users?

Yes, it will be automatically shared. none is initialized when we import the first op with optional inputs. Once it is initialized, the other ops will reuse it without creating a new none.


Preprint edits

Addresses issues #114 and #97 along with some minor edits, wrapping up final edits before submission.

These all look good. Should we also pull out the html comments at this point? Or does it not matter because we will submit the rendered pdf?

I think we should clean up the HTML comments, I think most have been addressed when I was looking through the manuscript.

<ping> what still needs to be done to submit? just to take out the html comments?

I think so, I seem to recall going through most of the issues. Does it read
like it's ready to submit to you?
On Thu, Mar 17, 2016 at 7:15 AM Naupaka Zimmerman<EMAIL_ADDRESS>wrote:

 what still needs to be done to submit? just to take out the html
comments?
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/emhart/10-simple-rules-data-storage/pull/122#issuecomment-197897185

I can check through it tonight and remove any last comments, etc. Maybe merge this PR now so everything stays organized?


Can't load library - windows_libs\<IP_ADDRESS>\lib\hadoop.dll

Looks like windows_libs\<IP_ADDRESS> is not updated yet in master. Project is failing with <IP_ADDRESS> profile.

Sorry for the oversight. I had not been keeping the windows libs up to date. I have corrected this. Please feel free to reopen if you still encounter issues using trunk.

Great, Thanks @sakserv


Should scrollTop/Left be relative to document origin rather than layout viewport?

And similarly, visualviewportchanged fire when the position changes relative to the document origin rather than just the layout viewport.
Arguments for document origin:

Better matches the current behavior of pageXOffset/YOffset which these APIs are intended to supplant.
Better matches scenarios involving triggers at particular scroll offsets -- e.g. load in more content when the visual viewport is at 95% of the scrollHeight.
Better matches scenarios involving positioning of non-fixed content, e.g. absolute-positioned modal dialogs that should be centered in the visible region.
Better matches scenarios of scrolling a particular part of the document into view by setting visualViewport.scrollTop
visualviewportchanged is sufficient to detect visual viewport motion relative to the document -- the developer doesn't need to additionally register for the scroll event

Arguments for layout viewport origin:

Better matches scenarios involving positioning of fixed content, e.g. pseudo-device-fixed as your code sample demonstrates.
Better matches "is in view" checks since the offsets can be directly compared against the getBoundingClientRect() of the target, which is also measured relative to the layout viewport origin.
visualviewportchanged can fire more rarely, particularly in usage scenarios with prolonged panning against the edge of the layout viewport.

I lean towards document origin but can see the pros for each side.  I'm guessing you may have had additional reasoning for selecting layout viewport origin in your draft -- anything I'm missing above?

I think the layout viewport origin is a better explanation for what's actually going on under-the-hood, the layout viewport is the scrolling content of the visual viewport. The document origin might be more convenient in some cases but I think it'll obfuscate the relationship of the two viewports.
More practically, using document-origin means that we then have to make choices about which viewport to scroll first when the developer writes to these properties. I think there are arguments for scrolling layout first and visual first in different scenarios. Without including the layout-origin coodinates the author has no way to choose.
I would rather we provide a utility somewhere to convert to document-origin or just include a polyfill since it's quite easy to go to document-origin from layout-origin.

We've been working on a polyfill and some examples and one of my findings working with this is that getting the properties of the layout viewport across browsers is not straightforward.
To get the layout viewport dimensions you need to:
Add a position: fixed; height:100%; width: 100% invisible element to the page and use getBoundingClientRect() to get its size.
To get the layout viewport scroll offset you need to:
Add a position: absolute; left: 0px; top: 0px; element and use getBoundingClientRect to get the negative of the layout viewport scroll offset.
This is somewhat clunky, though it works in Chrome/Edge/Firefox (working on Safari now). For that reason, I think I now agree that having document-relative coordinates in visualViewport is a good idea. It lets authors position elements using position: absolute without worrying about the layout viewport. For the reason I mention above, I think they should be read-only.
IMO, we should also keep scrollTop and scrollLeft relative to the layout viewport and keep those writable. In addition to being writable, I've found simulating position: device-fixed using a position: fixed element to be much smoother than position: absolute; when you're fully zoomed out, it looks perfect and you only get a bit of delay jank when you zoom in.
So, what do you think about adding visualViewport.pageX and visualViewport.pageY?

pageX/pageY should be in the latest canary and they've been added to the draft spec.


mv does not have a force mode

Currently, you cannot do a mv if the target key exists. I can easily add that functionality with a -f flag to the mv command; that's not really the issue I'm concerned about. What I am concerned about is placement.
In traditional UNIX, the options come before the args, so we'd end up with:
kvstore mv -f namespace oldkey newkey

But that goes against kvstore format where the namespace is ALWAYS the field after the command. We could break with tradition and allow
kvstore mv namespace oldkey newkey -f

which would be much easier on everyone's fingers; typically you'd type a mv command, see that it fails, do a command recall and then tack the -f on the end instead of having to arrow back or do some kind of other finger contortions to stick the -f up in the front of the recalled command. But, people might look at you weird (because it's your name on the software, not mine. :-) )
So, which way do you want me to code it - traditional options up front or radical options at end?

I would say traditional placement makes the most sense, and flags can be extracted by iterating through the args and capturing any that begin with -*.  We might want to do a parse expression at the beginning that sets variables like "$KVSTORE_COMMAND", "$KVSTORE_NS", "@KVSTORE_ARGS", "$KVSTORE_FLAG_F", etc to make this more standard

Hmm. We're going to have to push all option and args processing into each function. Each one will have different options and its probably best to let each one deal with what's valid for it and what's not.
Give me a few days to pull that together. Oh and I have gotten away from using getopt and getopts because you never know which one will be available, one of them doesn't process long strings and I can't stand that long opts need -- while short ones need -. I do my own processing and looping with only one real hard fast difference from regular processing: no single option ganging. So -f -t -x are ok but -ftx is not. Seems like a small price to pay.

Just a note. Real life has taken over for the next week or so. I'll let you know when I get a chance to work on this

No problem, I have been away as well, but whenever you have something ready I can review

mv STILL does not have a force mode. :-) But I have added some other commands, clearing the decks for adding the -f on the next pull. In the meantime, check out pull #7 .

Ugh - Totally forgot about this. It's on my disk ready to PR. I'll do this tonight (2017/09/07)

Pull #11 moves the options to start of command list, where they should be.

Added by https://github.com/ccarpita/kvstore/pull/11