sensorEndpoints error in App.config

The two sensorEndpoints in \GatewayService\Gateway\Microsoft.ConnectTheDots.GatewayService\App.config cause a dot net error on Raspberry Pi. Removing one fixes the error and the service will run on Raspberry Pi.

Thanks for sharing. Looks like the cause of error is identical names of this endpoints - i've changed second to 'LocalForSocket2'.
Please let me know if it does not help.

That works.


Automatic renewal of expired grant tokens

Make the package automatically renew the oauth token. This can be done by:

Before each request is sent to google, check if the token has expired or is revoked.
If it's expired, delete the saved token
Then initiate the google oauth process
Then save the new token
Finally complete the request.

Currently to deal with expired or invalid tokens, you have to manually delete the credentials.json file in the credentials folder.


MINOR: Upgrade ducktape to version 0.8.1

Sister PR to #9932
Ducktape 0.8.1 was updated to include the following changes/fixes from 0.7.x branch:

Junit reporting support
fix for an issue where unicode characters in exception message would cause test runner to hang on py27.

Please merge this to 2.7 also. 2.6 and below are on ducktape 0.7.x branch and #9932 is about those branches.

@andrewegel @omkreddy

@andrewegel @omkreddy

A few flaky test failures are not relevant to the changes.
Merging to trunk and 2.7

A few flaky test failures are not relevant to the changes.
Merging to trunk and 2.7

Thanks for review and backport! Changes to ducktape were simply a bugfix to move a bunch of code into the finally block to make sure it executes, so they shouldn't affect test results.

Thanks for review and backport! Changes to ducktape were simply a bugfix to move a bunch of code into the finally block to make sure it executes, so they shouldn't affect test results.


Component actions

Thanks for putting together this app.  it's been a great tool for understanding rxjs and dispatcher/store patterns in angular 1.5.
I was curious if you could comment on the reasoning for binding actions directly to the component templates.
For example, you have
<task-form create-task="tasks.actions.createTask(title)"></task-form>
vs.
<task-form></task-form>
and instead injection TaskActions and calling this.taskActions.createTask(this.title); in submit()
I was a bit confused by how it was wired, but assume there is a good reason for the approach.

It's generally a good idea to inject services into [smart/fat/stateful] components, and pass actions down to [dumb/skinny/stateless/presentational] components. With respect to forms, a basic form like the  can be treated as a dumb component.


Add node-gyp setup for NodeJS bindings

Kickstarter to setup node-gyp to build NodeJS bindings. This setup should be identical and ideally replace run.me. I have very little experience with c and c++, and I've expressed my questions as comments to the file. I've granted permissions to the forked repo contributors to edit this branch so please feel free to push fixes to the setup I've started.
I've modified the Github Actions workflow to see current build errors on CI

node-gyp is the standard NodeJS addon builder, maintained by NodeJS team. Link to user documentation if necessary https://gyp.gsrc.io/docs/UserDocumentation.md

I have very little experience with c and c++

It's all right. What is needed is understanding how does node.js/npm infrastructure works and what are common expectations from its users. run.me is just a proof-of-concept, and yes, ideally it should be superseded by something that is aligned with real-life workflows. Thanks for doing this!
Down to business. We have a two-sided coin. From one side we have node.js/npm users' expectations, and from the other side we have blst-specific build steps that can be at odds with node-gyp, most notably calling swig and compiling libblst.a. Natural expectation would be that it would be solved with custom build steps. Unfortunately referred documentation is silent about them. Is it so that it's simply undocumented, or is it totally unsupported? Can you tell?

Following binding.gyp appears to be sufficient to build build/Release/blst.node on Linux.
{
  'targets': [
    {
      'target_name': 'blst',
      'sources': [
        'blst_wrap.cpp',
        '../../src/server.c',
        '../../build/assembly.S'
      ],
      'include_dirs': [ '..' ],
      'cflags_cc': [ '-fexceptions' ],
    },
  ]
}

It naturally requires blst_wrap.cpp to be available. Which is not ideal, one wants custom build step to generate it. And it obviously won't work on Windows, because you can't use assembly.S. One can wonder if node-gyp supports file globs such as ../../build/win64/*-x86_64.asm, and if it can handle asm files at all...

I've added the ascetic version of binding.gyp and would suggest to re-purpose this PR (or open new one) to work on system-dependent parts. For now I've masked possible errors with || true in actions script, but it should be eventually removed. Till then we have to eye-ball the build log for errors...

@dot-asm Thanks for the feedback! Will investigate further or reach out to node-gyp devs.

It naturally requires blst_wrap.cpp to be available. Which is not ideal, one wants custom build step to generate it

A SWIG generated blst_wrap.cpp is particular for a NodeJS version AND platform, only NodeJS version or universal? Depending on the answer it can be considered to distribute pre-builts.

@dot-asm I've tested in this repo to build the SWIG file on multiple NodeJS versions and the result is the same. Is that expected? You can inspect the resulting files in the artifact binding.node
https://github.com/ChainSafe/blst-ts/actions/runs/368940698

A SWIG generated blst_wrap.cpp is particular for a NodeJS version AND platform, only NodeJS version or universal?

A given SWIG version generates same blst_wrap.cpp irregardless node.js version or platform. Question is if you can compile it for your node.js. This is the question that stands in the way for providing pre-generated wrapper. Because formally speaking user might have legitimate need to use specific SWIG version of their choice. As simplest example, Ubuntu 20 is fully self-consistent in sense that if you use vendor-provided node.js and vendor-provided SWIG, it works all the way. Yes, blst_wrap.cpp pre-generated with custom-patched SWIG version works with vendor-provided node.js too, but it's really circumstantial... And argument goes other way too. Output from next-next SWIG version can be absolutely preferred. What one can do is to query node --version, swig -version and fall back to a pre-generated blst_wrap.cpp for specific combinations. But it's not really appropriate to unconditionally use one for all occasions.

A SWIG generated blst_wrap.cpp is particular for a NodeJS version AND platform, only NodeJS version or universal?

A given SWIG version generates same blst_wrap.cpp irregardless node.js version or platform. Question is if you can compile it for your node.js. This is the question that stands in the way for providing pre-generated wrapper. Because formally speaking user might have legitimate need to use specific SWIG version of their choice. As simplest example, Ubuntu 20 is fully self-consistent in sense that if you use vendor-provided node.js and vendor-provided SWIG, it works all the way. Yes, blst_wrap.cpp pre-generated with custom-patched SWIG version works with vendor-provided node.js too, but it's really circumstantial... And argument goes other way too. Output from next-next SWIG version can be absolutely preferred. What one can do is to query node --version, swig -version and fall back to a pre-generated blst_wrap.cpp for specific combinations. But it's not really appropriate to unconditionally use one for all occasions.

Should we expect then that all javascript users of this library to have SWIG installed? I don't fully follow your answer; in what cases will the blst_wrap.cpp will be different?

in what cases will the blst_wrap.cpp will be different?

blst_wrap.cpp differs with the SWIG version. And there is no guarantee that blst_wrap.cpp generated with specific SWIG version will work with specific node.js version. Hence we can't provide pre-generated one, it's unmanageable in the long run. It would have to be something for users to keep up with, pushing us with emerging problems, as well as SWIG if it turns to be their problem. Like outstanding one in #32.

in what cases will the blst_wrap.cpp will be different?

blst_wrap.cpp differs with the SWIG version. And there is no guarantee that blst_wrap.cpp generated with specific SWIG version will work with specific node.js version. Hence we can't provide pre-generated one, it's unmanageable in the long run. It would have to be something for users to keep up with, pushing us with emerging problems, as well as SWIG if it turns to be their problem. Like outstanding one in #32.

In Lodestar context we cannot expect users to install SWIG. They should install node-gyp at most while we will try to provide pre.built bindings for as many OS x NodeJS combinations as we can. This is standard practice for other libraries such as https://github.com/sass/node-sass/releases

I would suggest to concentrate on the matter here, binding.gyp. Does it work on MacOS X? What does it take to make it work on Windows? First things first.

I managed to get binging.gyp work on Windows, see 0f91a054be939e2b0213a356c9cf7c2319817371. At least on my virtual computer. This last sentence means that I don't really have confidence that it would work universally. Trouble is that when you install node.js, it asks if you want to install additional development tools, and it looks like it's installing some compiler components. But since I have even newer Visual Studio installed, it might end up using that one, and it might happen that it's the one that actually works. In which case me successfully building it isn't actually reassuring that it would work on a computer without newer or full-blown Visual Studio installation. In other words, feedback would be appropriate;-) As well as from Mac...

I managed to get binding.gyp work on Windows, see 0f91a05. At least on my virtual computer. This last sentence means that I don't really have confidence that it would work universally. Trouble is that when you install node.js, it asks if you want to install additional development tools, and it looks like it's installing some compiler components. But since I have even newer Visual Studio installed, it might end up using that one, and it might happen that it's the one that actually works. In which case me successfully building it isn't actually reassuring that it would work on a computer without newer or full-blown Visual Studio installation. In other words, feedback would be appropriate;-) As well as from Mac...

Thanks for pushing this :heart: I've rebased this branch on top of your work and setup a Github Action to test the node-gyp file on ubuntu-latest, macos-latest, windows-latest.
In macos-latest, windows-latest SWIG fails to be set up. Do you know how would it be setup in those environments?

In our blst-ts wrapper I build blst_wrap.cpp first in ubuntu only and then run node-gyp on all 3 OS. However the build still fails. You can see the failures per OS
macos-latest
Seems a build error that I can't understand what's the exact problem
https://github.com/ChainSafe/blst-ts/pull/10/checks?check_run_id=1466839643
windows-latest
Apparently it builds fine gyp info ok but the blst.node file is not there
Error: Cannot find module 'blst'

I'll check if the path is different for windows
https://github.com/ChainSafe/blst-ts/pull/10/checks?check_run_id=1466839667

macos-latest
Seems a build error that I can't understand what's the exact problem

It's the error: lines from compiler that we should concentrate on in first hand. And it looks like node-gyp doesn't pass down cflags_cc on MacOS. This ought to be problem with node-gyp. Question is if it's version specific, and/or if it's known problem, or maybe even intentional. It may not be the latter, because we're entitled for custom flags on MacOS exactly as much as on other OSes. And it does work on Linux, and it did work for me on Windows...

windows-latest
Lower NodeJS versions fail. I can't understand the build error as it doesn't seem to contain much info

windows-latest: 10-11: X

Hmm... Note that first error from compiler points at v8.h. It's as if the node.js header file is broken. It's unlikely to be the case, so one should wonder if one can actually use blst_wrap.cpp generated by patched swig with node.js 10.x. At the very least I know following. Ubuntu 20 is equipped with node.js 10.x by default and stock swig 4.0.1, and they do work together. I can check if I can intermix on Ubuntu, but don't hold your breath that it will yield solution for Windows.
Secondly, it issues "C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc" warning. This is Windows equivalent of -fexceptions, except that it's a warning, not a fatal error. But node-gyp is supposed to pass it, so apparently same problem as with MacOS? I get v7.1.2 if I execute node-gyp --version...
Just in case, there are also warnings about cast between 'void *' and 'long'. Those are "safe" to ignore. "Safe" in sense that corresponding interfaces are not supposed to be used in real-life scripts, those are debugging artefacts.

In macos-latest, windows-latest SWIG fails to be set up. Do you know how would it be setup in those environments?

I never tried, so I can't say that I know. If I had to guess, first I'd wonder if there is equivalent of Linux autoconf available... Though on Windows it might be something completely different. Either way, I'd also say that as long as you can compile one on Linux, generate wrapper and copy, it's just as good. Modulo fact that SWIG and node versions are compatible that is...

Was I dreaming? Didn't https://gyp.gsrc.io/docs/UserDocumentation.md mention cflags_cc? It doesn't now...

There is another update to binding.gyp committed. Based on combing through node-gyp source code. Check it out.
I don't understand why they did it that way. Normally you'd want to provide a unified way to control compilation on multiple platforms, but node-gyp seems to encourage the division among developers...

I can check if I can intermix [blst_wrap.cpp generated by patched swig with older node.js] on Ubuntu.

I can. Moreover, I can intermix them on my Windows [virtual] machine. So that failure on Github Actions is a mystery.

Was I dreaming? Didn't https://gyp.gsrc.io/docs/UserDocumentation.md mention cflags_cc? It doesn't now...

100%  cflags_cc is a thing, I've used it hahaha no clue why would it disappear.

Not sure if you could provide any help, but in our wrapper the bindings tests for macos-latest NodeJS version 11 very often fail with
error Command failed with signal "SIGABRT".

https://github.com/ChainSafe/blst-ts/pull/14/checks?check_run_id=1469860354#step:6:64
There is no more info nor logs. It's very strange because it happens in NodeJS v11 exclusively and only sometimes...

Thank you so much for the fixes! :heart:  Now node-gyp works for all macos-latest nodejs versions

I can. Moreover, I can intermix them on my Windows [virtual] machine. So that failure on Github Actions is a mystery.

Have you tried with NodeJS v10 in your Windows virtual machine?

I can. Moreover, I can intermix them on my Windows [virtual] machine. So that failure on Github Actions is a mystery.

Have you tried with NodeJS v10 in your Windows virtual machine?

Yes, that's what I actually meant to say. [Just in case, reference to "virtual" merely means that it's not my platform of choice, and as result I might fail to recognize common problems that would appear obvious to others, or fail to tell if there is anything special about my setup that does any specific trick.]

I can. Moreover, I can intermix them on my Windows [virtual] machine. So that failure on Github Actions is a mystery.

Have you tried with NodeJS v10 in your Windows virtual machine?

Yes, that's what I actually meant to say. [Just in case, reference to "virtual" merely means that it's not my platform of choice, and as result I might fail to recognize common problems that would appear obvious to others, or fail to tell if there is anything special about my setup that does any specific trick.]

Yeah I'm on the same boat, haven't used Windows in +15y and recently only through Github Actions :v:

Not sure if you could provide any help, but in our wrapper the bindings tests for macos-latest NodeJS version 11 very often fail with
error Command failed with signal "SIGABRT".

Can you reproduce it on your computer? Common way to troubleshoot such problems is to start application under debugger, crash it and collect stack back-trace...
But I don't quite understand. It says SIGABRT in the middle of what appears to be a line of successful tests. Is it correct impression? If so, is it like there are multiple scripts executed one after another, and crash is observed as some particular script finishes? If so, I'd first wonder if there are some subtleties in memory management that might have to be mitigated in blst.swg. Or it might as well happen that this is how incompatibilities between swig and node versions manifest themselves... One can wonder what happens if you take blst_wrap.cpp generated by swig 4.0.1, which does support node pre-v12. It should also be noted that blst_wrap.cpp compiles with warnings, and they might give a clue [which might turn to be swig's problem]. But aren't odd node.js version kind of "throwaway"-s? I mean they are maintained only for short times and serve as kind of playground for new features? In other words, if the problem is actually specific to v11 and nothing else, then it might be appropriate to ignore?

Now node-gyp works for all macos-latest nodejs versions

Cool! And now binding.gyp has a custom action and template blst_wrap.py script. I assume that binging.gyp doesn't actually have to reside where it is. For example you might be able to copy it to location of your choice, re-bias relative paths and so to say "take over"...

Can you reproduce it on your computer?

I don't own any MacOS so unfortunately not. For my own Linux it does not happen.

But aren't odd node.js version kind of "throwaway"-s? I mean they are maintained only for short times and serve as kind of playground for new features? In other words, if the problem is actually specific to v11 and nothing else, then it might be appropriate to ignore?

Yeah, this can be totally ignored and users should not be using this version anyway. Just checking if you had any idea. If the error is persistent I will just drop support for macos-node11

I assume that binging.gyp doesn't actually have to reside where it is. For example you might be able to copy it to location of your choice, re-bias relative paths and so to say "take over"...

Since I'm referencing supranational/blst as git submodule I would rather not have to modify anything for the convenience of just pulling changes easily. I'm down to push any setup changes upstream so everyone can benefit from an improving setup

I've rebased to current master and modified the CI workflow to build with SWIG once and re-use the result for ubuntu, macos and windows

Template version detection in blst_wrap.py was updated. "Template" means that it won't run as it stands now(*), and intention rather is that it will be taken for deployment off-tree. Problem with using it in-tree is that actual node.js users such as yourself, @dapplion, are in better position to catch and, more importantly, assess problems. After which you can tag @supranational(**) from your repo, or file an issue here. Note that this is not about shifting the burden of problem solving, but rather about how it's communicated:-)
(*) it takes removal of one line;
(**) should work, and if it doesn't, it should be fixed.

Template version detection in blst_wrap.py was updated. "Template" means that it won't run as it stands now(*), and intention rather is that it will be taken for deployment off-tree. Problem with using it in-tree is that actual node.js users such as yourself, @dapplion, are in better position to catch and, more importantly, assess problems. After which you can tag @supranational(**) from your repo, or file an issue here. Note that this is not about shifting the burden of problem solving, but rather about how it's communicated:-)
(*) it takes removal of one line;
(**) should work, and if it doesn't, it should be fixed.

Thank for providing the python script! Could you let me know how to run it in our case? I can't manage to execute SWIG nor any output gets printed out. I may be missing something

Could you let me know how to run it in our case?

You're not supposed to run it for yourself, node-gyp will invoke it for you. First thing it tries is to spot swig 4 or later on your $PATH. It's assumed that it would be "the right one," i.e. patched version for node v12 and forward, or stock 4.0.x for node v10 (and presumably earlier, at least v8 worked for me on Ubuntu 18). If it fails to locate swig 4, and "do something else" line is commented out, it will execute node --version and depending on output will choose between two pre-generated versions, blst_wrap.v12.cpp and blst_wrap.v8.cpp, in the same directory as blst_wrap.py script itself, to "feed" to node-gyp.
If you wish, I can try to put together a pull request to blst-ts...

Could you let me know how to run it in our case?

You're not supposed to run it for yourself, node-gyp will invoke it for you. First thing it tries is to spot swig 4 or later on your $PATH. It's assumed that it would be "the right one," i.e. patched version for node v12 and forward, or stock 4.0.x for node v10 (and presumably earlier, at least v8 worked for me on Ubuntu 18). If it fails to locate swig 4, and "do something else" line is commented out, it will execute node --version and depending on output will choose between two pre-generated versions, blst_wrap.v12.cpp and blst_wrap.v8.cpp, in the same directory as blst_wrap.py script itself, to "feed" to node-gyp.
If you wish, I can try to put together a pull request to blst-ts...

Oh I see! Now I see the action in the node-gyp file. The purpose of this PR is never meant to be merge but to easily verify that the configuration works. What we have on blst-ts is very similar to what's in blst-ts. If you want you can open a PR there or just commit to this branch that's closer to your repo. You should be able to commit on top of it.
In blst-ts CI I experience the same error as here https://github.com/supranational/blst/pull/43/checks?check_run_id=1501254076#step:7:46
I'm not sure if node-gyp swallows the errors from the python script but I don't see any clear error in the logs

Sorry about the delay. So node v10 build on Windows fails again. As already mentioned, it looks as if headers are corrupted. We'll have to see if it depends on node's minor version number...

Microsoft blip blip bliiiiiiiiiiiiiippppp bllllliiiiiiiiiiiiiiiiiippppppppppp blip.... Blip blip! Blip... I mean COME blip-ing ON! "We support c++14." Then why don't they predefine freaking __cplusplus accordingly? Like blip-ing everybody else?

"We support c++14."

Not that I have access to actual standard, but all the drafts stipulate that __cplusplus "shall be defined" and as value reflecting the standard, at least 201103L for contemporary ones. In other words, chances are that Microsoft does not comply.

Microsoft blip blip bliiiiiiiiiiiiiippppp bllllliiiiiiiiiiiiiiiiiippppppppppp blip.... Blip blip! Blip... I mean COME blip-ing ON! "We support c++14." Then why don't they predefine freaking __cplusplus accordingly? Like blip-ing everybody else?

hahaha, totally justified market share...

The files

bindings/node.js/blst_wrap.v8.cpp
bindings/node.js/blst_wrap.v12.cpp

Are generated by you locally? Could both be generated on CI on this PR?

After adding blst_wrap.py the idea is to generate blst_wrap*.cpp with node-gyp in one step without run.me right? Would that CI step work using node-gyp only?

After adding blst_wrap.py the idea is to generate blst_wrap*.cpp with node-gyp in one step without run.me right? Would that CI step work using node-gyp only?

I'd argue there is value in exercising both, because it allows to tell apart node-gyp-specific problems. I mean if run.me succeeds, you know it's something with node-gyp. Though it might make sense to separate the steps, so that one knows which log file to look at from single glance...

The files

bindings/node.js/blst_wrap.v8.cpp
bindings/node.js/blst_wrap.v12.cpp

Are generated by you locally?

Yes.

Could both be generated on CI on this PR?

First of all, why two files. If you test v12 file, you can find that it actually works even with earlier node versions, so why bother with v8 at all. Well, v12 is generated by unofficial patched version, so that formally speaking it's "not there." But as soon as swig catches up and specifies which node versions are supported by new version, it might be possible to switch to single pre-generated wrapper. Now, with this in mind, is it possible to generate them in Github Actions? Should be possible if one gets creative enough. The v8 file was generated on Ubuntu 20 with stock swig 4.0.1. So I suppose if one spins up ubuntu-20 image instead of ubuntu-latest(*), one can generate v8 as is, and then v12 with ~/swig/bin on modified $PATH...
(*) Though they plan switch ubuntu-latest to ubuntu-20 soon.

@dot-asm Thank you! I'm trying to replicate this setup in blst-ts but I can't get blst_wrap.py to work, I'm not sure why it doesn't find ./blst_wrap.v12.cpp
This is the CI run with the error https://github.com/ChainSafe/blst-ts/pull/19/checks?check_run_id=1530028228#step:8:46

@dot-asm Would you mind pushing this fix to master so I can update our git submodule? https://github.com/supranational/blst/pull/43/files#diff-7009d5c1156c3b0d41aff8545e89c58b863b63fae7286c43e1f5a4bf066bdf97R28
I confirm it fixes the build issues in windows node 10,11 so thank you so much!! :heart: :tada:

As already mentioned/implied, I'm opposed to the idea of keeping pre-generated wrappers in the main tree. It's not sustainable in long run.

As already mentioned/implied, I'm opposed to the idea of keeping pre-generated wrappers in the main tree. It's not sustainable in long run.

I agree, the idea is to generate those on CI and distribute them over NPM but not to keep them in src. Also since blst-ts references supranational/blst as a submodule I would like not to do any modification at all (like moving blst_wrap.py around) since it makes it harder to track. Do you think this is a good strategy to wrap your src or maybe there's a better path?

I've bumped supranational/blst git submodule in our repo and I'm unable to build with node-gyp on any OS https://github.com/ChainSafe/blst-ts/pull/13/checks?check_run_id=1553743489#step:5:112
I see your note in binding.gyp about customizing the files but I believe the optimal strategy is that the upstream repo works without any modifications while we continue to use git submodules.
blst_wrap.py will run swig even if it finds a blst_wrap.py file?

But let me pick your brain. I'd expect to find references to bingings.gyp or a build script in package.json. I see reference to dist/scripts/install.js, but where is it? If it's generated from src/scripts/install.ts, then install procedure doesn't look at package.json? At least not at first? In such case why have it at all? Is it correct understanding that installation procedure will try to download blst.node binary, and if suitable is not found, it will try to build from source? If so, why not attempt to download blst_wrap.cpp prior build attempt?

Are there environment variables set by any of the building tools involved? The reason I ask is that if there is one pointing at your project root, it might be appropriate to have blst_wrap.py look for pre-generated wrappers in a directory relative to your root. If no variable is set, we can just make one up, and you can set it in build script...

If no variable is set, we can just make one up, and you can set it in [your] build script...

We can choose to specify directory where to look for blst_wrap.v*.cpp, or we can simply appoint the file. As simplest example blst_wrap.py could see if blst_wrap.cpp environment variable is set and attempt to copy $blst_wrap.cpp to destination chosen by node-gyp. [I naturally mean Python-specific expression of "copy $blst_wrap.cpp."]

As simplest example blst_wrap.py could see if blst_wrap.cpp environment variable is set...

One can also argue that $blst_wrap.cpp should have highest priority and override call to swig...

Thanks for the explanation! I've successfully integrated latest master into blst-ts, and it works fine for all OS and NodeJS versions including windows-latest node v10. Also worker-threads work fine.
I've opened a PR with the updated blst_wrap.py https://github.com/supranational/blst/pull/48

Given that the blst_wrap.cpp works fine for all environments I will skip generating two versions (v12, v8 you proposed). Let me know if you forsee and issue with that.

But could you walk me through your "behind-the-scene" build procedure? This is for general education...

But could you walk me through your "behind-the-scene" build procedure? This is for general education...

If you refer to the CI runs to get prebuilds:
Run 1 job build-swig for ubuntu-latest + NodeJS 12

Run yarn boostrap which builds the typescript scripts that call node-gyp
Upload resulting blst_wrap.cpp as a workflow artifact

Run matrix job build for all OS and Node versions

Download blst_wrap.cpp from workflow artifact
Run yarn boostrap which builds the typescript scripts that call node-gyp
Upload resulting *.node as a workflow artifact

The Typescript scripts main logic is here https://github.com/ChainSafe/blst-ts/blob/master/src/scripts/install.ts which tries in order

Find existing *.node binding in FS
Download *.node binding from that specific version Github release assets
Run node-gyp. It also tells blst_wrap.py if prebuild blst_wrap.cpp was found and where

Let me know if that answers your question

Closing to now pollute the repo since the purpose of this PR is fulfilled :)

If you refer to the CI runs to get prebuilds:

The interest is more general than that:-)

Run 1 job build-swig for ubuntu-latest + NodeJS 12

Run yarn boostrap which builds the typescript scripts that call node-gyp

Is it correct understanding that "bootstrap" is a reference to the "bootsrap" line in package.json? Then the "bootsrap" line in package.json calls yarn build. Is it correct understanding that this "build" is a reference to the "build" line in package.json? Which simply calls tsc. Which in turn looks into tsconfig.json to figure out what to do, right? I.e. traverse src and transcompile everything to javascript and populate dist directory. And it would be the last yarn install that would look at the "install" line in package.json and ultimately have node execute node-gyp...
Some additional questions.
Is src/bindings.ts file manually composed? If so, question is how do we keep it up to date with blst.hpp as it evolves. Best would be if we had a copy to play with in blst/bindings/node.js, along with an ascetic sanity test. This way we can make changes at own pace, ensure that they are syntactically correct, and then ping you for feedback and integration. Can you help with this? The ascetic test that is. No rush:-)
I've tried to simply run tsc in blst-ts directory and got a bunch of errors. I assume this is because my tsc might be too old. At least partially, as I didn't run any yarn commands. Anyway, I have tried tsc that comes with Ubuntu 20, 3.8.3, while package.json mentions 4.0.3. Is it correct assumption? Is it possible to have the above mentioned mini-test less dependent on tsc version? In other words working with stock Ubuntu 20:-)

Is it correct understanding that "bootstrap" is a reference to the "bootsrap" line in package.json? Then the "bootsrap" line in package.json calls yarn build. Is it correct understanding that this "build" is a reference to the "build" line in package.json? Which simply calls tsc. Which in turn looks into tsconfig.json to figure out what to do, right? I.e. traverse src and transcompile everything to javascript and populate dist directory. And it would be the last yarn install that would look at the "install" line in package.json and ultimately have node execute node-gyp...

Yeah that's exactly what's going on. They key thing here is that for regular users that consume, dist will already be there and by convention npm or yarn will call the install script and the last step of the installation. So when doing
yarn add @chainsafe/blst

it pulls the build content from NPM and runs the install script afterwards

Is src/bindings.ts file manually composed? If so, question is how do we keep it up to date with blst.hpp as it evolves. Best would be if we had a copy to play with in blst/bindings/node.js, along with an ascetic sanity test. This way we can make changes at own pace, ensure that they are syntactically correct, and then ping you for feedback and integration. Can you help with this? The ascetic test that is. No rush:-)

Yes it's manually composed. Right now there are tests for every single method to ensure they exist and take those specific arguments. I can help with it of course. Do you think current blst-ts as-is is a good starting point?

I've tried to simply run tsc in blst-ts directory and got a bunch of errors. I assume this is because my tsc might be too old. At least partially, as I didn't run any yarn commands. Anyway, I have tried tsc that comes with Ubuntu 20, 3.8.3, while package.json mentions 4.0.3. Is it correct assumption? Is it possible to have the above mentioned mini-test less dependent on tsc version? In other words working with stock Ubuntu 20:-)

If you just run tsc it may pick a globally installed version different than the project's. You can either do
./node_modules/.bin/tsc

or
npx tsc

To run the project's tsc version

I can help with it of course.

Cool! Thanks!

Do you think current blst-ts as-is is a good starting point?

Well, I, a typescript illiterate, am not exactly right person to ask:-) There were some additions to blst.hpp recently, but it would be good exercise for me to add them. So yes, let's go with what you've got as starting point.

If you just run tsc it may pick a globally installed version different than the project's.

Oh! There is per-project culture... Well, in my mind it's only more reasons to aim for previous version:-) For the intended purposes minimalistic test could simply perform syntax analysis, say with tsc --noEmit bindinings.ts. Is it possible? Having a kind of full project structure feels superfluous...

Oh! There is per-project culture... Well, in my mind it's only more reasons to aim for previous version:-) For the intended purposes minimalistic test could simply perform syntax analysis, say with tsc --noEmit bindinings.ts. Is it possible? Having a kind of full project structure feels superfluous...

You can always run tsc --version and make sure you running a newer version. blst-ts uses 4.0.3, update and it would be fine.

Having a kind of full project structure feels superfluous...

If you can accept two json files with 4 lines total this is the minimal thing I could came up with
https://github.com/supranational/blst/pull/49


Feature/match publish

@Payne680 ??

Please always fill a description conform to the repo rules when you're calling for PR please


fixes ifndef test in Makefile

Fixes https://github.com/edgexfoundry-holding/edgex-cli/issues/138
Signed-off-by: Malini Bhandaru<EMAIL_ADDRESS>

LGTM


Fixed #29492 -- Improved compilemessages speed with multithreading.

I know for sure that collectstatic could benefit from something similar to speed up collection and post-processing so it might be worth investigating if there's something we could define on BaseCommand to prevent code duplication in the future.

Simon, your remark makes sense, for sure. I'll still commit this one in the current state, which shouldn't prevent any refactoring later.
It's also possible that shared utilities might be more async-oriented than multithread-oriented. To be explored!


[Proposal]: Improve ScreenGear capture rate using DXcam (Windows)

Brief Description

While mss and pil are capable of decent capture rates, the rate can be greatly improved using DXcam.
DXcam uses the Windows Desktop Duplication API.
Context

Allowing faster capture rates would allow vidgear to capture video game input far more accurately. I was able to achieve capturing frames > 90 fps average as compared to ~30 fps using mss or Pillow.
Your Current Environment

VidGear version:  0.2.5
Branch:  PyPi
Python version: 3.9.6
Operating System and version: Win 11

@ReenigneArcher Thanks. This looks promising! I'll run some tests and let you know soon.

I don't mean to spam your repo, but I am highly interested in vidgear as it seems like an awesome library with a lot of potential. I'll just put this here for now, although it's a slightly different topic. I can open it in a separate issue/proposal if you prefer.
I've also been looking into screen capture with ffmpeg. I'm not sure how good the performance is as of yet. One advantage is that initial testing (from command line only) actually captures the mouse movement (on windows) which is probably worth investigating it further just for that reason. https://trac.ffmpeg.org/wiki/Capture/Desktop
I've used ffmpy for re-encoding videos in python before, but not yet for screen capture or piping the output.
There's another library that looks interesting for handling ffmpeg streams as well (https://pypi.org/project/python-ffmpeg-video-streaming/). I wasn't able to get it to work but I didn't put in too much effort honestly.

I've also been looking into screen capture with ffmpeg. I'm not sure how good the performance is as of yet. One advantage is that initial testing (from command line only) actually captures the mouse movement (on windows) which is probably worth investigating it further just for that reason. https://trac.ffmpeg.org/wiki/Capture/Desktop

That's why I'm working on deffcode. It will replace OpenCV here.

@ReenigneArcher DXcam cannot employed as ScreenGear backend untill unless https://github.com/ra1nty/DXcam/issues/17 is resolved. Also, we'll have to wait untill DXcam becomes stable. I'll reopen this issue when these problems are fully addressed by DXcam author(s).

Okay, thanks for the update.
You can also install without the test pypi repo.
python -m pip install git+https://github.com/ra1nty/DXcam.git@cd1c36783d206027075309d7a9be89ef5099d10a#egg=dxcam
or latest:
python -m pip install git+https://github.com/ra1nty/DXcam.git@main#egg=dxcam
If you use poetry instead of pip, it's also possible to install directly from git.

Hi @abhiTronix , pypi has been release on pypi:  https://pypi.org/project/dxcam/0.0.5/
We fixed all the known issues and I can say it's relatively stable now.

@ReenigneArcher @ra1nty This issue is resolved on my local machine, and it is working great 😃. But until  https://github.com/ra1nty/DXcam/issues/45 is resolved, the changes cannot be made.

Fantastic news. Thank you for your efforts!


I continue with tearing :(

I tried anything but in my gnome shell, I have tearing when I use freshplayer plugin, I tried "exp_enable_3d = 1
" but this don't affect to my system.

Yep, there were no changes related to tearing both recently and at whole project duration time. I digged into the issue, but it seems tearing is a very hard problem which have no well-known solution. I plan to experiment with some DRI2-related technique, and post update here after that. But I don't know when it would be.
As for "exp_enable_3d", this option doesn't exist anymore, it was renamed to "enable_3d". Rename reason was enabling it by default, but since then I disabled it again. So the only visible change is naming/

(related: #96, #74)

I had little bit flickering with "enable_3d = 1", or then it's really bad tearing :D
I'm using nvidia gpu (gtx560ti) with latest non-free drivers

You can try compton, various backends and vsync methods.
On my machine compton --backend glx works great, till some fullscreen OpenGL application launchs, which freezes graphics completely. Although compton --backend xrender --vsync opengl seems to be working fine.

There's no way to fight tearing inside application. As plugin model assumes all instances do drawing in one thread one after another, waiting for vsync makes no sense. There would be enormous lags.


Make use of lock.withLockVoid to simplify code

Motivation:
We should make use of lock.withLockVoid to simplify our code and make it more robust.
Modifications:
Replace manual lock() / unlock() calls by withLockVoid(...)
Result:
Code is cleaner and easier to understand.

@normanmaurer generally this is a good idea but I suspect that this will cause allocations. Would you mind checking that? It's quite possible we need to add a @_inlinable to the func withLock

So I debugged it with @weissi and we needed to add the @_inlinable to ensure we not do an extra allocation. This will also help in other places where we use withLock*.

@weissi PTAL again to verify it.


refactor(step-1) remove cluster related stmt

Proposed changes
Issue Number: close #xxx
Problem summary
Cluster is deprecated since 0.14.
It is time to remove it.
This is the step 1: remove related stmt:

create
drop
alter
link
migration

Checklist(Required)

[ ] Does it affect the original behavior
[ ] Has unit tests been added
[ ] Has document been added or modified
[ ] Does it need to update dependencies
[ ] Is this PR support rollback (If NO, please explain WHY)

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall

TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 33.23 seconds
stream load tsv:          421 seconds loaded<PHONE_NUMBER>9 Bytes, about 169 MB/s
stream load json:         25 seconds loaded<PHONE_NUMBER> Bytes, about 89 MB/s
stream load orc:          58 seconds loaded<PHONE_NUMBER> Bytes, about 18 MB/s
stream load parquet:          30 seconds loaded 861443392 Bytes, about 27 MB/s
https://doris-community-test-1308700295.cos.ap-hongkong.myqcloud.com/tmp/20230507021935_clickbench_pr_139665.html

run buildall


Lowercase custom header

Background
This ensures that if a custom server-side header value is set authentication still works. Currently on master requests fail if a custom header value is set to a string with capital letters. See the linked issue for additional background. If this patch is accepted I'll update the docs.
Fixes #218.
Test steps

Add an example header key with "Example-Header" to the example app.

Create a new token by making a POST request to /auth/local with the default user credentials.

Use that token with to make a request to /messages.

[ ] Verify that you are able to authenticate with a capitalized header (Example-Header).
[ ] Verify that you are able to authenticate with a lowercase header (example-header).

I thought that the body-parser module automatically converted them to lowercase.  I think we definitely want this if it's not happening already.

The body-parser module doesn't touch the headers.

Well, see what I know? :)  Whichever module it is, I’ve not seen an uppercase header in node.

On Jun 3, 2016, at 4:24 PM, Joshua Jabbour<EMAIL_ADDRESS>wrote:
The body-parser module doesn't touch the headers.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/feathersjs/feathers-authentication/pull/219#issuecomment-223709174, or mute the thread https://github.com/notifications/unsubscribe/AAH3WTL0tLnojWFlZfFSbRpxcAWZMP_Sks5qIKmtgaJpZM4It5dl.

Yeah, node itself does the lowercasing iirc. So yes, Feathers should def also do the same.

Yep, node: https://nodejs.org/api/http.html#http_message_headers :)

@mmwtsn 👍 awesome! Would you be able to add a quick test in auth to make sure that headers are being lower cased?

@ekryski thanks! I pushed up a commit lowercasing the client-side header as discussed in https://github.com/feathersjs/feathers-authentication/issues/218#issuecomment-223716099 as well as a test for the capitalized header bug. Without .toLowerCase() the test fails.
I opened up a pull request to update the docs accordingly once this is merged.

Thanks again! This has just been released in v0.7.8


Prepare release for v1.0.6

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 94.118%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
43

Relevant Lines:
45

💛  - Coveralls


Над данным кодом ещё идет обработка https://trashbox.ru/files30/1084489/net

От КЕНТ

Хорошо главное не забыть написать код спс)))

Islyan kod gerek https://doh-2.seby.io/dns-query buu islenok

пожалуйста по быстрее мне срочно нужен новый код

Gayrat edin isleyan kod berayin
чт, 22 окт. 2020 г., 22:09 enegulrahmanova<EMAIL_ADDRESS>
пожалуйста по быстрее мне срочно нужен новый код
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Jigsaw-Code/Intra/issues/303#issuecomment-714634604,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQZPKIAEJ2XR3NEPXGRQ7ZLSMBRNDANCNFSM4S2XNFYA
.

https://trashbox.ru/files30/1084489/net
почему не работайет этот код

Hany kod tayyn bolmadymy

Manada bersenizlan kody cyksa

sol kod kabir telde isleya yone menda islanok
пт, 23 окт. 2020 г., 9:08 AM Oraz<EMAIL_ADDRESS>
Manada bersenizlan kody cyksa
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Jigsaw-Code/Intra/issues/303#issuecomment-714896535,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AROTBE4VX5VELWYDG47YEGTSMD6SHANCNFSM4S2XNFYA
.

Mendede islanokda sho, yada obrabotkasy gutaryanca garashmalymy?

owa  garash bolmasada Z-VPN isleya
пт, 23 окт. 2020 г., 9:12 AM Oraz<EMAIL_ADDRESS>
Mendede islanokda sho, yada obrabotkasy gutaryanca garashmalymy?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Jigsaw-Code/Intra/issues/303#issuecomment-714897766,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AROTBE2OBV4LMXEE5GLY3U3SMD7BXANCNFSM4S2XNFYA
.

z vpn dp yazdym velin uc dort sany cykdyda haysysy bulan
пт, 23 окт. 2020, 9:13 sehmus1042<EMAIL_ADDRESS>
owa garash bolmasada Z-VPN isleya
пт, 23 окт. 2020 г., 9:12 AM Oraz<EMAIL_ADDRESS>
Mendede islanokda sho, yada obrabotkasy gutaryanca garashmalymy?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/Jigsaw-Code/Intra/issues/303#issuecomment-714897766
,
or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/AROTBE2OBV4LMXEE5GLY3U3SMD7BXANCNFSM4S2XNFYA
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Jigsaw-Code/Intra/issues/303#issuecomment-714898233,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ARPNV5B4IGPJIM45SE4IP2DSMD7H7ANCNFSM4S2XNFYA
.

Kod berayinda islanoga bul

ay sho koda bizede gerek
пт, 23 окт. 2020, 15:12 mayajyk<EMAIL_ADDRESS>
Kod berayinda islanoga bul
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Jigsaw-Code/Intra/issues/303#issuecomment-715245696,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ARPNV5ECGMFHW7SOBI6FA2LSMFJHRANCNFSM4S2XNFYA
.

Mmm🙄
23 Eki 2020 Cum 15:13 tarihinde Oraz<EMAIL_ADDRESS>şunu yazdı:

ay sho koda bizede gerek
пт, 23 окт. 2020, 15:12 mayajyk<EMAIL_ADDRESS>
Kod berayinda islanoga bul
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/Jigsaw-Code/Intra/issues/303#issuecomment-715245696
,
or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/ARPNV5ECGMFHW7SOBI6FA2LSMFJHRANCNFSM4S2XNFYA
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Jigsaw-Code/Intra/issues/303#issuecomment-715246645,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ARJR67Y4B7W4JIH2C2L3XW3SMFJOFANCNFSM4S2XNFYA
.

Reply to this email directly, view it on GitHub
<
https://github.com/Jigsaw-Code/Intra/issues/303#issuecomment-715245696
,
or unsubscribe
<

https://github.com/notifications/unsubscribe-auth/ARPNV5ECGMFHW7SOBI6FA2LSMFJHRANCNFSM4S2XNFYA

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/Jigsaw-Code/Intra/issues/303#issuecomment-715246645
,
or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/ARJR67Y4B7W4JIH2C2L3XW3SMFJOFANCNFSM4S2XNFYA
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Jigsaw-Code/Intra/issues/303#issuecomment-715265368,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ARORXFOYZ5SL76IOKWJ2IN3SMFNUTANCNFSM4S2XNFYA
.

Reply to this email directly, view it on GitHub
<
https://github.com/Jigsaw-Code/Intra/issues/303#issuecomment-715245696
,
or unsubscribe
<

https://github.com/notifications/unsubscribe-auth/ARPNV5ECGMFHW7SOBI6FA2LSMFJHRANCNFSM4S2XNFYA

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<
https://github.com/Jigsaw-Code/Intra/issues/303#issuecomment-715246645
,
or unsubscribe
<

https://github.com/notifications/unsubscribe-auth/ARJR67Y4B7W4JIH2C2L3XW3SMFJOFANCNFSM4S2XNFYA

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/Jigsaw-Code/Intra/issues/303#issuecomment-715265368
,
or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/ARORXFOYZ5SL76IOKWJ2IN3SMFNUTANCNFSM4S2XNFYA
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Jigsaw-Code/Intra/issues/303#issuecomment-715296908,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ARJR676QSBL42JXM26UOAXLSMFVOTANCNFSM4S2XNFYA
.

Taze tapdinzmi kod

вс, 25 окт. 2020 г., 1:24 PM Elyas77<EMAIL_ADDRESS>
Taze tapdinzmi kod
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Jigsaw-Code/Intra/issues/303#issuecomment-716111120,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AROTBE3HPUNNDES6QMZ4D43SMPODDANCNFSM4S2XNFYA
.


[IGA] Preprocessor extension to support Isogeometric AnaLysis

Extension to implement:
Entities

Control Points (Parametric/Cartesian)
Knots
NURBS Elements
Bezier Elements

Model for IGA

Subdomains extended to include Patches
Element -> Supportive -> Gauss Quadrature for more than 3 points
Readers -> Implement Reader for IGA

Problem

Isogeometric

Extension of the functionality to read various formats of geometry input files (IGES etc).


Add .custom option to AuthorizationType of AccessTokenPlugin

Description
This PR adds a .custom option to the AuthorizationType of the AccessTokenPlugin, which enables to specify a custom header field and a custom token prefix.
// Examples:
.custom(headerField: nil, tokenPrefix: "JWT")
// will result in this header 'Authorization: JWT <token>'

.custom(headerField: "X-Access-Token", tokenPrefix: nil)
// will result in this header 'X-Access-Token: <token>'

Motivation
I recently used Moya in a project of mine and the backend it interacts with requires me to use x-access-token as header field and it also requires that only the token value is set as value in that header. I was about to create a CustomAccessTokenPlugin in my project, but I thought that there might be other developers who are in a similar situation, so I created this PR instead.
Please let me know what you think and if you require any changes :)

          1 Warning

:warning:
Any changes to library code should be reflected in the Changelog. Please consider adding a note there and adhere to the Changelog Guidelines.

  Generated by :no_entry_sign: Danger

Codecov Report

Merging #1393 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1393   +/-   ##
=======================================
  Coverage   88.41%   88.41%
=======================================
  Files           5        5
  Lines         164      164
=======================================
  Hits          145      145
  Misses         19       19

Continue to review full report at Codecov.

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

This is related to #1283

Hey @ffittschen, thank you very much for taking your time to do it. However, we have quite a big discussion around this topic at #1283. Before taking any steps further we have to agree on a solution. We would love it if you could help us with your feedback and then you could recreate a PR with implementation.
For now I have to close it, unfortunately, but as I said please help us resolve it issue and we can go back to it really soon. Thanks for understanding!


fix(node-stuff): use more conventional shim method

Summary
In previous implementation, when there's a . in the path, the __webpack_fileURLToPath__(temp + '/..').slice(0, -1)  will change like this:
file:///Users/abc/.pnpm/index.js

-- after __webpack_fileURLToPath__(temp + '/..') -->

/Users/abc/.pnpm/index.js/..

-- after slice(0, -1) -->

/Users/abc/.pnpm/index.js/.

Use the commonly used and battle tested way, also used by tsup https://github.com/egoist/tsup/blob/49c11c3073ce977a01c84e7848fc070d5de0a652/assets/esm_shims.js.

Checklist

[ ] Tests updated (or not required).
[ ] Documentation updated (or not required).

I need a canary version now.


Profile added, changed scroll bar ui

@AnkitaMalik22 , could you please add the hacktoberfest-accepted tag to my pr


Note if theme or plugin is not (yet) compatible

As extension to the compatibility field in metadata.json there could be perhaps a note in the backend if a theme or a plugin is not (yet) compatible to the installed version.

There should be a notice at the theme listing. User should be allowed to enable them if they still want to use an incompatible theme.

I think the incompatible theme/plugin should have a warning with a light red background color instead of hiding it completely. :D
"This theme/plugin is incompatible with your Bludit version. Proceed at your own risk."

Implemented on the Github version!


Implemented Random message

Should resolve #205
https://user-images.githubusercontent.com/2345436/121245115-f1fa4c80-c89f-11eb-98ef-984f159447f2.mp4

Thank you so much for all the help here! I'll try to take a look this weekend.


Support Qdrant's Api Key in Docker Compose and Testcontainers

Read QDRANT__SERVICE__API_KEY env var from compose file and Testcontainers definition to configure the connection details for Qdrant.

excelent :)


Reload nginx when domain status is set to enabled

https://github.com/schenkd/nginx-ui/blob/82cd91cdcaf3aaa47a28b52690ad01d7e833db7e/app/api/endpoints.py#L197
When a new changes(domain) is added and enabled, is it possible to reload nginx to make tis config live ?

Just added a simple auth and nginx service reload.
https://github.com/shyjuk/nginx-ui/


⚠ Jenkins Plugins Artifactory has degraded performance

In fce180f, Jenkins Plugins Artifactory (https://get.jenkins.io/plugins/artifactory/) experienced degraded performance:

HTTP code: 200
Response time: 1260 ms

Resolved: Jenkins Plugins Artifactory performance has improved in b53046f after 41 minutes.


Marble strings should ignore whitespace

The readme seems to suggest to align marbles using spaces, outside of the marble string:
const e1 = hot('----a--^--b-------c--|', {a: 0});
const e2 = hot(  '---d-^--e---------f-----|', {a: 0});

However, this alignment whitespace is removed every time one reformats code in an IDE. For this reason, other marble testing libraries allow using whitespace within the marble string:
const e1 = hot('----a--^--b-------c--|', {a: 0});
const e2 = hot('  ---d-^--e---------f-----|', {a: 0});

This library interprets a space as a time frame, making this alignment strategy impossible.

Example reproduction:
const input = hot('   --a|');
const expected = hot('--a|');
expect(input).toBeObservable(expected);

Output:
Expected notifications to be:
  "--a|"
But got:
  "-----a|"

Good point, will implement.
You are also welcome to create a PR yourself if you don't like to wait.


No fid_kid.py

I want to compute FID/KID, but it seems there is no fid_kid.py. Is it possible to share?

Please cd ./metirc

Thanks! Oh, I've missed such an easy thing;

What's the FID/KID score of the provided cat2dog model?
When I compute the score of it,
python metric/fid_kid.py dataset/cat2dog/testB results/cat2dog/fakeB --mmd-var

FID:  31.21598867148849
mean MMD^2 estimate: 0.31708042463877906
python metric/fid_kid.py dataset/cat2dog/testA results/cat2dog/fakeA --mmd-var

FID:  43.559898830804855
mean MMD^2 estimate: 1.1181057541950077
This is too good compared to Table. 1 in the paper.
Is this just from different seed, or am I missing something?

@alpc91 sorry to bother you, but I would really appreciate it if you reply.

The provided pretrianed model is about trained on more than 200K iters. And different seeds will also have some impact on the results.

@alpc91 sorry to bother you, but I would really appreciate it if you reply.


what error

Checklist

[X] I've read the contribution guidelines.
[X] I've confirmed the issue is certainly related to this repository. If not, please consider to make a new issue in https://github.com/tier4/caret/issues

Description
hi，i record data on ubuntu20.04. and analyze data on ubuntu22.04. i open the jupyter-lab and run this scripts

After execution, it redirected to a webpage

open it using Google browser


The "--static=on" option is unable to achieve static compilation.

After testing, it has been found that in the latest release of SRS 5.0, using the command './configure --static=on' does not result in a static compilation. Upon examining the configure script, it was discovered that adding './configure --static=on' only includes the '-static-libstdc++' flag during the linking process, rather than '-static'. Additionally, it was noted that the compilation of SRS 5.0 involves the use of other libraries. A feasible method to achieve true static compilation has been identified as
./configure --srt=off --extra-ldflags=-static --sanitizer=off
The options '--srt=off' and '--sanitizer=off' are necessary for successful compilation. Without '--srt=off', the compilation will not complete, and omitting '--sanitizer=off' will result in a conflict with the static compilation option.
TRANS_BY_GPT4

Duplicated


adding parametrized queries

many people are already familiar with parametrized queries since they're available in dbt and airflow, so we should add that. possibly with jinja?
%%sql --params {"corpus_name": "hamlet", "limit": 10}
SELECT word, SUM(word_count) as count
FROM `bigquery-public-data.samples.shakespeare`
WHERE corpus = {{corpus_name}}
GROUP BY word
ORDER BY count DESC
LIMIT {{limit}}

This is how BigQuery does it (but with a different syntax).
I'm unsure if the --params {"corpus_name": "hamlet", "limit": 10} if the best choice. perhaps something simpler like -p corpus_name hamlet -p limit 10? similar to what we do in ploomber-engine

I like this.
I think that it should be inline vs passing everything under a flag?
It can be from variables in the notebooks for v1, I think I already saw a similar solution somewhere.

I think that it should be inline vs passing everything under a flag?

you mean something like this?
limit = 10
corpus_name = "something"

%%sql
SELECT word, SUM(word_count) as count
FROM `bigquery-public-data.samples.shakespeare`
WHERE corpus = {{corpus_name}}
GROUP BY word
ORDER BY count DESC
LIMIT {{limit}}

Exactly.

cool, I'd say there should be two mode. one where the user explicitly says "go grab my global scope" and another one where they pass parameters explicitly.
Here, we grab existing limit and corpus_name from existing scope (shorter version: %%sql -u):
%%sql --use-globals
SELECT word, SUM(word_count) as count
FROM `bigquery-public-data.samples.shakespeare`
WHERE corpus = {{corpus_name}}
GROUP BY word
ORDER BY count DESC
LIMIT {{limit}}

here, we pass values explicitly:
%%sql  -p limit 1 -p corpus_name stuff
SELECT word, SUM(word_count) as count
FROM `bigquery-public-data.samples.shakespeare`
WHERE corpus = {{corpus_name}}
GROUP BY word
ORDER BY count DESC
LIMIT {{limit}}

Mixing them will use the existing scope and override any passed values:
%%sql  -p limit 1 --use-globals
SELECT word, SUM(word_count) as count
FROM `bigquery-public-data.samples.shakespeare`
WHERE corpus = {{corpus_name}}
GROUP BY word
ORDER BY count DESC
LIMIT {{limit}}

thoughts?

We can do this mix, I don't see why we need --use-globals though.

We can do this mix, I don't see why we need --use-globals though.

We can do this mix, I don't see why we need --use-globals though.

following the zen of python 😁: Explicit is better than implicit.

lol sure.
Let's gather more feedback.

and, we could even combine it with the --save feature:
%%sql --save some_name --no-execute
SELECT word, SUM(word_count) as count
FROM `bigquery-public-data.samples.shakespeare`
WHERE corpus = {{corpus_name}}
GROUP BY word
ORDER BY count DESC
LIMIT {{limit}}

Then:
%sql -p limit 10 -p corpus_name one

%sql -p limit 100 -p corpus_name another

That could be one example for the docs, some_name should probably be some_query

That could be one example for the docs, some_name should probably be some_query.

agree

Probably the no-execute will always be on in that scenario.

unless you use --use-globals

@edublancas
For the --params, the abbreviation -p is conflict with our current --persist
-p / --persist Create a table name in the database from the named DataFrame ([example](https://jupysql.ploomber.io/en/latest/api/magic-sql.html#create-table))

let's use capital p: -P

Let's think about if we want to keep this
Since: https://jupysql.ploomber.io/en/latest/intro.html?highlight=variable#variable-substitution

I looked at the existing behavior: it needs to be more consistent (see here) and support some  new features. So let's go ahead and implement it with jinja2.Template.
I think the current implementation is happening here: https://github.com/ploomber/jupysql/blob/27823e65a216db36fa0c9dbd1b381a4501f5765d/src/sql/run.py#L393
so we need to:

[ ] deprecate the existing implementation  (see note below)
[ ] implement with jinja2
[ ] ensure we can re-render snippets when we change a parameter value in a snippet with the --with option (see here)

what's interesting about the existing implementation is that the original author decided to pass the user's namespace implicitly, so I think let's do it that way; once that's in, we can decide if we add the --use-globals and --parameter options.
example of the new api:
parameter = "value"

%%sql
select * from table where parameter = '{{parameter}}'

should resolve to:
select * from table where parameter = '{{value}}'

deprecation
I think we should keep the existing behavior for a bit to allow users to migrate.
I think we can detect queries with the existing behavior with some regex that looks for :something $something or {something}, and if so, show  a warning so they use {{something}} (and show our slack link so they can ask for help)

I think the original way they parsed the variable was happening earlier before our execution function:
# Suppose we execute following calls in notebook:
test_x = 3
%sql SELECT * FROM my_data limit $test_x

In the def execution function, where our main sql execute handler
    def execute(self, line="", cell="", local_ns={}):
        # skip
        print ("line: ", line)
        # print -> SELECT * FROM my_data limit 3
        command = SQLCommand(self, user_ns, line, cell)
        # args.line: contains the line after the magic with all options removed
        args = command.args

After some researches I think Ipython already parsed the line string with :variable or {variable}
Deprecation
Probably we need to find the way to control that parsing part (either throwing some warning message, or disable the :variable or {variable} in the future)
Add Double Curly Bracelets parsing support
In current codebase, if we execute something like:
test_x = 3
SELECT * FROM my_data limit '{test_x}'

It will become
    def execute(self, line="", cell="", local_ns={}):
        # skip
        print ("line: ", line)
        # print -> SELECT * FROM my_data limit '{test_x}'
        command = SQLCommand(self, user_ns, line, cell)
        # args.line: contains the line after the magic with all options removed
        args = command.args

We can still parse the SELECT * FROM my_data limit '{test_x}' to
SELECT * FROM my_data limit 3 to fulfill the feature, but I am not sure if this is a good approach since the Ipython already has the logic to handle the parsing part natively, the best approach is we can see & control the original parsing logic in Ipython then modify to our way

Update 2/22/23:
Design Proposal
There is a decorator called @no_var_expand which can be attached to def execute(self, line="", cell="", local_ns={}): function
After the var expand is turned off by our hand, we can write our custom parsers to handle the variable by ourself. There will be two cases:

Neither --use-globals and --parameter is provided, which means we should still provide the legacy variable usage. We use our custom parser (A) to handle ${variable} & :variable in line or cell string
Either --use-globals and --parameter is provided, we use our custom parser (B) to handle {{variable}} in line or cell string

Custom parser A: only handle the ${variable} & :variable case, we might reuse the var_expand func in Ipython
Custom parser B: only handle the {{variable}} case, we can just use jinja2 template.render function to parse the string
Finally, I think when user provides something like ${variable} & :variable meanwhile with --use-globals and --parameter, like %sql --use-global SELECT * FROM my_table limit ${my_limit}, this mixin usage should not be allowed in this design
@edublancas Kinda complicate...but lmk what you think

For both 1 & 2, we can add the feature, support it for the required minimum version and deprecate it in the next major, as per our deprecation policy. I think if there are no major design issues/concerns we should move to talk over an actual PR.

@edublancas
Sounds good to me now!


Add progress notification to create

Fixes #3531

@alexr00 Is a notification the best we can do here? Can't we somehow show progress in the view itself?

@alexr00 A good example of what I mean is @benibenj's fix in https://github.com/microsoft/vscode-pull-request-github/pull/3729: that operation was slow so we had to show progress somewhere. The fix was to show the UI prematurely and show progress there. An alternative fix would've been to use a notification for progress and open quick open once done; this would've been a bit jarring.
Maybe we need a restructuring in the view such that we can open it immediately and show progress within... but it would definitely improve the overall experience. What do you think?


autonumber start with each download again

Please follow the guide below

You will be asked some questions and requested to provide some information, please read them carefully and answer honestly
Put an x into all the boxes [ ] relevant to your issue (like that [x])
Use Preview tab to see how your issue will actually look like

WARNING
All invalid issues will be rejected!!

Before going further

If your problem is a bug with youtube-dl or a request for new site support please report it here

Make sure you are using the latest yt-dlg version (Click the Settings icon and then About to view the current version)

Make sure you are using the latest youtube-dl version (Click the Settings icon and then Update to update to the latest youtube-dl version)

Make sure you searched the bugtracker for similar issues including closed ones

Make sure to read the FAQs file

[x] I think my problem is NOT with youtube-dl
[x] I've verified and i assure that I'm running yt-dlg 1.X.Y
[x] I assure that i am using the latest version of youtube-dl
[x] Searched bugtracker
[x] I've read the FAQs file

What is the purpose of your issue?

[x] Bug report
[x] Feature request (request for a new functionality)
[ ] Question
[ ] Other

Please remove any sections between (---) if they are not related to your issue

Bug report
If the problem occurs when downloading a URL please provide the full verbose output as follows:

Restart yt-dlg
Go to Options > Extra tab
Enable Debug youtube-dl
Go to Options > Advanced tab and Clear your log content
Try to download the URL
Copy the whole log content and insert it between the ``` part below

delete me and insert your log content here

What operating system do you use ?
Windows
List of actions to perform to reproduce the problem:

in filename format use (autonumber)
download more than on file via GUI
..

What is the expected behaviour ?
one would think that not every file is numbered with 1, but first with "1", second with "2" etc
What happens instead ?
every download is numbered with "1"

Feature request (request for a new functionality)
Please make sure that the requested feature is NOT already in the TODO list

[x] I've verified and i assure that my requested feature is NOT in the TODO list

What operating system do you use ?
Windows

make (autonumber) work  when downloading more than one video like a user would expect by using the "--autonumber-start" option youtube-dl has and increase the valut for ech video by 1
nice to have: offer the option "--autonumber-start" in your gui, so a user can start with a value greater than 1

thank you!

every download is numbered with

"00001"

I have a dirty hack that does this, but it looks like the way the codebase works right now it might require some substantial reorganization to do it cleanly and "properly" :(


new release v1.9.4

Hi! This is the friendly automated conda-forge-linting service.
I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.
Here's what I've got...
For recipe:

Failed to even lint the recipe (might be a conda-smithy bug) :cry:

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@jakirkham need some help here. I'm guessing that I need to update the feedstock. I tried conda smithy rerender, but it gives me:
Fetching package metadata ...........
Traceback (most recent call last):
  File "c:\miniconda3\Scripts\conda-smithy-script.py", line 5, in <module>
    sys.exit(conda_smithy.cli.main())
  File "c:\miniconda3\lib\site-packages\conda_smithy\cli.py", line 289, in main
    args.subcommand_func(args)
  File "c:\miniconda3\lib\site-packages\conda_smithy\cli.py", line 200, in __call__
    configure_feedstock.main(args.feedstock_directory)
  File "c:\miniconda3\lib\site-packages\conda_smithy\configure_feedstock.py", line 477, in main
    render_run_docker_build(env, config, forge_dir)
  File "c:\miniconda3\lib\site-packages\conda_smithy\configure_feedstock.py", line 47, in render_run_docker_build
    matrix = compute_build_matrix(meta, forge_config.get('matrix'))
  File "c:\miniconda3\lib\site-packages\conda_smithy\configure_feedstock.py", line 399, in compute_build_matrix
    mtx = special_case_version_matrix(meta, index)
  File "c:\miniconda3\lib\site-packages\conda_build_all\version_matrix.py", line 212, in special_case_version_matrix
    py_vn = minor_vn(index[python_pkg.fn]['version'])
KeyError: 'python-2.6.8-5.tar.bz2'

Two things to note here.

PR should be from your fork and not a branch on the feedstock. Seems we already have a CircleCI release as is.
conda-smithy doesn't support conda 4.3. So you will need to downgrade to 4.2. This should fix that issue. However, if it doesn't, please let me know.

Aha, I knew there was something wrt how PR's were to be created, but I could not remember what it was. Thanks. Downgrading to conda 4.2 made the render work. Closing this in favor of #2


Waves too sensitives at scroll

Expected Behavior

Waves on button should not react when user is scrolling

Current Behavior

Waves are too sensitives. When user scroll, waves gets activated. That bug do not happen in the original Waves library (http://fian.my.id/Waves/)

Possible Solution

Maybe update Waves library (currently integrated in version v0.6.0) to the lastest version: 0.7.4.
Steps to Reproduce (for bugs)

Here is a comparison video between the original library and the Materialize integration: https://goo.gl/photos/eDgpny7cqjFTVbhs7
Your Environment

Version used: v0.100.1
Browser Name and version: Chrome (Mobile-Android) 59.0.3071.125
Operating System and version (desktop or mobile): Android

0.7.5 is the latest version. We may have to port our changes when we update as the integrated version has bugfixes and some other changes so we have to rebase this part / file.

Duplicate of #4027


ci: enable moon test native backend on bleeding

Pull Request Test Coverage Report for Build 3381
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.4%) to 83.165%

Totals

Change from base Build 3376:
0.4%

Covered Lines:
4105

Relevant Lines:
4936

💛  - Coveralls


Export Link component from nextra-theme-docs

Aside from the components such as Card, Cards, FileTree, Callout, and etc., would it be possible to export the Link component, too?
The reason being that I cannot use variable interpolation to declare links in MDX, e.g. [Text](url), if I want to use a variable for the URL: https://github.com/mdx-js/mdx/issues/2173
This forces me to use <Link href={url}>{text}</Link> instead, but it is unstyled as I can only import it from next/link. It would be nice to have access to the styled Link component used by theme docs :)

Custom MDXComponents :)

Create MDXComponents.jsx from folder Components
import cn from 'clsx'
import { Callout } from '../Callout'
import Link from '../Link'
import { Tab, Tabs } from '../Tabs'

export const MDXComponents = {
  Callout: (props) => <Callout {...props} />,
  a: (props) => (
    <Link
      {...props}
      className="font-semibold !no-underline !border-b-[1px] !border-b-primary-600 hover:!border-b-2 !rounded-none"
    />
  ),
  blockquote: (props) => (

  ),
  p: (props) =>
,
  ul: (props) =>
,
  ol: (props) =>
,
  li: (props) =>
,
  Tab: (props) => <Tab {...props} />,
  Tabs: (props) => <Tabs {...props} />,
}

From root projects add to theme.config.tsx
eg:
import { MDXComponents } from '@components/MDXComponents'

const theme = {
  components: MDXComponents,
}

export default theme

@tuanducdesign but that means having to hardcode CSS classes to my Link component, while all I want is to use the same styles as the one that Nextra uses internally.
Hardcoding the class names make the custom MDX component non-futureproof, and therefore isn’t really a viable solution for me.


Interrupt

View details in Rollbar: https://rollbar.com/trystant/BOW/items/675/

Interrupt
  File "/usr/local/rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/net/protocol.rb", line 158, in wait_readable
  File "/usr/local/rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/net/protocol.rb", line 158, in rbuf_fill
  File "/usr/local/rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/net/protocol.rb", line 136, in readuntil
  File "/usr/local/rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/net/protocol.rb", line 146, in readline
  File "/usr/local/rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/net/http/response.rb", line 40, in read_status_line
  File "/usr/local/rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/net/http/response.rb", line 29, in read_new
  File "/usr/local/rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/net/http.rb", line 1437, in block in transport_request
  File "/usr/local/rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/net/http.rb", line 1434, in catch
  File "/usr/local/rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/net/http.rb", line 1434, in transport_request
  File "/usr/local/rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/net/http.rb", line 1407, in request
  File<EMAIL_ADDRESS>line 27, in block (2 levels) in request_with_newrelic_trace
  File<EMAIL_ADDRESS>line 428, in disable_all_tracing
  File<EMAIL_ADDRESS>line 26, in block in request_with_newrelic_trace
  File<EMAIL_ADDRESS>line 48, in tl_trace_http_request
  File<EMAIL_ADDRESS>line 23, in request_with_newrelic_trace
  File<EMAIL_ADDRESS>line 999, in request
  File<EMAIL_ADDRESS>line 25, in perform_request
  File<EMAIL_ADDRESS>line 40, in block in call
  File<EMAIL_ADDRESS>line 21, in with_net_http_connection
  File<EMAIL_ADDRESS>line 32, in call
  File<EMAIL_ADDRESS>line 139, in build_response
  File<EMAIL_ADDRESS>line 377, in run_request
  File<EMAIL_ADDRESS>line 21, in block in perform_request
  File<EMAIL_ADDRESS>line 257, in perform_request
  File<EMAIL_ADDRESS>line 20, in perform_request
  File<EMAIL_ADDRESS>line 128, in perform_request
  File<EMAIL_ADDRESS>line 15, in info
  File<EMAIL_ADDRESS>line 59, in server_version
  File<EMAIL_ADDRESS>line 63, in server_below?
  File<EMAIL_ADDRESS>line 256, in index_options
  File<EMAIL_ADDRESS>line 70, in searchkick_index_options
  File<EMAIL_ADDRESS>line 190, in reindex_scope
  File<EMAIL_ADDRESS>line 53, in searchkick_reindex
  File<EMAIL_ADDRESS>line 26, in block (4 levels) in <top (required)>
  File<EMAIL_ADDRESS>line 24, in each
  File<EMAIL_ADDRESS>line 24, in block (3 levels) in <top (required)>
  File<EMAIL_ADDRESS>line 248, in block in execute
  File<EMAIL_ADDRESS>line 243, in each
  File<EMAIL_ADDRESS>line 243, in execute
  File<EMAIL_ADDRESS>line 187, in block in invoke_with_call_chain
  File "/usr/local/rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/monitor.rb", line 214, in mon_synchronize
  File<EMAIL_ADDRESS>line 180, in invoke_with_call_chain
  File<EMAIL_ADDRESS>line 173, in invoke
  File<EMAIL_ADDRESS>line 152, in invoke_task
  File<EMAIL_ADDRESS>line 108, in block (2 levels) in top_level
  File<EMAIL_ADDRESS>line 108, in each
  File<EMAIL_ADDRESS>line 108, in block in top_level
  File<EMAIL_ADDRESS>line 117, in run_with_threads
  File<EMAIL_ADDRESS>line 102, in top_level
  File<EMAIL_ADDRESS>line 80, in block in run
  File<EMAIL_ADDRESS>line 178, in standard_exception_handling
  File<EMAIL_ADDRESS>line 77, in run
  File<EMAIL_ADDRESS>line 27, in <top (required)>
  File "/usr/local/rvm/gems/ruby-2.3.0@ebwiki/bin/rake", line 23, in load
  File "/usr/local/rvm/gems/ruby-2.3.0@ebwiki/bin/rake", line 23, in <main>
  File "/usr/local/rvm/gems/ruby-2.3.0@ebwiki/bin/ruby_executable_hooks", line 15, in eval
  File "/usr/local/rvm/gems/ruby-2.3.0@ebwiki/bin/ruby_executable_hooks", line 15, in <main>
Interrupt
  File "/usr/local/rvm

There has been one instance of this in 50 days. I'll reopen if it occurs again, but for now, I believe we can close this.


android java.lang.NullPointerException

When doing gradle build on android example from examples folder I get:
FAILURE: Build failed with an exception.
What went wrong:
A problem occurred configuring project ':app'.
java.lang.NullPointerException (no error message)

Is that all the output you get? I don't think we can do much with this information...

Yes, that's all. Do you get the same? I just downloaded the repo, added local.properties and tried to build using gradle build in console.

I fixed the problem by using build scripts from https://github.com/SFML/SFML/wiki/Tutorial%3A-Building-SFML-for-Android. Than I deleted -stdlib=libc++ from them and updated classpath to 'com.android.tools.build:gradle:4.2.0'. After that I typed gradle wrapper, changed distributionUrl to https://services.gradle.org/distributions/gradle-6.7.1-all.zip in gradle-wrapper.properties.


Fix the --typescript option swallowing the first input after it

Previously resin-lint --typescript src test would only recognise test as a target directory
Change-type: patch

@LucianBuzzo can you publish this (unless auto-publishing is set up?)

This was a major change, not patch.

@Page- It appears that this module auto publishes https://www.npmjs.com/package/resin-lint

@zvin the major change was https://github.com/resin-io/node-resin-lint/pull/15
@LucianBuzzo it does now because I PRed it in https://github.com/resin-io/node-resin-lint/pull/19 but it didn't before

@Page- #15 is a patch too.
Some projects are relying on the first argument behind --typescript being swallowed (like here https://github.com/resin-io-modules/file-disk/blob/master/package.json#L24 ).
This PR changed the resin-lint command interface.
It doesn't matter much as resin-lint is only a dev dependency and the projects will get fixed.


update type checking

resolves #11

Current dependencies on/for this PR:

main

PR #12

PR #13   👈

PR #14

This comment was auto-generated by Graphite.

@cameronraysmith queued this pull request to merge with Graphite.

@cameronraysmith merged this pull request with Graphite.


How can I use "sortable" between my fontend code

I am a beginner of  kirki,
But I don't know how to use  "sortable" to sort the elements at fontend，
Where can I get  a fontend template of   "sortable"  control
Thanks

@wowwwai I just added an example on http://aristath.github.io/kirki/docs/controls/sortable.html

Hi. Link from above is missing. Can I ask for sample usage of sortable also?
Thanks!


Allow user to deselect geometry

Currently it is not easy to deselect a geometry once a user selects it.
Add an X next to the geom label to allow it to be dismissed:
e.g. NYPD Precinct        101 X ?

Logic

action that causes geo identifier to become null / undefined

map redisplays polygons for same geography type

map zooms back out to all of NYC

UI:

filter by area text read out needs a way of deselecting ("X")

triggering the deselect action removes identifier text but keeps geo button active


Update steal-cordova to latest

0.1.3 installs steal-cordova@5 and old version of cordova-ios that won't build with xcode 9.

so @bgando this was the problem I had 😢
the simulator won't launch but that's a problem in ios-sim, it will be fixed when cordova starts using<EMAIL_ADDRESS>by default. I did open it through xcode as you explained.


Default to using ~/.local/share/nn for data files

Should be defined as:
import System.Directory  -- from "directory" package

defaultHome :: IO FilePath
defaultHome = getXdgDirectory XdgData "nn"

Also silently create this directory if it needed and does not exist (and other $NN_HOME is not specified).

The defaulting was taken care of by a8928ecaf067ebc98649b9cb81d6b0eeae9d3fca. New issue (#14) created to address the creation of a missing directory.


example for new structure in inventory

I reorgnized the directory structure for my inventory in ansible-oracle.
tree inventory/

inventory/
└── orafs
    ├── group_vars
    │   └── all
    ├── hosts
    └── host_vars
        └── oradb03
            └── vars.yml
        └── oradb04
            └── vars.yml

Replace hosts with symbolic links to the files in inventory when a central file for the hosts-inventory is used. The advantage is a clear structure for each 'hosts' in the playbook.
Adding the ansible-vault is very easy. Just add a file vault.yml in the directory of vars.yml.
The host_vars and group_vars from '/' could be removed. This makes the whole structure for projects with own configurations much cleaner. Removing the examples is very easy as well.
What do you think about the structure?

The example is related to #38.
I could give some examples how I used the vault within the structure.

Yeah, I like that structure, but I'm not going to change everything to that (at least not now)
For #38, I kept it simpler and just did this:
group_vars/vbox-si-asm/
                    |-- passwords.yml
                    `-- vbox-si-asm.yml

and it works very well.
I have a bunch of re-factoring that I have to finish, and after that is done I'll look into maybe changing the entire inventory structure.
But, I have tested the structure you're using and I like it, so it will probably end up looking like that eventually.

is there a branch for this example?

The example inventory will be replaced by a new one in the future.
Closing it here.


Cancelling the download of a VM thinks it's complete.

I was downloading a VM, and then I cancelled it. Then I got a notification showing that it's complete. Isn't it supposed to show "cancelled"?

Fixed in PR #42


More proactive help with names when searching (Autocorrect)

Rather than telling our users to go off to a separate, hard-to-find page crammed with names and use the browser's 'find' command to hack through them, why don't we provide an autocomplete function on the search page which offers forenames or surnames matching what they have typed so far? If they have selected a District for their search, only offer names associated with that District.

After discussion, we agreed that the autocomplete should always offer a selection from all the names, rather than trying to filter by e.g. event type, District or date. This is compatible with the other search criteria (County, District, date, etc.), which are also not filtered based on the user's selections (apart from Districts being filtered by County).
As an initial piece of work, it was agreed that I would attempt to implement a suitable table structure, together with routes which return all names matching a given stem as JSON.
Concern was expressed about how this facility could be provided in an accessible manner.

Tested, works well!

@Vino-S to put this into MongoDB and then run Richard's rake task and share the steps for future rake tasks.

Looking into matching names which are not at the start of a 'unique name'. MongoDb has a 'text' index type, but it only matches/fires on complete words within a string.  That doesn't meet our requirements, which are to match as the user types.

Changed strategy to use MongDB collections as the source of autocomplete. This needs moving to test3, the rake tasks need to be run, then we can test whether this approach scales.

@Vino-S could you please do the above?

@Vino-S to run the rake tasks

ready for testing in test3

OK: first impressions:

the autocorrect terms are mixed case (some all uppercase; others mixed case), and the autocorrect matching is case sensitive. (This may be where the Colberts went!) We need to implement a strategy which is effectively case-insensitive, e.g. having all the autocorrect terms in uppercase and forcing input to uppercase as it is typed. Then the input strategy will match the search strategy (which is also case-insensitive)
the input of subsequent characters is blocked until the autocorrect returns a set of suggestions based on what has been typed so far. As more characters are typed, I would expect the response to get quicker, but this doesn't seem to be the case. This amount of delay, as it stands, won't be acceptable to users

Colberts ahoy! :-

I've tried adding an index to the forenames and surnames collections, limiting the number of responses to 10 and making the search case-insensitive.

Yay!

@Vino-S could you please push the updated fb_523_rbl branch to test3, so we can see whether my changes have the desired effect (or indeed any effect)? Thanks

OK, that is now working somewhat better on test3. Please have a look and comment. The key question is: is the response time slick enough?

I wasn't getting any autocomplete on forenames, but this is because Vino has only managed to load up to "Elizabeth Grigson". (I was trying "Jane".) This fragment of the possible forenames table represents 1414022 distinct names, so it would get quite big if completed. More to the point - is this actually helpful for researchers? Should we just offer single forenames?

@vino to clear the collection then run the rake task (and report number of distinct names) for Richard to then test.

As regards accessibility and autocomplete, a quick search turned up these guidelines: https://www.w3.org/WAI/ARIA/apg/patterns/combobox/. While the 'pop-up' lines obviously appear without signalling a screen refresh, the text box we are aiming to populate is part of the original page as loaded, so I don't see why it can't have suitable ARIA attributes. Does @AlOneill tell us what ARIA markup is required, or is it our job to work that out?

It looks as though the rake task has run to completion. Now get a list of possible first names. The only issue spotted is the familiar one of the same name with different case, e.g.:

If we're going to tidy up the list of names so that each name only appears once, we should take the opportunity to agree on a 'preferred' format for both forenames and surnames (and then implement it in our autocomplete lists). Personally I would prefer initial uppercase followed by lowercase for both, but I know there is a tradition of putting surnames into upper case. Do we need to consult more widely?

@Vino-S I have pushed an update to fb_523_rbl which forces forenames to initial uppercase then lowercase. Please re-run this rake task on the full test3 data, so we can see the result.

@Vino-S to let @richardofsussex know when Test 3 is back up for testing

If the rake task has run, it had no effect. This is what I get for forenames: a mix of all lower case, normal case and upper case:

@Vino-S please confirm whether this rake task has actually been run.

@Vino-S to look into this

@Vino-S to update the code for the rake task to deal with casing

Yes, these are now fine on test3 and can be moved to beta.

@Vino-S please, create a script to run a rake task

Very few first names in the autocomplete on beta. Does the rake task need running for both first names and surnames on beta?

Agree with Richard. I see a different number of first name and surname variants on test 3 and beta.

Also we have a mix of uppercase and lowercase surname variants. Should we leave this as it is?  @DeniseColbert @richardofsussex

@Vino-S to contact @lemon-ukgen about scheduling of rake task

On test3 now:

Mix of lowercase and uppercase in Surnames
Different formats for Names and Surnames. I think the format for both should be the same. (Initial letter in uppercase followed by lowercase for both Names and Surnames).

Hyphenated surnames require an uppercase letter after each hyphen, as well as at the start of each name.

Vinp please move a hyphen


[Proposal] PHAR Distribution

Given that Jigsaw is primarily run as a CLI tool, would it be possible to box it up and also officially distribute as a .phar?
This allows projects to simply include jigsaw.phar directly in the repository, not only removing the burden of installing Jigsaw globally, but for many projects removing the need for composer at all. This also greatly decreases the chances of dependency/versioning issues across a team, and is extremely valuable when working on the project w/ non-PHP devs like front-end designers.
This may also provide an alternative solution to #32, by looking first for jigsaw.phar in the current directory first.

I too would like to see a phar distribution; having it installed globally via composer causes issue on my machine because it has conflicting requirements with some other globally installed tools - having it boxed as a phar would solve that.

I was able to build a package myself here are some instructions on how I did it:
### First you need to download the lastest of phar
### Install phar-composer
php phar-composer.phar --version
chmod 755 phar-composer.phar
sudo mv phar-composer.phar /usr/local/bin/phar-composer

### Build and Install the jigsaw project
phar-composer install  tightenco/jigsaw

No plans for this at the moment, but if you run into dependency conflicts when installing globally via Composer, you can always install Jigsaw locally to your project.


[Bug Report] Safari OS X: once a Select's menu was opened only the Select's upper half remains interactive

Element UI version
1.2.9
OS/Browsers version
OS X 10.11.6 / Safari 10.1
Vue version
2.2.6
Reproduction Link
https://jsfiddle.net/c1amumsp/6/
Steps to reproduce
The jsfiddle displays a Select component.

Click the Select to open its menu, click it again to close the menu.

Now hover with the mouse over the Select. You'll see the pointer cursor appearing only in the Select's upper half. The Select's lower half does not respond to mouse clicks anymore.

Note: the problem does not occur in Chrome or Firefox. It occurs only in Safari.
What is Expected?
After closing the Select's menu the entire Select is still expected to react to mouse clicks.
What is actually happening?
After closing the Select's menu only the Select's upper half can be used to open the menu again. The lower half does not respond to mouse clicks anymore. No pointer cursor appears.

Not reproducible on OS X 10.11.6 / Safari 9.1

So, does this mean this bug will not be fixed?
Safari 10.1 is the up-to-date browser on OS X El Capitan. It is installed by App Store automatically.

No, I was just adding some extra information. Perhaps someone else with OS X 10.11.6 and Safari 10.1 will be able to comment if they're able to reproduce it.

Didn't reproduce this in OS X 10.12.4 / Safari 10.1. Would you mind uploading a gif of this problem?

Thank you for the replies!
Hint: the problem occurs only (as I've described) if the Select's menu was already opened/closed at least once.
In the screenshot you can see that the expand-trigger element does not cover the entire el-select element. The el-select respond to mouse clicks only in the limited area (see arrow and blue area in the screenshot). The same applies to the contract-trigger element.
The clickable area is limited due to this rule (shown in the screenshot):
.resize-triggers > div {
    overflow: auto;
}

overflow: auto causes Safari to reserve space for scrollbars at the elements right and bottom borders (see screenshot). That is the very space that is not available for mouse clicks to open the menu. This is the origin of the problem I describe in this ticket.

I didn't notice it before, but now I do. Here's a GIF with two strange things:

Even before the first click on the select, .resize-triggers > div are actually still half the height of the select, but the field responds to the first click on the lower half.
Removing overflow: auto does seem to fix it, but this style does not affect the "hit-box" until after the first click.

@syn-zeta I appreciate your investigation very much, and that you've acknowledged the bug eventually.
I assume you've done the test in Safari 9.1 and thus have proven the bug applies to Safari 9.1 as well.
Due to the bug the user experience of the Select component is very bad on OS X. To the everyday user it feels like the Select component does react to mouse clicks only occasionally.
Hopefully the bug will be fixed.
Thank you for your effort!

Similar issue for me in the old Chrome(CEF 1650)，user can't trigger the select to open sometimes. Then I find out that it was because sometimes user clicked on the .contract-trigger div but the .el-select.
When I remove the overflow: auto on that div, it works as expected ~

In current Element UI 1.3.5 the Select component is still not fixed.
On OS X the Select component is seriously flawed and practically not usable in production.
Meanwhile the bug has been acknowledged on all recent Safari browsers by several users.
Is there a plan to fix it?

@jri I'm now finally reproducing this. @savokiss thanks for your information, that is the correct fix.
Fixed in #5226. Will be available in the next release.

@Leopoldthecoder Thank you very much :-)


Regression on last update when nesting tags

Hello!
We found a regression with the last update, I could replicate it with this test, but I'm not able to fix it in the code.
Can you please have a look?
Thanks!
  57 passing (78ms)
  1 failing

  1) sanitizeHtml should drop the content of textarea elements but keep the closing parent tag, when nested:

      AssertionError: '
Paragraph' == '
Paragraph
'
      + expected - actual

      -
Paragraph
      +
Paragraph

      at Context.<anonymous> (test/test.js:50:12)

The fix has been published. Thanks!

Thanks :)


How can I verify the binding works in walkthrough.md

In https://github.com/kubernetes-incubator/service-catalog/blob/master/docs/walkthrough.md , we only show example of the binding ready, but how can I verify the binding works? i.e. How can I verify that the binding can help me talk to the UPS broker server?

I think this is addressed in the walkthrough. The example broker doesn't provide a real service. You can look at the secret that gets created, but there isn't any provisioned service to talk to.

The walkthrough is difficult to understand, @MHBauer , can you please show more detail for how does the created secret related with UPS broker?

Ah, I see, there is a ups controller doing this https://github.com/kubernetes-incubator/service-catalog/blob/master/contrib/pkg/broker/user_provided/controller/controller.go#L125-L138 , so each broker need to have their own controller binging logic.

I created a PR https://github.com/kubernetes-incubator/service-catalog/pull/662 to help navigate the UPS to its controller which can help people to understand the logic of UPS more clear.


Publish 7.5-20220518001855+0000

Publish 7.5-20220518001855+0000

@bot-gradle test and merge

OK, I've already triggered a build for you.


Exception in onLogin callback: Error: Match error: Expected plain object

Hi,
I may be mistaken, but using the suggested onLogin fragment, the error
Exception in onLogin callback: Error: Match error: Expected plain object

Is returned as a result of check(user, Object); in the _setUserAvatar call because Meteor.user() returns a Document and not a plain object.

Are you using Safari?
Can you try to add ejson package and see if it solves this? If not I would suggest to replace the code with
let user = Meteor.users.findOne({_id: Meteor.userId()});
AvatarManager.setUserAvatar(user);

Chrome. And I've added the ejson package and it still returns that error.
I've added the equivalent code in my onCreateUser callback and it works, but I thought I should mention the problem for those installing it as described in the README.

can you try the demo site ? I tested it on Chrome and it works.
http://avatarmanager.meteor.com/

Hi,
If you're sure, then I believe you. :) Given you only just released the update and I've changed my implementation, we'll close it off unless someone else has this problem.
Thanks for looking into it.