text:
ci: overhaul ci and cd workflows

Fixes #325

If you don't mind, I would just add some changes

If you don't mind, I would just add some changes

Of course, go ahead.

Plesse see the output of baipp:
https://github.com/PyPSA/linopy/actions/runs/9871896061/attempts/1#summary-27260815050
I think this is really helpful.

@afuetterer
This is all super great. Thanks a lot for your input !
I made some smaller adjustments and added trusted publishing and tried to use the baipp dist also for tests. Would you have a look?
CI with the baipp versions still needs a fix.

CI with the baipp versions still needs a fix.

What do you mean?

I added concurrency to cancel early, if multiple commits are pushed in short time to the same PR.

Okay, well, of course you needed to have python versions defined in the pyproject.toml. :smile:

Oh my god, finally. Please squash. :smile:

Should I squash the commits or do you perform squash and merge?
Any more changes at the moment?

I guess you need to update the required check in your PR settings. It hangs.

Also the badge URL in the readme needs to be changed.

Fingers crossed, that the release workflow and the trusted publishing works.

Fingers crossed, that the release workflow and the trusted publishing works.

I will test that in a release of a different repo soon

@lkstrp let me know if we should merge this

@FabianHofmann Let's go

Oh no.
You did not squash the commits, instead you merged my messy 20+ testing commits.

ah damn forgot about that, a good reminder that we wanted to set squash as default for prs

Good idea.
Now you have my, try, try, finally commit messages in your history. :)

so that everybody these sees that effort you have made ;) thanks for the nice contributions!

authors: FabianHofmann afuetterer lkstrp

repo: PyPSA/linopy


text:
Improve PyThaiNLP performance

PyThaiNLP wants you help us to improve the performance. You can fork this git, coding new code to improve the performance, and send your pull request to PyThaiNLP.
These are some lists for you.

[ ] Delete unused code
[ ] Port model to onnx #639
[ ] Reduce the use of external packages that are not standard Python packages.
[ ] Use Cython for any code but still keep pure python for not installed cython or cannot install cython

I propose to remove tinydb as an external dependency (as mentioned in #506). It seems to me that using a 3rd-party database library is an overkill for just querying a JSON file which is by no means large in size.
tinydb is only used twice, once in init.py for database initialization, which could be simply replaced by creating an empty JSON file, and once in core.py for querying the local database, which could be done using json in the Python standard library instead.
And it is confusing that while tinydb is used to query the local JSON database, it is not used when parsing JSON data returned from https://pythainlp.github.io/pythainlp-corpus/db.json (see core.py).
The performance improvement gained by using tinydb or other 3rd-party database libraries is, I suppose, to be negligible, but to have one more unnecessary external dependency is not a good idea, I think, for future development and maintenance of the project. Instead, JSON querying could be easily done using json in the standard library.
What is your opinion? If you agree, I would be happy to work on this and send an PR.

I propose to remove tinydb as an external dependency (as mentioned in #506). It seems to me that using a 3rd-party database library is an overkill for just querying a JSON file which is by no means large in size.
tinydb is only used twice, once in init.py for database initialization, which could be simply replaced by creating an empty JSON file, and once in core.py for querying the local database, which could be done using json in the Python standard library instead.
And it is confusing that while tinydb is used to query the local JSON database, it is not used when parsing JSON data returned from https://pythainlp.github.io/pythainlp-corpus/db.json (see core.py).
The performance improvement gained by using tinydb or other 3rd-party database libraries is, I suppose, to be negligible, but to have one more unnecessary external dependency is not a good idea, I think, for future development and maintenance of the project. Instead, JSON querying could be easily done using json in the standard library.
What is your opinion? If you agree, I would be happy to work on this and send an PR.

I am agree.

When working on #691, I found a problem relating to the version checking behavior of the corpus downloader.
The downloader checks both the name and the version here, so later if the corpus is found in the local database and a re-download is not forced, the versions should always match.
I'm not sure what the expected behavior is here. If a corpus with the same name but different version is found in local database (and force = True is not specified), should the downloader suggest the user to use force = True or just silently re-download and rewrite the latest version of the corpus?

Yes, It is not force download that you can see https://github.com/PyThaiNLP/pythainlp/runs/7957249794?check_suite_focus=true#step:5:5219 and https://github.com/PyThaiNLP/pythainlp/blob/dev/tests/test_corpus.py#L86.

@wannaphong I mean that since both the name and the version of the corpus is checked, the else block would never be reached, so the user will never be notified that a newer version of the requested corpus is available.
That is, in cases that the corpus is found in the local database, but the version do not match, the latest version of the corpus would be silently downloaded and rewritten. If this is indeed the expected behavior, the else block would be redundant.

OK. I'm agree.

@wannaphong So what is the expected behavior? If the user should be notified to use force = True when newer versions of the corpus are available, I could work on a patch to fix it.

@wannaphong So what is the expected behavior? If the user should be notified to use force = True when newer versions of the corpus are available, I could work on a patch to fix it.

I'm agree. The user should get notified when newer versions are available.

@wannaphong Should be fixed in #692, please review the PR.

I'm doing reduce import time. #719

source: gharchive/issue

authors: BLKSerene wannaphong

repo: PyThaiNLP/pythainlp

license_type: permissive

license_source: bigquery


text:
Logging a TorchMetric resets it, produces very subtle and unexpected behaviour

🐛 Bug
The way I understand it, it is recommended to log a TorchMetric instance, instead of its .compute() output (only if you do this, DDP synchronization is possible, should you want it):
def __init__(self):
    self.val_acc = Accuracy()
    ...

def validation_step_end(self, outputs):
    self.log("val/acc", self.val_acc)

However I was suprised to learn that this also quietly seems to reset the metric, even if the metric should not be reset:
def __init__(self):
    self.val_acc = Accuracy()
    self.val_acc_best = MaxMetric()
    ...

def validation_epoch_end(self, outputs):
    self.val_acc_best.update(self.val_acc.compute())
    self.log("val/acc_best", self.val_acc_best)
    # after this line, self.val_acc_best.value = -Inf

Imagine my surprise that my "best accuracy" was decreasing every few epochs.
To Reproduce
import os

import torch
from torch.utils.data import DataLoader, Dataset
from torchmetrics import Accuracy, MaxMetric

from pytorch_lightning import LightningModule, Trainer

class RandomDataset(Dataset):
    def __init__(self, size, length):
        self.len = length
        self.data = torch.randn(length, size)

    def __getitem__(self, index):
        return self.data[index]

    def __len__(self):
        return self.len

class BoringModel(LightningModule):
    def __init__(self):
        super().__init__()
        self.layer = torch.nn.Linear(32, 2)
        self.val_acc = Accuracy()
        self.val_acc_best = MaxMetric()

    def forward(self, x):
        return self.layer(x)

    def training_step(self, batch, batch_idx):
        loss = self(batch).sum()
        self.log("train_loss", loss)
        return {"loss": loss}

    def validation_step(self, batch, batch_idx):
        val_loss = self(batch).sum()
        self.log("valid_loss", val_loss)
        return {"loss": val_loss}

    def validation_step_end(self, outputs):
        print(self.val_acc_best.value)
        self.val_acc_best.update(outputs['loss']) # get val accuracy from current epoch
        print(self.val_acc_best.value)
        self.log("valid_loss_best", self.val_acc_best)
        print(self.val_acc_best.value)

    def test_step(self, batch, batch_idx):
        loss = self(batch).sum()
        self.log("test_loss", loss)

    def configure_optimizers(self):
        return torch.optim.SGD(self.layer.parameters(), lr=0.1)

def run():
    train_data = DataLoader(RandomDataset(32, 64), batch_size=2)
    val_data = DataLoader(RandomDataset(32, 64), batch_size=2)
    test_data = DataLoader(RandomDataset(32, 64), batch_size=2)

    model = BoringModel()
    trainer = Trainer(
        default_root_dir=os.getcwd(),
        limit_train_batches=1,
        limit_val_batches=1,
        limit_test_batches=1,
        num_sanity_val_steps=0,
        max_epochs=2,
        enable_model_summary=False,
    )
    trainer.fit(model, train_dataloaders=train_data, val_dataloaders=val_data)
    trainer.test(model, dataloaders=test_data)

if __name__ == "__main__":
    run()

As you will see in the output, self.val_acc_best.value will be -Inf in the second epoch, and therefore fails to track the best loss.
Expected behavior

Environment
* CUDA:
        - GPU:
                - NVIDIA GeForce GTX 1060 6GB
        - available:         True
        - version:           10.2
* Packages:
        - numpy:             1.20.3
        - pyTorch_debug:     False
        - pyTorch_version:   1.10.0+cu102
        - pytorch-lightning: 1.6.0dev
        - tqdm:              4.62.3
* System:
        - OS:                Linux
        - architecture:
                - 64bit
                - ELF
        - processor:
        - python:            3.8.12
        - version:           #1 ZEN SMP PREEMPT Wed, 22 Dec 2021 09:23:53 +0000

cc @borda @carmocca @edward-io @ananthsub @rohitgr7

I thought this is the expected behavior. The metric gets reset every epoch.

However I was suprised to learn that this also quietly seems to reset the metric, even if the metric should not be reset:

In which case should the metric not get reset?

A metric that tracks the best metric across epochs should not be reset between epochs.

Yes. This is working as expected given the current design where it is assumed that resetting on epoch end is desired.
ModelCheckpoint is one example of a callback that tracks a metric across all epochs, you'll notice it does not use pl_module.log at all.
For us to implement this, we'd need an argument like log(reset="step"|"epoch"|None)

For the time being, I would recommend you to use self.val_acc_best.compute() and not log the associated metric which is more a cross epoch tracker than a metric.

authors: awaelchli carmocca nils-werner tchaton

repo: PyTorchLightning/pytorch-lightning

license_source: github-api


text:
Checkpoints and loggers saving to different directories

🐛 Bug
The default ModelCheckpoint() callback is saving the checkpoint to a different directory than the directory for the CSVLogger logger I have set up. For example, when the first ever run is made the checkpoint is saved in 0/ while hparams.yaml and metrics.csv are saved in version_0/?
├── pl_logs
│   ├── 0/
│   │   ├── checkpoints/
│   ├── version_0/
│   │   ├── hparams.yaml
│       └── metrics.csv

To Reproduce
import pytorch_lightning as pl
from pytorch_lightning.callbacks.early_stopping import EarlyStopping
from pytorch_lightning.loggers import CSVLogger
from MyDataModule import MyDataModule
from MyModel import MyModel
from test_tube import HyperOptArgumentParser
from test_tube.hpc import SlurmCluster

def train(hparams, *args):
    ## Instantiate Modules ----
    dm = MyDataModule(batch_size=hparams.batch_size, nw=10)
    model = MyModel(
        lr=hparams.learning_rate,
        batch_size=hparams.batch_size,
    )

    ## Loggers ----
    log_csv = CSVLogger('.', name='pl_logs')
    loggers = [log_csv]

    ## Callbacks ----
    cb_earlystop = EarlyStopping(monitor='val_loss')
    callbacks = [cb_earlystop]

    ## Setup Trainer ----
    trainer = pl.Trainer(
        overfit_batches=10,
        min_epochs=1,
        max_epochs=1,
        num_sanity_val_steps=2,
        callbacks=callbacks,
        logger=loggers,
    )

    ## Train Model ----
    trainer.fit(model=model, datamodule=dm)

if __name__ == '__main__':
    ## Setup Hyperparameters ----
    parser = HyperOptArgumentParser(strategy='grid_search', add_help=False)
    parser.opt_list('--learning_rate', default=1e-3, type=float, options=[1e-4, 1e-3, 1e-2], tunable=True)
    parser.opt_list('--batch_size', default=2, type=int, options=[1, 2, 4, 6], tunable=True)
    hyperparams = parser.parse_args()

    ## Setup Slurm Cluster Object ----
    cluster = SlurmCluster(
        hyperparam_optimizer=hyperparams,
        log_path='/home/hunglab/mwarkent/projects/',
        python_cmd='python',
        enable_log_err=False
    )
    cluster.per_experiment_nb_cpus = 12
    cluster.per_experiment_nb_nodes = 1
    cluster.memory_mb_per_node = (16 * 1000)
    cluster.job_time = '07-00:00:00'

    ## Submit Jobs ----
    cluster.optimize_parallel_cluster_cpu(
        train_function=train,
        nb_trials=1,
        job_name='torch',
        job_display_name='torch'
    )

Expected behavior
My expectation was that the checkpoints and all other logger files would be stored in the same versioned subdirectory. I recall this was happening when I used pytorch_lightning previously, but something seemingly has changed.
Environment

PyTorch Lightning Version: pytorch-lightning 1.3.4
PyTorch Version: torch 1.8.1
Python version: Python 3.6.8
OS: Linux
How you installed PyTorch: pip

I just want to confirm what you would like to see in a PR based on our discussions.
So far it seems like this is consensus:

[ ] By default, ModelCheckpoint should use the same version naming system as loggers (i.e. version_{num}, not {num})
[ ] Ensure the same version number is shared between loggers in a LoggerCollection and also with callbacks, such as ModelCheckpoint

Thoughts?

I agree that we want to fix the version issue for logger collection. I think at this point a PR would be welcome <3
However, as I see it, this is completely independent of ModelCheckpoint. There should be no changes required on this side.

authors: awaelchli mattwarkentin


text:
Convert warning message to debug-level info in spawn plugins

What does this PR do?
Suggested by @carmocca and @tchaton
The current warning is not appropriate, it is really more an info.
Before submitting

[x] Was this discussed/approved via a GitHub issue? (not for typos and docs)
[x] Did you read the contributor guideline, Pull Request section?
[x] Did you make sure your PR does only one thing, instead of bundling different changes together?
[x] Did you make sure to update the documentation with your changes? (if necessary)
[x] Did you write any new necessary tests? (not for typos and docs)
[x] Did you verify new and existing tests pass locally with your changes?
[x] Did you update the CHANGELOG? (not for typos, docs, test updates, or internal minor changes/refactorings)

PR review
Anyone in the community is free to review the PR once the tests have passed.
Before you start reviewing make sure you have read Review guidelines. In short, see the following bullet-list:

[x] Is this pull request ready for review? (if not, please submit in draft mode)
[x] Check that all items from Before submitting are resolved
[x] Make sure the title is self-explanatory and the description concisely explains the PR
[x] Add labels and milestones (and optionally projects) to the PR so it can be classified

Did you have fun?
I made sure I had fun coding 🙃
Part of #1 (it's a lie, this is just here to avoid noisy GitHub bot)
cc @borda

@justusschock @tchaton @rohitgr7 @Borda can you give me your opinion on the discussion above.

source: gharchive/pull-request


text:
most basic nft minting is now failing

Describe the bug
Standard example from tutorials fails to execute
To Reproduce

download https://github.com/Python-Cardano/pycardano/blob/main/examples/native_token.py
then run it first time to get the address : in my case addr_test1vzwy2qavznsp3lgut03hp62vyde6y8ttjh3plwk6ds3y4zg37je5g
The use the faucet from cardano to transfer some tADA
Check using cardano-cli the utxo

Logs
`                           TxHash                                 TxIx        Amount
a0facadf037b67622c0099de4f0828bcc81efb910efec8b73e9250044e93712f     0        10000000000 lovelace + TxOutDatumNone`

Now that tADA is there in the wallet, try to mint the NFT
Following error happens: pycardano.exception.UTxOSelectionException: All UTxO selectors failed. inside the function: signed_tx = builder.build_and_sign([payment_skey, policy_skey], change_address=address)
Such a basic thing is now giving error ...something is wrong ...

Expected behavior
Should have just minted the NFT tokens
Environment and software version (please complete the following information):

OS:
Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.6 LTS
Release:	20.04
PyCardano Version [0.9.0]

Additional context
None

I saw a few success NFT mint transactions under your account: https://preview.cardanoscan.io/address/609c4503ac14e018fd1c5be370e94c2373a21d6b95e21fbada6c224a89
Is the issue resolved now?

I am also running into this issue. I think the problem is that it is trying to find input UTxOs for the newly minted native tokens.

AFAIK all minted tokens are considered as inputs in the tx builder, I think there is no need for explicitly adding them

Check out this code
https://github.com/Python-Cardano/pycardano/blob/main/pycardano%2Ftxbuilder.py#L1049

Agreed with @nielstron , all token minted will be provided to tx builder automatically. I am still not sure what the root cause was for this issue. The first thing came to my mind was the chain context, e.g. blockfrost, wasn't in sync with the tip of chain, so it couldn't find the utxo from the new account. If this happens in the future, please post a full log from pycardano, from which we can tell what exactly failed. For example, if UTXO selection failed, it will tell what UTXOs were provided, and what failed to fulfill, see here.

Well, I'm glad I asked first. This was super helpful. My issue is separate from what was reported here then.
I'm building pycardano into a backend application, where the frontend gives me the utxos from a wallet. Because I already have the utxos and I've almost completely removed blockfrost from the workflow, I had to create a custom utxo selection loop outside of the builder because the builder will hit blockfrost for utxos any time non-ada assets are in the outputs.
With the link provided by @nielstron, I can fix this. However, I wonder if there might be a better solution to the current build workflow so that coin selection doesn't force a context call to get utxos.

If you do not provide an input address there should be no call to fetch UTxOs from the chain? If at all that call would be triggered by fee calculation, not presence of tokens.

I would like to close this issue actually because the discussion appears to diverge. @theeldermillenial please re-open a new issue with the full error log when you encounter this issue again and feel free to open an enhancement issue if you feel like the building needs some improvements.

authors: cffls nielstron reitcircles theeldermillenial

repo: Python-Cardano/pycardano

license: MIT


text:
关于redis4proxypool的问题

在docker-compose.yml中，redis4proxypool没有设置开机自启，导致每次重启需要手动开启redis4proxypool，不设置redis4proxypool自启是有什么考虑吗？

docker-compose 只是为了方便测试而设置的，对开机自启什么的没有什么考虑支持。如果要正式部署的话还是建议比如 Kubernetes，设置对应策略来自启。

authors: Germey hourku

license: mit


text:
Replace lib2to3.fixes.fix_dict to avoid unnecessarily list() calls

lib2to3.fixes.fix_dict will basically wrap any call to dict.keys(), .values() or .items() in list() no matter its context.
However as far as I can tell the calls are more or less pointless when the result is either directly iterated upon (e.g. for k, v in d.items()) or checked for containment (e.g. if a in d.keys()) leading to lots of diff-noise to revert.
Would be nice if python-future had its own dict-iteration fixer avoiding this annoyance.

Iterating views while adding or deleting entries in the dictionary may raise a RuntimeError or fail to iterate over all entries.

If the inside of the for loop is adding or deleting entries, then the list() is needed

I've written my own "fix_dict_methods" that does this:
"""Fixer for some dict methods.

Imports these compatibility methods from `future.utils`.

d.iterkeys() -> iterkeys(d)
d.iteritems() -> iteritems(d)
d.itervalues() -> itervalues(d)

d.viewkeys() -> viewkeys(d)
d.viewitems() -> viewitems(d)
d.viewvalues() -> viewvalues(d)
"""

It should be safer for PY2 code that's slowly getting futurized step-by-step.
It doesn't wrap any of the simple .keys/values/items() calls in list() either, since I haven't found many spots we need that fix yet, but I might follow up with it as a separate step - I think I can run the normal fix_dict if I need that change.
Let me know if there is interest in this variant of fix_dict. I'm also up for changing its name. (Maybe fix_dict_methods_with_import?

Hi @rdrey, I am interested in this variant. Sound like a good idea to run it before the normal fix_dict, especially if the codebase always calls the iter version when it only needs iterator.
Do you mind sharing it?

@rkouye here you go: https://gist.github.com/rdrey/a307f46f7708b65421061374a14d60e9

authors: r3m0t rdrey rkouye xmo-odoo

repo: PythonCharmers/python-future


text:
Create view libs protocol.

Hi, I have something for you – https://github.com/Deepwalker/backslant
Actually, if you plan to implement Rails somehow, you need to provide something like ActiveView – one rails project can use wast amount of different view builders and all of them are interchangeable and play nice together.
And in backslant I really did play well with jinja2 – both using iterators inside (generators actually), and its damn simple to make them play well together.
Today I wrote simple thing to support include backslant templates into the jinja templates:
from jinja2.environment import Template
class BSTemplate(Template):
    def __new__(cls, *a, **kw):
        return object.__new__(cls)

    def __init__(self, bs_renderer):
        self.renderer = bs_renderer
        self.name = repr(bs_renderer)

    def root_render_func(self, context):
        return cohorts.render(context=context)

    def new_context(self, vars, shared=False, locals=None):
        return dict(vars=vars, locals=locals)

Its simple to add special case to jinja2, that will eliminate this staff, and will support just generators.
And this is damn simple proto – any view lib must support simple protocol – it return view instance that supports generator protocol.
And we have two libs that almost support it. Backslant actually did, and did it way simpler then jinja2.

Can you propose something in Pull Request that can be used to achieve this goal? For example, we can use Jinja2 and other template engines in he same way. It will be a decoration over the template engines with the same external interface.

By the way, we can do the same for Model layer by adding multiple ORM implementations and use the same interface to interact with them. For example, two developers can use different ORM depends on their needs or qualification. Don't sure that mess of different libs inside one project is a good idea - but it will open the doors to flexibility and allow to integrate other projects with different libs (ORM, template engines) to our existing project and use it without code changes.

@Deepwalker do you have any updates for this issue? I wish to release full-featured version of Python on Rails in coming weeks. You can help me to speed-up this process.

I can write separate ActiveView, that you can include to project as view layer. With support for jinja2, mako etc. Not sure if will be able to make all them interchangable, like in rails, but will try.

@Deepwalker thanks. I will push my changes to a View in coming days. Please check updates before you will push tour changes and create Pull Request.
Our main goals now - create interface to use Model and View layers. It means that customer can select any ORM (SQL Alchemy, SQLObject, etc) and any Template Engine (Jinja2, Mako, etc). When we will do this - we can release a first stable version of the Python on Rails.

Added support for Jinja2 templates. Updated example blog app to use these templates.

repo: PythonRails/rails


text:
Proper usage of NavigationLink?

Can you please elaborate on the usage of NavigationLink with QGrid?

NavigationLink does not seem to be working here.

Hi there,
Feel free to contribute to this project by creating a PR, if you see there is any issue. I'm currently focused on QDesigner Beta (https://Q-Mobile.IT/Q-Designer).
Best,
Karol

Great Work
Can I know how to add action on cell tap?

NavigationLink seem not to be doing good, when the view loads cells all of them turn into blue.
` VStack{
            if networkManager.loading{

                Text("Loading movies")
            }else{

                QGrid(networkManager.movies.results, columns: 3){movie in
                    NavigationLink(destination: MovieDetails(movie: movie)){

                    QGridCell(movie: movie)

                    }

                }

                }

}`

some problem like you, how to fix it

I resolved this issue in my project. It has nothing to do with QGrid.
Your QGridCell should look like this:
struct QGridCell: View {
    var imageName: String
    var text: String

    var body: some View {
        VStack(alignment: .center) {
            Image(self.imageName)
            .renderingMode(Image.TemplateRenderingMode?.init(Image.TemplateRenderingMode.original))
            .resizable()
            .scaledToFit()
            .shadow(color: .primary, radius: 5)
            Text(self.text).lineLimit(1)
        }
    }
}

Please note setting a rendering mode for your image:
.renderingMode(Image.TemplateRenderingMode?.init(Image.TemplateRenderingMode.original))
By default, "linking" controls are blue (e.g. text below the image), so the image is also blue. When you specify the rendering mode, image will be rendered well.

authors: AfroCyberGuy andreykats arquehi gatamar karolkulesza suneelseelam

repo: Q-Mobile/QGrid


text:
'Newtonsoft.Json.JsonSerializationException' for some Rules

I have just installed the Hue Motion Sensor using the official app, and it seems it breaks the Q42.HueApi.
The following JSON causes an exception:

"29": {
"name": "MotionSensor 13.day-on",
"owner": "Ftg8b0E4NVk3vVpodvV-Nh-rg8q3XfB0sDUZv3Hy",
"created": "2016-10-15T12:01:33",
"lasttriggered": "2016-10-23T08:59:32",
"timestriggered": 5,
"status": "enabled",
"recycle": true,
"conditions": [
{
"address": "/config/localtime",
"operator": "in",
"value": "T08:00:00/T23:00:00"
},
{
"address": "/sensors/13/state/presence",
"operator": "eq",
"value": "true"
},
{
"address": "/sensors/13/state/presence",
"operator": "dx"
},
{
"address": "/sensors/15/state/status",
"operator": "lt",
"value": "1"
},
{
"address": "/sensors/14/state/dark",
"operator": "eq",
"value": "true"
}
],
"actions": [
{
"address": "/groups/3/action",
"method": "PUT",
"body": {
"scene": "kZvpr1yJTqvHyQA"
}
},
{
"address": "/sensors/15/state",
"method": "PUT",
"body": {
"status": 1
}
}
]
},

Which API call retuns this json? Getting all rules?

Oh yes..

await Client.GetRulesAsync();

You should be able to re-create if you use the JSON mentioned above.

Fixed with this commit: https://github.com/Q42/Q42.HueApi/commit/d131c2064c83e657039e235f43c4bdaa5ef5f1d1
Main problem was a missing operator (in). And also fixed parsing the sensor action in the json.
New release is on NuGet

Yep, that fixed it :)! Thanks for being so fast!


text:
Driver / AWG5208 fixes

Fixes #1060
The sub-issues of #1060 are addressed/fixed in the following ways

Validators have been updated
Upload of files now by default overwrites (by first deleting the old file if it is present)
Marker stopped value has been added
A method to delete a sequence from sequence list has been added. There is unfortunately no (easy) way to know what sequences a .seqx file contains, so the user should manually delete the relevant sequence from the sequence list.
play now by default waits for the instrument to be ready.

@ThorvaldLarsen @jenshnielsen
@ThorvaldLarsen try to see if awg.play(); awg.run_state() always does what you think it should.

@WilliamHPNielsen I had to change 2 lines to get upload to work:
1090              if lstlens[0] != np.shape(elem_names)[1]
and
1282             for assetname in np.array(elem_names)[:, n-1]

@WilliamHPNielsen Plans got changed so I will be setting this up on T11 also tomorrow. Any chance that this one will be merged in the near future so I don't have to mess to much around with a local file across multiple computers?
If this is still some time out could I ask you to put the driver in wrappers repository? Then I can use the driver from there until this one is done.

Yes, carrying around a local file between two computers atm.

Gotcha.

@ThorvaldLarsen, I think the current version addresses all of the points you raised in this conversation. Can you confirm, then I'll merge it in.

Yes this looks good. Just tested it and my upload works with this version.
Thanks!

Great, thanks! Then I just need to make the tests pass 😛

authors: ThorvaldLarsen WilliamHPNielsen

repo: QCoDeS/Qcodes


text:
CF error for VPC

Hi,
This is my json for vpc, and ma getting an eror while creating stack:-
Template validation error: Template format error: Unresolved resource dependencies [cfcidr] in the Resources block of the template
{
"AWSTemplateFormatVersion": "2010-09-09",
"Description": "Create VPC",
"Parameters": {
    "netcidr": {
        "Description": "CIDR for the VPC",
        "Type": "String",
        "Default": "10.10.0.0/16"
    }
},

"Resources": {

    "cfvpc": {
      "Type": "AWS::EC2::VPC",
      "Properties": {
        "CidrBlock": {"Ref": "cfcidr"},
        "EnableDnsHostnames": true
      }
    }

}

}

Thanks a lot.
Sorry for the very silly mistake.

repo: QT-DevOps/DevOpsIssues


text:
Do landing page

Added a landing page for QUT DO team. At the moment, this page is not accessible via the header nav but through a link in the About us page. The URL of the landing page is /qut-digital-observatory.
My aim is to have the page deployed on Monday, in time for the RI newsletter which will include this link.

Thanks for the edits Alice! I'll merge now.


text:
AKQAS-BUG#001

当点击“？”时，
Traceback (most recent call last):
File "E:\科创编程比赛参评\参评作品（2022省）\2022省馆信息素养提升实践活动（江油实验学校报绵阳5件）\航天知识学习检测系统（钱羿帆）\航天知识学习检测系统\Main.py", line 168, in
main()
ile "E:\科创编程比赛参评\参评作品（2022省）\2022省馆信息素养提升实践活动（江油实验学校报绵阳5件）\航天知识学习检测系统（钱羿帆）\航天知识学习检测系统\Main.py", line 47, in main
#### questions()

File "E:\科创编程比赛参评\参评作品（2022省）\2022省馆信息素养提升实践活动（江油实验学校报绵阳5件）\航天知识学习检测系统（钱羿帆）\航天知识学习检测系统\Main.py", line 88, in questions
#### ex = eg.ccbox("请选择： ", "qyf-rycbstudio.github.io", ["继续", "返回"], image="./ques.png")

File "E:\python123\lib\site-packages\easygui\boxes\derived_boxes.py", line 91, in ccbox
#### return boolbox(msg=msg,

File "E:\python123\lib\site-packages\easygui\boxes\derived_boxes.py", line 147, in boolbox
#### assert False, "The user selected an unexpected response."

AssertionError: The user selected an unexpected response.

已解决。
resolved.


text:
Expose ability to set python version via client

What is the expected behavior?
Expose ability to set python version via client.
Something like
serverless.run(program, config=Configuration(python=Configuration.PY_39))

closing as done by #1077

repo: Qiskit-Extensions/quantum-serverless


text:
for operator, use to_xxx() rather than _check_xxx or convert

What is the expected enhancement?
Since current operator support single representations, use convert method results in error, it is safer to use to_matrix() or to_paulis() or to_grouped_paulis()

resolved by #188

repo: Qiskit/aqua


text:
Consider adding a check for notebook (and image?) file size

https://github.com/Qiskit/documentation/pull/1673 is an example of an enormous file size we didn't realize. That has two major downsides:

Makes the site slower for users to access, especially when they have slow Internet
Slows down next.js's build process

I think https://github.com/Qiskit/documentation/issues/1672 may help address this. But either way, we may want to add a check that file sizes don't cross a threshold, e.g. >400MB. This would be at least for Jupyter notebooks, but maybe also for dedicated image files.
The allowlist mechanism should set new thresholds, e.g. (my-file.ipynb, 600) to set a threshold of 600MB.
FYI: how to reduce Jupyter notebook image size
Often PNGs are smaller than SVGs:
# Don't use SVGs for this file because the images are too large,
# and the SVGs are much larger than their PNGs equivalents.
%config InlineBackend.figure_format='png'

You can reduce the resolution of Matplotlib figures. However, this often makes the image less useful and I think it tends to be better to instead set figsize:
import matplotlib
matplotlib.rcParams["figure.dpi"] = 100

You can sometimes set figsize directly in Qiskit SDK:
# We set `figsize` to a smaller size to make the documentation website faster
# to load. Normally, you do not need to set the argument.
plot_gate_map(backend, figsize=(4, 4))

If figsize is not exposed, then you can change the returning figure:
fig = plot_circuit_layout(isa_circuit, backend=backend)
fig.set_size_inches(0.5 * fig.get_size_inches())
fig

One of the other techniques is to see if any of the images can be removed entirely. Are they pulling their weight?

Note that unless the SVG is is orders of magnitude bigger than its PNG equivalent, it may still load faster for users. SVGs can be compressed a lot when sent over the network, whereas PNGs are already compressed so the file size we see is much closer to what's actually sent.

authors: Eric-Arellano frankharkins

repo: Qiskit/documentation


text:
Login using IBM Cloud API key

What is the expected feature or enhancement?
A user should be able to login using their IBM Cloud API Key.
class IBMRuntimeService(RuntimeService):
    def __init__(self, auth=None, token=None, locator=None):
        """Initialize a new client to use the runtime service.

        Args:
            auth: Authentication type. `cloud` or `legacy`. If not specified, the saved default is used.
                If there is no default value, and both accounts were saved on disk, the cloud type is used.
            token: Token used for authentication. If not specified, the saved token is used.
            locator: The authentication url, if `auth=legacy`. Otherwise the CRN.
        """
        pass

When the user does
service = IBMRuntimeService(token="<apikey>", locator=<CRN>)

no API calls would be made but the passed in values should be stored in the RuntimeClient.
And then for subsequent calls made to the API like service.programs() or service.pprint_programs() the
Service-CRN: <paste-CRN-here> and Authorization: apikey <paste-apikey-here> headers should be sent with every request.
The URL for production vs staging should be automatically determined based on the cname in the CRN. staging for staging vs bluemix for prod.
Example curl to get programs:
curl --location --request GET 'https://us-east.quantum-computing.cloud.ibm.com/programs' --header 'Service-CRN: <paste-CRN-here>' --header 'Authorization: apikey <paste-API-key-here>'

Took a look at the implementation details and see the risk to bloat or overload some of the function signatures if we stick with the plan to use the same class (IBMRuntimeService) to handle both cases in a fully transparent way.
Context
To my understanding there are different terms that end users are familiar with, i.e.

familiar to users of http://cloud.ibm.com/ ("cloud")

API key
CRN

familar to users of https://quantum-computing.ibm.com/ ("legacy")

API token
Authentication URL
Hub, Group, Project

Challenge / Risk
To map the above terms to the proposed common interface, additional overloaded terms like locator have to be introduced. This might come with an additional learning curve and/or confuse users.
cloud_service = IBMRuntimeService(auth="cloud", token=cloud_api_key, locator="crn:v1:bluemix:public:quantum-computing:us-east:...")
legacy_service = IBMRuntimeService(auth="legacy", token=legacy_api_token, locator="https://auth.quantum-computing.ibm.com")

The same challenge will also become relevant when the save_account function is updated to serve both worlds.
# how to extend this
IBMRuntimeService.save_account(
    token: str, url: str,
    # how to design the interface to not mix and match parameters that are only relevant for legacy/cloud
    hub: Optional[str] = None,
    group: Optional[str] = None,
    project: Optional[str] = None,
)

Proposal
from abc import ABC
class IBMRuntimeService(ABC, RuntimeService):
    # implements common functionality across cloud / legacy but is not directly instantiated

class IBMCloudRuntimeService(IBMRuntimeService):
    # cloud users explicitly need to instantiate this class
    def __init__(self, api_key, crn):

class IBMLegacyRuntimeService(IBMRuntimeService):
   # legacy users explicitly need to instantiate this class
    def __init__(self, token, url):

@rathishcholarajan, @jyu00 - added a few thoughts in my previous commment. Let me know what you think (or discuss on Monday).  As always: I may be totally wrong with these concerns. If so, I'm happy to learn why.

Discussed in during our daily sync meeting and agreed to move forward as initially planned for now (i.e. use a single IBMRuntimeService). This decision is heavily based on the assumption that the runtime APIs will be the same across Cloud/Legacy and not require users to supply different parameters (cc: @renier).

repo: Qiskit/qiskit-ibm-runtime


text:
PEXPIRE command support

PEXPIRE DOC

Also did some tweaking to Expiry to just hold a timestamp
We also probably want to change parse to return a Result to avoid indentation hell

Is it mergeable? (we should use draft / open mode on PR - then we know when it's meargeable)

Is it mergeable? (we should use draft / open mode on PR - then we know when it's meargeable)

yeah all seems to be fine

repo: Qovery/RedisLess


text:
An example that correctly extracts the specs from '@spec'!

It also does not break the documentation :-D.
Related to #17 .
Before this can be merged, we definitely need the following:

An option added to use TypeCheck that enables this behaviour. Maybe read_attributes: true (defaults to false)?
An option added to use TypeCheck that explicitly not writes types/specs to the type-attributes for when someone wants to customize them separately. Maybe write_attributes: false (defaults to true)?
Remove the example-file before merging.

This is awesome! I've already tried it in my codebase for a number of files and it seems to work.
If we can use @spec/@type and it supports all of the standard typespec syntax (eventually) plus the special powers your library already provides, the spec/type syntax no longer needs to be used, right? This would be even better than I might have envisioned since there is no new keyword at all.
Additionally, I'm going to play devil's advocate here even though I likely don't understand all of your goals or some of the ramifications, but are 1 and 2 really necessary? Isn't it enough flexibility that you can choose to use TypeCheck on a specific module as needed already? I just wonder if additional config options might make for more confusion.

I can envision cases where the attributes the user would like to have different values in the documentation vs. for the typechecking, if only because it is difficult to have a 100% feature-parity between Elixir's builtin typespecs and TypeCheck (although I want to try to reach this). For instance, I don't yet have a good idea of how to tackle #5.
However, if the code of this branch works properly (i.e. if there are no edge-cases that we've missed so far), I think that read_attributes: true will probably become be the default when someone calls use TypeCheck.

I continue to love working with @spec and @type from this branch. One thing I was thinking about was whether this might create any confusion where someone either:

Doesn't know their use of @spec is subject to TypeCheck
Thinks @spec is subject to TypeCheck, but it is not

I've already had a few times where I thought I was using TypeCheck, but then quickly realized my tests were passing with incorrect types and that I had just forgotten to use TypeCheck. Not a big deal because I suspect similar modules in a lot of codebases will use a shared module that brings TypeCheck in.
All that being said, part of me wonders if it is more explicit if, say, @spec!/@type! were used specifically when you want TypeCheck to do it's thing and then @spec/@type stay as they are. This might eliminate some of the need for some of these configuration switches as well and make it easier for existing codebases using typespecs to gradually switch in an explicit way (I know the configuration toggles also help with this though). And then if the library ever gets to the point where it can fully handle an existing codebase with @spec/@type, that option is added. And then it eventually goes into Elixir core (muhahahah).
Anyway, just some rambling thoughts.

All that being said, part of me wonders if it is more explicit if, say, @spec!/@type!  were used specifically when you want TypeCheck to do it's thing and then @spec/@type stay as they are.

This is a great idea! I think it is a perfect marriage between explicitness (not altering existing behaviour) and the 'principle of least surprise' (people will know how it probably works without having to look it up).
I'll alter this PR to work with @spec! and @type! instead, and will rename the macros to reflect this change as well.

Closed in favour of #23

authors: Qqwy baldwindavid


text:
Share postgresql docker container for tests

A new container is started for each test, it shouldbe shared

Done

repo: Qrlew/qrlew


text:
Screenshot Quality

Independent of #301, we should make sure that screenshots are not comprised of unnecessary whitespace (for ex., grabbing a whole window when we only see action in a small section).
Probably the best way to implement this is to take subsets of existing screenshots when they're problematic.

Lectures with screenshots:

[ ] getting_started
[ ] tools_editors
[ ] version_control
[ ] testing

OK, most of these were in version_control. Went through and cropped the offenders, we should see the changes reflected in tomorrow's build.

repo: QuantEcon/lecture-source-jl


text:
read_dimensions: crashes when mdd has meta on columns that are not in the ddf

Currently, it is assumed that the ddf contains all columns listed in the .mdd metadata. This might not be the case and should not lead to data inconsistencies (while ddfs with columns not registered in the mdd would). We should catch these situations and report them while converting; right now the method will simply crash with a KeyError.

Resolved by #709.

authors: alextanski jamesrkg

repo: Quantipy/quantipy


text:
numpy.NAN/ INF now converted to '-' in dataframe columns in ExcelPai…

…nter

This PR resolves #468.

authors: AlasdairE jamesrkg


text:
support batch circuit execution

this would allow the compiler to generate a batch of quantum operations on a batch of registers, via a new keyward
for id in @eachregister
    if configs[id] == 1
           1 => X
    end
end

A better way could be
@eachregister id begin
    if configs[id] == 1
           1 => X
    end
end

actually @register id <expr> might be better


text:
Completing the non-Clifford capabilities [$800]

Bug bounty logistic details (click to expand)
To claim exclusive time to work on this bounty either post a comment here or message skrastanov@umass.edu with:

your name
github username
(optional) a brief list of previous pertinent projects you have engaged in

Currently the project is claimed by no one until ....
If you want to, you can work on this project without making a claim, however claims are encouraged to give you and other contributors peace of mind. Whoever has made a claim takes precedence when solutions are considered.
You can always propose your own funded project, if you would like to contribute something of value that is not yet covered by an official bounty.

Project: Completing the non-Clifford capabilities [$800]
This library already has some nascent capabilities to represent non-Clifford states as a weighted sum of tableaux states. Such a representation is useful in settings where there is a small number of non-Clifford gates in a mostly Clifford circuit. The cost is still exponential in the number of non-Clifford gates, but manageable. We have simple state representation and gate application already done, expect is nearly implemented in this PR, and project! still needs to be implemented. To obtain this bounty, the aforementioned features need to be completed, well tested, and well documented.
Required skills: Understanding of the Stabilizer formalism and decompositions of arbitrary states in terms of Pauli channels
Reviewer: Stefan Krastanov
Duration: 2 months
Publication: In the next 2 years we plan to release a paper in a selective journal about this software. Contributing to this issue would deserve a co-authorship status on such a paper (if the contributor so desires)
Payout procedure:
The Funding for these bounties comes from the National Science Foundation and from the NSF Center for Quantum Networks. The payouts are managed by the NumFOCUS foundation and processed in bulk once every two months. If you live in a country in which NumFOCUS can make payments, you can participate in this bounty program.
Click here for more details about the bug bounty program.

I checked out Ted's paper some time ago, which seems very exciting. Your initial work on non-Clifford is also quite cool about generalized stabilizer.
Therefore, I will be delighted to work on this as that will teach me more about non-Clifford functionalities.
Also, there is a question I wanted to ask you: is non-Clifford the same as non-stabilizer/non-stabilizerness? In some papers, they use the term non-stabilizerness (when they refer to magic, they call it a non-stabilizerness)

Sounds good! Happy to reserve this bounty for you for the next two months.
Yes, the terms you mentioned are frequently used interchangeably.

Overall progress on Non-Clifford functionalities are divided into the following parts: 1) implementing the basic TODOs, 2) fixing bug in expect, 3) implement project 4) providing user rich experience by having implemented most APIs from #260
to push them asap after this issue 5) Overall documentation 6) scaffolding for future non-cliff functionality/APIs.

#346
#348
Only project! is left. I am working on it locally, while waiting for the above PRs to be reviewed.
Documentation: Improved the documentation in 1).  Future work will be to have a dedicated section in (stabilizer manual) stab_.md just like we have a detailed section for MixedDestablzier.
Opened an issue about md ⊗ S"X" in #339.
To fully utilize non-clifford functionality, there are important API that are necessary to work with sm which are in PR #260.  Atm, I have also completed 5 of them. So, they can the easily added to provide rich non-clifford functionality as soon as possible.  Thus, PR #345 implements  sm⊗sm, tHadamard*sm, pcT⊗P"X" , pcT*tId1 , P"-Y"*sm and copy(sm). Outputs of these tasks: https://github.com/QuantumSavory/QuantumClifford.jl/pull/316#issuecomment-2282218098
To realize embed for sm, #342 that provided embedding for Tableau and Stabilizer
Experimental Work on conj_destabs: https://github.com/QuantumSavory/QuantumClifford.jl/discussions/347
Also, we need for base.zero operators for MixedDeStabilizer , Destabilizer, MixedStabilizer,  they will be helpful for later use. Even size(md)[1], or size(md)[2] gives error atm. I have fixed them, but didn't push the PR yet.

@Fe-r-oz , what is the status of your work on this bounty? I see you have done a lot of quality of life improvements and additions to tests (certainly useful!). Among the actual main components of the work, I see you have finished expect (probably the most important completed part of the work).
It seems projectrand! is the main component left -- without it, the smaller "quality of life" improvements are not as useful. And it seems projectrand! has been the main "difficult" or "substantial" component. Could you focus on it so that we can wrap up the bounty? The work left after this is done would be much easier and more straightforward in comparison.

Note that this was reserved in July to be done by September. While you have been doing great work, I am not very comfortable keeping a bounty reserved while you are working on other bounties.

Thank you for the feedback. Currently, only projectrand! remains to be completed. I’ve updated the tests in line with your comments in PR #355 today, confirming that result1 or result2 yield a zero matrix in stabilizer state projections using GeneralizedStabilizer for single-qubit Pauli operators, which suggests that the approach is on the right track. The tests have also been updated to use random_stabilizer/pauli for this specific case.
Additionally, smaller work includes informative error message for the project! function today, drawing from your insights in #355. This updated message is reflected in PR #416 and incorporates both your suggestions from #355 and relevant details about pauli measurement from the associated paper with general documentation in #409. I hope we can integrate these improvements as well.
I plan to implement projectrand! by November 10th, 2024, by utilizing the density matrix update χ′, which is calculated using χ′=expect(p,genstab) and the corresponding probability defined by prob=(real(χ′)+1)/2. I hope to provide a valuable foundation via projectrand! for testing the consistency of multi-qubit, non-stabilizer operations by this date to facilitate future developments.

Hi Stefan, I wanted to provide you with an update on the bounty.
In #355, we demonstrate that multi-qubit non-stabilizer circuits, incorporating non-Clifford gates at randomized positions, can be probabilistically projected through repeated trials. These findings align with Ted's concluding observation that "no magic state will be simulatable through every stabilizer circuit" particularly given the assumption that BQP is larger than BPP. Ted also raised an unresolved question: "What conditions are both necessary and sufficient for determining the set of quantum states (magic states) that can be simulated through stabilizer circuits?"

In addition, as an example, attached is the .txt file showing the results of applying a randomized 3-qubit non-Clifford gate to a stabilizer circuit for multi-qubit projection. The results demonstrate that the post-measurement complex density matrices match the expected outcomes (printed as TRUE), supporting Ted's comment that we can simulate some 'magic' states using the stabilizer-defined basis. However, not all 'magic' states are simulatable in this way (printed as FALSE), as noted by Ted. These specific results have been reproduced via reproducible 2 from https://github.com/QuantumSavory/QuantumClifford.jl/pull/355#issuecomment-2465850317. PFA: 3_qubit_ncgate_results.txt.
Tests for a probabilistic non-stabilizer simulator have been added, evaluating up to 10 qubits with random non-Clifford gates at randomized positions. This message serves as a brief summary of the findings.
I look forward to hearing your thoughts. Thank you!

Future prospects: The paper Unbiased Simulation of Near-Clifford Quantum Circuits echoes similar insights as mentioned in Ted's one of concluding paragaph. Given that the dynamics of a general quantum system fall within the complexity class BQP, a scalable method for simulating universal quantum circuits on a classical computer is highly unlikely. This paper addresses the simulation of stabilizer circuits with non-stabilizer errors by representing these errors as quasiprobability distributions over stabilizer operations. The authors present a new method for simulating arbitrary quantum circuits that combines the efficiency of stabilizer propagation with Monte Carlo sampling via stabilizer channel decomposition.

Thank you for your feedback during the previous review.
Last week, I implemented the Pauli measurement algorithm for projectrand! in PR #427. I look forward to your review. Thanks!

authors: Fe-r-oz Krastanov


text:
exporter_exporter windows service functionality

Currently, exporter_exporter does not have means to run as a windows service. Running it as a service on windows without a service wrapper a la nssm/winsw would be ideal.
I also investigated the possibility of building it as an MSI package with INSTALL_OPTIONS a la wmi_exporter.
Is this worth investigating?

I don't have access to a Windows system to test on, but if you can get something working I'd definitely consider the patches.
Ideally it would fit with the existing release process.

I'd be interested in this too. We are currently using an in-house chocolatey package which basically wraps it in nssm to have a service.

The golang 'svc' package provides means to build Windows services. wmi_exporter and telegraf make use of it.
Examples can be found here:
https://github.com/golang/sys/tree/master/windows/svc/example
The bosun project has a very good example on how this works:
https://github.com/bosun-monitor/bosun/blob/master/cmd/scollector/service_windows.go
Perhaps we could implement similar functionality and then use smth like
exporter_exporter.exe -winsvc install

@frunzales I had a look at the bosun example, it looks reasonable enough. If the flag can be hidden on non-winodws OSes, that would be ideal. I'll happily accept a PR, but I can't work on this myself (just don't have access to something to test on, sorry).

authors: LDaneliukas frunzales tcolgate


text:
🛑 Portfolio is down

In 296251a, Portfolio (https://www.quentinp.me) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Portfolio is back up in c6dfff4.

repo: QuentinPhilipp/uptime


text:
Modify frame ninepatches

I've changed frame and transparent frame images to improve scaling. Try to rebuild the UI and see if it looks better. I think the black lines around the edges were added by mistake, or at the very least they do not look intentional.
Also, I have a suggestion about the buttons with the icons such as play.png or sound.png. Instead of shipping the icons with the background in a single image, use icons with transparent background and the same frame ninepatch along with an ImageButton (button + image child) or ImageTextButton (button + image & label children). Both are supported by ktx-scene2d.
Same goes for game_hud.png. You essentially "hardcoded" the bottom UI panel with that image, which will make it difficult to change or scale. You should recreate this HUD with Scene2D widgets such as Tables. Note that Table can have a custom background and accepts ninepatch drawables AFAIK.

I think the black lines around the edges were added by mistake, or at the very least they do not look intentional.

From my understanding this is how 9-patches work. There needs to be 4 black lines at the edges so that you know which area is scalable. From the official documentation

In the following picture, I have defined what area the content will be placed in (in other words, what will be scaled), and what areas I don't want to scale. Again, this is achieved by padding with a 1 pixel border in the image.

Also, I have a suggestion about the buttons with the icons such as play.png or sound.png. Instead of shipping the icons with the background in a single image, use icons with transparent background and the same frame ninepatch along with an ImageButton (button + image child) or ImageTextButton (button + image & label children). Both are supported by ktx-scene2d.

I had the same idea but I hate working on UIs and in the end it would look the same as it does now, except that the UI.atlas becomes little bit smaller ;)
Fully agree that this would be the better way to do it but it takes me most likely again 2 or 3 hours to make it look the same as it does now and I don't have the motivation for that. But feel free to assist me!
I had the intention to mention it in the video tutorial series, that this should be the way to go.

Same goes for game_hud.png. You essentially "hardcoded" the bottom UI panel with that image, which will make it difficult to change or scale. You should recreate this HUD with Scene2D widgets such as Tables. Note that Table can have a custom background and accepts ninepatch drawables AFAIK.

Agree here as well but I also wanted to keep that for the video tutorial series to showcase two approaches. The "quick&dirt" GameUI approach with hardcoding things (=bad practice) and the LoadingScreen/MenuScreen and GameOverScreenUI approaches with using tables (=best practice).

From my understanding this is how 9-patches work. There needs to be 4 black lines at the edges so that you know which area is scalable. From the official documentation

I'm not referring to the lines at the edges, I'm referring to the lines around the corners. See the diff:

in the end it would look the same as it does now

That's true for now, but if you end up changing the button style, you'll have to replace all the graphics.
If you have the original icons without the button backgrounds, I could see what I can do.

If you have the original icons without the button backgrounds, I could see what I can do.

I just drew some pixels again with an online tool since Gimp makes me crazy with it's very unintuitive behavior.
I will try to improve that and also see what I can do with the corners that you mentioned in the frames. Thanks for pointint that out!

authors: Quillraven czyzby

repo: Quillraven/Dark-Matter


text:
Regression: Internal Error in dev environment when running with an empty (dummy) mod

This did not happen in loader 0.22.0. It apparently happens because newer versions expect some META-INF files relating to if the mod has to be remapped.
Reproduction

Clone the template mod repo
Run runClient once to generate the run directory
Drop in a jar file containing only
quilt.mod.json
Run the client again.
Observe the following crash:
crash-2024-04-01_17.44.47.7103-quilt_loader.txt

Can you retry with 0.25.0-beta.1? I think I encountered this issue and quietly fixed it in commit 1c74011 Fix annotations not applying properly to packages.

repo: QuiltMC/quilt-loader


text:
Fix normalized number by removing ( and -) in phone

Normalized number returns blank when the number contains brackets. So got the normalized number by removing the brackes and hyphens in the phone

Thanks @sureshmi. We shouldn't alter whatever's returned by android. If you want to alter the normalized phone number you get by default, you should probably do it in your app directly.

authors: joachim-quis sureshmi


text:
Add filters to MatchMS data to remove spectra with invalid RT & RI

Spectra which have neither RT nor RI are currently not useable/don't contribute anything to the computations, so should be filtered out after reading the initial file.

Options to filter the structures could also include:
molecular weight / monoisotopic mass range
elements present
bp (predicted) range of compounds
Also, it would be good to be able to set an m/z window for the spectra.

@ElliottJP This is mostly a functionality of matchms - this was for reading files only where there might be some invalid RI. Currently, they are handled as None, but it would be better to either discard them or not allow reading the file in order to avoid the overhead from dealing with this problem.

Depends - we often have spectra without Rt/RI (they can be imputed) that in some cases are used purely for matching.

Well the matching is not part of the tool itself so doesn't really need to be respected. It also just makes handling the data a lot easier if the dataframes aren't expected to have missing values

authors: ElliottJP hechth

repo: RECETOX/RIAssigner


text:
install iRODS on dev-immcellfie

( Project Plan )
Which deliverable?
Which repos (e.g., tx-logging)?
Repo - immcellfie-api
Short name
Description
install iRODS on dev-immcellfie
Related tickets
Steps to close this ticket
Close ticket when... @krobasky to fill in steps to close.

irods installed on dev-immcellfie

authors: LauraCapps xu-hao

repo: RENCI/fuse-immcellfie


text:
panic when providing an incorrect interface

In the interface wrappers there are panics raised when trying to read a contract with the incorrect interface (e.g. https://github.com/RGB-WG/rgb-interfaces/blob/master/src/rgb20/wrapper.rs#L86). These panics have broken a method in rgb-lib, where we get a contract ID and a contract interface and we verify that the user has provided the correct iface (e.g. doing let contract = runtime.contract_iface_class::<Rgb20>(contract_id);). @dr-orlovsky please suggest a workaround for this or remove the panic

As I suggested in the beginning, the panic helped to find a real bug: Stash::impl_for::<C> instead of error NoAbstractImpl somehow resolves to an implementation of RGB20 for RGB21 interface...

authors: dr-orlovsky zoedberg

repo: RGB-WG/rgb-std


text:
Support Testnet4 Network

This PR updates rgb-std to be compatible with the latest Network changes, including support for Testnet4.
It also fixes a compilation error encountered during the development process.
If you have any suggestions, please leave your valuable comments, I will actively cooperate with the revision, thank you very much

We need to remove mut, not the reference. Also, the patch should go into a dedicated section of Cargo.toml as I pointed out elsewhere

I agree with you. We're done :)


text:
geom_gate(aes(col = "node")) - map geom_gate col to nodes

Hi Mike,
Just wondering whether we can map the colour of the gate to the name of the population (i.e. differnet gate colour for each population)? It would be nice to show the node names for a given gate in the legend...
Not sure if this is possible?
Thanks.
Dillon

good point. Will need come up an intuitive yet simple argument to control what to display
instead of type = "gate_name", we can do
geom_stats(type = "count", show_gate_name = TRUE)

but this won't meet the need of only showing the gate name

can we pass a vector type=c("count","gate_name")

Then we will use space to separate two strings. I like that!

I have accomplished this using the plotrix package for base graphics. It would be great if we could do it with ggcyto - overcrowding may be an issue...

I am not sure what your use case will be (why not post whatever example plot you were talking about).
ggcyto was designed in the way that you typically don't expect too many gates placed on 2d space for any given parent population,

I guess the most gates would be the quadrant gate situation....in some situations the channel/markernames are not sufficient to describe the population just by looking at the plot - it would be nice to have this information somewhere in plot so you don't have to refer to the text to figure out what the populations are...

This is not a good quadGate in the first place

@DillonHammill I see what you're getting at.  Would some transparency for the background of the label be acceptable in the meantime?

@mikejiang  I wonder if we could leverage the ggrepel package to label the populations in the gates. The idea would be to have the gate name as the label, but rather than place it in the center of the gate, place it somewhere else (using ggrepel) and have it point to the center of the gate.

Yeah that would help!

@DillonHammill can you try passing aes(alpha=0.5) to the geom_stats() layer?

@DillonHammill just a note that passing alpha to geom_stats works for me when using ggcyto but not autoplot.

Great! Thanks guys!

@gfinak , see this
p + geom_stats(type = c("gate_name", "percent"), fontface= "bold")

I will look into ggrepel  when I get a chance

That is excellent thanks @mikejiang!

authors: DillonHammill gfinak mikejiang

repo: RGLab/ggcyto


text:
CLOUDP-119550: Fixed incorrect tag for the manager

All Submissions:
Resolves https://jira.mongodb.org/browse/CLOUDP-119550 for this fork

[x] Have you signed our CLA?
[x] Put closes #XXXX in your comment to auto-close the issue that your PR fixes (if there is one).

Hi @igor-karpukhin can you resubmit this PR against RHEcosystemAppEng/dbaas-refactor-rebased branch? This is where the RHODA release build is based on. Thanks.

@igor-karpukhin @jianrongzhang89 changed base branch.


text:
[Snyk] Security upgrade axios from 1.4.0 to 1.6.0

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to fix one or more vulnerable packages in the `npm` dependencies of this project.
Changes included in this PR

Changes to the following files to upgrade the vulnerable dependencies to a fixed version:

package.json
package-lock.json

Vulnerabilities that will be fixed
With an upgrade:

Severity
Priority Score (*)
Issue
Breaking Change
Exploit Maturity

748/1000  Why? Proof of Concept exploit, Recently disclosed, Has a fix available, CVSS 7.1
Cross-site Request Forgery (CSRF) SNYK-JS-AXIOS-6032459
No
Proof of Concept

(*) Note that the real score may have changed since the PR was raised.

Commit messages

Package name: axios
    The new version differs by 25 commits.

f7adacd chore(release): v1.6.0 (#6031)
9917e67 chore(ci): fix release-it arg; (#6032)
96ee232 fix(CSRF): fixed CSRF vulnerability CVE-2023-45857 (#6028)
7d45ab2 chore(tests): fixed tests to pass in node v19 and v20 with `keep-alive` enabled; (#6021)
5aaff53 fix(dns): fixed lookup function decorator to work properly in node v20; (#6011)
a48a63a chore(docs): added AxiosHeaders docs; (#5932)
a1c8ad0 fix(types): fix AxiosHeaders types; (#5931)
2ac731d chore(docs): update readme.md (#5889)
88fb52b chore(release): v1.5.1 (#5920)
e410779 fix(adapters): improved adapters loading logic to have clear error messages; (#5919)
bc9af51 fix(formdata): fixed automatic addition of the `Content-Type` header for FormData in non-browser environments; (#5917)
4c89f25 fix(headers): allow `content-encoding` header to handle case-insensitive values (#5890) (#5892)
ae00391 docs(paramsSerializer config within request config): update documentation for paramsSerializer
a989ccd Change isNaN to Number.isNaN
b5b7760 docs: fix CommonJS usage note
9e62056 fix(types): removed duplicated code
6365751 chore(release): v1.5.0 (#5838)
1601f4a feat(export): export adapters without `unsafe` prefix (#5839)
dff74ae docs: linting documentation notes (#5791)
ca73eb8 feat: export getAdapter function (#5324)
9a414bb fix(adapter): make adapter loading error more clear by using platform-specific adapters explicitly (#5837)
b3e327d fix(dns): fixed `cacheable-lookup` integration; (#5836)
8fda276 fix(headers): fixed common Content-Type header merging; (#5832)
d8b4ca0 fix(headers): added support for setting header names that overlap with class methods; (#5831)

See the full diff

Check the changes in this PR to ensure they won't cause issues with your project.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
🛠 Adjust project settings
📚 Read more about Snyk's upgrade and patch logic

Learn how to fix vulnerabilities with free interactive lessons:
🦉 Cross-site Request Forgery (CSRF)

/retest

/retest

I thought I did disable this, but looks sane, lets get it in :)

repo: RHEnVision/provisioning-frontend


text:
🛑 RC Documentation is down

In 6fd5a90, RC Documentation ($URL_RC_DOCUMENTATION) was down:

HTTP code: 0
Response time: 0 ms

Resolved: RC Documentation is back up in 4a22a29.

repo: RIT-RC/rc-status-page


text:
🛑 CEOTR Home Page loads is down

In eaa1e00, 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 4e43e74 after 43 days, 8 hours, 52 minutes.

repo: RKTowse/upptime


text:
🛑 Sensor Tracker login is down

In 83cfe67, 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 d66d380 after .


text:
🛑 CEOTR Home Page loads is down

In dad7072, 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 07bd498 after 2 minutes.


text:
🛑 Sensor Tracker login is down

In 99c4485, 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 7bc125c after 1 minute.


text:
🛑 CEOTR Home Page loads is down

In 037451d, 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 cd87a85 after 2 minutes.


text:
🛑 CEOTR Home Page loads is down

In dd9b588, 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 b943e49 after 2 minutes.


text:
🛑 CEOTR Home Page loads is down

In 9917135, 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 d12ceec after 2 minutes.


text:
🛑 CEOTR Home Page loads is down

In b9a4d51, 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 b975f65 after 2 minutes.


text:
🛑 Sensor Tracker login is down

In fe15ac4, 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 a4892eb after 1 minute.


text:
🛑 Sensor Tracker login is down

In 271d4d7, 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 a9878bd after 1 minute.


text:
🛑 Sensor Tracker login is down

In ea9dad6, 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 2e9cee8 after .


text:
🛑 CEOTR Home Page loads is down

In c6c858e, 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 0eb9fcb after 2 minutes.


text:
🛑 Sensor Tracker login is down

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

HTTP code: 502
Response time: 43 ms

Resolved: Sensor tracker login is back up in 7c70835.


text:
🛑 Sensor Tracker login is down

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

HTTP code: 502
Response time: 97 ms

Resolved: Sensor tracker login is back up in 7a56c0b.


text:
🛑 CEOTR Home Page loads is down

In 5e43baa, 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 82d04b2.


text:
🛑 CEOTR Home Page loads is down

In c0fd5e0, 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 21f0dbb.


text:
🛑 Sensor Tracker login is down

In 5761364, 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 5b74894.


text:
🛑 CEOTR Home Page loads is down

In 0fabecb, 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 bf7320e.


text:
🛑 Sensor Tracker login is down

In 21d497a, 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 6da76a1 after .


text:
🛑 Sensor Tracker login is down

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

HTTP code: 502
Response time: 47 ms

Resolved: Sensor tracker login is back up in 06b9548 after 38 days, 0 hours, 39 minutes.


text:
🛑 RMUG Installations is down

In 96ce962, RMUG Installations (https://installations.rmusergroup.net) was down:

HTTP code: 502
Response time: 384 ms

Resolved: RMUG Installations is back up in 28f9db5 after 7 minutes.

repo: RM-User-Group/RMUG-Upptime


text:
Add option to modify line spacing and character spacing.

This is a feature request. I personally like to use Fira Code on Windows 10 x64. And I'm really enjoying using Nvy as my daily driver now, but the character height in Fira Code (in general) is not very high. I was hoping Nvy would have the option to add custom line spacing and character spacing, for improved clarity.

You can now modify the line spacing with --linespace-factor=<FLOAT> e.g. --linespace-factor=1.2 to multiply the line spacing by 1.2. Modifying the character spacing is a bit more tricky and I would rather not support that at this moment.

repo: RMichelsen/Nvy


text:
How can we obtain force values

Hi,
How can we obtain force values relating to the arm joints of robotis-op3?
Is it possible?  We see lines relating to force in manager.
Do you have  lines of code to measure force.
Thanks

Hi,
There is no way to obtain the force value in ROBOTIS-OP3.
There is no way to help. sorry.
Regards,
Kayman

This issue will be closed as there isn't any recent activity. Please feel free to reopen when necessary.

authors: ROBOTIS-Kayman ROBOTIS-Will xxchenchen


text:
EXSWHTEC-135 - Implement tests for hipGraphicsGLRegisterBuffer

Basic positive test
Positive test case for multiple registrations of same resource
Negative parameter tests.

Depends-on: #62

@mirza-halilcevic
Will you please resolve the merge conflicts for this PR?

PR has been merged into develop branch via commit 0fbfa9cde1a6cc3f3bb0e5d27f0ca224378a421d

authors: mangupta mirza-halilcevic rorake

repo: ROCm/hip-tests


text:
[gfx90a][FP16] Disable Solvers that unable to comply the "ALT FP16" attribute

Simplify access to ALT attribute from ProblemDescription
ConvBinWinogradRxSf2x3, ConvBinWinogradRxSf2x3g1
ConvBinWinogradRxSf3x2
ConvAsm1x1U, ConvAsm1x1UV2
ConvAsmBwdWrW1x1, ConvAsmBwdWrW3x3
ConvHipImplicitGemmBwdDataV1R1, ConvHipImplicitGemmBwdDataV1R1Xdlops
ConvHipImplicitGemmBwdDataV4R1Xdlops
ConvHipImplicitGemmForwardV4R4Xdlops, ConvHipImplicitGemmForwardV4R4Xdlops_Padded_Gemm
ConvHipImplicitGemmForwardV4R5Xdlops
ConvHipImplicitGemmV4R1Fwd, ConvHipImplicitGemmV4R1WrW
ConvHipImplicitGemmWrwV4R4Xdlops, ConvHipImplicitGemmWrwV4R4Xdlops_Padded_Gemm
Not necessary for:

ConvBinWinogradRxS due to this reasoning.
ConvHipImplicitGemmBwdDataV4R1, ConvHipImplicitGemmV4R4Fwd, ConvHipImplicitGemmV4R4WrW as these support only FP32.

:warning: @JehandadKhan From now on, many Bwd and WrW Solvers are disabled for gfx90a by default. Therefore, perf-db tuning will skip them. In order to tune perf-configs for them, MIOPEN_DEBUG_CONVOLUTION_ATTRIB_FP16_ALT_IMPL=0 can be set in the environment. This is just FYI. I do not think that tuning of disabled Solvers is really required.

Ready for review!

This solver should also been disabled
ConvCkIgemmFwdV6r1DlopsNchw
list:ConvCkIgemmFwdV6r1DlopsNchwhttps://github.com/ROCmSoftwarePlatform/MIOpen/blob/037e006c19be0d810c5cf1ced53b02e10d99702d/src/solver/conv_ck_igemm_fwd_v6r1_dlops_nchw.cpp#L82

authors: asroy atamazov

repo: ROCmSoftwarePlatform/MIOpen


text:
Fix kernel hit miss

fixes #616

CI tests passed, ready to go.

@ZPEthanWen
:tada: Congratulations! Your first contribution to MIOpen is done! :tada:

authors: ZPEthanWen atamazov


text:
Update COV code

Add options to select V4 and V5. Minor changes in headers to match spec. Remove support for V2. Set new default to V4 to match current default in assembler.

Thanks for your comments.
I do not have further comments.
I would like to wait for comments from other reviewers.

Conflicts are from merging in #1605. Take care not to squash those changes when fixing the conflics.

When merging I just used the versions from your commit, since it looks like they removed any specific CodeObjectVersion form the yaml and default is the desired behavior.

It looks like precheckin build failed with the following error message.
Tensile::FATAL: Unknown CodeObjectVersion V3

It looks like precheckin build failed with the following error message. Tensile::FATAL: Unknown CodeObjectVersion V3

Caused by new test files that were added in latest merge. They've been updated now.

authors: AlexBrownAMD nakajee

repo: ROCmSoftwarePlatform/Tensile


text:
Add new options to hipblaslt-bench

Add options algo_method and requested_solution.
The option algo_method is to choose which searching API.
0-	getHeuristic
1-	getAllAlgos
2-	getSolutionByIndex
Currently 2 does not allow the user to choose their own index but only use the API to call the first runnable kernel for any input problem.
The option api_method is to choose which APIs to call,
0-	The cublaslt style API
1-	The cublaslt style matrix declaration + C++ style API
2-	Pure C++ style API
requested_solution is only valid when algo_method is set to 0.
Example command to run getAllAlgos with C++ style API with default size,
./clients/staging/hipblaslt-bench --api_method 2 --algo_method 1

hit errors on gfx90a:
./clients/staging/hipblaslt-bench --requested_solution 2
corrupted size vs. prev_size
Aborted (core dumped)

authors: KKyang jichangjichang

repo: ROCmSoftwarePlatform/hipBLASLt


text:
Add sccache support for hip clang compiler

Signed-off-by: Jagadish Krishnamoorthy jagdish.krishna@gmail.com

Initial changes. LGTM

authors: jaglinux pruthvistony

repo: ROCmSoftwarePlatform/sccache


text:
Raspberry Pi Zero W support

I tested today the library with the new Raspberry Pi Zero W and I get this error:

Traceback (most recent call last):
File "/usr/local/lib/python3.4/dist-packages/gpiozero/pins/data.py", line 654, in pi_info
) = PI_REVISIONS[revision]
KeyError: 9437377

Thanks - this is a known issue. See this comment.
I intend to merge this PR and do a new release as soon as possible.
For now, the easiest way to get it working is:
git clone https://github.com/RPi-Distro/python-gpiozero
cd python-gpiozero
git checkout -b support_extra_models origin/support_extra_models
sudo python setup.py install
sudo python3 setup.py install

Then try again and it should work. Please let us know either way!

See #531 - we're hoping to get a new version released soon :-)

@lurch do my instructions look correct to you?

I think git checkout -b support_extra_models origin/support_extra_models can be reduced to just git checkout support_extra_models (the tracking-branch gets created automatically by git).
And I've never actually tested python setup.py install myself!
@driesdepoorter If you're not desparate, it might be easiest to just wait until the apt-get package gets updated, rather than having multiple versions of GpioZero installed.

Thank you for the quick fix @bennuttall

Maybe the code should be "fail-safe" and not crash if the Pi is not
detected or if the Pi revision is not detected.
Some sane default (on what pin are available) could be used in that case.
I mean, every new hardware release the problem seems to be the same.
Doing the change in advance would be a spoiler the foundation might not
want...
Doing it after might be difficult depending on Debian schedule and other.
Regards
2017-03-02 18:37 GMT+01:00 Dries Depoorter notifications@github.com:

Thank you for the quick fix @bennuttall https://github.com/bennuttall
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/RPi-Distro/python-gpiozero/issues/541#issuecomment-283723470,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ASiRnBED-_7jvSoJzla1Gz0Cofymj4PWks5rhv5VgaJpZM4MRKoW
.

@dglaude see #530 ;-)

A fix has been released. You'll find it on PyPI, and it'll make its way into Raspbian shortly.
To update now:
sudo pip install gpiozero
sudo pip3 install gpiozero

But note, if you later update with apt your pip version will take precedence.

Updated previous comment

authors: bennuttall dglaude driesdepoorter lurch

repo: RPi-Distro/python-gpiozero


text:
adding posts and example archive

As discussed in https://github.com/RSE-leaders/SORSE20/issues/15#issuecomment-642940625, this PR adds a simple setup to have posts (with categories), and we render them at the bottom of the home page as announcements:

(I suspect this would be moved up somewhere else or put on a sidebar, I'm just plopping it there to show how the syntax looks). And then each post is a dummy page for now:

And then I added an archive page to show posts by year, this could also be filtered by category (but doesn't have to be). This isn't currently linked from anywhere.

@Chilipp since you have vision for how you want the final thing to be, please take this and edit however you please! Details that need attention are:

where to put the link to post archive (and how to customize rendering the listing, e.g., adding categories, or even rendering different pages or sections for different categories)
how to format the url for posts (if we add a category to the frontend matter of the posts and use that instead of the tag then we could much better represent this in the url.
where to render posts (filtered to some subset) on the front page.

I don't intend for this to be perfect, but a good start that you can work from to tweak to the needs of the site.
Signed-off-by: vsoch vsochat@stanford.edu

You're really fast @vsoch :satisfied: I'll need to think about it as it's already pretty late over here :wink: thanks a lot!

Yeah sounds good!

how to format the url for posts (if we add a category to the frontend matter of the posts and use that instead of the tag then we could much better represent this in the url.

Yes, I think using categories is the way to go here. Maybe Announcements also does not sound very nice. Shall we use News instead and use this as the corresponding category?

where to render posts (filtered to some subset) on the front page

this depends what we will have on the front page. If we go for what I proposed in https://github.com/RSE-leaders/SORSE20/issues/15#issuecomment-641529419 and only have a short welcome text, I'd put the posts and events below this text.

Yes, actually I think this can be merged, right @vsoch? Then I update #64

authors: Chilipp vsoch


text:
RumbleBridge - new selector needed on user/channel page

$dom->find('li.video-listing-entry') wasn't working for me when I tried it. (I'm a new user, today.)
Changed it to $dom->find('ol.thumbnail__grid div.thumbnail__grid--item') and that seems to do the trick.

nice nice. thanks for taking the time to fix

authors: bkidwell dvikan

repo: RSS-Bridge/rss-bridge

license: unlicense


text:
Fix PHP 7.3 deprecation warnings

Fix PHP 7.3 deprecation warnings. Those flags are implied by FILTER_VALIDATE_URL.

Thanks for the PR :+1:
It took me a while to figure out that those flags actually have no meaning whatsoever, even in PHP 5.6 (which is currently the primary version for this project). To my surprise it has been in the code sind PHP 5.2.1. Not sure why they didn't explain that in the official documentation :confused:
The bug report on the PHP bug tracker explains everything:
https://bugs.php.net/bug.php?id=75442
Anyway, you are absolutely right to remove them. There are, however, other places in the code where those flags are used. Those should be removed as well. Could you do that in this PR to keep it simple?

Done, that's all of them I think?

authors: LogMANOriginal triatic


text:
undefined on ASP core via API Explorer

Hi,
We get undefined in swagger.json when using  ASP core via API Explorer but when switching back to reflection(deprecated) everything is fine.

Thanks
Payam

What is undefined?

I think HTTP methods like GET, POST

Ah yes, strange. Can you provide a sample?

It wasn't the case.
we figured out when you don't use [HttpGet] then the application doesn't consider it as default and convert it to undefined.

But asp.net core handles it as GET?

Yes
On Thu, Nov 29, 2018 at 2:51 PM Rico Suter notifications@github.com wrote:

But asp.net core handles it as GET?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/RSuter/NSwag/issues/1779#issuecomment-442798701, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEM1FPUciW4socx0ttLrwV3CNrDRfPbHks5uz8NFgaJpZM4Y3BtB
.

--
Sent from iPhone

@dougbu is this a "bug" in api explorer or just not supported? i.e. if no Http*Attribute is available then "undefined" is reported instead of GET which is actually used...

"undefined" is reported instead of GET which is actually used…

Undefined is correct in this case. It means any HTTP action is fine, not just GET. If NSwag doesn't handle this case, that's a bug in this repo.

I think swagger cannot handle that, or we define all possible http methods which seems a little bit overkill

authors: RSuter dougbu khaninejad

repo: RSuter/NSwag


text:
[update] Update nuclei-sdk package version

Nuclei SDK version updated from 0.2.3 -> 0.3.0

新的修改已经提交。

repo: RT-Thread/packages


text:
Un support null element for array

Test case is follow:
@Test
public void testNullElementArray () {
        // given
        Schema arrayRecordSchema = Schema.createArray(Schema.createUnion(Schema.create(Schema.Type.STRING)
                , Schema.create(Schema.Type.NULL)));

        List<Object> records = new ArrayList<Object>();
        records.add(null);
        records.add(null);
        records.add(null);

        // when
        List<Object> array = decodeRecord(arrayRecordSchema, arrayRecordSchema,
                specificDataAsDecoder(records, arrayRecordSchema));

        // then
        Assert.assertEquals(3, array.size());
        Assert.assertNull(array.get(0));
        Assert.assertNull(array.get(1));
        Assert.assertNull(array.get(2));
    }

Hi,
thank you for pointing that out - we indeed had a small bug in handling null array elements. Fix is already on its way.

Hi,
Release 1.0.4 which fixes this bug is already available.

thanks

authors: dervan flowenol gcvirus

repo: RTBHOUSE/avro-fastserde


text:
问:预训练的SoVITS-G模型路径 和 预训练的SoVITS-D模型路径  的区别?

预训练的SoVITS-G模型路径 GPT_SoVITS/pretrained_models/s2G488k.pth
预训练的SoVITS-D模型路径 GPT_SoVITS/pretrained_models/s2D488k.pth
这两个模型有什么区别

VITS 中有生成器 Generator 即 net_g 和判别器 Discriminator 即 net_d, 这两个部分以对抗的方式进行训练.
更多细节可以搜索生成对抗网络 GAN 和 VITS.

authors: SapphireLab litongjava

repo: RVC-Boss/GPT-SoVITS


text:
Converted audio file using a custom trained model includes a lot of noise

I've trained a couple of models, one with V1 40KHz setting and the other with V2 48KHz setting. But when I use those models to convert a vocals file, the converted vocals file has a lot noise which sounds like distortion and sawtooth wave. What can I change in my training settings that can help me successfully train a model which converts the audio files without adding any noise?
Thanks in advance!

Check the clip for other sounds and try to remove them

Which clip are you talking about? The vocals tracks that I used for training the model don't have any noise.


text:
go-realtime-gui is crashing when i press "start conversation"

i add my model but i don't change the logs
i change the mic and headphone and press start and it crash

just the gui stop working
and i don't kn why

ok i fixed it by changing my output by (windows directsound) to (MME)

How did you choose the MME output? I use Voicemeeter, but there is no MME in the RVC output options

为什么我改了还是无响应


text:
how to combine voices ?

i was told one could merge multiple voices into one and create a original new voice .
No idea how to pull that off though .

you can try to use the ckpt processing tab in gradio webui

Very simplified Explanation:
Step 1:Train Model A and Model B
Step 2:Go to "ckpt Processing"
Step 3:Insert Full Path in "Path to Model A:", same for B (ex. "G:\RVC-Webui\weights\keanu_en.pth" Model A, "G:\RVC-Webui\weights\franksinatra_en.pth" Model B)
Step 4: Choose how much of Model A you want to Dominate in the generated Model (Weight (w) for Model A) 0.5 means 50% of the Voice, and if you just want to mix 2 Voices, is generally good enough to leave as it is.
You can still try out other combinations latter.
Step 5: Don´t forget to give the new Model a Name, and set it to the same Version as the Models you trained before (so if both were v2, then this Model is v2 as well), mixing different Versions didn´t work for me, so either stick with v1+v1 or v2+v2.
Step 6: Test the new Model on the Inference Tab!

authors: KabetzuriBoii TripleKiller666 Yurzi


text:
Unable to read from io.StringIO

$ python
Python 3.8.5 (default, Jul 28 2020, 12:59:40)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import io
>>> buf = io.StringIO('hello world')
>>> buf.seek(0)
0
>>> import smart_open
>>> smart_open.open(buf).read()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.8/codecs.py", line 500, in read
    data = self.bytebuffer + newdata
TypeError: can't concat str to bytes

version 4.0.1

I briefly looked into this because one of the tests dealing with it failed.
If you want to support this I think the only way is to explicitly check for StringIO and return it unmodified from open(). Also raise an error if mode='b' or if newline is specified because those can't be supported. encoding and errors can be ignored because no encoding actually takes place with StringIO.

I briefly looked into this because one of the tests dealing with it failed.
If you want to support this I think the only way is to explicitly check for StringIO and return it unmodified from open(). Also raise an error if mode='b' or if newline is specified because those can't be supported. encoding and errors can be ignored because no encoding actually takes place with StringIO.

I don't like the idea of an explicit check. It's too narrow.
How about a fin.peek(0) to see what's in the actual stream? If it's text, we can't do anything other than return it as is.

I don't like the idea of an explicit check. It's too narrow.
How about a fin.peek(0) to see what's in the actual stream? If it's text, we can't do anything other than return it as is.

I don't think StringIO has a peek method. Even if it did, other's would rarely implement it. You would have to do a read followed by rewinding with seek which limits you to random access files.
In general I'm not sure accepting file objects even makes sense. Why would you call smart_open or even the built in open if you already have a file object? I can see the point of having StringIO/BytesIO work for being able to mock something in memory but beyond that I'm not convinced.
Supporting StringIO also breaks the concept of smart_open always treating the underlying file as a byte stream which complicates things and may set you up for quite a bit of maintenance pain in the future.

I don't think StringIO has a peek method. Even if it did, other's would rarely implement it. You would have to do a read followed by rewinding with seek which limits you to random access files.
In general I'm not sure accepting file objects even makes sense. Why would you call smart_open or even the built in open if you already have a file object? I can see the point of having StringIO/BytesIO work for being able to mock something in memory but beyond that I'm not convinced.
Supporting StringIO also breaks the concept of smart_open always treating the underlying file as a byte stream which complicates things and may set you up for quite a bit of maintenance pain in the future.

@markopy You make valid points.

In general I'm not sure accepting file objects even makes sense. Why would you call smart_open or even the built in open if you already have a file object?

@piskvorky WDYT? What was the motivation of allowing smart_open to accept a file object as input? It breaks symmetry with the built-in function.
>>> open(open('setup.py'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: expected str, bytes or os.PathLike object, not _io.TextIOWrapper
>>>

Perhaps we should do exactly as the built-in option, and accept the above three classes as inputs exclusively?

@markopy You make valid points.

In general I'm not sure accepting file objects even makes sense. Why would you call smart_open or even the built in open if you already have a file object?

@piskvorky WDYT? What was the motivation of allowing smart_open to accept a file object as input? It breaks symmetry with the built-in function.
>>> open(open('setup.py'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: expected str, bytes or os.PathLike object, not _io.TextIOWrapper
>>>

Perhaps we should do exactly as the built-in option, and accept the above three classes as inputs exclusively?

I'm not sure, would have to dig through the history. I like @markopy 's argument, makes sense to keep smart_open's mission clean and contained.

I'm not sure, would have to dig through the history. I like @markopy 's argument, makes sense to keep smart_open's mission clean and contained.

Just one thing to add: For complete consistency with built in open you also need to accept integer file descriptors as pointed out in #528.

Just one thing to add: For complete consistency with built in open you also need to accept integer file descriptors as pointed out in #528.

I found this: https://github.com/RaRe-Technologies/smart_open/pull/32. @gojomo what was your motivation there, do you remember?

I found this: https://github.com/RaRe-Technologies/smart_open/pull/32. @gojomo what was your motivation there, do you remember?

I can't recall the motivation. I vaguely think some bit of example code or downstream code in Gensim may have needed this behavior, and at the time I may have thought that even Python's open() worked this same way. There might have been a request via another issue or forum.
Given my minimal comment & your rapid review & integration, we'd probably talked about it somewhere else, but I'm not sure where.
If we try removing the passthrough case & running all smart_open & gensim tests, maybe we'll find something that breaks?

I can't recall the motivation. I vaguely think some bit of example code or downstream code in Gensim may have needed this behavior, and at the time I may have thought that even Python's open() worked this same way. There might have been a request via another issue or forum.
Given my minimal comment & your rapid review & integration, we'd probably talked about it somewhere else, but I'm not sure where.
If we try removing the passthrough case & running all smart_open & gensim tests, maybe we'll find something that breaks?

Are you interested in investigating this further @markopy ?

Are you interested in investigating this further @markopy ?

The change from #32 now resides in _open_binary_stream  so it implicitly assumes the file is opened in binary mode. In that context failing for StringIO or anything else that returns something other than bytes on read makes sense.
There are a whole bunch of tests explicitly for SmartOpenFileObjTest as well as some using BytesIO to test other things. There is also a test for this use case:
        Does our detection of the `name` attribute work with wrapped open()-ed streams?

        We `open()` a file with ".bz2" extension, pass the file object to `smart_open()` and check that
        we read decompressed data. This behavior is driven by detecting the `name` attribute in
        `_open_binary_stream()`.

I find support for this somewhat questionable but I don't have time to investigate why this might exist and whether to remove it again makes sense.
The easiest thing to do is to keep the current support for handling binary file objects but not extend it to text streams like StringIO.

The change from #32 now resides in _open_binary_stream  so it implicitly assumes the file is opened in binary mode. In that context failing for StringIO or anything else that returns something other than bytes on read makes sense.
There are a whole bunch of tests explicitly for SmartOpenFileObjTest as well as some using BytesIO to test other things. There is also a test for this use case:
        Does our detection of the `name` attribute work with wrapped open()-ed streams?

        We `open()` a file with ".bz2" extension, pass the file object to `smart_open()` and check that
        we read decompressed data. This behavior is driven by detecting the `name` attribute in
        `_open_binary_stream()`.

I find support for this somewhat questionable but I don't have time to investigate why this might exist and whether to remove it again makes sense.
The easiest thing to do is to keep the current support for handling binary file objects but not extend it to text streams like StringIO.

@piskvorky Removing support for open-ing a buffer (as opposed to a string) seems to have no effect on gensim tests.
What do you think about removing this functionality?

@piskvorky Removing support for open-ing a buffer (as opposed to a string) seems to have no effect on gensim tests.
What do you think about removing this functionality?

I have no chips on the table – if gensim (and i guess gensim-data) continue to work, let's axe it.

I have no chips on the table – if gensim (and i guess gensim-data) continue to work, let's axe it.

Yes, I think it does, even though it doesn't seem like people use this particular feature much.

Yes, I think it does, even though it doesn't seem like people use this particular feature much.

authors: gojomo markopy mpenkov piskvorky


text:
Log node discovery task failure

Log the entire workflow task data on a node discovery task failure.
ACK message if graph and route ID's match.

@RackHD/corecommitters @changev @panpan0000

:+1:

authors: anhou jlongever

repo: RackHD/RackHD


text:
Make Writer public again.

Because this library is harder to use when the returned value by the
main functions is protected.
For example, you cannot do something as simple as this:
  var writer *srslog.Writer
  var err error

  if secureConnection {
    writer, err = srslog.DialWithTLSCertPath(...)
  } else {
    writer, err = srslog.Dial(...)
  }

I've also added godoc to both TLS functions.
Signed-off-by: David Calavera david.calavera@gmail.com

Thanks!

authors: calavera lvh

repo: RackSec/srslog