I use ControlNet and AnimateDiffEvo ，something wrong happen

RuntimeError: Expected all tensors to be on the same device, but found at least two devices, cpu and cuda:0! (when checking argument for argument mat1 in method wrapper_CUDA_addmm)
after comfyui  update
=====================
detail message：
got prompt
Requested to load AutoencoderKL
Loading 1 new model
[AnimateDiffEvo] - INFO - Regular AnimateDiff activated - latents passed in (16) less or equal to context_length 16.
[AnimateDiffEvo] - INFO - Using motion module mm_sd_v15_v2.ckpt version v2.
Requested to load ControlNet
Loading 1 new model
unload clone 3
40%|#### | 8/20 [00:14<00:21, 1.81s/it]
ERROR:root:!!! Exception during processing !!!
ERROR:root:Traceback (most recent call last):
File "/root/ComfyUI/execution.py", line 153, in recursive_execute
output_data, output_ui = get_output_data(obj, input_data_all)
File "/root/ComfyUI/execution.py", line 83, in get_output_data
return_values = map_node_over_list(obj, input_data_all, obj.FUNCTION, allow_interrupt=True)
File "/root/ComfyUI/execution.py", line 76, in map_node_over_list
results.append(getattr(obj, func)(**slice_dict(input_data_all, i)))
File "/root/ComfyUI/nodes.py", line 1319, in sample
return common_ksampler(model, seed, steps, cfg, sampler_name, scheduler, positive, negative, latent_image, denoise=denoise)
File "/root/ComfyUI/nodes.py", line 1289, in common_ksampler
samples = comfy.sample.sample(model, noise, steps, cfg, sampler_name, scheduler, positive, negative, latent_image,
File "/root/ComfyUI/custom_nodes/ComfyUI-Impact-Pack/modules/impact/sample_error_enhancer.py", line 22, in informative_sample
raise e
File "/root/ComfyUI/custom_nodes/ComfyUI-Impact-Pack/modules/impact/sample_error_enhancer.py", line 9, in informative_sample
return original_sample(*args, **kwargs) # This code helps interpret error messages that occur within exceptions but does not have any impact on other operations.
File "/root/ComfyUI/custom_nodes/ComfyUI-AnimateDiff-Evolved/animatediff/sampling.py", line 284, in motion_sample
return wrap_function_to_inject_xformers_bug_info(orig_comfy_sample)(model, noise, *args, **kwargs)
File "/root/ComfyUI/custom_nodes/ComfyUI-AnimateDiff-Evolved/animatediff/model_utils.py", line 209, in wrapped_function
return function_to_wrap(*args, **kwargs)
File "/root/ComfyUI/comfy/sample.py", line 101, in sample
samples = sampler.sample(noise, positive_copy, negative_copy, cfg=cfg, latent_image=latent_image, start_step=start_step, last_step=last_step, force_full_denoise=force_full_denoise, denoise_mask=noise_mask, sigmas=sigmas, callback=callback, disable_pbar=disable_pbar, seed=seed)
File "/root/ComfyUI/comfy/samplers.py", line 716, in sample
return sample(self.model, noise, positive, negative, cfg, self.device, sampler, sigmas, self.model_options, latent_image=latent_image, denoise_mask=denoise_mask, callback=callback, disable_pbar=disable_pbar, seed=seed)
File "/root/ComfyUI/comfy/samplers.py", line 622, in sample
samples = sampler.sample(model_wrap, sigmas, extra_args, callback, noise, latent_image, denoise_mask, disable_pbar)
File "/root/ComfyUI/comfy/samplers.py", line 561, in sample
samples = self.sampler_function(model_k, noise, sigmas, extra_args=extra_args, callback=k_callback, disable=disable_pbar, **self.extra_options)
File "/root/miniconda3/lib/python3.10/site-packages/torch/utils/_contextlib.py", line 115, in decorate_context
return func(*args, **kwargs)
File "/root/ComfyUI/comfy/k_diffusion/sampling.py", line 137, in sample_euler
denoised = model(x, sigma_hat * s_in, **extra_args)
File "/root/miniconda3/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1501, in _call_impl
return forward_call(*args, **kwargs)
File "/root/ComfyUI/comfy/samplers.py", line 285, in forward
out = self.inner_model(x, sigma, cond=cond, uncond=uncond, cond_scale=cond_scale, model_options=model_options, seed=seed)
File "/root/miniconda3/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1501, in call_impl
return forward_call(*args, **kwargs)
File "/root/ComfyUI/comfy/samplers.py", line 275, in forward
return self.apply_model(*args, **kwargs)
File "/root/ComfyUI/comfy/samplers.py", line 272, in apply_model
out = sampling_function(self.inner_model, x, timestep, uncond, cond, cond_scale, model_options=model_options, seed=seed)
File "/root/ComfyUI/custom_nodes/ComfyUI-AnimateDiff-Evolved/animatediff/sampling.py", line 632, in sliding_sampling_function
cond, uncond = calc_cond_uncond_batch(model, cond, uncond, x, timestep, model_options)
File "/root/ComfyUI/custom_nodes/ComfyUI-AnimateDiff-Evolved/animatediff/sampling.py", line 488, in calc_cond_uncond_batch
c['control'] = control.get_control(input_x, timestep, c, len(cond_or_uncond))
File "/root/ComfyUI/custom_nodes/ComfyUI-Advanced-ControlNet/control.py", line 182, in get_control
return super().get_control(x_noisy, t, cond, batched_number)
File "/root/ComfyUI/comfy/controlnet.py", line 174, in get_control
control = self.control_model(x=x_noisy.to(dtype), hint=self.cond_hint, timesteps=timestep.float(), context=context.to(dtype), y=y)
File "/root/miniconda3/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1501, in _call_impl
return forward_call(*args, **kwargs)
File "/root/ComfyUI/comfy/cldm/cldm.py", line 287, in forward
emb = self.time_embed(t_emb)
File "/root/miniconda3/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1501, in _call_impl
return forward_call(*args, **kwargs)
File "/root/miniconda3/lib/python3.10/site-packages/torch/nn/modules/container.py", line 217, in forward
input = module(input)
File "/root/miniconda3/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1501, in _call_impl
return forward_call(*args, **kwargs)
File "/root/ComfyUI/comfy/ops.py", line 28, in forward
return super().forward(*args, **kwargs)
File "/root/miniconda3/lib/python3.10/site-packages/torch/nn/modules/linear.py", line 114, in forward
return F.linear(input, self.weight, self.bias)
RuntimeError: Expected all tensors to be on the same device, but found at least two devices, cpu and cuda:0! (when checking argument for argument mat1 in method wrapper_CUDA_addmm)
Prompt executed in 41.42 seconds

Hey, are you using fp8 by any chance? A recent comfy update made it incompatible with my code - I'll make AnimateDiff Evolved work with fp8 again soon

Hey, are you using fp8 by any chance? A recent comfy update made it incompatible with my code - I'll make AnimateDiff Evolved work with fp8 again soon

Great!

嘿，你用的是fp8吗？最近的一次舒适更新使其与我的代码不兼容 - 我很快就会让 AnimateDiff Evolved 再次与 fp8 一起使用

大佬，我也是这个问题，期待你的更新解决。

Could both of you provide a screenshot of your workflows, as well as a screenshot of your ComfyUI/custom_nodes directory?

Could both of you provide a screenshot of your workflows, as well as a screenshot of your ComfyUI/custom_nodes directory?

workflow:

update ComfyUI since Dec.29 ,something wrong happen

Hmm, based in your initial error stack, I don't see a message about it loading the AnimateDiffModel when it starts sampling - I think your AnimateDiff-Evolved is outdated. Try updating it and Advanced-ControlNet as well. A lot of model management code got updated in December that might fix your issue.

I use the workflow same as your example but get the nothing output without any error message. Could you help me to find out the cause of the problem?

I'm going to assume you have fixed your issue - reopen it if you still have an issue.


Initial release of SD/MMC interface driver

Pull request contains generic API interface for SD/MMC device and device specific driver for STM32F7 MCU family.

Codecov Report

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

@@           Coverage Diff           @@
##           master   #13214   +/-   ##
=======================================
  Coverage   48.75%   48.75%
=======================================
  Files         319      319
  Lines       46871    46871
  Branches    10835    10835
=======================================
  Hits        22850    22850
  Misses      19394    19394
  Partials     4627     4627

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 d942c1d...ce3ea11. Read the comment docs.

Anyone review this? Maybe this patch is useful for me.

+1

What is the status of this pull request?

@pic16f887, sorry for late feedback on this. Had missed this proposal.
After having had a very quick look, this seems rather good, even if I can't comment on the proposed API.
Could you rebase the PR so we can start an active review?

@erwango, I have rebased the code.

@pic16f887, sorry once again for letting this PR not reviewed.
To get more attention on that PR, can you please split the generic API and STM32 parts?
The generic API should get more attention.

@pic16f887 any updates on this?

Adding support to SDMMC looks quite interesting.
Has it been abandoned?

Currently I don't have a free time to finish it. You are free to use this code.


Lock examples to Next.js 12?

There are a few breaking changes in Next.js 13 https://nextjs.org/docs/upgrading#upgrading-from-12-to-13
There are a few breaking changes in React 18 https://reactjs.org/blog/2022/03/08/react-18-upgrade-guide.html
We are finding that using the examples and the tutorials is quite a learning curve because we also have to do the codemode for Link components and other breaking changes in React 18.
You can see some of the blockers in the failures on a recent PR https://github.com/vercel/examples/pull/446#event-7733106994

It will take some time to update each example to Next 13 and React 18, in the mean time, what do you think about locking the examples to use the latest in the major versions of Next.js 12 and React 17?
For example:
Before
    "next": "latest",
    "react": "latest",

After
    "next": "^12.3.2",
    "react": "^17.0.2",

I found the work has already begun to update the examples to canary (my searches for Next.js 13 didn't yield results, but if  look for canary, I can see the PRs https://github.com/vercel/examples/pulls?q=is%3Apr+canary)


Document support for structured array attribute access

The support for attribute access of structured arrays can be surprising,
as it is not supported by NumPy. This commit documents this behavior, as
an alternative to removing support for attribute access, which is
presently considered non-trivial (see discussion on Issue #5375).
Fixes #878.
Does not fix #5375

I've updated the original comment, I don't think this should close #5375? It can act as a reminder that this behavioural mismatch still exists.

I've updated the original comment, I don't think this should close #5375? It can act as a reminder that this behavioural mismatch still exists.

Yeah, I agree that it's better not to close it, since the docs do state it will eventually be deprecated.

I've just merged in the fix for the flake issue introduced by another merge. The other fail was a conda HTTP error.

@gmarkall what about numpy.recarray? Numba has only one type for both structured array and recarray, and the attribute access makes more sense in that context.
This is your example adjusted to use recarray
from numba import njit
import numpy as np
record_type = np.dtype([("ival", np.int32), ("fval", np.float64)], align=True)
def f(rec):
   value = 2.5
   rec[0].ival = int(value)
   rec[0].fval = value
   return rec
arr = np.recarray((1,), dtype=record_type)
cfunc = njit(f)
# Works
print(cfunc(arr))
# works too
print(f(arr))

IIUC, I think the behaviour is consistent between Numba and NumPy for recarrays. Is that what you are referring to?

yes. the documentation now says that the behaviour will be deprecated, which would replace one numba--numpy mismatch with another. Unless the types are split and attribute array kept for recarrays but not for struct arrays.
do you think the current behaviour causes problems? Otherwise I'd suggest keeping it.

As far as I can see the documentation only talks about structured arrays, not recarrays (and to me implies that it will be deprecated for structured arrays only) - can you show me what I'm missing please?

I might be inferring too much, in that case I apologize. Where I'm coming from is that at the moment there's one type and one documentation for both objects. Deprecating something for one of them would do it for the other.
Are you saying that when the time comes to remove attribute access, a separate type (and documentation) would be added?

Yes, I would add a separate type and documentation at deprecation time - because it's a bit more complicated to type them differently than I had time for, I wrote this documentation instead,

thanks for the clarification @gmarkall


Processors should be considered as rightful dependencies

fixes #76

Side-effect on the artifactUsedClassesMap attribut should be removed in another commit, but I modified a method outside my scope to be sure that at least the right state was returned. Please tell me if you're OK with that.

Side-effect on the artifactUsedClassesMap attribut should be removed in another commit, but I modified a method outside my scope to be sure that at least the right state was returned. Please tell me if you're OK with that.

Hi @afillatre, I'm OK with the proposal. I agree, the DefaultProjectDependencyAnalyzer needs some refactoring.


yarn build fails to build graphql-serve

Running yarn build from the root, sometimes graphql-serve does not build successfully.

Module: graphql-serve
Version: 0.16.x
Node.js / npm versions: NA

$ tsc
lerna ERR! yarn run build exited 2 in 'graphql-serve'
lerna ERR! yarn run build stdout:
$ tsc
node_modules/@types/express/index.d.ts(99,42): error TS2344: Type 'P' does not satisfy the constraint 'Params'.
  Type 'P' is not assignable to type 'ParamsArray'.
node_modules/@types/express/index.d.ts(108,124): error TS2344: Type 'P' does not satisfy the constraint 'Params'.
  Type 'P' is not assignable to type 'ParamsArray'.
node_modules/@types/express/index.d.ts(109,138): error TS2344: Type 'P' does not satisfy the constraint 'Params'.
  Type 'P' is not assignable to type 'ParamsArray'.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Automatically generated comment to notify maintainers
/cc @machi1990, @wtrocki


Add weather_measurement table to SETUP.sql...

AA5SB reported that he was trying to use the dashboard on a system other than the RPi Wx Station, so it didn't have the weather_measurement table.

In dev ready to close


Correct way to handle reject in verifyJWT

As title says, what is the correct way to handle a rejection in verifyJWT method?
What I try to do is:
verifyJWT(jwt, options)
  .then(...)
  .catch(error => console.log(error))

and
try {
   const result = await verifyJWT(jwt, options);
} catch(e) {
   throw e;
}

but the node console always says
UnhandledPromiseRejectionWarning: Unhandled promise rejection.
This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)

And the request stays in pending status until socket hung ups

You are doing it right and it should not throw that error.
Can you post a tiny project that exhibits this behavior?

You are doing it right and it should not throw that error.
Can you post a tiny project that exhibits this behavior?

Thank you for the response! I cant put here the whole code flow but what I can do is put the functions that call it:
const verifyToken = async (jwt, isUser = false) => {
	const options = {
		resolver,
		audience: serverDid
	};
	try {
		return await verifyJWT(jwt, options);
	} catch (error) {
                // errorMessages is an object with personalized messages
		const message = errorMessages[error.name] || INVALID_CODE(isUser);
		throw message;
	}
};

The above function is in turn enclosed in a general trycatch within the path from which it is invoked
What I tried and with which I got this error, was to edit the token manually by adding or modifying some letter. The console shows the error (invalid length for example), but does not go the way of rejection

Is this still an issue?
It seems that this is a misunderstanding of async
In your code from before, verifyToken is going to return a Promise.
To get away from the unhandled promise rejection error, you need to catch():
verifyToken(token)
  .then((result) => { console.log('token was verified:', token) })
  .catch((error) => { console.log('bad token', error) })

I'm closing this. Please reopen if this is still an issue, but please also link to a project that shows the failure.. not just a snippet of code.


Disable network access when building in copr

Make the copr build environment as close to koji as possible to
prevent last-minute suprises just before the next release.

Seems to be working nicely:
Networking enabled: False


Markdown issue for bold

Gitea version (or commit ref): 1.12.0+dev-403-g154b137b6
Git version: -
Operating system: -
Database (use [x]): -
Can you reproduce the bug at https://try.gitea.io: https://try.gitea.io/alexanderadam/636f7374-cherry.cr#user-content-contributors
Log gist: -

Description
Bold text within a table isn't rendered bold?
This code:
|Bold text below|
|:---:|
|**[this should be bold](…)**|
|**[this should be bold](…)**|

should render like

Bold text below

this should be bold

this should be bold

Screenshots
github on the left and gitea on the right

Looks like this is a bug in goldmark

Looks like or is a bug? Should I open a corresponding bug in goldmark?

@alexanderadam Does this help?
https://github.com/go-gitea/gitea/blob/421e7b7875d4ee71eeaec6e1e28a3758adcb55ce/go.mod#L99

@yuin is incredibly fast and the fix is now in goldmark version 1.1.24.


Issue with Sigil.NonGeneric.Emit.Call

Hi,
The function Sigil.NonGeneric.Emit.Call ends up calling this overload of Emit.Call:
public Emit<DelegateType> Call(MethodInfo method, Type[] arglist = null)
That overload is for already builded types and, in fact, the inner MethodBuilder object does not seems to like the call to GetParameters() (NotSupportedException -> Type has not beed created).
Is it possible to fix this calling the other overload of Emit.Call?
Thanks!

Opened a pull request


Add PKG_HASH and PKG_BUILDNUMBER support

I think we may not have support for using PKG_HASH and PKG_BUILDNUMBER in the build string right now (for this one needs to compute the values first, then use jinja to evaluate the template.

Hey @wolfv, am I correct in understanding that PKG_HASH and PKG_BUILDNUM are not possible to include in a custom build string in a boa recipe? If so are there any workarounds to get the current package-hash into the build string in case we need to finetune build numbers of package variants (while keeping the hash) like this?
I would like to do something like this in a boa recipe
build:
  number: 4
  string: 'aster_h{{ PKG_HASH }}_{{ PKG_BUILDNUM }}'

But unfortunately it results in -aster_h_.tar.bz2 :(
I am using boa==0.15.1 btw.


Update URL for JDK bug

Codecov Report

Merging #1050 (0c1a79f) into master (fee35dd) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master    #1050   +/-   ##
=========================================
  Coverage     92.06%   92.06%
  Complexity     7484     7484
=========================================
  Files           194      194
  Lines         15725    15725
  Branches       2897     2897
=========================================
  Hits          14478    14478
  Misses          674      674
  Partials        573      573

Impacted Files
Coverage Δ

.../org/apache/commons/lang3/time/FastDateParser.java
94.83% <ø> (ø)

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


Futbin data

This is the error from the console
Failed to load https://www.futbin.com/18/playerPrices?player=200529: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'chrome-extension://dcmhogfnodefoildnphkcfcjaamoahkb' is therefore not allowed access.
commonUtility.js:28 shortfuts: SyntaxError: Unexpected end of JSON input
logError @ commonUtility.js:28
xhr.onreadystatechange @ script.js:215
XMLHttpRequest.send (async)
getFutbinData @ script.js:220
(anonymous) @ script.js:78
safeCallbackApply @ VM316 extensions::uncaught_exception_handler:27
handleResponse @ VM317 extensions::sendRequest:67
commonUtility.js:28 shortfuts: Unable to get Futbin data.

Darn. The request didn't have any security issues when using local code. Rules must be different when using the extension from the store. Thanks for reporting - I'll take a look ASAP.
On mobile, so please excuse any errors or brevity.

From: andreiiulian90<EMAIL_ADDRESS>Sent: Friday, October 27, 2017 1:19:13 AM
To: martellaj/shortfuts
Cc: Subscribed
Subject: [martellaj/shortfuts] Futbin data (#44)
This is the error from the console
Failed to load https://www.futbin.com/18/playerPrices?player=200529: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'chrome-extension://dcmhogfnodefoildnphkcfcjaamoahkb' is therefore not allowed access.
commonUtility.js:28 shortfuts: SyntaxError: Unexpected end of JSON input
logError @ commonUtility.js:28
xhr.onreadystatechange @ script.js:215
XMLHttpRequest.send (async)
getFutbinData @ script.js:220
(anonymous) @ script.js:78
safeCallbackApply @ VM316 extensions::uncaught_exception_handler:27
handleResponse @ VM317 extensions::sendRequest:67
commonUtility.js:28 shortfuts: Unable to get Futbin data.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/martellaj/shortfuts/issues/44, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AA-OVifK_HSRaqyFTWRKLrUl7PLM-w-_ks5swZIBgaJpZM4QIs3x.

Fixed! Thanks!


Error in workflow when encrypting private key to be exported

What version of Go are you using (go version)?
go version go1.14.2 darwin/amd64

What operating system and processor architecture are you using?
Testing purposes on a MacBook Pro (darwin/amd64)

What did you do?
Trying to migrate from x/crypto/openpgp to ProtonMail/crypto/openpgp to enable exporting generated PGP key with private key encrypted with passphrase. Test code is in https://gist.github.com/jbouse/86957f5e7bd44337eeccf9d705d54c55

What did you expect to see?
I expect to see a single log output stating:
2020/05/13 14:45:00 Encrypted: true
I also expect to see 2 files created testkey.asc and testkey.pub.asc with the encrypted private and the public key respectively.

What did you see instead?
I get the expected log output and the testkey.pub.asc contains the expected public key; however, the testkey.asc file is prematurely closed and I receive the following panic message output:

panic: interface conversion: interface is nil, not crypto.Signer

goroutine 1 [running]:
golang.org/x/crypto/openpgp/packet.(*Signature).Sign(0xc000150000, 0x11aa9c0, 0xc000164200, 0xc0003e0000, 0x0, 0xc000164200, 0x0)
        /Users/JeremyBouse/go/pkg/mod/github.com/!proton!mail/crypto@v0.0.0-20200416114516-1fa7f403fb9c/openpgp/packet/signature.go:564 +0x14c
golang.org/x/crypto/openpgp/packet.(*Signature).SignUserId(0xc000150000, 0xc000016260, 0x1e, 0xc0003e40e0, 0xc0003e0000, 0x0, 0x15, 0x20)
        /Users/JeremyBouse/go/pkg/mod/github.com/!proton!mail/crypto@v0.0.0-20200416114516-1fa7f403fb9c/openpgp/packet/signature.go:635 +0xca
golang.org/x/crypto/openpgp.(*Entity).serializePrivate(0xc000066190, 0x13a22a8, 0xc000066280, 0x0, 0x1152d01, 0x0, 0x13a22a8)
        /Users/JeremyBouse/go/pkg/mod/github.com/!proton!mail/crypto@v0.0.0-20200416114516-1fa7f403fb9c/openpgp/keys.go:537 +0x1df
golang.org/x/crypto/openpgp.(*Entity).SerializePrivate(0xc000066190, 0x13a22a8, 0xc000066280, 0x0, 0xc000066280, 0x11a9640)
        /Users/Jere:511 +0x67
main.encodePrivateKey(0x11a9040, 0xc00000e0a8, 0xc000066190)
        /Users/JeremyBouse/Git/poc/main.go:43 +0x181
main.generateKeys(0x1179fea, 0x8, 0x117c084, 0x13)
        /Users/JeremyBouse/Git/poc/main.go:80 +0x4a6
main.main()
        /Users/JeremyBouse/Git/poc/main.go:34 +0x4b

If however, I comment out lines 74-77 of the gist main.go file and rebuild then it executes fine without the panic but the private key is not encrypted with a passphrase and the log output instead reports as expected:
2020/05/13 15:04:52 Encrypted: false
For debugging I've let it use the safe default packet.Config and set the parameter to nil rather than use the config variable that was defined to make sure that wasn't the cause for issue. Am I missing a step or performing something incorrectly or is there an issue within the entity.SerializePrivate function when the key is encrypted?

Hey :wave: Try using SerializePrivateWithoutSigning instead of SerializePrivate. SerializePrivate always tries to re-sign the key, which is impossible when it's encrypted.

Hello @jbouse, SerializePrivate resigns the key, but it has no access to the PrivateKey field since it's encrypted. You should use SerializePrivateWithoutSigning in this case.

@twiss I'll try that and see if it helps solve the problem. Thank you.

Okay so changing SerializePrivate to SerializePrivateWithoutSigning solved the issue and appears to be working as expected now. Of note this method does not appear to be shown on the documentation I saw on https://pkg.go.dev/github.com/ProtonMail/crypto@v2.0.0+incompatible/openpgp?tab=doc where I was reading from so maybe this is a recent change? I had tried the SerializePrivateNoSign as the doc page had but it had failed stating method didn't exist.

Yeah, we recently changed this indeed. Sorry about that!


Adding debug setup information to doc

Description
Adding debug information to help contributors to set up their dev environment.
Type of change
Doc only

Thanks for adding this guide. It's super helpful. Do you think we should add another section walking through how to test local changes in the k8s cluster scenario? So the steps to build the new image, push to registry, change values.yaml to pull correct image, etc.)

thanks for the suggestion, just added the commands for Test local changes in the k8s cluster scenario


lnwallet: respect local dust limit in cooperative close

Change Description
When the remote dustlimit is lower than the local one, a cooperative closure could create an output that doesn't respect the local dustlimit. By comparing the remote balance to the local dustlimit we're protected against creating invalid cooperative close transactions according to the local standards.
This requirement is part of the BOLTs: https://github.com/lightning/bolts/blob/5f8fea8dc3c8c612167dd9645c4a21fe9de2f147/03-transactions.md?plain=1#L373
Unfortunately this now leads to failure to close the channel. But that's better than crafting invalid transactions in my opinion.
Next steps will be

allowing the remote peer to eliminate its own output (spec).
potentially having a ruleset to in some circumstances eliminate the local output if it's small enough.

Steps to Test

Create a channel with Alice and Bob
Alice has dustlimit 10000
Bob has dustlimit 2000
Bob's balance is 2500
Attempt to cooperatively close the channel
Alice should not include Bob's output in the closing transaction

Pull Request Checklist
Testing

[ ] Your PR passes all CI checks.
[x] Tests covering the positive and negative (error paths) are included.
[x] Bug fixes contain tests triggering the bug to prevent regressions.

Code Style and Documentation

[x] The change obeys the Code Documentation and Commenting guidelines, and lines wrap at 80.
[x] Commits follow the Ideal Git Commit Structure.
[x] Any new logging statements use an appropriate subsystem and logging level.
[x] Any new lncli commands have appropriate tags in the comments for the rpc in the proto file.
[x]  There is a change description in the release notes, or [skip ci] in the commit message for small changes.

📝 Please see our  Contribution Guidelines for further guidance.

Otherwise we'd always end up using max(local_dust_limit, remote_dust_limit) since we'd also need to make sure ourBalance >= remoteDust?

That's a decision you can make. To either fail the closing procedure, because you have in invalid signature according to the remote party, or to omit your own output. Probably a good reasoning to decide whether you should omit your own output is:

is my output below the remote dust limit? If yes, would it cost me more if I would force close the channel?

For now, this PR only ensures you never create a transaction below your own dust limit in the first place. Deciding to omit your own output can be future improvements.

The reason we haven't done this is because iirc each implementation does something slightly different. I'd defer work on this PR until we can all agree on the logic here. Additionally, changing this now will result in incompatibility with older LND nodes.

Additionally, changing this now will result in incompatibility with older LND nodes.

I agree there will be an incompatibility with older LND nodes. In fact, there will be an incompatibility between upgraded LND nodes too. If one party omits the peers output, but the peer doesn't, there's an incompatibility. But it also doesn't ever make sense to construct a closing transaction with an output below your own dustlimit. So the incompatibility already exists. This change just makes it more obvious.

FWIW rbf-coop close will make this explicit, as the ender of a signature states which outputs is does/doesn't cover: #8453

@jssdwt, remember to re-request review from reviewers when ready

@jssdwt, remember to re-request review from reviewers when ready

@jssdwt, remember to re-request review from reviewers when ready

@jssdwt, remember to re-request review from reviewers when ready

@jssdwt, remember to re-request review from reviewers when ready

@jssdwt, remember to re-request review from reviewers when ready

@jssdwt, remember to re-request review from reviewers when ready

@jssdwt, remember to re-request review from reviewers when ready

@jssdwt, remember to re-request review from reviewers when ready

@jssdwt, remember to re-request review from reviewers when ready

@jssdwt, remember to re-request review from reviewers when ready

@jssdwt, remember to re-request review from reviewers when ready

@jssdwt, remember to re-request review from reviewers when ready

@jssdwt, remember to re-request review from reviewers when ready

@jssdwt, remember to re-request review from reviewers when ready

@jssdwt, remember to re-request review from reviewers when ready

@jssdwt, remember to re-request review from reviewers when ready

@jssdwt, remember to re-request review from reviewers when ready

@jssdwt, remember to re-request review from reviewers when ready

@jssdwt, remember to re-request review from reviewers when ready

@jssdwt, remember to re-request review from reviewers when ready

Closing due to inactivity

Closing due to inactivity

Closing due to inactivity

Closing due to inactivity

Closing due to inactivity

Closing due to inactivity

Closing due to inactivity

Closing due to inactivity

!lightninglabs-deploy mute


[ITensors] [BUG] Sum of MPOs in DMRG for excited states doesn't work

In the example page in the documentation it is reported that passing an MPO which is a sum of some MPOs as a vector to the dmrg function results in faster computation. For bigger system I found the speedup is non-negligible and I would like to use the same trick for excited states, but the implementation of dmrg for this particular case is missing.
Minimal runnable code
using ITensors

N = 4
sites = siteinds("S=1/2", N)

os_HA = OpSum()

os_HA +=  1, "Z", 1, "Z", 2
os_HA +=  1, "Z", 3, "Z", 4
os_HA += -1, "Z", 1, "Z", 3
os_HA += -1, "Z", 2, "Z", 4

W = rand(N)
os_HB = OpSum()
for j in 1:N
    os_HB += W[j], "Z", j
end

HA = MPO(os_HA, sites)
HB = MPO(os_HB, sites)

psi0 = randomMPS(sites, 5)
psi1 = randomMPS(sites, 5)

E0, psi0 = dmrg([HA, HB], psi0, nsweeps=10, outputlevel=0)
E1, psi1 = dmrg([HA, HB], [psi0], psi1, nsweeps=10)

The first dmrg call works as expected, while the second one gives the error reported below.
Output of minimal runnable code
MethodError: no method matching dmrg(::Vector{MPO}, ::Vector{MPS}, ::MPS, ::Sweeps)

Closest candidates are:
  dmrg(::MPO, ::Vector{MPS}, ::MPS, ::Sweeps; weight, kwargs...)
   @ ITensors ~/.julia/packages/ITensors/MnaxI/src/mps/dmrg.jl:40
  dmrg(::Any, ::Any, ::MPS; nsweeps, maxdim, mindim, cutoff, noise, kwargs...)
   @ ITensors ~/.julia/packages/ITensors/MnaxI/src/mps/dmrg.jl:365
  dmrg(::Vector{MPO}, ::MPS, ::Sweeps; kwargs...)
   @ ITensors ~/.julia/packages/ITensors/MnaxI/src/mps/dmrg.jl:30
  ...

Stacktrace:
 [1] dmrg(x1::Vector{MPO}, x2::Vector{MPS}, psi0::MPS; nsweeps::Int64, maxdim::Int64, mindim::Int64, cutoff::Float64, noise::Bool, kwargs::Base.Pairs{Symbol, Union{}, Tuple{}, NamedTuple{(), Tuple{}}})
   @ ITensors ~/.julia/packages/ITensors/MnaxI/src/mps/dmrg.jl:376
 [2] top-level scope
   @ In[20]:26

Version information

Output from versioninfo():

julia> versioninfo()
Julia Version 1.9.4
Commit 8e5136fa297 (2023-11-14 08:46 UTC)
Build Info:
  Official https://julialang.org/ release
Platform Info:
  OS: macOS (arm64-apple-darwin22.4.0)
  CPU: 10 × Apple M1 Pro
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-14.0.6 (ORCJIT, apple-m1)
  Threads: 8 on 8 virtual cores
Environment:
  JULIA_NUM_THREADS = 8

Output from using Pkg; Pkg.status("ITensors"):

julia> using Pkg; Pkg.status("ITensors")
Status `~/.julia/environments/v1.9/Project.toml`
  [9136182c] ITensors v0.3.52

Thanks for the report. We are currently working on a rewrite of the projected MPO code, it should be easy to add support for this once that is done.
@emstoudenmire this is a good use case to keep in mind for the new projected MPO code.

@mtfishman thanks, definitely helpful. I'm keeping a list of cases to cover and I'll add this one.


Throw TypeErrors for invalid keyframe inputs

Throw TypeErrors for the following scenarios:

Invalid easing on keyframe.
Unsorted keyframe offsets as input.
Out of bounds keyframe offset.

This change builds upon https://github.com/web-animations/web-animations-next/pull/470.

I wonder if we should be deprecating these first before throwing TypeErrors.

I don't think deprecation is necessary before the TypeErrors you're adding here, particularly since people would need to deliberately upgrade their version of the polyfill to get them (as opposed to just getting them by a push from us).

I found myself taking a careful look at the code in keyframe-interpolations.js to check whether each "easingFunction" was supposed to have an underscore to start or not. This suggests to me that we need to either (a) refactor the code to make it obvious when things are being mixed up (e.g. by having Interpolations and PropertySpecificKeyframes defined as separate classes in their own files), or (b) make them all the same, or (c) add tests to help catch stupid mistakes when changing this code. WDYT?

It kind of is separated by files already. normalize-keyframes.js is processing user input and its output should in theory be able to be used again as user input, this is why we underscore it as it may get exposed to the user again.
In keyframe-interpolations.js we're creating internal structures that should never be shown to the user, this is hinted at by the lack of underscore properties.
You've made me realise a potential bug where normalizeKeyframes() doesn't handle the presence of _easingFunction in a keyframe very well.

Also I originally did mix up the use of underscore in this code accidentally, the mistake was caught by multiple tests as keyframe easing no longer functioned.

Discussed offline that instead of storing _easingFunction on the normalised keyframe we can store it in a global cache that interpolations look up later on to reuse the parsing work. Reminder that parsing must happen in normalizeKeyframes() in order for easing TypeErrors to be thrown at the correct time.

Turns out there's no need for caching. I've split toTimingFunction() up into normalizeEasing() and parseEasingFunction() which are called during normalisation and interpolation creation respectively as separate actions. PTAL.

lgtm with nit


INFINITY-1491 Document custom update plan, and custom plans in general

Removes the data store tutorial which has become very outdated and largely supplanted by the main dev guide

Gonna just assume that this docs-only PR didn't actually cause hello-world to fail


Use SOQL Formulas in 'Field to Aggregate' and 'Aggregate Result Field'

Would be great to be able to specify a formula to aggregate a calculation. Current workaround is to create formula work fields on the child object. That in turn gets aggregated via DLRS. And if some formula is necessary for the result field, then again the result gets output into a work field and a formula is applied to that to be displayed on the page.
If formulas are allowed in both Field to Aggregate and Aggregate Result Field, then this would be solved right within the tool. So if I (hypothetically) need to find the max value of Field_A__c * Field_B__c and then apply, dunno, some percentage calculation to the result, I would avoid all the extra steps to create and document work fields.

Unfortunately I don't think SOQL supports calculations. If you have a more detailed example of a SOQL query that runs and what you'd like to achieve we can figure out how to get it added to the tooling.
SOQL does have some limited functions but not mathematical calculation. I believe there is already an open issue to see if we can support the existing SOQL functions.


Unexpected loading wheel when opening a room

There should be enough data in the store to display a room without displaying a loading wheel.
Even worse, sometimes, there is a blank screen for several seconds.
This is a regression.

There should be enough data

This is not always true. With collapsing of member events, we may need to get more data from the HS in some rooms:
2018-06-11 10:28:13.531190+0200 Riot[8408:2220379] [MXEventTimeline] paginate : request 30 messages from the server
...
2018-06-11 10:28:16.883412+0200 Riot[8408:2220379] [MXEventTimeline] paginate : got 30 messages from the server

is the pagination from server slower?

There is the same pagination slowness issue on riot-web. The spinner stayed for at least 10s in this screenshot:

On riot-ios, we decided to show nothing while we cannot fill the screen. This is more a UI issue.


Custom iterators not supported in for-of loops

TypeScript Version:  2.9.0 rc

Search Terms:

for of iterator

Code
var Thing = {
    [Symbol.iterator]: function () {
        return {
            next: function () {
                return {
                    done: false,
                    value: 1
                };
            }
        };
    }
};

for (var a of Thing) {
    console.log(a);
    break;
}

Expected behavior: No error is reported in the editor and during compilation, and 1 would be logged if executed
Actual behavior: The editor in the Playground reports an error:

Type '{ [Symbol.iterator]: () => { next: () => { done: boolean; value: number; }; }; }' is not an array type or a string type.

Visual Studio 2015 Update 3 with TypeScript 2.9 tools installed also reports an error at the place of [Symbol.iterator].
Playground Link: https://www.typescriptlang.org/play/#src=var Thing %3D {
    [Symbol.iterator]%3A function () {
        return {
            next%3A function () {
                return {
                    done%3A false%2C
                    value%3A 1
                }%3B
            }
        }%3B
    }
}%3B

for (var a of Thing) {
    console.log(a)%3B
    break%3B
}
Related Issues:

OK, --downlevelIteration


CodeTaskFactory error on missing attributes does not contain element name

When using CodeTaskFactory, if a Reference element is missing the Include attribute, or a Using element is missing the Namespace attribute, an error is printed about an empty attribute value.
This error isn't great for a few reasons

It doesn't say which element the attribute is on
It says "The "Include" attribute has been set but is empty" even when it's missing
It's emitted at the point the task is used, not declared, so the message about the Include attribute is easily confused for referring to the Items passed to the task

Team Triage:
This seems reasonable, marking up for grabs. Could you please include a repro with expected/actual error and a sample project file? Thanks!

Sample:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTarget="Build">
  <UsingTask
    TaskName="MDDownloadFiles"
    TaskFactory="CodeTaskFactory"
    AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.Core.dll" >
    <ParameterGroup>
      <Downloads ParameterType="Microsoft.Build.Framework.ITaskItem[]" Required="true" />
    </ParameterGroup>
    <Task>
      <Reference Assembly="System.IO.Compression" />
      <Using Import="System.IO" />
      <Code Language="cs" Source="$(MSBuildThisFileDirectory)/MDDownloadFiles.cs" />
    </Task>
  </UsingTask>
  <Target Name="Build">
    <MDDownloadFiles Downloads="@(MDDownload)" />
  </Target>
</Project>

Actual result:
test.csproj(16,5): error MSB3752: The "Include" attribute has been set but is empty. If the "Include" attribute is set it must not be empty.

Expected result (note location is also different):
test.csproj(10,5): error MSB3752: The required "Include" attribute on the "Reference" element is missing or empty.

Note that if you delete the Reference element, you see another, similar error:
Actual result:
test.csproj(16,5): error MSB3752: The "Namespace" attribute has been set but is empty. If the "Namespace" attribute is set it must not be empty.

Expected result (note location is also different):
test.csproj(10,5): error MSB3752: The required "Namespace" attribute on the "Using" element is missing or empty.

I'm working on a new CodeTaskFactory which is based on Roslyn and is cross platform.  I think I've addressed this issue with more validation.
https://github.com/jeffkl/roslyn/blob/inlinetask/src/Compilers/Core/MSBuildTask/CodeTaskFactory.cs

Nice :)
Though FWIW, my repro was already using the Roslyn compiler and running on a Mac.

Nice :)
Though FWIW, my repro was already using the Roslyn compiler and running on a Mac.

The CodeTaskFactory that ships with Microsoft.Build.Tasks.Core.dll uses the .NET CodeDom library which does not work on .NET Core.  We've had to [disable this[(https://github.com/Microsoft/msbuild/blob/master/src/Tasks/CodeTaskFactory.cs#L1025) CodeTaskFactory and instead I'm working on this other CodeTaskFactory that will ship with the Roslyn MSBuild task library which will use Roslyn to compile an in-memory assembly.  Hopefully that makes sense.

The old CodeTaskFactory is disabled on .NET Core.
The Mono implementation of CodeDOM can use Roslyn (awesome!) and CodeTaskFactory works in Mono, modulo this issue.
We should figure out a strategy for inline tasks on Mono. It should probably just go with the desktop/full framework approach, but we should be explicit about it.

And please note that everyone using Visual Studio for Mac is using msbuild on Mono, not on .NET Core, and that extremely unlikely to change.


currentUser returns blank at Jamf Connect loginwindow

Jamf Connect at loginwindow seems to behave differently than native loginwindow. While at loginwindow currentUser is blank:
currentUser=$(scutil <<< "show State:/Users/ConsoleUser" | awk '/Name :/ { print $3 }')
[[ "$currentUser" == "" ]] and [[ -z "$currentUser" ]] both return TRUE.
[[ -n $currentUser ]] return FALSE
$(/usr/bin/stat -f "%Su" /dev/console) returns root
Installomator test for not being at loginwindow would succeed while in reality they should fail.
Installomator version: "9.1beta"

Does this issue still occur on the latest Jamf Connect version?


JBPM-5369 RHBPMS-4369 Could not parse knowledge when creating RuntimeManager concurrently

Master PR: https://github.com/droolsjbpm/jbpm/pull/637

Fixed concurrency issue in RuleFlowProcessValidator.
Removed duplicite start and end nodes validation => Fixed IncrementalCompilationTest.

@mswiderski please, verify my changes. Thanks. (I am sorry for formatting changes, feel free to recherrypick the commits from master)

jenkins retest this

RHBPMS-4369 it's not even proposed for the release and we are in blocker only phase now so unless it gets all acks we won't be able to merge it. Don't think this is actually a blocker.

Closing this, because it's not a blocker and 6.5.x is now in blocker only state. Master PR was merged.


feat: add unsafeEnv option

When true, all variables in .env files are exposed to the client. Also, variables in process.env that are prefixed with VITE_ are exposed to the client without the VITE_ prefix.
This is nice when you know your .env files are only used for client-side variables.

@aleclarson Just an idea, but what would you think about to provide an option with a array of strings to explicitly allow several envs? This may improve security :thinking:
But maybe it is overkill :shrug:

@yyx990803: This feature creates a security hole where, in a team project, another team member could expose sensitive information without being aware that unsafeEnv is enabled.


PostgreSQL Threads

Hi peter!
I would like to push a feature to your code - the ability to specify postgresql threads as an env var.
I thing it can be useful.
Could you give me permission to create a branch so you can evaluate the changes?
Thank you.
Auro

NOMINATIM_PG_THREADS=${NOMINATIM_PG_THREADS:=2}
   sudo -u nominatim /srv/nominatim/build/utils/setup.php --osm-file $NOMINATIM_DATA_PATH/$NOMINATIM_DATA_LABEL.osm.pbf --all --threads $NOMINATIM_PG_THREADS

Hi @auro
If you would like to contribute to the project yourself then you can do the following:

Fork the repository
In your fork, create a new branch with the changes you want to make
Create a pull request from your fork to this repository

See this guide for more detail:
https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request-from-a-fork
Or if you prefer, I can look into adding the changes you want to make for you.

Hi @peter-evans how are you? Just made a push request, thank you for your help.


Oracle Life Curse dice replacement doesn't work

The moderate Curse of Outpouring Life is supposed to replace the dice in the heal spell from d8 to d12 if all your targets are living creatures, but it doesn't do anything. The code that is supposed to do it is as follows (also in the examples of the wiki for rule elements: damage dice), with the "all-living-targets" preventing any replacement no matter what you target.
{
    "key": "DamageDice",
    "override": {
        "dieSize": "d12"
    },
    "predicate": [
        "item:slug:heal", {
            "or": ["oracular-curse:stage:moderate", "oracular-curse:stage:major", "oracular-curse:stage:extreme"]
        },
        "all-living-targets"
    ],
    "selector": "spell-damage"
}

Totally didn't notice the checkbox in the actions tab, sorry for bothering


update spark 3.0.1 scala 2.12

Closes #190
Build with tests passes on JDK14 on OSX

I've merged these changes elsewhere due to it being quicker than rebasing. Works fine, had to update Jackson though which doesn't seem to get used in the tests but blows up if out of sync with Spark.


Fix: default sort option for discovery

References
Fix #8837
Description
This PR introduces a default sort option for DiscoveryConfiguration in discovery.xml, which replaces default sorting (by score,DESC)
Instructions for Reviewers
List of changes in this PR:

Added defaultSortField to DiscoverySortConfiguration, whose value is configurable in discovery.xml like this:
(our use case bean workspaceConfiguration, refer to change list for actual changes):

[...]
    <bean id="workspaceConfiguration"
        class="org.dspace.discovery.configuration.DiscoveryConfiguration"
        scope="prototype">
        [...]
        <property name="searchSortConfiguration">
            <bean class="org.dspace.discovery.configuration.DiscoverySortConfiguration">
                <!--The default sort filter to use for the initial workspace loading-->
                <property name="defaultSortField" ref="sortDateAccessioned" />
        [...]

This leads to necessary changes in dspace-api and webapp, most notably org.dspace.discovery.utils.DiscoverQueryBuilder#getDefaultSortDirection, which now use defaultSortField if not null. In our case, DiscoverySearch for workspace configuration will sort by sortDateAccessioned,DESC from now on.
To accomodate dspace-angular, which sort using the first option in <property name="sortFields"/> in discovery.xml, we add reference to <bean id="sortDateAccessioned"/> to the list value

                <property name="sortFields">
                    <list>
                        <ref bean="sortDateAccessioned" /> <!--addition-->
                        <ref bean="sortScore" />
                        <ref bean="sortTitle" />
                        <ref bean="sortDateIssued" />
                    </list>
                </property>

For Testing:
Added 2 test cases:

org.dspace.app.rest.utils.RestDiscoverQueryBuilderTest#testSortByDefaultSortField: verify that DiscoverySortConfiguration.defaultSortField is set and can be used for sorting
org.dspace.discovery.DiscoveryIT#searchWithDefaultSortServiceTest: verify that DiscoverResult.indexableObjects of a DiscoverQuery in workspace configuration is sorted by configured defaultSortField

Checklist

[x] My PR is small in size (e.g. less than 1,000 lines of code, not including comments & integration tests). Exceptions may be made if previously agreed upon.
[x] My PR passes Checkstyle validation based on the Code Style Guide.
[x] My PR includes Javadoc for all new (or modified) public methods and classes. It also includes Javadoc for large or complex private methods.
[x] My PR passes all tests and includes new/updated Unit or Integration Tests based on the Code Testing Guide.
[x] If my PR includes new libraries/dependencies (in any pom.xml), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.
[x] If my PR modifies REST API endpoints, I've opened a separate REST Contract PR related to this change.
[x] If my PR includes new configurations, I've provided basic technical documentation in the PR itself.
[x] If my PR fixes an issue ticket, I've linked them together.

To see the specific tasks where the Asana app for GitHub is being used, see below:

https://app.asana.com/0/0/1204642791317008

@buithaihai thank you so much for your contribution. It would help a lot many users.
Can you consider lastModified as the default sort field and also proposing copyField an addition to search Solr schema?

Can you consider lastModified as the default sort field and also proposing copyField an addition to search Solr schema?

Yes. Testing indicates that this is good and produced no problem. I have modified discovery.xml code so that it works as you describe:
                <!--The default sort filter to use for the initial workspace loading-->
                <property name="defaultSortField" ref="sortDateAccessioned" />
                <property name="sortFields">
                    <list>
                        <ref bean="sortDateAccessioned" />
                        <ref bean="sortScore" />
                        <ref bean="sortTitle" />
                        <ref bean="sortDateIssued" />
                    </list>
                </property>

P/s: I rebased then force-pushed my code to make it up-to-date on origin/DS-8837, so if you want to verify it again I suggest you delete the local branch and then checkout again.

I have made the requested changes. Somehow the change to sortLastModified failed. It should have been as you said.

Thank you again @buithaihai this work is very helpful for users!
I will test it again today.


AntiAliasing support for OSX

Build failed - but it only did because the Kore reference wasn't updated, so I'll take this anyway.
Thanks!


下载完大于60GB的视频后，显示页无反应，视频未成功上传

cid：onsd00879,onsd00770,idbd00754
现象：下载完单个视频后，显示页无反应，视频没有成功上传

When the vid download to 100%, the ikoa will call ffmpeg to optimize the vid, but the free dyno has 500MB RAM only, if the size of the vid is too large,  the dyno crashes, so you can't get any response from the page.
I  set the "web_optimized" option to false in the latest version.


Updated README.md

Data messages can be sent via Firebase console as well as FCM APIs.
PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[x] Documentation  changes
[ ] Other... Please describe:

PR Checklist
For bug fixes / features, please check if your PR fulfills the following requirements:

[ ] Testing has been carried out for the changes have been added
[ ] Regression testing has been carried out for existing functionality
[x] Docs have been added / updated

What is the purpose of this PR?
Updated documentation regarding data messages which can be sent from Firebase console.
Does this PR introduce a breaking change?

[ ] Yes
[x] No

What testing has been done on the changes in the PR?

What testing has been done on existing functionality?

Other information

This PR would make the documentation incorrect - data messages cannot be sent from the Firebase Console.
Adding custom key-value pairs means you are simply adding a custom data payload to a notification message not sending a data message which contains no notification properties and hence will not be displayed as a system notification.


Drop support for legacy Python 2.7

Fixes #434.
Python 2.7 reaches EOL on 2020-01-01. Many projects are pledging to drop support before or during 2020: https://python3statement.org/
It's also relatively little used. Here's the pip installs for vcrpy from PyPI for May 2019:

category
percent
downloads

3.6
37.19%
65,506

3.7
26.36%
46,432

2.7
21.83%
38,445

3.5
11.53%
20,303

3.4
2.48%
4,361

null
0.31%
553

3.8
0.29%
503

3.3
0.01%
14

Total

176,117

Source: pypistats python_minor vcrpy --last-month # pip install pypistats
There's one bit of six remaining in this PR, what's the best way to replace this?
    def test_case(self, predicate=None):
        predicate = predicate or self.is_test_method
        return six.with_metaclass(auto_decorate(self.use_cassette, predicate))

hmmm. I think this is a @kevin1024 decision. I can see arguments on both sides.
I would squash commits for this change so we get a nice clean changelog

Happy to squash, or this can also be done at merge time:

@hugovk fix conflicts

Resolved!

Looks like new conflicts with master. 😢
Looks soo good seeing all the python2 code getting gutted.
Dropping support would be a breaking change making this inclusion a v3 upgrade to vcr. (FYI @arthurHamon2)
Let’s iterate on this PR and get it merged by the end of the week before any more conflicts crop up.

I'm not sure we have to rush it ! This is a big breaking change and the downloading stats show that 21% still come from Python 2. Maybe it would be wise to release a last version 2.X with the bug fixes and warn that Python 2 will be removed in the future 3.0 release.
@kevin1024 what do you think ?

Great point @arthurHamon2 and that'd add more value to this project being empathetic of v2.7 users until the last gasp as they are often there not by choice. For the v2.1.x we should slip in a deprecation warning.
I'd like to close out @hugovk 's work so they do not have to keep rebasing with master until we release a v3.x
Is this where other projects potentially create v2.1.x, v2.2.x, v3.0.x branches to accumulate changes for different releases?
https://producingoss.com/en/release-lines.html
This article had some good discussion on the topic.

Some projects have already dropped Python 2.7 to reduce maintenance burden. Others are waiting until the EOL before dropping. Others are dropping 2.7 now/soon but creating a 2.7 maintenance branch, and keeping that until EOL, or only accepting community contributions after that.
Some examples:

https://www.numpy.org/neps/nep-0014-dropping-python2.7-proposal.html
https://docs.pytest.org/en/latest/py27-py34-deprecation.html
https://pillow.readthedocs.io/en/stable/deprecations.html#python-2-7
https://docs.djangoproject.com/en/dev/faq/install/#what-python-version-should-i-use-with-django

Rebased and updated!

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@78e21aa). Click here to learn what that means.
The diff coverage is 92.85%.

@@            Coverage Diff            @@
##             master     #443   +/-   ##
=========================================
  Coverage          ?   88.87%
=========================================
  Files             ?       24
  Lines             ?     1474
  Branches          ?      208
=========================================
  Hits              ?     1310
  Misses            ?      136
  Partials          ?       28

Impacted Files
Coverage Δ

vcr/stubs/aiohttp_stubs/__init__.py
98.85% <ø> (ø)

vcr/stubs/boto3_stubs.py
56.25% <0%> (ø)

vcr/stubs/tornado_stubs.py
0% <0%> (ø)

vcr/matchers.py
95.89% <100%> (ø)

vcr/persisters/filesystem.py
100% <100%> (ø)

vcr/stubs/compat.py
100% <100%> (ø)

vcr/patch.py
84.12% <100%> (ø)

vcr/serializers/compat.py
93.54% <100%> (ø)

vcr/config.py
93.67% <100%> (ø)

vcr/util.py
90.47% <100%> (ø)

... and 5 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 78e21aa...2c138dd. Read the comment docs.

Hi @hugovk I haven't forgotten this PR. I've assigned it to the v3 milestone.
There are some bug reports coming in for v2.1.0 that I'd like to address and also add Python3.8 support into our TravisCI matrix targetted for v2.2.0 hopefully in September before it's release in October.
Then pull the trigger on v3.0 dropping python 2 support.
Just wanted to give you an update and thanks for your patience. I'm looking forward to culling that maintenance burden.

Thanks, sounds good!

Ok looks like Python3.8 CI is passing now there is official support on TravisCI.
The reported aiohttp bugs are attracting no PRs to address them.
The other fixes have been in the wild for a few months now.

I'm looking to close this PR by the end of Nov 2019 pending time taken to get #478 merged and released as a minor release.

Ok it is finally happening! I grafted the commits from this branch onto branch v4.0.x in PR#499.
Thanks for your work on this PR @hugovk and your immense patience and continual rebasing.
Closing this in favor of #499

You're welcome, thanks for maintaining VCR.py!

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
Attention: Patch coverage is 92.85714% with 3 lines in your changes missing coverage. Please review.

Please upload report for BASE (master@78e21aa). Learn more about missing BASE report.

Files with missing lines
Patch %
Lines

vcr/filters.py
66.66%
0 Missing and 1 partial :warning:

vcr/stubs/boto3_stubs.py
0.00%
1 Missing :warning:

vcr/stubs/tornado_stubs.py
0.00%
1 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff            @@
##             master     #443   +/-   ##
=========================================
  Coverage          ?   88.87%
=========================================
  Files             ?       24
  Lines             ?     1474
  Branches          ?      208
=========================================
  Hits              ?     1310
  Misses            ?      136
  Partials          ?       28

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Does not transform SVG (v3.0.2)

I ran the following script off the documentation:
optimize.mjs
import { transform } from "@svgr/core";

const svgCode = `
<svg xmlns="http://www.w3.org/2000/svg"
  xmlns:xlink="http://www.w3.org/1999/xlink">
  <rect x="10" y="10" height="100" width="100"
    style="stroke:#ff0000; fill: #0000ff"/>
</svg>
`;

const jsCode = transform.sync(
  svgCode,
  { icon: true },
  { componentName: "MyComponent" }
);

console.log(jsCode);

And ran it with Node. The output was
<svg xmlns="http://www.w3.org/2000/svg"
  xmlns:xlink="http://www.w3.org/1999/xlink">
  <rect x="10" y="10" height="100" width="100"
    style="stroke:#ff0000; fill: #0000ff"/>
</svg>

I expected the output to be in React syntax.
I used v3.0.2 of the package.

yea this happens also in next js, when i using the app router endpoint

Same for me. I'm at a loss for troubleshooting this. Any ideas?

I was running into the same issue and @rossmoody suggestion worked for me.
Thanks 🙇

@JonnyBurger I think the config may need the plugins: ['@svgr/plugin-jsx'] part to transform to JSX. Otherwise it only transforms the SVG.

Thank you! The docs aren't clear about this at all.

The docs are really bad about this. Literally zero indication that anything extra is needed, and doesn't use the plugin in any examples. Yet, the entire project is about converting raw SVGs to React Native SVGs, so its easy to assume this is what it does, instead of just outputting the exact same input.

just check the cli project.  You'll find most of that you need.
 for (const asset of assets) {
      const targetPath = path.join(assetsTargetPath, asset.relativeFilePath)

      const dir = path.dirname(targetPath)

      if (!(await FileHelper.exists(dir))) {
        await FileHelper.mkdir(dir)
      }

      const svgPath = asset.sourceFilePath
      const svgCode = await FileHelper.readFile(svgPath)
      const tsxPath = targetPath.replace('.svg', '.tsx')

      const tsxCode = await transform.sync(svgCode, {
        native: true,
        icon: true,
        typescript: true,
      }, { componentName: 'SvgIcon', caller: { //SvgIcon - dummy name, haven't finished this part yet, see BTW
        name: '@svgr/cli',
        defaultPlugins: [svgo, jsx, prettier],
      } })

      await FileHelper.writeFile(tsxPath, tsxCode)

      // await FileHelper.copyFile(asset.sourceFilePath, targetPath)
    }

Don't forget to install yarn add @svgr/core @svgr/plugin-svgo @svgr/plugin-jsx @svgr/plugin-prettier
BTW, I don't get it why I see xmlns in the result...:
 return (
    <Svg xmlns="http://www.w3.org/2000/svg" width={24} height={24} viewBox="0 0 918 918" {...props}>

But, I have consistent output that is similar to https://react-svgr.com/playground/?native=true


API Overview Link Incorrect

The API Overview link is pointing to the cumulative Swagger UI doc which no longer included NLC API documentation. Should be linking to this Swagger doc https://watson-api-explorer.mybluemix.net/apis/natural-language-classifier-v1 like in the docs.

thanks


[halide:x64-linux] Cmake find_package fails - Libs installed to the wrong folder

Host Environment

OS: Ubuntu 20.04
Compiler: GCC 9.3
cmake 3.21.1

To Reproduce
Steps to reproduce the behavior:

$  ./vcpkg install Halide:x64-linux

use cmake code in a project:

set(CMAKE_TOOLCHAIN_FILE "$ENV{VCPKG_ROOT}/scripts/buildsystems/vcpkg.cmake")
project(Halide_lab VERSION 0.1.0)
find_package(Halide REQUIRED)

After I installed Halide that way, in my project, cmake find_package still failed:
The autoscheduler libraries were expected to be in the vcpkg/installed/x64-linux/tools/halide folder, which they weren't.
So I had to copy them by hand from the vcpkg/installed/x64-linux/lib folder to the expected place. But that's a different issue I guess.

@gebdadendo -- Please @ me in that issue as it's my responsibility to fix
Originally posted by @alexreinking in https://github.com/microsoft/vcpkg/issues/19635#issuecomment-907317473

The problem is with vcpkg_cmake_config_fixup() being very greedy on Linux whereas on Windows it only rewrites bin/*.exe. I posted the following on Slack the other day... need a response:

Where does vcpkg want me to put loadable modules on Linux? On Windows, putting them in bin was fine, since they had a .dll extension. But vcpkg_cmake_config_fixup() apparently breaks my package on Linux since it rewrites bin/ to tools/, whereas on Windows it rewrites bin/.exe to tools//.exe.

I wonder if the right solution is to make vcpkg_cmake_config_fixup() smarter about selecting executable targets on Linux. This could be done by shelling out to file, making sure regex matches only add_executable(), etc. etc.

It's been a bit over a month... can I get some advice re: how to resolve this issue? I'm happy to put in the work on either the Halide port or on reworking vcpkg_cmake_config_fixup as I suggested above.
@ras0219-msft @ras0219 @NancyLi1013 @JackBoosY

IIUC the problem is not generally rewriting bin to tools/port/bin on Linux, but having bin in the original exported config when libraries (or plugins?) indeed belong to lib.

Vcpkg's policies require (or at least used to require) that loadable modules be placed in bin, not lib.
https://github.com/microsoft/vcpkg/pull/13860/commits/3bfdc2ff63a5257c4754f6922f114f3aba8f8345

Vcpkg's policies require (or at least used to require) that loadable modules be placed in bin, not lib. See the commit message in 3bfdc2f

The comment refers to DLLs which are in bin on Windows. This is not quite the same as shared objects or loadable modules on Linux. For reference, qt5-base installs plugins to plugins on Linux.

@dg0yt - so is the resolution to use two different folders based on the platform, or would placing them somewhere like lib/halide all the time be okay?

so is the resolution to use two different folders based on the platform, or would placing them somewhere like lib/halide all the time be okay?

@alexreinking I can't say for sure for vcpkg.  But you already pinged the vcpkg maintainers 9 hours ago so you let us wait for a response.

root@usr:/home/usr/work/vcpkg# find packages/halide_x64-linux/tools/halide/
featurization_to_sample    get_host_target            retrain_cost_model         weightsdir_to_weightsfile
root@usr:/home/usr/work/vcpkg# find packages/halide_x64-linux/share/ | xargs grep "featurization_to_sample"
grep: packages/halide_x64-linux/share/: Is a directory
grep: packages/halide_x64-linux/share/HalideHelpers: Is a directory
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-release.cmake:# Import target "Halide::featurization_to_sample" for configuration "Release"
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-release.cmake:set_property(TARGET Halide::featurization_to_sample APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE)
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-release.cmake:set_target_properties(Halide::featurization_to_sample PROPERTIES
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-release.cmake:  IMPORTED_LOCATION_RELEASE "${_IMPORT_PREFIX}/tools/halide/featurization_to_sample"
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-release.cmake:list(APPEND _IMPORT_CHECK_TARGETS Halide::featurization_to_sample )
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-release.cmake:list(APPEND _IMPORT_CHECK_FILES_FOR_Halide::featurization_to_sample "${_IMPORT_PREFIX}/tools/halide/featurization_to_sample" )
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-debug.cmake:# Import target "Halide::featurization_to_sample" for configuration "Debug"
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-debug.cmake:set_property(TARGET Halide::featurization_to_sample APPEND PROPERTY IMPORTED_CONFIGURATIONS DEBUG)
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-debug.cmake:set_target_properties(Halide::featurization_to_sample PROPERTIES
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-debug.cmake:  IMPORTED_LOCATION_DEBUG "${_IMPORT_PREFIX}/tools/halide/featurization_to_sample"
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-debug.cmake:list(APPEND _IMPORT_CHECK_TARGETS Halide::featurization_to_sample )
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-debug.cmake:list(APPEND _IMPORT_CHECK_FILES_FOR_Halide::featurization_to_sample "${_IMPORT_PREFIX}/tools/halide/featurization_to_sample" )
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces.cmake:foreach(_expectedTarget Halide::Tools Halide::ImageIO Halide::RunGenMain Halide::Runtime Halide::retrain_cost_model Halide::featurization_to_sample Halide::get_host_target Halide::weightsdir_to_weightsfile)
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces.cmake:# Create imported target Halide::featurization_to_sample
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces.cmake:add_executable(Halide::featurization_to_sample IMPORTED)
grep: packages/halide_x64-linux/share/halide: Is a directory
grep: packages/halide_x64-linux/share/halide/tools: Is a directory
packages/halide_x64-linux/share/halide/tools/autotune_loop.sh:    ${AUTOSCHED_BIN}/featurization_to_sample ${D}/${FNAME}.featurization $R $P $S ${D}/${FNAME}.sample || echo "featurization_to_sample failed for ${D} (probably because benchmarking failed)"
root@usr:/home/usr/work/vcpkg# find packages/halide_x64-linux/share/ | xargs grep "get_host_target"
grep: packages/halide_x64-linux/share/: Is a directory
grep: packages/halide_x64-linux/share/HalideHelpers: Is a directory
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-release.cmake:# Import target "Halide::get_host_target" for configuration "Release"
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-release.cmake:set_property(TARGET Halide::get_host_target APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE)
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-release.cmake:set_target_properties(Halide::get_host_target PROPERTIES
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-release.cmake:  IMPORTED_LOCATION_RELEASE "${_IMPORT_PREFIX}/tools/halide/get_host_target"
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-release.cmake:list(APPEND _IMPORT_CHECK_TARGETS Halide::get_host_target )
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-release.cmake:list(APPEND _IMPORT_CHECK_FILES_FOR_Halide::get_host_target "${_IMPORT_PREFIX}/tools/halide/get_host_target" )
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-debug.cmake:# Import target "Halide::get_host_target" for configuration "Debug"
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-debug.cmake:set_property(TARGET Halide::get_host_target APPEND PROPERTY IMPORTED_CONFIGURATIONS DEBUG)
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-debug.cmake:set_target_properties(Halide::get_host_target PROPERTIES
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-debug.cmake:  IMPORTED_LOCATION_DEBUG "${_IMPORT_PREFIX}/tools/halide/get_host_target"
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-debug.cmake:list(APPEND _IMPORT_CHECK_TARGETS Halide::get_host_target )
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-debug.cmake:list(APPEND _IMPORT_CHECK_FILES_FOR_Halide::get_host_target "${_IMPORT_PREFIX}/tools/halide/get_host_target" )
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces.cmake:foreach(_expectedTarget Halide::Tools Halide::ImageIO Halide::RunGenMain Halide::Runtime Halide::retrain_cost_model Halide::featurization_to_sample Halide::get_host_target Halide::weightsdir_to_weightsfile)
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces.cmake:# Create imported target Halide::get_host_target
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces.cmake:add_executable(Halide::get_host_target IMPORTED)
grep: packages/halide_x64-linux/share/halide: Is a directory
grep: packages/halide_x64-linux/share/halide/tools: Is a directory
packages/halide_x64-linux/share/halide/tools/autotune_loop.sh:HL_TARGET=`${AUTOSCHED_BIN}/get_host_target avx512 avx512_knl avx512_skylake avx512_cannonlake`
root@usr:/home/usr/work/vcpkg# find packages/halide_x64-linux/share/ | xargs grep "retrain_cost_model"
grep: packages/halide_x64-linux/share/: Is a directory
grep: packages/halide_x64-linux/share/HalideHelpers: Is a directory
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-release.cmake:# Import target "Halide::retrain_cost_model" for configuration "Release"
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-release.cmake:set_property(TARGET Halide::retrain_cost_model APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE)
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-release.cmake:set_target_properties(Halide::retrain_cost_model PROPERTIES
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-release.cmake:  IMPORTED_LOCATION_RELEASE "${_IMPORT_PREFIX}/tools/halide/retrain_cost_model"
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-release.cmake:list(APPEND _IMPORT_CHECK_TARGETS Halide::retrain_cost_model )
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-release.cmake:list(APPEND _IMPORT_CHECK_FILES_FOR_Halide::retrain_cost_model "${_IMPORT_PREFIX}/tools/halide/retrain_cost_model" )
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-debug.cmake:# Import target "Halide::retrain_cost_model" for configuration "Debug"
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-debug.cmake:set_property(TARGET Halide::retrain_cost_model APPEND PROPERTY IMPORTED_CONFIGURATIONS DEBUG)
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-debug.cmake:set_target_properties(Halide::retrain_cost_model PROPERTIES
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-debug.cmake:  IMPORTED_LOCATION_DEBUG "${_IMPORT_PREFIX}/tools/halide/retrain_cost_model"
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-debug.cmake:list(APPEND _IMPORT_CHECK_TARGETS Halide::retrain_cost_model )
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-debug.cmake:list(APPEND _IMPORT_CHECK_FILES_FOR_Halide::retrain_cost_model "${_IMPORT_PREFIX}/tools/halide/retrain_cost_model" )
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces.cmake:foreach(_expectedTarget Halide::Tools Halide::ImageIO Halide::RunGenMain Halide::Runtime Halide::retrain_cost_model Halide::featurization_to_sample Halide::get_host_target Halide::weightsdir_to_weightsfile)
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces.cmake:# Create imported target Halide::retrain_cost_model
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces.cmake:add_executable(Halide::retrain_cost_model IMPORTED)
grep: packages/halide_x64-linux/share/halide: Is a directory
grep: packages/halide_x64-linux/share/halide/tools: Is a directory
packages/halide_x64-linux/share/halide/tools/autotune_loop.sh:            ${AUTOSCHED_BIN}/retrain_cost_model \
root@usr:/home/usr/work/vcpkg# find packages/halide_x64-linux/share/ | xargs grep "weightsdir_to_weightsfile"
grep: packages/halide_x64-linux/share/: Is a directory
grep: packages/halide_x64-linux/share/HalideHelpers: Is a directory
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-release.cmake:# Import target "Halide::weightsdir_to_weightsfile" for configuration "Release"
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-release.cmake:set_property(TARGET Halide::weightsdir_to_weightsfile APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE)
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-release.cmake:set_target_properties(Halide::weightsdir_to_weightsfile PROPERTIES
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-release.cmake:  IMPORTED_LOCATION_RELEASE "${_IMPORT_PREFIX}/tools/halide/weightsdir_to_weightsfile"
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-release.cmake:list(APPEND _IMPORT_CHECK_TARGETS Halide::weightsdir_to_weightsfile )
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-release.cmake:list(APPEND _IMPORT_CHECK_FILES_FOR_Halide::weightsdir_to_weightsfile "${_IMPORT_PREFIX}/tools/halide/weightsdir_to_weightsfile" )
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-debug.cmake:# Import target "Halide::weightsdir_to_weightsfile" for configuration "Debug"
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-debug.cmake:set_property(TARGET Halide::weightsdir_to_weightsfile APPEND PROPERTY IMPORTED_CONFIGURATIONS DEBUG)
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-debug.cmake:set_target_properties(Halide::weightsdir_to_weightsfile PROPERTIES
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-debug.cmake:  IMPORTED_LOCATION_DEBUG "${_IMPORT_PREFIX}/tools/halide/weightsdir_to_weightsfile"
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-debug.cmake:list(APPEND _IMPORT_CHECK_TARGETS Halide::weightsdir_to_weightsfile )
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces-debug.cmake:list(APPEND _IMPORT_CHECK_FILES_FOR_Halide::weightsdir_to_weightsfile "${_IMPORT_PREFIX}/tools/halide/weightsdir_to_weightsfile" )
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces.cmake:foreach(_expectedTarget Halide::Tools Halide::ImageIO Halide::RunGenMain Halide::Runtime Halide::retrain_cost_model Halide::featurization_to_sample Halide::get_host_target Halide::weightsdir_to_weightsfile)
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces.cmake:# Create imported target Halide::weightsdir_to_weightsfile
packages/halide_x64-linux/share/HalideHelpers/Halide-Interfaces.cmake:add_executable(Halide::weightsdir_to_weightsfile IMPORTED)
grep: packages/halide_x64-linux/share/halide: Is a directory
grep: packages/halide_x64-linux/share/halide/tools: Is a directory
root@usr:/home/usr/work/vcpkg#

Is there anything I missed?
All tools are in tools/halide folder and the cmake configurations are correct.

In windows:

dynamic libraries -> bin.
static libraries -> lib.
tools -> tools/${PORT}

In non-Windows:

dynamic libraries -> lib.
static libraries -> lib.
tools -> tools/${PORT}.

The module file should be placed in share/ (called by the library) or placed in tools/PORT (called by the tool).
Of course, we may need to modify the code or configuration.

@JackBoosY - it looks like the Halide port is going to be updated in #20749... it would be nice to get this fixed at the same time. What is the agreed-upon resolution? Re-add set(VCPKG_POLICY_EMPTY_PACKAGE enabled) and set -DHalide_INSTALL_PLUGINDIR=plugins/${PORT}?

@JackBoosY any updates here? This is also causing https://github.com/microsoft/vcpkg/issues/22228 which makes automating things downstream with the package impossible.

I'm not sure about that.
I think we cannot effectively solve this problem before we solve rpath.
Any other suggestions here?

This issue should be fixed by https://github.com/microsoft/vcpkg/pull/23035. Please ping me to reopen this issue if it still bother you.


set DRIVE_PATH to current directory by default

Unless configured as an environment variable, the DRIVE_PATH should just be the location in which the server was launched
This will make it super easy to launch (just one thing to configure - SAS_PATH)

Change DRIVE_PATH to SASJS_ROOT
default to ./sasjs_root if not specified


Duplicate loading when cache_classes=false and eager_load=true

For a variety of reasons I won't go into here, I have to run my app with eager_load = true in development (where cache_classes = false). (I realize this is an unusual Rails setup for development env).
I'm trying to use this gem to handle decoration loading, but in this situation, the decorator is loaded twice on application initialization, once when the code is eager loaded (because Rails eager loads app/**/*) and once when this gem runs its load! method.
I tried various fixes changing when/where Decorators.load! is run, but no luck. I was wondering if someone with a deeper understanding of the Rails autoloading and boot processes had any thoughts.

Oh dear..  here's the guts of it
So currently the library says that if you're eager loading then we have to use after_initialize, otherwise we use to_prepare.
Then, if you're caching classes it says to use require, otherwise to use load.
I think to cater to this situation the plugin might have to store away which things it's already decorated in that wave of decorations and skip decorators that it's already done.  We could do this in the register step by appending to an instance variable like @registered_but_not_applied and then removing from this variable each time we loaded or required a decorator.  As development mode is where most of the pain comes from, due to code reloading, I think that this would have the caveat that you'd have to refresh the @registered_but_not_applied collection to match the @registered collection at the start of each Rails request in development mode so that it knows to do it again.
Hopefully this all makes a certain amount of sense.. do you have any suggestions for what might work?

I follow your logic, but I'm not sure that would address the problem.... the reason it wouldn't work is because the first "round" of the decorators getting loaded is [during the :eager_load! initializer] (https://github.com/rails/rails/blob/master/railties/lib/rails/application/finisher.rb#L53) which uses require to load the files.
Since it's using require, Rails autoload won't work with those files. (I believe it needs to use require_dependency to work with autoload?)
I tried running Decorators.load! in config.before_eager_load, which I really thought would work, but didn't for reasons I can't explain. Under this setup, changing the file even once caused the decorations to disappear on the next request. Maybe doing a hard require on a file even once results in it not working with Rails autoloading?

Actually this gave me an idea to try monkey-patching ActiveSupport::Autoload#eager_load! to use require_dependency. FML IM A TERRIBLE PERSON. I'll report back if that works.

OK, if we need to use require_dependency maybe that'd work better?

sorry, i tried to reproduce in a fresh rails app and couldn't. my quest continues. thanks for your time, i think this gem is nice.

Thank you!!


Cannot read property 'workerSrc' of undefined

I tried to include this add-on in an our existing ember-cli build. Am getting an error Cannot read property 'workerSrc' of undefined. Can you please let me know, anything I have to include to make it run properly ?
The version which I have used is 0.4.11

@mysterlune Can you please look into it and help me ASAP ?


Update README.md

@rultor, release, tag is 0.0.15

@rultor, release, tag is 0.0.15

@dours OK, I will release it now. Please check the progress here

@rultor, release, tag is 0.0.15

@dours Done! FYI, the full log is here (took me 9min)


Is your feature request related to a problem? Please describe.
TPA and Back commands need to have a way to block certain worlds
Describe the solution you'd like
Add a permission requirement for each world sililar to how Essentials does where if it enabled you can add permissions for worlds you want people to be able to enter with TPA
Describe alternatives you've considered
considered disabling TPA all together
Additional context
Add any other context or screenshots about the feature request here.
Discord contact: Tia Kimiko#8615

wrong plugin ...


New version: NamedColors v0.2.2

Registering package: NamedColors
Repository: https://github.com/JuliaGraphics/NamedColors.jl
Created by: @oxinabox
Version: v0.2.2
Commit: 56325069d6915f026f3a45aebcc85bd15d8d1d53
Reviewed by: @oxinabox
Reference: https://github.com/JuliaGraphics/NamedColors.jl/commit/56325069d6915f026f3a45aebcc85bd15d8d1d53#commitcomment-71515796
Description: More color names than you ever knew you wanted

Closing infavor of
https://github.com/JuliaRegistries/General/pull/58677


[Bug]: Space missing after bold followed by a reference

Summary
The following rst:
**all** :ref:`data <tce-data>`

produces the following code:
alldata

Obviously, a space is missing after .
The same happens for italic:
*all* :ref:`data <tce-data>`

Code snippet that reproduces the problem
See summary
Expected output
A space between the closing tag and the link

I've had similar cases in the past when testing the Symfony documentation. I believe all those were caused by our own templates, and not by a bug in Guides.
You might want to check if this is reproducible in a test in this repository (or using the default theme).

I am able to reproduce this with the guides default templates... :-(


[Question/possibly bug] How paket.exe update package_id --filter should work

Hi,
We have a project(s) with around > 100 nuget packages. The update process for all of them tooks ~2minutes. Most of them are pinned to the specific version.
Is it possible to update only specific package and just check whether it's dependencies are fullfilled?
I've tried the following commands:
.paket\paket.exe update Newtonsoft.Json
and
.paket\paket.exe update Newtonsoft.Json --filter
It actually update a package, but after that it checks all other packages which are pinned to the specific version.
We need to execute an update command each time its built on our CI server to ensure we have a newest version (our internal company's library).
The question: should update with --filter argument resolve other packages?
Best regards,
MiloszeS

it still needs to check if the resolution is still valid. So requests are still needed to be done

Sounds fair in case the package has been updated.
Is it still valid in case the package won't be updated (it already has a newest version which is downloaded and is listed in the paket.lock file)? I've found it checks all versions also in case the update hasn't been done at any package.

that could probably made as an optimization step


initial run of "cmdeploy run" fails at "Request certificate for:"

Operating System (Linux/Mac/Windows/iOS/Android):

Server: up-to-date Ubuntu 23.10 (Matic)

chatmail Version:

commit 824f70f463e04eced87ffce37d2d345eb2ba81fb (HEAD -> main, origin/main, origin/HEAD)
Author: link2xt<EMAIL_ADDRESS>Date:   Wed Apr 10 17:46:18 2024 +0000
Document email authentication requirements

Expected behavior:

cmdeploy run:
completes without intervention; or
prompts for user input; or
terminates in an orderly fashion with instructions on what to do about the ToS agreement.

Actual behavior:

stops at error message "failed to request certificate: terms of service agreement is required, but user declined"

Steps to reproduce the problem:

First time execution of cmdeploy run on newly deployed server

Screenshots:
Logs:

You should be able to run git pull origin main --rebase and try to deploy it again :)


Registering a concrete type class breaks indexing of array

Describe the bug
When a concrete type class is created using vespa-documentgen-plugin, and then registered in services.xml, array<string> fields with {indexing: index} stop being indexed.
To Reproduce
A full reproduction repo is available at https://github.com/angelf/vespa-bug-report. In summary

Add a field of type array<string> with {indexing: index} to a schema and verify that search by that field works as expected
Register a concrete class generated with vespa-documentgen-plugin in services.xml with the <document> tag
Search by the field of type array<string> (YQL or userQuery)
The field stops matching
Other fields (for example of type string) are not affected - search works as expected for those

Note that:

PUT-ing documents does not show any error,
there are no messages in vespa.log
The generated document classes work as expected elsewhere (for example, they can be used fine in docproc: documents will get the correct class and can be manipulated using concrete classes)

Expected behavior
Search results should not be affected at all by registering a concrete type class.
Environment (please complete the following information):
I'm using ghcr.io/vespa-engine/vespa-arm64-preview on a Apple Silicon Mac
Vespa version

vespa on docker: 7.594.36
vespa-documentgen-plugin used at generation: 7.594.36

Yes, I've reproduced this.  The reason we have probably not spotted this before is that attribute has typically been used for array string fields. attribute implies match:word. Single valued strings (which are more commonly used with index) are handled as expected. What happens is that the indexing document processor does not tokenize the field, and instead indexes the entire content 'foo bar' as an entry in the dictionary, this then breaks for searching as the search will tokenize.
[{
    "put": "id:test:news::stack",
    "fields": {
        "title": ["foo bar"],
        "description": "foo bar"
    }
}]

Results in
vespa-index-inspect dumpwords --indexdir index.flush.2/ --field title
foo bar	1
vespa-index-inspect dumpwords --indexdir index.flush.2/ --field description
bar	1
foo	1

I also notice this from your pom.xml which is another problem we should address
 <!-- Turns out that vespa codegen generates code that raises warnings, which in turn make the project fail
            (-wError is implicitly set?). This is solved by injeciting a @SuppressWarnings at the begining of each generated
            class
            -->
            <plugin>
                <groupId>com.google.code.maven-replacer-plugin</groupId>
                <artifactId>maven-replacer-plugin</artifactId>
                <version>1.3.2</version>
                <executions>
                    <execution>
                        <phase>prepare-package</phase>
                        <goals>
                            <goal>replace</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <includes>
                        <include>target/generated-sources/vespa-documentgen-plugin</include>
                    </includes>

                    <regex>true</regex>
                    <regexFlags>
                        <regexFlag>MULTILINE</regexFlag>
                    </regexFlags>

                    <replacements>
                        <replacement>
                            <token>^(@SuppressWarnings\(.*?\)\s+)?public class</token>
                            <value>@SuppressWarnings("all") public class</value>
                        </replacement>
                    </replacements>
                </configuration>
            </plugin>

Lovely, great thanks for investigating this.

This is fixed by
https://github.com/vespa-engine/vespa/pull/25404
You need to switch to using docker.io/vespaengine/vespa (it has arm64 support already) to get a
newer vespa version; the fix should be in the next release (version >= 8.107.8).
Note that the problems where you needed to add @SuppressWarnings should be fixed already in Vespa 8.
This bug was caused by interaction between concrete document types and the indexing document processor.
Since concrete documents store array<string> straight-forward as a Java List<String> it's not possible
to add the tokenization information necessary in order to index individual words in each string.  Converting back
to the canonical format fixes this entire class of problems.

version with fix is now available from docker.


Add codec test

add codec unit tests for improving code coverage

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@4c45d81). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #442   +/-   ##
=========================================
  Coverage          ?   54.48%
=========================================
  Files             ?      128
  Lines             ?     5948
  Branches          ?      877
=========================================
  Hits              ?     3241
  Misses            ?     2423
  Partials          ?      284

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 4c45d81...59815c8. Read the comment docs.

It seems that tests are failing. @Handora

[INFO] Running com.pingcap.tikv.codec.CodecTest
[ERROR] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.078 s <<< FAILURE! - in com.pingcap.tikv.codec.CodecTest
[ERROR] readNWriteDateTimeTest(com.pingcap.tikv.codec.CodecTest)  Time elapsed: 0.009 s  <<< FAILURE!
org.junit.internal.ArrayComparisonFailure: arrays first differed at element [3]; expected:<-108> but was:<-107>
at com.pingcap.tikv.codec.CodecTest.readNWriteDateTimeTest(CodecTest.java:471)

Also if this PR is ready to review, you may request for review or tag this PR with reviewable

I have correct the error on timezone part

You might need to test #444 with this PR. So you could merge two PRs into one and edit corresponding title and description. @Handora

I think that they are two different parts, this one is focusing on codec
unit tests while the other is focusing on MyDecimal, they are separated.
And MyDecimal is still having some small bugs on fromDouble side and I am
implementing the part (for example: for the internal presentation like
1.2300003E5 and so on).
On Fri, Sep 7, 2018 at 2:36 PM birdstorm<EMAIL_ADDRESS>wrote:

You might need to test #444 https://github.com/pingcap/tispark/pull/444
with this PR. So you could merge two PRs into one and edit corresponding
title and description. @Handora https://github.com/Handora
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/pingcap/tispark/pull/442#issuecomment-419338266, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AX2fcncqg6sOTrcZHk2YFghCr5Aaz-0uks5uYhQFgaJpZM4WcltR
.

Yes, there are two parts here.

Fix MyDecimal
Add Codec test

If you want to fix MyDecimal, you need to validate whether it is correctly fixed. Thus you need to either move MyDecimal tests into #444, or merge #444 with this PR.

/run-all-tests


Update README

Remove bintray reference as it's no longer in existance and artifacts are on maven central
Update branch references for builds and coverage

Coverage remained the same at 93.781% when pulling d5d3dd55047cfd365db52b233ecadcce01e6699d on tgianos:updateReadme41x into 9dad1cdb29b49df5c177ad66fe3765c4368d7c1d on Netflix:4.1.x.


Update MXPagerView Version

When use viewControllers in tabs, losting navigationViewController

It has already be done on the develop branch.


Revert "Modified README.md and CONTRIBUTING.md for consistent capatilization."

Reverts TarasokUA/Notion-Enhancer#1
Sorry, I accidentally created a pull request on the wrong fork, please revert it.

np)

Thank a lot, I'm just getting my feet wet with git and GitHub \o/
Sorry for the trouble.

It's ok)


add unit test for client/httputils.go

Signed-off-by: ZouYu<EMAIL_ADDRESS>
Ⅰ. Describe what this PR did
add unit test for client/httputils.go
Ⅱ. Does this pull request fix one issue?

NONE
Ⅲ. Why don't you add test cases (unit test/integration test)? (你真的觉得不需要加测试吗？)
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews

Codecov Report

Merging #1258 into master will decrease coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1258      +/-   ##
==========================================
- Coverage   48.51%   48.50%   -0.02%
==========================================
  Files         121      121
  Lines        7682     7682
==========================================
- Hits         3727     3726       -1
  Misses       3649     3649
- Partials      306      307       +1

Impacted Files
Coverage Δ

supernode/daemon/mgr/scheduler/manager.go
21.91% <0.00%> (-0.69%)
:arrow_down:

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 bae7528...9abd23a. Read the comment docs.


Fix and Test Windows Batch Script

Currently only the Linux / Mac start script to start a local Metanome version is tested.
For Windows the Batch file start two Tomcat instances (Backend & Frontend) but closing them
when the Command window is closed doesnt work currently.
The Metanome Backend and Frontend instance running on Windows has to be closed using the task manager.

Fixed


Epochs.next() docs don't match behavior

Docstring says here that Epochs.next() returns an instance of mne.epochs.Epochs, but in fact it returns a numpy.ndarray (or a tuple of ndarray, event_id if return_event_id=True).  Personally I think the docs reflect how it should work, but it's obviously easier to just change the docs to reflect what it actually does.

indeed ... can you open a PR to fix the docstring?

Will do (tomorrow, it's rather late in utc-8).
On Apr 5, 2016 10:31 PM, "Alexandre Gramfort"<EMAIL_ADDRESS>wrote:

indeed ... can you open a PR to fix the docstring?
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/mne-tools/mne-python/issues/3099#issuecomment-206125756

@agramfort should I open a separate issue about the naming of next() vs. iter_data(), or is that a change that would be nice but will never happen?

We want the next method to exist because we need it for iteration. I'm fine with making a new iter_data method basically just a clearer alias for next, if that's what you have in mind.

well, what I have in mind is making next actually return an instance of Epochs (so that its methods are in place) and having a separate method like iter_data to iterate just the numpy arrays.  But that doesn't seem to be a popular view...  nobody is coming out and saying "we don't want to do that" but there seems to be ample support for the "just change the docs" approach.

I would say fix the doc for now. No rush for the rest. We have more urgent
matter to do. It's no blocker