Embed buildkit

Currently the setup instructions start with "make sure dagger-buildkit is running". We should remove this dependency on an external buildkit daemon, by embedding buildkit into the cloak binary.

One of the features that everyone I worked with loved about Concourse CI was the single binary approach. It was just shy of 300MB (so almost as big as Windows '98), but it had absolutely everything built-in, including the CLI. It had Windows, Mac & Linux variants, and it was trivial to run it on any platform. The vast majority of people would run it on Linux because it had proper support for containers. Windows & Mac were storing state in dirs and were not as mature, but they worked and people used them.
This is the experience that I imagine us having for the new Dagger:

WDYT @vito?

If certain features are not supported on a particular platform today, it's OK to return not implemented errors. In terms of the platforms that BuildKit supports, this suggests to me that everything we care about is supported: https://github.com/moby/buildkit/releases/tag/v0.10.4

To keep you all in touch, the second option seems very promising -> embedding the go distributed binary with //go:embed binary. Using below test script:
package main

import (
	_ "embed"
	"fmt"
	"os"
	"os/exec"
)

//go:embed binary
var f []byte

func main() {
	_ = os.WriteFile("foobar", f, 0755)
	defer os.Remove("foobar")
	out, err := exec.Command("./foobar", "version").CombinedOutput()
	if err != nil {
		fmt.Print("ok", err)
		return
	}
	fmt.Printf("Output: %s\n", out)
}

I am able to play with "foobar", which is the go binary. It would require to have different "embed" go binary for each distribution (in our pipeline), but it seems manageable. Next step today: auto-build my fork of cloak using that very script.

Next challenge around that: we currently only build on linux, so managing windows + mac will then become more important

To keep you all in touch, the second option seems very promising -> embedding the go distributed binary with //go:embed binary.

I think it will be more than this. Once we actually want to build something with the embedded binary we will also need to have access to a GOROOT (i.e. all the stdlib source code), so that will need to be embedded too I believe.
Overall, my thinking is that no matter what we will need a provisioner (docker, lima, etc.), right? And so it seems simplest to me to just re-use what we support for provisioners as builders too. So we can embed our source code into our binary but then just use docker build or lima whatever to actually build it. That means that we have no new dependencies or complications on top of the dependencies and complications we need for provisioning/executing daggerd.
Another option here would be to either A) embed the full golang container image into our binary (which we can then unpack and use locally) or B) import a container image pulling library that allows us to pull and unpack it locally when needed. I'm not sure, but we might be able to get away with a rootless approach here through use of LD_LIBRARY_PATH (that's the safe one, not to be confused with the evil LD_PRELOAD) and thus avoid the need to chroot or setup namespaces, etc.. But this would be more advanced, probably not the right starting place.
I agree that if we go the route of embedding the go binary and GOROOT it's not the absolute end of the world, but I am quite confident it will eventually be a pretty huge gotcha for anyone building or packaging dagger. One of go's touted benefits is that if you give it the right build arguments it will create a statically linked binary for you. If we go this route, that's just not possible anymore as there will always be this secret link against libc.

Ok, so (2) seems doable BUT isn't the easiest to implement. As seen with @sipsma today I'll implement, for tomorrow, the pluggable provisioner approach to merge the current Buildkit integration into cloak (to avoid parallel work for too long).
We'll then be able to explore all the other options from there
Another source of reference: https://github.com/k0sproject/k0s, which has 3 approches (using provisioners), with and without provisioners.

Quick side-note: one weakness to our approach was we left the user responsible for managing the sudo concourse worker command lifecycle. Maybe we could have a "systemd unit" provisioner to make it easier to daemonize. This would only be relevant to a Linux host though.

@vito
Thanks for the context there, super interesting and the matryoshka doll idea was particularly delightful :-)
One thing to clarify, part of what we are doing here is to wrap buildkitd. We aren't considering this a fork because we are still using the same buildkitd codebase, we just are recreating their main func and making it a subcommand of cloak. We're doing the same for buildctl too.
The main problems we need to solve are:

cloak may need to provision itself on platforms that are different than what it was built for (i.e. cloak on a macbook needs to deploy itself to a linux vm running in docker desktop/lima/etc.).
Like you mentioned, there are more binaries to buildkitd than just buildkitd (runc, emulators, etc.)

Is there a reason I missed to avoid embedding pre-built binaries?

For the use case here this would entail embedding cloak and any other required binaries (runc, emulators) for each target platform we may want to support. I suppose runc and emulators could also become subcommands of cloak too, so then that simplifies the problem to cloak embedding cloak binaries for all other platforms.
My main concern there was the enormous bloat in the binary size, which was one reason why I liked the approach of embedding source code only as much as possible and then re-using our provisioners (docker, lima, etc.) to also do the building. However, I'm realizing that might be a personal bias worth reassessing (I did a lot of IoT stuff in previous jobs where huge binary generally == bad). The fact that @gerhard and other concourse users did not consider 300 MB to be a deal breaker probably indicates that it's not the mortal sin I thought it was.
If we assume big binary is fine, then yeah it's by far the simplest approach in terms of runtime behavior (build time is a bit complicated, but that's fine obviously).

I do think that no matter what we need to make all of this pluggable and behind interfaces like:

Builder - give me a cloak binary (or rootfs with binaries) targeting a given platform, hypothetical example implementations:

Retrieve an embedded binary/rootfs
Download a corresponding binary/rootfs from the internet somewhere (check its hash and all that)
Use embedded source code to build cloak using docker build (or various equivalents)
Use embedded source code to build cloak using cloak (once we've bootstrapped ourselves sufficiently)

Provisioner - run cloak somewhere, example implementations:

docker
lima
fork/exec (need sudo)
embedded rootless container engine
k8s
CLOAK_HOST env (connect to existing one)

The thing is today we do already have 2 Provisioner implementations (docker run and BUILDKIT_HOST env), so what we're trying to do now is add our first Builder implementation. I think given that we already have a dependency on docker run in our main current Provisioner, the absolute simplest route is to add a Builder that just uses docker build. No new dependencies.
I think this is the shortest route to something usable. It may also be desirable in that until we have sufficiently stabilized cloak, it may not be good to bootstrap and use cloak to build cloak (my instinct anyways, low confidence). So even when we want to start embedding binaries in binaries, we will need to build those binaries somehow.docker build is probably an okay solution for enabling that until we've reached the point of being able to use cloak.
That's why I suggest starting here with docker build+embedded source code, but in such a way that its behind an interface that can have more implementation in the future.

Oops, a correction now that I've checked how Concourse is actually packaged these days: it doesn't do an all-in-one binary anymore, instead it's a big (1.4GB!!!) .tgz that you unpack to /usr/local/concourse that just includes all of its dependencies under bin/ and other dirs. They aren't embedded anymore. The approach is similar in spirit; it's still bundling binaries, but the user manages where they're placed instead of having a self-extracting binary.
I think we opted to do this because we had a ton of assets to unpack and it was faster to just have the user do it at installation time rather than pay a penalty at runtime.

One thing to clarify, part of what we are doing here is to wrap buildkitd. We aren't considering this a fork because we are still using the same buildkitd codebase, we just are recreating their main func and making it a subcommand of cloak. We're doing the same for buildctl too.

Similar for us - concourse worker was just glue for running gdn and registering it as a Concourse worker. But instead of re-implementing main we just ran gdn as a sub-process.
We originally tried using its code directly, the same as you're proposing, but it was nontrivial to integrate its build into ours. Just shelling out ended up being less of a hassle and meant we could very quickly just bump an asset when it came time for security updates without worrying if any part of the build process or dependencies (replace rules in go.mod etc) had changed.

My main concern there was the enormous bloat in the binary size, which was one reason why I liked the approach of embedding source code only as much as possible and then re-using our provisioners (docker, lima, etc.) to also do the building. However, I'm realizing that might be a personal bias worth reassessing (I did a lot of IoT stuff in previous jobs where huge binary generally == bad). The fact that @gerhard and other concourse users did not consider 300 MB to be a deal breaker probably indicates that it's not the mortal sin I thought it was.

Totally fair. We did get a snarky tweet about it. :laughing: But yeah it didn't seem to cause any actual issues.
If we're considering embedding Go itself though, it's not exactly tiny:

File name
Kind
OS
Arch
Size
SHA256 Checksum

go1.19.1.linux-amd64.tar.gz
Archive
Linux
x86-64
142MB
acc512fbab4f716a8f97a8b3fbaa9ddd39606a28be6c2515ef7c6c6311acffde

Maybe parts of it could be stripped out?
The sum of all binaries in buildkit's .tgz is 111.5MB, which is definitely heftier than I had hoped but it's around the same ballpark. If we remove buildctl (I don't think we need it?) that would save 25M.
❯ ls -lh
total 111M
-rwxr-xr-x 1 vito users  25M Oct 20  2015 buildctl
-rwxr-xr-x 1 vito users  38M Oct 20  2015 buildkitd
-rwxr-xr-x 1 vito users 5.2M Oct 20  2015 buildkit-qemu-aarch64
-rwxr-xr-x 1 vito users 3.8M Oct 20  2015 buildkit-qemu-arm
-rwxr-xr-x 1 vito users 2.9M Oct 20  2015 buildkit-qemu-i386
-rwxr-xr-x 1 vito users 3.3M Oct 20  2015 buildkit-qemu-mips64
-rwxr-xr-x 1 vito users 3.2M Oct 20  2015 buildkit-qemu-mips64el
-rwxr-xr-x 1 vito users 3.8M Oct 20  2015 buildkit-qemu-ppc64le
-rwxr-xr-x 1 vito users 3.4M Oct 20  2015 buildkit-qemu-riscv64
-rwxr-xr-x 1 vito users 2.9M Oct 20  2015 buildkit-qemu-s390x
-rwxr-xr-x 1 vito users  20M Oct 20  2015 buildkit-runc

This would definitely start to add up if we start bundling each supported platform/architecture. Maybe we could have a "netboot" version that lazily downloads the appropriate package as needed? We'd still want a batteries-included version for behind-the-firewall though...

+1 to the builder/provisioner ideas. I think those are important primitives to have around so we can stay nimble and adjust as we encounter new deployment schemes.

I am closing this issue because, although the need to bundle buildkit still exists, our preferred solution is no longer to bundle everything in the same binary. Rather, we should aim to make the Dagger Engine a fully server-side component (instead of the current mix of client-side API router and server-side solver (aka buildkit) - then bundle it all into an OCI image. We should start fresh and discuss this new approach in a new issue.


Calling vkGetPhysicalDeviceSurfaceCapabilitiesKHR triggers Objective C error

Hi, I am having some issues with a Vulkan function triggering an Objective C error.
My code queries for swap chain capabilities in the following snippet. I am trying to access the currentExtent struct inside the VkSurfaceCapabilitiesKHR object.
// instance, physicalDevice, metalSurface are initialised. logicalDevice is not yet initialised.
VkSurfaceCapabilitiesKHR surfaceCapabilities;
std::vector<VkSurfaceFormatKHR> surfaceFormats;

vkGetPhysicalDeviceSurfaceCapabilitiesKHR(physicalDevice, metalSurface, &surfaceCapabilities);

uint32_t numFormats;
vkGetPhysicalDeviceSurfaceFormatsKHR(physicalDevice, metalSurface, &numFormats, nullptr);
if (numFormats) {
    surfaceFormats.resize(numFormats);
    vkGetPhysicalDeviceSurfaceFormatsKHR(physicalDevice, metalSurface, &numFormats, surfaceFormats.data());
}

However for some reason the vkGetPhysicalDeviceSurfaceCapabilitiesKHR  call produces the following error, but when it is commented out the vkGetPhysicalDeviceSurfaceFormatsKHR  call works as expected.
2020-06-13 19:11:48.957138+1000 VulkanExperimentation[1512:56079] -[_NSViewBackingLayer naturalDrawableSizeMVK]: unrecognized selector sent to instance 0x600000c5d5f0
2020-06-13 19:11:48.957297+1000 VulkanExperimentation[1512:56079] Failed to set (contentViewController) user defined inspected property on (NSWindow): -[_NSViewBackingLayer naturalDrawableSizeMVK]: unrecognized selector sent to instance 0x600000c5d5f0

Similarly, when I run the following after simply commenting out the failing line above, a similar message comes up.
vkCreateSwapchainKHR(logicalDevice, &createInfo, nullptr, &swapChain);

2020-06-13 20:47:24.897935+1000 VulkanExperimentation[2482:100730] -[_NSViewBackingLayer setDevice:]: unrecognized selector sent to instance 0x600000c7e2e0
2020-06-13 20:47:24.898175+1000 VulkanExperimentation[2482:100730] Failed to set (contentViewController) user defined inspected property on (NSWindow): -[_NSViewBackingLayer setDevice:]: unrecognized selector sent to instance 0x600000c7e2e0

I am on MacOSX 10.15.3 with MoltenVK 1.0.41 dynamically linked. My code adds the VK_KHR_surface v25 and VK_EXT_metal_surface v1 instance extensions and the VK_KHR_swapchain device extension when it creates the logical device.
I have looked at the cube demo which uses function pointers for the surface capabilities call, but replacing the function pointer with a standard function call does not trigger the above error in that project for some reason.
I feel like I have made an elementary mistake somewhere as I am relatively new to C++ and macOS development, but I am at a loss as to what is causing these issues. Any help would be much appreciated.

What kind of layer did you pass to vkCreateMetalSurfaceEXT()? It has to be a CAMetalLayer, or you'll see errors like that.

Hi Chip, thanks for the suggestions! I have double checked my surface creation code and it should use a CAMetalLayer, and the makeBackingLayer function has been replaced to return a CAMetalLayer. However, when I print [self.view.layer isKindOfClass:[CAMetalLayer class]] it prints NO whereas it returns YES for CALayer.
Upon further inspection, lo and behold I used the UIKit method for creating a CAMetalLayer backing layer instead of the AppKit method (source, this basically means I was overriding -(CALayer*) makeBackingLayer and +(Class) layerClass instead of the AppKit method of running self.view.layer = [CAMetalLayer layer] directly.)
Fixing that issue causes my swap chain code to work like a charm :) Thanks for the pointers, I never would have suspected the surface was the issue otherwise as it never threw any errors in any other function calls until now!
For anybody with similar issues, here is an abbreviated section of my working layer creation code:
- (void)viewDidLoad {
    [super viewDidLoad];
    self.view.wantsLayer = YES;
    self.view.layer = [CAMetalLayer layer];
    // The C++ code needs access to the CAMetalLayer to call MoltenVK's vkCreateMetalSurfaceEXT function
    // Assuming there is a C++ class with ctor taking CAMetalLayer as a void* type
    _vulkanWrapper = new VulkanWrapper((__bridge void*)self.view.layer);
}

The following was my prior code closely based off the Cube demo which uses the UIKit method. If you may need to port to iOS this may (?) be useful. You can have both snippets present, they do not conflict.
-(BOOL) wantsUpdateLayer { return YES; }
+(Class) layerClass { return [CAMetalLayer class]; }
-(CALayer*) makeBackingLayer {
    CALayer* layer = [self.class.layerClass layer];
    CGSize viewScale = [self convertSizeToBacking: CGSizeMake(1.0, 1.0)];
    layer.contentsScale = MIN(viewScale.width, viewScale.height);
    return layer;
}

That's curious... The UIKit method works for Wine. We don't even bother overriding +[NSView layerClass]. We just create a CAMetalLayer directly (dlls/winemac.drv/cocoa_window.m:925):
    - (CALayer*) makeBackingLayer
    {
        CAMetalLayer *layer = [CAMetalLayer layer];
        layer.device = _device;
        layer.framebufferOnly = YES;
        layer.magnificationFilter = kCAFilterNearest;
        layer.backgroundColor = CGColorGetConstantColor(kCGColorBlack);
        layer.contentsScale = retina_on ? 2.0 : 1.0;
        return layer;
    }


unable to apply more than one filter on a column in MudDatagrid

Bug type
Component
Component name
MudDataGrid
What happened?
In MudDataGrid, if you use the simple mode of filtering and try to implement more than one filter on a column, and then try to debug it, you will notice that only one filter for the "Sign" column is visible in the DataGrid.FilterDefinitions.

Expected behavior
you should be able to apply multi filters on a column
Reproduction link
https://try.mudblazor.com/snippet/GaceuQwleOnWjMnA
Reproduction steps
i was trying to  server side filtering . i noticed when i was passing the filters to API
Relevant log output
..

Version (bug)
6.15.0
Version (working)
No response
What browsers are you seeing the problem on?
Chrome, Microsoft Edge
On what operating system are you experiencing the issue?
Windows, Android
Pull Request

[ ] I would like to do a Pull Request

Code of Conduct

[X] I agree to follow this project's Code of Conduct

I have tried with "Position" and so far I see that both filters are working together

Obviously if you use it with contains on a string like in your example with "B" and "Bi" that only "Bi" will show because the logic is not "B" or "Bi", it's "B" **and" Bi, so only string matches this two rules will be shown. If you for example change it to "S" and "i" then only elements with "Si" will shown. This demonstrates that both filters are applied because Li, Ti, Ni, Bi, S, Sc, Se, Sr, Sn, Sb, Sg are not shown. I hope you get the idea.

Correct, the issue was with the Title in version 6.15.0, which has been resolved in version 6.16.0 as a bug fix: "DataGrid: Fix FilterDefinition.Title not updating when selected field is changed by [@Saman-00]"


Double-Take not creating Sensor for trained PICs[BUG]

Describe the bug
Successfully trained several pictures to names, but the names are not showing up as sensors (sensor.double_take_myname).
Expected behavior
HA displays the names I have selected to train as sensors.
Screenshots
If applicable, add screenshots to help explain your problem.
Hardware

OS: Debian 11
Browser: Brave

Additional context
I have the unknown, front door, driveway, and update sensors, but not the sensors with the persons name.  Otherwise, everything else is working perfectly.

The sensors are based on MQTT so they won't be created until doubletake sends a match for that topic, once there is a match it will be created. This is the expected behavior.

Thanks
On Wed, Aug 10, 2022 at 8:45 AM Nicolas Mowen @.***>
wrote:

The sensors are based on MQTT so they won't be created until doubletake
sends a match for that topic, once there is a match it will be created.
This is the expected behavior.
—
Reply to this email directly, view it on GitHub
https://github.com/jakowenko/double-take/issues/233#issuecomment-1210623893,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFZ7S2MAO5QHJCKHJ7YEVULVYOP6PANCNFSM56BM7HXA
.
You are receiving this because you authored the thread.Message ID:
@.***>


enhance: support recursive_parameter_enabled in connector

Description
When using LLM in ml-commons connector, the prompt may contains substring like ${parameters.xxxx} . The PRs adds a parameter named recursive_parameter_enabled to enable users to configure whether to recursively replace the parameter in payload.
Here are an example to show why skipping parameter validation won't work. Suppose that the current parameter map is {"prompt": "You are a ${parameters.role}", "role": "bot"} the payload creation is ambiguous.
The user might also wish to send the  You are a ${parameters.role} to the remote model. If we simply skip parameter validation, there would be no way for user to control the behavior.
We thus need a parameter recursive_parameter_enabled for users to configure the behavior of filling in parameters. The user can specify this parameter in the following manner:
POST /_plugins/_ml/connectors/_create
{
  "name": "BedRock test connector",
  "description": "The connector to BedRock service for claude model",
  "version": 1,
  "protocol": "aws_sigv4",
  "parameters": {
      "region": "us-east-1",
      "service_name": "bedrock",
      "anthropic_version": "bedrock-2023-05-31",
      "endpoint": "bedrock-runtime.us-east-1.amazonaws.com",
      "auth": "Sig_V4",
      "content_type": "application/json",
      "max_tokens_to_sample": 8000,
      "temperature": 0.00001,
      "recursive_parameter_enabled": true
  },
  "credential": {
    "access_key": "xxxx",
    "secret_key": "xxxx"
  },
  "actions": [
    {
      "action_type": "predict",
      "method": "POST",
      "url": "https://bedrock-runtime.us-east-1.amazonaws.com/model/anthropic.claude-instant-v1/invoke",
      "headers": {
        "content-type": "application/json",
        "x-amz-content-sha256": "required"
      },
      "request_body": "{\"prompt\":\"${parameters.prompt}\", \"max_tokens_to_sample\":${parameters.max_tokens_to_sample}, \"temperature\":${parameters.temperature},  \"anthropic_version\":\"${parameters.anthropic_version}\" }"
    }
  ]
}

Issues Resolved
Resolve https://github.com/opensearch-project/ml-commons/issues/2712
Check List

[x] New functionality includes testing.

[ ] All tests pass

[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Please hold on this PR for a while. We are looking for a better solution

Reimplemented this PR with idea from RFC: https://github.com/opensearch-project/ml-commons/issues/2748

This PR still needs more discussion. I can fix UT later.

Can we add backport 2.x?

This PR is ready for review.

Any IT to cover this?

This PR already has an UT file to cover when RECURSIVE_PARAMETER_ENABLED is false, true or missing. What do you expect to test from the IT?

Any IT to cover this?

This PR already has an UT file to cover when RECURSIVE_PARAMETER_ENABLED is false, true or missing. What do you expect to test from the IT?

I was expecting when the parameter is set to true/false/missing, the http response are as expected.

Any IT to cover this?

This PR already has an UT file to cover when RECURSIVE_PARAMETER_ENABLED is false, true or missing. What do you expect to test from the IT?

I was expecting when the parameter is set to true/false/missing, the http response are as expected.

IT added in RestMLRemoteInferenceIT.java. Please help review, thanks!

Closing this PR as I have implemented a new solution in https://github.com/opensearch-project/ml-commons/pull/2812


Bump OpenTelemetry to 1.0-rc

plug_cowboy has replaced their own calls to telemetry with cowboy_telemetry library, so I've decided to use IMHO more flexible Plug.Telemetry

Resoled by #12


Use a single atlas for multiple font effects

Currently to use multiple font effects you have to create multiple font systems (i cant find a way without doing it at least)
This would use much less vram as you need less texture atlases
Haiving Effect and effectparameters on the Font.DrawText call would be the most logical place to put them so you can use multiple effects on a single font system

Nice idea. Probably rich text syntax could be also updated with the new command '/e' that would turn on an effect.


Azure resource group not being deleted despite destroyResourcesOnDeletion set to true

I'm having an issue with an Azure resource group not being deleted despite having the destroyResourcesOnDeletion setting set to true.
Here are some relevant logs from when the Terraform controller responsible for destroying the resource group was running:

When I check in Azure, I see that the resource group is still there and has not been deleted, even though the documentation for the tf-controller states that it should be deleted. Can anyone help me understand what might be causing this issue? Has anyone else experienced a similar problem?
p.s.  this also happen with other Terrafom resources and to put you in the picture i have a teraform for creating k8s secrets that depends on another for creating an acr repository which also depends on the creation of a third responsible for creating the resource group apparent in this exemple.

Hi @studyVersion
It's a known problem when the resource deletion process was too complex, for example, the TF object itself or the referenced source disappeared before the deletion process finished.
We're re-designing a new deletion workflow to fix this problem.

Thank you for your prompt reply. I greatly appreciate it. I will make an effort to address the issue with a workaround. I am eagerly looking forward to having it resolved.

@LappleApple to follow up on complexity and other details


Feature/MPAS_init_coldstart

With this PR, a new functionality is added to the MPAS-Workflow to generate cold start initial conditions using mpas_init. At this moment, pre-ungribed GFS analysis are used (in a following PR that step is part of the workflow).
Changes:

A new folder is created in which the pre-ungribed GFS analysis is linked and the mpas_init is executed (this can be changed in the future as needed). For that, changes were needed in the scripts config/filestructure.csh, getCycleVars.csh and config/filestructure.csh;
The GenerateColdStartIC.csh script that manages the generation of the cold initial conditions was created and added to the workflow parts in SetupWorkflow.csh and the drive.csh accordingly;
The corresponding namelist.init_atmosphere and streams.init_atmosphere were added and adjusted.

Closes https://github.com/NCAR/MPAS-Workflow/issues/52

As we only expect this PR to affect ColdStart workflows, do you mind adding a description in the PR message of cold-start tests that you have exercised?

Sure! I forgot to include that in the PR comment. Thanks for reminding me!

Sure! I forgot to include that in the PR comment. Thanks for reminding me!

Added a Test section in the PR comment.


Fix local host serve when pointing to production sim

This fixes local serve in arcade when using the production simulator. It was a regression accidentally caused by #7720
If the simulator is missing, our CLI redirects requests to the production simulator which ends up changing the domain of the iframe. Because the origin changes with the redirect, the messages we send with postMessage never reach the content window.
This fixes that by sending to both domains when on localhost. Should be harmless since one of the messages will just always be ignored. I don't love how I got access to the target id (apptarget isn't usually visible in pxsim), but piping everything from the webapp for local serve seemed messy.
This really only effects arcade

Oops. Do we have support to force using the production simulator?

@pelikhan not that I'm aware, but we totally should! This was a pain to test


more secure passwords

is there a way to make you password field require the new user have numbers, caps, lowercase, and special characters in their passwords?

Yes, there is. However, I won’t be accepting the PRs at the moment because
the repo must be synonymous with the code in the video.
On Tue, Jul 4, 2023 at 12:20 PM medducea @.***> wrote:

is there a way to make you password field require the new user have
numbers, caps, lowercase, and special characters in their passwords?
—
Reply to this email directly, view it on GitHub
https://github.com/arpanneupane19/Python-Flask-Authentication-Tutorial/issues/9,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AOPJM7X3AXCFYAVFF2MXPNLXORGGXANCNFSM6AAAAAAZ57RLJA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***
com>

--
Arpan Neupane

Okay thank you
On Tue, Jul 4, 2023 at 10:47 Arpan Neupane @.***> wrote:

Yes, there is. However, I won’t be accepting the PRs at the moment because
the repo must be synonymous with the code in the video.
On Tue, Jul 4, 2023 at 12:20 PM medducea @.***> wrote:

is there a way to make you password field require the new user have
numbers, caps, lowercase, and special characters in their passwords?
—
Reply to this email directly, view it on GitHub
<
https://github.com/arpanneupane19/Python-Flask-Authentication-Tutorial/issues/9>,

or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/AOPJM7X3AXCFYAVFF2MXPNLXORGGXANCNFSM6AAAAAAZ57RLJA>

.
You are receiving this because you are subscribed to this thread.Message
ID: @.***
com>

--
Arpan Neupane
—
Reply to this email directly, view it on GitHub
https://github.com/arpanneupane19/Python-Flask-Authentication-Tutorial/issues/9#issuecomment-1620578691,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BA76KCTAMZ26CYYGS2SNRH3XORJKPANCNFSM6AAAAAAZ57RLJA
.
You are receiving this because you authored the thread.Message ID:
<arpanneupane19/Python-Flask-Authentication-Tutorial/issues/9/1620578691@
github.com>

You can use RegEx within the input field in the HTML to add requirements
for numbers, special characters, etc.
On Tue, Jul 4, 2023 at 12:48 PM medducea @.***> wrote:

Okay thank you
On Tue, Jul 4, 2023 at 10:47 Arpan Neupane @.***> wrote:

Yes, there is. However, I won’t be accepting the PRs at the moment
because
the repo must be synonymous with the code in the video.
On Tue, Jul 4, 2023 at 12:20 PM medducea @.***> wrote:

is there a way to make you password field require the new user have
numbers, caps, lowercase, and special characters in their passwords?
—
Reply to this email directly, view it on GitHub
<

https://github.com/arpanneupane19/Python-Flask-Authentication-Tutorial/issues/9>,

or unsubscribe
<

https://github.com/notifications/unsubscribe-auth/AOPJM7X3AXCFYAVFF2MXPNLXORGGXANCNFSM6AAAAAAZ57RLJA>

.
You are receiving this because you are subscribed to this
thread.Message
ID: @.***
com>

--
Arpan Neupane
—
Reply to this email directly, view it on GitHub
<
https://github.com/arpanneupane19/Python-Flask-Authentication-Tutorial/issues/9#issuecomment-1620578691>,

or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/BA76KCTAMZ26CYYGS2SNRH3XORJKPANCNFSM6AAAAAAZ57RLJA>

.
You are receiving this because you authored the thread.Message ID:
<arpanneupane19/Python-Flask-Authentication-Tutorial/issues/9/1620578691@
github.com>

—
Reply to this email directly, view it on GitHub
https://github.com/arpanneupane19/Python-Flask-Authentication-Tutorial/issues/9#issuecomment-1620579463,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AOPJM7UJBTC4WQOERCK6SS3XORJOPANCNFSM6AAAAAAZ57RLJA
.
You are receiving this because you commented.Message ID:
<arpanneupane19/Python-Flask-Authentication-Tutorial/issues/9/1620579463@
github.com>

--
Arpan Neupane


Standardize on / for paths in settings

Testing https://github.com/microsoft/vscode/issues/158835
I see this is the value that is filled in by the extension on Windows:
"livePreview.defaultPreviewPath": "c:\\Github\\microsoft\\vscode\\test\\leaks\\index.html"

Typically for cross-platform paths we use / as the separator as it looks much nicer and is more portable (\ on unix is not a path separator), with https://github.com/microsoft/vscode-livepreview/issues/274 this would look like:
"livePreview.defaultPreviewPath": "test/leaks/index.html"

verif steps:

Use Live Preview prerelease
Right-click an html file in the explorer and click "open automatically on server start"

Check the path in livePreview.defaultPreviewPath. Should use / delimeters.


Changing device description of an OTAA device, system returns to pre-join state for device

This is a bug report for the Console

When changing the device description of an OTAA device, the system returns to the pre-join state for that OTAA device. As a result:

The device's DevAddr and App Session keys are no longer valid, thus the device must be manually instructed to re-join.

This was discovered by @terrillmoore and I tonight at the Heat Seek meetup as we work to set them up to pilot with TTN.
Thanks!
Forrest
Please tag Terry Moore in all correspondence.

Confirmed

Fixed in console repository. Will be deployed to production soon.

Deployed to production. Fix confirmed.

Thanks for the prompt response, all! Much appreciated!

Yes, thanks again, appreciate it! :+1:


Fe: add /accounts

Should go directly to your account page.

This got added in, closing issue

Woops I misread the title ignoring the /


Crashing with Physics Mod cloth physics

Game crashes when using CPM models and Physics Mod with cloth physics for cape turned on.

latest.log

Was fixed by Physics Mod in haubna/PhysicsMod#435


Fix module registration.

Fix module registration by forwarding the registration call from C to Rust. Apparently this is needed on Windows i686. See discussion here: #91
This closes #75.

Worth noting that the extendr_module! macro works pretty well now.

Ah. I'm a bit behind the times. There is a naming issue with the DLL on windows that you are fixing.

Yes, correct. On Windows the linker strips all symbols from the generated library unless there's a function called R_init_<pkgname>() in the C file. This PR fixes this problem.


Differentiate log level depending on "response.status"

https://github.com/movio/bramble/pull/179
Currently, all requests are being logged as Info (v1.4.3/instrumentation.go:56) and it really results in lots and lots of logs, hence increases costs for our applications.
As per our application's requirements, we don't want to see logs for HTTP200 responses.
What we would like to achieve is to log depending on the response.status value like below.
However, if you come up with a better idea, we are welcome to use it.
func (e *event) finish() {
	e.writeLock.Do(func() {

		var logEntry = log.WithFields(log.Fields{
			"timestamp": e.timestamp.Format(time.RFC3339Nano),
			"duration":  time.Since(e.timestamp).String(),
		}).WithFields(log.Fields(e.fields))

		responseStatusCandidate := e.fields["response.status"]

		if responseStatusCandidate == nil{
			logEntry.Info(e.name)
			return
		}

		responseStatusCode, ok := responseStatusCandidate.(int)

		if !ok{
			logEntry.Info(e.name)
			return
		}

		if (responseStatusCode >= 100 && responseStatusCode <= 199){
			// informational responses
			logEntry.Debug(e.name)
		} else if (responseStatusCode >= 200 && responseStatusCode <= 299){
			// successful responses
			logEntry.Debug(e.name)
		} else if (responseStatusCode >= 300 && responseStatusCode <= 399){
			// redirection messages
			logEntry.Debug(e.name)
		} else if (responseStatusCode >= 400 && responseStatusCode <= 499){
			// client error responses
			logEntry.Error(e.name)
		} else if (responseStatusCode >= 500 && responseStatusCode <= 599){
			// server error responses
			logEntry.Error(e.name)
		} else {
			logEntry.Info(e.name)
		}
	})
}

We would be super happy to receive feedback about this one because this is really important for us.

Hi @anar-khalilov, thanks for your PR.
I can understand your need to not log all downstream requests, we'll have to consider a general solution rather than one that just fits your use case though.
Are you ok running a fork for now while we consider this?
Things to consider:

Should this be configurable
Log levels, error should be for gateway errors, not downstream responses, so perhaps warning makes more sense
We could make the instrumentation middleware customisable

Thanks for comprehensive response. We are currently unable to run a fork due to corporate policies. Because of that we are wondering if this issue has been planned/started etc.

Hi @anar-khalilov, it's not on our roadmap yet. If you are unable to run a fork, are you able to put a filter in your log collection that drops the unneeded records?


Increase dust limit to 6000

it seems the default dust limit is 600 (https://github.com/haw-itn/openassets-ruby/blob/master/lib/openassets/api.rb#L20)
Afaik the bitcoind dust limit is higher and also coinprism uses 6000.
I recommend raising the default to 6000. If you agree I'd make a pull request. :)

Afaik the bitcoind dust limit is higher and also coinprism uses 6000.

@bumi
In coinprism, dust limit is 600. I was confirmed in the following transaction.
{
    "hex" : "0100000001fbf006d14c440028e9f30a448e6b7affe905bc40f5a91b79cc2b0e9b3b81effd000000006a47304402204583824baea8690c1808111bd9fc900d57d2bac08faf0fe876aafd072b2c7d6702207d5838ef56a145eac1c12941888ee92056e328af0ce6b762d30bdcd095e1878c0121027d0a3936d61960a32ce5644c2b5a2e4095370c1b290f317089a9f5b5ac54100fffffffff0358020000000000001976a914eee8edbf48e3cbe8a079a63bf4e7c9ab5239694c88ac0000000000000000256a234f4101000188271b753d68747470733a2f2f6370722e736d2f766d77565867666d6f66385d0100000000001976a914eee8edbf48e3cbe8a079a63bf4e7c9ab5239694c88ac00000000",
    "txid" : "293731d26e3559b737f93446a8d3fe4747b23b0302e3ee1ae6043b337e21ad5a",
    "version" : 1,
    "locktime" : 0,
    "vin" : [
        {
            "txid" : "fdef813b9b0e2bcc791ba9f540bc05e9ff7a6b8e440af3e92800444cd106f0fb",
            "vout" : 0,
            "scriptSig" : {
                "asm" : "304402204583824baea8690c1808111bd9fc900d57d2bac08faf0fe876aafd072b2c7d6702207d5838ef56a145eac1c12941888ee92056e328af0ce6b762d30bdcd095e1878c01 027d0a3936d61960a32ce5644c2b5a2e4095370c1b290f317089a9f5b5ac54100f",
                "hex" : "47304402204583824baea8690c1808111bd9fc900d57d2bac08faf0fe876aafd072b2c7d6702207d5838ef56a145eac1c12941888ee92056e328af0ce6b762d30bdcd095e1878c0121027d0a3936d61960a32ce5644c2b5a2e4095370c1b290f317089a9f5b5ac54100f"
            },
            "sequence" :<PHONE_NUMBER>
        }
    ],
    "vout" : [
        {
            "value" : 0.00000600,
            "n" : 0,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 eee8edbf48e3cbe8a079a63bf4e7c9ab5239694c OP_EQUALVERIFY OP_CHECKSIG",
                "hex" : "76a914eee8edbf48e3cbe8a079a63bf4e7c9ab5239694c88ac",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "1NnErpsoEa54DUcMRKQPFtjxd2DZwNaB1t"
                ]
            }
        },
        {
            "value" : 0.00000000,
            "n" : 1,
            "scriptPubKey" : {
                "asm" : "OP_RETURN 4f4101000188271b753d68747470733a2f2f6370722e736d2f766d77565867666d6f66",
                "hex" : "6a234f4101000188271b753d68747470733a2f2f6370722e736d2f766d77565867666d6f66",
                "type" : "nulldata"
            }
        },
        {
            "value" : 0.00089400,
            "n" : 2,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 eee8edbf48e3cbe8a079a63bf4e7c9ab5239694c OP_EQUALVERIFY OP_CHECKSIG",
                "hex" : "76a914eee8edbf48e3cbe8a079a63bf4e7c9ab5239694c88ac",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "1NnErpsoEa54DUcMRKQPFtjxd2DZwNaB1t"
                ]
            }
        }
    ],
    "blockhash" : "0000000000000000059ddd29c9d3be67e0fb57640b546dd636802198a29fc544",
    "confirmations" : 5,
    "time" :<PHONE_NUMBER>,
    "blocktime" :<PHONE_NUMBER>
}

ohh, sorry. damn, I think I got confused. bitcoind has a minRelayTxFee of 1000 by default, or am I wrong about that also?

maybe we should add a comment in the readme. because it won't work with the default values of bitcoin-core and openassets-ruby.

tx fee is defined by default_fees (default: 10000), and its can be changed at the time of the api call (as fee variable). so it might even problem?
Since default_fees of description was missing, it adds it to the readme.

these are two different values, isn't it?
I think the default bitcoind dust limit is 5000. (https://github.com/bitcoin/bitcoin/blob/34f200d1404dcb93d45f43e249048f4b6eed0197/doc/release-notes/release-notes-0.11.1.md#minimum-relay-fee-default-increase)
So if you are connecting openassets-ruby to a newly installed, default bitcoind the transactions won't work because of the dust limit.

sorry, replay late.
Bitcoin's dust limit (minRelayTxFee) is 5000 in version 0.11.0.
It is transaction fee, isn't it?
So, transaction fees in openassets-ruby has been set as default_fees.
The default default_fees is 10000, so I think that there is no problem because the greater than 5000.
I upgrade Bitcoin Core to 0.11.2, and I was abled to send transaction.


Missing changelog for 6.5.3

Bug Report
Current Behavior
Ran a yarn upgrade on my project and it got 6.5.3, however the changelog.md file on this github repo shows only upto 6.5.2
Reproduction
Just do a yarn add rxjs and it will download 6.5.3
Expected behavior
Missing update on changelog.md I guess....
Environment

Runtime: [e.g. Node v8.16.0, yarn v1.16.0]
RxJS version: 6.5.3
(If bug is related) Loader, build configuration: [e.g webpack, angular-cli version, config]

Possible Solution
N/A
Additional context/Screenshots
warning package.json: No license field
[1/4] Resolving packages...
[2/4] Fetching packages...
info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
warning "laravel-mix ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>|| ^6.0.0".
warning " ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>|| ^3.0.0 || ^4.0.0".
[4/4] Building fresh packages...

success Saved lockfile.
success Saved 2 new dependencies.
info Direct dependencies
└─<EMAIL_ADDRESS>info All dependencies
├─<EMAIL_ADDRESS>└─<EMAIL_ADDRESS>Done in 15.09s.

Missing tag and release as well.

Any news on this? We will not upgrade until a changelog entry is released, or at least this issue is acknowledged by a maintainer!

@benlesh ?

Fixed. I just didn't push up the changes to the changelog.


LSF Dask Workarounds now tested and working properly

Description
The untested Dask + LSF unit fixes had a few bugs in them, this corrects that and makes them more robust to other patterns in the lsf.conf file (i.e. comments)
cc @ChayaSt as this will fix the LSF issues you were seeing.
Status

[x] Changelog updated
[x] Ready to go

I've also proposed an upstream fix so we can hopefully remove the monkey-patching at some point.
dask/dask-jobqueue#274

I think this is ready, between @ChayaSt and my's debugging, I think this is working as intended now.


Bugfix/use write head instead of implicit header

updated PR with rebase from express/compress:master to handle #128

Just wanted to note on here it looks like just a rebase, without addressing the review comments yet. I presume that will come in follow up commits?

Just wanted to note on here it looks like just a rebase, without addressing the review comments yet. I presume that will come in follow up commits?

Yes, working on that now.

@dougwilson I found all the comments I think needed to be fixed, except 2 perhaps that I'll work on tonight.

the on('data') callback which I think doesn't need a data check; per the noop it's just a way to prevent hangs
the comments from @sogaani regarding the response code. I'll look at that as well.

@dougwilson Is there anything more you see for this PR to have?
@sogaani with regards to your comment on the error status code; it seems to be a big edge case. I work on a very large API and haven't encountered this issue before.

I was under the impression you were going to make changes in regards to the two bullet points above, which is what I'm waiting on. I never saw any additional comments after that message. Are you still working on them?

Eh! Sorry; I did leave the on('data') callback as is in the test, but I removed all the logs and I believe covered everything you had commented on in the previous test.
For the second bullet point I quite literally have no clue off the top of my head how to even cover that in an edge case test.

Seems like this one got stuck right?

For the clarity that #129 is not in this PR, the PR description should be changed to:

updated PR with rebase from express/compress:master to handle #128 and #129

@Icehunter, you might want to correct the indentations at line 740-744 and line 747-753.
I didn't include them previously so that https://github.com/expressjs/compression/pull/170/commits/38fe9fd5756f524e438c9abb9e91e7193921e0e3 is surgical.
https://github.com/expressjs/compression/blob/38fe9fd5756f524e438c9abb9e91e7193921e0e3/test/compression.js#L737-L756

@Icehunter, for the clarity that #129 is not in this PR, the description should change:

updated PR with rebase from express/compress:master to handle #128 and #129

@Icehunter, for the clarity that #129 is not in this PR, the description should change:

updated PR with rebase from express/compress:master to handle #128 ~and #129~

Updated and rebased again :)

@dougwilson When you are free, can you review this PR?

@dougwilson When you are free, can you review this PR?
Fixes #122 and supersedes #128.
Many thanks! 🤗
I didn't have access in the forked repository to run the GH actions. So I forked the PR.
I ran the GH actions on my own repository and here is the result for the latest commit (4c1d27b):
https://github.com/lamweili/compression/actions

@dougwilson, have you got the time to take a look at this PR?

@dougwilson, have you got the time to take a look at this PR?

@dougwilson, have you got the time to take a look at this PR?

sorry @Icehunter, Can you fix the code style?

sorry @Icehunter, Can you fix the code style?

Sure thing.

Dropping some context from slack re: this PR

The original issue here is compression relying on node http internals since the days of connect in 2011
Here's when the commit w/ _implicitHeader originally landed:
https://github.com/senchalabs/connect/commit/715e4f56f8e4ad75baa35a7ae049bd69ca8bf6c6
http2 module has a different API and internals than http1 in node. So that method doesn't exist at all in http2, throwing when used.
Compression module doesn't support http2 explicitly. It likely can, but was never intended to.
writeHead has been around since that first commit, but for reasons lost to time wasn't used

Idk that I can say that issue #122 "supporting http2" is closed after landing #170, because I personally haven't reviewed the code or tested for http2 edgecases.
However, removing an http internal to replace w/ a public interface which is equivalent is 💯

This history is long w/ 19 commits, @bjohansebas when/if you merge I'd suggest squashing via the dropdown to keep the history clean


Entities not viewable

Hi Patrik, thank you for your work. Just have a question regarding the entities. Some of them are not available. Is this because of the satus of the EV Charger.

E.g Power is not available but Current.
Would the htpp version for the inverters also possible?
Thank You
Wolfgang

And there even is an existing integration using the WiFi dongle connection instead of Modbus RTU.

Thanks will test it.
@PatrikTrestik How can I make the entities visible/ usable
Have test switching the modes (Eco, Stop, etc) works very good and a very fast response time.

Thanks will test it. @PatrikTrestik How can I make the entities visible/ usable
Have test switching the modes (Eco, Stop, etc) works very good and a very fast response time.

Standard HA, go to entities list and enable what you want .

Sorry, new to HA. Works all very good. Thank You.
Issue is closed in my opinion.


Update recommendingProbability

Take the values of predictedSolveProbability to define recommendingProbability.
I have tested with a few accounts and it didn't change for most of them (except mine), because the problem only happens when all predictedSolveProbability of remaining problems is less than 0.2.
This doesn't solve completely the problem, since the user can have all the probability close to the same value.
Solves #267

Codecov Report

Merging #269 into master will decrease coverage by 0.06%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master     #269      +/-   ##
==========================================
- Coverage   23.72%   23.65%   -0.07%
==========================================
  Files          66       66
  Lines        1766     1771       +5
  Branches      238      239       +1
==========================================
  Hits          419      419
- Misses       1277     1282       +5
  Partials       70       70

Impacted Files
Coverage Δ

...ms-frontend/src/pages/UserPage/Recommendations.tsx
0% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

Thanks! It looks almost perfect to me, but I found a bug. The number of the problems when I chose All is fewer than 100.

It looks good to me.


[Serialization] Fix reporting dependency cycle with a missing clang module

Fix a segfault when diagnosing a dependency cycle involving a
missing clang module.
rdar://problem/57364033

@swift-ci Please smoke test


Model deployment

Hi, do you plan to support model deployment like in mmcls any time soon?

Hi, currently the model deployment is not in the plan.

any general guidelines/tips that you could give?

You may be interested in the mmcls docs  or mmdet docs about model deployment.


compact array of props

I've reduced original issue #3 to only compact properties, not values for now.
The reason is compacting values require own strategy for each value and this is the case for separate module which I've started with border-radius values.
https://github.com/tyv/compact-css-values/blob/master/src/border-radius.js
Also I removed value tests in favor of the compact-css-values lib.

so the idea is compact will use that lib when it is done.
you can mark this PR as [WIP] until that or merge it, because it only adds functionality.


Handle margin around undistorted images

So that the user can select what he wants:

see an image which is 100% filled by the undistorted image
see 100% of the original image (even though it makes appear some black borders)
select the margin (positive or negative) around the image

Included in release 0.3


[WIP] Refactor how the events are captured and stored

Q
A

Branch?
2.0

Bug fix?
no

New feature?
yes

BC breaks?
yes

Deprecations?
no

Tests pass?
no

License
MIT

This PR introduces an object-oriented approach for the storage of events. Before the events were stored as plain arrays of data which were frequently passed through functions. As all know PHP arrays are passed by variable while instead objects are passed by reference, so there should be improvements in term of performance. Does it makes sense to make the Event class immutable (like the PSR-7 Request class?
This PR is a work in progress and is not ready for merge

There shouldn't be a use case for modifying events after their creation, so :+1: for immutable events, since they are being passed around by reference now and we should avoid any "spooky action from distance".

According to the official SDK reference what is not an attribute of the event is assumed to be an interface. I was thinking to split make the event composable: a set of data collectors should collect the data (e.g. the stacktrace or the user information) and then somehow the resulting data should be added to the event. What do you think about this?

I like the idea of splitted interfaces that follows the official SDK. I just hope that those are not too much work for no benefit!!
For me is 👍 but I would like to ear from @stayallive too, because I'm not sure that we can use a read-only-value-object approach with all of those stuff.

Well I'm not sure if we would benefit from making it immutable since an event is mostly only handled by the Client and we might shoot ourselfs int he foot making it immutable (if we later want to introduce middleware for example) to make it easier for 3rd parties to modify the event being sent or scrub some extra data or something, or am I thinking in the wrong direction here?
I do like the idea of splitting the event in components that can be composed to an event however this sounds very complex, how would you see an event being built (in pseudocode)?

https://github.com/ramsey/uuid/blob/f44f53e5ceb7474a83b6e11e6623ff9d6f6da598/src/Generator/RandomBytesGenerator.php#L34
http://php.net/manual/en/function.random-bytes.php

random_bytes — Generates cryptographically secure pseudo-random bytes

That's good

I've re-read the code, and I'm now inclined against an immutable object: everywhere we do a $event = $event->withSomething();, which is easy to miss and create issues. We cannot leverage the advantage of immutability here, since the event is created, filled and the immediately sent or stored to be sent; it's no longer juggled around.
Therefore, I'm :+1: for avoiding complexity and go forward with this without immutability. @ste93cry do you want help with this?

since the event is created, filled and the immediately sent or stored to be sent; it's no longer juggled around.

This is not entirely true, as the event is supposed to be passed to the processors which can edit the data it contains. Also, an immutable event would prevent any modification of itself after it reached the Httplug client that could create bugs or strange things difficult to track.

do you want help with this?

The main problem with this PR is how to collect things for the SDK data interfaces. I was thinking about creating a sort of system that works with the middleware pattern so that the event can be composed and then the processors are called on top of the built object. This would allow third parties to hook into the process at any time. Does it makes sense?

For me it make sense, but you would be forced to create a generic ->with($name, $value) method, since the current implementation has freedom to use any string as a sub-category/tag for the event.

https://github.com/getsentry/sentry-php/blob/dcc287f6579b765c7935e0e60fa642ae029b834f/lib/Raven/Client.php#L363-L365
The following check can be found in the Client::captureException method. An exception can have multiple previous exceptions, shouldn't this check be repeated for each one instead of the first only?

The following check can be found in the Client::captureException method. An exception can have multiple previous exceptions, shouldn't this check be repeated for each one instead of the first only?

I don't know, but this would be a change in the behavior of the lib; I think we should be coherent with all the others Sentry implementantions, and we should change this only if the others are doing it like that.

I understood the meaning of this pull request only now. I approve changing of storing internal data from plain array to structured objects.
https://github.com/nokitakaze/php-mutex/blob/master/src/phpdoc.php
https://github.com/nokitakaze/php-keyvalue/blob/master/src/phpdoc.php
https://github.com/nokitakaze/php-queue/blob/master/src/phpdoc.php
This is how structured data (like Sentry events) should be stored. It helps to understand the meaning of every field in event datum, makes highlights in code (in IDE) and allows to find incorrect using of fields (i.e. using integer field as string argument in some method).

I think we should be coherent with all the others Sentry implementantions,

I had a look at the other SDKs, and the most common like Javascript or Ruby does not have anything similar to the "previous exception" concept of PHP. Instead, the Python SDK behaves a bit different: the excluded_exceptions option accepts strings or classes. In the first case the string is matched strictly against the name of the exception class, in the second case the exception object instance is matched against each item of the list using issubclass so that you don't have to explicitly configure all exceptions classes if they all share the same common parent. As there doesn't seems to be a shared behaviour between integrations regarding how an exception is excluded, I think my proposal to apply the filter of excluded exceptions to the nested exceptions is valid

Ok, good investigation. Please list it as a BC in the migration document then.

Does it makes sense to log the session_id() in the user collector? According to the SDK reference of the User interface:

You should provide at least either an id (a unique identifier for an authenticated user) or ip_address (their IP address).

I don't think the session ID is a valuable information (not that the IP address is more valuable anyway imho). If users want to identify a user that got an error, then they should add tags or even better create their own middleware and edit the event object by attaching whatever info they want

I agree; also attaching the session ID could rise some security issues. To identify a user a specific integration with the app (or the framework) in use is needed, so it's out of scope.

I think calling session_id() should be customizable

@stayallive @dcramer What's the checksum of an event? Is it something that's still used by Sentry or not? I can't find any docs about it and the other SDKs seems to implement it differently or not implement it at all... In case it's still needed should it be configurable or it should be something pre-calculated?

@ste93cry you dont need to compute it these days. It's basically something we use to fingerprint events, and realistically at this point should be left up to the server to generate.

Does it makes sense to mainain this part of code?
https://github.com/getsentry/sentry-php/blob/dcc287f6579b765c7935e0e60fa642ae029b834f/lib/Raven/Client.php#L412-L416
Given the fact that I don't like to use the method_exists function for these sort of things but I would prefer an interface instead, the level can now be set in the $payload argument that's passed to each middleware so the same thing can be accomplished in a better way

@ste93cry getSeverity() seems to exist on the \ErrorException class only, see: http://php.net/manual/en/errorexception.getseverity.php
It doesn't seem so useful to me to create a new interface, so I would just move this piece of code in the middleware as you said, but I fear that we need to keep the method_exists; the only alternative that I see is to change it to a instanceof \ErrorException.

I didn't know the getSeverity method was part of a PHP class, I though it was something introduced by Sentry to customize the error level of the event. At this point I would change the condition to the instanceof variant as you suggested, it seems better to me as this method is marked final and is only implemented by that particular exception. If users want to override the level they can set the level option in the $payload argument and they will get the same behaviour as before (1.x)

My two cents: like the instanceof more to, just add an entry to the changelog because it's technically a BC break so it should be documented, but don't think there will be many people affected.

I noticed that the auto_log_stacks option is turned off by default, is this really a good thing? I mean, without stacktraces Sentry is just a logging platform (more or less...). Also, in 1.x the check to skip generating the stacktrace for an event being sent is applied only to the Stacktrace interface while each value of the Exception interface will always contain the whole stacktrace. I think it would be better to unify this thing by checking in both places if stacktraces should be collected or not. WDYT?

I noticed that the auto_log_stacks option is turned off by default, is this really a good thing? I mean, without stacktraces Sentry is just a logging platform (more or less...). Also, in 1.x the check to skip generating the stacktrace for an event being sent is applied only to the Stacktrace interface while each value of the Exception interface will always contain the whole stacktrace. I think it would be better to unify this thing by checking in both places if stacktraces should be collected or not. WDYT?

we should check if the separate Stacktrace interface is still needed

@dcramer I tried sending an event to Sentry without the top-level stacktrace interface set but with the stacktrace interface set for each exception interface value and it still displays the stacktrace in the event view. Can you please confirm it the first is needed anyway for some reason or if we can stop sending it? This would also reduce the size of the whole request data

Also @ste93cry please stop from adding other fixes to this PR: is already too big... please focus on closing this, and just list somewhere what you encounter, so we can fix those later together.

Everything that I've done here is strictly connected to the subject of this PR and it meant refactoring one of the core parts of this library, so it's normal that it's big 😃
A few remaining questions:

The captureQuery method captures a SQL query but the query interface is not officially documented in the SDK docs (or at least I didn't find it). Should I keep the method or not?
in the middlewares I'm using a PSR-7 object to represent the request object, however Httplug works only for clients and so doesn't provide any method to discover or create instances of the Psr\Http\Message\ServerRequestInterface. I'm actually using Zend Diactorosy to internally create the object and pass it to the middlewares, but maybe we should provide a factory so that the implementation is left to the user? Requiring a library explicitly will defeat the purpose of the autodiscovery feature of Httplug

For the captureQuery we should ask to someone on the Sentry side... For the Diactoros, I agree that requiring it would defeat the autodiscovery part.

captureQuery is legacy- I wouldn’t bother supporting it

@dcramer @stayallive what about the question regarding the top-level stacktrace key of an event message?

the top level stacktrace should only be used if you're not sending an exception (because the exception already has the stacktrace coupled to it)

It's not super relevant for php here but the toplevel stacktrace property does not support some sentry processing features. In that case it makes more sense to send a threads property with a single thread that holds the stacktrace instead.

Regarding the ServerRequestInterface, I've talked to @ste93cry and ask for input elsewhere, I'm :+1: for requiring Diactoros as the factory:

it's the de-facto standard on PSR-7 (was used to develop the spec)
it's super-stable
it doesn't interfere with the freedom of the end user in the choice of the HTTP client with HTTPlug
it only depends on the PSR-7 lib, which we already required through HTTPlug.

Ok so here it's the status of this PR: I asked to review the code because it's almost done, the only thing I would like to improve a bit is the code coverage of some methods (e.g. the Client::capture method) but this can be done later with other changes. I would also ask if it makes sense to keep the Client::getLastEventID method as Client::capture already returns the same information and we could then simplify a bit the class.

I'm :+1: for removing Client::getLastEventID, since it will remove an other bit of state from the client. Anyone else can think of a reason for not dropping it?

I am not sure Client::getLastEventID should be removed, I do see why it should, but this would require any plain SDK implementers to implement their own state while it's such a minor thing to do ourselfs. And yes it is also a minor thing to do for the end user, but still I'm not sure.
For the ease of use, just 3-5 lines you can implement the lib (although I am not sure what the state on that is now...) and implementing user feedback means just asking the client for the last ID no matter from where it was called (maybe even by 3rd party components on which you have no control).
So in favor of keeping it simple for the end user (which I think should be considered over ultra-clean code in this lib) it might be a good idea to leave the Client::getLastEventID.

It's a nice reason, in fact. I could happen frequently that Sentry is not called directly but by third party integrations (the bundle, the Laravel integration...) so yeah, maybe we should leave it.

I would propose to have Client::getLastEvent but also a Client::getLastEventID (which uses Client::getLastEvent to retrieve the event and just returns the ID) for the ease of use and not breaking BC and people needing to know how to retrieve the ID from the Event object.

Ok. We deprecate it to drop in in next major, so people will migrate toward Event::getId().

Yeah we can, although I'm not bothered by it being there (if it uses the Event for getting the ID).
But if you want to deprecate it I'm not against.

I would propose to have Client::getLastEvent but also a Client::getLastEventID

My opinion about removing any getLastEvent* method was dictated by the fact that I don't think it's useful to maintain in the state of the client the last event (ID or object). The only reason I could think of an user would want to get the event is to log it somewhere but this is possible now with a custom middleware. Also, the event is just a container of information that was added to provide a better way to interact with the message and to prevent passing arrays all along which gets copied everytime by PHP: it does not know if it was sent, it's being sent, failed to be sent or whatever else. By the way if all agree to just deprecate it and not take the chance to remove it in 2.0 I'm fine with it

getLastEventID (or getLastEvent, but thats less useful) needs to stay. This is used for things like User Feedback.
In general, a lot of the API that exists, make an assumption that it has a good reason to exist, and I'd consider getting sign off from @getsentry/sdks before removing an actual feature.

In general, a lot of the API that exists, make an assumption that it has a good reason to exist

Sorry if my message seemed to be rude, it was not my intention. I like to simplify things the most I can and I didn't know the getLastEventID method was useful for the User Feedback feature. I still think now that we have the middleware pattern we should point users to use that instead of relying on the client maintaining its own state, but it's fine if everyone agrees as I said before. I'm going to fix the remaining things, if anyone wants to add more comments to the review before this PR gets merged this is the good time

I've been refactoring the python SDK and implementing a prototype roughly based on this gist. Some features like an interface for internal SDK errors have only been shortly discussed. Axing the equivalent of getLastEventID is also planned once the integrations don't depend on it.

Ok so:

getLastEvent(): Event should be added
we deprecate getLastEventId() in favor of getLastEvent()->getId()
we will always have an endpoint that will allow the end user to retrieve the last event in some form (that is required to Python too, @ashwoods!)

It seems a good plan to me :+1:

we deprecate getLastEventId() in favor of getLastEvent()->getId()

should I trigger a deprecated notice in the getLastEventId() method?

Since I suggested it, I'm obviously :+1: for it. That will mean that it will not be dropped until next major, so I don't think others will oppose it.


Use rand 0.8 again

#1525 accidentally moved back to rand 0.7

This is likely deliberate. There was quite a bit of discussion on this on Discord, but the core issue is:

For most random number generation needs, people grab the rand crate. For this to work on WASM, upstream (for reasons I don't understand) ditched their WASM feature flag and now expect you to override their dependency manually and toggle the feature flag yourself:
rand = "0.8"
getrandom = {version="0.2", features=["js"]}
Except in the case of Bevy this doesn't actually work because bevy_ecs depends on rand 0.7 which depends on getrandom 0.1. > So people get a thread_rng or similar panic in the browser and are none the wiser despite following upstream instructions. > Figuring this out is pretty painful. This actually does work:
rand = "0.8"
getrandom = {version="0.1", features=["wasm-bindgen"]}
The reason I ask this in this channel is because perhaps there is an alternative path to take with bevy_ecs dependency on rand on which people could comment, instead of arguing with rand's upstream.

This was actually unintentional. The issue was the 0.7/0.8 combination. As long as we are consistent i think we're fine. I just rand usage on this branch and it works as expected on wasm.

bors r+


"unpack requires a buffer of 4 bytes" error for EdDSA key

I have "unpack requires a buffer of 4 bytes" error when passing EdDSA key.
Need to either update code to support it (paramiko.Ed25519Key.from_private_key_file function) or at least specify in documentation that only RSA keys are supported.

same here

same

same

same


[Weight] Cleanup train argument for initialize gradient

Cleanup train argument for initialize gradient
This argument was needed when weights and gradient were initialized together
But now, the caller must call initializeGradient only when its trainable
Self evaluation:

Build test: [x]Passed [ ]Failed [ ]Skipped
Run test: [x]Passed [ ]Failed [ ]Skipped

Signed-off-by: Parichay Kapoor<EMAIL_ADDRESS>

:memo: TAOS-CI Version: 1.4.20191203. Thank you for submitting PR #890. Please a submit 1commit/1PR (one commit per one PR) policy to get comments quickly from reviewers. Your PR must pass all verificiation processes of cibot before starting a review process from reviewers. If you are new member to join this project, please read manuals in documentation folder and wiki page. In order to monitor a progress status of your PR in more detail, visit http://nnsuite.mooo.com/.

:memo: TAOS-CI Version: 1.4.20191203. Thank you for submitting PR #890. Please a submit 1commit/1PR (one commit per one PR) policy to get comments quickly from reviewers. Your PR must pass all verificiation processes of cibot before starting a review process from reviewers. If you are new member to join this project, please read manuals in documentation folder and wiki page. In order to monitor a progress status of your PR in more detail, visit http://nnsuite.mooo.com/.


File Upload Does Not Work

protractor: 3.1.1
selenium-server: 2.52.0
robotjs: 0.3.7
chromedriver: 2.21
Win7 64 bit

I used to be able to perform the file upload using robotjs but it has stopped working recently. I am not sure whether it's due to updates on protractor or selenium server or it is the robotjs update.
It stopped working on both chrome and firefox.
My code does simple task as below:
robot.typeString(docToUpload);
robot.keyTap("enter");

I tried adding keyboard delay too with no avail
robot.setKeyboardDelay(5000);
robot.typeString(docToUpload);
robot.keyTap("enter");

Is this still being supported?

It is! Just really busy. RobotJS hasn't been updated recently, what specifically isn't working? Is the text not being typed? Or enter isn't pressed?

@octalmage Thanks for getting back!
Text is not being typed even though the focus is on the textbox in the upload window. On the other hand, if I manually change the focus to somewhere else in the middle of the test, Robot types it there.

Hi @g0rd,
Were you able to figure this out? Which OS are you on? I haven't been able to replicate any issues with typing.

I'm going to close this, please let me know if you still need help!

Hi @octalmage, I am sorry I couldn't get back to you earlier. We have abandoned using robotjs because it's still typing outside of the in-focus textbox. I have tried this both on Wiindows 8.1 and 7

No worries! I'm sorry we weren't able to get this figured out. I'm still interested in resolving this if you are. Could you provide the steps to replicate? I spent a bit typing and clicking in Chrome on Windows but I wasn't able to break it.

I will write down the detailed steps by the end of the day

uploadBtn.click().then(function () {
    browser.driver.sleep(1000);
    robot.typeString(fileToUpload);
    robot.keyTap("enter");
    browser.driver.sleep(2000);
}

Is it this kind of upload dialog?

yes. that's what it is

So, it has somehow started working:
robot.setKeyboardDelay(200);
robot.typeStringDelayed("\\", 40);
robot.typeStringDelayed("\\", 40);
robot.typeStringDelayed(fileToUpload, 100);
robot.keyTap("enter");

but it doesn't type the first letter. No matter how much delay I put in

Kind late but wanted to give my 2 cents.
The reason it does not type the first letter (assumption here) is because you are useing it in an end2end testing scenario with protractor.
It {
// does webstuff here
// open file selector
}
it {
// Robot JS here  < instantly starts - the file selector has not been opened yet.
}
Testing is done async.

@RHeijnen, Thank you!
I think this was one of those brain fart moments. I wasn't checking the promise on the browser wait after opening the file selector window.
just changed from
upload.click().then(function(){
   browser.driver.sleep(500);
   robot.typeStringDelayed(fileToUpload, 25);
   robot.keyTap("enter");
   browser.driver.sleep(2000);
})

to
upload.click().then(function(){
    browser.driver.sleep(500);
}).then(function(){
    robot.typeStringDelayed(fileToUpload, 25);
    robot.keyTap("enter");
    browser.driver.sleep(2000);
})

Thanks @RHeijnen! I know this has been an issue for many and I wasn't sure what I could do to help. I really appreciate it!


Add process type on batch

Description
Add process type on batch

References

#855

Codecov Report

Merging #1505 (09ecd71) into main (1646b59) will increase coverage by 19.03%.
The diff coverage is 85.71%.

@@             Coverage Diff             @@
##             main    #1505       +/-   ##
===========================================
+ Coverage   26.91%   45.94%   +19.03%
===========================================
  Files          60       74       +14
  Lines         977     1358      +381
  Branches       50        0       -50
===========================================
+ Hits          263      624      +361
- Misses        704      719       +15
- Partials       10       15        +5

Impacted Files
Coverage Δ

...h/source/DataHub.WebApi/GraphQL/Types/BatchType.cs
0.00% <0.00%> (ø)

...ntegration/Controllers/WholesaleControllerTests.cs
97.82% <100.00%> (ø)

...taHub.WebApi/Controllers/Wholesale/Dto/BatchDto.cs
0.00% <0.00%> (-100.00%)
:arrow_down:

...trollers/MarketParticipant/Dto/FilteredActorDto.cs
16.66% <0.00%> (-83.34%)
:arrow_down:

...gistration/HealthEndpointRegistrationExtensions.cs
45.45% <0.00%> (-36.37%)
:arrow_down:

...WebApi/RequireNonNullablePropertiesSchemaFilter.cs
80.00% <0.00%> (-8.00%)
:arrow_down:

apps/dh/api-dh/source/DataHub.WebApi/Startup.cs
91.66% <0.00%> (-0.93%)
:arrow_down:

...egration/Controllers/ChargeLinksControllerTests.cs
100.00% <0.00%> (ø)

.../Integration/Controllers/ChargesControllerTests.cs
100.00% <0.00%> (ø)

... and 12 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


feat: improve headers guideline (#769)

This pull request picks up a couple of header related tasks and left overs from previous pull request, e.g. #760, and from the rolling agenda to complete default header definition support via the guidelines:

Add general introduction on how to reference default header definitions from the guideline.
Add script to generate guideline definition of headers from provided default models to use models as a single source of truth.
Add support for Idempotency-Key, Prefer, Accept-Encoding, Content-Encoding, Sunset, and Deprecation headers.
Improve support and correct definitions of If-Match, If-None-Match, ETag , Cache-Control, and Vary headers.
Replace references to RFCs obsoleted by RFC-9110 and RFC-9111 - except of status code and error codes section.

Generally, this pull request is editorial and does not require Zally to be changed, however, it would be good to add a hint about compression as a Zally rule, since we now can identify endpoints not supporting compression.

👍

👍

👍


Explicitly setting modulePathIgnorePatterns to the default value breaks dontMock method

Steps to repo:

Create a new folder
Run npm install jquery underscore jest-cli
Run npm init and accept all defaults except setting the test command to jest
Place this following test into __tests__

describe('SomeTest', function() {
    it("requires underscore (unmocked) and jQuery (mocked)", function() {
        jest.dontMock('underscore');
        var _ = require('underscore');
        var $ = require('jquery');

        expect(_.mock).toBeUndefined();
        expect($.mock).toBeDefined();
    })
});

If you run npm test it will pass, as you'd expect.  Now edit the generated package.json to add  "jest": {"modulePathIgnorePatterns": ["/node_modules/"]}, and rerun npm test.  You'll get:
cody@possum jest-test $ npm test

><EMAIL_ADDRESS>test /Users/cody/Coding/jest-test
> jest

Found 1 matching tests...
 FAIL  __tests__/test.js (0.058s)
● SomeTest › it requires underscore (unmocked) and jQuery (mocked)
  - Expected undefined to be defined.
        at Spec.<anonymous> (/Users/cody/Coding/jest-test/__tests__/test.js:8:24)
        at Timer.listOnTimeout [as ontimeout] (timers.js:110:15)
1 tests failed, 0 tests passed (1 total)
Run time: 0.761s
npm ERR! Test failed.  See above for more details.
npm ERR! not ok code 0

In other words, setting modulePathIgnorePatterns to ["/node_modules/"] causes don'tMock() method to break mocking.  This is true despite the fact that, according to the docs this is the default pattern.
I have confirmed this on the current version of jest on NPM, as well as the current HEAD commit (dbd9eb2eb2de1d04fb9510dc653bdfc063715ead).  I have confirmed that setting modulePathIgnorePatterns to something like `["/nonsense_path/"] makes everything work.
In addition, note that the issue is that setting modulePathIgnorePatterns is causing calling dontMock() to break mocking.  These tests both pass:
describe('SomeTest', function() {
    it("requires underscore (unmocked) and jQuery (mocked)", function() {
        jest.dontMock('underscore');
        var _ = require('underscore');
        var $ = require('jquery');

        expect(_.mock).toBeUndefined();
        expect($.mock).toBeUndefined();
    })
});

Showing that calling dontMock() causes all future requires to be unmocked.  As well as:
describe('SomeTest', function() {
    it("requires underscore (unmocked) and jQuery (mocked)", function() {
        var _ = require('underscore');
        var $ = require('jquery');

        expect(_.mock).toBeDefined();
        expect($.mock).toBeDefined();
    })
});

Showing that without dontMock(), everything still works as expected.  It's the combination of setting modulePathIgnorePatterns, calling dontMock(), and then trying to require something that should be mocked that's broken.
(I originally submitted the bug as #64, which I've closed because it turns out I was completely wrong about the actual issue.)

@pselden In my experience, the bug interacts with testPathDirs as well.
testPathDirs
  A list of paths to directories that Jest should use to search for tests in.

  There are times where you only want Jest to search in a single sub-directory (such as cases where you have a src/ directory in your repo), but not the rest of the repo.

^^ That sounds like it should only affect the discovery of test files. Nope: it breaks stuff.
It's an additionally painful ergonomics issue because the two settings look like ripe targets for improving Jest's poor startup time. And yes - excluding node_modules from testPathDirs does seem to make it run faster, but you've got this latent bug where the vaunted auto-mocking goes bonkers.

Any intention on addressing this? been open for a while

Seriously how is this still open.

I did some digging,
Setting modulePathIgnorePatterns causes Loader.prototype._getNormalizedModuleID in HasteModuleLoader.js to always return "user::" as the module id. This isn't a problem until you use dontMock and add an entry in HasteModuleLoader's  this._explicitShouldMock. This entry looks like "user::": false.
When you require a module after using modulePathIgnorePatterns and using dontMock, the loader when it calls _shouldMock, always returns false because it calls _getNormalizedModuleID, which always returns "user::".
I think when using modulePathIgnorePatterns something goes wrong generating the resource map. Not sure though

Thank you for reporting this issue and appreciate your patience. We've  notified the core team for an update on this issue. We're looking for a response within the next 30 days or the issue may be closed.

This is still a problem

Not that I know of
On Sep 9, 2015 9:09 PM, "Peter Jihoon Kim"<EMAIL_ADDRESS>wrote:

This is still a problem
—
Reply to this email directly or view it on GitHub
https://github.com/facebook/jest/issues/66#issuecomment-139111112.

I'm seeing the same issue if I specify a testPathDirs ... even if it is "testPathDirs": ["__tests__"]

I have the exact same problem described by @AlcockP. Removing testPathDirs resolved the problem and everything is mocked properly.

+1 on the problem with testPathDirs. Replacing dontMock() with require.requireActual('path') seems to be a viable workaround.

This should not be an issue any more with jest 0.7+.


Support independent fixup scripts

As best practices evolve, it's easy for existing repos to fall behind. Having a command that allows you to browse suggestions or automatic fixers would make upkeep a simpler process. These shouldn't require much buy-in to the base skuba templates either as we know that teams will deviate.
A reasonable starting point would be the existing monolithic skuba configure command. Breaking that command up into multiple separate submodules that would make initial configuration a lot less hamfisted while also enabling this exact use case.
Examples of potential fixups include:

Upgrading to the latest Node.js version
Adopting serverless-plugin-canary-deployments

There's also opportunity to roll glaring issues into custom linting rules that are packaged up into skuba lint. That would give us the power to break CI if the issue is deemed serious enough.

I believe https://github.com/seek-oss/skuba/pull/1382 resolved this


Saver doesn't follow HTTP Status Code 30x redirects

It would be nice if the saver could handle file URLs which may be redirected.
IE
File Explorer gives Kloudless the url "example.com/myFile.pdf" to save
Kloudless requests "example.com/myFile.pdf" and recieves a 302 status code with a "Location: example.com/myActualFile.pdf" header
It would be nice if Kloudless would follow that header to the actual file and save that one.
I don't know if this is feasable, but would be quite useful for hooking up to dynamic file systems.

While we do follow redirects for GET requests (like downloads), uploads generally do not resend POST data on a redirect, since the redirect could be in response to a successful operation rather than a failure. We would not want to resend data on a success since it may not be expected, and even if it is, it may not be idempotent. I believe the HTTP spec does allow for the scenario you describe with a 307 response code, but I doubt the server you are talking about returns that.

Hmm strange. Its failing in this case for me. Maybe because it was getting redirecting twice? The second time to a separate domain.
first response 301, second response 302.
Anyway, we are just using the direct URL now, so it's may not be worth tracking down.

Whoops, I misunderstood and replied too soon. This is the case where the Saver downloads the file and attempts to save it. I'll verify that we follow redirects on downloads for this particular case and get back with an update.

Cool, no problem. Thanks Vinod.
On Thursday, April 2, 2015, Vinod Chandru<EMAIL_ADDRESS>wrote:

Whoops, I misunderstood and replied too soon. This is the case where the
Saver downloads the file and attempts to save it. I'll verify that we
follow redirects on downloads for this particular case and get back with an
update.
—
Reply to this email directly or view it on GitHub
https://github.com/Kloudless/file-explorer/issues/18#issuecomment-89104050
.

I've been unable to reproduce this. The Saver URL is handled correctly through multiple redirects in my tests (both 301 and 302). If you could provide me with a test URL, I can help troubleshoot further.

Please re-open this issue if you continue to encounter this problem.


Broken Link

Description:
https://github.com/ibm-hcbt/cloud-pak-sandboxes/blob/master/scripts/iaf/README.md
In Step 3:
3. Prerequisites for installing AI components (optional)
Go here for details.
Problem:
Clicking here presents,
We're sorry!

To view the documentation for IBM Automation Foundation Entitled, you need to be authorized.
Please sign in to IBM with your IBM ID.

If you can't view the documentation after you sign in, contact IBM Documentation support to request access to this documentation.

This link flakiness has to do the the docs.  Sometimes it works, sometimes it doesn't.  They are working on it:


Semantic highlighting breaks in the working tree view

Issue Type: Bug
When making changes in a GitHub repository folder, going into Source Control and clicking one of the changes files, the working tree view is opened and you can see that the left side of this view does not have proper semantic highlighting, whereas the right side does.
VS Code version: Code 1.59.1 (3866c3553be8b268c8a7f8c0482c0c0177aa8bfa, 2021-08-19T11:56:46.957Z)
OS version: Windows_NT x64 10.0.19043
Restricted Mode: No

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz (12 x 3192)

GPU Status
2d_canvas: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onoop_rasterization: enabledopengl: enabled_onrasterization: enabledskia_renderer: enabled_onvideo_decode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
19.89GB (4.53GB free)

Process Argv
D:\Users\rodri\Documents\GitHub\hypixel-translators-bot --crash-reporter-id 1aa51578-c79e-468f-b062-c24334e21918

Screen Reader
no

VM
0%

Extensions (17)

Extension
Author (truncated)
Version

better-comments
aar
2.1.0

jsdoc-markdown-highlighting
bie
0.0.1

vscode-eslint
dba
2.1.23

gitlens
eam
11.6.0

EditorConfig
Edi
0.16.4

prettier-vscode
esb
8.1.0

copilot
Git
1.3.2425

vscode-graphql
Gra
0.3.16

discord-vscode
icr
5.7.0

vscode-env
Iro
0.1.0

python
ms-
2021.8.1147840270

jupyter
ms-
2021.8.1236758218

remote-wsl
ms-
0.58.2

vsliveshare
ms-
1.0.4673

vetur
oct
0.34.1

vscodeintellicode
Vis
1.2.14

minecraft-lang-colorizer
zz5
1.0.0

A/B Experiments
vsliv368cf:30146710
vsreu685:30147344
python383cf:30185419
vspyt653:30270858
pythonvspyt602:30300191
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythonvspyt639:30300192
pythontb:30283811
pythonptprofiler:30281270
vshan820:30294714
vstes263cf:30335440
pythondataviewer:30285071
pythonvsuse255:30340121
vscod805cf:30301675
pythonvspyt200:30340761
vscextlangct:30333562
binariesv615:30325510
pythonvssor306:30344512
bridge0708:30335490
pygetstartedc2:30351386
vstre464cf:30350173
bridge0723:30353136
vsdyn420:30354109

Semantic highlighting comes from language servers and not all language servers ca work with virtual files (files from repositories). Also, semantic highlighting depends on resolving references in the context of a project which is hard for repo files as the project context is unknown to the language server.
For what language did you see the issue?

Semantic highlighting comes from language servers and not all language servers ca work with virtual files (files from repositories). Also, semantic highlighting depends on resolving references in the context of a project which is hard for repo files as the project context is unknown to the language server.
For what language did you see the issue?

Sorry forgot to mention it was on TypeScript. Just thought it was weird how one view worked and the other one didn’t

Not sure if TypeScript want to attempt to get sematic highlighting for the file content on the left side of the diff editor.

Why would it not?

As mentioned, semantic highlighting depends on resolving references in the context of a project. The left-hand file is a file from the history, and might reference other files from the history. The TypeScript server does not have access to these other files.


Update pftv-adblock-inject.js

Use the second button instead since Project Free TV updated their site

thank you

will update extension on chrome store soon


[Bot Rules] Update Cosmos Contacts

Summary
Updating Cosmos contacts, by request.

//fyi: @ronniegeraghty


Problem with php 8.1 and readonly

Hello, I updated the version of php and it throws me this problem, how can I solve it?

readonly is a PHP 8.1 feature which the package does not support yet.
https://github.com/laravel-json-api/laravel/issues/138

Yes, this is a duplicate of a previous issue. See #138 for PHP 8.1 - I'll add some instructions there as to how to install the dev version if you need to. I'm just waiting for Laravel 9 before I tag a major release. That's due in the next week or two.


(%TheTrueLtaker) gen9pokeaaa: banning meowscarada and magpull

%TheTrueLtaker: "banning meowscarada and magpull"
Created via Iolanthe on Wed, 13 Sep 2023 13:55:52 GMT.

Already effected at https://github.com/OperationTourCode/OTC/commit/136e09fdac173a1a94268a1126d44024972e0c4b


wr.s3.read_excel can't read multi-sheet .xls files

Describe the bug
I'm using Data Wrangler to process some Excel spreadsheets stored on S3. The spreadsheets are multi-sheet. I've found that wr.s3.read_excel reads .xlsx  objects fine. But it fails when reading .xls objects. My testing indicates that the problem with .xls is for multi-sheet spreadsheets only. BTW, my testing also indicates that reading my test multi-sheet .xls files works OK using the basic Pandas pd.read_excel method.
Environment
asn1crypto==1.4.0
astroid==2.3.0
awswrangler==2.8.0
backcall==0.2.0
beautifulsoup4==4.9.3
boto3==1.17.86
botocore==1.20.45
certifi==2021.5.30
chardet==4.0.0
decorator==5.0.5
Django==2.0.2
et-xmlfile==1.1.0
git-remote-codecommit==1.15.1
idna==2.10
ikp3db==1.4.1
importlib-metadata==3.10.0
ipython==7.22.0
ipython-genutils==0.2.0
isort==4.3.21
jedi==0.18.0
jmespath==0.10.0
lazy-object-proxy==1.6.0
lxml==4.6.3
mccabe==0.6.1
numpy==1.20.3
openpyxl==3.0.7
pandas==1.2.4
parso==0.8.2
pbr==5.5.1
pexpect==4.8.0
pg8000==1.19.5
pickleshare==0.7.5
prompt-toolkit==3.0.18
ptyprocess==0.7.0
pyarrow==4.0.1
Pygments==2.8.1
pylint==2.4.4
pylint-django==2.3.0
pylint-flask==0.6
pylint-plugin-utils==0.6
PyMySQL==1.0.2
python-dateutil==2.8.1
pytz==2021.1
redshift-connector==2.0.881
requests==2.25.1
s3transfer==0.4.2
scramp==1.4.0
six==1.15.0
soupsieve==2.2.1
stevedore==3.3.0
traitlets==5.0.5
typed-ast==1.4.2
typing-extensions==<IP_ADDRESS>
urllib3==1.26.4
virtualenv==16.2.0
virtualenv-clone==0.5.4
virtualenvwrapper==4.8.4
wcwidth==0.2.5
wrapt==1.12.1
xlrd==2.0.1
zipp==3.4.1
To Reproduce

In Excel create a new spreadsheet. Add a second tab to it called 'Sheet2'. Type a small table of rows and columns into that sheet.
Save the spreadsheet as demo_excel_multi_sheet.xlsx.
Save the spreadsheet a second time as demo_excel_multi_sheet.xls.
Upload copies of both spreadsheets to a test S3 bucket.
Run the following program using Python 3,

import awswrangler as wr
import pandas as pd
import boto3
import io

data_bucket = <Name of your bucket>
xlsx_object = 'demo_excel_multi_sheet.xlsx'
xls_object = 'demo_excel_multi_sheet.xls'

# XLSX on S3 using Data Wrangler works.
xlsx_s3_df = wr.s3.read_excel('s3://' + data_bucket + '/' + xlsx_object, sheet_name='Sheet2')
print(xlsx_s3_df.head())

# XLS locally also works.
xls_local_df = pd.read_excel(xls_object, sheet_name='Sheet2')
print(xls_local_df.head())

# XLS on S3 using Boto3 works.
s3 = boto3.resource('s3')
s3_client = boto3.client('s3')
obj = s3_client.get_object(Bucket=data_bucket, Key=xls_object)
data = obj['Body'].read()
df_boto = pd.read_excel(io.BytesIO(data), sheet_name='Sheet2')
print(df_boto.head())

# XLS on S3 using Data Wrangler doesn't work.
xls_s3_df = wr.s3.read_excel('s3://' + data_bucket + '/' + xls_object, sheet_name='Sheet2')
print(xls_s3_df.head())

Notice that the first 3 print(xyz.head()) statements succeed, but the 4th one is never reached (error message on previous line of code).
P.S. Please do not attach files as it's considered a security risk. Add code snippets directly in the message body as much as possible.

Thanks for raising this @johntelforduk. The culprit is this guy. Removing that line solves it.
From the pandas docs, it seems that the openpyxl engine cannot handle xls. I believe we should simply rely on Pandas to infer the right engine but will try to understand if there are any caveats first and then will open a PR for a fix.

Hi @jaidisido,
Thanks for investigating this.
I commented out the pandas_kwargs["engine"] = "openpyxl" line that you mentioned in my dev environment. I'm pleased to say that it fixed the bug for my test spreadsheet.
Let me know if I can assist in any way; testing the completed fix, etc.
Regards, John T.

Thanks, it has now been merged to main and can be tested:
pip uninstall awswrangler -y
pip install git+https://github.com/awslabs/aws-data-wrangler.git@main

until it's available in the next release.

My testing indicates that this is fixed. Thanks!


Improving "Our Popular Courses" page

Hi @vivekvardhan2810 .I can improve Our Popular page to make it look more eye-appealing and easy to use .

Could you assign me this issue and add labels gssoc-ext and hactoberfest-accepted ?

this issue was resolved, so i am closing this issue.


add package config purging option

Expose a parameter to support replacing or keeping existing config files for debian package upgrades.
Otherwise, important files like /etc/init.d/logstash do not get updated.

Woops. Created this on the wrong fork. please ignore this PR.


feat: generate tslint.json

init now generates a tslint.json file which inherits from the default
configuration. This empowers the users to customize if necessary
instead of being overly opinionated.
Fixes: #127
Fixes: #119
This depends upon #158 and #159, so the first two commits don't need to be reviewed. They will be removed once those PRs land.

Codecov Report

Merging #160 into master will increase coverage by 0.09%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #160      +/-   ##
==========================================
+ Coverage   96.67%   96.77%   +0.09%
==========================================
  Files          10       10
  Lines         331      341      +10
  Branches       22       24       +2
==========================================
+ Hits          320      330      +10
  Misses         11       11

Impacted Files
Coverage Δ

test/test-clean.ts
100% <ø> (ø)
:arrow_up:

src/lint.ts
100% <100%> (ø)
:arrow_up:

test/test-kitchen.ts
100% <100%> (ø)
:arrow_up:

test/test-format.ts
100% <100%> (ø)
:arrow_up:

test/test-lint.ts
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

I am 👎  on this approach.  My hope would be that the average user wouldn't need to have their own tslint.json.  I'm mostly 👎 on supporting the override at all, but I get why some people will just insist on it.  Instead of generating this during init, could we add a command that drops the file for you?  Like a gts customize-lint or something like that?

This is a good discussion.
This is what the README says about this project:

No configuration. The easiest way to enforce consistent style in your project. Just drop it in.

This also speaks to what you are trying to argue about the average user not needing to customize anything. I agree with that. Yet, this project, today, generates a tsconfig.json in the users's directory. Is that an invitation for the user to customize it? Maybe, maybe not (IMHO I don't think it is an invitation to customize). It is just how we wire things up.  By the same argument, I do not think that generating a tslint.json is an invitation for the user to customize the lint config.
Either way, we need to be consistent in our own reason. We need to have a good reason why it is okay to generate tsconfig.json and not the tslint.json. We should generate both, or neither.

Fair points!  I suppose in a perfect world, I'd prefer we take the same approach with tsconfig.json. As long as there was an easy way to generate it, not needing to have that either would be great :)

I think generating the files is friendlier. The value of this project is in providing a good, consistent style guide that can be used in a project without thinking about it.
If someone has thought about the precise, but different, style they want, and still find value in this project – let us not turn them away.

As long as there was an easy way to generate it, not needing to have that either would be great :)

I do not think this is practical. The user needs to be able to customize their repo structure.

The other reason why this is desirable is mentioned in https://github.com/google/ts-style/issues/119: IDE support. A tslint.json in the correct location ends up getting picked up by the IDE or other tooling the user may have,.
I'm -1 on generating the configuration only under a flag, if provided by the user. That is not going to be discoverable. This needs to be the default behavior so that users don't have to pass a flag effectively equivalent to --and-work-with-my-IDE. I feel strong about this at this point.

Again, all fair points.  You're probably right about this, but I that doesn't mean I have to be happy about it 😆 You won me over.  I'm cool with this approach.