No longer works since latest Comfy Update

Since todays update, PulID is no longer working on my end. Doing a rollback to the previous version makes it work again.
The Error:
!!! Exception during processing !!! forward_orig() takes from 7 to 9 positional arguments but 10 were given
Traceback (most recent call last):
  File "D:\AI\StabilityMatrix\Packages\ComfyUI\execution.py", line 323, in execute
    output_data, output_ui, has_subgraph = get_output_data(obj, input_data_all, execution_block_cb=execution_block_cb, pre_execute_cb=pre_execute_cb)
  File "D:\AI\StabilityMatrix\Packages\ComfyUI\execution.py", line 198, in get_output_data
    return_values = _map_node_over_list(obj, input_data_all, obj.FUNCTION, allow_interrupt=True, execution_block_cb=execution_block_cb, pre_execute_cb=pre_execute_cb)
  File "D:\AI\StabilityMatrix\Packages\ComfyUI\execution.py", line 169, in _map_node_over_list
    process_inputs(input_dict, i)
  File "D:\AI\StabilityMatrix\Packages\ComfyUI\execution.py", line 158, in process_inputs
    results.append(getattr(obj, func)(**inputs))
  File "D:\AI\StabilityMatrix\Packages\ComfyUI\comfy_extras\nodes_custom_sampler.py", line 633, in sample
    samples = guider.sample(noise.generate_noise(latent), latent_image, sampler, sigmas, denoise_mask=noise_mask, callback=callback, disable_pbar=disable_pbar, seed=noise.seed)
  File "D:\AI\StabilityMatrix\Packages\ComfyUI\comfy\samplers.py", line 740, in sample
    output = self.inner_sample(noise, latent_image, device, sampler, sigmas, denoise_mask, callback, disable_pbar, seed)
  File "D:\AI\StabilityMatrix\Packages\ComfyUI\comfy\samplers.py", line 719, in inner_sample
    samples = sampler.sample(self, sigmas, extra_args, callback, noise, latent_image, denoise_mask, disable_pbar)
  File "D:\AI\StabilityMatrix\Packages\ComfyUI\comfy\samplers.py", line 624, in sample
    samples = self.sampler_function(model_k, noise, sigmas, extra_args=extra_args, callback=k_callback, disable=disable_pbar, **self.extra_options)
  File "D:\AI\StabilityMatrix\Packages\ComfyUI\venv\lib\site-packages\torch\utils\_contextlib.py", line 116, in decorate_context
    return func(*args, **kwargs)
  File "D:\AI\StabilityMatrix\Packages\ComfyUI\comfy\k_diffusion\sampling.py", line 155, in sample_euler
    denoised = model(x, sigma_hat * s_in, **extra_args)
  File "D:\AI\StabilityMatrix\Packages\ComfyUI\comfy\samplers.py", line 299, in __call__
    out = self.inner_model(x, sigma, model_options=model_options, seed=seed)
  File "D:\AI\StabilityMatrix\Packages\ComfyUI\comfy\samplers.py", line 706, in __call__
    return self.predict_noise(*args, **kwargs)
  File "D:\AI\StabilityMatrix\Packages\ComfyUI\comfy\samplers.py", line 709, in predict_noise
    return sampling_function(self.inner_model, x, timestep, self.conds.get("negative", None), self.conds.get("positive", None), self.cfg, model_options=model_options, seed=seed)
  File "D:\AI\StabilityMatrix\Packages\ComfyUI\comfy\samplers.py", line 279, in sampling_function
    out = calc_cond_batch(model, conds, x, timestep, model_options)
  File "D:\AI\StabilityMatrix\Packages\ComfyUI\comfy\samplers.py", line 228, in calc_cond_batch
    output = model.apply_model(input_x, timestep_, **c).chunk(batch_chunks)
  File "D:\AI\StabilityMatrix\Packages\ComfyUI\comfy\model_base.py", line 144, in apply_model
    model_output = self.diffusion_model(xc, t, context=context, control=control, transformer_options=transformer_options, **extra_conds).float()
  File "D:\AI\StabilityMatrix\Packages\ComfyUI\venv\lib\site-packages\torch\nn\modules\module.py", line 1736, in _wrapped_call_impl
    return self._call_impl(*args, **kwargs)
  File "D:\AI\StabilityMatrix\Packages\ComfyUI\venv\lib\site-packages\torch\nn\modules\module.py", line 1747, in _call_impl
    return forward_call(*args, **kwargs)
  File "D:\AI\StabilityMatrix\Packages\ComfyUI\comfy\ldm\flux\model.py", line 181, in forward
    out = self.forward_orig(img, img_ids, context, txt_ids, timestep, y, guidance, control, transformer_options)
TypeError: forward_orig() takes from 7 to 9 positional arguments but 10 were given

It seems that the problem comes from this line. I modified it back to this and now image generation works with PuLID.

same problem

Same here

I kept reverting comfyui to previous commits and reached the commit 8b90e50979b0d33e1f8d10d5c938361f59f95474 but still it's not working. @Pantonia4 Can you tell us which commit exactly broke this custom node?

Use of Hyper-FLUX.1-dev-8step-lora is not working either. Only get noise image

It seems that the problem comes from this line. I modified it back to this and now image generation works with PuLID.
Please note that this is a temporary workaround for simple workflows with PuLID and is not a permanent fix; it may also impact the functionality of other nodes.

For me, the PuLID node stopped working immediately after I updated Comfyui on 2024-11-12. So, immediately after @Pantonia4 posted the error "TypeError: forward_orig() takes from 7 to 9 positional arguments but 10 were given" in the Comfyui repository, considering that the PuLID nodes had not undergone changes, I started looking for what it was updated in Comfyui.
First I checked the branches.
https://github.com/comfyanonymous/ComfyUI/branches
https://github.com/comfyanonymous/ComfyUI/tree/patch_hooks_improved_memory
https://github.com/comfyanonymous/ComfyUI/pull/5583
https://github.com/comfyanonymous/ComfyUI/tree/improved_memory
https://github.com/comfyanonymous/ComfyUI/compare/improved_memory...master
click on Files changed
search for "flux" and "comfy/ldm/flux/model.py"
https://github.com/comfyanonymous/ComfyUI/compare/improved_memory...master#diff-453e6e6c1a6fa355aa5f5b6aabb5f9153c526c115d08ad757c0243d9f8ca31ee
and I took each line in turn, so I discovered that removing transformer_options from ..ComfyUI_windows_portable\ComfyUI\comfy\ldm\flux\model.py solves the problem (at least for me).
out = self.forward_orig(img, img_ids, context, txt_ids, timestep, y, guidance, control, transformer_options)
https://github.com/comfyanonymous/ComfyUI/commit/96b2080971b1e6606bdbaf2aa4f24b7f aca3999a#diff-453e6e6c1a6fa355aa5f5b6aabb5f9153c526c115d08ad757c0243d9f8ca31eeL159
Maybe someone much more skilled will find a better solution - I'm not a coder.
Since 2024-11-12 I haven't updated Comfyui or any other nodes, and it seems that now there is a fix for forward_orig:
https://github.com/sipie800/ComfyUI-PuLID-Flux-Enhanced/pull/27#issue-2664002771
Using FLUX-Dev I get ~1 min (2.10s/it) to generate an 1080p image with PuLID and ~3 min to generate a video sequence 1080p 60fps (10.78s/it, dpmpp/karras/cfg2.5) using SVD/Video Helper Suite. Sometimes the time increases to 5-15 min per img/vid so I have to cleanup the VRAM or unload modules or to restart Comfyui to get the same working speed. But I personally find it extremely acceptable.
OK. Now I am trying to finish a personal project, but I hope that during the next week I will upgrade Comfyui and the nodes, I will test more and come back with more details. Also, I suspect a problem with the Nvidia driver and CUDA package on this torch version ... 2.4.1+cu121 was much faster. So... there will be more work.
My own specs + log, packages list and snapshot.
Platform: Windows 10 Pro 64-bit v.22H2
Python version: 3.11.8 (tags/v3.11.8:db85d51, Feb 6 2024, 22:03:32) [MSC v.1937 64 bit (AMD64)]
Total VRAM 24564 MB, total RAM 130980 MB
pytorch version: 2.5.1+cu124
xformers version: 0.0.28.post3
Set vram state to: NORMAL_VRAM
Device: cuda:0 NVIDIA GeForce RTX 4090 : cudaMallocAsync
GPU/s: NVIDIA GeForce RTX 4090
NVIDIA Driver: 566.03
ComfyUI-Manager (V2.51.9)
ComfyUI Revision: 2827 [8ebf2d88] | Released on '2024-11-12'
comfyui.log
packages list.txt
2024-11-17_23-59-18_snapshot.json
I hope this information helps you. Thanks everyone for all the great work!

Hi there, I see where it says change this line to this line.  When I click the links it opens the code but I am not sure which line needs to be changed from what to what.
Not great at this, is there a line number I should be looking for.

Hi there, I see where it says change this line to this line. When I click the links it opens the code but I am not sure which line needs to be changed from what to what.
Not great at this, is there a line number I should be looking for.

Hi there, I see where it says change this line to this line. When I click the links it opens the code but I am not sure which line needs to be changed from what to what.
Not great at this, is there a line number I should be looking for.

Thanks for that, I noticed though the path doesn't line up with comfyui portable.  Not sure where to look.  If I search for model.py I see a few returns

Found it :)

Hi there, I see where it says change this line to this line. When I click the links it opens the code but I am not sure which line needs to be changed from what to what.
Not great at this, is there a line number I should be looking for.

Thanks for that, I noticed though the path doesn't line up with comfyui portable. Not sure where to look. If I search for model.py I see a few returns

You can find model.py here: [your drive]\ComfyUI_windows_portable\ComfyUI\comfy\ldm\flux\

:/  got this now
expected scalar type Half but found BFloat16

:/ got this now
expected scalar type Half but found BFloat16

If you're using FLUX/CUDA, make sure you are using the right model/vae/clip.

:/ got this now
expected scalar type Half but found BFloat16

If you're using FLUX/CUDA, make sure you are using the right model/vae/clip.

Actually I tried #27 and I do get "expected scalar type Half but found BFloat16". The workflow is attached in #27 it uses GGUF, but I also tried another workflow that uses the fluxdev model also with #27 fix but still got the same "expected scalar type Half but found BFloat16" . I don't think it's related to the right mode/vae/clip.

Actually I tried #27 and I do get "expected scalar type Half but found BFloat16". The workflow is attached in #27 it uses GGUF, but I also tried another workflow that uses the fluxdev model also with #27 fix but still got the same "expected scalar type Half but found BFloat16" . I don't think it's related to the right mode/vae/clip.

I know that workflow but never use it.
Anyway, let me know if this workflow works for you:
ady-pulid-flux-txt2img.json
Requested to load Flux
Loading 1 new model
loaded partially 14234.197129821778 15024.12890625 0
100%|██████████████████████████████████████████████████████████████████████████████████| 30/30 [01:08<00:00,  2.29s/it]
Requested to load AutoencodingEngine
Loading 1 new model
loaded completely 0.0<PHONE_NUMBER>7282715 True
Prompt executed in 119.17 seconds

That's a cool workflow.  I have been trying to do something like that to take the input face, a pose image and pulid them out.  Always looks face details and skin looks plastic, plus pulid seems to drift a fair bit from the source

Actually I tried #27 and I do get "expected scalar type Half but found BFloat16". The workflow is attached in #27 it uses GGUF, but I also tried another workflow that uses the fluxdev model also with #27 fix but still got the same "expected scalar type Half but found BFloat16" . I don't think it's related to the right mode/vae/clip.

I know that workflow but never use it. Anyway, let me know if this workflow works for you: ady-pulid-flux-txt2img.json
Requested to load Flux Loading 1 new model loaded partially 14234.197129821778 15024.12890625 0 100%|██████████████████████████████████████████████████████████████████████████████████| 30/30 [01:08<00:00, 2.29s/it] Requested to load AutoencodingEngine Loading 1 new model loaded completely 0.0<PHONE_NUMBER>7282715 True Prompt executed in 119.17 seconds
LE: BTW, for "expected scalar type Half but found BFloat16" error there is an opened issue here #15

Thank you for the workflow and for pointing me to the issue #15  that discusses "expected scalar type Half but found BFloat16" .
I tried your workflow but I still get "expected scalar type Half but found BFloat16" and I'm on the code for PR #27

0%|          | 0/40 [00:00<?, ?it/s]
!!! Exception during processing !!! forward_orig() takes from 7 to 9 positional arguments but 10 were given
Traceback (most recent call last):
File "D:\u01\stabilityMatrix\Data\Packages\ComfyUI\execution.py", line 323, in execute
output_data, output_ui, has_subgraph = get_output_data(obj, input_data_all, execution_block_cb=execution_block_cb, pre_execute_cb=pre_execute_cb)
File "D:\u01\stabilityMatrix\Data\Packages\ComfyUI\execution.py", line 198, in get_output_data
return_values = _map_node_over_list(obj, input_data_all, obj.FUNCTION, allow_interrupt=True, execution_block_cb=execution_block_cb, pre_execute_cb=pre_execute_cb)
File "D:\u01\stabilityMatrix\Data\Packages\ComfyUI\execution.py", line 169, in map_node_over_list
process_inputs(input_dict, i)
File "D:\u01\stabilityMatrix\Data\Packages\ComfyUI\execution.py", line 158, in process_inputs
results.append(getattr(obj, func)(**inputs))
File "D:\u01\stabilityMatrix\Data\Packages\ComfyUI\comfy_extras\nodes_custom_sampler.py", line 633, in sample
samples = guider.sample(noise.generate_noise(latent), latent_image, sampler, sigmas, denoise_mask=noise_mask, callback=callback, disable_pbar=disable_pbar, seed=noise.seed)
File "D:\u01\stabilityMatrix\Data\Packages\ComfyUI\comfy\samplers.py", line 740, in sample
output = self.inner_sample(noise, latent_image, device, sampler, sigmas, denoise_mask, callback, disable_pbar, seed)
File "D:\u01\stabilityMatrix\Data\Packages\ComfyUI\comfy\samplers.py", line 719, in inner_sample
samples = sampler.sample(self, sigmas, extra_args, callback, noise, latent_image, denoise_mask, disable_pbar)
File "D:\u01\stabilityMatrix\Data\Packages\ComfyUI\comfy\samplers.py", line 624, in sample
samples = self.sampler_function(model_k, noise, sigmas, extra_args=extra_args, callback=k_callback, disable=disable_pbar, **self.extra_options)
File "D:\u01\stabilityMatrix\Data\Packages\ComfyUI\venv\lib\site-packages\torch\utils_contextlib.py", line 116, in decorate_context
return func(*args, **kwargs)
File "D:\u01\stabilityMatrix\Data\Packages\ComfyUI\comfy\k_diffusion\sampling.py", line 689, in sample_dpmpp_2m
denoised = model(x, sigmas[i] * s_in, **extra_args)
File "D:\u01\stabilityMatrix\Data\Packages\ComfyUI\comfy\samplers.py", line 299, in call
out = self.inner_model(x, sigma, model_options=model_options, seed=seed)
File "D:\u01\stabilityMatrix\Data\Packages\ComfyUI\comfy\samplers.py", line 706, in call
return self.predict_noise(*args, **kwargs)
File "D:\u01\stabilityMatrix\Data\Packages\ComfyUI\comfy_extras\nodes_custom_sampler.py", line 545, in predict_noise
out = comfy.samplers.calc_cond_batch(self.inner_model, [negative_cond, middle_cond, self.conds.get("positive", None)], x, timestep, model_options)
File "D:\u01\stabilityMatrix\Data\Packages\ComfyUI\comfy\samplers.py", line 228, in calc_cond_batch
output = model.apply_model(input_x, timestep, **c).chunk(batch_chunks)
File "D:\u01\stabilityMatrix\Data\Packages\ComfyUI\comfy\model_base.py", line 144, in apply_model
model_output = self.diffusion_model(xc, t, context=context, control=control, transformer_options=transformer_options, **extra_conds).float()
File "D:\u01\stabilityMatrix\Data\Packages\ComfyUI\venv\lib\site-packages\torch\nn\modules\module.py", line 1736, in _wrapped_call_impl
return self._call_impl(*args, **kwargs)
File "D:\u01\stabilityMatrix\Data\Packages\ComfyUI\venv\lib\site-packages\torch\nn\modules\module.py", line 1747, in _call_impl
return forward_call(*args, **kwargs)
File "D:\u01\stabilityMatrix\Data\Packages\ComfyUI\comfy\ldm\flux\model.py", line 181, in forward
out = self.forward_orig(img, img_ids, context, txt_ids, timestep, y, guidance, control, transformer_options)
TypeError: forward_orig() takes from 7 to 9 positional arguments but 10 were given
Prompt executed in 111.83 seconds

OK. Now I am trying to finish a personal project, but I hope that during the next week I will upgrade Comfyui and the nodes, I will test more and come back with more details.

I just updated ComfyUI to the latest version and all the nodes I use (including PuLID_ComfyUI and ComfyUI-PuLID-Flux-Enhanced) and personally I have no problems.


fix(ui): fix beta alert EE-5498

closes #EE-5498

/azp run

Re-triggered the checks with https://github.com/portainer/portainer/pull/8975
If for some reasons they fail later because the branch doesn't exist, feel free to reopen the PR, restore the branch and retrigger the checks from there.


use Harness.IO instead of sys in harness

alternative fix for #4359.
It is ok for sys to be undefined since it is just an implementation detail of the default version of CompilerHost. Compiler and language service can already handle this. However test harness still uses sys all over the place, in this PR usages of sys in tests were replaced with Harness.IO. Also I've kept only fs in 'package.json' since this is the only module we use that is not shimmed by the 'webpack'.

ok, something is broken I need to re-run tests on Linux box since on Windows machine everything works fine

The browser stuff in package.json is so that webpack/browserify don't shim those modules. They're not actually needed at runtime in the browser and shimming them just adds to the filesize without actually doing anything.

I'm ok with putting back 'fs', 'os' and 'path' since these modules should not be used in tests. However currently test harness uses 'buffer' so it needs to be shimmed. It can be re-added to 'package.json' if there is a way to tell browserify cli to either ignore 'package.json' or include some module if even if it was skipped in "browser" section - after few minutes of experimenting I have not found it.

pinging @mhegazy

currently test harness uses 'buffer' so it needs to be shimmed

Gotcha. +1, I think this is much better than rolling back #4308

:+1:


[FEATURE REQ] Enable passing timespan as range for ApplicationInsightsDataClient methods

Is your feature request related to a problem? Please describe.
Currently it is not possible to use ApplicationInsightsDataClient methods to get data between a timespan range.
Describe the solution you'd like
According to the API Docs:

Specify the timespan
The Application Insights APIs specify time using ISO 8601 formats. A timespan, or time range, for a query can be specified as

the length of time before now (e.g P2D for the last 2 days, PT12H for the last 12 hours, etc.), or
as a time range specified by a start and end time where each time has the format YYYY-MM-DDThh:mm:ss.sssZ and these are combined to form a time range as 2016-03-01T13:00:00Z/20016-03-03T15:30:00Z, or
or as a start time and a length of time after that, e.g. 2016-03-01/P1D which specifies the time range covering the entire day March 1 UTC.

Currently only option 1. is possible to use.
Options 2 and 3 are simply not possible because the SDK methods only receive one TimeSpan parameter. This parameter is encoded it into the query parameter as
timespan=<iso-format-timespan>
so there is never a possibility of having the query parameter as
timespan=<iso-format-timespan-1>/<iso-format-timespan-2>
Which is possible in the API Explorer:

Describe alternatives you've considered

Using QueryWithHttpMessagesAsync but it also receives a timespan which is used as query parameter without supporting ranges
Build the url and executing the GET request manually: defeats the purpose of the SDK

Additional context
Using latest SDK version: Microsoft.Azure.ApplicationInsights 0.9.0-preview
Is it possible to issue a PR? I'm not seeing the methods in the master branch (https://github.com/Azure/azure-sdk-for-net/tree/master/sdk/applicationinsights/Microsoft.Azure.ApplicationInsights/src)
Information Checklist

[X] Description Added
[X] Expected solution specified

Thanks @AndreMantas for reporting this - routing this for the right team to take a look

Hi @AndreMantas ,
Sorry for the late response.
I checked and I am able to provide URL-encoded ranges in the timespan parameter, see this query for example.
I didn't use the ApplicationInsightsDataClient class, but seems like it only encodes the timespan parameter, so it should behave the same.
However, I did find 2 typos in the examples you provided, maybe they caused your attempts to fail?
In #2 using fromDate/toDate ranges, your toDate has a typo - 20016 instead of 2016,
and in #3 using fromDate/toPeriod example, the period should be PT1D instead of P1D.
Can you please try again and let me know if you still see the issue?

@AndreMantas could you take a look at @alongafni's reply?

@alongafni the 2 typos you mentioned is when i'm quoting the API Docs: https://dev.applicationinsights.io/documentation/Using-the-API/Metrics
It was either that way when i copied from there or somehow i added the typos.
Either way it doesn't matter because im not using those values...
My issue is specifically with the ApplicationInsightsDataClient: https://docs.microsoft.com/en-us/dotnet/api/microsoft.azure.applicationinsights.applicationinsightsdataclient?view=azure-dotnet#methods
I could obviously create a raw request in c# and add the query string parameters as i wanted but that is not the point here.
What i am/was reporting is the lack of possibility to pass a timespan range to the methods of this class so that it encodes them. As i said:

Options 2 and 3 are simply not possible because the SDK methods only receive one TimeSpan parameter. This parameter is encoded it into the query parameter as
timespan=<iso-format-timespan>
so there is never a possibility of having the query parameter as
timespan=<iso-format-timespan-1>/<iso-format-timespan-2>

@AndreMantas Sorry, I understand now what you meant in the original post. I will take it from here and keep you updated with any progress.

@AndreMantas I did some digging, and apparently the package you referenced is Deprecated (even though it is not marked as such, sorry about that) - https://www.nuget.org/packages/Microsoft.Azure.ApplicationInsights/
The package that you should be using is this - https://www.nuget.org/packages/Microsoft.Azure.ApplicationInsights.Query/0.9.0-preview
Docs are here - https://docs.microsoft.com/en-us/dotnet/api/microsoft.azure.applicationinsights.query.applicationinsightsdataclient?view=azure-dotnet-preview
In the new package, the timespan parameter is modeled as string which allows providing any of the 3 time ranges you describe, and I verified I can use option #3 with it:
var task = client.Events.GetCustomEventsWithHttpMessagesAsync(appId, "2020-05-01/2020-05-02");
task.Wait();
var results = task.Result;
As you may have noticed, the methods and parameters are organized a bit differently, so you need to do something like this:
client.Events.GetCustomEventsWithHttpMessagesAsync(applicationId, ...);
Please let me know if you have additional questions or concerns.
Alon


[FEATURE REQUEST] Per-account flag names

Is your feature request related to a problem? Please describe.
I use flags for the type of transaction on my checking account (ACH pull, bank bill pay, debit card, etc.). I'd like to try using flags for other purposes, but the names I assigned for use on my checking account carry over to other accounts as well.
Describe the solution you'd like
There should be an option to make flag names per-account.

Dang, this would be pretty nice. I've added a Trello card for this here. Feel free to upvote it and hopefully it gets picked by someone to work on!


Pro 1.4.1 Lines not accepting decimal in Radius/Diameter box

Found some problems entering Radius/Diameter values in the Circle tab on DD in Pro 1.4.1.

Click Map Point tool by Center Point
Click a location on map (I used point off coast of Colombia in South America
Click in Radius/Diameter and type 1000.00
Note that the decimal does not show up and by the hundredths "0" actually shows an error in the box:

verify pr: https://github.com/Esri/distance-direction-addin-dotnet/pull/370

looks to me like it works on 1.4

[press enter]

seems ok for 1.4.1 as well, tested using build 1453


Remote addresses didn't match WARN in logs

I'm using Spring Cloud Gateway M9 on Kubernetes.
Here is my config:
.route(r -> r.host("my.domain.name")
             .and()
             .remoteAddr("<IP_ADDRESS>/24")
             .uri("http://my.internal.app"))

I'm seeing a lot of warnings in my log like this one:
Remote addresses didn't match <IP_ADDRESS> != my.domain.name

Looking at the code of RemoteAddrRoutePredicateFactory:
...

InetSocketAddress remoteAddress = config.remoteAddressResolver.resolve(exchange);
if (remoteAddress != null) {
   String hostAddress = remoteAddress.getAddress().getHostAddress();
   String host = exchange.getRequest().getURI().getHost();

  if (!hostAddress.equals(host)) {
    log.warn("Remote addresses didn't match " + hostAddress + " != " + host);
  }

...

I don't understand why the remote (client) address is compared with the URI's host address. Am I missing something?

That's a great question. I'll turn it to debug unless I can remember why :wink:.

5 years later... and this is still happening :) btw - it actually helps understand what IP is being matched against (because when the service works behind god knows how many reverse proxies, you never know for sure!)
but yeah, the basic premise of this check is beyond me... why would a remote IP ever be compared against the host where the service runs on?


Redistribute doesn't change the layout from CutDimension{1} to CutDimension{2}.

 m = round(Int, rand(10,10))
dm = compute(Context(), distribute(m, cutdim(1)))

ComputeFramework.DistMemory(Any,Pair[2=>RemoteRef{Channel{Any}}(2,1,17),3=>RemoteRef{Channel{Any}}(3,1,18)],ComputeFramework.CutDimension{1}())
 dm = compute(Context(), redistribute(dm, cutdim(2)))

ComputeFramework.DistMemory(Any,Pair[2=>RemoteRef{Channel{Any}}(2,1,25),3=>RemoteRef{Channel{Any}}(3,1,26)],ComputeFramework.CutDimension{1}())
The layout changes from CutDimension{2} to CutDimension{1} but doesn't change form CutDimension{1} to CutDimension{2}.

The new commit has fixed the distribution of data. But the redistributed data node doesn't have metadata and has the UnknownLayout.
ComputeFramework.DistData(Any,Pair[2=>RemoteRef{Channel{Any}}(2,1,26),3=>RemoteRef{Channel{Any}}(3,1,27)],ComputeFramework.UnknownLayout(),Dict{Any,Any}())

Bump.


The term "render" is overloaded

Currently, the term "render" is used to refer to two separate, but quite different things:

Render functions, which take a collection of props and a context object and return an Element tree.
Rendering an Element tree to a target store (e.g. DOM or string).

This dual usage also appears in React with component.render and ReactDOM.render.
Can we find a different (but still pleasing) term for the second meaning?

I'm not able to come up with a better name. I think the overload is acceptable since we've restructured internally with the "targets" folder.


2024-09 - Main

See readme for contributing guidelines.

Can you please add imo Imo motd and Motd in to main.
thanks.

Api

Please add aac to main.
thanks.

btsink BTsink Btsink.

Io na and Na

Please add ui Ui and Io in to main.
thanks.

VO to main please.
thanks.

@GeorgeWu3 Thanks. VO was just added to Main.

What about the previous comment for us?

Sorry, I meant ui.

@GeorgeWu3 ui was just added.

Thanks.

Please add CA ca us and uk in to main.
thanks.

vo and I think thats it for now.

How can you possibly add us to be spelled US? That's a word! Also, Ca sometimes means circa, E.G. Ca 5000 BCE. Unsure if the a is also capitalized in that scenario. As for UK, probably? But honestly anyone who doesn't capitalize the acronyms for UK and US is just doing it wrong, to say nothing of the fact the technically correct version is U.S. and U.K., unsure about Canada. We should at least require the capitals, I totally understand not requiring the dots though. Are you saying that all caps CA should be spelled? That might make more sense depending on circa, and capitalized US and UK are already handled.

Can you please make CA to be spelled out in Maine?

@GeorgeWu3 CA was just added to main. @ultrasound1372 Circa is handled with ca lowercase or c.a..

please add vo and ca to be To be spelled out in lower case.

@GeorgeWu3 Not doable for their lowercase variants - please see @ultrasound1372's previous comment regarding ca.

I could have sworn that there is also some French import that uses vo lowercase, but VO uppercase should be spelled as V O. Can't think of any case besides the abbreviation for VoiceOver where it would be used.

Please add AWM and AEM in to main to be Spelled out because these are Yamaha's sound technology for their keyboards.
thanks.

Also OTS as well

@GeorgeWu3 All of them were just added.

While we're talking about acronyms, how about OTT, which is a popular plug-in? The typical pronunciation I've heard in occasional YouTube videos from producers actually seems to have stress on the letters in the order secondary, none, primary, that is the T at the end is the most stressed, but exactly how the stress works is a bit up for debate, some might pronounce it in the order primary, none, secondary. Spelling should be OK for now. I think only properly written in all caps.

We have a potential issue in main. The entries Id and id, both of which are spelled out as ID, conflict with Freud's psychological component known as the id, pronounced as it was before these entries were added. I suspect this is why eloquence doesn't do this itself. Ran into this while playing a trivia game. Given it always has an article, I can't be certain that the version with an initial capital should be removed, I'd have to find actual literature to figure out whether he thought it worthy of a proper noun, or if other authors talking of his work did.

A brief click through the first few pages of Google Scholar shows it consistently written as "id" (lower case) in all publications including Freud's own work. I'd be happy with restoring the original pronunciation for the fully lower case entry.

The reason why I want Id and id to be spelled out Because in the super shot game from l-works in the registration part of the manual, they have written Id and id in the manual.
Super shot is as easy as playign it.  Go to the lWorks program group.  point to super shot, then click on registration.  the program will tell you that you haven't registered yet, it will coppy your Product Id in yoru clipboard.  You are given a product id by the game.  You will then have to e-mail us the Product Id to get your unlock code.  This is a very simple process.
Open your favorite e-mail client and send a message to<EMAIL_ADDRESS>with the name of the game, and your registration

Upon further consideration: "id" (the initialism), while non-standard, has a larger number of meanings, a broader context, and as a result, appears more frequently in daily text. As important as the Freudian psychoanalytic model might be to some, there's a case to be made for preferring the initialism over the word. @ultrasound1372

I get your point now, that's fine if we just have the lower case Version of id

@thunderdrop I just removed "id," fully lowercase, from main.

Can you please revive back the lowercase id? sometimes I spell it that way
and I think that’s fine.

The proper way, as I understand, is always supposed to be ID? IN all caps. The fully lowercase form is a legitimate conflict here if it is common to lowercase the initialism. Hmmm. Uppercase i alone can be left alone probably since there is no conflict there. So yeah it probably comes down to whether it is particularly common to write the initialism with no capitals, which is more likely to be the case with on-screen keyboard users, and how likely someone using IBMTTS is to be encountering Freud's model. We should probably seek broader opinion on this, but to most Freud probably sounds like such a niche case that among general blind users it would favor the initialism. I would just hope this wouldn't spread to Apple's implementation, but it's not like they can't remove it if they do pull again.

@ultrasound1372 Honestly - and this is my personal opinion on the matter, it would be better to keep "id," fully lowercase, as is. There is a huge difference between spelling it uppercase and keeping it, by mistake, lowercase. But I'd be happy to have it altered either way via consensus.

saim here.

Message ID: @.***
com>

Anecdotally, I see a lot of the lowercase initialism on social media and in IMs. I agree that it's standard to capitalize initialisms in English, but in practice a lot of very common ones are written in lower case in informal writing. I think someone will be dissatisfied no matter what we choose, but the majority in this case is pretty obviously informal writers. It's not this dictionary's job to prescribe certain usages or spellings. Some are enforced as a consequence of avoiding specific conflicts, so if we're going to change it at all, I'd personally rather conflict with the few psychology students needing Freud's term than the large number of people writing lowercase "id" in informal contexts to mean identity document, identity, ident(ifier,) image description, etc. However, anyone spelling or reading it that way and using this dictionary up until this proposed change is probably used to hearing it as a word, so I don't see a great deal of damage done if we just don't fix what isn't broken. In summary: I'm all for changing it to accommodate the informal spelling of a very common word, but don't see a huge problem for the majority of users if we leave it alone.

So what's the decision on the lower case id? My personal opinion is I don't really mind keeping it no matter how it spells.

Please add YPT in to main.
thanks.

@GeorgeWu3 YPT was just added to Main.

I wonder if we can restore back this entry to main to be spelled out just in case if I encounter a text document or an Internet that has this lower case abbreviation please?
id	igh dee

Please add BYOD in to main to be Spelled out.

@GeorgeWu3 Thanks. BYOD was just added to main. But lowercase "id" can't be added - at least at this time.

Please add psrtutorial and Url in to main.
thanks.

I suppose, if consensus seems to favor the spelling of lowercase id, I'll withdraw my hesitance on that matter. There is even another pronunciation that could occur for it which you see in some synthesizers, pronounced like "I'd," likely arising from the same kind of writing that turns "I'm" into "im" on social media, due to on-screen keyboard users. I would not wish to favor that one though, in fact a case could be made for spelling "im" as well, as in instant message. That's a different discussion though.

@GeorgeWu3 What is psrtutorial supposed to be? PSR tutorial? Where is this encountered, and is it not spelled PSRTutorial?

There is a website is called psrtutorial.com and that is where I here that
PSR part of that Website has to be spelled.

Message ID: @.***
com>

@GeorgeWu3 I just took a look, and the website title is correct, displaying as PSR Tutorial.com or PSR Tutorial. As we don't correct websites unless they are mispronounced on webpages or in their titles, I don't think we can add it.

Please add VGA in to main.
thanks.

Please add VAD in to main.
thanks.

@GeorgeWu3 VGA is already in Main. It was added a long while ago.

@GeorgeWu3 VAD is also in Main. Please kindly check before making a request.


python311Packages.appthreat-vulnerability-db: 5.5.10 -> 5.6.0

Diff: https://github.com/AppThreat/vulnerability-db/compare/refs/tags/v5.5.10...v5.6.0
Changelog: https://github.com/AppThreat/vulnerability-db/releases/tag/v5.6.0
Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 285084 run on x86_64-linux 1

2 packages failed to build:

dep-scan
dep-scan.dist

4 packages built:

appthreat-depscan
appthreat-depscan.dist
python311Packages.appthreat-vulnerability-db
python311Packages.appthreat-vulnerability-db.dist

quart is already broken.


Improvements for Problem guideline (176)

We discovered that our current guideline about problem/json is interpreted somewhat differently (both between guild members, and by other developers in the company).
Some things to clarify (most related to each other):

[ ] 1. Is the problem object meant just for the client developers (for debugging purposes), or is it also intended to be used by client applications?

[ ]  1a. If the latter, only for display to a human (e.g. in an UI), or also for automatic processing decisions?

[ ] 2. What is the intended meaning of the type (+ title) member, compared to the status code?

[ ] 2a. Should the problem types be defined in your API? (How?) Should they be standardized across APIs?
[ ] 2b. Can clients rely on the type attribute?
[ ] 2c. Is this the same as an "error code"?

[ ] 3. What is the meaning of the instance field?

[ ] 3a. Does pointing to a specific occurrence of an error is meant to point to a code location, or to a set of input data or time when this error happened (e.g. via flow-ID)?
[ ] 3b. When is this needed/useful in addition to the type?

[ ] 4. For cases where a server application doesn't have more detailed error information, should fields (e.g. type + title) be filled with default values replicating the status code information, or just be left empty/missing?
[ ] 5. What are compatibility concerns for problem objects? Is it an incompatible change if in some specific situation now a different type value is returned?
[ ] 6. How can/should the problem object be extended?

[ ] 6a. Use the type as a discriminator for subtyping?
[ ] 6b. How can extended problems and generic ones coexist?

[ ] 7. Client robustness: Can clients rely on anything in the error object? If not, can they still use something?

(Also, if we are looking at this guideline: Fix the typo instant → instance in the first paragraph.)

I tried to dump a few thoughts on this without going through the whole discussion, so feel free to just skip over this and treat it as a brain dump. I'll try to go through the discussion and reconcile it with my thoughts in a bit :)

Is the problem object meant just for the client developers (for debugging purposes), or is it also intended to be used by client applications?

Currently the spec heavily leans towards it being for developers. I'd tend to mostly agree there. The errors the API returns likely have to be interpreted and provided with the right messaging in the right context for them to be useful when embedded into a frontend.
For apps facing a huge audience of diverse customers (e.g. Fashion Store), this seems critical and we should just display "Unknown error" + reference they can provide for debugging. For cases where the customer can actually do something about it, it should be a special case that looks at the Problem type and shows the appropriate localized in-context message.
For apps with a specific known audience, e.g. employees, displaying the title  + detail  + any other context directly is a lot easier and helps debugging. We're unlikely to localize this across many languages for a small set of users anyway.

1a. If the latter, only for display to a human (e.g. in an UI), or also for automatic processing decisions?

I'd say if there is an obvious automatic processing decision that can be taken (e.g. retry), the client can use type or status to make that decision, but it should not consider other fields.

What is the intended meaning of the type (+ title) member, compared to the status code?

type may be used to make automatic decisions in certain failure modes, title is an engineer-readable short version of type. They're application-specific status codes, while status should have the same meaning across all applications (as far as possible).

2a. Should the problem types be defined in your API? (How?) Should they be standardized across APIs?

I don't think they should be standardized across APIs and they don't necessarily need to be documented, unless they can/should be used for the automated decision making in the client. The different cases could be listed as different responses in the API spec, perhaps highlighting the type in the description?

2b. Can clients rely on the type attribute?

Yes, but I think in that case it should be documented in the API spec (or rather, vice versa), see 2a.

2c. Is this the same as an "error code"?

Yes. It's also good to differentiate between textual error codes and numerical error codes. type is only the same as the former.

What is the meaning of the instance field?

It seems difficult implement in many cases, but to me it seems like an identifier that points to a specific individual request error. E.g. type + a Flow ID + any other variable context.

3a. Does pointing to a specific occurrence of an error is meant to point to a code location, or to a set of input data or time when this error happened (e.g. via flow-ID)?

I understand it more as the latter. The former I'd capture as a custom message in detail that you can Ctrl+F to find. I don't know if you could reference code location without leaking a lot of implementation details to the client (it feels closer to dumping a stack trace, which goes against REST#177).

3b. When is this needed/useful in addition to the type?

It seems a bit of an edge case, but it might be useful for debugging specific requests (e.g. looking up matching logs or traces).

For cases where a server application doesn't have more detailed error information, should fields (e.g. type + title) be filled with default values replicating the status code information, or just be left empty/missing?

I think it's better to have a default fallback. It's not so bad for developers without one, but if you are exposing this to users e.g. for internal apps, you have to otherwise implement a fallback in the client, which is less ideal.
In fact, I think for some cases you should always have the default / static type, e.g. for internal server errors, as it seems very unlikely that the client could make automated decisions based on internal API state, but I might be missing something. type seems more for client errors.

What are compatibility concerns for problem objects? Is it an incompatible change if in some specific situation now a different type value is returned?

I'd say the API spec should be the deciding factor. If it's documented to return a specific type, it shouldn't change that behavior. Of course, in the real world it's a bit messier, so I would always try to keep type and status the same for the same class of problems. If they need to change, I'd treat it similarly to changing the status code.
The human readable messages (title , detail) should not be interpreted by clients, so they should be able to be changed without considering it to be a breaking change.

How can/should the problem object be extended?

Not sure. There are two extensions I can think of off the top of my head, not sure if the guidelines have anything on these.

Batch/bulk responses, what's the best way to provide multiple problems?
Hierarchical problems. I believe there are some internal services that return problems like this, but it doesn't seem to be codified in the spec.

6a. Use the type as a discriminator for subtyping?

That seems sensible, but I'd only do that if it's really needed to drive a business case as otherwise it can get complicated very quickly.

6b. How can extended problems and generic ones coexist?

I don't see a big problem here, it's the same as other API responses. All extensions should only add fields, not change existing ones. Then consumers of the problems either just handle the generic problems or have the code to handle specific ones too. Extra unhandled fields should be ignored as per the usual with JSON parsing.

Client robustness: Can clients rely on anything in the error object? If not, can they still use something?*

I think this is on a case-by-case basis. Other points already touch on this quite a bit.

2a: If the API designer knows what errors can happen, they should mention them in the API definition. This can be done by extending the problem object and adding an x-extensible-enum to the type property. (You'd still need to list the meanings in a description field, or point to some external documentation.)

That's a good way to list them! I'd go with descriptions first as just the types can be endpoint-specific and are probably hard to interpret out of context (just in the enum itself).

If you have a bunch of related APIs, using common types for related errors makes sense (and using different types for different errors makes even more sense) – this makes it easier for clients who relate to multiple APIs, as they now can share error handlers.

I'm finding it difficult to see cases of two APIs being so similar that they share the same errors and even further that the clients can respond to the errors in the same way across multiple APIs. I'd tread carefully here as it seems easy to make assumptions on error semantics leading to unexpected behavior (= incidents) later. Did you have some specific examples in mind here?

2b: Clients can not rely on the type property being there, or having just values which are known. There could always be some infrastructure component injecting errors, which doesn't know your problem types.

Yeah that's a good point, there should always be an "unknown error" fallback on the client-side as well to handle cases where you e.g. don't even get JSON. At the same time, it seems useful to also implement fallbacks in the application for common cases (e.g. internal errors), so that you get a little more detail.

If you don't have additional information to the status code, you can just omit the type (i.e. default it to about:blank) and title. A client can generate a generic error message when hitting an almost-empty problem object.

There are two cases.

Fallback type provided e.g. /problem/internal-error. This indicates to the client/user that we know that there was an error, but there's nothing you can do about it. In other words, the call failed successfully. 😅
Unknown error (no type). We don't even know what happened, maybe the call didn't even work.

I don't know if it makes sense to differentiate between them, but it might be useful for engineers at least?

Clients can use properties in the problem object (especially those which are documented in the specification), but they can't rely on them being there, or having specific values. In case a problem object doesn't have needed information, the client needs to fall back to some reasonable default behavior (similar as when there is an error without problem object).

I'm not sure what this means exactly. If the client can't rely on e.g. "wrong price" being returned when the "price" constraint fails to show the right localized error message, what's the point in even having type there in the first place? Of course it doesn't make sense to expect a specific call failing in a specific way, because if you do, why would you even make it? :)

My 2 cents on this issue:

The problem details are usually not described in the API and must be expected to change over time. As long as the API does not defined/enumerate values for typeand instance to signal the commitment to keep problem information stable and define a clear semantic, these should not be used by client applications to decide on actions.

If the semantic of the different values of type and instance is properly defined in the problem description, or the problem object states an explicit commitment to maintain the semantic, clients may make use of these fields to determine actions.

type values should be more specific than status codes to make best use of the problem information. However, since systems are often lacking a more detailed information when encountering an error, it is okay in my opinion to fallback on a status code name when a better definition is missing.

The types need only be defined in the API when the API wants to signal a commitment to maintain a stable error information that can be used by clients to derive actions.

The instance field should serve the purpose of defining a clear error instance from which the developer can derive the source location of the error and optionally also the call context of the error, i.e. the set of parameters relevant for the error. The latter may include the flow-id but should usually be more specific - if supported.

I agree with @SmilyOrg that blanking is a bad thing here since it requires clients/users to fill the semantic gap. So if no additional information is available these should be prefilled with status code specific fallback information.

If problem resource are specified sufficiently to declare a commitment on their stability, I think the same compatibility requirements as for regular resources are expected to hold.

I think, the idea of extended problems is to provide a distinct schema to express the context information of a specific error, that else would be aggregated by the instance and description fields to support a clearer (unified) semantic and to express the commitment to support certain client side actions. I would encourage to extend the problem and to provide more structured information whenever an API wants to make a commitment to provide a well defined stable error behavior..

As long as the problem is only specified generically, clients should not rely on anything and be aware that information may instantly change. The (extended) problem specification should clearly specify on what clients can rely.

@tfrauenstein I think you agreed a few month back to compile these suggestions into some kind of proposal.

hint: pls. see also API Guild Initial discussion from May and RFC discussion from September


FindwxWidgets: link with the new required libs under MSW

Latest wxWidgets git master version and the upcoming 3.1.1 release requires
linking with shlwapi and version DLLs. As this does no harm when using the
previous versions, just do it unconditionally.

Thanks!
Please see CONTRIBUTING.rst for the preferred contribution path and submit a MR to our GitLab instead.  You can still use GitHub OAuth if desired.

Sorry for not noticing this, replaced with https://gitlab.kitware.com/cmake/cmake/merge_requests/676


Allow /quitquitquit on localhost only

For https://github.com/istio/istio/issues/15041
WIP because I am adding tests still
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[x] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: howardjohn
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

pilot/OWNERS [howardjohn]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: fpesce, howardjohn
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

pilot/OWNERS [howardjohn]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@howardjohn: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/integ-new-installer-k8s-presubmit-tests.sh
0550d5936f1edff4538257a82550f5991dd2d764
link
/test integ-new-install-k8s-presubmit-tests-master

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@howardjohn: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/integ-new-installer-k8s-presubmit-tests.sh
0550d5936f1edff4538257a82550f5991dd2d764
link
/test integ-new-install-k8s-presubmit-tests-master

prow/integ-mixer-k8s-presubmit-tests.sh
0550d5936f1edff4538257a82550f5991dd2d764
link
/test integ-mixer-k8s-presubmit-tests-master

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

New changes are detected. LGTM label has been removed.

@howardjohn: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/integ-new-installer-k8s-presubmit-tests.sh
0550d5936f1edff4538257a82550f5991dd2d764
link
/test integ-new-install-k8s-presubmit-tests-master

prow/integ-mixer-k8s-presubmit-tests.sh
0550d5936f1edff4538257a82550f5991dd2d764
link
/test integ-mixer-k8s-presubmit-tests-master

prow/istio-lint.sh
49c3d62cfe94baae62ccbd7e6b3263a9eabd1033
link
/test istio-lint-master

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/lgtm

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: fpesce, howardjohn
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

pilot/OWNERS [howardjohn]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@howardjohn: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/integ-mixer-k8s-presubmit-tests.sh
0550d5936f1edff4538257a82550f5991dd2d764
link
/test integ-mixer-k8s-presubmit-tests-master

prow/integ-new-installer-k8s-presubmit-tests.sh
4d91f0b6cb5aacb0eef05f4f68ab59f233b229b9
link
/test integ-new-install-k8s-presubmit-tests-master

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

New changes are detected. LGTM label has been removed.

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: fpesce, howardjohn, yangminzhu
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

pilot/OWNERS [howardjohn]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@howardjohn: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/integ-mixer-k8s-presubmit-tests.sh
0550d5936f1edff4538257a82550f5991dd2d764
link
/test integ-mixer-k8s-presubmit-tests-master

prow/integ-new-installer-k8s-presubmit-tests.sh
9763438ac990e175c2140346c0fad34ec05e1d3e
link
/test integ-new-install-k8s-presubmit-tests-master

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@howardjohn: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/integ-mixer-k8s-presubmit-tests.sh
0550d5936f1edff4538257a82550f5991dd2d764
link
/test integ-mixer-k8s-presubmit-tests-master

prow/integ-new-installer-k8s-presubmit-tests.sh
9763438ac990e175c2140346c0fad34ec05e1d3e
link
/test integ-new-install-k8s-presubmit-tests-master

prow/racetest.sh
9763438ac990e175c2140346c0fad34ec05e1d3e
link
/test istio-racetest-master

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test istio-racetest-master

@howardjohn: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/integ-new-installer-k8s-presubmit-tests.sh
9763438ac990e175c2140346c0fad34ec05e1d3e
link
/test integ-new-install-k8s-presubmit-tests-master

prow/racetest.sh
9763438ac990e175c2140346c0fad34ec05e1d3e
link
/test istio-racetest-master

prow/integ-mixer-k8s-presubmit-tests.sh
9763438ac990e175c2140346c0fad34ec05e1d3e
link
/test integ-mixer-k8s-presubmit-tests-master

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


The bayonet on Kardashev-Mosin is now a worker

The bayonet on Kardashev-Mosin is now a worker

About the PR

Why / Balance

Technical details

Media

[ ] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Breaking changes

Changelog

no way!


Error for DMing a user is uncaught in verification

Sentry Issue: BOT-8Z
As can be seen below, Discord returns a 400 with a specific code rather than a 403 forbidden. Currently, verification attempts to catch this by suppressing a 403 rather than a 400.
HTTPException: 400 Bad Request (error code: 50007): Cannot send messages to this user
(1 additional frame(s) were not displayed)
...
  File "bot/cogs/verification.py", line 503, in on_member_join
    await member.send(ON_JOIN_MESSAGE)
  File "discord/abc.py", line 850, in send
    channel = await self._get_channel()
  File "discord/member.py", line 243, in _get_channel
    ch = await self.create_dm()
  File "discord/user.py", line 715, in create_dm
    data = await state.http.start_private_message(self.id)
  File "discord/http.py", line 245, in request
    raise HTTPException(r, data)

Unhandled exception in on_member_join.

Hmm, I guess let's just suppress discord.HTTPException then if you're cool with that.

That feels too broad. You could catch it and only suppress if it has that specific error code.


chore(package): update rollup to version 1.26.3

:tada: This PR is included in version 2.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Enable circleci testing

Description
Enable circleci testing on new orb
Issues Resolved
[List any existing issues this PR resolves]
Check List

[ ] All tests pass. See https://github.com/sous-chefs/apache2/blob/master/TESTING.md
[ ] New functionality includes testing.
[ ] New functionality has been documented in the README if applicable

          1 Error

:no_entry_sign:
Please include a CHANGELOG entry.

  Generated by :no_entry_sign: Danger

Cool, markdown lint is working again . it's found some errors

@damacus can you admin this one in please?


Block-Specific Multicall

Is it possible to pass a block parameter to the multicall in order to execute queries at that specific block height?
In Ethers, a single query can be executed with a blocktag ({ blockTag: blockNumber }) in order to accomplish this.
Having similar functionality on multicalls would be incredible.

I have created this PR to do this as I needed it too.
https://github.com/joshstevens19/ethereum-multicall/pull/39

Merged above will deploy tomorrow! 👏👏


Release/1.0.3

Fix docs action (close #367)
Update on_success docstring (close #358)
Add py.typed to package (close #360) (Thanks to @edgarrmondragon)
Update typing (#364)
Fix PagePing, PageView, and StructuredEvent property getters (close #361)

coverage: 96.619% (+0.7%) from 95.946%
when pulling ba24c288ffb2837c1e5224fe7edf7dfe86e75584 on release/1.0.3
into cb7e434be13af1f5dfe5b6b3416d062c477f8de1 on master.


python311Packages.gios: 3.1.0 -> 3.2.0

Diff: https://github.com/bieniu/gios/compare/refs/tags/3.1.0...3.2.0
Changelog: https://github.com/bieniu/gios/releases/tag/3.2.0
Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 263407 run on x86_64-linux 1

5 packages built:

home-assistant-component-tests.gios
python310Packages.gios
python310Packages.gios.dist
python311Packages.gios
python311Packages.gios.dist


Chapter 1 - no snowflake

For the InDB example there is no snowflake database in your repo.

Hey @Sivivatu !
can you please help @dkinneyBU ?

HI @dkinneyBU, The snowflake database is part of the snowflake sample data. Once you have created an (account)[https://signup.snowflake.com/] (you can use a trial with $400 of credits), you will have access to the table SNOWFLAKE_SAMPLE_DATA.TPCDS_SF10TCL.STORE_RETURN.


Constraints visualization

(Sorry, I had to delete my repo and recreate this pull request. Here it is again.)
Originally by @jihoonl. Some nits by @wohe from #337 have been addressed. Some haven't (e.g. https://github.com/googlecartographer/cartographer_ros/pull/337#discussion_r117281636 & https://github.com/googlecartographer/cartographer_ros/pull/337#discussion_r117281982, https://github.com/googlecartographer/cartographer_ros/pull/337#discussion_r117280199). Disclaimer: I have only updated @jihoonl's code so that it compiles with regards to API changes, without giving much thought what it actually does. :)

This should probably be refactored so it uses a single LINE_LIST marker instead of creating a marker for each constraint, which is very slow. Perhaps, for intra constraints, the new coloring system could be used to color contraints differently for each submap.

Sorry, I did not read your comments first. Yes, I agree.

@ojura Friendly ping. You're not blocked by anyone, right?

Hi, sorry, I had some other stuff going on (and spent the bigger part of the last week fixing CMake build errors). I definitely have finishing this on my todo list for this week. If anyone wants to collaborate, feel free to post here or to send me a pull request.

You're not blocked by anyone, right?

I am not sure what you mean :)

No problem and no need to hurry. I just wanted to make sure you are not waiting on anyone else to do something before you can continue.

@ojura , @Mofef wanted to create a PR #400 for your fork(larics:constraints_visualization). But, somehow, he couldn't create a PR against your repo. Can you apply the changes in #400 in your branch? then we will close #400.

Now it's working again same as before. Putting everything inside a single marker and coloring is not yet done.

Hello everyone (@wohe @Mofef @jihoonl), please have a look. I completed the refactoring and added coloring. Everything is now published on a single topic, but in separate namespaces, so you can still disable everything.
For intra constraints, I added different coloring for different submaps, while the residuals are now bright red. For inter constraints, I retained Magazino's fixed bright yellow/teal color scheme.

By the way, it seems the pixel bleaching code in shaders of the Submaps plugin sometimes clashes with rviz's rendering, which affects the LINE_LIST marker - especially in places where more that 2 submaps are overlaid.
https://www.youtube.com/watch?v=_XMGt5iYzdI
Notice how it affects the grid too.

I believe it's ready for merging, I have mostly addressed the nits (and the rest is a compromise :-). Please merge #402 first.

@wohe, here's some art :-)
http://free.iiifhosting.com/iiif/8cf6f3eea5aa729a5551ab535c75fce49e6a7d71fde965e4f43550d89efe8741/

I have two minor questions for the reviewer:

is it okay to use const auto& with e.g.  GetAllSubmapData() and the rest
should I add here multiplication with node.constant_data->tracking_to_pose).translation() like here?

I have just rebased on top of merged #402. Also, if you're having z-fighting-alike rendering bugs like in the video I linked above, I found that recompiling rviz with the change I described in this comment helped.

Regarding the other question: Since we now only publish the translational part it does not matter. The transform I suggested adding is between yaw-only xy plane aligned frame and the full orientation. If you leave it out, the orientation will not be correct. In case you want to add it: it is needed for both the constraint pose and the trajectory node pose. You could also just add a comment why it is not needed here.

In that case, would it make sense to remove it from GetTrajectoryNodeList() as well, because we are taking only the translational part there too? That would make things consistent. Plus, I can add a comment why it's left out.

Sounds good.

Done.

Thanks, I'll merge as soon as the tests passed.


Doesn't base provider implement DECODER operation?

In the documentation about base provider in section about implemented operations it states that only Asymmetric Key Encoder is implemented.
That kind of deviates from the naming convention since only ENCODER and DECODER operations exist. But that is not my point.
Since OpenSSL is able to load a DER or PEM encoded certificates don't the base and default providers implement both ENCODER and DECODER contrary to just ENCODER operation as stated in the manual pages for both the base provider and the default provider?

The base provider implements decoders too.

marking as inactive, will be closed at the completion of 3.4 dev without further input


Windows Hello integration w/ sudo

Is your feature request related to a problem? Please describe.
I think that the main power point of WSL is its seamless integration with Windows. Integrating sudo tasks with WSL would go a long way towards this.
Describe the solution you'd like
Something like WSL Hello Sudo - which seems to be pretty easy and safe to implement.
Describe alternatives you've considered
The mentioned above WSL Hello Sudo

The ask is effectively repeat #285.


Added timeout after animation

This fixes an issue where spam clicking the next or prev button will cause a breakage of animation if there are no slides left to animate to.

http://forum.metroui.org.ua/viewtopic.php?id=69


Remove unused senders and schemas

Problem statement
Some senders and/or schemas are not currently being used. In an effort to improve clarity in the code base and configuration where possible, those un-used items should be removed.
An example would be the sender all-in-one-health-ca. That sender no longer submits data directly to RS but the schema is still present in the master branch and the sender is present in staging and production settings.
Acceptance criteria

[ ] Only schemas actively used are present in the master branch
[ ] Only senders actively sending data are present in staging and production settings

To do

[ ] Query metabase to identify any in-active senders. Inactive would be senders that have not submitted data in 30 days
[ ] Query settings to identify all schemas that are currently being used by active senders. Remove schemas that are not in that list

most_recent_send_dates_2023-05-25T21_10_24.955553Z.csv
schemas_and_last_use_date_2023-05-25T21_00_05.059039Z.csv
Ran queries to find senders (pulled from Settings table) and their most recent send dates (pulled from Report File table)
select senders.org, senders.sender, max(report_file.created_at) most_recent_file
from (select o."name" org, s."name" sender
    from setting s
    join setting o
    on s."organization_id" = o."setting_id"
    where s."type" = 'SENDER') senders
left join report_file
on senders.org = report_file.sending_org
    AND senders.sender = report_file.sending_org_client
group by senders.org, senders.sender
order by most_recent_file asc;

as well as schemas with their most recent use date (from Report File table)
select schema_name, max(created_at) most_recent_use
from report_file
group by schema_name
order by most_recent_use asc;

@adegolier any updates on this ticket?

Modified the query to pull senders that are

Set as active
Have not sent any files in the past 90 days (We decided 90 days was a better measure)
Had their settings created more than 30 days ago (to hopefully prevent shutting down any that are being onboarded or are recently onboarded and have not yet sent files

This resulted in the following list:
find_unused_senders_that_are_still_listed_as__active__2023-07-11T14_42_06.039819Z.csv

@adegolier following up on Sharon's request above. Is it possible to do what she is asking?

I'm unclear on what is even being asked because I'm not sure what the "other" column represents. I didn't provide any schemas, only the inactive senders. Those don't look like the names of schemas to me.

@sliu1000 Did you reach out to all these senders and the ones you said no on are saying they're still going to send us data?
@LaFreda1 I don't understand the point of moving them somewhere else. My understanding was that the intent of this ticket was to remove things that are not being used. If we want to leave them, I think we should just leave them instead of putting them somewhere else.

@victor-chaparro What do you think? should we mark the unused schemas as deprecated at least?

@sliu1000 @adegolier  I do think it's a good idea to archive them, just in case we ever need them again. If we decide to onboard these senders to the UP it will be useful to know what settings they had. We can create an archive folder under schemas to move them there to clean things up.

Okay, this ticket is getting a lot bigger if I'm expected to build an archiving feature for settings. Can somebody please clarify what we want to do with this because it sounds like I've already ruined it.

@adegolier You don't need to build an archiving feature. Instead of hard deleting the files we just need to move them to an archive folder. Have you started deleting the files? Let me know if you wanna pair on this, I should be able to help with this.

@victor-chaparro As far as I'm aware, the settings are in the database, which, maybe Postgres has some folder feature that I'm not aware of, but as far as I know that doesn't exist. We has previously established that I was to provide Sharon with a list of Senders that had not sent us anything in the past 30 days, she or her team was to reach out to them and ask them if they intended to continue sending to us or not, which I was under the impression that that was what the screenshot of the list she provided was, so I went through and deleted them.

@victor-chaparro That goes back to building an archiving feature since that doesn't currently exist. If "archive" would cause it to not show on the front end, I am unclear how this differs from the delete feature (considering that records of every change to settings are in the database, and there is an "is deleted" column that marks things as having been deleted, while keeping them in the database). If it continues to show on the front end, I am unclear what the point of "archiving" is.

@adegolier The idea is to not "hard delete" these settings, I wasn't aware we had a soft delete feature which is what we should do. We just want to keep the settings in case we ever need to go back and onboard these receivers/senders and not have to start from scratch. I think Sharon's main concern were the schemas and not the settings, do you think moving un-used schemas to an archive folder is doable?

@victor-chaparro I mean, yes, it's easy to move things from one folder to another. It's more a matter of is there a point in doing that? Is anybody going to be able to find them or remember where they are if, for some reason, we need them in the future? Is being able to retrieve things that had previously been deleted not part of the point of version control?

@adegolier Its just standard protocol for document management.  We want to keep and not delete those schemas.  However, moving those schemas to an archive folder makes it clear that it was once used but no longer used from a process perspective.

@adegolier Is Github the repository you are referring to?  @victor-chaparro Are you aware of any code archiving processes? I think in the past I've seen people just add (deprecated in the file name??) not sure what the proper code archiving process is.

@sliu1000 @adegolier We normally don't archive code because we have version control for that, but these are not code files. I think deleting them will be hard for someone to look in the version control history if we decide we need them again. If we move them to an archive folder and decide to onboard these senders again doing a quick search in the repo will make it easy to find them and not start from scratch.

Personally I don't see a point in archiving them if we think we're still going to use them in the future. Is there really a reason to not keep them where they are if we think we might need them? If yes, please tell me where to put them, and I'll try to do another pass at making sure there aren't any existing settings using those schema so we don't get deluged with errors.

Honestly, we are going to deprecate the covid schemas completely after we migrate everybody to the UP. But, it would be useful to know which schemas are not being used to better assess which schema settings we need to support in the UP. So, it's up to you if you want to move them somewhere or mark them as deprecated.


Missing ability to see activity definition before adding to the plan

nsims
https://jira.jpl.nasa.gov/browse/AERIEQS-362
Low
IOTs need to be able to look at what they are adding in detail to make sure it is the set of commands that they were expecting and to confirm that they aren't adding activities in an order that could cause harm.

Related to https://github.com/NASA-AMMOS/aerie-ui/issues/589


Added namespaced field into kubernetes oam definition.metadata

Signed-off-by: ashish<EMAIL_ADDRESS>Description
Adds namespaced field in metadata of definitions for kubernetes components to differentiate between api resources which are namespaced vs which are not

This PR fixes #
Notes for Reviewers
Signed commits

[x] Yes, I signed my commits.

Codecov Report

Merging #5447 (32bdcfa) into master (4c5831d) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #5447   +/-   ##
=======================================
  Coverage   13.11%   13.11%
=======================================
  Files         107      107
  Lines        9961     9961
=======================================
  Hits         1306     1306
  Misses       8378     8378
  Partials      277      277

Flag
Coverage Δ

unittests
13.11% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

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 4350cd6...32bdcfa. Read the comment docs.

Lint check issue on capitalization of variable name.


Add admin user to cryocloud hub

Based on request by @tsnow03

Self merging, as it's just an admin list update: https://infrastructure.2i2c.org/en/latest/contributing/code-review.html#changing-active-infrastructure-in-general


[id] Replace deprecated fullversion shortcode #41485

Fixes https://github.com/kubernetes/website/issues/41485
There doesn't seem to be a localization branch for in, so I'm using main instead.

Related to https://github.com/kubernetes/website/issues/41005

/area localization

/remove-language ja

/lgtm

/approve

Hi @kubernetes/sig-docs-id-owners
I am one of the SIG-Docs localization subproject leads.
PTAL this PR and please let us know current status of Indonesian localization activities these days. I hope to know health status of localization (slack message: https://kubernetes.slack.com/archives/CJ1LUCUHM/p1689096931939129)

Thanks for following this up @seokho-son


Not parsing daily notes in nested folders

Version 1.4.4
In my use case of daily notes, I like to file my daily notes into folders organized by month but the current calendar plugin doesn't visualize daily notes in those folders.

When I click on an existing daily note, It throws this error:

So far the plugin works for notes in the root dailies folder, so I can still see the current month, but fixing this would be greatly appreciated.

Oh I realized this was already created by someone else, I'll close this issue for now.


Error publishing in a Azure slot

Hi
When I have tried to deploy my Aurelia project to the slot I got this error. yesterday this worked well.
Action: appService.DeploySlot
Error type: object
Error Message: An error has occurred.
Version: 0.16.0
OS: darwin
Product: Visual Studio Code
Product Version: 1.39.2
Language: es

Call Stack
extension.bundle.js:323:409148
extension.bundle.js:218:111699
extension.bundle.js:157:26069
extension.bundle.js:157:27311
extension.bundle.js:164:7075
extension.bundle.js:157:24982
extension.bundle.js:1:576782
extension.bundle.js:194:5449
events.js:182:13
extension.bundle.js:194:18309
events.js:187:15
extension.bundle.js:194:17141
events.js:273:13
events.js:187:15
_stream_readable.js:1092:12
next_tick.js:63:19

Hi @kintela
Thanks for reporting.
Is this still recurring?  Sometimes Azure has outages and random errors will occur.  Please try again and let me know if it's still happening.  In that case, please leave repro steps as well.

Nos works fine thanks
El jue., 31 oct. 2019 19:29, Nathan<EMAIL_ADDRESS>escribió:

Hi @kintela https://github.com/kintela
Thanks for reporting.
Is this still recurring? Sometimes Azure has outages and random errors
will occur. Please try again and let me know if it's still happening. In
that case, please leave repro steps as well.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode-azureappservice/issues/1256?email_source=notifications&email_token=ACMYDUVBYF6TWNN47GPLEKTQRMPXNA5CNFSM4JFD4QC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECYZPWY#issuecomment-548509659,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACMYDUWFJE4ES5MM4Q6RJ73QRMPXNANCNFSM4JFD4QCQ
.


@mzikherman updates to overlay

center the content on the overlay and fade out the dropshadow with the content on the dropdown
https://github.com/artsy/force/issues/688

ooo nice!! Thank youu


Update dataset.py

Bug fixes

Hey @RoseString,
Thanks for fixing this bug by replacing exend with extend!
May I ask you, out of interest, why you decided to replace the read._replace() method with the replace() function?

Thanks @RoseString!

May I ask you, out of interest, why you decided to replace the read._replace() method with the replace() function?

I think because it was broken: The Read class used to be a namedtuple and the way to create a new instance with a replaced value for those is to use the _replace method. When I changed Read to a dataclass, it seems I did not catch the use of _replace. For dataclasses, the correspoding functionality is available via dataclasses.replace as done here.


mainnet-ignition-v0.20.1 not syncing headers to 100%

 My mainnet CPU wallet isn't completing the sync. I was running an old version so upgraded to v0.20.1 and still the same issue. I read the above note but don't know how to runn memtest or linpack. Please advise as to a fix for my wallet or how to run above suggestions.
Expected behavior
 Wallet to sync to 100% in order to utilize my qtum tokens
Actual behavior

To reproduce
 Every time I open my wallet it happens
System information
 v0.20.1, got it from github
 windows 8.1/toshiba laptop
windows 8.1
 It worked for a while, I didn't open the wallet for a couple days and when I went in it hasn't been able to sync to 100%

If your wallet gets stuck syncing the blockchain the best thing to do is exit the wallet, delete the local blockchain and resync the whole thing.
Make sure your have a good backup of the wallet, then exit the wallet, and in the Qtum data directory, delete the folders blocks, chainstate and stateQtum. Then restart the wallet.


[FLINK-26033][BP-1.14][flink-connector-kafka]Fix the problem that robin does not take effect due to upgrading kafka client to 2.4.1 since Flink1.11

What is the purpose of the change
The behavior of DefaultPartitioner has been changed from round robin to sticky partitioner from Kafka 2.4.0 (See KIP-480). So it does not take effect since Flink 1.11 that we bumped Kafka client version to 2.4.1.
Brief change log

Added two classes org.apache.flink.streaming.connectors.kafka.partitioner.FlinkRoundRobinPartitioner and org.apache.flink.streaming.connectors.kafka.FlinkRoundRobinPartitionerTest to the flink kafka connector
Modified the KafkaConnectorOptionsUtil::getFlinkKafkaPartitioner method, set default and round-robin separately

Verifying this change
This change added tests and can be verified as follows:

Assume there are 2 sinks, 5 kafka partitions.
The actual situation is that each sink will round-robin on the 5 partitions

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (no)
The serializers: (no)
The runtime per-record code paths (performance sensitive): (no)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: (no)
The S3 file system connector: (no)

Documentation

Does this pull request introduce a new feature? (no)

PatrickRen  Could you take time to review it ?

There seems to be no JUnit 5 in release-1.14，so I'm going to switch back to JUnit 4.  same for release-1.13

Closing since 1.14 is no longer supported


Testing & demo counts discrepancy

Hello,
I wanted to check if the way of processing the testing and demo video/image can rise to difference results for the same image and the same model? Let's say one of images in the dataset is picked along with it's h5 file and running it give a pred value and the same image fed to demo script gives out a different prediction count and the difference is quite huge
Anything that's being missed here or to take note of ?
Thank you!

The image resolution or make sure the pre-trained model has been successfully loaded


AWSExecutor class implementation

Acceptance Criteria

[ ] Implement AWSExecutor class as per Design Details
[ ] Add docstring for AWSExecutor class
[ ] Add unit tests for AWSExecutor class

Design Details (AWSExecutor class)
The AWSExecutor is a type of remote executor, so it inherits from RemoteExecutor.  This class contains authentication handling.

Class attributes:

region — Region in which the task will run
s3_bucket_name — An alias for the super-class’s remote_cache
profile — IAM profile used to run the task
execution_role — Name of an IAM role assumed by a task (optional)
log_group_name — Name of the log group in Amazon CloudWatch (optional)

Class methods:

_validate_credentials — Validate user credentials (sometimes called _get_aws_account currently) using aws sts get-caller-identity

Current plugins which can inherit from this class: EC2, ECS, Batch, Lambda, Braket [Note: EC2 inherits from both AWSExecutor and also from SSHExecutor]

In the end, we want to put this class, as well as all AWS plugins, inside a repository called covalent-aws-plugins (i.e. the AWS plugin monorepo).  Each plugin should remain individually installable as well.

Duplicate of https://github.com/AgnostiqHQ/covalent-aws-plugins/issues/1


flit dont' like when modules have no docs.

$flit wheel
Fetching list of valid trove classifiers                          I-flit.inifile
Starting new HTTPS connection (1): pypi.python.org  I-requests.packages.urllib3.connectionpool
Traceback (most recent call last):
  File "/usr/local/bin/flit", line 11, in <module>
    sys.exit(main())
  File "/Users/bussonniermatthias/Library/Python/3.5/lib/python/site-packages/flit/__init__.py", line 57, in main
    verify_metadata=args.verify_metadata).build()
  File "/Users/bussonniermatthias/Library/Python/3.5/lib/python/site-packages/flit/wheel.py", line 31, in __init__
    self.metadata = common.make_metadata(self.module, self.ini_info)
  File "/Users/bussonniermatthias/Library/Python/3.5/lib/python/site-packages/flit/common.py", line 148, in make_metadata
    md_dict.update(get_info_from_module(module))
  File "/Users/bussonniermatthias/Library/Python/3.5/lib/python/site-packages/flit/common.py", line 38, in get_info_from_module
    docstring_lines = m.__doc__.splitlines()
AttributeError: 'NoneType' object has no attribute 'splitlines'

Quite deliberately - the README says: "Make sure that foobar’s docstring starts with a one-line summary of what the module is, and that it has a version"
In both cases, the error should be more explanatory, though.

closed by #16


Replace HighCharts with ChartJS

HighCharts is freely available for non-commercial use but it has been requests by multiple users that a truly open-source charting library be the default.  ChartJS is the most popular and equivalent option at this time and has been selected as the preferred solution.  ChartJS also uses the MIT open-source license making it compatible with all of the OceanDataTools projects.
The goal of this migration is to replicate as much as possible the current charting functionality using ChartJS.

Released in v2.7.0


CosmosDB - Locations field missing from model

It seems the properties.locations field is not in the model
https://github.com/Azure/azure-sdk-for-python/blob/master/sdk/cosmos/azure-mgmt-cosmosdb/azure/mgmt/cosmosdb/models/database_account.py
However it is required to update the account:
https://docs.microsoft.com/en-us/rest/api/cosmos-db-resource-provider/databaseaccounts/createorupdate#request-body
The field comes across in the HTTP response from a GET just fine, it is just lost in deserialization.
This seem to make it hard for me to update a CosmosDB account (e.g. change a firewall) as the API does not appear to fully support PATCH (only for tags?) and I can't get the data I need to do acreate or update.
What am I missing here?
@shurd as you handled a similar issue :)

The CreateOrUpdate method actually takes a DatabaseAccountCreateUpdateParameters instance.

Yeah so that model requires locations which is missing from your swagger for GET (and thus the database_account model), so I can't fill out locations to successfully make an update call.
Ideally I'd PATCH so I did not have to provide a locations, but the PATCH API is also not  implemented and only supports tags.
It looks like the Azure CLI just manually hacks the readLocations into locations since the invalid model loses the locations during deserialization.
Seems like in current situation you can't really programmatically update the account without some trickery that may or may not be safe.

This appears to be the incorrect swagger file responsible for bad models when retrieving current state
https://github.com/Azure/azure-rest-api-specs/blob/master/specification/cosmos-db/resource-manager/Microsoft.DocumentDB/stable/2015-04-08/cosmos-db.json#L4272
Locations comes back in the HTTP response, but isn't accessible via SDK.

This is the best I've come up with to try to update an account
(I'm using the raw dictionary here instead of the model, but the same applies either way)
I'm concerned this isn't safe?   Could readLocations be different than locations?
        resource = *GET THE ACCOUNT RESOURCE FROM CLIENT AS_DICT*

        resource['properties']['locations'] = []

        for loc in resource['properties'].get('readLocations'):
            resource['properties']['locations'].append(
                {'location_name': loc['locationName'],
                 'failover_priority': loc['failoverPriority'],
                 'is_zone_redundant': loc.get('isZoneRedundant', False)})

        # Update resource
        self.client.database_accounts.create_or_update(
            resource['resourceGroup'],
            resource['name'],
            create_update_parameters=resource
        )

Hi @stefangordon thank you for raising this issue. Every region on an account is a readable location, so you can use these from the GET response to form an update request. The code snippet you provided looks to be correct.
Right now, our PATCH request only supports updating tags as this behavior is required by ARM. We are currently working on supporting PATCH for all properties on the account.

And if Locations actually is returned, then the swagger should probably be updated to reflect this fact.

We will include locations in the next swagger update, which is expected in the next two weeks. We are tracking this internally as work item 509483.


problem to recieve metrics

Hi
I have problem to get metrics from my fortigate fw
I only see this kind of metrics.
Container running I see this log message:
What I´m I missing?
Regards
Daniel
2023/05/03 21:28:37 Loaded 1 API keys
2023/05/03 21:28:37 Fortigate exporter running, listening on ":9710"
HELP go_gc_duration_seconds A summary of the pause duration of garbage collection cycles.
TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0"} 0
go_gc_duration_seconds{quantile="0.25"} 0
go_gc_duration_seconds{quantile="0.5"} 0
go_gc_duration_seconds{quantile="0.75"} 0
go_gc_duration_seconds{quantile="1"} 0
go_gc_duration_seconds_sum 0
go_gc_duration_seconds_count 0
HELP go_goroutines Number of goroutines that currently exist.
TYPE go_goroutines gauge
go_goroutines 10
HELP go_info Information about the Go environment.
TYPE go_info gauge
go_info{version="go1.15.4"} 1
HELP go_memstats_alloc_bytes Number of bytes allocated and still in use.
TYPE go_memstats_alloc_bytes gauge
go_memstats_alloc_bytes 1.650808e+06
HELP go_memstats_alloc_bytes_total Total number of bytes allocated, even if freed.
TYPE go_memstats_alloc_bytes_total counter
go_memstats_alloc_bytes_total 1.650808e+06
HELP go_memstats_buck_hash_sys_bytes Number of bytes used by the profiling bucket hash table.
TYPE go_memstats_buck_hash_sys_bytes gauge
go_memstats_buck_hash_sys_bytes 1.44482e+06
HELP go_memstats_frees_total Total number of frees.
TYPE go_memstats_frees_total counter
go_memstats_frees_total 237
HELP go_memstats_gc_cpu_fraction The fraction of this program's available CPU time used by the GC since the program started.
TYPE go_memstats_gc_cpu_fraction gauge
go_memstats_gc_cpu_fraction 0
HELP go_memstats_gc_sys_bytes Number of bytes used for garbage collection system metadata.
TYPE go_memstats_gc_sys_bytes gauge
go_memstats_gc_sys_bytes 3.992976e+06
HELP go_memstats_heap_alloc_bytes Number of heap bytes allocated and still in use.
TYPE go_memstats_heap_alloc_bytes gauge
go_memstats_heap_alloc_bytes 1.650808e+06
HELP go_memstats_heap_idle_bytes Number of heap bytes waiting to be used.
TYPE go_memstats_heap_idle_bytes gauge
go_memstats_heap_idle_bytes 6.4167936e+07
HELP go_memstats_heap_inuse_bytes Number of heap bytes that are in use.
TYPE go_memstats_heap_inuse_bytes gauge
go_memstats_heap_inuse_bytes 2.58048e+06
HELP go_memstats_heap_objects Number of allocated objects.
TYPE go_memstats_heap_objects gauge
go_memstats_heap_objects 3293
HELP go_memstats_heap_released_bytes Number of heap bytes released to OS.
TYPE go_memstats_heap_released_bytes gauge
go_memstats_heap_released_bytes 6.4167936e+07
HELP go_memstats_heap_sys_bytes Number of heap bytes obtained from system.
TYPE go_memstats_heap_sys_bytes gauge
go_memstats_heap_sys_bytes 6.6748416e+07
HELP go_memstats_last_gc_time_seconds Number of seconds since 1970 of last garbage collection.
TYPE go_memstats_last_gc_time_seconds gauge
go_memstats_last_gc_time_seconds 0
HELP go_memstats_lookups_total Total number of pointer lookups.
TYPE go_memstats_lookups_total counter
go_memstats_lookups_total 0
HELP go_memstats_mallocs_total Total number of mallocs.
TYPE go_memstats_mallocs_total counter
go_memstats_mallocs_total 3530
HELP go_memstats_mcache_inuse_bytes Number of bytes in use by mcache structures.
TYPE go_memstats_mcache_inuse_bytes gauge
go_memstats_mcache_inuse_bytes 3472
HELP go_memstats_mcache_sys_bytes Number of bytes used for mcache structures obtained from system.
TYPE go_memstats_mcache_sys_bytes gauge
go_memstats_mcache_sys_bytes 16384
HELP go_memstats_mspan_inuse_bytes Number of bytes in use by mspan structures.
TYPE go_memstats_mspan_inuse_bytes gauge
go_memstats_mspan_inuse_bytes 36856
HELP go_memstats_mspan_sys_bytes Number of bytes used for mspan structures obtained from system.
TYPE go_memstats_mspan_sys_bytes gauge
go_memstats_mspan_sys_bytes 49152
HELP go_memstats_next_gc_bytes Number of heap bytes when next garbage collection will take place.
TYPE go_memstats_next_gc_bytes gauge
go_memstats_next_gc_bytes 4.473924e+06

Hi! Check https://github.com/bluecmd/fortigate_exporter#prometheus-configuration

Hi, thanks for your answer. But I don't see any metrics with name fortigate when I surf against my container/metrics.
So I guess something is wrong?
Daniel

I only  see go metrics.

@DanielJohansson1976 you should use the /probe endpoint not /metrics https://github.com/bluecmd/fortigate_exporter#prometheus-configuration

Thanks, Now I recieve this:
curl 'https://fortigate_exporter.sds.io/probe?target=https://fortigate.sds.io&token=xxxxx&profile=fortigate'
HELP probe_duration_seconds How many seconds the probe took to complete
TYPE probe_duration_seconds gauge
probe_duration_seconds 0.041923755
HELP probe_success Whether or not the probe succeeded
TYPE probe_success gauge
probe_success 0
Any more tips?
Thanks for your help.

2023/05/04 15:02:06 Loaded 2 API keys
2023/05/04 15:02:06 Fortigate exporter running, listening on ":9710"
2023/05/04 15:03:12 Probe request rejected; error is: No API authentication registered for "https://fortigate.XXXX.io"
2023/05/04 15:03:30 Error: Response code was 404, expected 200
2023/05/04 15:03:30 Probe of "https://<IP_ADDRESS>" failed, took 0.186 seconds
2023/05/04 15:05:33 Error: Response code was 404, expected 200
2023/05/04 15:05:33 Probe of "https://<IP_ADDRESS>" failed, took 0.181 seconds
HELP fortigate_cpu_usage_ratio Current resource usage ratio of system CPU, per core
TYPE fortigate_cpu_usage_ratio gauge
fortigate_cpu_usage_ratio{processor="0"} 0
fortigate_cpu_usage_ratio{processor="1"} 0
fortigate_cpu_usage_ratio{processor="2"} 0
fortigate_cpu_usage_ratio{processor="3"} 0
HELP fortigate_current_sessions Current amount of sessions, per IP version
TYPE fortigate_current_sessions gauge
fortigate_current_sessions{protocol="ipv4"} 774
fortigate_current_sessions{protocol="ipv6"} 0
HELP fortigate_memory_usage_ratio Current resource usage ratio of system memory
TYPE fortigate_memory_usage_ratio gauge
fortigate_memory_usage_ratio 0.46
HELP fortigate_vdom_cpu_usage_ratio Current resource usage ratio of CPU, per VDOM
TYPE fortigate_vdom_cpu_usage_ratio gauge
fortigate_vdom_cpu_usage_ratio{vdom="root"} 0
HELP fortigate_vdom_current_sessions Current amount of sessions, per VDOM and IP version
TYPE fortigate_vdom_current_sessions gauge
fortigate_vdom_current_sessions{protocol="ipv4",vdom="root"} 790
fortigate_vdom_current_sessions{protocol="ipv6",vdom="root"} 0
HELP fortigate_vdom_memory_usage_ratio Current resource usage ratio of memory, per VDOM
TYPE fortigate_vdom_memory_usage_ratio gauge
fortigate_vdom_memory_usage_ratio{vdom="root"} 0.46
HELP fortigate_version_info System version and build information
TYPE fortigate_version_info gauge
fortigate_version_info{build="1396",serial="FGT40FTK21099NC3",version="v7.2.4"} 1
HELP probe_duration_seconds How many seconds the probe took to complete
TYPE probe_duration_seconds gauge
probe_duration_seconds 0.180845745
HELP probe_success Whether or not the probe succeeded
TYPE probe_success gauge
probe_success 0
One step forward.

could you try to run exporter with http debug?
GODEBUG=http2debug=1 ./fortigate-exporter -auth-file fortigate-key.yaml -insecur
what I found is there a change between firmware 7.0.x and 7.2.x which breaks exporter. seems there is no more /api/v2/monitor/switch-controller/managed-switch at the very least. may be more.

It is interesting that Fortinet change the api contract between minor versions. I agree that pagination should be done instead of just a larger number - my bad.

It is interesting that Fortinet change the api contract between minor versions. I agree that pagination should be done instead of just a larger number - my bad.

I don't think it was a api contract change tbh. I couldn't find api/v2/monitor/switch-controller/managed-switch endpoint in fortinet docs, it always been api/v2/monitor/switch-controller/managed-switch/status. probably it was working for a while, until fortigate have fixed it.

@p-v-a is there an action to be done here? Should the above patch be merged? If so, care to move it to a PR?
To me I'm having trouble grokking if there are things left to be done here, so I'll close this issue.