Getting very less accuracy for Image

class` FashionMNIStModelV0(nn.Module):
  def __init__(self,input_features,hidden_units,output_features):
    super().__init__()
    self.layer_stack=nn.Sequential(
        nn.Flatten(),
        nn.Linear(in_features=input_features,out_features=hidden_units),
        nn.Linear(in_features=hidden_units,out_features=output_features)
    )

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

model_0=FashionMNIStModelV0(input_features=784,hidden_units=10,output_features=len(class_names)).to("cpu")

My Training Model

'''
from tqdm.auto import tqdm

torch.manual_seed(42)
train_time_start_on_cpu = timer()

#set the number of pochs (we'll keep this small for faster raining time)
epochs=3

#create trining and test loop
for epoch in range(epochs):
  print(f"Epoch:{epoch}\n------")

  #trianing
  train_loss = 0

  #Add a loop tp loop through the training batches
  for batch,(X,y) in enumerate(train_dataloader):
    model_0.train()

    #Forward pass
    y_pred = model_0(X)

    loss = loss_fn(y_pred,y)

    train_loss+=loss

    optimizer.zero_grad()

    loss.backward()

    optimizer.step()

    #Print the data
    if batch %400 ==0 :
      print(f"Looked at {batch *len(X)}/{len(train_dataloader.dataset)} samples.")

    #Divide the train loss
  train_loss /= len(train_dataloader)
    #testing
  test_loss,test_acc=0,0
  model_0.eval()

  with torch.inference_mode():
    for X_test,y_test in test_dataloader:
      y_test_pred = model_0(X_test)

      test_loss = loss_fn(y_test_pred,y_test)

      test_loss+=test_loss

      test_acc= accuracy_fn(y_true=y_test,y_pred=y_test_pred.argmax(dim=1))

    #calaulte the test loss average per batch
    test_loss/=len(test_dataloader)

    test_acc/=len(test_dataloader)

  #Print out what happens
  print(f"\n Train loss:{train_loss:.4f} | Test Loss:{test_loss:.4f} | Test acc :{test_acc:.4f}")

  #calulate trining time
  train_time_end_on_cpu = timer()
  total_train_time_model_0 = print_train_time(start=train_time_start_on_cpu,
                                              end=train_time_end_on_cpu,
                                              device=str(next(model_0.parameters()).device)
  )
  print(f"Total time : {total_train_time_model_0}")

'''

Output

"""

Epoch:0
------
Looked at 0/60000 samples.
Looked at 12800/60000 samples.
Looked at 25600/60000 samples.
Looked at 38400/60000 samples.
Looked at 51200/60000 samples.

 Train loss:0.4307 | Test Loss:0.0042 | Test acc :0.2596
Train time on cpu: 13.978 seconds
Total time : 13.977587818999382
Epoch:1
------
Looked at 0/60000 samples.
Looked at 12800/60000 samples.
Looked at 25600/60000 samples.
Looked at 38400/60000 samples.
Looked at 51200/60000 samples.

 Train loss:0.4246 | Test Loss:0.0041 | Test acc :0.2596
Train time on cpu: 26.074 seconds
Total time : 26.073535761999665
Epoch:2
------
Looked at 0/60000 samples.
Looked at 12800/60000 samples.
Looked at 25600/60000 samples.
Looked at 38400/60000 samples.
Looked at 51200/60000 samples.

 Train loss:0.4218 | Test Loss:0.0042 | Test acc :0.2396
Train time on cpu: 38.908 seconds
Total time : 38.908417628999814

`

Can some check and let me know
`

with torch.inference_mode():
    for batch,(X_test,y_test) in enumerate(test_dataloader):
      y_test_pred = model_0(X_test)

      test_loss = loss_fn(y_test_pred,y_test)

      test_loss+=test_loss

      test_acc= accuracy_fn(y_true=y_test,y_pred=y_test_pred.argmax(dim=1))

      if batch% 10 ==0:
        print(f"batch : {batch} | test_acc :{test_acc:.3f}")

getting a good accuracy
batch : 0 | test_acc :81.250
batch : 10 | test_acc :81.250
batch : 20 | test_acc :81.250
batch : 30 | test_acc :87.500
batch : 40 | test_acc :93.750
batch : 50 | test_acc :93.750
batch : 60 | test_acc :81.250
batch : 70 | test_acc :81.250
batch : 80 | test_acc :75.000
batch : 90 | test_acc :78.125
batch : 100 | test_acc :68.750
batch : 110 | test_acc :84.375
batch : 120 | test_acc :87.500
batch : 130 | test_acc :75.000
batch : 140 | test_acc :65.625
batch : 150 | test_acc :75.000
batch : 160 | test_acc :84.375
batch : 170 | test_acc :75.000
batch : 180 | test_acc :81.250
batch : 190 | test_acc :84.375
batch : 200 | test_acc :90.625
batch : 210 | test_acc :84.375
batch : 220 | test_acc :90.625
batch : 230 | test_acc :87.500
batch : 240 | test_acc :93.750
batch : 250 | test_acc :87.500
batch : 260 | test_acc :78.125
batch : 270 | test_acc :81.250
batch : 280 | test_acc :75.000
batch : 290 | test_acc :78.125
batch : 300 | test_acc :87.500
batch : 310 | test_acc :90.625

my data loader
## BATCHSIZE
from torch.utils.data import DataLoader
BATCHSIZE=32

train_dataloader = DataLoader(dataset=train_data,
                              batch_size=BATCHSIZE,
                              shuffle=True)

test_dataloader = DataLoader(dataset=test_data,
                             batch_size=BATCHSIZE,
                             shuffle=True)

train_dataloader , test_dataloader

Hi @kumarsiddappa-git, I had the same problem and modified the learning rate to a smaller number like 0.005. The accuracy looked better than lr=0.1. I hope this also works for you.


[BUG] Vendor-specific fields not fully tested in SDK

Reproduction steps
Test cluster (0xFFF1FC05) (src/app/zap-templates/zcl/data-model/chip/test-cluster.xml) does not seem to have cases where we have vendor-specific fields in attribute structs, event structs, or command argument structs. These are needed to test MEI functionality in the SDK.
E.g. NestedStruct tests that SimpleStruct can be nested within it, but doesn't test that:

Another vendor (e.g. 0xFFF2) can add a field to NestedStruct
Another vendor (e.g. 0xFFF2 or 0xFFF3) can add a field to SimpleStruct, which is nested within NestedStruct

Bug prevalence
Always
GitHub hash of the SDK that was being used
Latest (and presumably all)
Platform
core
Platform Version(s)
No response
Anything else?
No response

None of that is supported right now, basically.  Which is why the spec has:

Support for encoding Field IDs with an MC source is provisional.

Because the SDK does not actually let you do that.

Because the SDK does not actually let you do that.

With direct TLV access:
void ReadClient::Callback::OnAttributeData(const ConcreteDataAttributePath & aPath, TLV::TLVReader * apData, const StatusIB & aStatus) {}

and also with AttributeAccessInterface, it is possible for a client to see these fields as per spec.

That's true.  You just can't do it via the codegen helpers.


Keyvault latest version 1.1.0 does not support secrets.

Link to sample
No response
Library name and version
Azure.ResourceManager.Keyvault
Language of the Sample

[X] C#/.NET
[ ] Java
[ ] JavaScript/TypedScript
[ ] Python
[ ] Golang
[ ] Other - Please specify in Issue details field

Sample Issue Type

[X] Sample not working
[X] Sample missing
[ ] Do not understand sample

Issue details
We are migrating from Microsoft.Azure.Management.KeyVault SDK to the new Azure.ResourceManager.KeyVault SDK (latest 1.1.0)

We noticed that the latest version did not contain Secret resource or any capability to support secrets. No example found for the same.
We downgraded the version to 1.0.0.-beta8. Even though it supports SecretResource, we are unable to fetch any secrets in the code. The value remains null.

Please provide examples or guidance to fetch Secret resource.
Expected behavior
No response
Actual behavior
No response
Reproduction Steps
No response
Environment
development

@ArcturusZhang @ArthurMa1978 can you help check?

We removed the preview API when we released the stable version, now that we have a stable version of the KeyVault secrets, we will bump the API version and add this feature back in the next Azure.ResourceManager.KeyVault version

Thank you for responding. The stable version does not support keyvault secrets, could you help us understand if there's something we are missing.

The stable version does not support keyvault secrets

Yes, our current Azure.ResourceManager.KeyVaultsdk 1.1.0 version does not support Secrets operations, but we will release a new version to support that this month(March 2023)


run the trt_yolov3.py  error

helmet.txt

env
os:ubuntu 18.04
python: 3.6.9

change the class num in yolo.py
category_num=5

change the class name dict in yolov3_class.py

convert the weights to onnx file (success)

convert the onnx to trt file (success)

execute commad
python3_ trt_yolov3.py --model yolov3-416 --rtsp --uri rtsp://admin:abcd1234@<IP_ADDRESS>:554/h264/ch1/main/av_stream
the error message :
trt_outputs = [output.reshape(shape) for output, shape
ValueError: cannot reshape array of size 5070 into shape (1,255,13,13)

cfg file:
helmet.txt
weights file:
链接：https://pan.baidu.com/s/1LQVdKnSkQQtLsUbJgDPi3w
提取码：u39i
i had try many ways  ,but i still can't resolve the error,pls give me some advice.thk you .

"trt_yolov3.py" is a rather old version of the code.  It has been replaced by "trt_yolo.py" now.
Please git pull the latest code from the repo and follow the steps in README.md to convert your model.

I had git pull the latest code ,and flollow the steps in README.md, when I  try to excute   "python onnx_to_tensorrt.py -m helmet",
the error message output :

how to solove  this? thk you.

the error message:
message.txt

My code assumes the conv features maps before yolo layers are:
https://github.com/jkjung-avt/tensorrt_demos/blob/0276e9b3a7e7f69cdb5fa668f27dd3719c2aa68a/yolo/plugins.py#L90
But your custom model is using "// 4" instead of "// 8".  As a quick fix, you could patch the above line of code with the following:
    yolo_whs = [[w // 32, h // 32], [w // 16, h // 16], [w // 4, h // 4]]

Thk you! It works.

The FPS is amazing!

I tried to use the trt file on  camera  detection, But  i faced a new problem,

I tried to modify  the conf_th and nms_threshold in yolo_with_plugins.py , But it did not work，Why this happens？

This happens when your TensorRT inference runs too fast (inference and draw detection boxes on the same image multiple times).
You could use the "--copy_frame" command-line option to get around that.  (FPS would be slightly lower since the image needs to be copied before each inference.)

i had use the  "--copy_frame" option, And now I‘m trying  to detect 18  rtsp urls,  But  i get a problem.

Thk you! I tried to run the code , And not found the same problem.


initial docs commit

Closes #46.

@rwblair What's the status of this? Should we try to get this merged today for a 0.3.0 release, or push off for now?

@rwblair, they finally migrated sphinx-versioning to sphinx-contrib
See https://github.com/sphinx-contrib/sphinxcontrib-versioning/pull/46#issuecomment-386867658

I think moving on to upgrading fMRIPrep's dependencies is probably more important than squeezing this in now. Sorry for the short turnaround question at lunch time.

Outstanding work! Will review ASAP
On Tue, Aug 27, 2019, 12:45 Ross Blair<EMAIL_ADDRESS>wrote:

Ok I think this is ready. Documentation is being saved as an artifact so
we can review it there. Once this gets merged and a new version tagged, we
will need to blacklist this branch from sphinx-versioning so it doesn't
show up in the side menu.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/poldracklab/smriprep/pull/65?email_source=notifications&email_token=AAESDRTT3ZYRC5OWLNYCD5DQGV76RA5CNFSM4HBG2FWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5I4XCI#issuecomment-525454217,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAESDRWN74Z2X5J2QR6E4Z3QGV76RANCNFSM4HBG2FWA
.

@oesteban take another look at the docs, I removed the title and modules list for the packages as per your request.
If this looks ok we can merge it, and then I'll open a new PR removing the test tags and having sphinx-versioning using master as its reference point instead of the ci_doc_deploy branch.

Biggest error in the doc build is coming from /nipype/sphinxext/plot_workflow.py:

Traceback (most recent call last):
File "/home/rwblair/miniconda2/envs/smriprep/lib/python3.7/site-packages/nipype/sphinxext/plot_workflow.py", line 485, in run_code
exec(code, ns)
File "", line 3, in
ImportError: cannot import name 'BIDSLayout' from 'pybids' (unknown location)

Perhaps adding the autodocs_mock_imports could help (https://github.com/poldracklab/fmriprep/blob/6f3e63a44329dd9560b3e0d01779b821c406c900/docs/conf.py#L50-L54)
Also, we could remove the import from here:
https://github.com/poldracklab/smriprep/blob/268647be2167a59ad8cb9606b50c93910ec0468f/smriprep/workflows/base.py#L58
https://github.com/poldracklab/smriprep/blob/268647be2167a59ad8cb9606b50c93910ec0468f/smriprep/workflows/base.py#L196
and replace them with a namedtuple as in https://github.com/poldracklab/fmriprep/blob/master/fmriprep/workflows/base.py#L86

Sorry... Had to change the title for my sanity. Feel free to change it to something more accurate.

Tests look fixed. Any objections to merging @oesteban? Once this is merged I'll open up another PR that removes the doc_test_* tags and removes the ci_doc_deploy branch from being built via sphinxcontrib-versioning.

I'll have a last look later today :+1: . Thanks very much for figuring this out.

Looks like you need pybids ~= 0.9.4

READY????


Update overview.md

Testing

test PR

test PR

Docs Build status updates of commit cca66f8:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

msteams-platform/overview.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit cca66f8:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

msteams-platform/overview.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


Expired tokens removed before refresh can happen

Thanks for posting this example.
I believe the implementation is slightly broken.
Attempting to authenticate with an expired access token causes it to be removed from the server:
https://github.com/reneweb/oauth2orize_resource_owner_password_example/blob/430deec5554ff0c3eed9a001decea2339bd616d0/auth.js#L50
When a client then attempts to obtain a new access token using a refresh token, the original access token no longer exists for updating and thus authentication fails:
https://github.com/reneweb/oauth2orize_resource_owner_password_example/blob/430deec5554ff0c3eed9a001decea2339bd616d0/oauth.js#L51

Hey,
I realize that this issue is very old. I never got notified and just looked randomly at my old projects on github and saw the issue. Yeah, you are right this is indeed a problem and thanks for pointing it out.
I changed the code to not remove the access token when it is expired so the update will succeed (https://github.com/reneweb/oauth2orize_resource_owner_password_example/blob/master/auth.js#L50). It should also be possible to upsert the access token entry instead of doing an update.


[chore] Consolidate genai.request.seed

Fixes #
This is a follow up for https://github.com/open-telemetry/opentelemetry-python-contrib/pull/3081/files#r1884746832
/cc @lmolkova @lzchen
Changes
Please provide a brief description of the changes here.
Note: if the PR is touching an area that is not listed in the existing areas, or the area does not have sufficient domain experts coverage, the PR might be tagged as experts needed and move slowly until experts are identified.
Merge requirement checklist

[ ] CONTRIBUTING.md guidelines followed.
[ ] Change log entry added, according to the guidelines in When to add a changelog entry.

If your PR does not need a change log, start the PR title with [chore]

[ ] schema-next.yaml updated with changes to existing conventions.

@gyliu513 thanks for the contribution!
The markdown tables are auto-generated from yaml definitions - please check https://github.com/open-telemetry/semantic-conventions/blob/main/CONTRIBUTING.md#1-modify-the-yaml-model for more details.
Also, we don't remove attributes, we deprecate them - you can find some examples in the https://github.com/open-telemetry/semantic-conventions/blob/main/model/gen-ai/deprecated/registry-deprecated.yaml
We'll also need a changelog record for it - you can find more details on how to create one in https://github.com/open-telemetry/semantic-conventions/blob/main/CONTRIBUTING.md#4-changelog.

It seems @xrmx's PR got in faster #1710. Sorry about this, but thanks a lot @gyliu513 !


script to return nodes in the approved list which are not currently staked

On mainnet this gives,

$ flow scripts execute  ./transactions/idTableStaking/scripts/get_approved_but_not_staked_nodes.cdc -n mainnet
Result: ["1780288437c9aed5056836bfffcfe19334dd6e229607fccfb3fe9b1d4d24cdca", "237a7a04ecf88b7c21001589ecc277190a6f7cd6e56a296a203552ade6db0927", "5a4bff17941a73909472afe23f1ccdc59d7526f93b16b4e374bd8353f8b624b4", "94609410b05584616f628f98a26acec339f7e1ce43132f0d8d268540317023d8", "a67ca1afd47c58358c656dffa2e5585d80b01371866e5634b68dcbab090b9b6f", "da27c0fc2a4fe12c04bd70058252c5a26cfe41485bf6ea6aba1c724b7a07542d", "dc3054cae816874d7dbbe838a41ef97c8a01b44643bffc82afe3a8228eed29fd", "069d081eb931c30e73c8dfbbf6359198f48c9e650d3d25a7449267de811d4fca", "a1fd244595bcd4371f1abc38a60384b87b25a41e806ce970ec19ea6c651f365b", "dfe68dcea8dc6cd54b56899c8ebb1ae144edcd8f4527fe7572cf4125f4c5a7ac", "1059d479c9ce3d6fd9cc48fca99fc5135b59e7f944c3ab14aca56b054209bf20", "2c08e4113b88e3709e06de152b64127be20d1b2db7d6a5c018b85f131ae330b4", "8894e0d5092ad62c5498b71b4f0680f60ba3828ace7b3329a2aeb94f2a7242fb", "1fecd2813d2b931a7cc10efd5d0e53936e0dfb4e31d67750201c5e02dad0bdaf", "44b928d503a90afe50333314f8eac8dc2e3fa982bc49ba246e15bb6b0c494a31", "dd9fa94156de9a05d6f344eb83943418ad6436d25ee26695bd7610d4d90ebaa8", "864b8e7d8770a2342d02c251b0b5508d7795726605f9f6069237b5eb8eb1db29"]

getStakedNodeIDs first loads from /storage/idTableCurrentList, which is set to equal the approve list every epoch. Then it checks if all those nodes' stakes are above the minimum and removes them from the list if they aren't. So now, it will correctly not include non-access nodes on the approve list who aren't participating in the network. This script will currently not catch access who aren't participating but are approved though, because their minimum stake is zero so everything is sufficient for that.
During the upgrade, the list stored in /storage/idTableCurrentList is not changed, but getStakedNodeIDs() is changed, as is the way that we save nodes to that list. If a node has committed tokens that are moved to staked, they are added to the list, and if they have staked tokens that are moved to unstaking so that their staked total is below the minimum, they are removed from the list. We've also changed the meaning of it to mean participant node IDs, which means nodes that are actively participating in the network instead of actually staked because we are giving current access nodes some time to commit stake for their nodes before kicking them out.
So getStakedNodeIDs() will still return approved nodes from before the upgrade even if they aren't staked, because they are still "participants". Does that make sense? For non-access nodes, that hopefully shouldn't be a problem because we just removed all of them from the approved list who weren't staked, but still something to be aware of.
Maybe we can still merge this and then I'll make some changes to it in my branch to make it work the way you're actually intending after the upgrade

OK. yeah, then in that case this script, as it stands, will only be useful to identify extra non-access nodes.


Allow affixing tags with dashes in their name (e.g. Angular directives)

fixes #47

I think the best hope to implementing this is via #50 (if that gets merged this gets merged)

Closing this PR because it's been too long inactive. I no longer use AngularJS


mat-expansion-panel within mat-dialog-content: weird behavior

Reproduction
Use StackBlitz to reproduce your issue: https://stackblitz.com/edit/angular-yltxip
Steps to reproduce:

Open the dialog

Expected Behavior
I'm expecting the expansion-panel to be initialized as closed
Actual Behavior
When the modal dialog is opened, the expansion-panel seems opened and it's closing very fast
Environment

Angular: 8.2.4
CDK/Material: 8.1.4
Browser(s): Chrome
Operating System (e.g. Windows, macOS, Ubuntu): Windows

See https://github.com/angular/components/pull/13888 and https://github.com/angular/components/pull/14127.

Closing as duplicate of #13870


Incremental Parsing?

So one thing that comes up in real-world parsing, is parsing part of a string, up to the end of the next parsed thing.
In other words you might want something like this:
remaining_text = '01-23-45-67-89-AF whatever ...'

mac, remaining_text = parse_next(remaining_text, MAC)

assert mac == MAC('01-23-45-67-89-AF')
assert remaining text == 'whatever ...'

And of course you want some sort of sensible error behavior.
Notably, right now macaddress doesn't help you do this. It assumes you already have strings which are the right size to pass in to the class constructor or parse.
Of course, neither does ipaddress... is this a deficit on the part of ipaddress? Or should this kind of functionality be provided somehow by higher-level wrapper libraries?
Notably:

If an incremental parsing library can't share parsing logic, then it has to reimplement a lot of the same parsing logic.

If an incremental parsing library has to reuse ipaddress or macaddress as it is right now, then they must necessarily take on an inefficiency:
Imagine you have a string that you want to parse for the next "token" being either an EUI48 or OUI literal. (Maybe you're writing a mini language for working with networking settings, like for scripting a router or something.)
(Quick aside: when parsing stuff from the front of something longer, parses might want to do either a greedy match or conservative match: if you see the string 01-02-03-04-05-06, do you conservatively match just OUI('01-02-03') and leave -04... unconsumed, or do you greedily match the whole EUI48('01-02-03-04-05-06')? In this use-case I think it's obvious that you'd want to do the greedy match, but in some cases you might want the conservative one.)
So the point is, from an efficiency perspective, ideally the parsing consumes 01-02-03, and then decides based on the next character whether or not it is done (and has parsed an OUI instance) or needs to continue to try to parse a full EUI48 instance.
(There's another permutation: if the next character is -, then sometimes you want to consider the OUI possibility as eliminated, so that if the rest doesn't parse into a full EUI48, it's now an error, and other times you want to consider the OUI possibility still "live", so that if the greedy match fails, you treat it as if you just parsed an OUI instance and stopped there, so that the next step of the parser can read from right after the OUI.)
In all of these cases though, it kinda makes sense to me to parse all the possibilities incrementally - check each character against all parse possibilities - the way I do in macaddress._parse. And while the logic of macaddress._parse assumes a string containing one complete address, and only tries the formats which match the size, it's probably pretty close to what an incremental parser would want in that case.

So it seems like a shame that I've written some careful logic, which can parse canonical and custom formats into all these hardware address types represented as distinctly typed objects in memory, and yet if someone wanted to write parser which parses hardware addresses from the next characters in a string, they'd basically have to reimplement a lot of what I did, or use what I did at the cost of a lot of boilerplate and inefficiency.

Tentative verdict is to not bother supporting this, but to give it a big think.
Basically, I'd like to think up what a good implementation of this from outside this library looks like, especially one that still constructs instances of objects that this library provides.

For comparison, here's the current macaddress._parse:
def _parse(string, *classes):
    length = len(string)
    if length < 1:
        raise ValueError('hardware address cannot be an empty string')
    candidates = {}
    for cls in classes:
        for format_ in cls.formats:
            if len(format_) == length:
                candidates.setdefault(format_, cls)
    candidates = sorted(candidates.items())
    address = 0
    start = 0
    end = len(candidates)
    for index in range(length):
        character = string[index]
        if character in _HEX_DIGITS:
            address <<= 4
            address += int(character, 16)
            character = 'x'
        elif character == 'x':
            character = ''
        while start < end and candidates[start][0][index] < character:
            start += 1
        while start < end and candidates[end - 1][0][index] > character:
            end -= 1
        if start >= end:
            raise _value_error(string, 'cannot be parsed as', *classes)
    _, cls = candidates[start]
    offset = (4 - cls.size) & 3
    address >>= offset
    return address, cls

Notably, assuming characters is an iterator, we could replace:
    candidates = sorted(candidates.items())
    address = 0
    start = 0
    end = len(candidates)
    for index, character in enumerate(characters):

with
    length = max(map(len, candidates.keys()))
    candidates = sorted(candidates.items())
    address = 0
    start = 0
    end = len(candidates)
    for index in range(length):
        character = next(characters)

which is obviously more boilerplate but brings the code of the three partial/incremental parse functions closer in shape to the existing _parse.

Notably, once we make them the same like that, the preambles of each function basically produce two things; length, candidates.
In the case of fixed-length input, length is the length of the input and candidates is just formats with that length.
In the case of unknown-length input, length is the length of the longest format and candidates is all candidates.
These two things could be pulled into their own functions:
def _parse_entire_string_preamble(string, classes):
    length = len(string)
    candidates = {}
    for cls in classes:
        for format_ in cls.formats:
            if len(format_) == length:
                candidates.setdefault(format_, cls)
    return length, sorted(candidates.items())

def _parse_front_of_string_preamble(string, classes):
    candidates = {}
    for cls in classes:
        for format_ in cls.formats:
            candidates.setdefault(format_, cls)
    length = max(map(len, candidates.keys()))
    return length = sorted(candidates.items())

I think we can remove the if length < 1: raise ValueError(...) case from the pre-amble, because the from-front-of-string code needs to handle "we ran out of bytes" cases too, and so we could handle them both by catching StopIteration.

Could probably refactor all the parse-functions into a single generator which takes candidates, characters, and length, and then use little wrappers:

_parse would use the entire-string preamble, and feed string in as characters: there can only be one result or zero results, so we just use return next(iter(...)) on the generator.
parse_longest would loop getting each result and assigning it as the last result, catch the parsing error at the end, re-raise if there is no last result, or return the last result.
parse_longest_no_backtrack would be like parse_longest but without the try-catch.
parse_shortest would do return next(iter(...)) just like _parse.

The parse error would need to be tweaked (perhaps another reason against the over-helpful errors I've been doing, but in this case I should really give individual attention to what the best error messages in each case are).

Ultimately though, if I was writing a parser, I would actually want this same functionality in an even more general way....
Because what these parse_* functions are doing is basically taking iterables of pieces (it just so happens in this case that the pieces are characters) and multiple alternatives of what sequences of pieces parse to what (which just so happens in this case to be specified with more characters where x has special meaning), and then using that.
So basically this is starting to approximate a parser combinator of sorts.
And ultimately when you're parsing iteratively you want different kinds of errors: if you expected characters and suddenly characters ended, you want to convey that explicitly; if you expected characters and got wrong characters, you want to convey that differently; and so on.
It does seem like an ideal solution maybe looks more like a parser and/or parser combinator library, and some sort of glue which can take macaddress classes and turn them and their formats definitions into equivalent stuff that can be passed into said parser (combinator) library.

Verdict: dropping this idea until I one day have the time to either find a great parser library for Python which already exists, or to write my own (if so, one or more of these parse functions could probably be reused as a base for a function provided in that library).
Then this will be revisited to see how easy it is to glue that stuff together with macaddress classes.


fix tool icon url validation

Resolves #4597
Pull Request Checklist:

[x] Positive Test Case Written by Dev

[ ] Automated Testing

[ ] Sufficient User and Developer Documentation

[ ] Passing Jenkins Build

[ ] Peer Code review and approval

Positive Test Case

Create a new Web App Connector
Type a valid URL into the metadata field "App Home Page URL"
Click on the Save Changes button
You no longer receive error about 'data_url'

BEFORE:

METRIC
VALUE

https://sonarqube.cuahsi-workstation.com:9000/dashboard?id=hydroshare-4600


navigateTo calls made inside plugins are reverted in app:created hook

Environment

Node Version:     v20.15.0
Nuxt Version:     ^3.12.3
CLI Version:      3.12.0
Package Manager<EMAIL_ADDRESS>
The issue does not depend on OS
Reproduction

clone the repo https://github.com/nicky1038/nuxt-redirect-in-plugin-demo which contains the reproduction example
execute npm run dev
open dev tools console in your browser
go to localhost:3000

You will remain on the root page, even though there was a navigateTo call in plugin.
In console it is possible to observe that the navigation in plugin is successful, but in app:created hook nuxt returns user back to the initial page.
Describe the bug
navigateTo calls are useless if they are performed inside plugins.
The reason is that nuxt:router plugin remembers the initial URL and registers app:created hook that performs navigation to that URL after all plugins finished their work.
@danielroe explained that the purpose of the redirect made by nuxt is to trigger all middlewares because there can be plugins that dynamically add new middlewares.
The expected behavior of nuxt is to preserve the current url in app:created hook and not to navigate to the initial one.
Additional context
No response
Logs
No response

Since nuxt 3.12 it is possible to use a dirty hack to stop app from being redirected to another location,
It works correctly and without any errors only when ssr option is false. When ssr is true, there is an error Hydration completed but contains mismatches. after the redirect (which is still correct).
hooks: {
    // once is a helper utility to ignore all invocations other than the first one
    'app:created': once(() => {
        // this middleware runs only once and leaves user on the current route
        const revertRedirectMiddleware = defineNuxtRouteMiddleware((_, from) => {
            // remove is a helper utility that finds and removes element from array
            remove(globalMiddleware, revertRedirectMiddleware)
            return navigateTo(from)
        })

        // globalMiddleware is imported from '#build/middleware'.
        // The middleware is being prepended to the list so that it will be executed before any other.
        globalMiddleware.unshift(revertRedirectMiddleware)
    })
}


KAFKA-2797: Only run rat when in the .git repository since it require s the .gitignore to generate the list of files to ignore

@ewencp this doesn't quite work for me, check this out:
./gradlew build
To honour the JVM settings for this build a new JVM will be forked. Please consider using the daemon: https://docs.gradle.org/2.8/userguide/gradle_daemon.html.
Building project 'core' with Scala version 2.10.5
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:jar
:assemble
:rat FAILED

FAILURE: Build failed with an exception.

* What went wrong:
A problem was found with the configuration of task ':rat'.
> No value has been specified for property 'excludes'.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 11.607 secs

@fpj Sorry, I pushed an update when I found the same problem. Did you try the newest version?

@ewencp I took the RC artifact and applied your changes to test it. Running gradle works, but not ./gradlew build or ./gradlew test.
I only see one commit here: 79c6cac. How many commits should I be seeing in this PR?

@ewencp OK, I got it, it works for me now. +1, LGTM.


Is it possible to change the spaCy pipeline?

Hi @d99kris,
I really like your implementation.
I've implemented a project with it and was wondering if it is possible
to influence the pipeline of spaCy within this wrapper?
Best,
Benny

Hi @BennyDietrich - thanks!
Using spaCy pipeline is currently not supported by spacy-cpp.
Let me take a look and see if it can be supported by spacy-cpp. If it's a small effort I might take a stab at it, but I'll have to check some and get back.

Hi @d99kris,
thanks for considering adding this for me!
Since we are already in contact I thought I could ask you another thing about spacy-cpp.
I try to use spacy-cpp with multi-threading. It runs into segmentation faults the moment when two threads try to access tokens from two different doc objects at the same time.
I've tried different things to prevent this behavior. First I started, creating different NLP objects from which I created the different docs. Since this didn't help, I tried to create different spacy objects and generated different NLP- and Doc-objects still without success.
I'm not sure where the problem comes from. Could it be that I'm currently not taking care of the GIL?
I'm sure you have a lot to do so I don't wanna hold you up, just thought you maybe have encountered a similar problem your self.

Hi @BennyDietrich - regarding pipeline support it seems it would be non-trivial to add, so I'll have to consider it out of scope for spacy-cpp due to somewhat limited resources, and having too many open source projects. 🙂
As for multi-threaded usage, yes I think your suspicion is right. Generally python and threading requires many considerations. Having that said, I would expect creating/sharing one Spacy instance across threads, and acquiring a mutex whenever calling into any Spacy API's should be safe, but there will also not be much parallelism. Personally I have not tried doing any threading with python.
I will proceed to close this issue.


Add link to the Java driver in Contributing docs

Because we now officially support the Java driver too.

Codecov Report

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

@@           Coverage Diff           @@
##           master    #2478   +/-   ##
=======================================
  Coverage   90.14%   90.14%
=======================================
  Files          41       41
  Lines        2365     2365
=======================================
  Hits         2132     2132
  Misses        233      233


Annotation data discrepancy in python client and csv dump

Similar to  #2649. There is a difference in the classification data presented in the python client and in the classification dump, specifically in the value of a question task in the annotation data. The csv dump gives the text that was presented as an option in the question: [{"task":"T0",...,"value":"All Muons"}]. The python client on the other hand presents integer, which I assume is the index of the option in the question, but honestly I'm not sure. [{'task': 'T0', 'value': 0}]
I personally don't have a specific need or preference for which version is delivered, although consistency across the different methods of accessing classification data in Panoptes would be much appreciated. I'm not arguing that data from the api should be exactly the same as the data in the csv dump, but in this example I can't go from the api to the csv dump without maintaining my own external mapping of the expected answer text and their indices in Panoptes.
{'id': '88474114', 'annotations': [{'task': 'T0', 'value': 0}], 'created_at': '2018-02-03T01:38:05.235Z', 'updated_at': '2018-02-03T01:38:11.037Z', 'metadata': {'session': '9440df0368e7819e53e5ba72b3db94133d9c4a4a4d75014fce12910e4ed968a7', 'viewport': {'width': 1918, 'height': 869}, 'started_at': '2018-02-03T01:37:59.739Z', 'user_agent': 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36', 'utc_offset': '21600', 'finished_at': '2018-02-03T01:38:05.116Z', 'live_project': False, 'user_language': 'en', 'subject_dimensions': [{'clientWidth': 782, 'clientHeight': 782, 'naturalWidth': 2000, 'naturalHeight': 2000}], 'workflow_version': '32.38'}, 'href': '/classifications/88474114', 'links': {'project': '5918', 'workflow': '5734', 'subjects': ['17511849']}}
Same classification data in csv dump:
{'classification_id': '88474114', 'user_name': 'not-logged-in-84e52d3d29185275d480', 'user_id': '', 'user_ip': '84e52d3d29185275d480', 'workflow_id': '5734', 'workflow_name': 'cluster classifiation', 'workflow_version': '32.38', 'created_at': '2018-02-03 01:38:05 UTC', 'gold_standard': '', 'expert': '', 'metadata': '{"session":"9440df0368e7819e53e5ba72b3db94133d9c4a4a4d75014fce12910e4ed968a7","viewport":{"width":1918,"height":869},"started_at":"2018-02-03T01:37:59.739Z","user_agent":"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36","utc_offset":"21600","finished_at":"2018-02-03T01:38:05.116Z","live_project":false,"user_language":"en","subject_dimensions":[{"clientWidth":782,"clientHeight":782,"naturalWidth":2000,"naturalHeight":2000}]}', 'annotations': '[{"task":"T0","task_label":"Which class dominates this cluster?","value":"All Muons"}]', ... , 'subject_ids': '17511849'}

I don't think we can change either of them at this point. The API results are relied upon by the frontends, which need the raw index of the option (correctly guessed!). And it would also be strange for an API client to get back a different result than what you sent into the API in the first place.
This transformation to readable strings happens in the backend upon exporting, to ease pains that users of those CSV dumps were having. On reflection, we probably should have only extended the JSON, not replaced values. But if we change that now we'll break everyone's data flow. :(

Ok, that makes sense. Seeing that the current versions need to see continued support, would it instead be sensible to add a flag to allow a client to request a different format for the annotation data, something that includes both the index and the text of an answer, or to specify which is preferred?
Otherwise, is there a way to request the index-to-text mapping from Panoptes?

@miclaraia - apologies for the tardy reply.
You can request the workflow task state via the version endpoint https://panoptes.docs.apiary.io/#reference/workflows/workflow-version/retrieve-a-single-version (where the id should match the classification version number) and marry the tasks -> annotations that way.
Also there is https://panoptes.docs.apiary.io/#reference/workflowcontents/workflowcontent-version/retrieve-a-single-version
You will be the first person to use that version history and it may be buggy, please do report any issues.


fix help error

Codecov Report

Merging #101 into release-rc4 will increase coverage by 0.04%.
The diff coverage is 0.00%.

@@                Coverage Diff                @@
##             release-rc4     #101      +/-   ##
=================================================
+ Coverage          33.00%   33.04%   +0.04%
  Complexity           361      361
=================================================
  Files                 51       51
  Lines               4409     4403       -6
  Branches             372      372
=================================================
  Hits                1455     1455
+ Misses              2846     2840       -6
  Partials             108      108

Impacted Files
Coverage Δ
Complexity Δ

...cross/stub/bcos/proxy/ProxyContractDeployment.java
0.00% <0.00%> (ø)
0.00 <0.00> (ø)

Continue to review full report at Codecov.

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


x/pkgsite: package removal request for [type path here]

What is the path of the package that you would like to have removed?
github.com/SidneyCao/gofile
github.com/SidneyCao/tcping

Are you the owner of this package?
Yes

What is the reason that you could not retract this package instead?
Today i have changed my github accout name from SidneyCao  to sidneycao,
and also the pkg path should changed from github.com/SidneyCao/gofile to github.com/sidneycao/gofile or
from github.com/SidneyCao/tcping to github.com/sidneycao/tcping
but now https://pkg.go.dev/ only shows  github.com/SidneyCao/*  and github.com/sidneycao/* will redirect to github.com/SidneyCao/*, which confused me a lot.

Now github.com/sidneycao/* will not redirect to github.com/SidneyCao/, but https://pkg.go.dev/  still not show github.com/sidneycao/.

i see both https://pkg.go.dev/github.com/sidneycao/tcping and https://pkg.go.dev/github.com/sidneycao/gofile

Now i can see both， but the search result can only show  github.com/SidneyCao/*

It worked！ Thanks  a lot!


[pwrmgr] Tests to V2(S) level

Description

[ ] pwrmgr_sec_cm 4/5 [1d]

estimate 4

These SEC_CM tests seem to pass now on the nightly dashboard, so I think we can close this.


Fix album selection in sharing.delete

Add additional sanity checks in Users and Sharing views to prevent server errors.
Improve the styling in the Users view (at least I think I improved it :smiley:).

Yeah, the first version of this patch had those corners round, but then I noticed that it was customary in Lychee to have only the bottom corners of buttons be round -- see, e.g., the Settings or Sharing views. So I decided to follow the established convention.
I'll ask @SerenaButler what he thinks :smiley:.

OK, with my latest push, the top corners should be consistently round in all the views. And yes, I kept them at the right angle for the inner corners in Save/Delete.
Also, I forgot to mention that this commit should fix https://github.com/LycheeOrg/Lychee-Laravel/issues/143.


[Relay][Documentation] List of passes invoked by opt_level does not seem to have been updated

The comment for relay.transform.build_config() gives the following list of passes per optimization level:
            OPT_PASS_LEVEL = {
                "SimplifyInference": 0,
                "OpFusion": 1,
                "FoldConstant": 2,
                "CombineParallelConv2D": 3,
                "FoldScaleAxis": 3,
                "AlterOpLayout": 3,
                "CanonicalizeOps": 3,
                "EliminateCommonSubexpr": 3,
            }

However, looking at the implementation of Optimize() in src/relay/backend/build_module.cc, I see more passes than just these being invoked and it is not clear from reading the code how the optimization level is taken into account. E.g.,
    pass_seqs.push_back(transform::EliminateCommonSubexpr(fskip));
    pass_seqs.push_back(transform::CombineParallelConv2D(3));
    pass_seqs.push_back(transform::FoldConstant());
    pass_seqs.push_back(transform::FoldScaleAxis());
    pass_seqs.push_back(transform::CanonicalizeCast());
    pass_seqs.push_back(transform::CanonicalizeOps());

(CanonicalizeCast was not listed in the comment quoted before.)
Is there any more accurate way we can document the passes that are invoked based on the optimization level specified? The implementations of files like build_module.cc and transform.cc are complicated at times and it takes a lot of reading to understand what exactly each part does.

yeah, I agree that we need a better way to document/define the optimization level for a pass. I am not sure how the opt level is defined for each pass as well.
Do you think it is necessary to have a -O level system to control the passes instead of manually adding them in the build_module.cc file? We should probably have a separate doc to explain the passes and opt levels like what gcc does https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html.

I know @jroesch has long been against having the O-levels, so perhaps he might weigh in on this topic.
I dislike that the O-levels are opaque in that there is no stated rationale for the passes included in them nor (as far as I know) much of a process for deciding which passes should be in what level.

close due to inactive status, feel free to open new dev discuss thread on https://discuss.tvm.ai/


Microsoft.OperationalInsights: Adding table migrate.

MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[ ] new API version
[x] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month.
When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month.
If updating an existing version, please select the specific langauge SDKs and CLIs that must be refreshed after the swagger is published.

[ ] SDK of .NET (need service team to ensure code readiness)
[ ] SDK of Python
[ ] SDK of Java
[ ] SDK of Js
[ ] SDK of Go
[x] PowerShell
[x] CLI
[ ] Terraform
[ ] No refresh required for updates in this PR

Contribution checklist:

[x] I commit to follow the Breaking Change Policy of "no breaking changes"
[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[x] Check this box if any of the following apply to the PR so that label "WaitForARMFeedback" will be added automatically to begin ARM API Review. Failure to comply may result in delays to the manifest.

Adding a new service
Adding new API(s)
Adding a new API version
-[ ] To review changes efficiently, ensure you are using OpenAPIHub to initialize the PR for adding a new version. More details, refer to the wiki.

[ ] Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If any of the following scenarios apply to the PR, request approval from the Breaking Change Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in a stable version
[ ] Removing properties in a stable version
[ ] Removing API version(s) in a stable version
[ ] Updating API in a stable or public preview version with Breaking Change Validation errors
[ ] Updating API(s) in public preview over 1 year (refer to Retirement of Previews)

Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.

The two claimed breaking change are with no effect on customers.

Version is not available yet and was limited behind feature flag (it was planned first as limited public preview which should start at February 15th). it was decided to open it to all, but manifest change didn't take effect yet.
Swagger introduced a mistake with one of the payloads, read only property for "source table" was in correct.
We added a new operation.

The two claimed breaking change are with no effect on customers.

Version is not available yet and was limited behind feature flag (it was planned first as limited public preview which should start at February 15th). it was decided to open it to all, but manifest change didn't take effect yet.
Swagger introduced a mistake with one of the payloads, read only property for "source table" was in correct.
We added a new operation.

Please get approval using the breaking change process outlined in the PR description.  If you feel the validation flagged the changes in error please give them that feedback as well.


Smart replace with "null" on php8 constructor promoted property

Example:
class SomeClass
{
    public function __construct(private $variable = 'default') {
    }
}

Aplying Smart replace with "null" generates:
class SomeClass
{
    public function __construct(private $variable = null) {
        $variable ??= 'default',
    }
}

In case of promoted properties generated code should look like this:
class SomeClass
{
    public function __construct(private $variable = null) {
        $this->variable ??= 'default',
    }
}

More info:
https://php.watch/versions/8.0/constructor-property-promotion

Related issue #33

Thank you for your time in reporting this issue. The fix has been implemented in version 0.25.0 and is available exclusively through the Releases page. It will be implemented in the JetBrains Marketplace once this issue that are affecting some users are resolved (no ETA).
In response to your report:

The issue has been identified and fixed. Now, when applying the suggested fix, $this will be included for promoted properties. (eg. $this->variable ??= 'default')


Convert TNC C module to cython

The TNC C module (optimize.tnc.moduleTNC.c) is quite hard to update/follow. This PR converts it to use a Cython wrapper instead.
This conversion will help debug #14879 (because I'll become familiar with the codebase)

@rgommers, when I try to build this cython extension (using python setup.py build) I get the following error message:
building extension "scipy.optimize._tnc_module" sources
Traceback (most recent call last):
  File "setup.py", line 622, in <module>
    setup_package()
  File "setup.py", line 618, in setup_package
    setup(**metadata)
  File "/Users/andrew/miniconda3/envs/dev3/lib/python3.8/site-packages/numpy/distutils/core.py", line 169, in setup
    return old_setup(**new_attr)
  File "/Users/andrew/miniconda3/envs/dev3/lib/python3.8/site-packages/setuptools/__init__.py", line 153, in setup
    return distutils.core.setup(**attrs)
  File "/Users/andrew/miniconda3/envs/dev3/lib/python3.8/distutils/core.py", line 148, in setup
    dist.run_commands()
  File "/Users/andrew/miniconda3/envs/dev3/lib/python3.8/distutils/dist.py", line 966, in run_commands
    self.run_command(cmd)
  File "/Users/andrew/miniconda3/envs/dev3/lib/python3.8/distutils/dist.py", line 985, in run_command
    cmd_obj.run()
  File "/Users/andrew/miniconda3/envs/dev3/lib/python3.8/site-packages/numpy/distutils/command/build.py", line 61, in run
    old_build.run(self)
  File "/Users/andrew/miniconda3/envs/dev3/lib/python3.8/distutils/command/build.py", line 135, in run
    self.run_command(cmd_name)
  File "/Users/andrew/miniconda3/envs/dev3/lib/python3.8/distutils/cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "/Users/andrew/miniconda3/envs/dev3/lib/python3.8/distutils/dist.py", line 985, in run_command
    cmd_obj.run()
  File "/Users/andrew/miniconda3/envs/dev3/lib/python3.8/site-packages/numpy/distutils/command/build_src.py", line 144, in run
    self.build_sources()
  File "/Users/andrew/miniconda3/envs/dev3/lib/python3.8/site-packages/numpy/distutils/command/build_src.py", line 161, in build_sources
    self.build_extension_sources(ext)
  File "/Users/andrew/miniconda3/envs/dev3/lib/python3.8/site-packages/numpy/distutils/command/build_src.py", line 324, in build_extension_sources
    sources, py_files = self.filter_py_files(sources)
  File "/Users/andrew/miniconda3/envs/dev3/lib/python3.8/site-packages/numpy/distutils/command/build_src.py", line 391, in filter_py_files
    return self.filter_files(sources, ['.py'])
  File "/Users/andrew/miniconda3/envs/dev3/lib/python3.8/site-packages/numpy/distutils/command/build_src.py", line 400, in filter_files
    (base, ext) = os.path.splitext(source)
  File "/Users/andrew/miniconda3/envs/dev3/lib/python3.8/posixpath.py", line 118, in splitext
    p = os.fspath(p)
TypeError: expected str, bytes or os.PathLike object, not list

Can you see anything incorrect with my alterations to optimize.setup.py?

@ev-br, there are a few things that need to be fixed further on, but your suggestion doesn't allow to go any further.

This PR is ready for a review now. The test fails are unrelated.

The privatisation drive meant that this PR was suffering from merge conflicts. It was easier to rebase on master and force push, after a bit of manual twiddling.
@da-woods, would it be possible for you to review the cython code for me? Hopefully there's nothing too egregious.
I've tried to copy the outgoing moduleTNC.c in terms of structure.

The other option would just be to have callback swallow the exception (maybe printing it first). To be honest, that might be cleaner and simpler

Yet another way would be to modify the C code to have tnc_callback produce a non-void return.

@rgommers, the PR is ready to go as far as I'm concerned. @da-woods had a look at the cython code and seemed to think it's in an ok state. I checked that raised exceptions works from both the objective and callback (with tests) and I can't detect any leaks.

@ev-br @rgommers it'd be great if this PR could go in before 1.8 is released (it closes . As far as I'm concerned it's ready to be merged. @da-woods has reviewed it, but it needs a core-dev to have a look at it and merge.

Thanks @andyfaff et al. -- note that I"ve also switched the title/label to clarify that this is a bug fix, though I suppose it is equally an enhancement for clarity/understanding.
In any case, feel free to re-label, etc. as you see appropriate.

I added a release note.


Zarr part mda

The zarr writer fails for me if I have only a partly set up MDASequence. Does it fail for you as well?
Will see if I can fix it.

The tests pass for me with this locally.

btw, love the test-driven development with the first commit here e1b5fe7 :)


Added support for multiple instances of Postmate on the same page

Fixes #25

@loganvolkers sorry again that it took me so long to get back to you.
This PR will be closed but some of the good work that was done within it may/will be used. If you'd like to do it within this PR or another, please reach out.
Thanks you!


[WIP] bazel/ci: Shift GCS upload script to bazel

Commit Message:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

/docs

/coverage


New permission system based on roles

🛠 Changelog

Replace current permission system with one based on roles. In practice, permissions stay as they are, and there is a migration which migrates from the old permission system to the new.
Full explanation:

https://helsinkisolutionoffice.atlassian.net/wiki/spaces/KAN/pages/8950382632/K+ytt+oikeuksien+uudistus+roolipohjaiseksi
https://helsinkisolutionoffice.atlassian.net/wiki/spaces/KAN/pages/8947040275/Roolit+K+ytt+oikeudet+TVP

Note that old permissions are removed when the new ones are added. If there is a risk that this might lead to wrong permissions being applied, we could save the old permissions as a backup. Still, the old permissions won't be effective even if saved.

Adds users permissions to the user view in Django admin. This serves as a place to view all the user's permissions in one place.
Adds an endpoint to the GraphQL API for checking users permissions. Frontend can use this endpoint instead of duplicating logic from backend.

🧪 Test plan

Automated tests
Manual testing with users of different permissions. Should check that users with different roles can still do their basic workflows. Backend does have tests for these as well, but just in case...

🚧 Dependencies

Requires frontend to rewrite permissions according to the new system. Roles can be fetched from the backend through the current user, but permissions still require a new endpoint, which will be added to this PR later.

🎫 Tickets

TILA-3200
TILA-3468
TILA-3201
TILA-3518

Added TILA-3518 to this PR.


No such file or directory (os error 2)', crates/linker/src/metadata.rs:59

You should replace your:
packages { pf: "https://github.com/roc-lang/basic-cli/releases/download/0.1.3/5SXwdW7rH8QAOnD71IkHcFxCmBEPtFSLAIkclPEgjHQ.tar.br" }

with:
packages { pf: "https://github.com/roc-lang/basic-cli/releases/download/0.2.0/8tCohJeXMBUnjo_zdMq0jSaqdYoCWJkWazBd4wa8cQU.tar.br" }

I'm working on a PR with a better error message right now.

@Anton-4 If I use the 0.2.0 tar ball as the tutorial suggests, I get the no such file error. However, if I change it to 0.1.3 it works. I'm on Linux and followed the install instructions here: https://github.com/roc-lang/roc/blob/main/getting_started/linux_x86_64.md
Version: roc nightly pre-release, built from commit d926ea0 on Mo 16 Jan 2023 09:08:48 UTC

Hi @ChrisWellsWood, I think this is because you are using an older version of roc. Using the latest nightly release should make basic-cli 0.2.0 work.

Sorry @Anton-4, that was me being dense. When I saw the error, I went to check the current version and noticed that there was only one release from October last year:

So I assumed I was up to date, but I see that the assets have been updated since. I understand why you're doing it this way, so there's not tonnes of similar nightly releases. Thanks!

Happy to help :)
Your reasoning was very logical here, I'll make an issue to put the nightly releases on the website to prevent this confusion.


Option to blank out tasks in registry (after backing them up)

I had a problem with my Task Scheduler, and, at first, your program didn't seem to help. But I wound up getting it to work by finding the tasks in the registry (at HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks. and .\Tree) and deleting them (after backing them up) and then using the Scan and Repair options in your program. To my surprise, this finally fixed the issue.
So I thought it might be nice if you could offer a way to automatically perform this feature. It would probably be prudent to backup the registry entries in a .reg file, just in case. But a "wipe tasks from registry and rebuild" might be useful for some users.
Or, at the very least, maybe a button that would open regedit at the correct location so people could mess with the tasks themselves if your program doesn't work at first.

Interesting. I thought that RepairTasks had more or less outlived its usefulness now that most people are on Windows 10, or if they're not, are no longer reverting from Windows 10 to Windows 7. But maybe there is life in the old warhorse yet, and scenarios where RepairTasks may be able to help.
Could you tell me please what version of Windows are you running, and what the symptoms of your task problems were?
Dijji

It's Windows 7 still--I've had troubles on this PC with Windows 10 on this PC, but that was long ago, and I've even done a fresh Win7 install since then. That said, I'm not sure my problem was really OS-specific.
What I think happened is that one of the antiviruses I was trying out screwed up its uninstall, and left corrupted tasks behind. The symptoms were that any time I'd open Task Scheduler, I would get repeated warnings about corrupted tasks, all of them named {1} or {0} (can't remember which),  and when it finally gave me access to the app, only the top level tasks were visible.  However, the Windows\Tasks folder still had all my tasks.
I tried a repair using your app, and the only fix was that a log directory didn't exist, and fixing that didn't help. I tried using your ZIP file to reset/replace all the tasks in that tasks folder (backing up the old ones and then deleting them), then running your program. While it did claim to repair them all, I kept getting the errors. Only deleting all the tasks in the registry (and backing them up) and allowing your program to recreate all the registry tasks finally fixed the problem.
I am so grateful your program exists., as I read through all of the manual steps and they were extremely daunting. I thought surely someone had written an automated tool. That you made it open source was why I trusted it.

Thank you. I feel the same way you do about trusting "repair" utilities found on the Internet. It's about as attractive as going into the local bar and asking for volunteers to help sort out your bank accounts. Hence, open source and as much explanation and provenance as possible.
I think you have it right in that the problem was a partial uninstallation. Two things have to be in sync: what it says in the registry, and the XML files in the Tasks directory. TaskRepair keys off the XML files, and makes sure there are registry entries to match, because it is the registry entries that rollback from Windows 10 loses. In your case, however, the uninstallation removed the XML files, but left the registry entries behind, causing the problems.
The right fix to TaskRepair would I think be to check for orphaned registry entries with no corresponding XML files, and offer to clean them up. This would reduce the risk of causing further damage by deleting the whole set of entries, by which point you had better have the XML files, or you will have nothing.
I think this would be a good thing for any remaining hardy Windows 7 users, and I will add this to my to-do list, though not at a very high priority, as it only helps a diminishing audience. Windows 10 eliminates the entire problem by holding all information about tasks in the registry, so nothing can get out of sync.


Modify velocity-template.xml and APITemplateBuilder to include operation policy mediation logic.

Closing the issue as the architecture has been changed.


Add some docker-compose config-wide shortcuts

Is your feature request related to a problem? Please describe.
When starting lazydocker in a docker-compose context with nothing currently running, there's no way to run docker-compose commands like build, pull, up on them all together
Describe the solution you'd like
I'm not entirely sure, but maybe adding config-wide options to the keyboard shortcuts under Status, given that already has a tab with docker-compose config? b: build all, p: pull all, u: up all would all be useful IMO and don't conflict with current shortcuts in that section.
I'm not sure though because the current shortcuts there are really about lazydocker itself.
Describe alternatives you've considered
I could always use docker-compose commands outside of lazydocker! Just being lazy :)
Additional context
Sometimes I'll want to run tests locally on a branch that I haven't built locally, and that our CI has already built. In those cases I want to do docker-compose pull or docker-compose build to pull/build all of the images for that branch together. It'd just be nice if I could pull all of that into lazydocker too :)

I 100% agree with this. I see no harm in having lazydocker-specific keybindings sitting alongside docker-compose-specific keybindings

I was also thinking about this. Combined with the -f option in my case.  Was thinking could possibly even replace a lot of the shell script we use which basically just runs things like up -d, down, logs etc. with the right set of files provided via the -f.  I could see changing our workflow to just launching lazydocker from our script that manages the set of files using -f and then you could do up,down etc. from lazydocker while the rest of the UI already replaces the other things we do.

Lazydocker has super nice architecture around these commands - we get interop of everything else with -f for free by just referencing the {{ .DockerCompose }} at the start of all the commands. :)

@mcintyre94 did you want to tackle this issue yourself?

I'm happy to give it a shot when I get some time, but equally happy for someone else to beat me to it - if you or someone else want to give it a shot then got for it :)

I've got a WIP PR up now: https://github.com/jesseduffield/lazydocker/pull/107

Closing with #107 - thanks @jesseduffield! :)


Report errors in actual Val test cases instead of copies

The main feature of this patch is XCTestCase.testSuite(at:relativeTo:). This function will locate the test cases of a test suite identified by its path relative to the Swift file that uses it.
If the suite can be found under Tests/, checkAnnotatedValFiles will report errors on the actual test cases rather than the bundled copies, thus fixing #429. Concretely, that means you'll be able to get to the reported error location with your favorite IDE, modify the file, and re-run your tests.
If the suite can't be found under Tests/, checkAnnotatedValFiles will fall back to its former behavior and read test cases from the bundle. This mechanism is necessary for CI on non-Apple platforms.

When will we ever have a suite that's not available under Tests/?

When will we ever have a suite that's not available under Tests/?

Probable never.

Probably never.

In that case I'd remove handling for these cases from the code and docs.  You probably don't even need an assertion for this, because the tests will just fail.


⚠ Bofrost.hr has degraded performance

In d9515ef, Bofrost.hr (https://www.bofrost.hr) experienced degraded performance:

HTTP code: 200
Response time: 2203 ms

Resolved: Bofrost.hr performance has improved in 9cecf9e after 7 minutes.


⚠ Fortnite has degraded performance

In e7b9d14, Fortnite (https://fortnite.com) experienced degraded performance:

HTTP code: 200
Response time: 1608 ms

Resolved: Fortnite performance has improved in d63792b.


feat(client): extensions generic type api

This PR enables extensions to deal with input and output types in generic extensions to be able to augment them dynamically on any given model. For this, three new utilities appeared:

Exact: Enforces exact type inputs, no more, no less while also narrowing input
Args: Dynamically retrieve the input type of a given model and a given operation
Result: Takes the input types and gives the result for a given model and operation
Payload: Retrieve the payload output types which represent scalars & relations objects

The gist:
const prisma = new PrismaClient()

const xprisma = prisma.$extends({
  model: {
    $allModels: {
      findOrCreate<T, A>(
        this: T,
        x: Prisma.Exact<A, Prisma.Args<T, 'findFirstOrThrow'> & { cache: boolean }>,
      ): Prisma.Result<T, A, 'findFirstOrThrow'> {
        const ctx = Prisma.getExtensionContext(this)

        console.log(ctx.name)

        return {} as any // TODO
      },
    },
  },
  query: {
    $allModels: {
      findUnique(operation) {
        const { __internalParams, query, args } = operation as any as {
          query: (...args: any[]) => Promise<any>
          __internalParams: any
          args: any
        }

        __internalParams.headers = {
          ...__internalParams.headers,
          'x-custom-header': 'hello',
        }

        return query(args, __internalParams)
      },
    },
  },
})

async function main() {
  const test0 = xprisma.link.findOrCreate({
    cache: true,
    select: {
      id: true,
    },
  })
}

Note: @millsp Looks like there is a conflict to solve

Is there any documentation (or examples) on how to use this?
I'm having a hard time figuring it out from sifting through the typedefs in the client and just figuring something like
Prisma.Result<typeof db.measurement, {include: {Location: true}}, "findMany">
out took a little while and is still using typeof.
The Advanced Type Safety docs article could probably use some docs on this.


Allow DiagnosticsCollection provider to read evaluation context for a notebook cell

I'm developing a notebook extension for XPath 3.1. The diagnostics collection provider in a separate extension (that I also maintain) for XPath needs to be able to read the evaluation context for the current notebook cell. Specifically, it needs [prefix, URI] XML namespace bindings and XPath variable names that are in scope for the cell. Without this data, 'problems' are reported unnecessarily and shown in the XPath notebook cell.
Please consider extending the notebook API to provide a feature that allows a notebook cell to publish key parts of it's dynamic evaluation context for this purpose.

I can work around most of the cell evaluation context issues by modifying the DiagnosticsCollection provider so I'm closing this issue.


Can we offer 2 different styles for menu on mobile?

Currently our navbar collapses when we go into mobile with only the logo in the center and turns into a sidebar. I have found that for some projects its good for it to be a sidebar, but in other cases the program REALLY lends itself well to a dropdown menu instead, specially if the sidebar nav only has a few items on it and then it just looks empty.
I attached pictures for reference. Notice how our current sidenav looks empty and bad in mobile if there are only a few options on it, but the dropdown still looks full and nice when in mobile view

Any chance we can offer a dropdown menu as well, and give the developer the options to use either style as he sees fit?

Btw, Material Design has a similar feature, bottom drawer

I've noticed this a few times now that whenever I use materialize instead of other frameworks my website starts to look a lot more blank and empty and am slowly trying to discover those and try to see if we can fix them for all of us


Support for other managed Kubernetes providers

Contributions/suggestions are welcome for other managed Kubernetes providers out there that take declarative configuration.
Amazon EKS: #10

Support for Azure Container Service

@joshisa Will checkout the IBM service. I assume there is a declarative spec for IBM. Can you please link me to an example spec that defines a k8s cluster?
@barry-schneider AKS is already support. Not sure what you meant.

@barry-schneider AWS Kubernetes offering is called EKS (Elastic Container Service for Kubernetes). We already have the implementation, but cannot open source until it goes into GA. More details at #10

@shahidhk IBM Cloud Container Service --> https://console.bluemix.net/docs/containers/cs_cli_install.html#cs_api

@crosen188 Let's move this conversation to #16

Alibaba Cloud

@barry-schneider Are you aware if declarative templates for Alibaba Cloud? If not, terraform could work.

AWS EKS ...


Kafka KRAFT fix

fix is already in for port (from develop branch) and update_run.sh. script has now been replaced by update_storage.sh script


Mvc.Core logging for controller and page factories

This adds logging around controller and page creation.

ControllerActionInvoker (and PageActionInvoker) are the best place to log it is in because, even if it doesn't allow to get more fine grained info, it work for any factory and would not required a closure on the factory delegate.
Not sure which EventId ids I should use. What is the logic? Incremental numbers and reusing it for different log levels?
I wasn't able to find existing tests around similar logging. Is it worth adding some?
I've included a fix for the name of a test in the same area but not related to this change, let me know if I should move it to a separate PR.

Addresses #11005

I wasn't able to find existing tests around similar logging. Is it worth adding some?

It would be nice to add some tests for these if you can. You should be able to find some tests for the logging in resource invoker to use as a base.
The risk is that the logging could get broken and throw, and we only find that out when someone actually needs it and turns it out. We've had this happen a few times 😢

@rynowak I've added tests.
If this approach looks good I can add tests for the rest of the logging in the Invokers in a separate PR.
Thank you,
Alessio

Thanks is great! Thanks. Up to you if you feel like sending a PR to add more tests.

Can you confirm that the failure in the build is unrelated?
Thank you

Agreed, I retried the failing parts of the build.

Thanks! only Helix is failing now. Is it good to be merged?

Merged. Thanks!


Design Freezer

Freezer tab needs design and feature suggestions.

Currently planned features:

List of items and number per person

Ordered by total amount for selected users

Only shows items where total for users >0

Quantity for communal user is always counted towards total.

live search + number

live search allows finding existing or entering new items

number as spinner showing current amount for item selected through search; 0 if product doesn't exist

Last edit date should be tracked for each item for occasional database cleanup to remove items that have been unstocked for a long period.


Ensure DynamicRelationField.to_representation is passed correct instance

This fixes a regression that was originally introduced in d0c31d3 and a869d28
There were a few places in our code where we have subclassed DynamicRelationField and overridden to_representation, conditionally short-circuiting the serialization of a many to many field depending on the request, context, or a property of the parent instance. We had been relying on the fact that to_representation for a ModelField and a DynamicRelationField was always passed the parent instance. But in d0c31d3, and then a869d28, some of the responsibilities of to_representation were moved over to get_attribute.
After updating to the latest version our methods no longer worked, because to_representation was now being passed the ManyRelatedManager, not the parent instance. This seems to me like a bug, as it breaks expectations about the arguments and return values of get_attribute and to_representation. And so far as I can tell, moving the logic back from get_attribute doesn't break anything in dynamic-rest, since the two methods are only ever called together, e.g.: in WithDynamicSerializerMixin._faster_to_representation():
attribute = field.get_attribute(instance)
# ...
ret[field.field_name] = field.to_representation(attribute)

I've included a test that shows roughly how we sometimes override to_representation.

Any chance this might get a review and merged? We're currently installing from our github fork, but we'd prefer to avoid that if we can. Thanks!

Seconding the request for eyes on this, it would be super helpful ❤

Let me know if there's anything I can to do to help get this merged in. We'd prefer it if we didn't need to maintain a fork. Thank you!

@suavesav can help?


creates functions for processing and uploading field sheet data

I added documentation for the field sheet processing and update functions. I wasn't sure if I should export the is_valid_field_sheet_data function (right now it is exported and linked in documentation). Seemed to me like it could be helpful for a user if they can't understand why their data isn't in the correct format but I noticed the other helper functions weren't exported.

we haven't been exporting the validate functions instead we tried to make the message they return as detailed as possible, the message you return is good.


how can i read logs?

i want to know how to read the logs?is there any callback ?

Sorry about that, the repo has been deprecated, I forgot to declare.
you can try other proxy package for koa.

发件人: 李佶橙<EMAIL_ADDRESS>发送时间: 2017年8月29日 14:45
收件人: bornkiller/koa-proxy2
抄送: Subscribed
主题: [bornkiller/koa-proxy2] how can i read logs? (#3)
i want to know how to read the logs?is there any callback ?
―
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/bornkiller/koa-proxy2/issues/3, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AD0Rohc0nOUlGuQvg4MN8UodCTgv5Hcpks5sc7N6gaJpZM4PFcoM.


installing-cardano-node.md Linux update

Updating documentation
Description of the change
After some failed test I end up by installing the latest ghc version, instead of the suggested 8.1.4.
In version 1.29.0 that compiler version prevent the creation of node.socket when starting the node for the first time.
I also updated all mentions from version 1.27.0 to 1.29.0

Closing as this is outdated (see #300 )


serverless schema does not support ${} everywhere

In many places, when we use $(), vscode complains about errors since reference.json does not have support for this.
Example:
resources:
  Resources:
    Bucket:
      Properties:
        BucketName: ${self:custom.bucketName}

@gildas we're aware of this issue and tooling is in the works for this.
The big issue here is if we start supporting them through the schema directly, then we end up in a situation that doesn't allow us maintain the original schema.
The preferred way would be a plugin or extension that evaluates variable reference and matches that agains the schema.
I'm in talks with the maintainer of the VSCode extension to figure out a way of doing this. I will keep this issue open until something gets figured out.

You're welcome

Let's move this to #50, since it's a duplicate!


fix(policy): Latest Purpose policy version updated

Description
Latest Purpose policy version ID 3.1 Trace updated.
Pre-review checks

[x] DEPENDENCIES are up-to-date. Dash license tool. Committers can open IP issues for restricted libs.
[x] Copyright and license header are present on all affected files

@sachinargade123  @adityagajbhiye pls review.

merge this PR after #55


Extend basket view to use default shipping address

The basket summary view attempts to look up a default shipping method so an indicative order total can be displayed.  The checkout allows the method to be changed later on though.
At the basket stage, we don't know the user's chosen shipping address so we don't pass it.  However, Oscar does have a concept of default shipping address.  We should extend the basket view to pass the user's default shipping address (if one is known).

pass where ?

right here https://github.com/django-oscar/django-oscar/blob/master/src/oscar/apps/shipping/methods.py#L33
how would I calculate the shipping charge, without knowing the address?


BugFix SYIOS-202: IOS should no longer reset badge count on launch.

fix: MXRoom.unreadEvents and [MXStore unreadEvents::] should be removed #82

LGTM


Add maxInstantiationDepth to compiler optionDeclarations

[ ] There is an associated issue that is labeled
'Bug' or 'help wanted' or is in the Community milestone
[X] Code is up-to-date with the master branch
[X] You've successfully run jake runtests locally (Had to run jake baseline-accept)
[X] You've signed the CLA
[ ] There are new or updated unit tests validating the change

Fixes #29511

The first two make sense to me, since I added a new field to the CompilerOptions interface in types.ts
The last one isn't so obvious to me and I'm not sure how I'd go about correcting this.
[EDIT]
Oh, I think it's just that I have to accept the new baseline file under baselines/local/showConfig/Shows tsconfig for single option/maxInstantiationDepth/tsconfig.json
{
    "compilerOptions": {
        "maxInstantiationDepth": 0
    }
}

I looked at the baseline changes and they seem okay to me. Nothing wildly different. So, I went and accepted them.
I know it's just a test with a dummy value but setting maxInstantiationDepth to 0 is a bad idea =P
[/EDIT]

The issue is only marked as Needs Investigation but I figured I'd take a stab at adding this compiler option. Being able to increase the maximum instantiation depth from 50 to an arbitrary value is useful for me because I seem to work with deeply nested, non-recursive, types a lot.
I'm not sure how to write unit tests to test this compiler option yet but I'll try and figure it out. I figured I'd just make the PR first.
I'm not sure what description to give this compiler option, and what code it would use.
Do I need to add maxInstantiationDepth to protocol.ts > CompilerOptions, too?
I'm also unsure what else I might be missing.

While jake runtests fails and I haven't written a unit test for this compiler option, I've tested it against a project I'm working on and it seems to work.
Without setting maxInstantiationDepth, compiling my project fails, setting maxInstantiationDepth to 74 lets it compile successfully.

I realize this PR has a bunch of problems but I'm out of my depth (No pun intended).

maxInstantiationDepth is an intentional limitation of the compiler to prevent slow compiles, so we're not going to remove it. Even if #32611 allows much more nested types to compile, it's likely that we'll have a different kind of limiter in place. Because that future limiter will be named something different, I don't think PR will apply to it.

maxInstantiationDepth is an intentional limitation of the compiler to prevent slow compiles, so we're not going to remove it. Even if #32611 allows much more nested types to compile, it's likely that we'll have a different kind of limiter in place. Because that future limiter will be named something different, I don't think PR will apply to it.

I am surprised by the feedback; TypeScript's flexibility has always been its strength.
If a codebase and an engineering team feel it could benefit more from a complex typing structure that enables something that may not be otherwise enabled with full compile time type safety; why shouldn't they be empowered to make the tradeoff choice themselves about whether they will accept slow compiles?
Especially when the change seems so easy and clean.
Would you be open to further discussion?


[BUG] Clarification on #1457

Please don't close this ticket--this is a valid bug--it is a valid discussion. A harmless, legitimate perspective. I'm terribly sorry a maintainer got so offended by something that wasn't even the slightest bit derogatory. My follow up to: https://github.com/fastfetch-cli/fastfetch/issues/1457 Their screenshot attempting to prove something, (I'm not sure what), right after preventing me to reply any further:

If you want to believe it's not possible because of what you tried alone than I can't force you to believe it can still work by other means. The above screenshot proves nothing besides the person who posted it wasn't reading anything I was telling them at all, and they also yelled at me and got angry when I wasn't doing anything wrong to them, just pointing out a bug they didn't want to fix. I am very aware the solution I gave was not bullet-proof, and it will sometimes report llvmpipe or something like that, in such a case we can use some form of fallback to avoid that, just like what you already do when failing to read the PCI ID if not running fastfetch under a root user.
I can't force this bug to be fixed, if you don't want to fix it, you don't have to. But my goodness, at least let people report bugs without closing and locking their tickets, so that others who actually want to fix the problem can see it and do something about it.  They wanted a monologue, not allowing me to express perfectly harmless and valid thoughts. I don't mean these things as an insult. If you want people working with you on an open source, (or any), project, it seriously pays to not be hostile.
Prerequisites:
You need Xorg installed (Xenocara). In a lot of cases you would likely need to run fw_update to ensure you have graphics acceleration enabled. If there are no graphics drivers available for you chipset, even after running fw_update, using GLX or Vulkan to get the PCI ID will fail, and this would also be the case when running without an Xorg or Wayland session, or when running under the scfb/vesa drivers.
Steps to produce and observe what I described in my previous ticket does in fact work for those who care enough to do it:

On OpenBSD you need the following installed: git, xxd, pkgconfig, sdl2, and x11.
Run the following in an Xorg graphical session:

git clone https://github.com/time-killer-games/sysinfo $HOME/sysinfo && cd sysinfo && ./build.sh

Be amazed.

If fw_update or the built-in kernel itself provided the graphics drivers necessary for retrieving the proper PCI ID, and pci.ids had that chipset and vendor correctly listed, you should see that information then printed to the terminal beside the "GPU MANUFACTURER" and "GPU RENDERER" fields. Again, you already have it so that there is a fallback when not run as root, why can't the same fallback be used when there is Xorg or no graphics acceleration instead? This would have a lot less failure cases to display the right information.
The only time it wouldn't show the right information is when the pci.ids file is bugged, you don't have Xorg running in the current TTY, or no drivers exist for your graphics card, that is way less failure cases than simply failing every single time you are not running under root.
All of these things I mentioned are perfectly valid and reasonable to consider. I don't care to argue about this so I won't say anything else. I don't appreciate being treated this way just because I told you something you don't want to hear--you wrote software with bugs.
Have a nice day.

There is no xxd in OpenBSD, nor pkg_add xxd work

There is, would you like me to provide video footage?

Got it working by installing vim. This is what I get

Just some normal stuff. To be honest I didn't get amazed...

Do you have graphics acceleration enabled?

No. As I have said, OpenBSD doesn't even have nouveau, nor does the proprietary nvidia driver.

Well yeah, but forcing this feature to only work when run as root, when it could work for more than 99% of non-NVIDIA GPU's is very limiting. That's the only point I was making in my initial ticket. If you don't find that pressing enough to do anything about it, then I guess there's nothing left to discuss.

when it could work for more than 99% of non-NVIDIA GPU's

I don't think so. AFAIK GPU manufacturers (except NVIDIA for FreeBSD I think) don't really care *BSDs. All GPU drivers of *BSDs (except NVIDIA for FreeBSD) are ported from Linux, which makes it very slow to support newest GPU devices. Even the most up-to-date BSD - FreeBSD has issues with Intel GPU. The newest GPU driver (only i919 but xe) of FreeBSD is ported from Linux 6.1. The newest Linux version is 6.12.
I still don't know what you want me to do. If fastfetch fails to query PCI devices directly, it silently falls back to vulkan or OpenGL. That's why the GPU entry in my last screenshot is detected as llvmpipe. I have repeated myself several times.

I've repeated myself multiple times too. This isn't getting anywhere. At this point, I would just say, don't worry about it.
Thank you for at least being willing to continue to discuss this at all. I really appreciate it.


Error getting result from Torch subprocess

Error getting result from Torch subprocess.
Line read:
Exception:
could not convert string to float:
============
stdout:
============
stderr: /root/torch/install/bin/luajit: inconsistent tensor size at /root/torch/pkg/torch/lib/TH/generic/THTensorCopy.c:7
stack traceback:
[C]: at 0x7fc6874ae020
[C]: in function '__newindex'
/root/openface/openface/openface_server.lua:63: in main chunk
[C]: in function 'dofile'
/root/torch/install/lib/luarocks/rocks/trepl/scm-1/bin/th:133: in main chunk
[C]: at 0x00406670
This happens with attached picture (when align fails).

Actually this one

Its because 96x95?

Hi @Strateus - what commands are you running? I'm just an unable to align error.
openface(master*)$ wget https://cloud.githubusercontent.com/assets/5196895/11178263/b704570e-8c5c-11e5-8fc9-21e69f891493.jpg -O issue54.jpg --quiet
openface(master*)$ ./demos/classifier.py infer ./models/openface/celeb-classifier.nn4.v1.pkl ./issue54.jpg
Warning: Unable to align and crop to the face's bounding box.
Traceback (most recent call last):
  File "./demos/classifier.py", line 158, in <module>
    infer(args)
  File "./demos/classifier.py", line 104, in infer
    rep = getRep(args.img)
  File "./demos/classifier.py", line 65, in getRep
    raise Exception("Unable to align image: {}".format(imgPath))
Exception: Unable to align image: ./issue54.jpg

yes, it happened because i pushed this image with original shape (ie 96x95x3) after align failed, that caused this error.


Improve legibility and general refactoring

I added a file to the source control to enable the experimental feture "records" without this the project does not run.
I also refactored the part in the main function where you set the window position, size and title to make it more readable and organized.

Hi @TimeLord2010, Thanks for sending a PR.
This PR brings significant changes to the project structure and also changes quite a lot of code lines.
Hence, it will require further testing and review.

We have made significant progress in this area in the current release, so I am closing this PR.
In case you wish to send a new PR, do check out some good first issues.


Taskbar hides when coming from full screen app

Hi,
I noticed that when I come from a full screen app (like Remote Desktop), Taskbar hides when it is set up for anything other than "Taskbar reserves space" in the Cairo settings. It would be nice if it would behave as expected - appearing again after exiting from full screen app.
Tom

This should be resolved in the latest release. Please re-open if you continue to have this issue.


Hyper always starts in windowed mode instead of fullscreen

[x] I am on the latest Hyper.app version
[x] I have searched the issues of this repo and believe that this is not a duplicate

OS version and name: Windows 10
Hyper.app version: Hyper 2.0.0 Canary 14

Issue

The Hyper window does not open up in full screen mode when restarted after closing the window. How do I set the default behavior to open up the main window in full screen rather than windowed mode?

This an OS quirk with Windows it seems
This article suggests you can edit the properties for the shortcut to always open maximized

Wow, that worked.
Will it be fixed in future releases as default setting?

Otherwise https://github.com/zeit/hyper/pull/2382 should hopefull go in one day

I'm on macOS and I also miss the option of always starting Hyper in full screen.


intelude.h missing

After following the csapex project installation instructions, I cloned the csapex_generic_obstacle_detection to the csapex plugins folder but I got a compilation error
 /home/user/ws/csapex/src/csapex/plugins/csapex_core_plugins/csapex_generic_obstacle_detection/src/obstacle_detection/obstacle_detector.cpp:17:42: fatal error: csapex/profiling/interlude.hpp: No such file or directory

Thanks for the report. I pushed the missing commits

Problem solved, thank you!


Bug_SchemaRenderer> Modal> 'schema' control prop> Preview is not getting changed when manipulating the data on 'schema' control prop.

Describe the bug
Preview is not getting changed when manipulating the data on 'schema' control prop.
To Reproduce
Steps to reproduce the behavior:

Go to 'https://storybook-preview-290--upbeat-sinoussi-f675aa.netlify.app/?path=/story/schemarenderer--modal'
Click on 'Toggle' button
Observe that modal window is appearing
Manipulate the data 'schema' control prop
Verify that preview is not getting changed

Expected behavior
Preview is not getting changed when manipulating the data on 'schema' control prop.
Screenshots
https://somup.com/c3nb69Th0o
Desktop:
OS: [Win 10]
Browser [chrome]
Version [Version 98.0.4758.82 (Official Build) (64-bit)]

Close the modal and reopen after changing the schema, the changes are seen. Changing props in the controls does not cause full re-renders by default.


DLRS is not getting calculated - the rollup is not writing zeros to my specified field when in realtime calc mode.

Hi, The DLRS is realtime still not getting calculated until we manually calculate it.
Please find the attached screenshot :

Note : The aggregate result and field to aggregate are of same name.

Hi
I am also having the same issue

I am also having the same issue. Manual calc works, but realtime is not updating

I am also having the same issue. Manual calc works, but realtime is not updating

I have figured out that the rollup is not writing zeros to my specified field when in realtime calc mode. A recent change in behaviour is preventing one of my Process Builder processes from firing. I have updated my process so that it fires on null values and zeros as a workaround, now realtime DLRS is calculating as long as the value is greater than 0.

Hmmm i would like to look into this further. There has been a few issues like this over the years... i wonder if this was at the heart of it for those that where not the usual reason...

Hi there, I am have a similar issue when trying to aggregate just a Count of IDs of Opportunity Team Members on an Opportunity ( rollup summaries OOTB Salesforce does not provide an option to Opportunity Team Members).  I just want to count the number of Opportunity Team Members on an Opportunity, and the Lookup Summary works when I force-calculate the field, does not work in realtime.
Set up is Standard:

Hi there, I am have a similar issue when trying to aggregate just a Count of IDs of Opportunity Team Members on an Opportunity ( rollup summaries OOTB Salesforce does not provide an option to Opportunity Team Members).  I just want to count the number of Opportunity Team Members on an Opportunity, and the Lookup Summary works when I force-calculate the field, does not work in realtime.
Set up is Standard:

I know a lot of this is quite old. Is anyone connected to this issue still having problems and would be interested in looking deeper? I'd like to give it a chance to find a root cause and get a resolution.
If I don't hear back from anybody then I'll probably close it and worry about it the next time it is reported. (We do still such reports from time to time but it is often found to be cause by missing Relationship Criteria Fields values, but not always)


add key for genomic reference to template

List the new key
Using OLS or a similar resource, please find a standard term that fits your needs. OLS-listed NCIT and OBI dictionaries are preferred sources. Non-OLS sources of ground truth for specific items such as ONCOTREE for cancer types, or GEO for platform definitions are also appropriate.
Key:reference_genome_build
Provide definition and source for the new key
Definition: The source-specific version of the published genome assembly. [ NCI ]
Source url: https://www.ebi.ac.uk/ols/ontologies/ncit/terms?iri=http%3A%2F%2Fpurl.obolibrary.org%2Fobo%2FNCIT_C164815
Please describe why this concept is necessary
For aligned read files it is important to know which reference genome the reads were aligned to. This helps users decide downstream analytical steps (i.e. whether to re-align or liftover to newer builds) while re-using the data.
Please describe the situations in which this concept may apply
This concept is important if 1) a user is looking for additional data that matches their own analytical dataset (i.e. aligned to same genome build), 2) needs to decide on downstream analytical steps after downloading the dataset from NF Data Portal.

We do actually have, so I think we just need to add it to the template https://github.com/nf-osi/nf-metadata-dictionary/blob/91a33e6147ffe5f2398a769b561c9fdb9ce687da/modules/props.yaml#L295-L299

What value should we be using here? There are a lot of standard genome values, but for my recent annotation (which inspired this issue), the reference is less standard and hosted on synapse: https://www.synapse.org/#!Synapse:syn50670703
I suppose in this case the name we could use is GRCh38_no_alt_plus_hs38d1 or GRCh38_no_alt_analysis_set_GCA_000001405.15

Looks like this reference is called GRCh38_Verily_v1 : https://cloud.google.com/life-sciences/docs/resources/public-datasets/reference-genomes (Verily's GRCh38)

Yah, I saw that, but I think that the Verily flavor has some additional changes.

The file linked in the Synapse ID seems to be similar to the following file listed in its README:
D. GCA_000001405.15_GRCh38_no_alt_plus_hs38d1_analysis_set.fna.gz

A gzipped file that contains all the same FASTA formatted sequences as
GCA_000001405.15_GRCh38_no_alt_analysis_set.fna.gz, plus:
7.  human decoy sequences from hs38d1 (GCA_000786075.2)

I guess you could also just link to the SynapseID where this specific build is stored.

Ah haha, this is very confusing. I didn't read the README, I just looked at this part:

The base assembly is GRCh38_no_alt_plus_hs38d1, which was created specifically for analysis. Its rationale and exact genomic modifications are documented in its README file.
Verily applied the following modifications to the base assembly:
Reference segment names are prefixed with chr. Many of the additional data files are provided by GENCODE, which uses the "chr" naming convention.
All 74 extended IUPAC codes are converted to the first matching alphabetical base pair as recommended in the VCF 4.3 specification.
This release of the genome reference is named GRCh38_Verily_v1.

I just read this as "GCA_000001405.15_GRCh38_no_alt_plus_hs38d1_analysis_set.fna.gz" is the 'vanilla' genome before Verily did anything to it. But yeah, the README makes things less clear....