Updated Microsoft.Extensions.DependencyModel to 1.1.0

In order to avoid a warning when using nunit in VS 2017 RC: "Found conflicts between different versions of the same dependent assembly that could not be resolved"
This is basically the same issue that was in xunit: https://github.com/xunit/xunit/issues/1091

Sorry, but I am going to close this PR. With the switch to the new style adapter when .NET Core moved to the csproj format, we are not going to maintain this adapter anymore. Thanks for the contribution.


python-raet packaging issue with Amazon Linux?

Moved from https://github.com/saltstack/salt/issues/31040 @lorengordon
I was doing some package testing this morning and found that I could not install python-raet on Amazon Linux due to a conflict of some kind around python-importlib. I don't quite understand the message. I setup the saltstack repo, then attempted to install python-raet. If anyone knows how to resolve the conflict, please let me know!
# yum install python-raet:
Loaded plugins: priorities, update-motd, upgrade-helper
amzn-main/latest                                                                                | 2.1 kB     00:00
amzn-updates/latest                                                                              | 2.3 kB     00:00
31 packages excluded due to repository priority protections
Resolving Dependencies
--> Running transaction check
---> Package python-raet.noarch 0:0.6.3-2.el6 will be installed
--> Processing Dependency: python(abi) = 2.6 for package: python-raet-0.6.3-2.el6.noarch
--> Processing Dependency: python-libnacl >= 1.4.3-1 for package: python-raet-0.6.3-2.el6.noarch
--> Processing Dependency: python-ioflo >= 1.3.8-1 for package: python-raet-0.6.3-2.el6.noarch
--> Processing Dependency: python-six for package: python-raet-0.6.3-2.el6.noarch
--> Processing Dependency: python-simplejson for package: python-raet-0.6.3-2.el6.noarch
--> Processing Dependency: python-importlib for package: python-raet-0.6.3-2.el6.noarch
--> Processing Dependency: /usr/bin/python2.6 for package: python-raet-0.6.3-2.el6.noarch
--> Running transaction check
---> Package python-importlib.noarch 0:1.0.2-1.el6 will be installed
---> Package python-ioflo.noarch 0:1.3.8-1.el6 will be installed
---> Package python-libnacl.noarch 0:1.4.3-1.el6 will be installed
--> Processing Dependency: libsodium for package: python-libnacl-1.4.3-1.el6.noarch
---> Package python-six.noarch 0:1.9.0-2.el6 will be installed
---> Package python26.x86_64 0:2.6.9-2.84.amzn1 will be installed
--> Processing Dependency: libpython2.6.so.1.0()(64bit) for package: python26-2.6.9-2.84.amzn1.x86_64
---> Package python26-simplejson.x86_64 0:3.6.5-1.12.amzn1 will be installed
--> Running transaction check
---> Package libsodium.x86_64 0:0.4.5-3.el6 will be installed
---> Package python26-libs.x86_64 0:2.6.9-2.84.amzn1 will be installed
--> Processing Conflict: python-importlib-1.0.2-1.el6.noarch conflicts python(abi) = 2.7
--> Restarting Dependency Resolution with new changes.
--> Running transaction check
---> Package python27.x86_64 0:2.7.10-4.119.amzn1 will be updated
--> Processing Dependency: python27(x86-64) = 2.7.10-4.119.amzn1 for package: python27-devel-2.7.10-4.119.amzn1.x86_64
--> Processing Dependency: python27(x86-64) = 2.7.10-4.119.amzn1 for package: python27-devel-2.7.10-4.119.amzn1.x86_64
--> Processing Dependency: python27(x86-64) = 2.7.10-4.119.amzn1 for package: python27-devel-2.7.10-4.119.amzn1.x86_64
---> Package python27.x86_64 0:2.7.10-4.120.amzn1 will be an update
--> Processing Dependency: python27-libs(x86-64) = 2.7.10-4.120.amzn1 for package: python27-2.7.10-4.120.amzn1.x86_64
--> Running transaction check
---> Package python27-devel.x86_64 0:2.7.10-4.119.amzn1 will be updated
---> Package python27-devel.x86_64 0:2.7.10-4.120.amzn1 will be an update
---> Package python27-libs.x86_64 0:2.7.10-4.119.amzn1 will be updated
---> Package python27-libs.x86_64 0:2.7.10-4.120.amzn1 will be an update
--> Processing Conflict: python-importlib-1.0.2-1.el6.noarch conflicts python(abi) = 2.7
--> Finished Dependency Resolution
Error: python-importlib conflicts with python27-2.7.10-4.120.amzn1.x86_64
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

# cat /etc/yum.repos.d/saltstack.repo:
# Enable SaltStack package repository
[saltstack-repo]
name=SaltStack repo for RHEL/CentOS 6
baseurl=https://repo.saltstack.com/yum/redhat/6/$basearch/latest
enabled=1
gpgcheck=1
gpgkey=https://repo.saltstack.com/yum/redhat/6/$basearch/latest/SALTSTACK-GPG-KEY.pub

Amazon Linux is not RHEL 6.  As you can see, it ships with Python 2.7, but the salt packages in the RHEL 6 repository are built against stock Python 2.6.

@carlwgeorge, my understanding is that Amazon Linux is based on EL6, and is expected generally to be compatible with repos and packages built for EL6 (including EPEL 6, as mentioned in their documentation). So I don't think it's an EL6 vs EL7 thing.
It makes more sense to me that it could be a Python 2.6 versus Python 2.7 thing. Are you saying you think the problem might be compatibility of the EL6 salt packages with Python 2.7?

To clarify a bit more, every salt package works fine with Amazon Linux and its default Python 2.7 install, except the python-raet package. So if it's a Python 2.6 vs Python 2.7 problem, the problem is specifically with this one package.

my understanding is that Amazon Linux is based on EL6, and is expected generally to be compatible with repos and packages built for EL6

"Based on EL6" is not the same thing as being EL6.  You can install some Fedora packages on RHEL, but it doesn't mean you should, or that it will continue to work in the future.

every salt package works fine with Amazon Linux and its default Python 2.7 install

No, they don't.
--> Processing Dependency: python(abi) = 2.6 for package: python-raet-0.6.3-2.el6.noarch

This line from the OP's output clearly indicates that python-raet is built against python26, not python27.  Amazon does ship python26 packages, which appear to be pulled in as dependencies.
--> Processing Conflict: python-importlib-1.0.2-1.el6.noarch conflicts python(abi) = 2.7

This line from the OP's output clearly shows that the "issue" is that python-importlib is being pulled as a dependency from EPEL.  It has a strict conflict with the default python on Amazon.
# repoquery --conflicts python-importlib
python(abi) = 2.7

To be 100% clear:  this means that it is impossible to install python-importlib on Amazon Linux, because you can't uninstall python27 (it would break yum).
This isn't a bug for EPEL.  This isn't a bug for Salt.  This is a usage error, plain and simple.

I really don't follow what you're saying. No packages are coming from EPEL on this instance. I intentionally uninstall the epel-release package and verify that no local yum repo sources are referencing the epel repos.
I'm perfectly willing to adjust how I'm doing this. Could you demonstrate how I can get python-raet to install successfully from the saltstack repo on Amazon Linux?

python-importlib is an EPEL package.  I see now that Salt includes a rebuild of this package in their repository, so you don't actually need to enable EPEL to be using it.  That doesn't change my point from before.

The python-raet package in the Salt RHEL 6 repository has hard dependencies on python(abi) = 2.6 and python-importlib
The python-importlib package conflicts with python(abi) = 2.7
On Amazon Linux, you cannot remove python27 (provider of python(abi) = 2.7), so you cannot install python-importlib, so you cannot install python-raet.

Bottom line is you can't count on packages built for RHEL 6 to work on Amazon Linux.  I can't explain it any other way.  The only true solution would be for Salt to offer actual Amazon Linux repositories, with packages built against Amazon Linux.  It might be possible to ask Amazon to create a custom python26-importlib package that doesn't conflict with their python27 package; but even if they do that, and it works, that is only a stop-gap measure until the next packaging difference bites you in the rear.

Ahh, ok, that explanation is more helpful. I think there are more alternative solutions though. importlib is included with python27, so python-importlib isn't really needed at all. Couldn't salt's rpm spec for python-raet be modified to check that and skip the require for python-importlib? Something like:
%{!?pyver: %global pyver %(%{__python} -c "import sys ; print sys.version[:3]")}
%if pyver < 2.7
Requires:  python-importlib
%endif

I also found a related issue in RHEL's Bugzilla indicating it may be sufficient to remove the 'Conflicts' statement in the python-importlib spec file.
We run into problems with every distro. Figuring out stuff like this is perfectly normal. No need to feel bitten. In this case, I was testing many of the saltstack repo packages with RHEL, CentOS, and Amazon Linux, and only had a problem with this one package and Amazon Linux, so I did what I felt was the responsible thing and opened an issue asking for help because I didn't really understand the underlying cause. Thanks for helping me understand the problem.

Couldn't salt's rpm spec for python-raet be modified to check that and skip the require for python-importlib?

It already does.  On RHEL 6 the pybasever macro is set to 2.6.
%if "%{?pybasever}" == "2.6"
BuildRequires:  python-importlib
Requires:       python-importlib
%endif

What you really want is packages built against Amazon's python27 packages.  That will require a new spec file or some more conditional checks in the existing spec files to require python27-* packages instead of python-* packages.  Either way, you still would need to build packages specifically for Amazon Linux.

I also found a related issue in RHEL's Bugzilla

I do agree with that bugzilla report.  There is no need for the conflict, and it should be removed to cooperate with other third party repositories (such as IUS) that provide python27 packages.  Even if that change is made, it is still just a stop-gap measure until another packaging difference between Amazon Linux and RHEL causes issues.

No need to feel bitten.

No hard feelings here, just don't spread the false idea that Amazon Linux is compatible with RHEL repositories.  It isn't, because Amazon Linux is not RHEL.  It is a weird hybrid mix of RHEL, Fedora, and custom RPMs.

I saw that line in the spec file, but the lines that set pybaseserver are not a sufficient test.
%if 0%{?rhel} < 7
%global with_python26 1
%define pybasever 2.6
%define __python_ver 26
%define __python %{_bindir}/python%{?pybasever}
%endif

Like I said.

That will require a new spec file or some more conditional checks in the existing spec files to require python27-* packages instead of python-* packages. Either way, you still would need to build packages specifically for Amazon Linux.

I hear what you're saying, but I disagree that a separate package is necessary or desirable in this case. It seems to me that a better conditional check in the existing package spec would be sufficient, and the package could remain in the existing repo. We'll have to agree to disagree on this one.
If the saltstack team considers this to be someone else's problem and wants to close the issue, that is their prerogative. Or they can adjust how they're building the the python-raet package or the python-importlib package, or adjust how they build their repos. There are several options, all with tradeoffs. Whatever direction they want to go is fine by me.

By all means, if you know how to create a python-raet RPM that works on both RHEL 6 and Amazon Linux, prove me wrong and do it.  I don't believe it's possible.  You may be able to create a single spec file that will build for either, but if you build python-raet for RHEL 6, it is going to depend on Python 2.6.
Also, I see part of the confusion that I missed at first.  The title of this page indicates that it should work on Amazon Linux.  In my opinion this bug should transition to just "update the docs" and remove mention of Amazon Linux.

@carlwgeorge, I realized I was thinking of the conditions in the rpm spec file as install-time evaluations rather than build-time evaluations. I better understand now the problem with creating a single python-raet rpm that would support both RHEL 6 systems with Python 2.6 and Amazon Linux systems with Python 2.7. My apologies for being dense; I'm obviously still learning the intricacies of the packaging system and the various distros. This does seem like a rather incredible limitation of RPMs and EL systems. Are there even security updates for Python 2.6 any longer?
On the plus side, I did test removing the line Conflicts:      python(abi) = 2.7 from the python-importlib spec file and that worked like a charm. Any recommendations on how to get that fixed upstream? Or do you have any recommendations for the salt team, if they were so inclined as to repackage that rpm for their own purposes? (I'm not sure what would be less effort over time: packaging every RPM for Amazon Linux specifically and hosting an entirely separate repo, or continuing to try to resolve one-off packages as conflicts are found.)

This does seem like a rather incredible limitation of RPMs and EL systems.

Is there any package format that allows for dynamic requirements based on the properties of the system?  I don't believe there is, so it's not really fair to call it a limitation of RPM.

Are there even security updates for Python 2.6 any longer?

Python 2.6 is EOL upstream, but Red Hat is maintaining the version they shipped in RHEL 6 with security backports until 2020.  They are doing the same with Python 2.4 in RHEL 5 until 2017.  On that note, Salt is responsible for the security updates for the python26 packages in the Salt RHEL 5 repo.  I believe those originally came from EPEL, but EPEL dropped them because no one wanted to maintain them.

Any recommendations on how to get that fixed upstream?

The bug exists, so not much more we can do.  For what it's worth, every time some adds themselves to the "CC list" of the bug, it sends an email to the package maintainer.  That kinda serves as a rudimentary "+1" system.

Or do you have any recommendations for the salt team, if they were so inclined as to repackage that rpm for their own purposes?

Salt could ship their own modified python-importlib without that conflict.  They already do ship newer version of several EPEL packages.

I'm not sure what would be less effort over time

Yeah, it could go either way.  Me personally, I think the most correct solution is to properly build against Amazon Linux.  Once that's implemented and automated, the ongoing maintenance cost should be minimal.  Waiting for other packaging difference bugs to pop up seems worse to me.

The bug exists, so not much more we can do.

Do they accept contributions? I might be able to find some time to submit an updated package, if there's a reasonable chance they'd accept it.

I commented on the bug asking to be added as a co-maintainer.  I'll give the primary owner a little while to reply, and then I'll escalate to other Fedora people.  Unresponsive maintainers can be "fired" (in a manner of speaking).

@lorengordon Going to remove the Conflict statement and rebuild python-importlib rpm and make it available from repo.saltstack.com for the next point release.

Ok, thanks @dmurphy18


error

Traceback (most recent call last):
for x in testfile.get_feature(2):

File "C:\Python27\lib\site-packages\pygeoj.py", line 497, in get_feature
return self[oldindex]
NameError: global name 'oldindex' is not defined

I believe this is an old bug that got fixed. A more stable version 1.0 is now out on pypi.


How do I execute the kubectl command on a slave node

What should I do if I want to execute the kubectl command on the slave node？

Hi @jepson66
By default, MicroK8s worker nodes do not get an admin kubeconfig file. Instead what you can do is grab one from any of the control plane nodes and run kubectl manually, e.g.:
Print a kubeconfig file for the admin user by running this command on any of the control plane nodes:
microk8s config > kubeconfig

Then manually move this to ~/.kube/config on your worker node, and install kubectl, e.g. with sudo snap install kubectl --classic
cp /path/to/kubeconfig ~/.kube/config

# install kubectl, e.g. with snap
sudo snap install kubectl --classic
kubectl get pod

Hope this helps!

OK, thank @neoaggelos, I'll try it.

@neoaggelos，According to what you said, it is configured, but the slave node still cannot use the kubectl command

@jepson66 is it possible you have an alias of microk8s.kuebctl to kubectl? Could you try calling directly /snap/bin/kubectl and use the  --kubeconfig <path_to_kubeconfig> just to be sure we are not picking up any config we are not supposed to?


[Auction] ‘Register to bid’ form is impossible to submit after validation errors

Martsy ticket: https://github.com/artsy/microgravity/issues/1104

maybe the new force version fixes this?

This ought to have been addressed on our side by https://github.com/artsy/eigen/pull/1645

done for now. Individual updates will be tackled with new issues/epics


WebSockets and HTTP sharing the same port using request headers

RFC 6455 doesn't mandate that a WebSocket server implementation be able to share the same port with HTTP, but the protocol was designed to allow the possibility.
Currently, WebSocketServerProtocol.handshake doesn't test for the "Upgrade: websocket" header. This doesn't cause any problems because only a WebSocket client would be able to finish the handshake process, but it does appear to rule out port sharing.
It would be convenient in some cases to be able to pass something like an HTTPServer into the WebSocketServer constructor and have requests without the "Upgrade: websocket" header be forwarded to it.
I realize that just putting WebSocket traffic on its own port solves the same problem more easily in most cases, so this idea probably isn't worth implementing if it would take a lot of effort.

Indeed, I didn't want to implement a HTTP server, only a websocket server (unlike e.g. aiohttp).
You can /probably/ inherit or wrap WebSocketServerProtocol into something that handles HTTP. I made an effort in the design of the API not to rule out this possibility immediately, but I never tried it, so it's entirely possible that it doesn't work...
If you try it, I'm interested into hearing about the results :-) However I suspect it will always be easier to run on a different IP or port.

I also need this feature, because it will make deployment more easy when been packaged by docker and other engines. Sharing the same port will make it easy to design the port forwarding : )

I just implement web ssh (https://github.com/ghostplant/websocket-myssh-tunnel.git) using this websockets library, but listening on two ports (8022/8023) seems to be ugly. I am finding a solution.

I believe the Docker best practice is to run different services in different containers, so you shouldn't serve static contents and websockets from the same container?
Supporting static file isn't enough, someone will ask for dynamic stuff shortly thereafter...

In your case, ghostplant, it sounds like you can use a regular web-server with server-side proxying, and have it proxy requests on a specific path into the websocket port. Since you're already using Docker, you can easily set up nginx to do that.

Firstly, Python Flask / Java Tomcat based websocket are designed to share http port and websocket port.
Secondly, if I seperate them two into different docker, when it comes to deploy multiple group of these services, it will be a little more complex, because javascript (from html client side) has to write a complex proceduce to calculate the corrent port of proxy requests to the websocket server.

To some extent, HTTP Request and WebSocket Request have same format so they can be regarded as one service.

I like that this is just a pure-Python websockets program with no framework dependencies, and I wouldn't want that to change. For your port-combining case, ghostplant, you can put nginx and this in the same Docker container, expose just the nginx port of that container, and set up nginx as a reverse proxy forwarding one path to the non-exposed websocket port and serving the other path itself, thus getting a container with one visible port serving both websocket and http requests.

I have to say that I don't aim at competing with Tomcat ;-) More seriously, websockets isn't designed to support HTTP(S). The scope of this issue is to make it easier to integrate with a third-party server.

So can you add a hook to allow users to implement handling HTTP event by themselves? Current "handshake" method in server.py doesn't satisfy idempotency so if users inherit that Protocol, they have to re-implement most of the codes.
I suggest two ways to support this hook in server.py, approximately adding 2-8 lines. Can I suggest the PR?

Of course you can submit a PR, that's the best way to describe the approach you're proposing.

I hacked together a simple subclass of WebSocketServerProtocol that can also serve regular HTTP requests. Something like this:
class HttpWSSProtocol(websockets.WebSocketServerProtocol):
    async def handler(self):
        try:
            request_line, headers = await websockets.http.read_message(self.reader)
            method, path, version = request_line[:-2].decode().split(None, 2)
        except:
            self.writer.close()
            self.ws_server.unregister(self)
            raise

        # TODO: Check headers etc. to see if we are to upgrade to WS.
        if path == '/ws':
            # HACK: Put the read data back, to continue with normal WS handling.
            self.reader.feed_data(bytes(request_line))
            self.reader.feed_data(headers.as_bytes().replace(b'\n', b'\r\n'))
            return await super(HttpWSSProtocol, self).handler()
        else:
            try:
                return self.http_handler(method, path, version)
            finally:
                self.writer.close()
                self.ws_server.unregister(self)

    def http_handler(self, method, path, version):
        response = '\r\n'.join([
            'HTTP/1.1 404 Not Found',
            'Content-Type: text/plain',
            '',
            '404 Not Found\n%s %s.' % (method, path),
        ])
        self.writer.write(response.encode())

async def ws_handler(websocket, path):
    pass

start_server = websockets.serve(ws_handler, '<IP_ADDRESS>', port, klass=HttpWSSProtocol)

It's unfortunate that we'd need to read the request headers twice for the WS case, and I guess there's where a PR could simplify a bit. Full working (but very hacky) code in https://github.com/tgwizard/touch-down

It's probably worth mentioning that load balancer health checks (on, for example, AWS, which now supports Websockets natively) are often http-only. Right now an easy workaround is to just use a second port and http.server for a trivial health check (respond to everything with 200), but it would be nice to be able to actually check the health of the websockets server itself, since that's ultimately what matters.
AWS limits successful response codes for health checks to be in the 200-399 (inclusive) range, so unfortunately you can't use the 101 response to pass the health check.

On that topic, other people have had issues with load balancer health checks that just opened a TCP connection. This worked but filled the logs with errors.

One solution would be a hook just before key = check_request(get_header) in WebSocketServerProtocol, that could be implemented in subclasses that don't want to proceed with the WebSocket handshake. I'm not very enthusiastic about that.

In my own work, I'm finding there are other use cases where a hook for normal HTTP requests seems to make sense.
One is if you want to expose an API on the server for callers to query something about the state of the websockets process.  Another is if you want the server to be able to receive data out-of-band via HTTP.  In both cases, it seems like an unnecessary step for the caller to have to "wrap" such one-off API calls in a websocket connection (and similarly, on the server-side, for the server to have to process it as a websocket connection).
In terms of where such a hook could go, it seems like it might make more sense to go in WebSocketServerProtocol.handler() before the call to handshake(). This is because, semantically, it seems to make more sense to call handshake() only if you actually want a websocket connection.
There is a second benefit to putting a hook in handler() before handshake(). It relates to a comment I made here about handling 404's.
Currently, to return a 404, it seems like the only way is to override get_response_status().  But get_response_status() happens relatively late in the process (e.g. after calling check_request()). In the usual case where a 404 depends only on the path, it seems like there should be a way to return a 404 before the handshake even begins. This could be done in the same place as the (non-ws) HTTP hook I'm suggesting above (i.e. before handshake() in handler()). This would let 404-handling be on the "fast path" (where it probably should be).
Putting a hook where I'm suggesting would require some minor refactoring like calling read_http_request() in handler() before handshake() instead of inside handshake().

Yes, I think a hook on the server-side just before handshake would be appropriate.
Perhaps that hook should replace get_response_status, perhaps not.
I may have strong opinions about the API we choose :-)

The way I did it was to add a pre_handshake() method containing the boilerplate, but the hook is still get_response_status() (called by pre_handshake()).

Just to clarify, the patch I posted in PR #202 keeps the API exactly the same as before.  All it changes is when get_response_status() is called, namely before handshake() instead of during.
The patch also moves the bits in handshake() that aren't specific to websockets to be called before handshake(). This way get_response_status() can access the same general attributes as before like path, origin, etc. Moving these bits has the additional benefit of simplifying handshake() and making it responsible only for the websocket-specific logic.
I will finish adding a couple tests to PR #202. Documentation changes should I think wait until after PR #199 is committed, because the changes would be on top of that (and appear to be minimal, from what I can tell, since the patch doesn't change the API). Thanks!

Given the very large overlap between the goals of get_response_status() and the extension point discussed here, I think it makes sense to change get_response_status() into a more generic API, which I drafted in #248 with a new API: process_request(). Dropping the get_response_status() keeps things simple.
process_request() only has access to path (== self.path) and request_headers (== self.request_headers). It may also poke into self.raw_request_headers if needed. That's sufficient to access origin with self.request_headers['Origin'] if needed.
I agree with postponing the documentation changes to #199, after we make a decision on the API.

Everyone who contributed to this issue: thanks for you inputs; can you comment on #248 to tell me if it solves your use case? Thanks!


Update to 1.0.0-alpha

I've made a few updates for Rust 1.0.0-alpha on https://github.com/brookst/image/compare/update-nightly
I haven't finished updating everything as I'm stuck on errors of the form:
error: mismatched types: expected `&mut color::Rgb<T>`, found `&_` (values differ in mutability)

Hopefully I'll solve those and submit a PR but I'm submitting my changes so far in case someone else wants to work on this.

I think the error is because let &Foo(_) = x; should be changed to let &mut Foo(_) = x; when x is mutable.

Ah, correct. That fixed it but @jameson-ernst beat me to it. Good to know how to fix up my own code though, thanks.

Can we publish this on crates.io?


Controller, Screen rendering issue [1.12] [Forge <IP_ADDRESS>7]

Hi,
Thanks for soilving the previous issue,
I now have a new one, I don't know if that's modpack related or not, but I crash everytime I try to open the controller block, I receive the following error :
The game crashed whilst rendering screen Error: java.lang.NullPointerException: Rendering screen
I don't know what's causing it, if you need, my modpack is "Bananonymous's Modpack" and it's public, Please help me sort this issue out so we can profit of your nice mod :D Thanks in advance.

This should be fixed in latest version


docs/README.md errors

It seems the Docker image is not the preferred installation route anymore and this should be reflected in the docs. Also, -h is not a valid option for satosa-saml-metadata, it is --help.
Third: on Ubuntu 16.10, python 2.7 is the default python interpreter and causes some awkward python versioning entanglement. A solid, working python3 environment can be built using:
# apt install python3 python3-setuptools virtualenv python3-pip
# virtualenv -p /usr/bin/python3 py3env
# source py3env/bin/activate
(py3env) # pip install satosa

See also #65 with regards to the Docker image.
Thank you for your report. We will update our documentation.
Also as a side note, as a Python developer I always recommend using virtualenv for development or production. Even if the underlying OS supports the needed version of Python.

Should be fixed with PR #75.


[helm] WATCH_NAMESPACE not WATCH_NAMESPACES

Update the deployment to use the correct env var name.
Solves: #939

Yes, it's definitely WATCH_NAMESPACE


Incorrect view or like count?

The blog https://www.benjamincarlson.io/blog/using-react-useeffect in your website has more likes than views. Is this a possible bug or am I missing something? I have attached a screenshot below.

Thanks for bringing this up. I manually fixed the issue by resetting the likes. It looks like this is a bug. The user can manually type in the url (with the api) and increment the likes over and over. Anyone is welcome to create a pr and try to fix this. I don't have time at the moment but I'll definitely look more into this.


Stencyl Nix package?

I'm new to NixOS (running 17.03), and I'd like to install Stencyl. It is a game engine. There are installation instructions available for Debian-like systems here, but I'm not sure how to source the correct dependencies for NixOS. Would anyone be able to help me set up a stencyl/default.nix package? It would be great if we could merge this upstream too.

translated from this guide: http://community.stencyl.com/index.php/topic,32022.0.html

boehm-gc
libXext
libxtst
libXi
ncurses
libXt
libXpm
libXmu
libXp
gtk2
atk
cairo
expat
fontconfig
freetype
glib
xorg.libICE
pango
libpng
libSM
libX11
libXau
libXcursor
libXdmcp
libXfixes
libXinerama
libXrandr
libXrender
zlib
nss
nspr
curl
alsaLib

You will also need to use callPackage_i686 instead of callPackage (since 32-bit only support).
jdk8 is also in nixpkgs. Since it seems to be a proprietary package, you probably also need to set the library path manually like in this package: https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/security/gorilla-bin/default.nix#L30

Cool, thanks @Mic92. I'm going to give writing the nix file a go.

Update:
I managed to get Stencyl running in my environment. I've included the default.nix file below; here are the steps I took to get it working:

Downloaded and extracted the 64 bit Linux install file from http://www.stencyl.com/download/get/lin64/ in the same directory as default.nix inside a directory called src. Note the URL responds with a tar.gz download file. However, I had trouble getting fetchurl to work with this URL because it doesn't end with a .tar.gz -- is there any way to force recognition of the tar.gz bundle, so it unpacks it appropriately?
I had to change the src/Stencyl bash executable to simply use java instead of the bundled run-time. This is because makeWrapper is used in the installPhase, making java available in the executable's path. Is there is nicer way to do this directly in default.nix?
Install with nix-env -f default.nix -i stencyl.

Any other ways I can improve this?
{ pkgs ? import <nixpkgs> {} }:

let
  version = "1.2.0";
in
  pkgs.stdenv.mkDerivation {

  name = "stencyl-${version}";

  src = ./src;

  buildInputs = with pkgs; [
    makeWrapper
  ];

  /*unpackCmd = ''*/
    /*tar -xf $curSrc --one-top-level=stencyl*/
  /*'';*/

  installPhase = let
    dependencies = with pkgs; [
      boehmgc
      xorg.libXext
      xorg.libXtst
      xorg.libXi
      xorg.libXt
      xorg.libXpm
      xorg.libXp
      xorg.libXmu
      xorg.libICE
      xorg.libSM
      xorg.libX11
      xorg.libXau
      xorg.libXcursor
      xorg.libXdmcp
      xorg.libXfixes
      xorg.libXinerama
      xorg.libXrandr
      xorg.libXrender
      ncurses
      gtk2-x11
      atk
      cairo
      expat
      fontconfig
      fontconfig-ultimate
      freetype
      glib
      gnome2.pango
      libpng
      zlib
      nss
      nspr
      curl
      alsaLib
      jdk
    ];
    libPath = pkgs.stdenv.lib.makeLibraryPath dependencies;
  in ''
    mkdir -p $out/bin $out/share/stencyl
    mv * $out/share/stencyl
    makeWrapper "$out/share/stencyl/Stencyl" "$out/bin/stencyl" \
      --prefix LD_LIBRARY_PATH : "${libPath}" --prefix PATH : "${libPath}"
  '';

}

Jdk probably does not belong to library path. If it is needed usually there is a shell script calling java.

@Mic92 you're right, Stencyl comes with its own java executable. However, I ran into a problem using it -- I kept getting an error no such file or directory with no other information. Changing to java fixed that problem and started Stencyl. However, trying to build a game inside Stencyl fails due to a similar error when running the bundled haxe and haxelib executables: no such file or folder with no further information. I'm not sure how to move forward -- callPackage_i686 doesn't affect the outcome either. Any thoughts?

So, I've made some progress. I'm now using patchelf to reassign the interpreters for the bundled executables with one in the Nix store. Below is my updated default.nix file.
I am getting an error now though, in which a bundled executable, $out/share/stencyl/plaf/haxe/haxelib, fails to run due to a missing shared library, $out/share/stencyl/plaf/neko-linux/libneko.so. The shared library is bundled with Stencyl; I'm not sure how to fix this error. Any ideas @Mic92 ?
{ pkgs ? import <nixpkgs> {} }:

with pkgs;

let
  version = "1.2.0";
in
  stdenv.mkDerivation {

  name = "stencyl-${version}";

  src = fetchurl {
    url = "http://www.stencyl.com/download/get/lin64/";
    name = "Stencyl-64-full.tar.gz";
    sha256 = "0adgsisk95hp0kiwzj49nb6w2d8g6hi0snkqbp1l7x5mhgf00zf2";
  };

  buildInputs = [
    file
    makeWrapper
  ];

  unpackCmd = ''
    tar -xf $curSrc --one-top-level=stencyl
  '';

  installPhase = let
    dependencies = [
      boehmgc
      xorg.libXext
      xorg.libXtst
      xorg.libXi
      xorg.libXt
      xorg.libXpm
      xorg.libXp
      xorg.libXmu
      xorg.libICE
      xorg.libSM
      xorg.libX11
      xorg.libXau
      xorg.libXcursor
      xorg.libXdmcp
      xorg.libXfixes
      xorg.libXinerama
      xorg.libXrandr
      xorg.libXrender
      ncurses
      gtk2-x11
      atk
      cairo
      expat
      fontconfig
      fontconfig-ultimate
      freetype
      glib
      gnome2.pango
      libpng
      zlib
      nss
      nspr
      curl
      alsaLib
      jdk
    ];
    libPath = stdenv.lib.makeLibraryPath dependencies;
    binPath = stdenv.lib.makeBinPath [ psmisc ];
  in ''

    # patch ELF interpreters and RPATHs
    find -executable -type f -exec file {} \; | \
    grep 'ELF.*executable.*interpreter' | \
    awk '{print $1}' | \
    tr -d ':' | \
    while read elf_executable; do
      echo "Patching ELF interpreter for $elf_executable"
      patchelf --set-interpreter "${stdenv.glibc}/lib/ld-linux-x86-64.so.2" --set-rpath "$rpath" "$elf_executable"
    done

    # install
    mkdir -p $out/bin $out/share/stencyl
    mv * $out/share/stencyl
    #--prefix LD_LIBRARY_PATH : "${libPath}" \
    makeWrapper "$out/share/stencyl/Stencyl" "$out/bin/stencyl" \
      --prefix LD_LIBRARY_PATH ':' "$out/share/stencyl/plaf/neko-linux/libneko.so:${libPath}" \
      --prefix PATH ':' "${binPath}"

  '';

}

Can you add this as a pull request? Then it is easier to comment or edit.

@Mic92 PR is up: https://github.com/NixOS/nixpkgs/pull/24881

Closing issue as I can't get the bundled Haxe dependency working correctly. Nixpkgs has a version of Haxe whose source is modified, and it is unclear how to integrate that with Stencyl. Hopefully someone with better knowledge of Haxe will be able to add this package to the repo. In any case, I personally no longer need Stencyl.


partial deploys don't put a message on the console

full deploy says stopping flows then starting flows.
I think it would be good for the partial redeploy options to put something on the console as well, just so it's "provable" that the message got there from the UI and that it was processed.

Already done - will be in next release:
13 Mar 10:28:41 - [info] Started modified nodes

or
13 Mar 10:29:26 - [info] Started modified flows


Adds link to the temporary alpha docs

Adds a link to the alpha docs in the alpha read me, to my knowledge it's not publicly listed anywhere ¯_(ツ)_/¯

to my knowledge it's not publicly listed anywhere

Yes, it's: https://github.com/callemall/material-ui/blob/master/ROADMAP.md#next. I think that it's a good idea to add it in the homepage. Still, we could give a bit of context.

Ohhh, I think that PR was targeting the master branch

I didn't replace the existing links because I figured that by the time we launched the alpha material-ui.com would be the host (rather than the temporary firebase url).
Also, there are some pages that exist on the master documentation website that don't exist on alpha documentation site (e.g. Require Knowledge).
That being said I did just go ahead and replace the very first link (to the "documentation site") and removed the link I added, I think that makes slightly more sense. We'll have to remember to change it back to material-ui.com though once we switch that dns for that over.

We'll have to remember to change it back to material-ui.com though once we switch that dns for that over.

I don't think that it's an issue as we already have to do it for different other locations.

👍


fixed about us brand logo link

fixed #703
Closes #703
https://github.com/codervivek5/VigyBag/assets/93243210/ee02d941-20c5-4c90-890b-0969ef17cdf9

@codervivek5 please review my PR

kindly solve merge conflict

@codervivek5 conflicts have been solved , kindly review the PR

kindly solve conflict then i will merge it

@codervivek5 check now


Support MCMCDiagnosticTools 0.3 and MCMCChains 6

This PR updates the MCMCDiagnosticTools and MCMCChains compat entries and improves relative_ess.
If you have time, maybe you could have a quick look @sethaxen since you implemented the recent improvements of ess in MCMCDiagnosticTools?
Closes #73.

I would suggest removing Turing from the tests completely - instead one could just save the output of a sample run for all relevant model.

I will go with this option and update the PR accordingly.

Tests pass now, and the cached samples seem to yield similar results as the current runs on the master branch.


Make auto_release_ptr bool-convertible

Could we use something like this?
#include <memory>

struct ReleaseDeleter
{
    template <class T>
    void operator()(T* x) {x->release();}
};

template <class T>
using auto_release_ptr = std::unique_ptr<T, ReleaseDeleter>;

Indeed, I've been thinking of doing that for a while now (but using a typedef since VS 2012 doesn't support defining types with using).

Done.


Exclude few folders in one filter

Hey, have repo that include two folders, for which I don't want to run some steps, tried following:
      - uses: dorny/paths-filter@v2
        id: changes
        with:
          filters: |
            ga:
              - '!.github/**'
            infra:
              - '!infrastructure/**'
            ga-infra:
              - '!.github/**'
              - '!infrastructure/**'`

Got this results:
Results:
Filter ga = true
  Matching files:
  infrastructure/src/resources/liquibase.ts [modified]
  src/main/java/com/.../file.java [modified]
Filter infra = true
  Matching files:
  .github/workflows/document_tests.yml [modified]
  src/main/java/com/.../file.java [modified] [modified]
Filter ga-infra = true
  Matching files:
  .github/workflows/document_tests.yml [modified]
  infrastructure/src/resources/liquibase.ts [modified]
  src/main/java/com/.../file.java [modified] [modified]

ga and infra looks good, expected that some folders not match, but in ga-infra I expected to see only src/main/java/com/.../file.java because other excluded
Can you point me what I did wrong or this not possible to implement, tried to read picomatch not get answers ..

@oleksandr-kinship
I had the same problem recently, but it seems that the negation operator is not supported.
Please also check the following related issue

https://github.com/dorny/paths-filter/issues/106
https://github.com/dorny/paths-filter/pull/151

I'd be happy if it's the same as GitHub's paths.

@oleksandr-kinship
I had the same problem recently, but it seems that the negation operator is not supported. Please also check the following related issue

exclude files or dir #106
Proposing v3.0.0 with updates and new features #151

I'd be happy if it's the same as GitHub's paths.

Thanks, it works for single rule but not in combination..
so I was tried another action, for me in general it's less comfortable, but at least it works fine so far,
here is example
      - name: Get changes
        uses: tj-actions/changed-files@v38
        id: changes
        with:
          files_yaml: |
            non-infra:
              - '!.github/**'
              - '!infrastructure/**'

      - name: Log non-infra changes
        shell: bash
        run: |
          echo "Is there changes for non-infra: ${{ steps.changes.outputs.non-infra_any_changed}}"
          echo "List of all non-infra changed files: ${{ steps.changes.outputs.non-infra_all_changed_files }}"

It appears that !foo is returning a list of files from the entire folder that do not match foo, instead of culling the existing filepaths from other lines. The underlying minimatch/picomatch libs are working as expected.
In our case, our filter was previously
- app-*/**
- !app-ui/**

but I'm pretty sure that resulted in a union of:

everything in app-*/** (including app-ui)
plus everything that didn't match `app-ui/**

resulting in a file list that includes everything in the folder as triggering a rebuild.
Instead, we changed to
- app-!(ui)/**

which is what we wanted. That syntax is described on picomatch's docs, which is what this action uses.


Move aggregation to country before tail filter

This PR addresses issue #
Please Check

[ ] Are the JSON schemas updated?
[ ] Are tests passing?

 Location page header rendering after vaccination block


How to configure rule severity

Hey, Thanks for your great work.
It seems that there is no way of configuring rule severity, I am wrong?
SonarQube is showing rules for typescript and many of them are considered "major" "bug" type (some of them are "smells" but still "major").
I cannot find a way how I could do it. I've tried using severity, like so (tslint.json):
        "indent": {
            "options": [
                true,
                "spaces"
            ],
            "severity": "warning"
        },

And this doesn't work.
So, to sum up, could some one tell me how to :

set different issue types
set different issue weight/severity

Thanks!!

You override those settings in the SonarQube admin interface itself - the plugin puts some best-guess defaults in (if you disagree with those then I'd be interested to hear your views, it was a fairly arbitrary decision by me so far).
Hit the Rules tab in your admin interface, pick the rule you want to change and then the Change button to alter the severity. You will probably need to re-run analysis to get the altered rule setup to be recognised by any project.

I'm not sure that you can change the Bug vs Smell vs Vulnerability through the admin interface, it's not something that's even been a requirement for me.

Thanks for your reply.
For me it is a bit fuzzy what rules are overtaken by what.
In context of c# rules we have every configuration and rules sheet in different files - which are then configured to be used in sonarqube. Thanks to that If by some chance settings in sonarqube are safe.
And configuring typescript, one thing was surprising for me. I saw rule list in sonarqube and in order to disable rule I could edit my tslint.json but I Imagine I can also disable rule in sonarqube right?
So surprising part was: what has priority.
And now when I think of it - why do I even need tslint.json if all rules are already there (sonarqube) and I can only enable/disable rule in tslint.json. I guess for configuring exact rule right?
It would be just awesome if this would be 1-1 (in favor of file configuration) because  now I can see bunch of rules (all are kinda enabled - but I know that they aren't) and I am not sure if I should spend my effort into configuring it in sonarqube to be one day surprised that someone accidentally reverted it and I cannot go back :)
As far for severity, in most cases I do agree with it, but I don't think "space-related-rules" should be major because in the end code will be just harder to read :)

It's different to the C# setup because the C# scanner is the thing actually doing the analysis, whereas for the TypeScript scanner it offloads that to the tslint tooling. That means you're configuring things in two places, which is awkward but you can make it easier.
I tend to just enable all the TypeScript rules in SonarQube, and then control which ones I actually want reported on by enabling or disabling them in tslint.json. That way you're really only configuring things in one place, and your local runs of tslint will match SonarQube's reporting all the time.
There's no real priority between the rules defined on both ends, it's a collaboration - disabling a rule in SonarQube won't stop tslint reporting the issue back to the plugin, we just won't record the breach. Similarly enabling a rule in tslint won't report it in SonarQube unless you've also enabled the rule.
Which space-based rules are major that are tripping you up? I'd thought purely-stylistic ones I'd allocated as minor so that might be a bug.

Ok, I think I can live with it although I think severity should be configured by tslint.json.
It is actually possible in it's schema.
It seems that rules are set to different severity:

But

I've got tons of major of:

Consecutive blank lines are forbidden
missing whitespace
statements are not aligned
parameters are not aligned
misplaced opening brace
expected nospace before colon in call-signature

Ah ok, I'll take a look at those - some of them are to keep it in sync with the Javascript plugin (since the same concerns broadly apply) but I'm surprised at a couple being down as major.
The trouble with severity in the tslint.json file is two-fold:

Rules have a default severity defined by the plugin at start-up time - not at analysis time, so I won't have an example tslint.json file to pull severities from (this may be workaroundable if the project had its own quality profile, I'm not sure, but I think the plugin would have to create it on your behalf)
If there were two projects analysed with different severities listed in their config file, which should the plugin choose? I'm using the plugin on an instance with 40+ projects operated by different teams in a largeish business, all of whom will have different requirements for their quality gates
The tslint.json severity support didn't exist back when the plugin was created, and one of the more recent goals of the plugin is to try to avoid knowing too much about how tslint gets configured and just trust its output

I might have a look at custom profiles being created by the plugin, though to be honest I'd be surprised if it's a supported feature of SonarQube.


Bitbucket PR pipelines dont pull $BITBUCKET_PR_DESTINATION_BRANCH automatically

Prior to making any comparisons to the destination branch we need to fetch it, like so:
git fetch origin $BITBUCKET_PR_DESTINATION_BRANCH:$BITBUCKET_PR_DESTINATION_BRANCH

Note: This will require PullrequestProviders to expose the name of the provider so we can add special behaviors like these.


keybind for refreshing presets

if presets aren't loaded properly, i would like a hotkey to be able to refresh presets, in order to not have to open the sidepanel and click the button

In which case you have a time that the presets are not loaded correctly? Normally those should be kept refreshed automatically.

when opening multiple clients, some of them will load the presets partially.

Ok, thanks for the log. So the refresh button keybind would be a bandage fix for the root issue that is the presets don't refresh when clients update.
We need to fix the refresh issue propperly so no refresh keybind is needed.


Reworked the regex for parsing an IP address

Update gather.py

Hey thanks for the pull request. I am am going to close it because I want a stricter regex. Lets connect on LinkedIn my useranme is rajivgupta2. Also I am going to extract the ping fuctionality anyway. I want to create a whole range of little utilities that get installed with pip install gogather. I will reference all future utilities in the help file. Also ask your coworker to connect with me (the old guy ;). I am old too!

That sounds good! Yeah after I posted it I immediately thought you did it
to be strictly for an IP and mine would determine 999.999.999.999 was an IP
haha.
On Thu, Nov 28, 2024 at 4:12 PM rantlabs @.***> wrote:

Hey thanks for the pull request. I am am going to close it because I want
a stricter regex. Lets connect on LinkedIn my useranme is rajivgupta2. Also
I am going to extract the ping fuctionality anyway. I want to create a
whole range of little utilities that get installed with pip install
gogather. I will reference all future utilities in the help file. Also ask
your coworker to connect with me (the old guy ;). I am old too!
—
Reply to this email directly, view it on GitHub
https://github.com/rantlabs/RANT/pull/3#issuecomment-2506761202, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AA44LNYGXYNTCAQQX2RY4AT2C6BMXAVCNFSM6AAAAABSIA2IEKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMBWG43DCMRQGI
.
You are receiving this because you authored the thread.Message ID:
@.***>


Fix link to webpack

Currently erroneously links to https://github.com/WhitestormJS/whitestorm.js/blob/dev/webpack.js.org
I suggest this should link to docs on usage docs for whitestorm + webpack instead.

@timoxley Thanks


Dev

Codecov Report

Merging #11 into master will increase coverage by 1.52%.
The diff coverage is 80.00%.

@@             Coverage Diff              @@
##             master      #11      +/-   ##
============================================
+ Coverage     94.03%   95.55%   +1.52%
- Complexity      188      190       +2
============================================
  Files             1        1
  Lines           486      495       +9
============================================
+ Hits            457      473      +16
+ Misses           29       22       -7

Impacted Files
Coverage Δ
Complexity Δ

src/JsonX.php
95.55% <80.00%> (+1.52%)
190.00 <2.00> (+2.00)

Continue to review full report at Codecov.

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


Created support for IP-cameras through RSTP

Able to take take input form ip cameras for running demo samples

@durgabhavaniv please rebase to the latest state

@vladimir-dudnik i rebased and created new pull request

@durgabhavaniv thanks, then this PR can be closed, I think?


Nock test suite breaking on Node 8.x

My project's test suite breaks
Nock's test suite breaks

My tests are breaking in Node.js 8.
Something simple like:
nock('http://example.com')
    .get('/')
    .reply(200, 'Hi!');

Doesn't get intercepted.
Using Node.js 7 it does.

@stevenvachon If you need to mock something in Node.js 8 now I just bashed create-test-server together.
No docs yet but you can see example usage here:
https://github.com/lukechilds/clone-response/blob/master/test/clone-response.js

@lukechilds thank you, but I transitioned from a real test server to nock a while ago and don't want to go back to it

I also run into this issue I see there is already a PR to make nock node 8 ready. I hope it will reviewed fast.

@StarpTech that PR doesn't pass tests, so it's not yet of any use.

@stevenvachon He said that there is only one browserify test failing. Thats a great base. BTW I think I will change to https://github.com/ctimmerm/axios-mock-adapter in combination with the excellent axios http request library. This not a solution for everybody but a much cleaner way to mock http calls in node.

This PR seems to fix the issue: https://github.com/node-nock/nock/pull/929
For my own project, where I only use nock to mock responses, I've monkey-patched nock to get the tests to pass: https://github.com/Rob--W/cors-anywhere/commit/70400ab166515db9b8fd117f3d208b4960ee846a (tested with nock 8.2.1).

Should be fixed in 9.0.14. Please reopen if issue persists.


Modify typos 修改错别字

实用->使用

[x] Have you followed the contributing guidelines?
[x] Have you explained what your changes do, and why they add value to the Guides?

Please note: we will close your PR without comment if you do not check the boxes above and provide ALL requested information.

"实用" and "使用" have the same pronunciation, but "实用" means "
practical", "使用" means "use", here it should be "使用".

OK
pon., 12 sie 2019, 02:01 użytkownik Mike Linksvayer <
<EMAIL_ADDRESS>napisał:

Merged #1043 https://github.com/github/opensource.guide/pull/1043 into
master.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/github/opensource.guide/pull/1043?email_source=notifications&email_token=AMXPFWVZR7T44BZATG5HMFDQECR65A5CNFSM4IKF3AP2YY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOS7WVQVA#event-2548914260,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMXPFWWMZRIJIGAAMU2X2I3QECR65ANCNFSM4IKF3APQ
.


'target type' command

I don't know if this issue was present in previous versions, but in the newest voyager v1.10 this command isn't working although being mentioned in documentation.
However 'target add list type' is working instead.

Hello,
Thanks for using operative framework,
Yes this is a mistake, target type command as not found for now.
Thanks you for this report, i will make this soon for the next build.


Link fails when using UI_TYPE external

I'm using current tip of develop (54e1fb847d046f97b23b94d9c002efe29b3a4240). I'm attempting to integrate #394 into my project, I added the line to my add_plugin call:
dpf_add_plugin(MyPlugin
  TARGETS vst3
  UI_TYPE external
  FILES_DSP
      MyPlugin.cpp
  FILES_UI
      MyUI.cpp)

but the build fails with:
/usr/bin/ld: cannot find -ldgl-system-libs-definitions: No such file or directory

I think a call to dpf__add_dgl_system_libs is missing in this code path. Perhaps it should be added here?
diff --git a/cmake/DPF-plugin.cmake b/cmake/DPF-plugin.cmake
index fcba2e12..2c2ca6b1 100644
--- a/cmake/DPF-plugin.cmake
+++ b/cmake/DPF-plugin.cmake
@@ -116,6 +116,7 @@ function(dpf_add_plugin NAME)
       dpf__add_dgl_opengl("${_dpf_plugin_NO_SHARED_RESOURCES}")
       set(_dgl_library dgl-opengl)
     elseif(_dpf_plugin_UI_TYPE STREQUAL "external")
+      dpf__add_dgl_system_libs()
       set(_dgl_external ON)
     else()
       message(FATAL_ERROR "Unrecognized UI type for plugin: ${_dpf_plugin_UI_TYPE}")

I think it is working in the examples because all the examples are in one big CMake script, so this path gets called eventually.

@AnClark have you successfully used this as a submodule in another project?

Seems like I need to create some out-of-dpf external ui plugin of sorts, to test this behaviour

@AnClark have you successfully used this as a submodule in another project?

Not yet. I'm porting SynthV1 to DPF, which has a Qt-based UI, but still work in progress (not ready for compilation).
As far as I try, the EmbedExternalUI example in develop branch can successfully compile.

I think a call to dpf__add_dgl_system_libs is missing in this code path. Perhaps it should be added here?

External UI does not really depend on DGL. So I didn't add dpf__add_dgl_system_libs() there.

@thirtythreeforty My pleasure!


x/sys/unix: add missing values from syscall pkg to enable complete migration

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
go tip
What operating system and processor architecture are you using (go env)?
Ubuntu 16.04 and Fedora22, Red Hat 7.x on ppc64le & ppc64
What did you do?
Trying to migrate Go code from syscall to sys/unix as described in the golang syscall package documentation https://golang.org/pkg/syscall/.  This was the suggested solution for issue https://github.com/golang/go/issues/19560.  While it is possible to fix just the case that is described in this issue, that is not a complete solution.  We want to avoid hitting another issue because of using syscall, so we'd like to migrate use of syscall to sys/unix.  Also having a mixture of references to syscall and sys/unix is confusing since then it is not clear when to use which one.
Issues with migrating from syscall to sys/unix:

syscall.Signal and syscall.Errno need to have a type defined within sys/unix so user code doesn't need to use these to convert signals and errnos to the appropriate integer type for the platform.

I was going to try a change for this based on a suggestion by Ian, but I'm not able to get the generator scripts in sys/unix to work.  I get these errors:
GOOS=linux GOARCH=ppc64le ./mkall.sh
could not determine kind of name for C.TIOCGETC
could not determine kind of name for C.TIOCGETP
could not determine kind of name for C.TIOCGLTC
could not determine kind of name for C.TIOCSETC
could not determine kind of name for C.TIOCSETN
could not determine kind of name for C.TIOCSETP
could not determine kind of name for C.TIOCSLTC
This happened on Fedora22 and Ubuntu 16.04.  If I could get some direction on what this might be that would help.

The structure SysProcAttr is defined in syscall but not in sys/unix.  It is used in the os package, so I don't think it should be moved to sys/unix.  Seems like it needs an equivalent declaration in os.

I think that syscall.SysProcAttr is a different issue to be dealt with differently.  In fact I don't see any reason to migrate that to x/sys/unix.  It's fine where it is.

Hm. Wouldn't that mean still using syscall then? Or is there an alternative for users that's outside of syscall for syscall.SysProcAttr?

@clnperez, yes, still using syscall. There's no alternative. It's part of the API: https://golang.org/pkg/os/exec/#Cmd.SysProcAttr

Then those things that can't be migrated from syscall to sys/unix should be documented so it is clear.  Right now the syscall package documentation just says to migrate from syscall to sys/unix.  Maybe that paragraph just needs a statement to identify the exceptions.

That is the only case:
$ cd $GOROOT/api
$ git grep syscall | grep -v ":pkg syscall" | grep txt:pkg
go1.txt:pkg os, type ProcAttr struct, Sys *syscall.SysProcAttr
go1.txt:pkg os/exec, type Cmd struct, SysProcAttr *syscall.SysProcAttr

If you want to add something minimal to the pkg syscall docs, feel free to send a CL.

Apparently at this point in time the generator scripts in the syscall pkg and x/sys/unix are not in sync with the z files they generate.  I could make the necessary changes to add definitions of Signal and Errno in sys/unix but don't know how to correctly generate all the right files without a lot of extra unrelated  changes or lots of manual changes.
Will changing the comments in syscall/syscall.go update the pkg syscall docs?

@laboger, please wait for https://go-review.googlesource.com/c/37943/

Will changing the comments in syscall/syscall.go update the pkg syscall docs?

Yes. You can send a CL for that part at least.


Discussion on Gluing Model

C.C. @HuStmpHrrr
In the gluing model definition of
Inductive glu_univ_elem_core : glu_typ_pred -> glu_exp_pred -> domain -> domain -> Prop

why do we need two domain types? In the Agda mechanization, sure, we used A ≈ B ∈ 𝕌 j (actually even there, why doesn't A ∈′ 𝕌 j work? Our transport or other lemmas there are all one-sided after all), but here we repeat the structure of A ≈ B ∈ 𝕌 j in the model anyway, and what we need is relating one syntactic term with one domain term.

I got this question while defining the gluing model for substitutions. Even in the Agda mechanization, we used a one-sided definition for the model instead of a binary one.

I think in principle the gluing model is ok to be unary. try to change it to unary. I think it will just work.

Yeah, I will try.

I think that will probably work out better for the subtyping relation. I think you can also try to define subtyping for gluing. it might be a bit twisted.

#132 resolves this.


Portainer deployment in Swarm, as service high availability works, as stack HA doesn't work.

I created in VM a 6 node swarm, 3 managers and 3 workers.
When I deploy Portainer 1.19.2 on Docker 18.06.1-ce (Ubuntu 18.04) using the following command:
docker service create
--name portainer
--publish 9000:9000
--replicas=1
--constraint 'node.role == manager'
--mount type=bind,src=/home/deploy/docker/portainer/data,dst=/data
portainer/portainer
Portainer starts correctly and when I shut down the manager node it is running on, Portainer is started on another manager node.
When I deploy Portainer 1.19.2 on Docker 18.06.1-ce using the following command:
curl -L https://portainer.io/download/portainer-agent-stack.yml -o portainer-agent-stack.yml
docker stack deploy --compose-file=portainer-agent-stack.yml portainer
When i take the manager node down that is running portainer, i get failures like:
failure, unable to retrieve nodes
failure, unable to retrieve endpoint information
After a new login on another manager node
failure, unable to verify Portainer signature
Bringing the failed manager node back up doesn't solve the problems. Portainer keeps
giving failures.
Am I doing something wrong or is https://portainer.io/download/portainer-agent-stack.yml incorrect?

Duplicate of #2271


blank setup window

i tried followed your installation but after the start.bat there's nothing. it's just says "Run Android Emulator with MFF intalled and select emulator's window from the list below selected:"

Which emulator (BlueStacks / NoxPlayer) and which its version are you using?

I use bluestack 5

Try to use BlueStacks 4 or NoxPlayer <IP_ADDRESS>.
I haven't tested BlueStacks 5 yet so it's possible that there issues with capturing.

thanks. it worked now

BlueStacks 5 support added in https://github.com/tmarenko/mff_auto/commit/b09e5da04631bd8a1bc121a0fc4b49679ea16e49
Released in https://github.com/tmarenko/mff_auto/releases/tag/0.8.7


FTP name

Description
Files app removes extension from FTP file name!
(for example .com)

Steps To Reproduce

Open Windows Explorer
Click on the "Add a network location" from the context menu

Requirements

e.g. Fix crash that occurs when...

Files Version
<IP_ADDRESS>
Windows Version
10.0.22621.2428
Log File
N/A

Thanks for the report, I've added this to the project board.


earlytalker: move return out of timeout

Part of this PR is a question: Why would you put that line if (!connection.early_talker) { return next(); } inside the setTimeout?  It looks to me like a non-optimization.
This also adds a log message when a relaying client trips over the early_talker plugin. Yes, I've seen it happen 3 times now, so I'm sure it's happening more often. Just not quite sure how often.

I'm going to reject this.   I think the 'return next()' inside the setTimeout() is what makes this plugin actually work.  e.g. it needs to wait on all clients to see if they are pipelining data when they shouldn't be and then returns next() for those that haven't.

I think the 'return next()' inside the setTimeout() is what makes this plugin actually work.

Ahhh, I see.


Add initial support for feature tap disambiguation.

This PR uses the S2 Geometry Library to add initial support for disambiguating feature taps, here's the behavior in action:
https://user-images.githubusercontent.com/11237600/118893724-e931de80-b8d0-11eb-8dd6-f5ec0efe4014.mov
Limitations
Unfortunately, the maps API does not propagate clicks downwards through handlers. As a result, taps at higher zoom levels, even those that appear ambiguous will have a bias toward markers. We could force disambiguation on all marker clicks, but this would be a trade off at lower zoom levels, where the user would have to make a selection even for very precise marker clicks within a polygon bound.
Due to the way we currently represent geojson features, polygon bounds tend to be larger than one might expect. For example, in the video in this PR, clicking on another letter polygon would still trigger disambiguation between the polygon and the point, even though the loop representing this portion of the polygon is quite far away from the contained point—this is because we presently represent the entirety of the json source on the map as a single feature, not as individual features per feature entity in the geo json.

@gino-m

Hi @scolsen, thanks for the PR and clear explanation. My understanding was that the bounds would only be used to identify which polygons to check against PolyUtil.containsLocation(). In the video about, the behavior appears broken in that, as you mention, the user is asked whether they meant to tap a marker which isn't overlapping the tap target. My understanding was that we'd do the following:

When a polygon is added to the map, add it to a hash map keyed by the S2 cell number at some reasonably high zoom level. The map would be of type Map<S2Cell, Set<GeoJsonPolygon>> or similar. The polygon would be added to all cells that overlap with the bounding box of the polygon (include cells inside the polygon, not just those intersecting w/vertices).
When a user taps the map (anywhere but a marker), calculate the S2 cell of the tapped latlng and get polygons that intersect that cell.
Use PolyUtil.containsLocation() to determine which polygons intersect the tapped latlng.
Show these polygons in the disambiguation dialog.

In the case a marker is tapped, we'd do the same as above, but instead using the marker's latlng location. We would show the list of intersecting polygons plus the tapped polygon.
Does this make sense? Please lmkwyt!

When a user taps the map (anywhere but a marker), calculate the S2 cell of the tapped latlng and get polygons that intersect that cell.

It's this part that proves problematic when using multiple click handlers--but this sounds like the right approach and I think we can do it this way if we drop the GMS json click handler! Just for posterity, here's why it's a problem when using the json click handler:
If the user clicks an arbitrary point on the map, this works, since we'll get a latlng.
However, if the user clicks an actual GeoJson feature, we don't get a single latlng, we get an entire Feature (GMS.data, not ground), which contains all the points making up the corresponding polygon, not just the actual latlng that was clicked (unfortunately). This is why it made more sense to me initially to hash GeoJsonFeatures and their corresponding s2loops (the outer bounds of a polygon, ignoring holes). This means at really low zoom levels (e.g. like zoom 1, when the user is zoomed really far in), we're getting the full extent of the tapped feature, most of which might be off screen, and we have no way of knowing (afaict) where precisely the user tapped.
It really is a huge limitation when it comes to precision. It makes it tempting to just set a single map-wide click handler and maintain lists/queues of features and dispatch on our own, but then we'd have to handle zoom-level  adjustment/correction ourselves...which is also a mess.
Another middle ground, which might be our best option is to handle geojson clicks specifically ourselves, that is:

We parse GeoJson into either a mapping from GeoJsonFeature -> s2cells or s2loops.
We set an onMapClick handler instead of an onGeoJsonClick handler. The onMapClick handler gets the precise latlng the user tapped/clicked at: https://developers.google.com/maps/documentation/android-sdk/events#map_click_long_click_events (vs. the geojson handler which gets us an entire feature extent)
On map clicks we perform lookup ourselves and handling ourselves

This would give us the desired precision at lower zoom levels, and the behavior at higher zooms (zoomed out far) would remain the same, since maps seems to bias toward marker targets at high zoom anyway.
So it sounds like we should drop the geojson click handler in favor of a map click handler and roll our own dispatch. I can try this out and see if it does the trick.

Hi @scolsen, that makes sense. From our last conversation I understood we were dropping the GeoJsonClickHandler for the reason you mention here. In that case, the only click handlers would be on map pins and map clicks, right?

Hi @scolsen, that makes sense. From our last conversation I understood we were dropping the GeoJsonClickHandler for the reason you mention here. In that case, the only click handlers would be on map pins and map clicks, right?

Yep, that's right. I somehow missed the dropping the GeoJson handler part before pushing this PR, but the change shouldn't take too much effort.

@gino-m the map click handler approach isn't going to work, unfortunately. When I remove the geojson click handler the maps API still seems to bypass the map click handler entirely if one clicks in the bounds of a geojson polygon.
This could be stemming from the fact that it seems to treat these polygons as the same things as the other maps polygons under the hood (one needs to add a polygon manager to handle clicks in the geojson layer, even). I don't know, but at any rate I can't get it to work. Maybe I'm doing something incorrectly, but the right approach is non-obvious at least.
https://user-images.githubusercontent.com/11237600/119441801-bb93cd80-bcf4-11eb-8349-b8b0f8bba864.mov
So, it seems like the map click handler approach is really all-or-nothing in terms of the way maps propagates (or rather doesn't) clicks across objects.
I think at this point our best bet might be the following until a better solution crops up:

Keep the current approach using a geo json click handler.
Only disambiguate between overlapping polygons, on polygon taps.

Basically, it seems like the maps API will divert clicks to the right layer whether or not we have a handler for that layer, and it will never propagate clicks to another layer. So in this instance, it doesn't matter if we have alternative handlers. If the user taps an object, marker, polygon, json, w/e, Maps will only send the tap to that layers/object's management bits, ignoring all others.
In other words, we need to roll our own tap position getter if we want that amount of precision. Or I'm just doing something completely wrong.
Is it somehow possible to "arrange" the layers so that the "map" layer is at the top? that would potentially solve our problem too, but then we'd need to handle markers as well.

https://user-images.githubusercontent.com/11237600/119577670-14ad4100-bd89-11eb-8299-0828030a6f60.mov
@gino-m ! All that remains is to remove the s2 import.

@gino-m ! All that remains is to remove the s2 import.

Fantastic!!! 🥇 🗺  👈  ❗
Please let me know when it's ready for another look! If you've address previous comments or they're not relevant please resolve or let me know and I'll do it. Great work!

@gino-m ready for another look!

@gino-m


the issues of add on the joint

Dear Sir,
Currently I am doing research project for my degree. I have some problem with adding an extra point at the middle hip (pelvis), I have change the part connection by following the parameter from [https://github.com/CMU-Perceptual-Computing-Lab/openpose/blob/master/src/openpose/pose/poseParameters.cpp]
I am using 19 points.
The issue now I am facing is about the val.py
when the code function group_keypoints(all_keypoints_by_type, pafs, pose_entry_size=19, min_paf_score=0.05, demo=False) operating, my 'kpts_b" always get the error 'IndexError: list index out of range'.
Hope you can tell me how to add on the point like how you add 'neck' by using COCO dataset.
Thank you so much.

I believe the main milestone here is to understand (the paper) what are BODY_PARTS_KPT_IDS and BODY_PARTS_PAF_IDS,  for this check #8 (you may also find some useful information in other issues). Basically you need to extend them properly (add proper values to the end), and make network to predict additional heatmap for pelvis and additional pafs (you may add two: left_hip->pelvis, right_hip->pelvis or so). The code in grouping will handle it automatically.

Thanks for the reply.
I wonder that for the BODY_PARTS_KPT_IDS and BODY_PARTS_PAF_IDS, do I need to extend it by following the order? because currently I referred the BODY_19N parameter from the CMU-Perceptual-Computing-Lab/poseParameters.cpp

Dear Sir,
Now i think my model could be trained after reading all the others posts.
However, I have some issues with the cocoeval.py problem,
File "/home/cz/.virtualenvs/pytorch/lib/python3.5/site-packages/pycocotools/cocoeval.py", line 223, in computeOks     dx = xd - xg ValueError: operands could not be broadcast together with shapes (18,) (17,)
how did you troubleshoot this for 'neck' last time?

Dear Sir,
I think now my problem is about the cocoapi to evaluate my model, the AP is 0.000 always. May I know how did you configure the API?

To extend this code with new pafs (and new keypoint, BODY_PARTS_KPT_IDS and BODY_PARTS_PAF_IDS need to be extended, as mentioned above. To evaluate through COCO API, you need to pass results in COCO format, it expects 17 keypoints. In validation script keypoints are converted from internal to COCO format.

Thanks for the reply. I have some questions again.
For the validation script, let say I have added on one extra point which is pelvis.
In to_coco_map = [0, -1, 6, 8, 10, 5, 7, 9, 12, 14, 16, 11, 13, 15, 2, 1, 4, 3] here, I tried add one more point, maybe like the neck (-1), pelvis (-8), but the AP still being 0.000
I also skipped the part_id of "pelvis" like how you skipped for "neck", could you tell me which part you have edited also?

COCO evaluation expects 17 keypoints in each pose, so if you have added pelvis as 19th keypoint, you do not need to modify to_coco_map. base_height is the height of network input, image height will be rescaled to it before network inference. You may try to evaluate provided pre-trained model, it should not have zero AP.

if I do not edit the to_coco_map, the 'BODY_PARTS_KPT_IDS' and 'BODY_PARTS_PAF_IDS' will be out of the index. I have tried the whole day, probably it is the problem from dataset, maybe the MPII dataset is required.

What else can help? You see, COCO evaluation expects a file with detection results and gold labels (I believe you make evaluation on COCO dataset). So you may run evaluation for provided pre-trained model, then compare content of this output file with detections detections.json to output file file after your modifications and check the differences.

Hope, it helped.


Groundwork for new config system

This lays the groundwork for the new config file system based on JSON-Schema validation. The necessary infrastructure is there now, but I haven't yet replaced the old machinery yet. We need a squash merge first to update master now and then I will work on the rest.
The JSON schema files are located in resource/schema/<version>/ => https://raw.githubusercontent.com/qooxdoo/qooxdoo-compiler/master/resource/schema/<version>/Manifest.json, <version> referring to the schema version (currently, "v1"). It should eventually be mirrored to https://qooxdoo.org/schema/<version>/Manifest.json which will result in a much nicer "$schema" string.
There is a problem with backslashes in regular expressions in the JSON schema files (regexes with backslashes in them just wont match anything), which I need to investigate, but I have fixed them where they were relevant for the time being.

merging, thank you @cboulanger !


Configure SSL certificate for the API

We can issue a valid certificate for the domain from #124 using Lett's Encrypt. We need to issue a certificate for the domain and configure it on the API gateway.

Time Spent

Date
Activity
Time Spent

3/7/22
Started initial research on Lett's Encrypt and SSL certification
1 hour

Estimated: 3 hours
Actual: In progress


Fixed resource URI when loading resource from Sinopia search results.

closes #1804

This broke because we changed where we got the URI from in the search result, which meant we had a complete URI instead of a partial URI. This obviated the need for the code which added back in the first part of the URI.


Add StringBuilder StringBuffer pages to String folder

[x ] I have read freeCodeCamp's contribution guidelines.
[x ] My pull request has a descriptive title (not a vague title like Update index.md)
[x ] My pull request targets the master branch of freeCodeCamp.
[x ] None of my changes are plagiarized from another source without proper attribution.
[x ] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

Thanks for the PR @trrrey, but we cannot merge this because folder names can only contain lowercase letters, numbers, and dashes. See our style guide for guide articles for more information. Thanks and happy coding!


(FACT-1607) split the default external fact directory into 2 test

I split the 2 tests for the default external fact directory into 2 tests
Updated code style, added risk tags, and TestRail numbers

Tested on:
arista4-32a, ciscoxr-64a%7Bhypervisor=vmpooler%7D, cisconx-64a%7Bhypervisor=vmpooler%7D, cumulus25-64a, debian8-64a, fedora25-64a, osx1012-64a, redhat7-64a, sles12-64a, solaris11-64a, ubuntu1604-64a, windows10ent-64a, windows2016-64a

CLA signed by all contributors.

@johnduarte Updated with your requested changes

@kurtwall Updated with your requests

I'll leave the merge to @johnduarte.


Alignment of images getting messed up

After generating the content from my ghost blog, the alignment of images don't seem to be right.
Also, the table of contents appears to go beneath the images.
Expected behaviour:

Source: https://www.crio.do/blog/backend-development-career/
Current Behaviour:

Temporary workaround:
// Table of Contents
export const toc: boolean = false

in appConfig.js.
This problem only exist when

export const nextInlineImages: boolean = false AND
export const toc: boolean = true

A proper solution must be made in the 'toc' feature.

Temporary workaround:
// Table of Contents
export const toc: boolean = false

in appConfig.js.
This problem only exist when

export const nextInlineImages: boolean = false AND
export const toc: boolean = true

A proper solution must be made in the 'toc' feature.

Thanks for reporting. Please verify.

Thanks for reporting. Please verify.

Yes, this works.
But table of content continues to overlap. I'll disable it for now.
Also, my author and tag pages don't work. Is that how it is supposed to be?

Yes, this works.
But table of content continues to overlap. I'll disable it for now.
Also, my author and tag pages don't work. Is that how it is supposed to be?

Wide and full screen images overlap the ToC by design, this is how it should be. With respect to author and tag pages, they are present but without the base path. There is a routing issue here, but don't know how to best solve this yet. Could you please publish your routes.yaml file that you use in your Ghost installation?

Wide and full screen images overlap the ToC by design, this is how it should be. With respect to author and tag pages, they are present but without the base path. There is a routing issue here, but don't know how to best solve this yet. Could you please publish your routes.yaml file that you use in your Ghost installation?

Plaese open a new issue for every new topic.

Plaese open a new issue for every new topic.


Unable to verify jwt against an RSA PUBLIC KEY

For this I had to extend LcRSA
LcRSA>>fromRsaPublicKeyPemString: pemString
	| nullp bio |
	nullp := FFIExternalObject new.
	bio := LcMemoryBIO fromString: (self cr2lf: pemString).
	[ handle := LcLibCrypto current
		apiPemReadBioRsaPublicKey: bio handle
		with: nullp
		with: nullp
		with: nullp.
	self errorIfNull: handle ]
		ensure: [ bio close ]

LcRSA class>>fromRsaPublicKeyPemString: pemString
	^ self new
		fromRsaPublicKeyPemString: pemString;
		yourself

Extend LcLibCrypto
LcLibCrypto>>apiPemReadBioRsaPublicKey: bio with: rsa with: cb with: uv
	^ self
		ffiCall:
			#(RSA * PEM_read_bio_RSAPublicKey #(BIO * bio , RSA ** rsa , FFIExternalObject cb , FFIExternalObject uv))
		module: self library

Then override:
JWARSASHA256 class>>checkSignature: parts withKey: key
...
rsa := (key includesSubstring: 'BEGIN RSA PUBLIC KEY')
		ifTrue: [ LcRSA fromRsaPublicKeyPemString: key ]
		ifFalse: [ LcRSA fromPemString: key ].
	pubKey := LcEvpPublicKey setRSA: rsa.
...

On top of this I also have a non rsa variant (BEGIN PUBLIC KEY), which I don't use/need at this moment. If you want I can provide you with the LcLibCrypto method and LcRSA method.

The LcRSA and LcLibCrypto are not part of this repository but of https://github.com/PierceNg/OpenSSL-Pharo. Can you add a pull request there and then we add the checkSignature here?

Is it OK to include the extensions of LcRSA and LcLibCrypto in package JSONWebToken-OpenSSL?
Or should I first do a pull request on https://github.com/PierceNg/OpenSSL-Pharo ?

The general rule would be that if it is convenient or helper method of JWT to OPenSSL it should be an extension method. But these methods look useful to OpenSSL and that's why I think they should be there.

So guess we'll have to wait for this pull request to be handled?
https://github.com/PierceNg/OpenSSL-Pharo/pull/4

Yes. I understand that you want to proceed. But if we hack these things away the software dies. So it is an attempt to make it proper. We can still go back having the extrension methods if PierceNg is not responding (which he will soon). If you want to proceed it sometimes better to fork those projects and apply your changeds there and open pull requests. So you can proceed and move back to other repos when the PRs have been integrated

solved via #13

Thanks Norbert!


Restore from snapshot is failing

issue:
Failed to create Volume from Snapshot, snapshot_id 54137281: {Code:E0014, Description:There is no billing information for volume ID 54066413. Please check if you have already deleted this volume, Type:SnapshotSpaceOrderFailed, RC:500} ("Failed to create Volume from Snapshot, snapshot_id 54137281: {Code:E0014, Description:There is no billing information for volume ID 54066413. Please check if you have already deleted this volume, Type:SnapshotSpaceOrderFailed, RC:500}"
Solution:
It should work as per the implementation may be some other issue as these error are not actual one we need to add the description of error properly and then check.

we already have issue
https://github.com/IBM/ibmcloud-storage-volume-lib/issues/5


Fire event after stored procedure finishes executing.

I have a stored procedure, that has a BEGIN TRANSACTION and COMMIT.
Is it possible to fire an event only after the stored procedure finished executing?
Scenario:
Have a Deal table that has Status column.
The stored procedure creates a Deal row with status 0
Then it updates that status from 0 to 1, 2, 3, 4, 5 and ends.
I want my listener to only fire an event when a new deal with status 3 is inserted/updated.
Doing an if (status = 3) would be a bad idea. as the end result of that "Deal" row is actualy status 5 and it should not be actioned.

Hi
you can use the filter. Have a look at:
https://github.com/christiandelbianco/monitor-table-change-with-sqltabledependency/wiki/Use-case:-Where-filter
Regards

Hi
you can use the filter. Have a look at:
https://github.com/christiandelbianco/monitor-table-change-with-sqltabledependency/wiki/Use-case:-Where-filter
Regards

Thanks, I had a quick look at it.
Could you tell me roughly what my filterExpression would look like?
Again, I am receiving 1 insert and 4 update statements at this time without this filter.
Would I filter for "COMMIT" command?

I've tested using that expression, implementing ITableDependencyFilter
I managed to capture the middle update query, when I wanted to capture only the end status (5)

Again, I want to only get an event on the end result when stored procedure finished executing.
It is not possible.


Angular new project creating error occurred.How can fix this all installations are done perfectly with latest modules

🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑
Angular new project creating error occurred.
2019-10-17T05_45_55_373Z-debug.log
Please file any Docs or angular.io issues at: https://github.com/angular/angular/issues/new/choose
For the time being, we keep Angular AIO issues in a separate repository.
🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑

This seems like a problem with your node/npm and not with Angular CLI.
Please have a look at the fixing npm permissions page, common errors page, npm issue tracker, or open a new issue in that issue tracker if the problem you are experiencing isn't known.


Can't install popper.js via NuGet into web project that targets .NET Framework 4.7

CodePen demo

Not applicable.
Steps to reproduce the problem

Create a new web project in VS2017 that targets .NET Framework 4.7.
Open NuGet Manager and try to install popper.js.

What is the expected behavior?

popper.js is successfully installed.
What went wrong?

Got the error message:
Could not install package 'popper.js 1.11.0'. You are trying to install this package into a project that targets '.NETFramework,Version=v4.7', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.
Any other comments?

No.

You should use the latest release of Popper.js which fix that issue :wink:
BTW if you install Popper.js throw Bootstrap, beta 2 is shipped with Popper.js since yesterday :+1:


fixed alignment of privacy policy page + made code organized

Description
fixed alignment of privacy policy page + made code organized
Fixes #652
before :

after:

Screenshots
Checklist

[x] Tests have been added or updated to cover the changes
[x] Documentation has been updated to reflect the changes
[x] Code follows the established coding style guidelines
[x] All tests are passing

@SurajPratap10 I made a mistake in 1st commit that I added things from my previous PR which was not merged because you didn't like it. so I reverted it in the final PR. Please check it out.

@SurajPratap10 Please review this, I have more PRs coming


the latest version 3.2.0 cause deployment on edge failed due to use node module stream

we use @aws-sdk/client-s3 on edge runtime, but the @smithy/util-stream use stream module break the usage of edge runtime. please revert the update or find a way not to use stream module.
./node_modules/@smithy/util-stream/dist-es/checksum/ChecksumStream.js:2:1
Module not found: Can't resolve 'stream'
https://nextjs.org/docs/messages/module-not-found
Import trace for requested module:
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>./src/server/modules/S3/index.ts
./src/server/routers/edge/upload.ts
./src/server/routers/edge/index.ts
./src/app/(backend)/trpc/edge/[trpc]/route.ts

@kuhe please check it. I suggest use web native Stream object like ReadableStream

I'm releasing a patch that contains bundler file replacement instructions for that file.

I think it's fixed now. Thanks


Sampling Operators

@senderista Here is my cleaned up version of the sampling operators. The tests pass and I am able to run queries with them. Let me know of any feedback.

Coverage increased (+0.14%) to 59.5% when pulling 4c90e6f358f879a15df54d049136aa56489a13e1 on radion:radion_sampling into 0f813fd68028e8a56bcc3add79e84f3f8fc44cba on uwescience:master.

Coverage decreased (-0.11%) to 59.24% when pulling e12b75bc7462845db8b7a93de4b61d832fba630a on radion:radion_sampling into 0f813fd68028e8a56bcc3add79e84f3f8fc44cba on uwescience:master.

Transient error on the Travis build unrelated to my changes here:
edu.washington.escience.myria.systemtest.JsonQuerySubmitTest > ingestTest FAILED       org.junit.runners.model.TestTimedOutException: test timed out after 120000 milliseconds

Update: currently investigating an issue that occasionally causes a samplescan query to never terminate.

Coverage increased (+0.16%) to 59.51% when pulling 09aa6aa56bb8a86ec8bf6bfb80c7941fa92e9e28 on radion:radion_sampling into 0f813fd68028e8a56bcc3add79e84f3f8fc44cba on uwescience:master.

Coverage increased (+0.13%) to 59.48% when pulling 047a6b19c8bdf8b3b178502f57171078ddb9e636 on radion:radion_sampling into 0f813fd68028e8a56bcc3add79e84f3f8fc44cba on uwescience:master.

Coverage decreased (-0.13%) to 59.23% when pulling 5086b8624f72e5210af2b6c2c40af8d49fe2129d on radion:radion_sampling into 0f813fd68028e8a56bcc3add79e84f3f8fc44cba on uwescience:master.

Coverage increased (+0.06%) to 59.42% when pulling 5086b8624f72e5210af2b6c2c40af8d49fe2129d on radion:radion_sampling into 0f813fd68028e8a56bcc3add79e84f3f8fc44cba on uwescience:master.

Coverage increased (+0.27%) to 59.63% when pulling 9474f6edabd158011849ccd76167fbafad3fd4e2 on radion:radion_sampling into 0f813fd68028e8a56bcc3add79e84f3f8fc44cba on uwescience:master.

Coverage increased (+0.28%) to 59.63% when pulling 48fd0d0f8478248839ab4548e296b6c7f671f3aa on radion:radion_sampling into 0f813fd68028e8a56bcc3add79e84f3f8fc44cba on uwescience:master.

Coverage increased (+0.28%) to 59.63% when pulling 48fd0d0f8478248839ab4548e296b6c7f671f3aa on radion:radion_sampling into 0f813fd68028e8a56bcc3add79e84f3f8fc44cba on uwescience:master.

Coverage increased (+0.27%) to 59.63% when pulling 26dfea855028232c02f71f45fa2f59784de48e62 on radion:radion_sampling into 0f813fd68028e8a56bcc3add79e84f3f8fc44cba on uwescience:master.

Coverage increased (+0.19%) to 59.54% when pulling 8687fa3b3b42c7880a3caeb4e62358f1185c2b49 on radion:radion_sampling into 0f813fd68028e8a56bcc3add79e84f3f8fc44cba on uwescience:master.


React Location vs. Tanstack React Router?

Hi! Just wanted to drop how happy I am that someone has solved this! Magical indeed. Thanks!
That said... I was wondering whether React Location is kind of the old version on Tanstack Router. The first one is 8 months old while second one in in current development as it seems. Do you see how to migrate this solution to the "new router"?

@swernerx Thanks for mentioning that!
Sure, I'm very excited about adding Tanstack's new Router, I'm planning to add it whenever I have the time. #34
I was also thinking to add type-safety at least for link paths to other integrations as well through code generation, and that will mostly come after adding Tanstack Router.

Support for React Router as a plugin to provide some type-safety landed at https://github.com/oedotme/generouted/releases/tag/v1.7.0


Image scaling when only width is provided results in unexpected heights

Related to https://github.com/facebook/react-native/pull/1538.
Currently when using a static image (require('./image.png')) and passing a width only in the style, the image scales to a height that doesn't quite make sense:
Static Image (@2x): 750 x 424 = 1.7688679245 aspect ratio
iPhone 6: passing width:375 results in height:212 = 1.7688679245 - we published the image for this resolution so the aspect ratio is correct here.
iPhone 5: passing width:320 results in height:212 = 1.5094339623

Height seems to have been left unchanged.
Aspect ratio has been altered. Left/right of image are cropped

iPhone 6 Plus: passing width:621 results in height:320 = 1.940625

Height has been recalculated & changed, but it's unclear how
Aspect ratio has been altered. Top/bottom of image are cropped

As a developer, my expectation or hope is that regardless of resizeMode, I should be able to pass only a width on an image – or use a container that clearly defines a bounding width without defining a bounding height – and the image frame should automatically scale to the image's aspect ratio. That's the simplest way to build for multiple device sizes, since you often only know what width you want and that you want to show the whole image, and are happy to allow content below to flow normally below the image.
In fact, react-native does seem to be trying to do this to some degree, it just seems to be making some weird calculations.
A few related thoughts:
IMO adding a new resizeMode is probably going too far since it's easier to just omit height and let the image scale on its own. The current resizeModes are adequate for defining image resizing when both width & height are specified, whereas when a developer defines only a width and not a height it's a clear indication that they are hoping the image frame will adjust itself accordingly.
Hopefully I'm not glossing over a big issue with remote images, my thought is that it could potentially work the same way in the width-only case once image data is available. (Perhaps the placeholder image or surrounding container can be swapped out with a width-only version after download, using a ternary statement in the render method after onLoad.)
In general, if only width is specified and the unexplained calculations listed above were normalized to fall back on aspect ratio, that would be a great help in building apps for multiple screen sizes. Thanks in advance for the opportunity to discuss this issue!

@davidaurelio , @frantic - who owns static bundle images these days?

Hey @mosesoak! A few things you can do to debug the issue (please attach the output of the command below):
from Terminal (assuming inside the folder with the image):
$ sips -g pixelHeight -g pixelWidth image*.png

from RN app (for iPhone 5 and 6+):
require('resolveAssetSource')(require('./image.png'))

@sahrens Do you think this is related to metadata extraction?

Not sure. Who owns the system e2e?
On Apr 6, 2016, at 8:01 AM, David Aurelio <notifications<EMAIL_ADDRESS>wrote:
@sahrenshttps://github.com/sahrens Do you think this is related to metadata extraction?
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHubhttps://github.com/facebook/react-native/issues/6112#issuecomment-206416199

I don’t think there’s an owner atm

Hey, since this has remained quiescent for a while I am going to close this issue. I think a useful way to make progress would be to run those commands that sahrens suggested above, so if you have that and we can make a bit of progress here then feel free to reopen this issue.


Configurably skip the file open check in S3Uploader.

This would be exercised by adding a checkIfOpen: false to an s3UploaderAdditionalFiles entry in the SingularityS3UploaderConfiguration.

🚢


Remove ephemeral file check.

Discord support files in ephemeral messages.

Im going to assume you tested it?


Update README.md

added my simple redux-simple-router example.
It is based on the basic example but has additional

css modules
express
isomorphic-fetch
webpack-dev-server
redux-logger

It is a simple app which lists all react components and shows their readme's similar to https://www.npmjs.com

Cool, can you rebase?

opps, sorry I got a bit confused rebasing. my first time :)
Should be able to merge this pr easier so I will close this one.