REST Client inheriting from http-client interface

This is a step further where the REST API itself inherits the http-client interface, allowing it to be used directly with the base interface in the same manner as the current library.
The advantage of using the REST public methods is the handling of the request-specific headers, which are handled separately from the default headers. The http-client Add/Remove header is equivalent to modifying the default headers without having the destroy the REST API session.

This is the interface_2 test package:
jki_lib_rest_client-<IP_ADDRESS>.zip

I did a test to completely decouple the NI Advanced HTTP Client from the REST API.  I created the pr-31-plus-decouple-advanced-http-client branch (based on this PR #31 branch) and it seems to work well.
I'm OK with including the advanced-http-client.lvclass in the REST API package, and to make it very easy for users to choose to use this client, but I think it's important not to have the REST API broken if the NI Advanced HTTP Client is not installed, even on Windows.

That probably requires that we, at least, take the advanced-http-client class out of the REST lvlib... Do you know if any other way? I'm sure we could load dynamically the class if it is found, but that will certainly cause headaches when building exe is we forget to include the ni-adv-client class explicitly.

From: Jim Kring @.>
Sent: Sunday, January 28, 2024 2:35:54 PM
To: vipm-io/HTTP-REST-Client @.>
Cc: Francois Normandin @.>; Author @.>
Subject: Re: [vipm-io/HTTP-REST-Client] REST Client inheriting from http-client interface (PR #31)
I did a test to completely decouple the NI Advanced HTTP Client from the REST API. I created the pr-31-plus-decouple-advanced-http-client branch (based on this PR #31https://github.com/vipm-io/HTTP-REST-Client/pull/31 branch) and it seems to work well.
I'm OK with including the advanced-http-client.lvclass in the REST API package, and to make it very easy for users to choose to use this client, but I think it's important not to have the REST API broken if the NI Advanced HTTP Client is not installed, even on Windows.
—
Reply to this email directly, view it on GitHubhttps://github.com/vipm-io/HTTP-REST-Client/pull/31#issuecomment-1913744233, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACZPNJGU3WAHSTOLMIAF3BDYQ3HEVAVCNFSM6AAAAABCOK45OCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJTG42DIMRTGM.
You are receiving this because you authored the thread.Message ID: @.***>

@francois-normandin yes, it involves taking the advanced http client out of the REST API lvlib.  since this issue only impacts a few users, I think it’s OK to have them call a special constructor or pass the advanced client obj into the constructor.

@jimkring
Given a separate constructor is required, and this dependency might go away in the future, should we completely remove it from the REST package and make it a separate package?
The point of putting it as a dependency was that there was no interface to easily extend the base.. Now that we're implementing this interface, I feel it would be ok to split the implementations since there is a change required anyway (new constructor). It's not like we can keep it a 100% drop-in replacement. Shall we bite the bullet and make it right?
Another advantage is that this separate package could be viewed as a template for whoever wants to implement this interface into their own specific class ...

For now, let’s keep working on these together in a single repo/package, until we get the http-client interface stabilized. This will make it a lot easier to evaluate and/or change the interface. I’d also like to evaluate creating .NET and pure G implementations (I have some laying around) and see how these all fit together.

I took a quick look at this PR too.  It's a clever implementation, but it does add confusion to the library as to which interfaces do what, and why you might use one over the other.  Couldn't this same functionality be included by adding a couple of extra methods to REST Client class to Add/Remove/Clear request headers?
For the other topic, I would advocate for pulling the "advanced" http API into a separate package.  As I mentioned in another thread, once this is finalized, I'll update our .NET implementation so that it can "ship" with an additional example... though that example will be considerably more complex.
Another useful example would be calling directly into the CURL library itself (which I've had occasion to use a couple of times though don't have something readily adaptable for this).

@jimkring

I like the idea of pulling the interface into http.lvlib, however... it will create namespacing problems because http is too likely to be already used out there (I probably do myself, in a project or two). If this were to be shared as a separate package that contains only a set of reusable interface methods for the world to reuse, that might work; but in the context of a REST API project, I believe it is best to keep the interface in the main lvlib. If we want to promote the reuse of the http package outside of REST context, it has to become a separately-maintained package. Otherwise, it should be rolled back in the original lvlib.
Removing the non-dynamic wrapper is a regression in my opinion. To me, it breaks two aspects of the SOLID principles. Don't get me wrong, it will work fine but... 1) It goes against the Liskov substitution principle. If I ever want to swap an implementation for another, I cannot guarantee that the code would work in the same way. In fact, the reason that @jyoung8711 needed a fork of this project in the first place (for his .net implementation), is a proof that the original choice of having the public methods be overridable, is not extendable enough and 2) I can also demonstrate how removing the wrapper creates a Close-Close situation instead of an Open-Close situation. Furthermore, it's easier to debug if you can trace all the static methods in a piece of code, as opposed to finding all the different permutations of the dynamically-dispatched calls that might stem from using a child in private data as opposed to the interface. I know those are advanced concepts that most developers might roll their eyes about, but for a reuse component, I believe it is important to set those higher coding standards.
optional overrides: in the context of the REST API, I have to agree with the proposal. For the same reasons stated above (Liskov, mainly), I do not create optional overrides unless it is expected that those method are no-op in normal implementations (pre & post callbacks are an example), but I am (I admit it`s a personal choice) not a fan of "Not implemented errors", because it does not break my code when I add an interface to an existing class. That being said, to preserve backwards-compatibility with the 1.x REST API, we have no choice.
response class: awesome! I like it... but we need to be symmetrical and do a request class on the other end of the calls. Too bad there are no generic request-response interface we could extend.  Again, not a big fan of the public methods being overridable.
response class: why the destructor? It is a byValue class after all.
Pre-Post request. Good reuse.

Static wrapper on dynamic method:
I mention Liskov and the Open-Close principle to justify why the wrapper is important. I think it is best if I take some time to serve examples of what I mean.
What follows has happened so many times to me in my career, that I now prefer to take the time to always create wrappers in my interfaces...
Let's say we use three different low-level implementations (here, derived from http-client interface, but in general, maybe three power supplies in a HAL). With a public dispatchable method, we get this:

Great... we have visual confirmation when we connect the VI that we have a common ancestor + we can double-click on the subVI and get access to the list of all the overrides.
Now, let's project ourselves in two years and discover that all our implementations are working great in the US but at not doing so great at our new manufacturing plant across the world... because we didn't expect that we'd need UTF-8 support, or maybe to add a message-abstraction layer, or maybe support the new HTTP3.5 in 2028... how do we make the change and propagate it
effectively everywhere? The solution might be to insert a single VI in the static method, before or after the dynamic VI. If we had created a wrapper up front, yes it would have seemed an extra layer, but then we could react to change without breaking any code and not having to touch, recompile, retest and distribute all our device implementations. Furthermore, what if we create a new derived class of the same interface... now we have to remember to duplicate that new piece of code that makes it work seamlessly everywhere. That is not just a good example of Open-Close principle but it is also breaking Liskov because I cannot be certain that all the devices I would use are compliant with this new paradigm... but if I had added the fix in the static method, I am certain that it does.
Another example...
What happens in the future when I am being asked to generate an event whenever I'm calling any of the REST methods? There are many solutions, but a very elegant and simple one would be to create a pre or post callback. Those callbacks can be virtual as well, and be marked as optional-override, so that they are no-ops in all implementations, but I can quickly add a logger/tracer into my workflow without having to pepper the additional code everywhere in my software. I'm not saying we should plan for those types of callbacks, but it provides a mean to enhance the library in the future, and avoid painting ourselves in a corner. No one can predict the future, least of all me, so I advocate strongly for staying open to extension while closed to behavioral modification.

@francois-normandin @jimkring --
In general I'm a fan of the latest refactoring.  I like the new Pre/Post request overrides, and the new response class.
However:

I agree that it would be preferable to pull the interfaces back into the primary library... or to rename it to be a bit more verbose.  I capture most reuse libraries as PPLs, so the name-spacing & library organization is important there. (fwiw i have the .NET implementation split into two libraries : HttpClient_Net (which is the core implementation) and REST Client_NET (which is the corresponding wrapper for this library)

While I like the "response" class.  I would advocate that the "Headers" themselves should still have overrides (possibly with a base "interface" class.  In the .NET interface, the headers themselves are .NET objects.  My preference would be to maintain them as that rather than forcing them into the text based format (which will create some overhead).  I would not be able to use the REST Client library (as is) without translating, which is undesirable.

I would advocate for destruction methods. Both for the response, and for the headers classes.  This follows more closely the .NET model which I might be able to take advantage of (I say might because I think I removed the "response" class from my main API to reduce complexity for the end-user).

@francois-normandin thank you for the great explanations.
My refactor was a bit of a journey to better understand the design and also explore using interfaces in a very practical way.
Some thoughts...
Yes, I'm OK moving the http-client back into REST API library :)
You're right that the Public Static API with Protect Dynamic Overrides pattern is really nice for guaranteeing the entry and exit points of a call and having the option to add code to them, including inserting new pre/post callbacks in the future without changing the Public Static API.  For the http-client I can see how we would almost certainly utilize such capabilities in the future.
In fact, I've been noticing the REST API is itself very much like a public wrapper (open to extension) around the http-client interface, which the REST API keeps private and does not expose to caller's (except for the constructor/injection).  As such, I was exploring what it would look like to keep the http-client interface "purely" abstract by not putting any actual code into the interface class (aside from the Not Implemented Errors, which is certainly another debatable point).
It seems like the http-client could grow into a thing that itself resembles the REST API. To avoid that, I think that we can do things like move the Pre-Request and Post-Request into the http-client interface and then the REST API can implement them.
And, we should probably do as you suggested, @francois-normandin, and create a request.lvclass class to go along with the new response.lvclass
Regarding the destruction methods, I was thinking about @jyoung8711's use case of .NET which might have references inside the response and then use .NET property nodes inside of the request object's accessor method overrides.

@jyoung8711 I have a question about the .NET implementation:

I agree that it would be preferable to pull the interfaces back into the primary library... or to rename it to be a bit more verbose.  I capture most reuse libraries as PPLs, so the name-spacing & library organization is important there. (fwiw i have the .NET implementation split into two libraries : HttpClient_Net (which is the core implementation) and REST Client_NET (which is the corresponding wrapper for this library)

What was the primary benefit of using the REST API as the starting point and then extending it with a .NET implementation?  Is there a benefit in your application to having your main application calling the REST API and being able to switch between specific implementations?

@jimkring
Good question.  The main reason was that we had standardized on this library throughout our fairly large application (spread throughout different plugins/modules/ppls... usually with a dependency injection).  We had to switch to the .NET implementation because it resolves certain proxy servers better.  A few of our users are behind various corporate firewalls/proxy servers, some of which are not resolved by the native LabVIEW HTTP API.
The fork that I did only broke the single "initialization" VI, so it was very easy to make the changes throughout the application, and then only recompile what I needed to (rather than swapping out the entire library).
Since that initial integration, I have actually found some benefits to being able to swap back and forth between the two.  The .NET API taps into the lower level windows REST functions, and handles certs, certain proxies, configurable TLS communication, follows redirects, and some other things out of box very nicely.  Whereas the LabVIEW native (and advanced client), is essentially just a modified raw CURL wrapper (https://curl.se/windows/) -- at least as far as I can tell.  It "hides less" which is also useful sometimes... especially for debugging purposes.
As an aside, the .NET API is also fundamentally asynchronous, which is VERY useful for longer downloads, and has some additional functionality that's proven useful.  However, to leverage this I've reverted to the lower level wrapper that we wrote, which is closer to a 1:1 wrapper of the native .NET classes.
That's probably more info than you wanted, but figured the context would be useful.

Thanks @jyoung8711. That's super helpful.  To echo back a summary of key drivers/points that I think I heard:

The REST API was standardized upon for your applications, (presumably for its benefits like request-specific headers, base url specified at initialization, extensibility, others?).
For adding needed HTTP functionality (that was not supported by the LV native HTTP Client), it was more practical (for your applications already using the REST API) to fork and extend the REST API with a plug-in interface and a .NET interface.
You also needed async downloads in some cases, and you ended up using the .NET specific implementation directly to do that.

For what it's worth, I've also needed async and created this little library.  I think it would be great if we supported async requests in the REST API, too.

@francois-normandin, at this point, I think it makes sense to continue onward with this PR (#31) as it currently stands.
For next steps on this PR, would it work to do the following?

add classes for http-request and http-response data ()
add preRequest.vi and postRequest.vi protected overrides
refactor the REST API to implement preRequest.vi and postRequest.vi (similar to what I've done in pr-31-response-class branch)

Also @jyoung8711 even if we're not able to fully implement a .NET implementation, it might be good to try to implement a simple implementation with GET.  For now, it could make sense to work on that in this PR and then we can strip it out (as we will for the advanced-http-client implementation) before we merge the PR.  Keeping these three implementations (basic, advanced, dot-net) together in a single branch will help a lot for testing and tweaks to the interface.

Thanks @jyoung8711. That's super helpful. To echo back a summary of key drivers/points that I think I heard:

The REST API was standardized upon for your applications, (presumably for its benefits like request-specific headers, base url specified at initialization, extensibility, others?).

Originally it was because of the base URL/URL building, and that it was class based -- with the anticipation that extendibility might eventually be required.  Unfortunately when that time came, we found that it needed some tweaks first (hence the fork).  We still heavily leverage this forked library throughout our code base (including new projects)

For adding needed HTTP functionality (that was not supported by the LV native HTTP Client), it was more practical (for your applications already using the REST API) to fork and extend the REST API with a plug-in interface and a .NET interface.
You also needed async downloads in some cases, and you ended up using the .NET specific implementation directly to do that.

Downloading (and other async requests) was the primary use case.  There's also some .NET streaming functionality that can be pretty handy to tap into (both for upload & download -- actually the downloading w/progress is a specific use of the streaming interface).  Previously there were some HTTP verbs that we also had to leverage the base library for, but these have since been added (I think PATCH, specifically)... There are a few other things I've leveraged the lower-level library for over the years, but those are the things that come to mind.  The .NET HTTP library is incredibly fully featured, and well-architected. It was a fun task to build adapt it into a set of LabVIEW libraries (and at the time it was one of my first big forays into .NET integration w/LabVIEW)

For what it's worth, I've also needed async and created this little library. I think it would be great if we supported async requests in the REST API, too.

I'm familiar with that library, and took a look at it when you first released it! It was a clever implementation, and I think the "follow redirect" function would be particularly useful to pull back up into this library as a utility function.

@francois-normandin, at this point, I think it makes sense to continue onward with this PR (#31) as it currently stands.
For next steps on this PR, would it work to do the following?

add classes for http-request and http-response data ()
add preRequest.vi and postRequest.vi protected overrides
refactor the REST API to implement preRequest.vi and postRequest.vi (similar to what I've done in pr-31-response-class branch)

@jimkring -- Is there a reason not including overridable "response headers" class? More out of curiosity than anything else (as I said the .NET can be adapted w/out this).

Also @jyoung8711 even if we're not able to fully implement a .NET implementation (e.g. if it's more time than you have right now before the interface fully stabilizes), it might still be good to try to implement a very simple dot-net implementation with at least a GET method. For right now, I think it could make sense to work on this within this same PR/branch and then we can strip it out (as we will for the advanced-http-client implementation) before we merge the PR. Keeping these three implementations (basic, advanced, dot-net) together in a single branch will help a lot for testing and tweaks to the interface. It will also give you a good way of communicating the needs of the .NET implementation, with respect to the interface design (e.g. destructor methods, async, by ref, etc.).

Adapting the library won't take much effort.  Once you've made the above changes, I should be able to add a corresponding library here in a day or so (depending on timing).
That current "shim" lives in the .NET VIPM today.  It sounds like you're advocating that it move over to this package instead?   If that's the case, it will create a dependency linkage to the Viviota .NET VIPM package, unless you're suggesting doing a separate/simplified wrapper that's independent as part of this package.
Which direction would you prefer here?

@jyoung8711

Is there a reason not including overridable "response headers" class? More out of curiosity than anything else (as I said the .NET can be adapted w/out this).

It sounds like a good idea -- I'll let @francois-normandin weigh in about the interface for extending the request, response, and headers classes.  That's part of the reason I was suggesting that we look at a practical example of how .NET would ideally like to "plug in" to the response headers, if it were made extensible.
I'll take a look at the Viviota .NET package and get back to you about best ways for us to structure our interface design explorations...

@jimkring -- Thanks for the clarification.
If we're trying to mockup a "quick demo" to see how close we are on interfaces / structures, then my recommendation would be to just add the dependency (at least temporarily).  The async / class based nature of the .NET interface will add a lot of overhead if you try to do it from scratch.
We can easily strip out the dependency before this library ships
I don't think the repo has an official release with a VIPM artifact... let me check on that and make sure it's uploaded.

@jimkring -- I've created a new pull request where I did a VERY quick add of the .NET interface from the Viviota repo.  If you install the VIPM package linked above you should be able to take a look.  I implemented the GET and POST so that it can be run with your Main.vi.  A few comments about what I found during this:

I didn't need to edit any VIs (except Main.vi) for this -- this is a great improvement!
I don't think the current pattern for generating the response class works very well.  Since the "create response" is an override http-client interface, you can't create the class with the correct typing.  There are a couple of work-arounds to this, but I would recommend removing the "Create Response.vi" & "Get Response Type" from the interface.  This leaves the creation process less ambiguous.  You can start with the "Create.vi" from the response class directly.  (the pattern may change a bit if the headers generic class is created).
I did have to create a separate data structure for my request headers... I had forgotten that .NET interface is VERY picky about how headers get labeled (request vs content vs response)... in general you'll be able to see how I handled the headers for requests / responses.  It was not too onerous.
We could get away without the additional classes in order to err on side of "simplicity" for users.

Thanks!

@jyoung8711 it's great you were able to get the .NET client proof-of-concept working so quickly -- nice work!

I would recommend removing the "Create Response.vi" & "Get Response Type" from the interface.

Yes, I think you're right. Each http-client can create its own specific response type in the HTTP method calls.

We could get away without the additional classes in order to err on side of "simplicity" for users.

OK, good to lean that direction :)

@jimkring --
One other thing that struck me while I was writing this.  It would be very handy to have a stub for "read" and "read all" for the request headers.  I know that the NI Http APIs don't support that, but it could be handled with an internal map similar to what I did with the .NET example, and I think being able to inspect the headers is a good value add.  Whether that should be pulled into this release (while things are in flux) or better left to a future release, I don't have a strong opinion.

@jyoung8711 @jimkring
I think we're in agreement here. The trend of this discussion indicates that we'd all like to see a more extensive and modular http-client interface, including a break down of the request, response and header classes.
In light of this, I would like to suggest that we proceed in this thread for development, but also consider pulling it out completely into a new HTTP Client repository. It would make it possible to depend on this http-client package in other projects that are not REST, such as SOAP, WebRTC or GraphQL, or any custom application using the same base functionality.
Technically, the .NET, cURL or NI-Adv-Client implementations would not be depending on the REST package... but any of these implementations would be supported through its constructor's interface input.
We don't have a "standard interfaces library" in LabVIEW, as depicted here, so ignore that part for the scope of this project, but does the rest of the model make sense to you both?

@francois-normandin, yes that architecture looks correct as a north star.
Would the following make sense?

[X] Define a new v3.0 project milestone with the http-client plug-in architecture (based on this PR #31 branch)
Development toward v3.0 will happen in the develop branch

Meaning: contributors (@francois-normandin @jyoung8711 @jimkring) will work in (a fork of) develop and create pull requests targeting that branch
[ ] merge main into develop since it's very behind.

PS: I just renamed the master branch as main (you may need to update your local repo clones)

@francois-normandin I changed the name of this PR to HTTP Client Plugin Interface to convey that it's the main thread of development.


Make Mono source-build-clean

Mono as currently built in runtime is not source-build-clean and restores prebuilt assets during the build.  We will need to fix this and upstream any patches required.  This should only affect the System.Private.CoreLib build; the libcoreclr build should not be bringing in prebuilts.

We are using mono (the VM, the alternative to CoreCLR) from the .NET runtime repo on s390x as a part of source-build. I am not aware of anything special that needs to be done; everything works fine out of the box right now.
I think the last set of issues was fixed by https://github.com/dotnet/runtime/pull/61607?
IMO we should close this issue now.


pip-compile on 1.10.2+ fails to handle mypy; >= '3.2' on python 2.7

I believe this is related to how environment markers are handled.
With requirements.in of:
mypy >= 0.560; python_version >= '3.2'

On python 2.7, run:
pip-compile --no-index --rebuild -v requirements.in

Produces:
Using indexes:
  ---snip---

                          ROUND 1
Current constraints:
  mypy>=0.560

Finding the best candidates:
  found candidate mypy==0.560 (constraint was >=0.560)

Finding secondary dependencies:
  mypy==0.560 not in cache, need to check index
Traceback (most recent call last):
  File "/home/musttu/.virtualenvs/wires/bin/pip-compile", line 11, in <module>
    sys.exit(cli())
  File "/home/musttu/.virtualenvs/wires/local/lib/python2.7/site-packages/click/core.py", line 722, in __call__
    return self.main(*args, **kwargs)
  File "/home/musttu/.virtualenvs/wires/local/lib/python2.7/site-packages/click/core.py", line 697, in main
    rv = self.invoke(ctx)
  File "/home/musttu/.virtualenvs/wires/local/lib/python2.7/site-packages/click/core.py", line 895, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/musttu/.virtualenvs/wires/local/lib/python2.7/site-packages/click/core.py", line 535, in invoke
    return callback(*args, **kwargs)
  File "/home/musttu/.virtualenvs/wires/local/lib/python2.7/site-packages/piptools/scripts/compile.py", line 187, in cli
    results = resolver.resolve(max_rounds=max_rounds)
  File "/home/musttu/.virtualenvs/wires/local/lib/python2.7/site-packages/piptools/resolver.py", line 102, in resolve
    has_changed, best_matches = self._resolve_one_round()
  File "/home/musttu/.virtualenvs/wires/local/lib/python2.7/site-packages/piptools/resolver.py", line 199, in _resolve_one_round
    for dep in self._iter_dependencies(best_match):
  File "/home/musttu/.virtualenvs/wires/local/lib/python2.7/site-packages/piptools/resolver.py", line 285, in _iter_dependencies
    dependencies = self.repository.get_dependencies(ireq)
  File "/home/musttu/.virtualenvs/wires/local/lib/python2.7/site-packages/piptools/repositories/local.py", line 64, in get_dependencies
    return self.repository.get_dependencies(ireq)
  File "/home/musttu/.virtualenvs/wires/local/lib/python2.7/site-packages/piptools/repositories/pypi.py", line 157, in get_dependencies
    self._dependencies_cache[ireq] = reqset._prepare_file(self.finder, ireq)
  File "/home/musttu/.virtualenvs/wires/local/lib/python2.7/site-packages/pip/req/req_set.py", line 634, in _prepare_file
    abstract_dist.prep_for_dist()
  File "/home/musttu/.virtualenvs/wires/local/lib/python2.7/site-packages/pip/req/req_set.py", line 129, in prep_for_dist
    self.req_to_install.run_egg_info()
  File "/home/musttu/.virtualenvs/wires/local/lib/python2.7/site-packages/pip/req/req_install.py", line 439, in run_egg_info
    command_desc='python setup.py egg_info')
  File "/home/musttu/.virtualenvs/wires/local/lib/python2.7/site-packages/pip/utils/__init__.py", line 707, in call_subprocess
    % (command_desc, proc.returncode, cwd))
pip.exceptions.InstallationError: Command "python setup.py egg_info" failed with error code 1 in /tmp/tmpreRyRhbuild/mypy/

This works on 1.10.0 and 1.10.1 but not on 1.10.2+ or 1.9.x.
On python 3.5 and 1.11.0, it works, and output even retains the environment marker:
...
mypy==0.560 ; python_version >= "3.2"
...

Environment Versions

OS Type: linux
Python version: 2.7.12
pip version:  9.0.1
pip-tools version: 1.11.0

Hello @tuukkamustonen, sorry for the delay.
You are right, this is due to how we handle the markers in the requirement file. pip-compile currently has a very partial support for environment markers, mostly for happy cases.
This is a known issue; pip-compile currently doesn't interpret environment markers in a requirement file itself. It simply brings them over to the output file. As pip-compile ends up processing mypy's setup.py on python 2.7, you get this result.
The reason it "worked" under v1.10.0 and v1.10.1 was actually due to a bug where the python 3 wheels would be used even on python 2 to get the dependencies (effectively meaning you were getting the python 3 variant of the dependencies, which may or may not be different). As a result, the .tar.gz was never used, the setup.py not executed, and you weren't getting any issue.
This is something I would like to see fixed in the future of course, but I'm bit short on time.
Contributions are always welcomed 😄

@vphilippon I had a similar issue while trying to install jsonschema==2.6.0 inside a Python 3.6 virtualenv. If you look at the install_requires section of jsonschema's setup.py file here, you'll find this:
install_requires=[
    "attrs>=17.3.0",
    "pyrsistent>=0.14.0",
    "six>=1.11.0",
    "functools32;python_version<'3'",
],

pip-compile is unable to ignore the functools32 dependency under Python 3.6, and I get the following error while installing from the requirements.txt: "This backport is for Python 2.7 only."
Could you please point me to the specific sections of the codebase where I can take a look for investigating the bug, so that I can submit a PR?

Hi @onyb, thanks for your offer!
I can point you to https://github.com/jazzband/pip-tools/blob/master/piptools/scripts/compile.py#L187 and https://github.com/jazzband/pip-tools/blob/master/piptools/resolver.py#L74
Although, the solution might be be to do something similar to https://github.com/jazzband/pip-tools/blob/master/piptools/sync.py#L114 (use .match_markers) to filter packages based on the system.
But we have to be carefull with to not break the generate_hash logic that generates hashes for all platforms.
That being said, filtering dependencies based on the current platform could also cause some issue with the work done in https://github.com/jazzband/pip-tools/pull/460.
If we mix the 2, what I forsee is that we will get in a state where we compute dependencies only for the dependencies of the current system/environment, while introducing potential "unresolved" packages in the final file, essentially breaking the reproductibility promise.
If we want to support the workflow where you have a single requirements.in file with markers, with which you perform a pip-compile on each target environment (python version + OS), then we would have to revert https://github.com/jazzband/pip-tools/pull/460, as it appears simply incompatible to me.
@barrywhart @suutari-ai @davidovich Any input here?

I have had similar issue with functools, where it was being included as an indirect dependency of an application that needed to support both Python 2.7 and 3.x. In that case at least, there is a straightforward workaround or solution. Include the following line in requirements.in:
functools32 ; python_version=='2.7'

The environment marker is passed through to requirements.txt even though the library requiring it doesn't include the marker, e.g.
functools32==3.2.3.post2 ; python_version == "2.7"

But your case is interesting, because jsonschema is actually specifying the environment marker. Are you saying it generates a requirements.txt file with functools32 but without the environment marker? If so, that sounds like a bug in #460, and perhaps a different issue than the original poster on this issue.
pip-compile is a very useful tool, but it also seems subject to occasional breakage because it's trying to do something that isn't really well supported by the underlying tools. That is, there's no universal, cross-Python version/environment way to get dependency information for a package.

FWIW, I can't reproduce the jsonschema issue. I created a Python 3.6.3 virtualenv and ran pip-compile using the following requirements.in:
jsonschema==2.6.0

And it generated the following requirements.txt:
#
# This file is autogenerated by pip-compile
# To update, run:
#
#    pip-compile --output-file requirements.txt requirements.in
#
jsonschema==2.6.0

@onyb i did the same check as Barry, and couldn't reproduce either. What's the setuptools version in the virtualenv? Older version did not interpret markers in the install_requires. Otherwise, check if functools32 might be coming from another package which doesn't have the environnement marker.
--

[...] it's trying to do something that isn't really well supported by the underlying tools. That is, there's no universal, cross-Python version/environment way to get dependency information for a package.

@barrywhart You summarized the whole pain of trying to deal with cross-environment dependency resolution. Thank you 👍
Regarding your functools32 example, I tried to pip-compile under python3, and it fails due to being python2 only. That is because the environment marker doesn't prevent the attempt of dependency resolution of functools32.
But, if I perform the pip-compile on python2, then it will succeed, and I would have a requirements.txt
with the environment marker on functools32.
In other words, the pip-compile has to be done in an environment where all packages are installable to succeed.
My honest feeling is that pip-tools is never going to be able to generate a true cross-environment requirements.txt. The main reason is the non-deterministic aspect of setup.py, as described here: https://dustingram.com/articles/2018/03/05/why-pypi-doesnt-know-dependencies
I think that a clear statement regarding this should be made: That the vision of pip-tools is to generate a requirements.txt that is complete and reproducible for the environment on which it was generated (with the possibility of an exception of the generate-hashes, for the happy case where the dependencies are the same across environments). This means that a requirements.in should be pip-compile'd on each target environment individually. With that said, we can improve pip-tools by having it parse the environment markers in the requirements.in, as pip, would and include/exclude the top-level dependencies from the dependency resolution. That would effectively exclude it from the final requirements.txt too.
Sadly, this wouldn't cover the case where a lib forgets to put environment markers on a package, as given by @barrywhart . The "real" answer is to have the offending package fix its dependencies, as it would with any version conflicts. The only other way around that would be to keep the environment markers from requirements.in in the requirements.txt as we do now, and in this particular instance the python2 version of the requirements.txt would work on python3, if there's no other variation. Maybe this could be added as an option instead to avoid unneeded markers for users that follow the suggested flow.
To be a 100% honest, I would prefer this feature (copying environment markers) to be removed. I hate to take away any contribution to the Open-Source (heck, we need more!), While it appeared to be a first step toward a better solution at first, I fear that keeping this feature would give us a lot of headache and a lot more trouble with this change now. I had to deal with a similar behavior when offering help and support with Pipenv, and I'm absolutely not willing to offer the same help and support to users here; It was really rough and confusing for everyone. I also doubt pip-tools has enough other knowledgeable contributors to take care of that user support.
Here is a are some examples of issues users would likely face and request support for (or worse, not be aware of at all):

Users would use the option to keep the markers, and then be surprised to see th package disappear from the requirements.txt when pip-compileing  on another environment.
Users would use the option to keep the markers and put a marker on a package with dependencies of its own that are possibly not required on the current environment, be lead to believe that they have a "happy case" where the requirements.txt is cross-environment, and then proceed to install on another environment, resulting in a non-deterministic installation with packages not listed in the requirements.txt, breaking one of pip-tools base promises.
Users would use the option to keep the markers and put a marker on a package with dependencies of its own that are possibly required only on the current environment, be lead to believe that they have a "happy case" where the requirements.txt is cross-environment, and then proceed to install on another environment, resulting in installing packages that are meant for another environment.

@barrywhart If you have a maintainable idea to keep that feature to un-break some cases as you mentioned, I would be happy to hear it.
Of course, such a change would be done as part of a Major release.
(That was quite a wall of text. There was a lot to point out. I really wish this was easier to deal with.)

Perhaps we could keep the environment marker copying, but make it optional (i.e. the default is to not propagate them).
I see your point about people getting confused using it, but TBH, I wonder how many people who use pip-compile understand that it's intended to target only the environment where it was built. I suspect most people just try it out and only look at the details when something surprises them.
@vphilippon, can you clarify your question here:

@barrywhart If you have a maintainable idea to keep that feature to un-break some cases as you mentioned, I would be happy to hear it.

Are you referring to something I said on this ticket, or is it a general question?

@barrywhart That was a general question. And of course, I intend to better document and put upfront the idea that pip-tools aims to take care of a single environment.
I'll let the idea of keeping the optional marker-copy behavior running in my head for a while, see how it comes out.

Idea: Just as pip-compile includes the original command in the requirements.txt file, e.g.:

# This file is autogenerated by pip-compile
# To update, run:
#
#    pip-compile --no-index --output-file requirements.txt requirements.in
#
cachetools==2.0.1         # via google-auth
certifi==2018.1.18        # via requests
...

It could also include details on the environment. pip-compile should fail if the user runs it on a different environment (i.e. if the requirements.txt file already exists and the runtime environment does not match the environment listed in requirements.txt).

Idea: Provide a tool similar in spirit to tox which generates requirements.txt files for a specified set of environments (i.e. Python interpreter versions, CPython or PyPy). Having an automated process for creating a file per environment makes cross-environment files seem less important.

Todo: Document the expectation that pip-compile should be executed for each target environment.
@barrywhart For your first idea, that wouldn't play too well with the --no-header option. Also, I'm not too keen on adding additional things like that: I'd like the requirements.in/requirements.txt files to stay "pure pip requirements file". I like the idea of trying to warn/prevent a user trying to run a file on the wrong environment, but I think this kind of "advanced" stuff would be better suited with pipenv.
For your second idea, that sounds like a good tool idea. I wonder how well it could be done simply with tox without any additional work here (except maybe documented examples), or how well it would stand as a standalone tool made to deal with other cross-environment tasks. I have a hunch that we'd be better off with a distinct tool, but I might be biased as a kind-of-busy-maintainer.

Oopsie, accidentally closed it :)
Though, it really should be closed now that #647 is in. Will give 2.x a spin tomorrow!


suggestion: keep basic template simple

the current default template seems alittle too customized for a default theme... why not have that be a specific theme that people can designate and maybe simply the default theme to be alittle more minimalistic and basic? (possible design idea: https://examples.sencha.com/extjs/6.2.0/examples/kitchensink/#basic-trees)

True. It would be a breaking change, but I agree with your logic.
I kind of like the presence of the drag handle, as it’s a common UI to indicate the ability to drag. If you’re suggesting a plainer, full-width style, I’d like to figure out a way that the draggability can be understood easily.

I kind of like the presence of the drag handle, as it’s a common UI to indicate the ability to drag.

In our user testing (not extensive at this stage) some Desktop users have found the drag handle confusing (actually they did know that clicking there let you drag the node). They did not associate the 'hamburger' icon with the ability to the drag the node.

If you’re suggesting a plainer, full-width style, I’d like to figure out a way that the draggability can be understood easily.

In our application (creating web forms) we would love to see a full-width style option which still highlighted the draggability.

+1

This is my suggestion to the discussion.
If the original theme is more compact it will most likely be suited in more user cases. Look at the two pictures below. The right one is more compact and displays the same information as the left one in almost half the space.

sizing could be an issue but I feel that it is merely a side product of the current design issue. @fritz-c I will come up with a rough prototype and put it up as a theme and if people find that to be better default maybe we can swap it. I have a few ideas in making it a bit easier to comprehend that it is a draggable node without having a designated space just to enable a drag function

Hello, been pretty busy and was able to get this out now.... @fritz-c, @JWaldenback, @buzztone, Would you guys be able to give me some feedback on this?

Can you provide a link, and maybe a demo site?

Any thoughts about my new basic theme proposal and the example that I provided? @JWaldenback, @fritz-c?

@lifejuggler I like it. But I would it to be more compact. Is that easily changed?
Have you seen this full node drag theme that fritz-c has made btw? I like it a lot, though it also needs to be more compact imo. Or at least easily customizable to change the height and size of the nodes.
https://github.com/fritz-c/react-sortable-tree-theme-full-node-drag

@lifejuggler @JWaldenback Feel free to make a PR :)

@JWaldenback, height should be adjustable... let me know if it isn't

@fritz-c , @wuweiweiwu, I made a pull request with the new custom theme added into the readme

closed by #289


Couldn't find petsc at the SuperMUC HPC system

Hello,
the petsc/3.8 module on the SuperMUC HPC system sets
setenv          PETSC_DIR       /lrz/sys/libraries/petsc/3.8.2/Medium_Node/arch-linux-3-c-3.8.2-Medium_Node-real_mpi.intel_5.1_opt
setenv          PETSC_ARCH      arch-linux-3-c-3.8.2-Medium_Node-real_mpi.intel_5.1_opt

ls $PETSC_DIR
bin  include  lib  share

I am not sure if the environment is misconfigured or rather an edge case that should be fixed in FindPETSC.
Thanks!

PETSC_ARCH should be blank (for all --prefix installs, PETSC_ARCH is used for builds in the source tree). Let me know if that doesn't work.

Unfortunatly not. I have blanked $PETSC_ARCH, but
> cmake ../..
-- The CXX compiler identification is GNU 6.3.0
-- Check for working CXX compiler: /lrz/sys/compilers/gcc/6.3/bin/c++
-- Check for working CXX compiler: /lrz/sys/compilers/gcc/6.3/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Build configuration: Debug
-- Special platform settings: none
-- Found MPI_CXX: /lrz/sys/intel/impi/<IP_ADDRESS>/intel64/lib/libmpicxx.so;/lrz/sys/intel/impi/<IP_ADDRESS>/intel64/lib/libmpifort.so;/lrz/sys/intel/impi/<IP_ADDRESS>/intel64/lib/release_mt/libmpi.so;/lrz/sys/intel/impi/<IP_ADDRESS>/intel64/lib/libmpigi.a;/usr/lib64/libdl.so;/usr/lib64/librt.so;/usr/lib64/libpthread.so
-- petsc_lib_dir /lrz/sys/libraries/petsc/3.8.2/Medium_Node/arch-linux-3-c-3.8.2-Medium_Node-real_mpi.intel_5.1_opt/lib
-- Recognized PETSc install with single library for all packages
-- Performing Test MULTIPASS_TEST_1_petsc_works_minimal
-- Performing Test MULTIPASS_TEST_1_petsc_works_minimal - Failed
-- Performing Test MULTIPASS_TEST_2_petsc_works_allincludes
-- Performing Test MULTIPASS_TEST_2_petsc_works_allincludes - Failed
-- Performing Test MULTIPASS_TEST_3_petsc_works_alllibraries
-- Performing Test MULTIPASS_TEST_3_petsc_works_alllibraries - Failed
-- Performing Test MULTIPASS_TEST_4_petsc_works_all
-- Performing Test MULTIPASS_TEST_4_petsc_works_all - Failed
-- PETSc could not be used, maybe the install is broken.
CMake Error at /lrz/mnt/sys.x86_64/tools/cmake/3.6.2/share/cmake-3.6/Modules/FindPackageHandleStandardArgs.cmake:148 (message):
  PETSc could not be found.  Be sure to set PETSC_DIR and PETSC_ARCH.
  (missing: PETSC_EXECUTABLE_RUNS) (found suitable version "3.8.2", minimum
  required is "3.6")
Call Stack (most recent call first):
  /lrz/mnt/sys.x86_64/tools/cmake/3.6.2/share/cmake-3.6/Modules/FindPackageHandleStandardArgs.cmake:388 (_FPHSA_FAILURE_MESSAGE)
  tools/cmake-modules/FindPETSc.cmake:331 (find_package_handle_standard_args)
  CMakeLists.txt:41 (find_package)

-- Configuring incomplete, errors occurred!
See also "/gpfs/work/pr62cu/di29veb3/shared_exafsa/software/precice/build/cmake-release/CMakeFiles/CMakeOutput.log".
See also "/gpfs/work/pr62cu/di29veb3/shared_exafsa/software/precice/build/cmake-release/CMakeFiles/CMakeError.log".

I have also uploaded the two log files:
CMakeError.log
CMakeOutput.log
The CMakeLists is at https://github.com/precice/precice/blob/develop/CMakeLists.txt
Best Thanks!

I actually use FindMPI:
find_package(MPI REQUIRED)
include_directories(${MPI_INCLUDE_PATH})
set(COMPILE_FLAGS  ${COMPILE_FLAGS} ${MPI_COMPILE_FLAGS})
set(LINK_FLAGS ${LINK_FLAGS} ${MPI_LINK_FLAGS})

Thought that it sets the flags correctly.
However CC=mpicc CXX=mpicxx cmake ../.. did the trick, even without unsetting PETSC_ARCH.
If you say, that this is a FindMPI problem, the issue can be closed.

I'm not going to make FindPETSc depend on FindMPI because (a) MPI is not needed in serial and (b) FindMPI is quite fragile, complicated, and often not used in favor of CC=mpicc.


fix markdown

Table was broken and cleaned up other markdown based on https://github.com/DavidAnson/vscode-markdownlint

/assign @foxish
/assign @unguiculus

/lgtm
/ok-to-test

/lgtm


Unknown application error occurred

Description
I have been working with Vercel support to resolve an issue where the jsonwebtoken package is encountering an error, "Unknown application error occurred". Vercel has directed me to open an issue here.
Reproduction
https://github.com/vercel-support/issue-reproduction
Here are my steps.

Clone the repo https://github.com/vercel-support/issue-reproduction
run, "yarn"
run the code in the api/login/checksecurityans file
Open Postman and POST to localhost:3000/api/login/checksecurityans
Get this error if you ran the code using 'vercel dev'

Cannot find module 'jsonwebtoken'
Require stack:
- /Users/josh.bechard/Dev/issue-reproduction/api/services/jwt-token-service.js
- /Users/josh.bechard/Dev/issue-reproduction/api/login/checksecurityans.js
-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>Did you forget to add it to "dependencies" in `package.json`?
Error! `node api/login/checksecurityans.js` failed with exit code 1

Or if you ran the file using node you might see an error like this one
[POST] /api/login/checksecurityans
17:08:28:62
2021-03-22T22:08:28.686Z    6d89535a-42b6-4836-89cd-1de6611f75ea    ERROR    Unhandled Promise Rejection  {"errorType":"Runtime.UnhandledPromiseRejection","errorMessage":"Error: error:0909006C:PEM routines:get_name:no start line","reason":{"errorType":"Error","errorMessage":"error:0909006C:PEM routines:get_name:no start line","code":"ERR_OSSL_PEM_NO_START_LINE","library":"PEM routines","function":"get_name","reason":"no start line","stack":["Error: error:0909006C:PEM routines:get_name:no start line","    at Sign.sign (internal/crypto/sig.js:110:29)","    at Object.sign (/var/task/api/node_modules/jwa/index.js:152:45)","    at Object.jwsSign [as sign] (/var/task/api/node_modules/jws/lib/sign-stream.js:32:24)","    at Object.module.exports [as sign] (/var/task/api/node_modules/jsonwebtoken/sign.js:204:16)","    at JwtTokenService.generateJwt (/var/task/api/services/jwt-token-service.js:57:29)","    at checkSecurityAns (/var/task/api/login/checksecurityans.js:4:33)","    at Server.<anonymous> (/var/task/___vc_helpers.js:813:19)","    at Server.emit (events.js:315:20)","    at parserOnIncoming (_http_server.js:874:12)","    at HTTPParser.parserOnHeadersComplete (_http_common.js:126:17)"]},"promise":{},"stack":["Runtime.UnhandledPromiseRejection: Error: error:0909006C:PEM routines:get_name:no start line","    at process.<anonymous> (/var/runtime/index.js:35:15)","    at process.emit (events.js:327:22)","    at process.emit (/var/task/___vc_sourcemap_support.js:587:21)","    at processPromiseRejections (internal/process/promises.js:245:33)","    at processTicksAndRejections (internal/process/task_queues.js:94:32)"]}
Unknown application error occurred

I do have a package.json file and it does include jsonwebtoken.
Environment
"jsonwebtoken": "8.5.1"
Node v14

I'm not sure exactly how Vercel runs the application, but my guess is it never finds package.json because it's in a subdirectory, so it never installs dependencies.
RSA requires private and public key files in a particular format (PEM) - you can't just pass some strings and expect them to work. Generate test keys using OpenSSL.


add Darwin Analytics :)

Thanks. Would appreciate adding Darwin here.
Please Read
Link Submission
Please submit your link(s) to the official Vue.js Awesome List repository (read first their contributing guide).
If they merge your pull request there, it will also be updated in this repository.
But if you really want to add it here, I would still review it.
Bug Fix or New Feature
For bug fixes or new features to this repository, delete this template text and proceed to provide information about the changes introduced in this pull request.
Contribution Agreement
By submitting a pull request to this repository, you are accepting this contribution agreement:

I dedicate any and all copyright interest in this software to the public domain. I make this dedication for the benefit of the public at large and to the detriment of my heirs and successors. I intend this dedication to be an overt act of relinquishment in perpetuity of all present and future rights to this software under copyright law.

Thanks @arpowers 🎉
I just want to note that the Vue.js devtools browser extension can't detect Vue.js usage in the site but it appears to be the case, too, for other Vue projects that use Vite.


Adding quotes for globbing

Added quotes to vars to prevent word splitting in case of spaces or special chars in dir names.
Ref: https://github.com/koalaman/shellcheck/wiki/SC2086

Yep, we're lazy.  Thanks!


Using with other kalman package - simdkalman

Hi @sbarratt !
I love this work!
I was just wondering if I could use the parameter estimation with a different kalman filter package like the one below. Just for speed purposes.
How would I then structure the model.
Many thanks,
Best,
Andrew
https://github.com/oseiskar/simdkalman

This will not work directly with that package. However, the math in our
paper can definitely be translated to the formulation used in that package.
On Wed, Oct 23, 2019 at 3:20 AM andrewczgithub<EMAIL_ADDRESS>wrote:

Hi @sbarratt https://github.com/sbarratt !
I love this work!
I was just wondering if I could use the parameter estimation with a
different kalman filter package like the one below. Just for speed purposes.
How would I then structure the model.
Many thanks,
Best,
Andrew
https://github.com/oseiskar/simdkalman
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/cvxgrp/auto_ks/issues/1?email_source=notifications&email_token=AB7LUGOATSFDTXYZC5H5RRDQQAQOBA5CNFSM4JD7EVY2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HTYVWQQ,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB7LUGPQC6F76TEBIS3SA4LQQAQOBANCNFSM4JD7EVYQ
.

Hi @sbarratt !! I have made some progress.
However i get an error with the below-
import simdkalman
kf = simdkalman.KalmanFilter(A, C, np.linalg.inv(W_neg_sqrt @ W_neg_sqrt), np.linalg.inv(V_neg_sqrt @ V_neg_sqrt))
kf = kf.em(measurements, n_iter=10)

ValueError                                Traceback (most recent call last)
 in
2
3 kf = simdkalman.KalmanFilter(A, C, np.linalg.inv(W_neg_sqrt @ W_neg_sqrt), np.linalg.inv(V_neg_sqrt @ V_neg_sqrt))
----> 4 kf = kf.em(measurements, n_iter=10)
~/env/lib/python3.7/site-packages/simdkalman/kalmanfilter.py in em(self, data, n_iter, initial_value, initial_covariance, verbose)
732             gains = True,
733             log_likelihood = False,
--> 734             verbose = verbose)
735
736         if verbose:
~/env/lib/python3.7/site-packages/simdkalman/kalmanfilter.py in compute(self, data, n_test, initial_value, initial_covariance, smoothed, filtered, states, covariances, observations, likelihoods, gains, log_likelihood, verbose)
526                 print('filtering %d/%d' % (j+1, n_measurements))
527
--> 528             y = data[:,j,...].reshape((n_vars, n_obs, 1))
529
530             tup = self.update(m, P, y, log_likelihood)
ValueError: cannot reshape array of size 119 into shape (119,48,1)
This is with your human migration example.
I was wondering if you could assist
MAny thanks and kind regards,
Andrew

According to the documentation (
https://simdkalman.readthedocs.io/en/latest/#simdkalman.KalmanFilter),
the order of arguments are:
simdkalman.KalmanFilter(state_transition, process_noise, observation_model,
observation_noise)

So, for you, this would be:
kf = simdkalman.KalmanFilter(A, np.linalg.inv(W_neg_sqrt @ W_neg_sqrt), C,
np.linalg.inv(V_neg_sqrt @ V_neg_sqrt))

On Sat, Oct 26, 2019 at 2:38 AM andrewczgithub<EMAIL_ADDRESS>wrote:

Hi @sbarratt https://github.com/sbarratt !! I have made some progress.
However i get an error with the below-
import simdkalman
kf = simdkalman.KalmanFilter(A, C, np.linalg.inv(W_neg_sqrt @ W_neg_sqrt),
np.linalg.inv(V_neg_sqrt @ V_neg_sqrt))
kf = kf.em(measurements, n_iter=10)
ValueError Traceback (most recent call last)
in
2
3 kf = simdkalman.KalmanFilter(A, C, np.linalg.inv(W_neg_sqrt @
W_neg_sqrt), np.linalg.inv(V_neg_sqrt @ V_neg_sqrt))
----> 4 kf = kf.em(measurements, n_iter=10)
~/env/lib/python3.7/site-packages/simdkalman/kalmanfilter.py in em(self,
data, n_iter, initial_value, initial_covariance, verbose)
732 gains = True,
733 log_likelihood = False,
--> 734 verbose = verbose)
735
736 if verbose:
~/env/lib/python3.7/site-packages/simdkalman/kalmanfilter.py in
compute(self, data, n_test, initial_value, initial_covariance, smoothed,
filtered, states, covariances, observations, likelihoods, gains,
log_likelihood, verbose)
526 print('filtering %d/%d' % (j+1, n_measurements))
527
--> 528 y = data[:,j,...].reshape((n_vars, n_obs, 1))
529
530 tup = self.update(m, P, y, log_likelihood)
ValueError: cannot reshape array of size 119 into shape (119,48,1)
This is with your human migration example.
I was wondering if you could assist
MAny thanks and kind regards,
Andrew
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/cvxgrp/auto_ks/issues/1?email_source=notifications&email_token=AB7LUGNKBXGCW5JPBXW4I53QQQFXZA5CNFSM4JD7EVY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECKEF3Q#issuecomment-546587374,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB7LUGLXVB5HOBUZDI5CPQLQQQFXZANCNFSM4JD7EVYQ
.

hi @sbarratt !! thank you so much for your help!!
I tried your code
kf = simdkalman.KalmanFilter(A, np.linalg.inv(W_neg_sqrt @ W_neg_sqrt), C,np.linalg.inv(V_neg_sqrt @ V_neg_sqrt))
kf = kf.em(measurements, n_iter=10)
but still received the error -

ValueError                                Traceback (most recent call last)
 in
68 measurements[~(K & ~M_test)] = np.ma.masked
69 kf = simdkalman.KalmanFilter(A, np.linalg.inv(W_neg_sqrt @ W_neg_sqrt), C,np.linalg.inv(V_neg_sqrt @ V_neg_sqrt))
---> 70 kf = kf.em(measurements, n_iter=10)
71 filtered_state_means, _ = kf.smooth(measurements)
72 yhat_em = filtered_state_means @ C.T
~/tutorial-env/lib/python3.7/site-packages/simdkalman/kalmanfilter.py in em(self, data, n_iter, initial_value, initial_covariance, verbose)
732             gains = True,
733             log_likelihood = False,
--> 734             verbose = verbose)
735
736         if verbose:
~/tutorial-env/lib/python3.7/site-packages/simdkalman/kalmanfilter.py in compute(self, data, n_test, initial_value, initial_covariance, smoothed, filtered, states, covariances, observations, likelihoods, gains, log_likelihood, verbose)
526                 print('filtering %d/%d' % (j+1, n_measurements))
527
--> 528             y = data[:,j,...].reshape((n_vars, n_obs, 1))
529
530             tup = self.update(m, P, y, log_likelihood)
ValueError: cannot reshape array of size 119 into shape (119,48,1)
Kind regards,
Andrew

What’s the shape of measurements
On Mon, Oct 28, 2019 at 2:42 AM andrewczgithub<EMAIL_ADDRESS>wrote:

hi @sbarratt https://github.com/sbarratt !! thank you so much for your
help!!
I tried your code
kf = simdkalman.KalmanFilter(A, np.linalg.inv(W_neg_sqrt @ W_neg_sqrt),
C,np.linalg.inv(V_neg_sqrt @ V_neg_sqrt))
kf = kf.em(measurements, n_iter=10)
but still received the error -
ValueError Traceback (most recent call last)
in
68 measurements[~(K & ~M_test)] = np.ma.masked
69 kf = simdkalman.KalmanFilter(A, np.linalg.inv(W_neg_sqrt @ W_neg_sqrt),
C,np.linalg.inv(V_neg_sqrt @ V_neg_sqrt))
---> 70 kf = kf.em(measurements, n_iter=10)
71 filtered_state_means, _ = kf.smooth(measurements)
72 yhat_em = filtered_state_means @ C.T
~/tutorial-env/lib/python3.7/site-packages/simdkalman/kalmanfilter.py in
em(self, data, n_iter, initial_value, initial_covariance, verbose)
732 gains = True,
733 log_likelihood = False,
--> 734 verbose = verbose)
735
736 if verbose:
~/tutorial-env/lib/python3.7/site-packages/simdkalman/kalmanfilter.py in
compute(self, data, n_test, initial_value, initial_covariance, smoothed,
filtered, states, covariances, observations, likelihoods, gains,
log_likelihood, verbose)
526 print('filtering %d/%d' % (j+1, n_measurements))
527
--> 528 y = data[:,j,...].reshape((n_vars, n_obs, 1))
529
530 tup = self.update(m, P, y, log_likelihood)
ValueError: cannot reshape array of size 119 into shape (119,48,1)
Kind regards,
Andrew
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/cvxgrp/auto_ks/issues/1?email_source=notifications&email_token=AB7LUGIGT7CZXGYCFND35S3QQ2XZVA5CNFSM4JD7EVY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECMIYWI#issuecomment-546868313,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB7LUGLQKGMKS427ZZBO7QLQQ2XZVANCNFSM4JD7EVYQ
.

Hi @sbarratt !!
When i do
measurements.shape
I get -
(119, 48)

I’m not sure then. You might want to file an issue on the simdkalman
repository. I’m closing this issue.
On Tue, Oct 29, 2019 at 2:22 AM andrewczgithub<EMAIL_ADDRESS>wrote:

Hi @sbarratt https://github.com/sbarratt !!
When i do
measurements.shape
I get -
(119, 48)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/cvxgrp/auto_ks/issues/1?email_source=notifications&email_token=AB7LUGL54NJOVNDL5VLEDR3QQ76ETA5CNFSM4JD7EVY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECPZI3Q#issuecomment-547329134,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB7LUGNCES654A3Y5MVPAH3QQ76ETANCNFSM4JD7EVYQ
.

cheers @sbarratt ! appreciate your help
Best,
Andrew


Vue is not catching errors on server side in SSR when using async child setup

Vue version
3.5.13
Link to minimal reproduction
Vue SFC Playground
Steps to reproduce
Just open a link and you will see errors when SSR is ON.
When SSR is OFF everything works as expected.
Also, commeting the line with top-level await (making Comp.vue a sync component) will also work fine both with and without SSR.
What is expected?
In SSR mode the page is expected to be blank white for 1 second and then display error message from App.vue.
This works as expected with SSR turned off.
Basically onErrorCaptured should be triggered, child setup and <template> render immediately stopped and error message from parent component shown.
What is actually happening?
In SSR mode the page is blank for 1 second but then it tries to render the <template> of Comp.vue using the data that might not even exist (because it appears in setup after throwing error).
And even if it manages to render <template> correctly, it still does not trigger onErrorCaptured in App.vue and do not switch to show error message.
Any additional comments?
I am building a custom rendering package built on top of Vue and it heavily uses structures like these:
 // Wrappers are supposed to catch ALL errors and throws in child <Block /> and show nice error message

<BlockWrapper>
    <Block ... />
</BlockWrapper>

<BlockWrapper>
    <Block ... />
</BlockWrapper>

<BlockWrapper>
    <Block ... />
</BlockWrapper>

...

Because of this bug OR my misunderstanding of how to handle async errors in Vue 3, even when thrown it still tries to render child block's <template> even with missing data (because setup is stopped executing), throws on reading properties of non-existing objects and the whole Nuxt page breaks.
Please, don't tell me this is a no-fix. It would be a disaster... 😭

The error threw in setup is correctly be caught:
https://github.com/vuejs/core/blob/833f9ea1f70baec0c3c3147595e10c44e7f87503/packages/runtime-core/src/component.ts#L884-L891
Therefore, regardless of whether the setup is executed successfully or not (whether there is a correct setupState), the component will be rendered:
https://github.com/vuejs/core/blob/833f9ea1f70baec0c3c3147595e10c44e7f87503/packages/server-renderer/src/render.ts#L117-L119
If the setup executed failed, means will render component with an empty setupState.Is this the expected behavior?

Well this behaviour is really confusing and right now I don't have even an idea of how to catch async child errors in parent wrapper... I tried onErrorCaptured, deep copying child setup, passing error ref to child as a prop and etc.
All these solutions just fail because Vue on server-side tries to render template with broken setup state first, which 99% will cause more unhandled errors and break the whole page (in case of Nuxt).
So I desperately need either a fix or workaround 🥲

@noootwo Can you please give me an example with Suspense (which is turned on by default in Nuxt) and SSR enabled? I tried to create a workaround yersterday for hours and failed. I am rather new in Vue.

@noootwo Can you please give me an example with Suspense (which is turned on by default in Nuxt on root level) and SSR enabled? I tried to create a workaround yersterday for hours and failed. I am rather new in Vue.

@Gwynerva Can you use try/catch to handle the error in sub-component's setup? Like this, I'm not sure this is what you need.

Unfortunately, the whole point in my library is that wrapper handles the error and adds some handy UI, while child component can be almost anything: KaTeX formula, image, paragraph and etc. Child components are external, often provided by other libraries. And if something goes wrong it is a wrapper that has to catch any errors and display nice error message.

Handling errors inside child component eliminates one of main purposes of the wrapper — providing same error design no matter what wrapper is rendering inside.

Unfortunately, the whole point in my library is that wrapper handles the error and adds some handy UI, while child component can be almost anything: KaTeX formula, image, paragraph and etc. Child components are external, often provided by other libraries. And if something goes wrong it is a wrapper that has to catch any errors and display nice error message.

Handling errors inside child component eliminates one of main purposes of the wrapper — providing same error design no matter what wrapper is rendering inside. I tried to pass error ref as prop to child and use onErrorCaptured inside child but it fails anyways.
In my situation handling errors in child is a bad practice, because children are supposed "by design" to throw if something goes wrong so wrapper could nicely tell user about a problem in unified way.
Observable block system is a good example of what I am trying to do with Vue.

Sounds you can do like this, but this is just temporary measures. After this issue is resolved, there should be more humanized approaches available.

Still not applicable because it requires handling the error inside the component where is was thrown. And I have like a few dozens of such "child" components, and all of them can pontentially throw... I really need to handle erros in wrapper, and this wrapper must be completely outside of child component. The only possible connections would be possible with props, but still onErrorCaptured would be a perfect solution here.
<Wrapper> // Part of base library, provides info about <Child> and also catches its errors
    <Child /> // Can be an external, can throw, can do anything...
</Wrapper>

<Wrapper>
    <Child />
</Wrapper>

<Wrapper>
    <Child />
</Wrapper>

Anyways, thank you, I think your example will do for testing purposes for now to prevent the whole page crashing on every error.
But this seems like a major SSR issue to me because right now onErrorCaptured simply does not do what it must do. @edison1105

The example without Suspense and SSR, catch the error in setup and render. The example with Suspense and without SSR, only catch the error in setup, and skip render the component which execute setup failed.
It seems like there are different behaviors in different situations, which one is expected? @edison1105

These two examples capture the same error messages. Below are the modified versions, please observe the console.log
without Suspense and SSR
with Suspense and without SSR
When wrapped inside Suspense, the error message is not displayed because of error.value = e triggers an update of Suspense, causing the Comp not to resolve. I don't think this can be considered a bug.

The original issue arises because we catch exceptions during client-side rendering execution at https://github.com/vuejs/core/blob/a038505c653a1d0cb1e929257d3479cee83dcceb/packages/runtime-core/src/componentRenderUtils.ts#L94 However, on the server-side, we don't catch exceptions at https://github.com/vuejs/core/blob/bf3d9a2af41659a743706306fc798b3d215df5af/packages/server-renderer/src/render.ts#L192 I think this should be fixed.

I would argue about "minor" because I my opinion using standart onErrorCaptured on async components is not something very specific. In fact, I am surprised I am the first one to report it...
Either way, it's nice to know it's not a problem on my end. Very much looking forward to the fix, as I haven't been able to find a workaround and the bug is extremely annoying.

@Gwynerva
If possible, you can throw the exception in onServePrefetch, it will be correctly handed.

@edison1105 Does not seem to work or I am doing something wrong?
Also, tried to use you PR directly in my project and it also fails "vue": "vuejs/core#edison/fix/12575" :(

@Gwynerva
Oh, I made a mistake. Additionally, #12601 did not resolve the issue with Suspense not displaying correctly. I will continue to try to fix it later.

@Gwynerva

@edison1105 Does not seem to work or I am doing something wrong?
Also, is there a way to use your PR instead of main version of Vue? I tried "vue": "vuejs/core#edison/fix/12575" but that did not work.

Strange, onServePrefetch isn't working as expected. I'll check it later. You can try the preview package of #12601 via:
npm i https://pkg.pr.new/vue@12601

@Gwynerva
Could you please provide a reproduction that includes these error details? It can be a  github repository, preferably simplified by removing unnecessary deps. I will take a closer look at it.

@edison1105 Sadly, I can't use your PR on Vue SFC Playground. But I made a StackBlitz demo with your PR and reproduced the same example as in first post.
Right now it does not even catching errors in sync Comp setup (with Promise line commented). And still not working with async Comp setup (when Promise line is uncommented).
Expected behaviour: both sync and async Comp throw calls must result in showing div with "Error: Back to App.vue" text.

@Gwynerva
Playground with PR #12601

@edison1105 Now it is working with async Comp and not working with sync Comp (try commenting and uncommenting Promise line in Comp.vue). And this bug works even when SSR is turned off, also in both (async and sync) cases it warns in console 🤣

@edison1105 Now it is working with async Comp and not working with sync Comp (try commenting and uncommenting await ... Promise line in Comp.vue). And this bug works even when SSR is turned off, also in both (async and sync) cases it warns in console 🤣
To be more precise, it actually "kind of" works, but instead of my own error message "Back to App.vue" it shows an error from render when accessing unexisting properties, meaning it for some reasons still tries to render Comp.vue template even when it's setup failed.

I couldn't see where the sync component fails to work. It works fine in both SSR and non-SSR. I am doing something wrong?
Suspense + Sync Component + SSR + PR 12601
The error message changed is expected:
<Suspense>

{{ error }}

    <Comp v-else :foo="'Foo Is Here!'" />
</Suspense>

if Comp.vue is sync, both the setup and render of Comp will be called, so you will see two error messages, observe the console.log
if Comp.vue is async, when an expectation is thrown during its setup, it will be called, Suspense will patch and Comp will be unmounted, Comp never resolved, so its render function will not be called.

The point is that it is completely pointless to throw second error as it is just a consequence of setup which failed before.
And I need to display the actual problem, the error in setup and not the error when rendering component which gives no info, because why even try rendering component which already throwed in setup?
Basically I need the Vue current main behaviour without SSR [link]. As  you can see, without SSR it detects an error in Comp.vue setup, immediately stops and gives control to App.vue onErrorCaptured block which replaces it with error message, not even trying to touch child <template>.

@edison1105 Why sync Comp.vue calling both setup and render? Isn't sync version is supposed to trigger parent onErrorCaptured which causes a component replacement just as it happens in async version? Or why async version is not calling both setup and render?
I want to show only actual error, the error in setup. Am I supposed to show only first error in onErrorCaptured and silently supress all other errors? Because both sync and async children can appear in my error handling wrapper.
Looks totally not safe for me to supress errors...

When calling the setup function of a component

if the return value is not a Promise, the component's render function will continue to execute in the same tick.
if the return value is a Promise, it will wait for the Promise to resolve before executing render. In this case, the setup and the Promise resolution do not occur in the same tick. The entire process is as follows:

setup is executed and throws an exception.
error.value is assigned, triggering an update and placing the update function in the queue.
The event loop processes the asynchronous callbacks in the task queue.
update is executed.
The Comp.vue component is unmounted.
The Promise resolves, preparing to execute the render function of Comp.vue, but since Comp.vue has already been unmounted, it is no longer processed.

Regardless of whether the component is synchronous or asynchronous, the exception thrown in the setup function always comes first, followed by the exception in the render function.

Ok, I see now. So I guess my solution here is to display div with the first error only.
So the only problem left are hydration mysmatches in my project, but I guess they might be bacuse of this bug we discovered.

@Gwynerva
This hydration mismatch is not necessarily the same as yours. This bug is actually an edge case; if the tag is not p, there will be no issue.
if the tag is not a p, it will work as expected.see

I will investigate this and let you know. Thank you!

@edison1105 Still hydration mismatches when rendering nodes deep inside <Suspense> (in Nuxt suspense is on root level and it can not be used again somewhere deep inside).
Playground Example

@Gwynerva
This is the expected behavior. The SSR output content is three empty divs since SSR has no patch and Comp.vue renders nothing. for this scenarios, you should use data-allow-mismatch = "children" to ignore the mismatch warning.
see Playground

@edison1105 Does this mean there are no ways to do prerender errors in the way I want it to do (error in child, reaction in parent) with Suspense + SSR? It is not a really big deal I guess, because there are supposed to be no errors when building for production but still.

Does this mean there are no ways to do component replacement in parent when async child throws with Suspense + SSR?

I think so.

 Oh gods, this is a disaster...
Well, I think my only option here is to redesing some core functionality.
Maybe require every not-ClientOnly child to be sync, which receives async data through props, and that async data is built in parent, where I can catch async errors right in the parent.


$router.navigate from controller

Might be a duplicate of #184 and #222
It seems that the navigation is never triggered when I'm doing something like :
$router.navigate('/register');

in a controller, but.
$router.parent.navigate('/register');

works.
I tried to figure out why this is not working, and it seems that the activatePorts method of the ChildRouter failed to query the view ports. It looks like this.ports is empty in the queryViewports method... I'm sorry, I can't figure myself how to fix it, but I'm pretty sure there is a bug here...

I can't seem to even get the second line to work in the activate function of the controller.


Terms and conditions functionality

Laravel Version: 8.55.0

PHP Version: ^7.3|^8.0

Database Driver & Version:

Description:
since i run composer update from 8.41.0 to  8.55.0 laravel version
i have this error :
Class 'League\CommonMark\Environment' not found
it worked well before...
Steps To Reproduce:

You probably used CommonMark v1.6 before and now you use v2.0
Laravel supports both so the error should be in your Code base.
You can either fix the CommonMark Version v1.6 in the composer.json for now with
composer require league/commonmark:^1.6

Or update the used reference to use the newer version instead. (Please take a look at the upgrade guide of CommonMark for further information)
Namespace of the new Environment Class:
use League\CommonMark\Environment\Environment;

You probably used CommonMark v1.6 before and now you use v2.0
Laravel supports both so the error should be in your Code base.
You can either fix the CommonMark Version v1.6 in the composer.json for now with
composer require league/commonmark:^1.6

Or update the used reference to use the newer version instead. (Please take a look at the upgrade guide of CommonMark for further information)
Namespace of the new Environment Class:
use League\CommonMark\Environment\Environment;

thanks for your help it works


Add more specific name for sonarqube analysis.

Black Duck Security Report
Merging #21 into master will not change security risk.
Click here to see full report


!!maxradiobuffer Command

The concept is simple. !!maxradiobuffer will clamp the max amount that FFMPEG will buffer before stopping the current radio stream. This command would be useful for when a user leaves a voice channel for an extended amount of time. Right now, Nadeko will pause the stream, but continue to buffer until resumed. This costs disk space and CPU time for no captive audience, so this command can help optimize Nadeko as well.
Proposed Syntax: !!maxradiobuffer  or !!mrb

no, it will bo done differently

For reference, Kwoth is referencing native OPUS talked about in #943


Removing package or replace . from model

When I generating a model, it result in a model.HTTPError
// HTTPError generic struct
type HTTPError struct {
Code    int    json:"code" example:"400"                   // report the status http code
Message string json:"message" example:"status bad request" // is an human readable error message
}
And :

A good feature is the way to removing the package from doc.json or replace the . with some other character like _.

The idea of a hiding package name will increase the conflicts due to similar "User" structs may be found in different packages like service, repository, models, dto and event from external packages.
Please provide a suggestion about how this should be handler according to the following  example:
file: models/user.go
type User struct {
	ID int64
	Username string
	Email string
}

file: http/response/user.go
import "models"

type User struct {
	User
	RequestID string
}

I'm dealing with the same issue, the suggestion with the _ is good, it could be use configurable - have the user set a delimiter as a flag.

I'm dealing with the same issue, the suggestion with the _ is good, it could be use configurable - have the user set a delimiter as a flag.

Excuse me, have you solved it ?

I'm dealing with the same issue, the suggestion with the _ is good, it could be use configurable - have the user set a delimiter as a flag.

Is it better to use camelCase ?


Fixed saving model

Correctly saves X labels
Added scatterz option

Coverage decreased (-0.2%) to 72.943% when pulling 09fb0da24b9a77a2c06e81734cd63c4fce7f871f on dev into fb38cf50a93f8f2c361ea985f645f96f0a32b942 on master.


Why doesn't this support -alluserconnection

This can't be applied to -alluserconnection VPN Connections.

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

ID: c2d70f95-0d79-c79d-407e-62ce149c1dfd
Version Independent ID: 92eed0c2-bd40-4b49-1fb7-a1060771fa1e
Content: Set-VpnConnectionTriggerDnsConfiguration (vpnclient)
Content Source: docset/windows/vpnclient/set-vpnconnectiontriggerdnsconfiguration.md
Product: w10
GitHub Login: @coreyp-at-msft
Microsoft Alias: coreyp

@officedocsbot unassign @e0i
@officedocsbot assign @yogkumgit

Hello @michaelkrieger
Thanks for your feedback.
Can you kindly tell me if is there any specific issue you see with the documentation of the cmdlet?
Tell me please if I misunderstood but I think that maybe your question is more suitable for user voice, kindly visit here.
https://windowsserver.uservoice.com/forums/295047-general-feedback
Thank you

@officedocsbot close


[Fix #12842] Add new Style/StaticSend cop

Fixes #12842.
Summary
Detects the use of the public_send method with a static method name argument. Since the send method can be used to call private methods, by default, only the public_send method is detected.
# bad
obj.public_send(:static_name)
obj.public_send('static_name')

# good
obj.static_name

Safety
This cop is not safe because it can incorrectly detect based on the receiver. Additionally, when AllowSend is set to true, it cannot determine whether the send method being detected is calling a private method.
AllowSend option
This cop has AllowSend option.
AllowSend: true (default)
# good
obj.send(:static_name)
obj.send('static_name')
obj.__send__(:static_name)
obj.__send__('static_name')

AllowSend: false
# bad
obj.send(:static_name)
obj.send('static_name')
obj.__send__(:static_name)
obj.__send__('static_name')

# good
obj.static_name

Before submitting the PR make sure the following are checked:

[x] The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
[x] Wrote good commit messages.
[x] Commit message starts with [Fix #issue-number] (if the related issue exists).
[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[x] Added tests.
[x] Ran bundle exec rake default. It executes all tests and runs RuboCop on its own code.
[x] Added an entry (file) to the changelog folder named {change_type}_{change_description}.md if the new code introduces user-observable changes. See changelog entry format for details.

I don't think this cop should concern itself with constants (at least by default). Surely I used a constant to intentionally factor it out, unless the constant is referenced only once I'd want to keep it.

Since a constant is generally immutable by definition, I think it can always be targeted without needing options. Are there any valid cases for excluding a constant?

There are barely any cases I could find that use public_send over send for this (send is just so much more used). This is basically what I was thinking about: https://github.com/hopsoft/turbo_boost-commands/blob/9b4535ca0fe17481e70ae292d03db5b3e984d376/test/application_system_test_case.rb#L11
It uses a constant to have one place that holds which browser is being tested. I don't believe the code will improve by calling the method directly.

I don't believe the code will improve by calling the method directly.

I see! Since using constants is intentional in some cases, it seems better to respect the user's intent and continue to target only string literals and symbol literals as is.

I'm not sure about the name.

The cop name Style/StaticSend has been updated to Style/SendWithLiteralMethodName.


Wrong behavior when run "mvn azure:select-subscription -DsubscriptionId=..."

Plugin name and version
azure-maven-plugin 0.1.0-SANPSHOT
Plugin configuration in your pom.xml

Expected behavior
Set the specify subscriptionId as the active subscription and not list all selectable subscriptions.
Actual behavior
After run mvn azure:select-subscription -DsubscriptionId="put your subscriptionId here", it list all the subscription.

Steps to reproduce the problem

Run mvn azure:login on a sample project
Run mvn azure:select-subscription -DsubscriptionId="put your subscriptionId here"

Command chang to: mvn azure:select-subscription -Dsubscription="put your subscription guide here"
Test Pass
Bits: https://github.com/microsoft/azure-maven-plugins/tree/feature-spring


Timer Button: The button under the timer has a state that makes it very hard to read.

I think this is a quick fix and most likely from bootstrap. simply take out the background of the button. This is on desktop, but I have noticed this on phone as well.

If this isn't happening on Desktop chrome, don't worry about it for now.

Fixes as of 4/7.


Grub installation fails saying no space left on device

My grub installation is fails saying no space left on device. I don't know if this has something to do with manjaro sway but still posting this here to get help if someone else has solved it. Attaching the screenshot as well.

As you can see, I don't have other boot entries as well. Only windows and my USB.

Could you maybe provide some more information regarding what the environment is?

closing for now dueto no reaction.


travis: add node 13 and remove 8 and 11

Remove node v8 and v11 from the travis yaml and add node v13

Merged, thanks @andrewhughes101!


[question] How to package when there are two many bundles in dist

I used react react-router, used the code split with webpack,so  when I compile the code to the dist, there are the list:
  1.search.js
  2.counter.js
  3.filter.js
  4.mark.js
  5.tags.js
  logo.png
  index.html
  vendor.js
  app.css
  node_modules/

but when after packaging the app, I open the app, click the link, the router did not work.the reason is  the file was not found.

How do I resolve this problem?

Did you resolve this issue? If not, where are the files being outputted to?

Closing due to no response


Customize generated commit message

Feature request
We have custom commit message pattern build on top of conventional commits. Please tell me where in the code I can add instructions to the AI service to append some additional information for the first line of the commit message. I would do it myself, I just need direction where is the right place in the code to add this.
Why?
We have custom commit message pattern
Alternatives
No response
Additional context
No response

You can edit here
https://github.com/Nutlope/aicommits/blob/604def8284361b8827087350fe6fcb6d9e2de836/src/utils/prompt.ts#L21-L35


Guide: Describe integrations for zebrunner guide

Description
Describe integrations for zebrunner guide:
https://zebrunner.github.io/documentation/guide/integrations/

high level information added: https://zebrunner.github.io/documentation/guide/integrations/


SSN display vuln has no spec

This is probably on me, as this was in there the first time around. I think it should be simple to add, though I may not have time this time around :/

actually, there is one ... hmmm: https://github.com/OWASP/railsgoat/blob/master/spec/vulnerabilities/sensitive_data_exposure.rb#L12

Fair to close the issue then?

ok - closing this, I'm not sure why the spec wasn't going to pending when I was expecting it to, but I guess after fixing other things it went pending with the rest of them.


restrain bbci_import_dependencies

I would prefer to be asked, whether I want those externals to be downloaded, i.e., make it optional based on user input.

The problem is that we wanted to prevent some manual "asking-for-input" due to cluster-jobs etc, which may not run then...
How about asking for input once and then writing a file into the /external folder such that all following startups do not ask for input independent on whether or not dependencies were downloaded...


Disable DPI scaling

Which operating system does the issue occur on?
Ubuntu
If on linux, are you using X11 or Wayland?
X11
I got this issue when Glutin 0.19 PR is merged
The WINIT_HIDPI_FACTOR=1 environment variable didn't work either I use
export WINIT_HIDPI_FACTOR=1 and in alacritty config
env:
  TERM: xterm-256color
  WINIT_HIDPI_FACTOR: 1.0

The only way I know is to disable it on every command line execution, but it didn't work in .desktop entries.

Disabled:

I've created a PR which sets the environment variables before starting the Alacritty window. Please let me know if this fixes the problem for you:
https://github.com/jwilm/alacritty/pull/1769


Handle combined repr attributes like #[repr(C, u8)] in repr checks

https://rust-lang.github.io/unsafe-code-guidelines/layout/enums.html#explicit-repr-annotation-with-c-compatibility

Currently, I suspect that #[repr(C, u8)] won't get detected as either #[repr(C)] or as #[repr(u8)], which I believe can lead to both false-positives and false-negatives. Due to the false-positives, this is a bug.
H/t https://twitter.com/bitshiftmask/status/1562185690208735233 + a private Twitter account I'm not going to name, you know who you are :) Thank you both!

This was closed by merging #171.


Unable to open solution on "develop" branch

When downloading the latest version of the branch and trying to open it, I get the following error on Visual Studio when it loads the xproj files:

Source\Repos\ApplicationInsights-aspnetcore1\src\Microsoft.ApplicationInsights.AspNetCore\Microsoft.ApplicationInsights.AspNetCore.xproj : error  : The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\DotNet\Microsoft.DotNet.Props" was not found. Confirm that the path in the  declaration is correct, and that the file exists on disk.

I do not have that "DotNet" folder under C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0. Am I missing an installation?

Hello,
The develop branch is using CLI run time. You need to install dotnet CLI in order to build the project. We also need visual studio tools to support that. That is still in develop mode. Can you please checkout from master for now. We shall update the instructions about the runtime installations and visual studio tools to support CLI soon.
Thanks

Sure thing. I will use master to send the changes for issue #23
Thanks!


exclude slf4j-log4j12

I believe this was inadvertently pulled in by #2857 and is causing ambiguous slf4j binding.

consider for 0.9.1?

ah, yeah, I think we used to get ZK through the Curator dependency which had excluded log4j.
👍

👍 agreed, 0.9.1 backport would be nice


reindex on assoc updates only if already saved

Only trigger a re-index if the Article has already been saved. This is important is you ever create an object with .new instead of .create and then add associations to it before saving (note that rails is smart and will "wait" to do all the database work on .save in this case).

Hi, that sounds legitimate -- although, would you have an example Ruby code to demonstrate how it breaks without the condition? I'd like to see it not only to satisfy my curiosity, but to better understand the flow there.

So, I believe the following would exercise the error (based on the example in examples/activerecord_associations.rb)
category = Category.create title: 'One'
author = Author.create first_name: 'John', last_name: 'Smith', department: 'Business'

article  = Article.new title: 'First Article'
article.categories << category

article.authors << author
article.save!

Right, thanks for pointing it out, I can see it in Pry now!
We definitely need to fix that example, I'd like to consider another way of expressing the intention there, however: instead of using if a.id, what if we used if a.persisted? That seems to me to convey the intention better, ie. Save the document when the database record has been already stored, as opposed to Save the document when the database record has an ID.
I can imagine scenarios where the latter approach would make sense, eg. when you're setting the IDs yourself in application code, but in the context of the example, which relies on the database-generated ID, the persisted? approach is more didactic?

Yup makes sense -- wanting to push to elasticsearch with an id but before saving would be an odd use case, and now this example makes it pretty clear that you need consider the details of when you do/don't index the Article anyway.


Correct warning in managed-html5-runtime-fiori-mta example makes app unavailable in Launchpad Content Manager

Hi Marius,
with the current configuration of the managed-html5-runtime-fiori-mta example I get the following warning during deployment:

[WARNING] Destinations content in module managed-fiori-destination-content is defined in a deprecated location (in a parameter of a requires element). Move the content parameter from the requires parameters to the modules parameters.

but when I correct that by moving the content section as I did in the pull request, the error is gone, but the app isn't available in Launchpad Content Manager anymore. Can you clarify this issue internaly?
Best regards
Gregor

Will do. Thanks Gregor

Hi Gregor,
You might have seen the fix from @ddonchev to your PR. I think that resolves the issue you found, correct?
I also updated the Fiori Sample with the same fix in @multi-cloud-html5-apps-samples@8c234ed

I'll close this one as it seems to be fixed. Please reopen if you disagree.


Integration of Spread with CI

We imagine people will want to integrate Spread with their CI system with deploys triggered by pushed commits. We're open to discussion around how that setup will work.

We'd really like to see integration with https://circleci.com/
For our workflow, we push to github, tests get run on circle, and if all the tests pass, the containers are deployed.
I think CircleCI might be one of the easier CIs to integrate with, so it might be a good first model for how CI integration will look.


allow-table-extended-to-handle-more-than-2048-chars (#326)

Resolves #326

Description
This PR allows the adapter to handle strings of more than 2048 characters when running show tables extended in Databricks. This is currently preventing users from being able to run this command when using dbt if they have a large number of tables in any given schema.
The way this is done is that it will pass the * in instances where the string length of the pipe separated tables is more than 2048 chars.
I have successfully tested both unit tests and tox -e integration-databricks-sql-endpoint.
Checklist

[x] I have run this code in development and it appears to resolve the stated issue
[x] This PR includes tests, or tests are not required/relevant for this PR
[x] I have updated the CHANGELOG.md and added information about my change to the "dbt-databricks next" section.

Hi @andrefurlan-db! Sorry to tag you here but was just wondering: when can we expect this change to be merged, please?
TIA!

Any update on when we can expect to see this fix implemented? @rcypher-databricks @andrefurlan-db ?

This went stale because of inattention. But the change has been approved. I just rebased the branch off of main so we can rerun the integration tests. Will merge once these pass.


prefer existing social media over first found

I noticed when running social_media.py --verify [--resolvetw], candidate_for is currently returning the first regex that passes.  This changes the logic to return the existing candidate first if its found.  This causes the output of the script to be less verbose, like so:
[W000437] mismatch on http://www.wicker.senate.gov - SenatorWicker -> AjitPaiFCC
Also, would anyone object to making lines like this debug-only?
Found redirect, downloading http://www.thune.senate.gov/public/ instead..

:+1:, and sure, making that line debug only sounds just fine.


Create cluster/addons for things to put into a kubernetes cluster

Moved DNS and heapster stuff there to start.

cc: @thockin @vishh

LGTM

Love it.


Update docs about pinned posts

Checklist

[x] I have read the contributing guidelines.
[x] There are no similar request on existing issues (including closed ones).
[x] I have read the project progress and know the current progress of the project.
[x] I was in the develop branch of the latest code.

Is your feature request related to a problem? Please describe
I followed the guide in the README and was trying to create my own content. I copied the frontmatter from a post from the original _posts folder in your repo. I didn't want to pin a post, so I changed the value to pin: false instead of removing this setting. I thought this would be the safer option but doing this causes the post to disappear from the homepage. There are no errors in the terminal running "bash tools/run.sh" but the homepage shows just a clock icon and an Invalid Date message.

This sent me down a rabbithole debugging the date settings etc before I went back to the original repo and copied a post exactly to test (which worked) and then changed one setting at a time.
Describe the solution you'd like
Updating the documentation to specifically state indicate that the pin setting should be removed if you don't want to pin a page.
Describe alternatives you've considered

Setting pin: false in the frontmatter works like any other unpinned post, in the same way as omitting the pin setting does.
Additional context

I really love this theme and am especially impressed and pleased with how good the documentation has been to follow and get started with. I'm starting to open source some of my own projects and I am finding out how much time and effort goes into great documentation. Kudos for your time and effort, I really appreciate it.

Thank you for your suggestion, this issue is a bug in a sense.  :)


Auth only needs refresh token

If you send a bad access token and a good refresh token. Server will send you a new access token. This is really bad because now a hacker only needs someone's refresh token to make requests as them.

Close this issue now and privately reach out to Ben. https://github.com/benawad/dogehouse/blob/staging/SECURITY.md

Don't submit issues if there is a security issue.

This is expected behavior, access token is only used for caching purposes

Oh wow, I think it would be more secure if you checked if the access token has valid signature and is not expired at least before letting the user authenticate.