text:
[RFC] Future of gpus/ipus/tpu_cores with respect to devices

Proposed refactoring or deprecation
Currently we have two methods to specifying devices. Let's take GPUs for example:

The standard case that we've all grown used to and are mostly aware of.

trainer = Trainer(gpus=2)

Introduced in 1.5, tries to make the number of devices agnostic. This means if you specify accelerator='tpu' we automatically know to use 2 TPU cores.

trainer = Trainer(devices=2, accelerator='gpu')

Recently, it has come up in https://github.com/PyTorchLightning/pytorch-lightning/pull/10404#discussion_r744562512 that we may want to deprecate and prevent further device specific names from appearing in the Trainer (such as hpus).
Related conversation https://github.com/PyTorchLightning/pytorch-lightning/issues/9053#issuecomment-904239610
I see two options:
🚀 We keep both device specific arguments (gpus tpu_cores ipus for the Trainer) and devices
👀 We drop gpus tpu_cores ipus in the future and fully rely on devices. (Potentially this would likely be done in Lightning 2.0, instead of after 2 minor releases)
cc @kaushikb11 @justusschock @ananthsub @awaelchli

IMO we should follow the contributing guidelines: https://github.com/PyTorchLightning/pytorch-lightning/blob/master/.github/CONTRIBUTING.md#main-core-value-one-less-thing-to-remember
Having multiple options in the public API to do the same thing is really confusing.

+1, totally agree
Current device related flags are confusing. Multiple flags partially overlap and interfere each other. When multiple flags passed in, we define prioritize and ignore some of the flags.
For example:
gpu=2, device=3 device will be ignored.
gpu=2, cpu=2, accelerator=cpu what will happen? I think cpu with num_process=2?
I prefer option 2, drop gpus, tpu_cores,  ipus in the future and fully rely on devices
And  can we have devices  be int, not set =auto?
With this option accelerator flag for device_type, devices (probably rename to devices_num?) for device_number. It's also scalable for new device types like hpus

I think going from this:
Trainer(gpus=2)

to
trainer = Trainer(devices=2, accelerator='gpu')

is a major step backwards in usability. now users have to dig into docs to understand how to use things. it definitely violates the "one-less-thing-to-remember" part of the API.
I guess, I'm just wondering why we're exploring this? I thought we were already pretty stable on the device API stuff

@williamFalcon The more kinds of accelerators we get, the more flags we will also have. Switching from Trainer(gpus=8) to Trainer(tpu_cores=8) also requires users to dig through the docs. Actually I find it easier to have Trainer(devices=2, accelerator='gpu'/'tpu') as the flags stay the same, it is easier to remember and also scaling better. So personally this would be the "one-less-thing-to-remember" for me.
Also I suspect, we would likely have the accelerator defaulting to 'auto' then which means that Trainer(devices=8) would run on gpu if available, on tpu if available and if no special accelerator is available it would fall back to cpu.

@williamFalcon As @justusschock shared, the previous approach doesn't scale well and makes exploration confusing.
Furthermore, the new API provides an auto as follows:
Trainer(devices="auto", accelerator="auto")

which would make the code runnable on every hardware without any code changes. Which isn't possible with the previous API.

To address the discoverability issue, isn't it common to import the Trainer and see what parameters are available? Isn't this more common that going to the docs to find the parameter?
I opened the issue as I felt it was important as a community we come to an agreement as the idea was floating around a few PRs (with inconsistent agreement). It's important to have one single direction here (especially as we introduce other accelerators). I do strongly disagree with removing gpus/tpu_cores/ipus/hpus/cpus from the Trainer for primarily ease/discoverability.
I think it would be beneficial to try get community votes on this, so maybe a post on our General slack channel is warranted?

Even something like gpus as lightning defines them today is ambiguous. PyTorch also supports AMD GPUs: https://pytorch.org/blog/pytorch-for-amd-rocm-platform-now-available-as-python-package/
But this isn't supported at all with Lightning because gpu assumes nvidia/cuda, whereas PyTorch's device allows for more backends.
In my head the accelerator in Lightning maps to the pytorch device being used. So why don't we preserve the same semantics PyTorch already offers for this to smoothen the transition and keep parity?

Adding to the conversation. In this issue, a user is requesting MIG instead of GPUs for A100 like a machine: https://github.com/PyTorchLightning/pytorch-lightning/issues/10529

@tchaton do we have a consensus to move forward with this issue?

Maybe thought that is a bit different there.
Going back to @williamFalcon argument that:
Trainer(gpus=2) to Trainer(devices=2, accelerator='gpu') is more work for the user.
My question here is that as far as I understand a correct me if I am wrong you have CPU and then either gpu/tpu/hpu/...
That is why you can have something as follow:
Trainer(devices=2, accelerator='gpu') where accelerator is only one combination.
I also assume that our users "don't" want to care if it is gpu/tpu/hpu.. as their code will remain the same as long as it is not CPU and even if it is CPU PL help you there to make it seamless.
Finally, we can automatically detect what kind of accelerator you have available today with auto.
That being said what if we had a "wrapper" around anything that is non CPU such that we can keep the same structure while making it "easy" for the users.
ie. Trainer(cpus=2,xpus=2) this will automatically find if x is gpu/tpu/hpu.
Then we allow default to be auto ie. Trainer(cpus=null,xpu=null) or could use -1 for example.

To take the pro-Accelerator argument to the extreme (also with the "fractional" devices), how about not splitting devices= and accelerator=?
If instantiating Accelerator all the time is too much of a hassle for @williamFalcon 's taste (I never liked the configuration part of tf sessions, either, and there is a good reason why PyTorch doesn't force you to do device = torch.Device("cuda") all over the thing but will just take "cuda"), how about:
Trainer(devices=2)   # I want two of whatever is available (so GPUs > CPUs in preference, but only the same kind.

Occasions where "casual users" will have TPU GPU and IPU in the same box will be rare enough...
This is breaking because it would make "GPU if available" the default :( (though I never understood why it is not).
For more elaborate configs, one could have
Trainer(devices=Accelerator("cuda", 2))

My apologies for adding another color of shed, but to my mind, there are these cases we want to cater to:

The easy one! Needing to instantiate Accelerator is a bit more API for people to remember than just gpus=.... Personally, I have to concentrate really hard to know how many c and l to put in there, too.
The turbopropower-user:  Would it not be more consistent and flexible to have Accelerator as the single truth about what their thing trains on? I certainly like to consider all my clusters of 512 DGXes for training BERT in 30 seconds a single device...
The unknown future. I think we'll see a lot more blur to "thing the training runs on = n devices of type a" that the proposed API of devices=2, accelerator=... suggests.

Best regards
Thomas

To add to @t-vi comment,
I believe the accelerator could be set to 'auto' by default as it is quite unlikely there is an overlapping machine with both GPUs and TPUs available.
So the hardware is totally abstracted and this provides an experience closer to Jax with their auto platform detection
Trainer(gpus=8) or Trainer(tpu_cores=8)  or Trainer(cpu=8)  or Trainer(hpus=8)  or Trainer(ipus=8) ...

would be replaced directly with:
Trainer(devices=2)

If a user has a machine with a GPU and wants to debug on CPU, he would simply add the accelerator to force the decision-making.
Trainer(devices=2, accelerator="cpu")

By the most critical point is:

I think we'll see a lot more blur to "thing the training runs on = n devices of type a" that the proposed API of devices=2, accelerator=... suggests.

I believe this API would need to provide a smarter hardware detection mechanism for MIG hardware.

Coming from both the High-Performance and embedded spaces, I'll weigh in here with some general thoughts.

Often with large clusters, we have models and/or datasets which can't fit on a single node. If the API says gpus=2 or tpus=2, what control do I have over where those devices are or which devices get used for which parts of the model? Should PTL support this type of deployment at all?

There are certain accelerators I might want to use which are only useful for inference but not training. FPGAs, for example, are really great for low-latency inference, but with the above API, do I have to instantiate a "Trainer" to use a device for inference? This makes little sense to me as a user. Is this something that PTL wants to support? If so, a rework is in order.

There is research being done on heterogeneous architectures which have GPUs, DSPs, etc. available on a single node. The distribution of work and communication between these devices is non-trivial and a scheduling nightmare, but it's not too far off. Virtualized communication technology like CXL and composable infrastructure like Liquid will enable these types of nodes to "exist" in a cloud or on-prem cluster. I think PTL should be forward thinking and have these types of setups in mind, especially if it is to be adopted by the research community as a usable tool.

A "device" as we think of it today (a GPU, a CPU) will likely be upended when in-memory processors come to the mainstream. (What is a "memory" device? How many "cores" does it have? It quickly loses any meaning). What about the Xilinx Versal architecture? It has many compute cores in a dynamic software-defined network fabric connected to an FPGA. It's one "device", but it's also many.

To the above points, I have a couple of suggestions:

The trainer should be agnostic to what it is executing on. It should be the object facilitating and orchestrating the training session (it is a trainer after all), but it shouldn't care what device is on the other end. If it does have knowledge of device-specifics, then as many of the users above pointed out, the API and argument count/complexity will explode if even just a few accelerators become mainstream and anything but basic training strategies are to be supported.

We should have an Accelerator API describing a device, its location, and its features. The average user shouldn't have to use this API at all, or even know it exists, and sane defaults should be set. However, it should be flexible enough to be used for cutting-edge device research. Where this accelerator API fits in the ecosystem is going to need to be decided by the community, but it shouldn't be passed to the trainer because if I have a device which is only for inference acceleration, then it makes no sense to create a trainer.

I am very interested to see where this discussion goes, and I apologize for the ramble.

This discussion has extended to other related points, but to give my opinion the original question, I fully agree with @tchaton's API vision here: https://github.com/PyTorchLightning/pytorch-lightning/issues/10410#issuecomment-972712672.
Where the original gpus, tpus, ... are deprecated and removed.
I don't think adding new options xpus=..., or devices=Accelerator("cuda", 2) should be in the cards anymore, as the new devices=..., format was just introduced in 1.5 and we would be once again deprecating this newly introduced functionality for a different thing. There's no clear winner here and we just need to choose one approach.

do I have to instantiate a "Trainer" to use a device for inference

it shouldn't be passed to the trainer because if I have a device which is only for inference acceleration, then it makes no sense to create a trainer.

Keep in mind that the Trainer has that name since it's been the core part of Lightning since the beginning, but it's way more than a "brainer" and could be thought of as an engine, for example, we have validate, test, and predict which are split from the training procedure

A lot of great inputs! Let me start off by summarizing:
The current API was built when only GPUs were supported. Then TPUs were added. And now a few years later, we live in a world where more alternatives are starting to emerge. This is the current API.
Trainer(gpus=2)
Trainer(tpus=2)

But now, we live in a world where more than GPU|TPU devices are coming out (HPU, etc...). In this case, the proposal is to modify the API like so:
Trainer(devices=2, accelerator='tpu')

Well... we also introduced the 'auto' flag, so the actual default call would look like this:
Trainer(devices=2)

# because Trainer(devices=2, accelerator='auto') is the default

@t-vi also brought up the alternative that there could be a class in the event that configs get unwieldy
Trainer(accelerator=Accelerator("cuda", 2))

@dlangerm also brought up that in certain complex scenarios:

Multinode training (which we've supported from day 1 @dlangerm, and you specify the num_nodes argument). Today we already support selecting many configurations here, so i'm not sure what a relevant usecase is.
Yes, PL already supports inference. We can think about configurations during inference needing a "Trainer" (@tchaton @carmocca maybe "Trainer" needs to be renamed in 2.0)
Heterogenous hardware is an awesome upcoming research challenge that we'll be excited to tackle next year. But today, it's premature until research matures a bit more.
In-memory processors also sound promising. If you know of a real use case, happy to collaborate on working out how to do something like that.
@dlangerm we do have an accelerator API (it's been there since 1.0)... it's just used internally and not exposed to the user.

Decision
So, with all that said, if there's broader community support for moving from:
Trainer(gpus=2)

to:
Trainer(devices=2, accelerator='tpu')

# default is auto
Trainer(devices=2)

Then I'm happy to back this option as it is more scalable and my only concern is "having to only remember one thing"...
So, I'd love to hear more from the community about the effect on usability.
if there are no major quelms about this and everyone's excited, let's roll it out for 2.0
cc @tchaton @carmocca @ananthsub @daniellepintz

I have a question about this; if we want to roll this out for 2.0 when can we start working on it? Could we start working on it now for example?

@tchaton  @awaelchli  @ananthsub What's you guys' thought on when will be the right time for 2.0? Should Accelerator Refactor and stable accelerator be part of the 2.0?
I think it's better to have big changes once. I will prefer having accelerator stable version and the flags addressed in the same version. It's easier to communicate with users and reduce future confusings.

Hey @daniellepintz @four4fish.
Yes, I agree with you both. I don't believe this change requires a Lightning 2.0 as this is a natural evolution of Lightning becoming hardware-agnostic directly at the Trainer level.
IMO, I would like to action this change for v1.6. @ananthsub @awaelchli @carmocca @kaushikb11 @justusschock  Any thoughts on this ?

Agreed. We could go ahead with this change for v1.6, along with major Accelerator refactor.

Given the above decisions, is there a consensus on renaming Trainer to something more appropriate for the "Brain" or "Engine" that is has become?
If these changes are towards a hardware-agnostic API that can be used for either training or inference, Trainer will become very confusing. Even today, creating a Trainer instance to perform Trainer.predict is fairly unintuitive.

@dlangerm this is not really related to this issue, so I won't go into much detail here. Feel free to open a new issue for this discussion.
From my POV, we shouldn't rename the Trainer before 2.0.
Renaming flags is one thing (and we will need to have a pretty long deprecation cycle for those), but renaming the major components as the Trainer or LightningModule would be too much of a breaking change since this could also break the API in all other places as well.

Hey @kaushikb11 I saw you assigned yourself to this issue. I was planning on working on the accelerator_connector refactor (https://github.com/PyTorchLightning/pytorch-lightning/issues/10422) which was blocked by this issue. Am I okay to proceed with accelerator_connector refactor or is that something you were planning on doing?

I am working on this in #11040 - do we also want to deprecate num_processes and num_nodes?

I think num_processes yes, but num_nodes we might still need in case of multi-node training

Got it, thanks!

authors: SeanNaren ananthsub carmocca daniellepintz dlangerm four4fish justusschock kaushikb11 t-vi tchaton williamFalcon zippeurfou

repo: PyTorchLightning/pytorch-lightning


text:
Calling module.log(...) within a callback fails

🐛 Bug
Calling pl_module.log(...) within a Callback fails, even though this is recommended by the documentation here: https://pytorch-lightning.readthedocs.io/en/latest/loggers.html#logging-from-a-callback
Error
  File "my_callback_file.py", line XX, in on_validation_epoch_end
    pl_module.log_dict(my_metrics_dict)
  File "/home/local/USHERBROOKE/pain5474/opt/miniconda3/envs/cav/lib/python3.8/site-packages/pytorch_lightning/core/lightning.py", line 287, in log_dict
    self.log(
  File "/home/local/USHERBROOKE/pain5474/opt/miniconda3/envs/cav/lib/python3.8/site-packages/pytorch_lightning/core/lightning.py", line 233, in log
    self._results.log(
  File "/home/local/USHERBROOKE/pain5474/opt/miniconda3/envs/cav/lib/python3.8/site-packages/pytorch_lightning/core/step_result.py", line 171, in log
    self.__set_meta(
  File "/home/local/USHERBROOKE/pain5474/opt/miniconda3/envs/cav/lib/python3.8/site-packages/pytorch_lightning/core/step_result.py", line 217, in __set_meta
    _internal = self['meta']['_internal']
KeyError: '_internal'
python-BaseException

cc @nathanpainchaud
This is happening on master
Expected behavior

We can log from callbacks using the lightning module
Environment
Happening on PyTorch Lightning master

@ananthsub I just tried on master and cannot reproduce (I think it was solved yesterday, as I could reproduce 2 days ago).

@SkafteNicki The issue was created by @ananthsub based on a question/issue I initially raised in the slack. I'll try to see if the bug is now resolved on master for me (it was still present as of yesterday afternoon) and I'll update you here as soon as I can.

Hey @nathanpainchaud,
Did you manage to reliably reproduce this behaviour? And if yes, could share the draft PR associated with this issue ?
I will try to try it out too.
Best regards,
Thomas Chaton.

Hey @tchaton,
Thanks for the follow up! I opened the draft PR where I added a test that reproduces the behavior I'm getting.
If I can help in any other way to get this sorted, just let me know!

@tchaton Any updates on whether this is a feature that's planned to be supported, or on the contrary it's been abandoned? I'm only asking this question because the issue has been labelled priority for a while, but every PR referring to it have been closed without getting merged :laughing:

Yes! thats been worked on these weeks. Starting to be merged now (https://github.com/PyTorchLightning/pytorch-lightning/pull/4439)

I still have problems logging my validation metrics using pl_module.log() in the on_validation_end() hook. Any thoughts?

source: gharchive/issue

authors: SkafteNicki aligholami ananthsub nathanpainchaud tchaton williamFalcon

license_type: permissive

license_source: github-api


text:
Horovod & py3.8

What does this PR do?
resolving Horovod as discussed in #2745
PR review
Anyone in the community is free to review the PR once the tests have passed.
If we didn't discuss your PR in Github issues there's a high chance it will not be merged.
Did you have fun?
Make sure you had fun coding 🙃

LGTM!  Thanks @Borda!

Surprisingly simple. LGTM 😄

yeah, we shall keep PR as simple as possible to the review is quick...

source: gharchive/pull-request

authors: Borda tgaddair


text:
Stable version as default in docs

Is your feature request related to a problem? Please describe
Most users install PyVRP through PyPI and so they use the stable version. However, www.pyvrp.org shows the documentation for the latest development version by default, possibly confusing users when they find features in the docs that aren't released yet.
Describe the solution you'd like

www.pyvrp.org should default to the stable version of PyVRP.
www.pyvrp.org/dev should default to the latest development version of PyVRP.

I'll pick this up. We're getting many questions about stuff not working because of this 😅

We also have the "older" docs hosted in this repository: https://github.com/PyVRP/PyVRP.github.io. Those are available at https://pyvrp.github.io/v0.7.0/, and so one. It'd be nice if we can somehow merge all that together so that:

pyvrp.org -> latest stable
pyvrp.org/dev -> latest build on main
pyvrp.org/v<version> -> docs associated with version <version>

I don't really know how to do this. I do know statsmodels has things set up exactly this way. Maybe we can borrow some of their setup for our own purposes?

I'm assigning this for 0.9.0, since we really ought to solve this ASAP.

I'm looking into how statsmodels does it for the next hour and will make notes in this comment.

Alright I had hoped to work on this today, but the devcontainer stuff took a little longer and now it's getting late. There's always tomorrow :).

I don't want this to block a release of 0.9.0, but I'll try to finish it in the coming week.

Possibly interesting: https://github.com/jimporter/mike?tab=readme-ov-file

I feel like I keep postponing this, but at some point we really ought to pick this up 😆

authors: N-Wouda leonlan

repo: PyVRP/PyVRP

license: MIT


text:
can't install version 3.2.x with python2

I'm not able to install version 4.2.1, due to importlib.util not being found.
I'm not sure exactly which module I need to install to meet this dependency.
I didn't experience this issue with version 3.1.x
[root@black markdown-3.2.1]# python2.7 setup.py
Traceback (most recent call last):
  File "setup.py", line 39, in <module>
    __version__, __version_info__ = get_version()
  File "setup.py", line 32, in get_version
    import importlib.util
ImportError: No module named util

As noted in the release notes, we dropped support for Python 2.7 in version 3.2. You have two options:

Update to Python 3.5 or later.
Continue to use Python-Markdown 3.1 with Python 2.7.

I suppose we could test and add an error message to the setup.py script. We did include an error message for those who have a develop install of the package. And pip will refuse to install 3.2 on Python 2.7 due to the meta-data mismatch.

Thanks for pointing that out. I'll continue using Python-Markdown 3.1 for now. It looks like transitioning to Python3 is going to be inevitable at some point, which is ultimately a good thing.

authors: leifliddy waylan

repo: Python-Markdown/markdown


text:
[Demo requested] Full example on one-to-many and many-to-many relationships

Hello,
I like pretty much the idea and the layout of PyNest.
Could you please provide a demo project that has users, products modules, with many-to-many and one-to-mant relationships between them ? maybe two demos for the 2 relationships could be better.
And how user interacts with product ? by using services or something else ?
I asked for this because if seems that the examples given in the repo only show the cases that user and product are independent.

Hello! Thank you for your words.
Basically, you were correct with you assumption that user and product will talk with each other using services. In that way, product service can inject user service and perform query operations on the user assets. Nest is really about organise your  code in small and decoupled lego pieces that helps you to build robust application.
I have a few examples i can share and i will upload them asap to the PythonNest organisation.

Hello @copdips
I have an awesome news for you!
I've just public one of my pynest projects, an application for managing stocks that demonstrate the powerful architecture of nestjs in python.
This is the link to the project - https://github.com/ItayTheDar/Stockify
Thanks again for bringing this issue to our community!

awesome, thanks

authors: ItayTheDar copdips

repo: PythonNest/PyNest


text:
Keithley 2600 4probe

This PR adds a new mode to the doFastSweep function of the of Keithley 26xx
The new mode allows for 4 probe measurements
@jenshnielsen

Agree with @astafan8 that we should not promote the Measurement but use the "new" dataset in the examples if possible. Otherwise this looks good

@astafan8 I have updated the notebook to use fastsweep in combination with a d0d. We could also make a new function(do_faste_sweep) in the driver wrapping the d0d. So performing the fastsweep stays a one-liner?

I have updated the notebook to use fastsweep in combination with a d0d

perfect!!! thank you!

We could also make a new function(do_faste_sweep) in the driver wrapping the d0d. So performing the fastsweep stays a one-liner?

no, that would be mixing concerns for negligible benefit -- do*d is already a one-liner-ish :) and the fact that doFastSweep exists as a method is just historical and shouldn't have been added in the first place.

repo: QCoDeS/Qcodes


text:
Average of different prediction horizons as a metric?

Hello Authors,
Could you please clarify the usage of the average of different prediction horizons as a benchmarking metric? Why was it used, and how to justify the validity of this?
I am doing a similar project and trying to report values at different horizons. My model is not getting values close to those reported in SOTA (top 5) models like yours.  Could you please help with the intuition on reporting the average rather than individual horizons?
Thanks
Santosh

IIRC that's a convention inherited by Informer and the followup works to it that have come out since this repo's initial release and before it's more recent versions. The accuracy of individual timesteps into the future can be arbitrary and hard to interpret. 1 step predictions are too easy, but distant predictions can be very difficult given a fixed length context window which may be too short. In highly periodic domains some distant horizons can also be easy (such as 24 hours ahead in a dataset with clear daily periodicity like weather forecasting). So reporting every horizon metric takes a lot of explaining, large tables, and can be misleading. Averaging gives a better sense of the model's performance over the entire duration we care about.
At a few points during this project I hacked together logging metrics for accuracy at each individual timestep as a sanity-check. In my experience you can expect a roughly linearly increasing error as you predict further into the future.
As far as replicating the results on these datasets in your own project, double check that you aren't counting missing datapoints in the metrics. This can make a huge difference and is something a lot of the literature (and early versions of this codebase) get wrong.

I agree with Jake, averaging over the whole prediction horizon makes sense in order to compare single numbers as a metric.
It is a pity though that different benchmarks use different metrics.
For example, check here for PEMS-Bay:
https://paperswithcode.com/sota/traffic-prediction-on-pems-bay
They report RMSE (I guess this is averaged over the whole horizon)
and MAE @ 12 step (this is for a single prediction 12 steps into the future)
It would be good to have more standardized metrics.
In the paper there is no RMSE for PEMS-Bay. There is MAE, MSE and MAPE, but unfortunately PapersWithCode does not report those.
This is not a question, just a comment, sorry for the spam! 😁

Yeah the traffic datasets / literature is the main example where reporting multiple horizons is the default. The longest horizons are 12 timesteps so this can be feasible. Once you get longer than that it stops making sense to report arbitrary intervals in tables in my opinion. It would be interesting if the convention for reporting forecasting results was a plot of error over forecast duration for each dataset. That wasn't necessary at the time (2021) but I think this is probably what I would do if I were to redo this project today...

authors: jakegrigsby santoshatchi steve3nto

repo: QData/spacetimeformer


text:
Maybe a @compile decorator?

I would like to discuss the possibility of adding something like a @compile decorator that compiles the Python functions/classes when the python module in imported and reuse the compiled JS. So only the load time will be affected, not the execution time.
This way we don't have to worry about manually compiling Python into JS.
If you like this suggestion, I can work on it.
Code example:
# events.py

@compile
def show_alert(e):
    e.preventDefault()
    alert("boom!")

# index.py

from htmldoom import render, elements as e
from events import show_alert

render(e.a(onclick=show_alert)("Click me"))
#  {e.preventDefault(), alert('boom!')}">Click me

Update:
If this is possible. I'm not sure.

Closing this due to lack of interest.

repo: QQuick/Transcrypt

license_source: bigquery


text:
数字货币DataStruct resample的一个warning，引入了一些talib没有的好指标

QUANTAXIS PR 😇
感谢您对于QUANTAXIS的项目的参与~ 🛠请在此完善一下最后的信息~
注意

如果非第一次fork, 请先将quantaxis 库的内容PR进您的项目进行更新, 然后再执行对于quantaxis的pr
请完善CHANGELOG再进行PR

PR前必看
请使用如下代码对要PR的代码进行格式化:
使用以下代码来格式化
pip install https://github.com/google/yapf/archive/master.zip
yapf -i --style .style.yapf <file>

🛠该PR主要解决的问题🛠:
完全用nparray传递参数的talib库，原因是用nparray因为没有 Series MultiIndex 的问题。
处理和补完速度都比pandas更快，转 pd.DataFrame/pd.Series 只需要一个构造函数。
我还引入了一些talib没有，但是写出来不超过10行代码，很容易实现好指标，源自外网(TradingView或者MQ4/5)找到的。
例如
Moving Average ADX
Hull Moving Average
Volume HMA(未完成)
作者信息:阿财
时间: 2020/03/07

Hello @Rgveda! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file QUANTAXIS/QAAnalysis/QAAnalysis_signal.py:

Line 39:1: E302 expected 2 blank lines, found 1
Line 58:80: E501 line too long (108 > 79 characters)
Line 75:74: W291 trailing whitespace
Line 118:80: E501 line too long (100 > 79 characters)
Line 255:1: W293 blank line contains whitespace
Line 256:80: E501 line too long (174 > 79 characters)
Line 257:52: E231 missing whitespace after ','
Line 258:52: E231 missing whitespace after ','
Line 259:53: E231 missing whitespace after ','
Line 260:54: E231 missing whitespace after ','
Line 262:80: E501 line too long (91 > 79 characters)
Line 263:80: E501 line too long (83 > 79 characters)
Line 264:80: E501 line too long (84 > 79 characters)
Line 271:80: E501 line too long (86 > 79 characters)
Line 272:80: E501 line too long (86 > 79 characters)
Line 273:80: E501 line too long (104 > 79 characters)
Line 274:80: E501 line too long (104 > 79 characters)
Line 278:80: E501 line too long (94 > 79 characters)
Line 279:80: E501 line too long (95 > 79 characters)
Line 280:80: E501 line too long (90 > 79 characters)
Line 281:80: E501 line too long (90 > 79 characters)
Line 285:80: E501 line too long (191 > 79 characters)
Line 286:80: E501 line too long (191 > 79 characters)
Line 287:80: E501 line too long (143 > 79 characters)
Line 287:109: E712 comparison to True should be 'if cond is True:' or 'if cond:'
Line 288:80: E501 line too long (143 > 79 characters)
Line 288:109: E712 comparison to True should be 'if cond is True:' or 'if cond:'
Line 289:80: E501 line too long (83 > 79 characters)
Line 290:80: E501 line too long (83 > 79 characters)
Line 291:80: E501 line too long (221 > 79 characters)
Line 292:80: E501 line too long (226 > 79 characters)
Line 294:80: E501 line too long (116 > 79 characters)
Line 295:80: E501 line too long (116 > 79 characters)
Line 297:44: E231 missing whitespace after ','
Line 309:1: W293 blank line contains whitespace
Line 310:80: E501 line too long (105 > 79 characters)
Line 311:46: E231 missing whitespace after ','
Line 312:46: E231 missing whitespace after ','
Line 313:47: E231 missing whitespace after ','
Line 314:48: E231 missing whitespace after ','
Line 316:80: E501 line too long (88 > 79 characters)
Line 323:80: E501 line too long (80 > 79 characters)
Line 324:80: E501 line too long (80 > 79 characters)
Line 326:80: E501 line too long (98 > 79 characters)
Line 327:80: E501 line too long (98 > 79 characters)
Line 337:53: W291 trailing whitespace
Line 338:23: E231 missing whitespace after ','
Line 338:35: E231 missing whitespace after ','
Line 338:57: E231 missing whitespace after ','
Line 340:43: E231 missing whitespace after ','
Line 342:80: E501 line too long (125 > 79 characters)
Line 345:80: E501 line too long (85 > 79 characters)
Line 347:80: E501 line too long (89 > 79 characters)
Line 348:80: E501 line too long (83 > 79 characters)
Line 349:80: E501 line too long (89 > 79 characters)
Line 350:80: E501 line too long (99 > 79 characters)
Line 351:80: E501 line too long (89 > 79 characters)
Line 352:80: E501 line too long (83 > 79 characters)
Line 353:80: E501 line too long (89 > 79 characters)
Line 354:80: E501 line too long (99 > 79 characters)
Line 355:80: E501 line too long (118 > 79 characters)
Line 356:80: E501 line too long (119 > 79 characters)
Line 357:80: E501 line too long (108 > 79 characters)
Line 358:80: E501 line too long (108 > 79 characters)
Line 361:1: E305 expected 2 blank lines after class or function definition, found 1
Line 362:1: E302 expected 2 blank lines, found 0
Line 370:1: W293 blank line contains whitespace
Line 371:40: E231 missing whitespace after ','
Line 371:53: E231 missing whitespace after ','
Line 372:42: E231 missing whitespace after ','
Line 372:54: E231 missing whitespace after ','
Line 373:47: E231 missing whitespace after ','
Line 373:60: E231 missing whitespace after ','
Line 373:72: E231 missing whitespace after ','
Line 374:80: E501 line too long (126 > 79 characters)
Line 375:1: W293 blank line contains whitespace
Line 376:41: E231 missing whitespace after ','
Line 376:63: E231 missing whitespace after ','
Line 377:42: E231 missing whitespace after ','
Line 377:54: E231 missing whitespace after ','
Line 378:47: E231 missing whitespace after ','
Line 378:59: E231 missing whitespace after ','
Line 378:72: E231 missing whitespace after ','
Line 379:80: E501 line too long (126 > 79 characters)
Line 381:80: E501 line too long (105 > 79 characters)
Line 395:1: W293 blank line contains whitespace
Line 400:1: W293 blank line contains whitespace
Line 401:80: E501 line too long (145 > 79 characters)
Line 404:80: E501 line too long (84 > 79 characters)
Line 405:80: E501 line too long (84 > 79 characters)
Line 406:1: W293 blank line contains whitespace
Line 409:80: E501 line too long (100 > 79 characters)
Line 411:80: E501 line too long (90 > 79 characters)
Line 412:80: E501 line too long (90 > 79 characters)
Line 413:80: E501 line too long (107 > 79 characters)
Line 414:80: E501 line too long (107 > 79 characters)
Line 423:80: E501 line too long (129 > 79 characters)
Line 424:40: E231 missing whitespace after ','
Line 425:1: W293 blank line contains whitespace
Line 429:80: E501 line too long (144 > 79 characters)
Line 430:80: E501 line too long (146 > 79 characters)
Line 432:59: E231 missing whitespace after ','
Line 433:35: E231 missing whitespace after ','
Line 436:1: W293 blank line contains whitespace
Line 437:80: E501 line too long (100 > 79 characters)
Line 442:52: E231 missing whitespace after ','
Line 443:52: E231 missing whitespace after ','
Line 444:52: E231 missing whitespace after ','
Line 445:55: E231 missing whitespace after ','
Line 446:55: E231 missing whitespace after ','
Line 447:62: E231 missing whitespace after ','
Line 448:80: E501 line too long (104 > 79 characters)
Line 449:80: E501 line too long (104 > 79 characters)
Line 450:22: W292 no newline at end of file

In the file QUANTAXIS/QAIndicator/talib_numpy.py:

Line 149:17: W291 trailing whitespace
Line 154:80: E501 line too long (107 > 79 characters)
Line 161:80: E501 line too long (146 > 79 characters)
Line 172:47: W291 trailing whitespace
Line 184:80: E501 line too long (105 > 79 characters)
Line 190:80: E501 line too long (94 > 79 characters)
Line 190:85: E203 whitespace before ','
Line 191:80: E501 line too long (81 > 79 characters)
Line 192:80: E501 line too long (86 > 79 characters)
Line 194:80: E501 line too long (84 > 79 characters)
Line 197:23: W291 trailing whitespace
Line 198:80: E501 line too long (82 > 79 characters)
Line 200:80: E501 line too long (107 > 79 characters)
Line 201:21: W292 no newline at end of file

In the file QUANTAXIS_Test/QAAnalysis_Test/QASignal.py:

Line 9:80: E501 line too long (137 > 79 characters)
Line 10:58: E231 missing whitespace after ','
Line 11:13: E128 continuation line under-indented for visual indent
Line 12:13: E128 continuation line under-indented for visual indent
Line 13:13: E128 continuation line under-indented for visual indent
Line 14:13: E128 continuation line under-indented for visual indent
Line 15:5: E265 block comment should start with '# '
Line 16:5: E265 block comment should start with '# '
Line 22:80: E501 line too long (105 > 79 characters)
Line 28:22: W291 trailing whitespace
Line 40:9: E128 continuation line under-indented for visual indent
Line 45:71: E231 missing whitespace after ','
Line 46:71: E231 missing whitespace after ','
Line 47:71: E231 missing whitespace after ','
Line 48:76: E231 missing whitespace after ','
Line 50:80: E501 line too long (82 > 79 characters)
Line 52:80: E501 line too long (109 > 79 characters)
Line 54:67: E712 comparison to True should be 'if cond is True:' or 'if cond:'
Line 54:80: E501 line too long (101 > 79 characters)
Line 55:80: E501 line too long (152 > 79 characters)
Line 55:99: E251 unexpected spaces around keyword / parameter equals
Line 55:101: E251 unexpected spaces around keyword / parameter equals
Line 56:80: E501 line too long (157 > 79 characters)
Line 56:99: E251 unexpected spaces around keyword / parameter equals
Line 56:101: E251 unexpected spaces around keyword / parameter equals
Line 58:80: E501 line too long (170 > 79 characters)
Line 59:80: E501 line too long (120 > 79 characters)
Line 60:80: E501 line too long (104 > 79 characters)
Line 61:76: E712 comparison to True should be 'if cond is True:' or 'if cond:'
Line 61:80: E501 line too long (110 > 79 characters)
Line 63:80: E501 line too long (178 > 79 characters)
Line 64:80: E501 line too long (99 > 79 characters)
Line 65:80: E501 line too long (104 > 79 characters)
Line 66:79: E712 comparison to True should be 'if cond is True:' or 'if cond:'
Line 66:80: E501 line too long (113 > 79 characters)
Line 68:80: E501 line too long (183 > 79 characters)
Line 69:80: E501 line too long (99 > 79 characters)
Line 70:80: E501 line too long (163 > 79 characters)
Line 71:80: E501 line too long (104 > 79 characters)
Line 72:79: E712 comparison to True should be 'if cond is True:' or 'if cond:'
Line 72:80: E501 line too long (113 > 79 characters)
Line 74:23: E251 unexpected spaces around keyword / parameter equals
Line 74:25: E251 unexpected spaces around keyword / parameter equals
Line 74:29: E231 missing whitespace after ','
Line 75:80: E501 line too long (102 > 79 characters)
Line 76:80: E501 line too long (112 > 79 characters)
Line 76:92: E251 unexpected spaces around keyword / parameter equals
Line 76:94: E251 unexpected spaces around keyword / parameter equals
Line 76:105: E251 unexpected spaces around keyword / parameter equals
Line 76:107: E251 unexpected spaces around keyword / parameter equals
Line 77:80: E501 line too long (108 > 79 characters)
Line 78:80: E501 line too long (112 > 79 characters)
Line 78:92: E251 unexpected spaces around keyword / parameter equals
Line 78:94: E251 unexpected spaces around keyword / parameter equals
Line 78:105: E251 unexpected spaces around keyword / parameter equals
Line 78:107: E251 unexpected spaces around keyword / parameter equals
Line 79:80: E501 line too long (85 > 79 characters)
Line 80:80: E501 line too long (91 > 79 characters)
Line 81:80: E501 line too long (93 > 79 characters)
Line 82:80: E501 line too long (93 > 79 characters)
Line 83:80: E501 line too long (112 > 79 characters)
Line 84:80: E501 line too long (112 > 79 characters)

In the file QUANTAXIS_Test/QAAnalysis_Test/QASignal_ADXm_Test.py:

Line 11:1: E302 expected 2 blank lines, found 1
Line 12:5: E265 block comment should start with '# '
Line 16:61: E231 missing whitespace after ','
Line 21:23: E251 unexpected spaces around keyword / parameter equals
Line 21:25: E251 unexpected spaces around keyword / parameter equals
Line 21:29: E231 missing whitespace after ','
Line 24:80: E501 line too long (180 > 79 characters)
Line 25:80: E501 line too long (82 > 79 characters)
Line 28:5: E741 ambiguous variable name 'l'
Line 31:5: E265 block comment should start with '# '
Line 35:1: E305 expected 2 blank lines after class or function definition, found 1

In the file QUANTAXIS_Test/QAAnalysis_Test/QASignal_hull_MA_Test.py:

Line 10:1: E302 expected 2 blank lines, found 1
Line 12:9: E128 continuation line under-indented for visual indent
Line 24:23: E251 unexpected spaces around keyword / parameter equals
Line 24:25: E251 unexpected spaces around keyword / parameter equals
Line 24:29: E231 missing whitespace after ','
Line 26:80: E501 line too long (180 > 79 characters)
Line 28:5: E265 block comment should start with '# '
Line 29:5: E265 block comment should start with '# '
Line 34:5: E741 ambiguous variable name 'l'
Line 34:6: E225 missing whitespace around operator
Line 40:1: E305 expected 2 blank lines after class or function definition, found 1
Line 40:12: E225 missing whitespace around operator

In the file QUANTAXIS_Test/QAFetch_Test/QAQuery_Advance_Test.py:

Line 844:1: W293 blank line contains whitespace

repo: QUANTAXIS/QUANTAXIS

license: mit


text:
leethub not working at all for me. i have solved more than 20 questions but not a single question pushed to my github

Please review previous closed issues before filling out a new one! Duplicate issues will be closed without comment.
Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.

leethub not working for me
i have solved more than 20 questions since i have added leethub extensions. I don't why but not a single solution pushed to github.

Switch to older version of leetcode .
There will be an option Revert to older version in drop down menu

repo: QasimWani/LeetHub


text:
how to use distributed partitioning

I change partitionMode   to  ParMETIS ,but it  seems to have no effect.

I change partitionMode to ParMETIS ,but it seems to have no effect.

@leepengcheng  ParMETIS still in development, will be published before November as expected.

authors: leepengcheng ryantd


text:
IAM topics

Adding some of the IAM-related topics.  There will be a lot of broken links and other issues until we solidify what all topics are being added and where.

Cleanup and move to another repo

authors: abbycross beckykd

repo: Qiskit/documentation


text:
Small fix in DragCalAnalysis model descriptions

Summary
This PR adds a missing freq parameter to the DragCalAnalysis model descriptions and to the formulas in the docstring.
Details and comments
See code.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

authors: CLAassistant catornow

repo: Qiskit/qiskit-experiments


text:
Allow to trigger workflow that publishes the documentation manually

Summary
Details and comments
Fixes #

Pull Request Test Coverage Report for Build 1912399559

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 56.778%

Totals

Change from base Build 1912304137:
0.0%

Covered Lines:
2044

Relevant Lines:
3600

💛  - Coveralls

authors: coveralls rathishcholarajan

repo: Qiskit/qiskit-ibm-runtime


text:
Batching of circuits to overcome memory issues when using statevector simulator

Summary
Currently batch_size parameter is ignored if the statevector simulator is used. This leads to unreasonable memory use due to the size of the transpiled circuits, up to 1TB of RAM for 800 by 800 kernel matrix and 20 qubits (see qiskit-terra, issue #6991). This pull request fixes this by transpiling and simulating circuits in batches, never storing the entire 800 circuits. The modification uses batch_size parameter that is already used in non-statevector case.
Details and comments
I had success by setting batch_size=50 (memory footprint down to <20 GB).

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

@rsln-s Thanks a lot for your contribution. Could you please add a reno file with a bug fix description? Also, if possible add a test to cover this fix.
@attp could you please take a look at the changes?

Added reno file. The correctness of the output of the code is checked by tests already in place; testing the memory usage may be complicated within constraints of gh-actions.

The spell checker also fails on this transpiled  word from the release note. If you add it to .pylintdict file in the root, our custom dictionary, since its correctly spelt then it should pass CI. (You will see the words are in lowercase in alphabetic order so just add it appropriately)

Updated the .pylintdict dictionary

@woodsp-ibm Do you have any comments?

Can I ask  you to make a minor change to the docstring for batch_size in the constructor. It says

batch_size: Number of circuits to batch together for computation. Default 1000.

specifically default 1000 yet the code has

batch_size: int = 900,

So it should state the default is 900. I think it may have been 1000 at one point but was changed, if I recall correctly, to 900 to fit more with the limits around the provider.
In terms of testing you say its covered by the current unit tests. From what I can see there is nothing explicitly testing that aspect. Of course batch_size defaults to 900 and is in main path. I am not sure what we do in test is ever affected by the batch size since from what I can see the tests are pretty small. Having said that if we had a test that dropped the batch size down I am not sure how to test it given its behavior is internal to evaluate - the only way comes to mind is hooking the quantum instance execute and checking the number of circuits is as expected along the way in addition the the final result being as expected.

Looks good to me.
Regarding the batch_size docstring, you are correct @woodsp-ibm the default was originally 1000, and we changed it to 900 to match the backend limits and reduce the number of jobs sent. I must have missed updating the docstring in the PR.

Updated the docstring as requested by @woodsp-ibm.

Just a note. Locally I changed the QuantumInstance execute method to print the number of circuits it was passed and ran the kernel unit tests. Its quite a small number so nowhere near the 900 limit - in fact its not even in double digits. Anyway I changed default back size in the kernel to a much small number and things worked but not all numbers were limited - presumably the ones via statevector usage as I was doing this from the main branch. Cloning your fork and doing the same from there then all the counts were limited - in fact I set it to 1 as a test and it printed all 1's and passed. So it seems its working ok. It would be nice if the test did somehow test out the batch size but maybe that could/should be raised as a separate issue. @adekusar-drl any thoughts here - you commented early on about a test around the fix.

@woodsp-ibm When I mentioned unit tests I did not have anything special on my mind. In general, your idea of setting batch size to 1 and then running a test on the statevector simulator make sense.
@rsln-s What do you think?

In general, your idea of setting batch size to 1 and then running a test on the statevector simulator make sense.
I had done it so it applied to the qasm mode as well - since it appeared not tested in general. While the final outcome can be checked as currently, what is more complicated to do is to check that indeed the batch size is limiting the number of internal computations (circuits). My only thought on perhaps how to do such a check. as I mentioned in an earlier comment was about hooking the QuantumInstance execute method on the instance used with the backend such that the number of circuits given to the method could be fairly easily intercepted and checked - i.e hook it and do whatever was needed to check then call over to the original method that was hooked so that the circuit results from execute can be returned.

@woodsp-ibm I approve, merge this PR and open an issue to improve tests for QuantumKernel. Any thoughts?

authors: CLAassistant adekusar-drl attp rsln-s woodsp-ibm

repo: Qiskit/qiskit-machine-learning


text:
Update git blame rev ignore list

Summary
In the recently merged #7615 we bumped the black version and constrained
it to a stable version to keep us on a fixed set of formatting rules but
also receiving bug fixes. In doing this some new formatting rules were
applied to the repo (mainly x ** y was changed to x**y) by the new
version of black. To reduce noise in the git blame this commit updates
the .git-blame-ignore-revs file (which was added after we started using
black in #6362) to include the sha1 for this commit. This means that
when running git blame on files this commit will be ignored (assuming
the local git environment is configured correctly).
Details and comments

Pull Request Test Coverage Report for Build 1791123583

0 of 0   changed or added relevant lines in 0 files are covered.
3 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.005%) to 83.355%

Files with Coverage Reduction
New Missed Lines
%

qiskit/pulse/library/waveform.py
3
89.36%

Totals

Change from base Build 1791028269:
-0.005%

Covered Lines:
52236

Relevant Lines:
62667

💛  - Coveralls

authors: coveralls mtreinish

repo: Qiskit/qiskit-terra


text:
RZXCalibrationBuilder fails for qubit pairs with GaussianSquareDrag

Environment

Qiskit version: 0.45 and 1.1.0.dev0+c99f325
Python version: 3.12
Operating system: Windows

What is happening?
RZXCalibrationBuilder fails for qubit pairs with GaussianSquareDrag, because it can't identify the native ECR direction.
How can we reproduce the issue?
The following code
from qiskit import QuantumCircuit
import numpy as np
from qiskit.transpiler import PassManager
from qiskit.transpiler.passes import RZXCalibrationBuilder

backend = provider.get_backend("ibmq_kolkata")
instmap = backend.defaults().instruction_schedule_map

qubits = ...
qc = QuantumCircuit(8)
qc.rzx(np.pi/2, *qubits)
pass1 = RZXCalibrationBuilder(instmap)
qc = PassManager(pass1).run(qc)

works if you set qubits=(4,7) and fails if you set qubits=(6,7).
The error originates here, and is caused by the filter counting comp tones which ignores anything but GaussianSquare or Waveform pulses. However, for some pairs (with the pair 6,7 being one of them) the pulses are reported as GaussianSqaureDrag. The pulses have beta=0 so they are identical to GaussianSquare, but they are not counted towards the comp tones, which leads to the failure.
What should happen?
The code should run for both qubit pairs.
Any suggestions?
I suspect changing the allowed types in the filter would solve the issue, but I am not familiar enough with this piece code, and what the backends might report for other qubits.
Counting GaussianSquareDrag with beta=0 is perhaps a safer option.

I was able to reproduce this issue on 0.46.
This works:
from qiskit import QuantumCircuit
import numpy as np
from qiskit.transpiler import PassManager
from qiskit.transpiler.passes import RZXCalibrationBuilder
from qiskit_ibm_provider import IBMProvider

provider = IBMProvider()
backend = provider.get_backend("ibm_cusco")
instmap = backend.defaults().instruction_schedule_map

qubits = (6,7)
qc = QuantumCircuit(8)
qc.rzx(np.pi/2, *qubits)
pass1 = RZXCalibrationBuilder(instmap)
qc = PassManager(pass1).run(qc)
qc.draw('text')

This, it does not:
from qiskit import QuantumCircuit
import numpy as np
from qiskit.transpiler import PassManager
from qiskit.transpiler.passes import RZXCalibrationBuilder
from qiskit_ibm_provider import IBMProvider

provider = IBMProvider()
backend = provider.get_backend("ibm_cusco")
instmap = backend.defaults().instruction_schedule_map

qubits = (4,7)
qc = QuantumCircuit(8)
qc.rzx(np.pi/2, *qubits)
pass1 = RZXCalibrationBuilder(instmap)
qc = PassManager(pass1).run(qc)
qc.draw('text')

QiskitError: "Native direction cannot be determined: operation on qubits [4, 7] for the following instruction schedule map: ...

The class qiskit.transpiler.passes.calibration.rzx_builder.RZXCalibrationBuilder is deprecated as of Qiskit 1.3. It will be removed in Qiskit 2.0. The entire Qiskit Pulse package is being deprecated and will be moved to the Qiskit Dynamics repository: https://github.com/qiskit-community/qiskit-dynamics. Note that once removed, qiskit.transpiler.passes.calibration.rzx_builder.RZXCalibrationBuilder will have no alternative in Qiskit.

authors: 1ucian0 ShellyGarion TsafrirA

repo: Qiskit/qiskit


text:
Add missing parameter in standard-gate mapping

Summary
The XXPlusYYGate and XXMinusYYGate instances returned from get_standard_gate_name_mapping were missing their optional beta parameter.

Details and comments

Pull Request Test Coverage Report for Build 7199428658

0 of 0   changed or added relevant lines in 0 files are covered.
16 unchanged lines in 4 files lost coverage.
Overall coverage decreased (-0.02%) to 87.552%

Files with Coverage Reduction
New Missed Lines
%

crates/qasm2/src/expr.rs
1
93.76%

qiskit/quantum_info/synthesis/two_qubit_decompose.py
2
96.65%

crates/qasm2/src/parse.rs
6
97.6%

crates/qasm2/src/lex.rs
7
91.41%

Totals

Change from base Build 7198837138:
-0.02%

Covered Lines:
59771

Relevant Lines:
68269

💛  - Coveralls

authors: coveralls jakelishman


text:
Improve qubit tracking in HighLevelSynthesis

Summary
Fixes #13239. Now for both examples in the referenced issue, HighLevelSynthesis produces a circuit with 24 CX-gates and 45 U-gates.
In addition, this also improves clean ancilla detection on following example:
inner1 = QuantumCircuit(4)
inner1.h(0)
inner1.cz(0, 2)
qc = QuantumCircuit(6)
qc.append(inner1.to_instruction(), [1, 2, 3, 4])
pass_ = HighLevelSynthesis(basis_gates=["cx", "u"])
qct = pass_(qc)

Even though the inner circuit inner1 is defined over the qubits 1, 2, 3, 4 in the main circuit qc, the qubits 1 and 3 in the inner circuit (corresponding to the qubits 2 and 4 in the main circuit) remain clean and can be used as clean ancilla qubits in the following gates.
Details and comments
This PR is based on numerous discussions with @Cryoris.
Recalling the second example from the referenced issue
inner = QuantumCircuit(6)
inner.mcx([0, 1, 2, 3, 4], 5)
custom_gate = inner.to_gate()
qc = QuantumCircuit(10)
qc.append(custom_gate, [3, 4, 5, 6, 7, 0])
basis_gates = ["u", "cx"]
tqc = HighLevelSynthesis(basis_gates=basis_gates)(qc)

the tricky part is that the recursive call to HighLevelSynthesis::_run on the inner circuit should have access to the clean "global" qubits outside of the circuit's definition. To tackle this, we introduce a class QubitContext which keeps the correspondence between the current DAG's qubits and the global qubits of the original circuit. The state of the global qubits (clean/dirty) is tracked by QubitTracker. When an internal synthesis algorithm (here for the internal MCX gate) checks how many clean/dirty ancilla qubits are available, it does so taking all of the global qubits into account.
However, this also means that synthesizing an internal DAG may output a DAG with more qubits. In particular (demonstrating possible complications) we can have an internal DAG with say 10 qubits that contains an MCX-gate over 8 qubits that can be synthesized by the appropriate synthesis algorithm to a circuit over 14 qubits (exploiting the global clean/dirty) qubits. Hence, our internal DAG must also grow in size (fortunately all the tracking is possible using the local-to-global correspondences of all the objects involved) which might mean that the DAG higher up in the chain might need to grow as well.
This PR also adds more HighLevelSynthesis tests exploring all these possible edge-cases.
In summary, this should handle any mixture of recursively defined circuits with annotated operations, custom gate definitions and HighLevelSynthesis plugins. For circuits containing control-flow ops, the extended functionality is not used (and will be delegated to another PR, if someone wants to tackle this). In other words, if we have a control-flow op over say 4 qubits in the bigger circuit, only these 4 qubits will be used when recursively processing the blocks in this op.
Update: An additional observation is that this also improves the synthesis of open-controlled MCX gates. In Qiskit, the name of an open-controlled gate is not of the form "mcx", but rather of the form "mcx_o17", where "17" is (the integer representation of) the control state. When processing this gate, HLS would not immediately call a synthesis plugin (since "mcx_o17" is not in the list of gate names for which plugins exist), but recursively process the definition of this gate, which is a quantum circuit consisting of a layer of X-gates, a closed-controlled MCX gate (called "mcx"), and the inverse layer of X-gates. During this recursion, HLS would now indeed call the synthesis plugin for the internal MCX-gate, and with this PR it would be able to use the ancilla qubits in the main circuit and outside of the internal open-controlled gate's definition.

Note: in 7432b6b I have disabled one of the newly added MCMT tests, I am trying to decide whether it points to a real bug or HLS is accidentally doing something too smart.

Please note a small follow-up PR #13369 that ports QubitTracker and QubitContext to Rust.


text:
Update coverage rustflags

This commit updates the flags used for generating coverage data with
grcov based on the latest README for grcov. [1] The last time these were
updated in #72 was to remove a flag that was being removed from rust and
causing the job to fail. However, that commit failed to add equivalent
flags which would perform the same functionality. This commit fixes that
oversight so we should have more reliable coverage collection.
[1] https://github.com/mozilla/grcov/blob/master/README.md

Coverage increased (+2.7%) to 88.235% when pulling b04d177b84b25ba180ec2987164c8f2f001a91fc on mtreinish:update-rustflags-for-coverage into a9dcb8d3f376b1971e48c68fbf6b2c4aa084c67a on Qiskit:master.

repo: Qiskit/retworkx


text:
Bugfix for Search child items functionality (task #5956)

Updated search child items logic to match new lists parsed structure.

Codecov Report

Merging #540 into master will decrease coverage by 0.09%.
The diff coverage is 0%.

@@             Coverage Diff             @@
##             master     #540     +/-   ##
===========================================
- Coverage     27.44%   27.35%   -0.1%
- Complexity      972      976      +4
===========================================
  Files            88       88
  Lines          3334     3345     +11
===========================================
  Hits            915      915
- Misses         2419     2430     +11

Impacted Files
Coverage Δ
Complexity Δ

...ent/Plugin/Search/Model/ChildListItemsListener.php
0% <0%> (ø)
21 <0> (ø)
:arrow_down:

src/ScheduledJobs/Jobs/CakeShellJob.php
0% <0%> (ø)
8% <0%> (+4%)
:arrow_up:

Continue to review full report at Codecov.

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

authors: codecov-io georgeconstantinou

repo: QoboLtd/project-template-cakephp


text:
Update examples

Add some minimal narration to the examples, and look into converting them into mkdocs-galley based examples to serve on the website.
These can live in the Tutorial or References section, under in an "Examples" sub-section.
Also, make sure this works narratively with the tutorial docs (which are derived from the examples)

Closing as duplicate of #26 -- will track it there

repo: Quansight/ragna


text:
Adds Custom Data from US Energy Information Administration (eia.gov)

Description
Built new custom data class for US Energy Information Administration data. Accommodates hourly, daily, monthly, quarterly, and yearly resolutions.
Related Issue
Closes #3106
Motivation and Context
Adds new custom data class to expand current custom data capabilities and add functionality for users.
Requires Documentation Change
Not likely, although updates to custom data documentation will be needed if deemed necessary. Additionally, documentation updates may be needed for Python indicators since it has been found that
self.EMA returns the same as self.EMA.Current.Value, at least when formatted in logging. This will need further testing.
How Has This Been Tested?
Tested locally across numerous tickers and resolutions.
Tested in QuantConnect Cloud in backtesting and live mode.
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Non-functional change (xml comments/documentation/etc)

Checklist:

[x] My code follows the code style of this project.
[x] I have read the CONTRIBUTING document.
[x] All new and existing tests passed.
[x] My branch follows the naming convention bug-<issue#>-<description> or feature-<issue#>-<description>

We need to create a "No New Data" Signal for custom data types which can address the null return problem. We should also review all existing custom data (quandl) implementations to confirm they're returning OK.

authors: AlexCatarino jaredbroad

repo: QuantConnect/Lean


text:
Minor typo and grammar fixes to comments in PeriodCountConsolidatorBase

Description

Related Issue

Motivation and Context

Requires Documentation Change

How Has This Been Tested?

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] Refactor (non-breaking change which improves implementation)
[ ] Performance (non-breaking change which improves performance. Please add associated performance test and results)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[x] Non-functional change (xml comments/documentation/etc)

Checklist:

[x] My code follows the code style of this project.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.
[ ] My branch follows the naming convention bug-<issue#>-<description> or feature-<issue#>-<description>

Thank you @RohanTalip

authors: RohanTalip jaredbroad


text:
Data Feed Options Don't Include Alt Datasets

When we run lean live, the "Select a data feed" prompt should include alt datasets like Tiingo. It currently just shows

Since you guys are at it, it would be nice to add also TwelveData: https://twelvedata.com

authors: DerekMelchin pberto

repo: QuantConnect/lean-cli


text:
Deploying algo using DLL

For security reasons, I want to deploy my algo in a .NET assembly rather than using a CS code project. Is there any way to do that? Even if I reference the DLL in the project and run it, that should be fine.

I'm closing this, this it's not supported.


text:
about_py: excel link added and misc edits

fixes #796

Good PR, nice improvements and fixes.  Please see commend above.

Thanks, @mtiley . Nice work.
Hi @jstac , I kept @mtiley 's changes and modified the sentence as you instructed.

Thanks @shlff!

Perhaps a link to this article could be included somewhere --- a history of how Python became so popular.
https://www.welcometothejungle.com/en/articles/btc-python-popular

Thanks for the feedback @jstac, I've made those changes.

Nice work, thanks @mtiley

authors: jstac mtiley shlff

repo: QuantEcon/lecture-source-py


text:
fix random access view regeression

thanks @PerretB for finding this bug!
fixes #856

Awesome, thanks!

authors: SylvainCorlay wolfv

repo: QuantStack/xtensor


text:
Fix a small typo in elastic

The default value from pymatgen is 0.06.

Can one of the admins verify this patch?

Thank you, @superstar54! I'll go ahead and merge this in.

repo: Quantum-Accelerators/quacc


text:
epoll: define EpollEvent structure per linux API

the userData is sometimes defined as [i32; 2] in Quark code. This doesn't make sense to me because the data is used in one piece as a u64 anyways. But I may be wrong.
However I don't see where this array is converted into u64, am I missing something? What's the initial idea of define the userData as [i32; 2] ?
This is tested on both x86 and aarch64, I don't see regression so far. Also fixes #1230
CC @QuarkContainer

Note: @CharlyYu fixed a similar issue recently, but the EpollEvent struct is defined in more than 4 places differently depending on how they are used and they all require additional padding for aarch64. I don't want to have 8x struct definitions of the same thing so I propose to use one unified def of this struct.
The Data field could be either a fd (i32), a u32, or a u64 data. If you use Data as i32 it will use the lower 4 bytes and has no conflict with the earlier defs.

repo: QuarkContainer/Quark


text:
🛑 Biken is down

In d35bb5e, Biken (https://biken.quentinp.me) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Biken is back up in 83dc903.

repo: QuentinPhilipp/uptime


text:
Feedback for “Middleware configuration”

urlMappingStrategy: rewrite is not working

Please provide a reproduction. It works as expected in https://github.com/QuiiBz/next-international/tree/main/examples/next-app

authors: QuiiBz ivanafanasyeu

repo: QuiiBz/next-international


text:
Flicker with client component

I have some flicker on refresh when using client components with translations, it's due the suspense in I18nProviderClient is there a way to fix this flicker?
https://github.com/QuiiBz/next-international/assets/655158/90f4363f-6dae-4e90-ad22-a8e29367b62e
layout.tsx:
"use client";

import { I18nProviderClient } from "@/locales/client";
import { ReactNode } from "react";

type ProviderProps = {
  locale: string;
  children: ReactNode;
};

export function Provider({ locale, children }: ProviderProps) {
  return (
    <I18nProviderClient locale={locale} fallback={
Loading...
}>
      {children}
    </I18nProviderClient>
  );
}

"next-international": "^1.1.4",
"next": "14.0.3",

Sorry for the delay, I started a new job. Could you share a minimal reproduction? I cannot reproduce the issue with the example in the repo: https://github.com/QuiiBz/next-international/tree/main/examples/next-app

No worries at all! Congrats on the new job, well deserved! I will actually investigate other things like next-theme to really know what the problem is here. So I will close this and if the problem still exists after midday is open-source it will be much easier for me to showcase the issue.
Marry Christmas and happy new year!

I just confirmed that it was indeed the next-themes provider, moving it down under I18nProviderClient fixed the flicker issue!

Hello, doesn't this contradicts this part of the documentation?

Move all your routes inside an app/[locale]/ folder. For Client Components, wrap the lowest parts of your app with I18nProviderClient inside a layout

Because the next-themes provider goes on the very top of your app. I'm having the same flicker issue.

That depends if next-themes can suspend too or not; next-international has a suspense boundary internally so it might be why it works when next-themes is a children of it.

In my case I use next-ui and next-theme, all of them should be inside the next-international provider. not only that, I think for every client component
Just want to add a note for everyone, looking for this flicker for a full day HAHA thank god

authors: QuiiBz cglacet pajarrahmansyah pontusab


text:
Travis CI

É preciso configurar o Travis-CI para rodar automaticamente os testes do projeto.
Já temos o .travis.yml no projeto, basta configurar a conta.

Eu deixei a tag ali pronta, pro php 7 pra cima, só editar o .travis.yml, se tiver alguma dúvida, eu tenho um livro a respeito: https://ci.mrprompt.com.br ou tento ajudar

Blz, deixa comigoEm 1 de abr de 2018 13:36, Thiago Paes notifications@github.com escreveu:Eu deixei a tag ali pronta, pro php 7 pra cima, só editar o .travis.yml, se tiver alguma dúvida, eu tenho um livro a respeito: https://ci.mrprompt.com.br ou tento ajudar
—You are receiving this because you commented.Reply to this email directly, view it on GitHub, or mute the thread.

resolvido, versão 7.0 do phpunit so roda com PHP 7.1 modifiquei a verão do phpunit para 6.5.

authors: Rctnet mrprompt

repo: QuilhaSoft/OpenCnabPHP


text:
Bradesco cnab240

Com a ajuda do @Rctnet consegui gerar o arquivo para ser homologado porém, já de cara, deu erro de arquivo invalido! Busquei na internet e parece que isso se da devido o formato que foi salvo o txt, tem que ser com salvo codificação ANSI.
Antes de enviar novamente para homologar, estou verificando os campos das classes Registro porém bateu umas duvidas:

O Registro0 se refere ao Header?
O Registro1 se refere ao Trailer?
O Registro3P se refere ao Segmento P?

Tem ainda Header_lote e Trailer_lote, quais são suas classes Registro correspondentes?
Eu atualizei o Registro0 considerando que ele seja o Header do arquivo porem notei que o Registro0 do cnab400 tem uma campo chamado "identificacao_registro" e nesse cnab240 que atualizei não consta esse campo no Header do arquivo e sim no Header de lote, esse Header de lote onde atualizo, qual classe Registro se refere a ela?

Quanto a codificação do arquivo, na linha 95 do exemploRemessa.php eu faço o decode de utf8 para salvar o arquivo, pode ser ai que você vai converter para ANSI, disponibilizei ontem também um update que permite a modificação do caracter de fim de linha, veja na linha 120 do https://github.com/QuilhaSoft/OpenCnabPHP/blob/master/src/resources/B748/remessa/cnab400/Registro0.php como é feito(necessário para o banco SICREDI)
3.1 - Composição do Arquivo cnab240 da CEF,Santander, o do bradesco deve ser igual
Registro Header de Arquivo                            (Tipo = 0) Registro0.php
Registro Header de Lote                                 (Tipo = 1) Registro1.php
Registros Iniciais do lote (opcional) ..             (Tipo = 2) Registro2.php
Registros de detalhe Segmentos                   (Tipo = 3) aqui podem conter os seguimentos P,Q,R,S
Registro3P.php , 3Q, assim sucessivamente
Registros finais do lote       (opcional)           (Tipo = 4) Registro4.php
Registro trailer do lote (opcional)                  (Tipo = 5)Registro5.php
Registro Trailer de Arquivo                            (Tipo = 9) Registro9.php

Blz @Rctnet , vou fazer uns ajustes e pintando alguma duvida ou dando certo eu retorno informando...

@Rctnet Alterei os campos das classes Registro conforme doc do Bradesco e consegui gerar o arquivo para homologar porém sempre ta recusando o arquivo e dando a mensagem "O registro possui tamanho invalido".
É um erro muito vago, não especifica onde é. Você sabe o que pode ser? Qual o tamanho que o arquivo precisa ter?
Uma curiosidade, analisando outros arquivos de outros bancos notei que tinha a descrição "REMESSA-TESTE" porém na documentação do Bradesco não vi em nenhum momento menção a isso. O txt que gerei não tem essa descrição.

O tamanho nesse caso é da linha, que deve ter 240 caracteres

Posta um arquivo aqui para eu dar uma olhada, ou manda no meu email

o arquivo que recebi esta sem quebra de liinha

Isso que notei tbm, abri ele no notepad++ e só tem uma linha unica

Quando gero os dados na tela, aparece a quebra de linha porém quando copio e salvo em txt dae acontece isso, mesmo salvando com codificação ANSI.

pode ser na conversão para ANSI os caracteres de fim de linha são inválidos

Depois de analisar os arquivos de teste na pasta Samples notei que tinha um comando de saida dos dados que trata o utf8, eu não estava tratando assim a codificação, foi uma falha minha.
Depois que inclui esse comando resolveu o problema da quebra de linha, agora vou enviar esse arquivo pro banco pra ver o  erro que dá.
O comando que usei foi esse na saida dos dados.
header("Content-Disposition: attachment;filename=" . $arquivo->getFileName() .";");
echo utf8_decode($arquivo->getText()); // observar a header do seu php para não gerar comflitos de codificação de caracteres

Que pena, a empolgação durou pouco kkkkk Deu o mesmo erro :/
Segue arquivo que enviei para validar.
REM_237_1234_1.txt

authors: CristianoMCon Rctnet


text:
Set indentation for attributes in new lines

There is an option to set indentation for child tags in XMLDocument but no option to set indentation for new line attributes and they are at present calculated at XMLElement#appendAttributesIndentText(Writer). It might be better to provide an option to set indentations instead of calculating them. For example, instead of providing an argument boolean newLineAttributes, you can provide int attributeIndentation whose negative value (e.g. -1) would imply no new line and any positive number would imply the amount of indentation.
Thanks.

I agree , there a lot of other issues to fix on com.reandroid.xml.* classes.

Any updates?

Sorry I don't know how I forgot this issue.
Keeping newLineAttributes, I have added  setAttributesIndentScale(float indentScale) for elements, you can set negative value to pull back.

Keeping newLineAttributes, I have added setAttributesIndentScale(float indentScale) for elements, you can set negative value to pull back.

It only scales the calculated indentation, it does not set the indentation.

I feel like i missed your point. As on the last commit you can set indentation to any position you like, I kept  newLineAttributes param to turn off/on indentation. The indentation for attributes must be calculated bc it is anchored with parent element.
Can you show me your goal with screenshoot/document ? Or make PR

I have ended up writing a concrete implementation of XmlPullParser to handle this. As I said in #18, I don't think XML conversion should be part of the library as it can be handled quite easily using XmlSerializer and Transformer functions.

authors: MuntashirAkon REAndroid

repo: REAndroid/ARSCLib


text:
🛑 RED7 Staff - Portal is down

In 826b475, RED7 Staff - Portal (https://portal.red7.ml) was down:

HTTP code: 0
Response time: 0 ms

Resolved: RED7 Staff - Portal is back up in e81a91a.


text:
Master installation script / convenience function

Is your feature request related to a problem? Please describe.
Setting up a fully-fledged R environment in VS Code currently involves several manual steps, as outlined in the README. Users must first install the languageserver package (from R), then add the REditorSupport extension (from VS Code), and then configure several other add-ons from other locations/sources (e.g. radian via pip in the terminal, httpd from R...).
In my experience, this startup rigmarole is tricky for newcomers and, possibly, even for fairly advanced users. (Example: I explicitly had to add radian to my $PATH on both Linux and Mac before it would work.) Once everything is set up, then VS Code genuinely makes for an excellent R IDE. But it's harder getting to that point than it needs to be IMO.
Describe the solution you'd like
One possible solution is to handle all of these installation requirements via a single convenience script or R function. I'm thinking something along the lines of arrow::install_arrow() and reticulate::install_python() (or even JILL and Homebrew).
Say this functionality was bundled as an R function; call it vscoder_setup(). Users could then pass arguments regarding the installation and configuration that they'd like... although I'd argue that the full enchilada of recommended steps—including the debugger plugin and radian—be installed as a default.
Describe alternatives you've considered
Apart from the current manual approach, none.
Additional context
#718 is somewhat related. Again, however, my goal is to provide a single convenience function that I can give to students and colleagues that sees them off to the races with minimal effort or assumed knowledge on their part.
Thanks for considering!

I think a generalized approach to doing this is to use VSCode Remote-Containers (or simply devcontainer CLI).

@grantmcdermott Another approach is building a Docker image with JupyterLab + R + code-server + ...
Log into https://demo.jupyter.b-data.ch with your GitHub account and start Image R (verse:latest) + code-server.
You may also run registry.gitlab.b-data.ch/jupyterlab/r/verse locally like the official Jupyter docker images: https://github.com/jupyter/docker-stacks#quick-start

See also https://gitlab.b-data.ch/explore/projects/topics/JupyterLab.
ℹ Multi-arch (linux/amd64, linux/arm64/v8) Docker images with code-sever + R | Python | Julia + ...

Thanks both. I agree the containerized options are nice and I personally make use of them a lot in my own workflow.
But again, I'm looking to accommodate users who will, typically, never have heard of Docker and might even be getting exposed to R and VS Code for the first time. (And me in the middle, trying to convince them to use both!) I'd love to make the setup+installation process for these users as simple as it is for, say, RStudio.

I think it would be fair to say that one of the main vscode-R goals, at present, is to drastically reduce the barrier to entry. This can be seen for instance in the defaulting of standard vsc-R settings, or the ability to toggle R options via extension settings.
RStudio's onboarding and new user experience is nothing short of exceptional and is something that can (and probably should) be used as a benchmark. @renkun-ken has a nice blogpost discussing this (unfortunately I can't find the link ATM).
As you've outlined, we need to do better with the setup phase. The python extension does a nice job of setting up upon initial installation, and perhaps we need to explore that more.
The selection of rPath and rTerm can also be confusing, and the cognitive overhead should hopefully be reduced in an upcoming PR.
Hopefully more to come in making this a more inviting experience :)

Hopefully the work the devs are doing to bring full multiroot support so that R in VSCode operates just like python will make things better, because the python side is really easy to get going, and R should be the same

And sorry but maybe I'm an idiot, but I've never gotten vscode-R to work. I follow the README and have all the requirements installed. I specify the rterm and rpath to fixed binary paths in my settings, but nothing works, you cannot attach an R terminal in VSCode, it doesn't do any syntax checking, really it just doesn't seem connected to R and radian at all. I'm simply not understanding because honestly how can anyone do these simple steps wrong.
Is it because my R, radian, languageserver, httpgd are in a single conda environment? I remember also trying to install these into system paths via my linux dnf package manager, but remember it also didn't work at all. How did other people get things to work?

authors: ElianHugh benz0li eitsupi grantmcdermott hermidalc

repo: REditorSupport/vscode-R


text:
Handle chain information in explicit form in invoices

This is a breaking change since inside the invoice structure we make chain non-optional; plus we add new error cases and make set_chain return Result. Thus I am making this PR against v11 branch.
Closes #103

Any reason why it is non-optional instead of optional as discussed in #103?

@fedsten the parameter is optional as was discussed, thus the invoice string is backwards-compatible. However, for each given invoice we always know which network it belongs to (since we are defaulting to mainnet as discussed), thus we must have a non-optional field.

Got it,  for clarifying.

In other words, a wallet will always know and be sure to which network a given invoice belongs. If the invoice has conflicting network information (like an address network doesn't match the network provided in a parameter) it will error during the parse procedure. But each parsed invoice always knows which network it is valid for,

@zoedberg wait, we do not have CI set up for this repo? Oh, I'll fix it.
I did this PR originally against v0.10 branch which was used rust-bitcoin v0.30. Then I understood it's breaking, so moved to v0.11, which doesn't depend on rust-bitcoin at all and have a different Address type (from bp-std) with different API. Thus the issue. Will fix.

Closing in favor of solution from https://github.com/RGB-WG/rgb-std/pull/118

authors: dr-orlovsky fedsten

repo: RGB-WG/rgb-wallet


text:
🛑 CEOTR Home Page loads is down

In b44df53, CEOTR Home Page loads (https://stg.ceotr.ca CEOTR Home) was down:

HTTP code: 0
Response time: 0 ms

Resolved: CEOTR Home Page loads is back up in 15b2de1 after 2 minutes.

repo: RKTowse/upptime


text:
🛑 CEOTR Home Page loads is down

In 0c91271, CEOTR Home Page loads (https://stg.ceotr.ca CEOTR Home) was down:

HTTP code: 0
Response time: 0 ms

Resolved: CEOTR Home Page loads is back up in 4341d70 after 2 minutes.


text:
🛑 CEOTR Home Page loads is down

In 960d72c, CEOTR Home Page loads (https://stg.ceotr.ca CEOTR Home) was down:

HTTP code: 0
Response time: 0 ms

Resolved: CEOTR Home Page loads is back up in a00fe7c after 2 minutes.


text:
🛑 CEOTR Home Page loads is down

In a685c2b, CEOTR Home Page loads (https://stg.ceotr.ca CEOTR Home) was down:

HTTP code: 0
Response time: 0 ms

Resolved: CEOTR Home Page loads is back up in 3602b4d after 2 minutes.


text:
🛑 Sensor Tracker login is down

In 4e69a74, Sensor Tracker login (https://stg.ceotr.ca/sensor_tracker) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Sensor tracker login is back up in df23ebd after 1 minute.


text:
🛑 Sensor Tracker login is down

In 2791adc, Sensor Tracker login (https://stg.ceotr.ca/sensor_tracker) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Sensor tracker login is back up in a2edb29 after 1 minute.


text:
🛑 Sensor Tracker login is down

In aa7a1b0, Sensor Tracker login (https://stg.ceotr.ca/sensor_tracker) was down:

HTTP code: 502
Response time: 52 ms

Resolved: Sensor tracker login is back up in 26ce07e.


text:
🛑 Sensor Tracker login is down

In f70f816, Sensor Tracker login (https://stg.ceotr.ca/sensor_tracker) was down:

HTTP code: 502
Response time: 46 ms

Resolved: Sensor tracker login is back up in f3f2118.


text:
🛑 Sensor Tracker login is down

In d5aeb60, Sensor Tracker login (https://stg.ceotr.ca/sensor_tracker) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Sensor tracker login is back up in 4e71703 after 1 minute.


text:
🛑 CEOTR Home Page loads is down

In a06f603, CEOTR Home Page loads (https://stg.ceotr.ca CEOTR Home) was down:

HTTP code: 0
Response time: 0 ms

Resolved: CEOTR Home Page loads is back up in 7c43f68.


text:
🛑 CEOTR Home Page loads is down

In 615141c, CEOTR Home Page loads (https://stg.ceotr.ca CEOTR Home) was down:

HTTP code: 0
Response time: 0 ms

Resolved: CEOTR Home Page loads is back up in c9fbbbb after 2 minutes.


text:
🛑 CEOTR Home Page loads is down

In 6b51877, CEOTR Home Page loads (https://stg.ceotr.ca CEOTR Home) was down:

HTTP code: 0
Response time: 0 ms

Resolved: CEOTR Home Page loads is back up in 1559d22 after 2 minutes.


text:
🛑 CEOTR Home Page loads is down

In 86c96ec, CEOTR Home Page loads (https://stg.ceotr.ca CEOTR Home) was down:

HTTP code: 0
Response time: 0 ms

Resolved: CEOTR Home Page loads is back up in 1e74faf.


text:
🛑 Sensor Tracker login is down

In a0570d2, Sensor Tracker login (https://stg.ceotr.ca/sensor_tracker) was down:

HTTP code: 502
Response time: 42 ms

Resolved: Sensor tracker login is back up in 68f87ec.


text:
🛑 Sensor Tracker login is down

In 2b8d234, Sensor Tracker login (https://stg.ceotr.ca/sensor_tracker) was down:

HTTP code: 502
Response time: 107 ms

Resolved: Sensor tracker login is back up in af2e687.


text:
🛑 Sensor Tracker login is down

In 91205f0, Sensor Tracker login (https://stg.ceotr.ca/sensor_tracker) was down:

HTTP code: 502
Response time: 48 ms

Resolved: Sensor tracker login is back up in 62bf4a8 after 38 days, 3 hours, 14 minutes.


text:
🛑 Sensor Tracker login is down

In 4b2ccf3, Sensor Tracker login (https://stg.ceotr.ca/sensor_tracker) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Sensor tracker login is back up in a1ed6c6 after .


text:
🛑 CEOTR Home Page loads is down

In fbb831b, CEOTR Home Page loads (https://stg.ceotr.ca CEOTR Home) was down:

HTTP code: 0
Response time: 0 ms

Resolved: CEOTR Home Page loads is back up in 1302d38 after 2 minutes.


text:
🛑 Sensor Tracker login is down

In becd186, Sensor Tracker login (https://stg.ceotr.ca/sensor_tracker) was down:

HTTP code: 502
Response time: 55 ms

Resolved: Sensor tracker login is back up in 1249e08.


text:
Let users make and pick presets for Psyonix bots

Some users like to run tournaments with Psyonix bots and sometimes change their name and appearance. In v4, the latter was technically possible, but a bit of a hassle to do. In v5 we should avoid hardcoding Psyonix bots too much. I propose the following features:

Users can pick specific Psyonix bot name+loadout

in core/match toml: Matches can have (Psyonix) bots with specified/overridden name and loadout
in GUI: TBD. Maybe it should be possible to override any bots' name and appearance by right/double clicking a bot added to the current match before match start.

Users can change the pool of names+loudouts used by Psyonix bots (less important, more advanced impl)

We don't want users to accidentally delete the standard Psyonix bot loadouts, but they should be able to define a pool of loadouts that rlbot picks from. It should be easy to include/exclude standard loadouts and new custom loadouts in this pool. One solution could be a file that includes paths to the included loadouts.

We could read config.toml for Psyonix bots and allow setting the name, which if matching a preset, would load that preset. Also if a looks config is defined, we could just use that instead of any preset. This would be easy to implement.
The “adding to the preset pool” could also be faked by the gui with the above system.

I have thought about this a bit more. We also have users who want to troll their friends by renaming Nexto. So ideally, we should find a general solution that works with both custom and Psyonix bots. I imagine some kind of override field in the match config now.
What is config.toml? The one corresponding to rlbot.cfg?
Also related: #40

So it would look something like this:
[[cars]]
config = "greg.toml"
team = 0
type = "psyonix"
skill = "allstar"

We have settled on something akin to what Virx described above. The match settings (rlbot.toml) can override any bot's name and loadout. This enables the GUI (and other match starter tools) to control how (Psyonix) bots appear when using that tool. By default, core will select randomly from the standard loadouts used in the game when spawning Psyonix bots.

authors: NicEastvillage VirxEC

repo: RLBot/core


text:
🛑 RMUG Files is down

In 79819da, RMUG Files (https://files.rmusergroup.net) was down:

HTTP code: 500
Response time: 338 ms

Resolved: RMUG Files is back up in 9ab6aa6 after 22 minutes.

repo: RM-User-Group/RMUG-Upptime


text:
Error- Can’t find orphan to remove, also 429

This is a really great plugin. I’ve been using it since you first posted it many months ago. It took many attempts to get it up and running, but it has been worth all the effort.  However, it has lots of stability issues. I have rebuilt it (a clean installation) about once a month.  Now I have 2 instances running on 2 different windows 10 mini computers. They are both running but Probably not for long.  The HomeBridge log is full of errors.
Steve Q

I reinstalled NPM and hb-service.  The plugin is now working.
SteveQ2

repo: RMCob/homebridge-wyze-connected-home-op


text:
Cleanup rnc accession columns

This is the start of work to cleanup the columns in rnc_accessions. Generally, this pull request stops writing and loading specific columns which do not appear to be useful. This should be safe to just run, but as far as I can tell tests are broken right now. Prior to running this pipeline this we must manually edit rnc_update.update_rnc_accession function in the database to remove references to the columns cleaned up here. Otherwise it will break when loading things into the database. For reference the columns are:

map
allele
ordinal
pseudogene
old_locus_tag
anticodon
division
common_name
classification
species
operon

The taxonomic columns are not needed but left in the entry object for now. There needs to be more careful work to remove them as we do use them for some logic within the pipeline.

I've been working through the database tests and have fixed some of them. Fixing those is going to take me a while. I can start tracking it but I suspect this is very slow going.

repo: RNAcentral/rnacentral-import-pipeline


text:
Throws exception while decrypting

    public static String encryptData(String data, String key) {
        byte[] decryptedData = data.getBytes();
        try {
            byte[] encryptedData = cryptor.encryptData(decryptedData, key.toCharArray());
            return new String(encryptedData);
        } catch (CryptorException e) {
            e.printStackTrace();
        }
        return null;
    }

    public static String decryptData(String data, String key) {
        try {
            byte[] encryptedData = data.getBytes();
            byte[] decryptedData = cryptor.decryptData(encryptedData, key.toCharArray());
            return new String(decryptedData);
        } catch (CryptorException e) {
            e.printStackTrace();
        }
        return null;
    }

I have used above encryption and decryption method.

// i have used JNCryptor as global.
private static  JNCryptor cryptor = new AES256JNCryptor();
i got CryptorException when i run this code.
i have referred few issue posted previously about this.

This is wrong:
return new String(encryptedData);

The encrypted data is binary and cannot be represented as a simple string. You are correct to think about using base64 instead.
Please show your full failing example with base64 and I can help further.

org.cryptonode.jncryptor.InvalidHMACException: Incorrect HMAC value.org.cryptonode.jncryptor.AES256JNCryptor.decryptV3Data()
org.cryptonode.jncryptor.AES256JNCryptor.decryptV3Data()
org.cryptonode.jncryptor.AES256JNCryptor.decryptData()

Please read http://sscce.org. This explains how to create decent example code that allows others to help you.

public class DVAESAlgorithm {
private static  JNCryptor cryptor = new AES256JNCryptor();
public static String encryptData(String data, String key) {
byte[] decryptedData = data.getBytes();
try {
byte[] encryptedData = cryptor.encryptData(decryptedData, key.toCharArray());
return new String(encryptedData);
} catch (CryptorException e) {
e.printStackTrace();
}
return null;
}
public static String decryptData(String data, String key) {
    try {
        byte[] encryptedData = Base64.decode(data,0);
        byte[] decryptedData = cryptor.decryptData(encryptedData, key.toCharArray());
        return new String(decryptedData);
    } catch (CryptorException e) {
        e.printStackTrace();
    }
    return null;
}

}
// accessing these class from my adapter class, i just checked with my name to encrypt and decrypt
String test = DVAESAlgorithm.encryptData("saravana kumar", encryptionKey);
String value = DVAESAlgorithm.decryptData(test,encryptionKey);
// issue occured
org.cryptonode.jncryptor.CryptorException: Unrecognised version number: -81.
org.cryptonode.jncryptor.AES256JNCryptor.decryptData(AES256JNCryptor.java:283)

you can check my code in below link.
https://github.com/SaravanakumarB/AES256-Algorithm

repo: RNCryptor/JNCryptor


text:
Segmentation Fault Pytorch  RX 6700xt

Hi,
I am trying to run a test for my RX 6700xt but I  face many problems.
I tried issue#1686 and 1687 but I was not able to fix them.
I get an error of segmentation faul when I am trying to do run a test inside a docker image:
https://www.youtube.com/watch?v=HwGgzaz7ipQ
The other problem is that after having installed rocm and pytorch terminal returns cuda available = false. ( in docker image returns true)
I have used both Ubuntu 22 and 20 but still have the same proble. Is pytorch compatible only with 5.2 rocm?
Also, in the docker image it returns cuda available but does not run the test.
Can anybody help?

Do you know if that version supports the 6700 xt? I have a 7900 xtx, which isn't supported and I can't use the gpu without it segfaulting, I would guess that it's a driver mismatch.

I followed the example below closely and got the same error again:
https://www.youtube.com/watch?v=IQSvz6jBCis&t=1072s
RX6700xt is compatible with the versions of the example

Looks like your gpu type is not in the official supported list:
https://rocm.docs.amd.com/en/latest/release/gpu_os_support.html
Can you run
rocminfo | grep gfx

Looks like your gpu type is not in the official supported list: https://rocm.docs.amd.com/en/latest/release/gpu_os_support.html
Can you run
rocminfo | grep gfx

According to the following guide RX 6700 XT should be suffecient.
https://www.videogames.ai/2022/09/01/RX-6700s-Machine-Learning-ROCm.html

@mpourasa RX6700 XT is not officially supported in our latest ROCm 6.1.1. Thanks!

authors: hongxiayang mpourasa ppanchad-amd tedtroxell

repo: ROCm/ROCm


text:
Update 6.2.2 docs

from 6.2 release branch roc-6.2.x

ignoring spell check failure
hit docker hub rate limit of 100 pulls per 6 hours


text:
Generic name change - To maintain a generic name instead of "image"

This PR changes the names of image_info to sample_info to maintain a generic name for all use-cases (audio, video, image)

@LakshmiKumar23 : can you please review this PR?

Hi @rrawther,
In our last call we discussed to rename image to sample which will be a common reference for image / audio / video. We are using this API to get info for other media too.
Can we replace sample with media / data? Please share your thoughts.

@swetha097 can you address the review comments? We need to merge this before we can review the audio PRs

@LakshmiKumar23 Addressed the comments.

@swetha097 @LakshmiKumar23 -- failing CI tests - http://math-ci.amd.com/blue/organizations/jenkins/main%2Fprecheckin%2FrocAL/detail/PR-114/2/pipeline/227

@swetha097  @LakshmiKumar23
[ 68%] Building CXX object rocAL/CMakeFiles/rocal.dir/source/meta_data/meta_node_resize_mirror_normalize.cpp.o
../../../rocAL/source/meta_data/bounding_box_graph.cpp: In member function 'virtual void BoundingBoxGraph::update_random_bbox_meta_data(pMetaDataBatch, pMetaDataBatch, DecodedDataInfo, CropImageInfo)':
../../../rocAL/source/meta_data/bounding_box_graph.cpp:76:36: error: expected primary-expression before '.' token
   76 |     auto crop_cords = CropImageInfo._crop_image_coords;
      |                                    ^
make[2]: *** [rocAL/CMakeFiles/rocal.dir/build.make:1060: rocAL/CMakeFiles/rocal.dir/source/meta_data/bounding_box_graph.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [CMakeFiles/Makefile2:909: rocAL/CMakeFiles/rocal.dir/all] Error 2
make: *** [Makefile:166: all] Error 2

@kiritigowda Fixed it.

@kiritigowda : this is ready to be merged. Is it still failing CI?

@kiritigowda CI passed on this

repo: ROCm/rocAL


text:
Cherry-pick to docs/6.2.1: Fix broken link in Ubuntu 20.04 tab of Docker support matrix

I made a typo in my local branch name. It's based on a checkout of upstream/docs/6.2.1. Sorry for the confusion!

We can close this, as it was addressed in https://github.com/ROCm/rocm-install-on-linux/pull/277

authors: amd-jnovotny yhuiYH

repo: ROCm/rocm-install-on-linux


text:
Unknown hip compiler

Running resnet50 by using migraphx from commit 31906785f138d31908da3794079ff90bc321bd97 in rocm5.1.1 causes a failure:
root@bogon:/data_share/qq/Workspace/Git/migraphx/build# /opt/rocm/bin/migraphx-driver perf --model resnet50
Compiling ...
terminate called after throwing an instance of 'migraphx::version_1::exception'
  what():  /data_share/qq/Workspace/Git/migraphx/src/targets/gpu/compile_hip.cpp:201: compile_hip_src: Unknown hip compiler: /opt/rocm
Aborted (core dumped)

the docker image I use:
docker pull rocm/pytorch:rocm5.1.1_ubuntu20.04_py3.7_pytorch_1.9.0

the docker image I use:
docker pull rocm/pytorch:rocm5.1.1_ubuntu20.04_py3.7_pytorch_1.9.0

How are you building MIGraphX?
I used the following steps:
git clone https://github.com/ROCmSoftwarePlatform/AMDMIGraphX.git
cd AMDMIGraphX; git checkout 3190678
rbuild build -d depend -B build_pyt_docker --cxx=/opt/rocm/llvm/bin/clang++
./build_pyt_docker/bin/migraphx-driver perf --model resnet50

I don't see the above error when I do this. For MI100 GPU.

repo: ROCmSoftwarePlatform/AMDMIGraphX


text:
Is this deprecated?

From what I can see, this hasn't been moved to the ROCm organization like the others, nor has it been updated past 5.5.0.
The last commit was also more than a year ago.

https://github.com/ROCm/MIOpen/commit/dd23f4e8c0783027128f95320c5af58982296d23#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5
looks like the answer is yes

repo: ROCmSoftwarePlatform/MIOpenGEMM


text:
problem setting up pool

Hey I followed the instructions from here. https://www.youtube.com/watch?v=dR2fgqCSJ4Y
I followed the directions, made a text file copied and pasted the binary code from the optiminer website, pasted my wallet address where It said to put it then I saved it as a .bat file. What am I missing here?

Look g hobson I'm sorry I set you off, but I can't understand code because I'm not a coder. it's not hard to understand it. It just took finding out where I needed to run the dang code.

repo: ROIcoin/ROIcoin