EOF During Large File Download

We are running an "Artifactory Generic Download" Task from our Azure Pipelines to download and deploy the artifacts uploaded by the developers. While the other smaller files (i.e. file size less than 500 MB) get downloaded with no issue, there are some huge exe files (1GB-4GB in size) for which we are getting an unexpected EOF error during download.
Generally it has to do something with the network connection, but it work in both ways(upload and download). However, when I checked back with the developers they told they did not face any such issues while uploading those big files using the Same Azure pipeline agent which we are using.
I found a similar issue in #232 but it got no confirmation whether the issue is resolved or not.
 Notice the attempt 1, 2 and 3 in the log you shared.
You can try increasing the retries value and see if this resolves the issue. This does look like a symptom of an unstable network, and the retries functionality is there to help in such cases. We plan to add the retries option to the Artifactory Generic Upload and Artifactory Generic Download tasks in Azure DevOps.

I am experiencing the same issue. I have a large artifact ~4GB where I am encountering this issue. It could be a network issue but I am not facing the same issue when using curl. I could increase the retries but just from the current retries I can estimate that the download time would then increase dramatically if it would finally work. I am running jfrog version 1.33.2.

I will have to switch to curl for now but I would prefer to use jfrog cli. If you need additional information please let me know and I will try and supply them.
Here is my jfrog cli command that I am using

 ./jfrog rt dl --user=${USER} --access-token=${TOKEN} --url=${URL} --sort-by=created --sort-order=desc --limit=1 --fail-no-op --retries=6 --flat ${REPO_PATH} ${FILE}

and this is my curl commands

TARGET_URL=$(curl -s -u "${USER}:${TOKEN}" -X GET "$URL/api/storage/$REPO_PATH?lastModified" | jq -r '.uri')
DOWNLOAD_URL=$(curl -s -u "${USER}:${TOKEN}" -X GET "$TARGET_URL" | jq -r '.downloadUri')
curl -u "${USER}:${TOKEN}" -s "$DOWNLOAD_URL" --output ${FILE}

@manszigher,
The retries mechanism works on each split of the downloaded file separately. By default, JFrog CLI splits a downloaded file into 3 parts. You can increase the split count (say to 15), using the --split-count flag. This way, if a retry is needed, a smaller portion of the file will be downloaded again. If the root cause is indeed network issues, JFro CLI and cUrl should be affected the same way. I am therefore curious as for the root cause.
Do share with us any troubleshooting or additional information you may have. Helping us improve JFrog CLI is greatly appreciated!

@eyalbe4 I can try the --split-count flag if you like. The file that I am trying to download is 4.18GB all my other files is ~2GB and bellow and I am not facing any issues when downloading dose using the jfrog cli. I have installed jfrog using "curl -fL https://getcli.jfrog.io | sh"

file jfrog
jfrog: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, Go BuildID=nGJ30Y7djR9IiYTUhSBS/STNEVm3XMKJ1m_TlAg-U/QkPgqkjhvXoCp8RnyE0W/9isJNE5A1twl4l_zsOUe, not stripped

@eyalbe4 Using --split-count=15 solves the issue for me.

@eyalbe4 it will fail as long as I am using --split-count < 5. I will use --split-count=15 it appears as if that improves the download time also.

real    1m24.312s
user    0m28.291s
sys     0m46.170s

while for --split-count=5

real    3m32.268s
user    0m29.839s
sys     0m44.808s

@manszigher - I'm happy to this resolves the issue!
Yeah - the improved download time is expected, because different chunks of the same file are downloaded in parallel.


Create CODE_OF_CONDUCT.md

Looking at the project settings, I noticed a 'community' link and explored that. This seems like a good addition. Not sure of the contact email is the one we want to use.

@mariochampion can you please review the wording of this. It came from a GitHub example. Please check that the email address mentioned is correct.


Fork module does not work as expected

Hi, I forked the repository following the instructions. When I run the following everything works and I can use the latent space for clustering etc.
adata = scvi.data.pbmc_dataset()
sc.pp.highly_variable_genes(adata, flavor='seurat_v3', n_top_genes=2000, batch_key='batch', subset=True)
scvi.model.SCVI.setup_anndata(adata, copy=True, batch_key='batch')
model = scvi.model.SCVI(adata, gene_likelihood='nb')
model.train()
model.save('model/', overwrite=True, save_anndata=True)
adata.write('adata.h5ad')
However when I run SOLO
solo_batch_1 = scvi.external.SOLO.from_scvi_model(model, restrict_to_batch=0)
solo_batch_1.train()
it fails with the following error
RuntimeError: Early stopping conditioned on metric validation_loss which is not available. Pass in or modify your EarlyStopping callback to use any of the following: train_loss, train_loss_step, train_loss_epoch
I then checked the model directory from scvi and there is only the model.pi file.
Maybe you can help me jumping over that hurdle - many thanks!
Florian

Hi Adam, many thanks! I run the colab and realized that I set copy=True in setup_anndata without catching the output. With the standard installation that leads to a error when training the model but not the forked version. When copy=False both version work perfectly.

We test all the latest code, so this would have appeared on our side. I think the issue is the pytorch lightning version, you should ensure it's between 1.5 and 1.6


Change audio requests to per-sentence

Many voices struggle on longer sequences, so I should send my paragraphs per sentence for highest quality, or 1-3 sentences.

Added, long sequences were reducing to ROBO voice for some voices, not good.


Update eventClient.c

This is C++ code, not C Code

and some function are not supported on my GTProxy


Please separate user and developer instructions

I think that with the introduction of Hatch its no longer clear if the instructions are for users or for developer contributors.
I would suggest moving the developer instructions a separate DEVELOPER_GUIDE.md file. And then focusing the README.md and docs/index.md file on users.
Then there is a clear seperation.

This has now been solved


Clarification on the capabilities of shareVia() on iOS and Android

Hi Eddy,
First off, thanks a ton for the work you've put into the plugin.
I was hoping to get a better understanding of what is currently capable with the shareVia() function on iOS and Android, and what limitations exist due to the OS.
Facebook
iOS appName: com.apple.social.facebook
Android appName: com.facebook.katana
-Info.plist: <string>fb</string>
Result: Works on both.  It's a beautfiul thing!
Twitter
iOS appName: com.apple.social.twitter,
Android appName: com.twitter.android
-Info.plist: <string>twitter</string>
Result: Works on both.
LinkedIn
iOS appName option 1: com.apple.social.linkedin (Promise rejects with "not available".  I have confirmed that the app is installed).
iOS appName option 2: com.linkedin.LinkedIn (Promise rejects with "not available".  I have confirmed that the app is installed).
Android appName: com.linkedin.android
-Info.plist: <string>linkedin</string>
Result: Works on Android.  On iOS, neither of the above appName options work, and  Looking at this thread it appears that it is not possible to use shareVia() with LinkedIn.  Is that still correct?
WhatsApp
iOS appName option 1: com.apple.social.whatsapp (Promise rejects with "not available".  I have confirmed that the app is installed).
iOS appName option 2: net.whatsapp.WhatsApp (Promise rejects with "not available".  I have confirmed that the app is installed).
Android appName: com.whatsapp
-Info.plist: <string>whatsapp</string>
Result: Good to go on Android, but again no luck on iOS.  Is it possible to use shareVia() with whatsapp on iOS.  We could change to use the shareViaWhatsApp() function, but it seems like if shareViaWhatsApp() can work than shareVia() should in theory be able to work.
Messenger
iOS appName option 1: com.apple.social.messenger
iOS appName option 2: com.facebook.Messenger
Android appName: com.linkedin.android
-Info.plist: <string>fb</string>
Result: Works on Android.  No luck on iOS.
I'd love to get some clarification on whether or not there is an issue with my usage of the plugin, or if the plugin has limitations that I could work on in a PR.
Thanks!

@ChrisHuntCal  is there a way to know the exact appName of an App that is needed by this plugin? No document and I was  in a confused.
For ex,
this app: https://itunes.apple.com/tw/app/line/id443904275?mt=8
can you tell me this app's appname I should used?
Actually, in Android, it runs well using name: 'line', However, no luck in iOS.


Add Bitcoin Core #15761

Should mentions of HD or multi-wallets be expanded to topics?

Good description, I especially appreciate the links to the historical documentation!  I think a topic for BIP32 would be appropriate, so I added it to the wishlist.  I'm not so sure about multiwallet mode; that seems to be more of a feature specific to a certain wallet rather than a protocol feature or interoperability tool like most of our topics.
Thanks!


Bump deps

Part of #797
Running this since a few weeks without problems.

Okay I fixed the lint error caused by mixed support libs by migrating to AndroidX (which should be done anyway).
Will run this over the next few days, probably upgrade them further to their latest release (1.0.2) and report back.

Thanks a lot. I'll check it out and give it a try.

Great! PR should now be in its final state.
androidx.annotation 1.0.2 is not relevant for opentasks and test_runner strictly depends on 1.0.0, so it cannot be upgraded yet.

Thanks for merging!
Was about to report the same, I didn't run into issues with this branch as well.


Fix Exit Account Creation Logic

this adds an additional check to verify that we are not in the /index root which was the route used after deleting an account.
The flow is intact during account creation and adding an account with the dropdown

Codecov Report
Patch and project coverage have no change.

Comparison is base (42b101c) 39.97% compared to head (63e617f) 39.97%.
Report is 1 commits behind head on main.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main     #719   +/-   ##
=======================================
  Coverage   39.97%   39.97%
=======================================
  Files          20       20
  Lines        1486     1486
=======================================
  Hits          594      594
  Misses        828      828
  Partials       64       64

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

We will merge this one after release v0.2.6


testnet stamps have batchTTL = -1

Context
1.8.2 and 1.9.0 rc3
Summary
Stamps located in the testnet are reporting a batchTTL of -1.
Expected behavior
I would expect the stamp to have a positive TTL.
Actual behavior
    {
      "batchID": "84529f9ac63b0030a60519dc74eca9ef23096f28110f3c8e836dcd7a8381789b",
      "utilization": 10,
      "usable": true,
      "label": "OSM-0-8",
      "depth": 25,
      "amount": "100000000",
      "bucketDepth": 16,
      "blockNumber": 7712510,
      "immutableFlag": false,
      "exists": true,
      "batchTTL": -1,
      "expired": false
    }

Steps to reproduce
Create a stamp, wait for it to exist and become usable, and the batchTTL will be -1.
Possible solution
I have tracked this down in the source code to a zero currentPrice coming from the blockchain.  When will a storage price be set on the testnet?  It is important that this be published so that stamp owners can top-up as necessary to keep their data alive as we enter the storage compensation testing phase.
{
  "chainTip": 7718030,
  "block": 7718025,
  "totalAmount": "0",
  "currentPrice": "0"
}

Setting a non-zero price on the price oracle resolves this, thanks.


Rename immutable context managers to *Context

Specifuically RunnerContextManager and BundleContextManager are what we need to improve.

Also, make RunnerContextManager fully immutable (will also help to persist it with ray.put) to avoid the cost of passing it around ever and over.

let me c if i can start looking into this issue. @pabloem can you later give some help here if I take this item?

I think it's fine if @flyingImer picks this up ? : )

@pabloem not sure I follow the RunnerContextManager one - not seeing any reference in the code base, am I missing anything here?


completely rewriting the application

Adding:

explicit rewrites for package urls
parser from go

Initially I have modified vgo2nix to be able to package fresh bingo(language server protocol agent for go) because it uses git.apache.org/thrift.git and vgo2nix started to ask for a password(because .git was droped and nix-prefetch-git thinked it should use SSH to pull the repo).
But this was two months ago. After that I have packaged a lot of other software and have some pain with go pseudo versions. After that I have found internal implementation which go tools use and adopted it(internal packages can not be imported).
Also I have checked today, this fixed https://github.com/adisbladis/vgo2nix/issues/16

To c4609f4e3ee0fd010d80c471f6a67c56c2279ead: test_reporoot/go.mod declares two packages, so I have decided to fix the expected test result.

@corpix I have tried the rewritten version of yours. The usability of the rewritten vgo2nix is not so good because prefetchModule is a blocking process and dependencies are being downloaded sequentially instead of in parallel.

Oh, yeah, it is not good at parallel fetching at the moment. I think I'll fix this soon

I'd like to incorporate some of these changes but a massive rewrite PR is not helpful.
Please do smaller incremental pull requests that can be reviewed on their own merit.

Not sure I'll have enough time to do this, but anyway, feel free to incorporate any changes without listing me as contributor


Document recovery from broken kubelet certificate

Document kubelet client certificate recovery:

Make more apparent the fact that kubeadm certs doesn't handle kubelet cert
Add steps to troubleshoot failed kubelet certificate renewall

Fixes https://github.com/kubernetes/kubeadm/issues/2502

/check-cla @k8s-ci-robot

/retitle Document recovery from broken kubelet certificate kubernetes/kubeadm#2502

/cc @neolit123

/sig cluster-lifecycle

you can add fixes https://github.com/kubernetes/kubeadm/issues/2502 in the PR description to close that issue.

thanks for working on this @antoinep92
/lgtm
/assign @savitharaghunathan
for sig-docs review / approval.

one last request @antoinep92 can you please squash the commits into a single one?

one last request @antoinep92 can you please squash the commits into a single one?
(removing my authorship is fine).

Done. Had to force push which confused github a bit but there is no diff
Thanks for your help for getting this into shape

/retitle Document recovery from broken kubelet certificate

/lgtm
/approve


[imageresizer] Resample types for image sizes

Description of the new feature / enhancement
Add a resample option for image sizes. Example resample types; auto, nearest, box, bilinear, hamming, bicubic, lanczo.
or a simpler, user-friendly type would be; auto, crisp-edges, pixelated.
source:

https://pillow.readthedocs.io/en/stable/handbook/concepts.html#filters
https://developer.mozilla.org/en-US/docs/Web/CSS/image-rendering

Scenario when this would be used?
Currently, smaller "pixelated" images become blurry when resizing them. Using "nearest" or "pixelated" would correctly resize the image without making it blurry
Supporting information
No response

/dup https://github.com/microsoft/PowerToys/issues/8790


Add note about the info object having a different shape

Why?
The on_raise documentation notes the info Hash that's passed in but doesn't explain that the shape of that hash is different when using process vs process_batch.
How?
Adds a note to the README explaining that differences exist and where to find the shape of that Hash in the code.

Thanks!


Create increment and decrement operations to change the value of a digit range

RFC, please.
This allows positive overflow but not underflow. It uses the selection range or the largest digit segment around the cursor.
Incrementing each digit separately is supported with a flag.

Bug-fixes to be added.


Improve documentation

Close in favor of the other PRs. Thanks for the split. It was really helpful.


feat(mat-tab-nav-bar): router-outlet transition animation like mat-tab-group

Feature Description
When enableing tab navigation, I have to use mat-tab-nav-bar instead of mat-tab-group. Works great, but removes the transition animation between the tabs (sliding left / right).
There are some other related issues about it: #15570, #18169
I cannot accept the answer that I should use mat-tab-group instead. The reason using mat-tab-nav-bar is the tab navigation over URL, etc. Or do you generally not recommend this? If yes why?
The workaround in the other solution works. But I wonder, why not just implement this this framework? Since the mat-tab-group already has this animation. What is the reason for refusing such a legitimate request?
I don't like to write code / workaround for stuff that should actually be part of the framework. Custom data with index for the animation, etc.
No offense, I was just wondering what the problem is. Together we could think about an elegant solution. Maybe a directive for the router-outlet container? But how to detect left and right sliding? (See workaround #18169)
Use Case
Just be consistent to mat-tab-group. Why not? Why should we regret implementing tab navigation using mat-tab-nav-bar. Which is an awesome feature? Just complete the implementation by adding the same animation like in mat-tab-group.

We can't implement this, because we don't know what element your content will be rendered into. There's a recent PR (https://github.com/angular/components/pull/24062) to add a component that wraps the router outlet which could allow us to implement the animation.


Publish custom module definitions

We have written several custom module definitions (hypercore, random-access-storage etc) here, but we use them in a few different modules (e.g. multi-core-indexer).
Ideally we publish these all to DefinitelyTyped, however that is time consuming and probably requires the types to be more complete.
For our internal use I think it would be useful to publish these types to an npm package for our own internal use. We could call this @mapeo/external-types and then include it in modules that use it (like this one) via the "typeRoots": ["./node_modules/@mapeo/external-types"] in tsconfig.json.
Note that the behaviour is slightly different from how ./node_modules/@types works: typeRoots will not be used in module resolution to look up types, only for including types in the global scope, so we need to continue to wrap all our declarations in declare module "module-name" (which is not necessary for types published to @types).
Proposal summary: extract module definitions from ./types in this repo and move them into a separate npm module @mapeo/external-types, as a temporary measure until we feel ready to either publish to DefinitelyTyped, or contribute types to upstream modules.
@achou11

related to https://github.com/digidem/digidem-types?

Closed via #125


Fixed frame bugfixes

This PR contains mostly bugfixes w.r.t how the obstime is handled in the transform_to call and allowing vectorized coordinate inputs by using astropy routines. This also speeds up the conversion significately since the ERFA routines are quite fast.

I've added a separate commit to this PR removing the rotate and transform function from util since the rotation functions in astropy are much faster & provide vectorized input support.
There are no users within poliastro left for these functions, but this is a change in the API which is not backwards compatible so you might want to cherry-pick this commit later for a major release.

Amazing that the astropy functions are faster! Good that we also gained vectorization in the transition :)
We don't have to worry about that breaking change. Could you please rebase on current master so we can merge straight away?

Rebased & pushed.

Merging, thanks a lot!


Min width of content based on control width

Hi! First of all thanks for this package. I think it's the best package for popovers. It has the only generic logic of positioning and this is great. I'm using it in Tooltips, Dropdown, Selects, Datepickers and other components.
For example, I've found a way to use it in new react-select v2. If you are interesting I can share a code.
In some interfaces I need to control the width of content depends on target element size. e.g. min-width of menu list in select has to be not thinner than control width.
do you have an idea how it can be done with tiny popover?

Thanks for your kind words! Indeed, I am interested in how you’re using the popover with react-select. I’d love to see your code, if that’s cool.
Can you clarify what you mean about width? One suggestion I have is perhaps the Autosize component from the react-virtualized library, which you’d use as a parent that will inject width and height into its child. But I’m still not quite sure I understand your question fully.
Best,
Alex

On Aug 21, 2018, at 16:26, Alexey Bondarenko<EMAIL_ADDRESS>wrote:
Hi! First of all thanks for this package. I think it's the best package for popovers. It has the only generic logic of positioning and this is great. I'm using it in Tooltips, Dropdown, Selects, Datepickers and other components.
For example, I've found a way to use it in new react-select v2. If you are interesting I can share a code.
In some interfaces I need to control the width of content depends on target element size. e.g. min-width of menu list in select has to be not thinner than control width.
do you have an idea how it can be done with tiny popover?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Hi, Alex! It works fine with react-select, and I've already found an answer to my question) I will show you a code. It's not ideal, looks like a hack, but it allows us to fix the bug with scroll and other bugs of react-select.
It's the customization of SelectContainer component. Also you can that I'm controling the size of menu for bottom, top positioning.
import React from 'react';
import { components } from 'react-select';
import { compose, setDisplayName } from 'recompose';

import Popover from '@/components/Popover';

const isMenuChild = index => index === 2;
const SelectContainer = ({ children, ...rest }) => {
  const menu = children.filter((child, index) => isMenuChild(index));
  const restChildren = children.filter((child, index) => !isMenuChild(index));
  return (
    <Popover
      position={['bottom', 'top']}
      align={'left'}
      isOpen={rest.selectProps.menuIsOpen}
      onClickOutside={rest.selectProps.onBlur}
      content={({ position, targetRect }) => {
        const style = {};
        if (['top', 'bottom'].indexOf(position) > -1) {
          style.width = `${targetRect.width}px`;
        }

        return (
          <div style={style}>
            { menu }
          </div>
        );
      }}
    >
      <components.SelectContainer {...rest}>
        {restChildren}
      </components.SelectContainer>
    </Popover>
  );
};

export default compose(setDisplayName('SelectContainer'))(SelectContainer);

For this case, it would be nice to disable right and left positioning of the popover. But anyway, now it also works fine)


about checkpoint

Thanks for your wonderful work
I want to know why the checkpoint is not saved when I only use the CEloss, I read the code but did not find where should be modify.

Hello, sorry for the late reply and thanks for your interest in our work!
Yes, I do need to clean this up at some point (the saving is a legacy from the ARPL code). However, all models should be saved with path format:
/work/sagar/open_set_recognition/methods/ARPL/log/{EXP_ID}/arpl_models/{DATASET}/checkpoints/{DATASET}_{EPOCH}_{LOSS}.pth
Also, 'CELoss' is known as 'Softmax' in this code. Let me know if this helps!

hello, thanks for your reply
but when I check the saved checkpoint, The file size is only 3.9M, why is this happening?

hello, thanks for your reply
but when I check the saved checkpoint, The file size is only 3.9M, why is this happening?

This should be because the model is very small (e.g VGG32, roughly 1M parameters)


Address signature test issues from issue 681

fixes #681

We also need to update the deployment to package the new signature test plugin.
https://github.com/jakartaee/data/blob/352d6366a6b071d521c244fb75a34670ce3f2fba/tck/src/main/java/ee/jakarta/tck/data/framework/arquillian/extensions/TCKArchiveProcessor.java#L95
@starksm64 I can open a different PR to do this work, or if you are able to test core profile you can update this PR. Let me know.

I add that change in the last commit

I think this broke the build, maybe because we still have stuff like <sigtest.version>1.6</sigtest.version> in some places.


[Snyk] Upgrade @oclif/plugin-plugins from 2.3.2 to 2.4.0

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to upgrade @oclif/plugin-plugins from 2.3.2 to 2.4.0.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 1 version ahead of your current version.
The recommended version was released 21 days ago, on 2023-03-08.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:
🧐 View latest project report
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

already past this


Request Cancel{model: ArrayObject} is not supported

These are works good for offline
$gateway->execute($status = new Capture($token));
$gateway->execute($status = new Authorize($token));
$gateway->execute($status = new GetHumanStatus($token));
But Cancel doesn't work.
$gateway->execute($status = new Cancel($token));
Request Cancel{model: ArrayObject} is not supported. Make sure the gateway supports the requests and there is an action which supports this request (The method returns true). There may be a bug, so look for a related issue on the issue tracker.
Is it a bug? Or Isn't there any Cancel Request for Offline?
Can you tell me the list of requests that I can use for offline?
like
$gateway->execute($currency = new GetCurrency('TRY'));
$gateway->execute($status = new Capture($token));
$gateway->execute($status = new Authorize($token));
$gateway->execute($status = new GetHumanStatus($token));
etc etc

The offline gateways does not support it (could be added though).

Can you tell me the list of requests that I can use for offline?

No I cannot tell you, look at the code.


feat: add /peers API endpoint to torii

Context
Ever since #5117 clients have lost the ability to find about other nodes in the network except for the node they are connecting to. This is because FindPeers doesn't return address anymore, just peers's public key. We can't return data that is not on chain in this query so I've implemented another torii endpoint
Solution

add new torii endpoint /peers

Alternatives
I see that we have /status and /metrics. I'm not sure why we have both since, from what I can see, /status is a superset of `/metrics. Considering this, I can make it so that peers are returned on one of those endpoints instead of adding a new point. I implemented this functionality on a separate endpoint because:

there can be lots of peers returned and we may want to batch this response
we don't want the client to pay the price of retrieving this long list of peers if they are interested in simple metrics

I see that we have /status and /metrics. I'm not sure why we have both since, from what I can see, /status is a superset of `/metrics. Considering this, I can make it so that peers are returned on one of those endpoints instead of adding a new point. I implemented this functionality on a separate endpoint because:
1. there can be lots of peers returned and we may want to batch this response

2. we don't want the client to pay the price of retrieving this long list of peers if they are interested in simple metric

Well, in fact, the /status endpoint already supports selective retrieval (see sub-routing in the reference), i.e. GET /status/peers "just works" already. I would say introducing a new route is not as nice as reusing the current one.
What do you think?

I see that we have /status and /metrics. I'm not sure why we have both since, from what I can see, /status is a superset of `/metrics. Considering this, I can make it so that peers are returned on one of those endpoints instead of adding a new point. I implemented this functionality on a separate endpoint because:
1. there can be lots of peers returned and we may want to batch this response

2. we don't want the client to pay the price of retrieving this long list of peers if they are interested in simple metric

Well, in fact, the /status endpoint already supports selective retrieval (see sub-routing in the reference), i.e. GET /status/peers "just works" already. I would say introducing a new route is not as nice as reusing the current one.
What do you think?

I noticed this. While I agree that introducing a new endpoint is not as nice, my thinking was that /status should have a short response so I didn't want to add peers there which could be a long list with a few thousand entries there. Maybe you can give some more thoughts on it?

I noticed this. While I agree that introducing a new endpoint is not as nice, my thinking was that /status should have a short response so I didn't want to add peers there which could be a long list with a few thousand entries there. Maybe you can give some more thoughts on it?

Mmm, I think we could advise users to use sub-routing at all times.  Still, even thousands of pubkey strings isn't that enormous, and happens in big production environments. If someone works with a really huge network, they would be probably knowledgeable of sub-routing feature.
In addition, it could be useful to not just add { peers: PeerId[] } field, but add a count to it: { peers: { count: 1234, list: [ ... ] } }, accessible by /status/peers/count. That could be useful for those uninterested in the exact identifiers, but only in the count of them.

I noticed this. While I agree that introducing a new endpoint is not as nice, my thinking was that /status should have a short response so I didn't want to add peers there which could be a long list with a few thousand entries there. Maybe you can give some more thoughts on it?

Mmm, I think we could advise users to use sub-routing at all times.  Still, even thousands of pubkey strings isn't that enormous, and happens in big production environments. If someone works with a really huge network, they would be probably knowledgeable of sub-routing feature.
In addition, it could be useful to not just add { peers: PeerId[] } field, but add a count to it: { peers: { count: 1234, list: [ ... ] } }, accessible by /status/peers/count. That could be useful for those uninterested in the exact identifiers, but only in the count of them.

May I then suggest that /status keeps returning brief info as before. And /status/peers returns full info?

Code-wise - looking good.

May I then suggest that /status keeps returning brief info as before. And /status/peers returns full info?

How about /status?include=peers? This would leave a door open for adding other potentially large fields.


Crash on game startup

When paired with Sodium 0.4.11+build.26, the game crashes on startup. Crash log: https://mclo.gs/21qM6Wq
This issue has already been posted on Sodium's bug tracker, but they said it needed to be fixed here instead.
https://github.com/CaffeineMC/sodium-fabric/issues/1723

I heard that Sodium 0.4.11 was (intentionally) removed for downloads, especially from Modrinth. Simply No Shading wouldn't be able or would support Sodium 0.4.11 (yet) due to this. Also, sodium-fabric#1746 stated that 0.4.11 was removed due to some (or maybe more issues), hence why it won't be supported (yet).
TLDR
Sodium 0.4.11 is not available now (or yet), try using 0.4.10 and come back if you found more issues.


[Toolbar] Port component

[ ] Component
[ ] Tests (at least unit tests)
[ ] Docs
[ ] Demo

Started on this, needs completing

Just reviewing status of ported components. Is this not done? https://github.com/callemall/material-ui/tree/v1-beta/src/Toolbar

@skirunman We need to make sure everything is fine. I haven't found the time to look into it.

Thanks, just tracking what we need before we can upgrade to 1.x.

I believe this concern has already been solved with v1. The Toolbar component is really simple. But we haven't seen any problem with the approach over the last 6 months.


Bug: ansi-regex is vulnerable to Inefficient Regular Expression Complexity

Current behavior
The code pipeline runs npm audit and throws the aforementioned error and prevents me from proceeding further to deploy on ECS. The current child dependency is 4.1.0 but the expected patched version is 6.0.1 || 5.0.1
Even though the vulnerability is low, the security team may not agree to budge on it.
Expected behavior
It would be great if the library can patch child dependencies viz. ora, replace-in-file
Minimal reproduction of the problem with instructions
Run npm audit on<EMAIL_ADDRESS>Environment
- Transloco version: 2.23.3
- Angular version: 12.2.3

### Contribution
I would like to make a pull request for this feature:
[ ] Yes! 🚀
[x] Maybe next time

@madhurahuja There is a major upgrade about to release the upgrades all of these, will be fixed in v3

@madhurahuja There is a major upgrade about to release the upgrades all of these, will be fixed in v3

Thank you for your response @shaharkazaz is there a tentative time when v3 release is planned?

@madhurahuja When I get the chance to release it 🙂  no estimated date, hopefully soon, it's 97% done.

@shaharkazaz Good to hear! Thank you much :)

@madhurahuja released v3, LMK if that works for you 😄

Thank you so much for so quick turnaround 👍 Let me check and get back to you!

Would it be possible to resolve this vulnerability as a minor patch for 2.x also? V3 appears to depend on Angular 12, but Angular 10 and 11 are still in LTS so this will catch a lot of people out who haven't yet had a chance to upgrade (my team included!)

@CameronJThomas You are welcome to open a PR to the v2 branch 🙂

Thanks! Have raised a PR per above 😄

@CameronJThomas Try<EMAIL_ADDRESS>

Thanks for the quick turnaround! I can confirm this is now passing audit so this issue can be closed 🙂


Add tooltip for long names in the settings page of workspace chat

Details

Fixed Issues

$ https://github.com/Expensify/App/issues/29130
PROPOSAL: https://github.com/Expensify/App/issues/29130#issuecomment-1753949914
Tests

[X] Verify that no errors appear in the JS console

Open the app on Web or Desktop
Open any long name workspace request money report or raise one and open
Click on header to open details page
Hover on 3 dots and observe that it displays complete workspace report name in tooltip
Click on settings
Hover on 3 dots in Name and observe that now the tooltip is displayed

Offline tests

Open the app on Web or Desktop
Open any long name workspace request money report or raise one and open
Click on header to open details page
Hover on 3 dots and observe that it displays complete workspace report name in tooltip
Click on settings
Hover on 3 dots in Name and observe that now the tooltip is displayed

QA Steps

[x] Verify that no errors appear in the JS console

Open the app on Web or Desktop
Open any long name workspace request money report or raise one and open
Click on header to open details page
Hover on 3 dots and observe that it displays complete workspace report name in tooltip
Click on settings
Hover on 3 dots in Name and observe that now the tooltip is displayed

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] If we are not using the full Onyx data that we loaded, I've added the proper selector in order to ensure the component only re-renders when the data it is using changes
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Web
https://github.com/Expensify/App/assets/59809993/7eaf1774-14fa-4ab3-a3a6-fc9297eac4b3

Desktop
https://github.com/Expensify/App/assets/59809993/5ac1e226-80fd-4f85-9980-efa9b96e3ba9

Mobile Web - Chrome

Mobile Web - Safari

iOS

Android

I didnt add the screenshots of mobile versions cause there is no tooltip in mobile and the issue affects only the web and the desktop apps

I see .. thanks @hoangzinh will cover them

@hoangzinh updated .. please let me know if any other change is needed

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/roryabraham in version: 1.3.88-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/chiragsalian in version: 1.3.88-11 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅


How to collect data for a specific jira project ?

closing due to inactivity, please reopen is this is still happening.


validation error for simplified repetition

A validation error occurs when a simplified repetition includes a continue. This might be due to the fact that the <instruction> inside the <continue> are not of the same <length> as required by the <simplify>true<simplify> element. An example can be found in this file:
JasiMasters2024021301.xml
The error message is:
Assertion evaluation ('                 ((./sw:simplify = true()) and (every $length in .//sw:length                     satisfies $length/*[1] = (.//sw:length)[1]/*[1])) or ./sw:simplify = false() or count(./sw:simplify) = 0') for element 'repetition' on schema type 'repetitionType' did not succeed.

When I compile with 2.0 the total length is incorrect. It is not 4000m

When I compile with 2.1, the total length is still wrong, but also the lengths are missing.

When I try to compile the JasiMasters2024025001.py file, I get the error:
Exception: Cannot simplify continue with repetitions of different lengths

just a note for JasiMasters2024022001.html
4000m is the correct total length as the 3x200 set is denoted as 3 x 3 x 200 as its still a repetition and you would be repeating 3 200s 3 times, if you wanted just the one set then you should leave the repetition count empty or not include it

<RepetitionCount> is a required element for a repetition in the XSD schema. If I set <simplify> to true I get the correct total distance calculation (2800), but the repetition is shown as 6x100, not 3x200 as it should be. Have a look at the JPEG. It shows what was intended. 3x200 in which each 200 is broken into 2x100 (continue). How can this be modelled?

this issue should be fixed in the python
not 100% sure about the xsd but it was working when last checked

tested and okay. Great job!


refactor: generic symbol graph

Example update in deno_doc: https://github.com/denoland/deno_doc/pull/387
Closes https://github.com/denoland/deno_graph/issues/316

@bartlomieju it no longer does "tracing" so it doesn't figure that out. The is_public is not used in deno_doc as it figures it out itself.


[stable/ghost] Update deployment apiVersion to 'apps/v1' - Mandatory for K8s 1.16

Signed-off-by: juan131<EMAIL_ADDRESS>What this PR does / why we need it:
There are several deprecations in the API introduced in K8s 1.16 (see https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.16.md#deprecations-and-removals) which affect our manifests. The following APIs are no longer served by default:

All resources under apps/v1beta1 and apps/v1beta2 - use apps/v1 instead
daemonsets, deployments, replicasets resources under extensions/v1beta1 - use apps/v1 instead
networkpolicies resources under extensions/v1beta1 - use networking.k8s.io/v1 instead
podsecuritypolicies resources under extensions/v1beta1 - use policy/v1beta1 instead

This PR address the changes to be done for stable/ghost.
Checklist

[x] DCO signed
[x] Chart Version bumped
[x] Title of the PR starts with chart name (e.g. [stable/chart])

/ok-to-test
/lgtm


Add support for transformers-0.5 release

somewhat related: ekmett/transformers-compat#11

:+1: , I can't use mtl in my plugins anymore because of this.

It seems like this is resolved.

Can we have a Hackage upload please?

@ekmett This is blocking a lot of packages from being tested with GHC 8.0 snapshots. And as it seems to be that in fact an upper-bound-relaxation is all that's needed, I've relaxed the upper bound on transformers for the existing mtl release: https://hackage.haskell.org/package/mtl-2.2.1/revisions/ -- if this is incorrect, please let me know

@hvr thanks

As a note, mtl still needs to have its bounds updated so that cabal-install can be bootstrapped with ghc 8.0, the hackage release still has ==0.4.* in its cabal bounds. Perhaps release an mtl candidate like cabal/cabal-install have so that bootstrap with ghc 8.0 can occur?
Registering Cabal-<IP_ADDRESS>...

Downloading mtl-2.2.1...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 15391  100 15391    0     0  20845      0 --:--:-- --:--:-- --:--:-- 67209
[1 of 1] Compiling Main             ( Setup.hs, Setup.o )
Linking Setup ...
Configuring mtl-2.2.1...
Setup: Encountered missing dependencies:
transformers ==0.4.*

Error during cabal-install bootstrap:
Configuring the mtl package failed.

@mitchty I'm confused... we edited https://hackage.haskell.org/package/mtl-2.2.1/revisions/ long ago... why doesn't that work for you?

@hvr the cabal file on hackage which the bootstrap.sh script uses has the bound of ==0.4.* aka, this isn't going through cabal-install but bootstrapping cabal-install from scratch.
So once Setup.hs is run with the mtl.cabal with the old bounds bootstrap.sh fails.
And as a note this is to test out building cabal-install on a new architecture so not having an existing cabal is something I can't workaround as easily. >.<
I can just patch the bootstrap.sh script with an updated mtl package with the cabal file bounds relaxed like on hackage.

@mitchty if you look at https://github.com/haskell/cabal/blob/1.24/cabal-install/bootstrap.sh#L268-L298 the bootstrap script fetches the revised mtl.cabal file...

That doesn't seem to be in the package in hackage however:
$ curl -L "https://hackage.haskell.org/package/mtl-2.2.1/mtl-2.2.1.tar.gz" | gzcat | tar xf - mtl-2.2.1/mtl.cabal
$ grep transformers mtl-2.2.1/mtl.cabal
  build-depends: base < 6, transformers == 0.4.*

Think I see the issue, ignore my comments. Thanks @hvr!

There seems to be an inconsistency in the Hackage database between the following two files:

hackage.haskell.org/package/mtl-2.2.1/mtl.cabal
hackage.haskell.org/package/mtl-2.2.1/src/mtl.cabal

The first of these links is what you get when you click on 'package description': it contains the bound transformers >= 0.4 && < 0.6. The second is what you get when you actually download the package source: it contains the bound transformers == 0.4.*.
Is this a glitch - I assume these two files should be be the same?

@robjhen not a glitch, but rather the way .cabal-revisions work, c.f. http://hackage.haskell.org/package/mtl-2.2.1/revisions/

I believe this has been resolved, so closing.


Improved Theme selector that outlines the current theme

I have used your project for my personal use cases and spend some time to improve upon then theme selector. The changes are as follows:
The current theme is now shown with an outline
Added a fill to the theme svg. This is done because there would be cases where text could be seen through the icon at medium screen sized
Cleaned up code by mapping over all the themes instead of hard coding each one


runtime: can not read stacktrace from a core file

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
This problem was introduced by b1d1ec9 (CL 110065) and is still present at tip.
Does this issue reproduce with the latest release?
No.
What operating system and processor architecture are you using (go env)?
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/a/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/a/n/go/"
GORACE=""
GOROOT="/usr/local/go-tip"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go-tip/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build495464568=/tmp/go-build -gno-record-gcc-switches"

What did you do?
Given:
package main

import "runtime/debug"

func main() {
	debug.SetTraceback("crash")
	crash()
}

func crash() {
	panic("panic!")
}

Running it under gdb will produce this stacktrace:
(gdb) bt
#0  0x000000000044fff4 in runtime.raise () at <autogenerated>:1
#1  0x0000000000438c2b in runtime.dieFromSignal (sig=6) at /usr/local/go-tip/src/runtime/signal_unix.go:424
#2  0x0000000000438dea in runtime.crash () at /usr/local/go-tip/src/runtime/signal_unix.go:526
#3  0x0000000000426487 in runtime.fatalpanic (msgs=<optimized out>) at /usr/local/go-tip/src/runtime/panic.go:696
#4  0x0000000000425e6b in runtime.gopanic (e=...) at /usr/local/go-tip/src/runtime/panic.go:502
#5  0x0000000000470ac9 in main.crash () at /home/a/temp/simple.go:11
#6  0x0000000000470a7b in main.main () at /home/a/temp/simple.go:7

however letting it produce a core file then reading the core file with gdb produces this:
$ gdb ./simple simple-core
...
(gdb) bt
#0  0x000000000044fff4 in runtime.raise () at <autogenerated>:1
#1  0x0000000000438c2b in runtime.dieFromSignal (sig=6) at /usr/local/go-tip/src/runtime/signal_unix.go:424
#2  0x00000000004390a8 in runtime.sigfwdgo (ctx=0xc000009ac0, info=0xc000009bf0, sig=6, ~r3=<optimized out>) at /usr/local/go-tip/src/runtime/signal_unix.go:637
#3  0x0000000000438488 in runtime.sigtrampgo (ctx=0xc000009ac0, info=0xc000009bf0, sig=<optimized out>) at /usr/local/go-tip/src/runtime/signal_unix.go:289
#4  0x00000000004502e3 in runtime.sigtramp () at <autogenerated>:1
#5  0x00000000004503d0 in ?? () at <autogenerated>:1
#6  0x0000000000000001 in ?? ()
#7  0x0000000000000000 in ?? ()

I'm not sure what's happening here. Is the signal handler running and overwriting part of the stack?

cc @eliasnaur @aclements

So that much makes sense. Is the real complaint here that the application's stack trace doesn't appear in the core dump?

Yes. I would expect some goroutine's stack to have a frame for main.main and main.crash in it, at least.

Where are you seeing goroutine 1 that you trust? The panic backtrace shows goroutine 1, but that happens before  dieFromSignal. gdb shows 1 in info goroutines, but it combines scheduler information with thread state in a way that'll just end up showing whatever the thread's up to, not the user code that was running for goroutine 1.

Also, how does sigfwdgo call dieFromSignal?

https://github.com/golang/go/blob/28b40f3528bf1f45e68da85b1d338a89e61f91b8/src/runtime/signal_unix.go#L637
or am I missing something?
I'm probably out of my depth at this point. Hopefully Austin or Elias can weigh in.

Where are you seeing goroutine 1 that you trust?

I'm seeing it while debugging delve, the TLS for the first thread contains a pointer to the same g struct that's in the first entry of runtime.allgs. And it has goid == 1.
I was under the impression that when a thread is running on one of those special stacks the pointer to g is changed accordingly, am I wrong? Should I check if sp is inside [g.m.gsignal.stack.stackhi, g.m.gsignal.stack.stacklo]?

or am I missing something?

oh I didn't see that.

I was under the impression that when a thread is running on one of those special stacks the pointer to g is changed accordingly, am I wrong? Should I check if sp is inside [g.m.gsignal.stack.stackhi, g.m.gsignal.stack.stacklo]?

If you want to handle this case I think you have to. This area of the code is responsible for handling signals that might be caused by C code, so it can't blindly muck with Go stuff until it knows what's up. The setg call you hoped had run is here: https://github.com/golang/go/blob/28b40f3528bf1f45e68da85b1d338a89e61f91b8/src/runtime/signal_unix.go#L661
way after the dieFromSignal call on 637. sigtrampgo checks the stack pointer to decide if gsignal or g0 is running: https://github.com/golang/go/blob/28b40f3528bf1f45e68da85b1d338a89e61f91b8/src/runtime/signal_unix.go#L307-L308 so that ought to be a decent model to follow.
(I still kinda think clearing out the signal handler in dieFromSignal is reasonable.)

Ok, the thread's sp is actually inside gsignal's stack. Do you know where the sp for the normal goroutine stack is saved in this case? g.sched.sp is zero.

That's a good point. The goroutine wasn't preempted normally, so nothing in the runtime will know what its stack pointer was. The only place you could find it is the ctx argument to the signal handler (the thing we wrap a sigctxt around), and even that will be awkward to interpret in the case of a chain of signal handlers.

I still kinda think clearing out the signal handler in dieFromSignal is reasonable.

I think the concern here is if the signal needs to be forwarded. E.g., if you have some SIGABRT-trapping crash handling service installed, we want the signal to get forwarded to it. Maybe dieFromSignal could check if we're forwarding it (which we never will be in pure Go programs) and, if not, go straight to its fallback path that clears the handler and raises?
cc @ianlancetaylor @bcmills

It is not so crazy to use the signal context to figure out where a signal handler was invoked.  That is what gdb does.  The key point is to reliably determine whether you are running in a signal handler.  I think gdb does that by recognizing the signal trampoline that is on the return stack, which resumes normal execution if the signal handler returns.

The only place you could find it is the ctx argument to the signal handler (the thing we wrap a sigctxt around), and even that will be awkward to interpret in the case of a chain of signal handlers.

I don't think the chained signal handlers are a problem. We don't manipulate the context when calling down the chain.
I was thinking we might be able to stash this away in g.sched.sp when we enter the signal handler, but there's still a window between switching to the signal stack and doing there, and it's possible we can receive a signal while g.sched.sp is set to something important.

I don't think we need to do anything in dieFromSignal, I think that in crash we could clear the signal handler.  At least at first glance I'm not worried about forwarding the signal once we are calling crash.

If we don't forward the signal, we potentially bypass crash reporters (particularly on iOS and Android) and skew people's crash metrics.
But I think I'm missing something here:

the thread is on the signal handler stack when it dies, not the goroutine stack

The saved base pointer in the root frame of the signal stack should point back to the goroutine stack, right? (Do we know why the debuggers aren't following that base pointer? Am I just confused?)

Since that was sort of addressed to me, I'll say that looking with GDB I think you're right that following the base pointer chain gets you to the right stack, and that seems better than using the signal handler context. Based on Stack Overflow I guess GDB only follows the base pointers when it's out of options.

Following the base pointer will presumably only work when the base pointer is used by the code being interupted, so it will be unreliable if the signal fires while executing C code compiled with -fomit-frame-pointer.

I think gdb also won't follow a frame pointer if it points to a smaller address, to avoid walking corrupted stacks or going in cycles.
But why doesn't it unwind through the signal context? That I would expect to work here.

Maybe it's because you aren't telling it where you saved rdx on the stack?

Never mind, I see now that x86_64_fallback_frame_state always knows how to get the context. My next guess is that, if gdb's documentation is correct, x86_64_fallback_frame_state is only used when no FDE is found, which is not the case for runtime.sigreturn.
This was also the problem for delve: if I ignore runtime.sigreturn's FDE it will just follow the frame pointer and end up back on the right stack.

@aarzilli, did you want anything else here?

I'm satisfied by blacklisting runtime.sigreturn's FDE on delve's side, I've left this issue open because I suspect it would be useful to other debuggers to remove it entirely from the executable.

With https://go.dev/cl/479096, backtrace from a core looks like so:
(gdb) bt
#0  runtime.raise () at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/sys_linux_amd64.s:154
#1  0x000000000043ecc5 in runtime.dieFromSignal (sig=6) at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/signal_unix.go:879
#2  0x000000000043f1de in runtime.sigfwdgo (sig=6, info=<optimized out>, ctx=<optimized out>, ~r0=<optimized out>) at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/signal_unix.go:1092
#3  0x000000000043da45 in runtime.sigtrampgo (sig=0, info=0xffffffffffffffff, ctx=0x453981 <runtime.raise+33>) at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/signal_unix.go:432
#4  0x0000000000453c66 in runtime.sigtramp () at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/sys_linux_amd64.s:352
#5  <signal handler called>
#6  runtime.raise () at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/sys_linux_amd64.s:154
#7  0x000000000043ecc5 in runtime.dieFromSignal (sig=6) at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/signal_unix.go:879
#8  0x000000000043e787 in runtime.crash () at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/signal_unix.go:971
#9  runtime.sighandler (sig=<optimized out>, info=<optimized out>, ctxt=<optimized out>, gp=0xc0001021a0) at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/signal_unix.go:793
#10 0x000000000043dbab in runtime.sigtrampgo (sig=3, info=0xc00010b4b0, ctx=0xc00010b380) at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/signal_unix.go:479
#11 0x0000000000453c66 in runtime.sigtramp () at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/sys_linux_amd64.s:352
#12 <signal handler called>
#13 runtime.futex () at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/sys_linux_amd64.s:557
#14 0x0000000000427af0 in runtime.futexsleep (addr=0xca, val=0, ns=4538115) at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/os_linux.go:69
#15 0x00000000004087a7 in runtime.notesleep (n=0xc000100148) at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/lock_futex.go:160
#16 0x000000000043164c in runtime.mPark () at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/proc.go:2323
#17 runtime.stopm () at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/proc.go:2323
#18 0x0000000000432e3c in runtime.findRunnable (gp=<optimized out>, inheritTime=<optimized out>, tryWakeP=<optimized out>) at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/proc.go:2996
#19 0x0000000000433bd1 in runtime.schedule () at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/proc.go:3349
#20 0x000000000043016d in runtime.mstart1 () at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/proc.go:1494
#21 0x0000000000430076 in runtime.mstart0 () at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/proc.go:1444
#22 0x0000000000451d25 in runtime.mstart () at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/asm_amd64.s:394
#23 0x0000000000453faf in runtime.clone () at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/sys_linux_amd64.s:618
#24 0x0000000000000000 in ?? ()

@aarzilli based on the prior comment, I'm not sure if you expect delve to work better or not, but it (mostly?) does not.
$ dlv version
Delve Debugger
Version: 1.20.1
Build: $Id: 96e65b6c615845d42e0e31d903f6475b0e4ece6e $

Interestingly, the main thread works ok (except 2 frame 15s?):
$ dlv core example.com core
 0  0x0000000000453d01 in runtime.raise
    at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/sys_linux_amd64.s:154
 1  0x000000000043ed05 in runtime.dieFromSignal
    at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/signal_unix.go:879
 2  0x000000000043f21e in runtime.sigfwdgo
    at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/signal_unix.go:1092
 3  0x000000000043da85 in runtime.sigtrampgo
    at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/signal_unix.go:432
 4  0x0000000000453fe6 in runtime.sigtramp
    at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/sys_linux_amd64.s:352
 5  0x00000000004540e0 in runtime.sigreturn
    at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/sys_linux_amd64.s:466
 6  0x000000000043e7c7 in runtime.crash
    at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/signal_unix.go:971
 7  0x000000000043e7c7 in runtime.sighandler
    at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/signal_unix.go:793
 8  0x000000000043dbeb in runtime.sigtrampgo
    at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/signal_unix.go:479
 9  0x0000000000453fe6 in runtime.sigtramp
    at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/sys_linux_amd64.s:352
10  0x00000000004540e0 in runtime.sigreturn
    at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/sys_linux_amd64.s:466
11  0x00000000004087a7 in runtime.notesleep
    at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/lock_futex.go:160
12  0x000000000043168c in runtime.mPark
    at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/proc.go:1519
13  0x000000000043168c in runtime.stopm
    at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/proc.go:2323
14  0x0000000000432e7c in runtime.findRunnable
    at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/proc.go:2996
15  0x0000000000433c11 in runtime.schedule
15  0x0000000000433c11 in runtime.schedule
    at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/proc.go:3349
16  0x00000000004301ad in runtime.mstart1
    at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/proc.go:1494
17  0x00000000004300b6 in runtime.mstart0
    at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/proc.go:1444
18  0x00000000004520a5 in runtime.mstart
    at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/asm_amd64.s:395
19  0x000000000045432f in runtime.clone
    at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/sys_linux_amd64.s:613

But other threads don't:
(dlv) thread 1812158
Switched from 1812159 to 1812158
(dlv) bt
0  0x0000000000453937 in runtime.usleep
   at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/sys_linux_amd64.s:135
1  0x000000000042c459 in runtime.asyncPreempt2
   at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/preempt.go:307
   error: error while reading spliced memory at 0x18: EOF
(truncated)

This seems to be using mp.curg.sched? I assume that is expected? Simple mode gets stuck at sigreturn.
(dlv) bt -mode simple
0  0x0000000000453cb7 in runtime.usleep
   at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/sys_linux_amd64.s:135
1  0x000000000043e7af in runtime.sighandler
   at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/signal_unix.go:791
2  0x000000000043dbeb in runtime.sigtrampgo
   at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/signal_unix.go:479
3  0x0000000000453fe6 in runtime.sigtramp
   at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/sys_linux_amd64.s:352
4  0x00000000004540e0 in runtime.sigreturn
   at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/sys_linux_amd64.s:466
5  0x0000000000452541 in runtime.goexit
   at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/asm_amd64.s:1619

After https://go.dev/cl/479096, behavior is mostly the same, except it chokes a bit more on sigreturn__sigaction:
(dlv) bt -mode simple
0  0x0000000000453937 in runtime.usleep
   at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/sys_linux_amd64.s:135
1  0x000000000043e76f in runtime.sighandler
   at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/signal_unix.go:791
2  0x000000000043dbab in runtime.sigtrampgo
   at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/signal_unix.go:479
3  0x0000000000453c66 in runtime.sigtramp
   at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/sys_linux_amd64.s:352
4  0x0000000000453d60 in runtime.sigreturn__sigaction
   at /usr/local/google/home/mpratt/src/go-experiment/src/runtime/sys_linux_amd64.s:471
5  0x0000000000000007 in ???
   at ?:-1
   error: error while reading spliced memory at 0x8: EOF

https://go.dev/cl/479096 fixed 386 and amd64, but all other architectures I've checked (arm64, mips64, riscv) are still broken (Silent skips mask some of these failures from the dashboard). Reopening.
These other architectures have sigreturn defined in the VDSO, and GDB does seem to have appropriate matching logic for the VDSO, so I suspect we aren't handling the frame correctly in runtime.sigtramp, making GDB unable to find the return address to the VDSO.

@prattmic I'm looking into fixing dlv's stacktraces on go1.21 given the changes that have been made. As far as gdb can generate a good stacktrace assume it's a delve problem. However I don't understand the stacktraces you have posted, how was the core file generated?

It doesn't look like, in this case, gdb's output is very good: none of the threads have a frame with main.main, which you would expect to see. I'm getting the same with delve with my local improvements btw.

Presumably this is because the goroutine that executes main.main isn't running on any thread, but if I stacktrace goroutine 1 with delve I get this:
(dlv) goroutine 1 stack
0  0x000000000042fd59 in runtime.asyncPreempt2
   at /usr/local/go/src/runtime/preempt.go:309
   error: error while reading spliced memory at 0x18: EOF

which is still wrong, but not obviously delve's fault.

That can be expected. sighandler -> startpanic_m -> freezetheworld does a best-effort STW prior to the panic. So main.main will be descheduled just before the crash. The idea behind this is so that the panic traceback and print all goroutines (we can do traceback of a running goroutine).
I actually just merged https://go.dev/cl/478975 to optionally disable this because it makes debugging the scheduler more painful when panic scribbles all over scheduler state.
In https://github.com/golang/go/issues/25218#issuecomment-1487300685, thread 5 actually does show main.main. I suspect this is because that thread happened to be the one to receive the original SIGQUIT.

@prattmic uh, you're right, I didn't see it. I have the same thing in my core file and delve does the same thing as gdb. I was expecting main.main to be on a thread that's running a goroutine, but it isn't. The state of the process is pretty weird when taking a core dump like this.


Cannot merge columns of type[LONG] and [FLOAT]

Hi, all!
I have old segments with FLOAT on some columns, Is it possible to convert column from FLOAT to current LONG?
Or what is a best approach to merge such segments, scheme are same.
Regards,
Valentin.

Just need to use FireHorse to load old one index and convert it to new one with new Scheme.


Added script to test on i386

I couldn't find any features on the CircleCI documentation to test on 32bit.
I have written a small script that uses a container to test on i386. Would you consider to add it to CircleCI?
I can do it myself if you guys want.
//cc @otoolep

Thanks @aviau -- you mean you would like us to configure Circle such it calls test-32bit-docker.sh during testing?

@otoolep Yes.
That would be in the circle-test.sh script I believe.

It sure would @aviau -- do you want to make the proposed change to that too, to complete the PR?

Alright. That will take me a couple of tries. Ignore all future commits until I report back!

@otoolep This works!
However, the tests don't pass as #3706 wasn't merged.

FAIL	github.com/influxdb/influxdb/toml [build failed]

I have enabled CircleCI caching, so we don't have to build the image every build.

I have rebased on  #3706. We will see if this passes.

Here we go. That passes.
@otoolep If you increase the parallelism on CircleCI, we can have this test run on on a separate job.
Right now, your parallelism is set to two.

One job runs: go test $PARALLELISM $TIMEOUT -v ./... 2>&1 | tee $CIRCLE_ARTIFACTS/test_logs.txt
The other job runs: GORACE="halt_on_error=1" go test $PARALLELISM $TIMEOUT -v -race ./... 2>&1 | tee $CIRCLE_ARTIFACTS/test_logs_race.txt

@otoolep I have rebased this on #3734
As you can see, the build still fails.

FAIL	github.com/influxdb/influxdb/toml [build failed]

Thanks @aviau -- what is the full build failure?

@otoolep Its available on CircleCI: https://circleci.com/gh/influxdb/influxdb/4903

I don't see the string 'build failed' anywhere in the artefacts.
https://circle-artifacts.com/gh/influxdb/influxdb/4903/artifacts/0/tmp/circle-artifacts.X82CqPm/test_logs.txt
https://circle-artifacts.com/gh/influxdb/influxdb/4903/artifacts/1/tmp/circle-artifacts.mCl2QQJ/test_logs_race.txt

The 32bit doesn't output there yet. Look at the log.

I do see it in the Javascript display however.

Does it build if you push the test value down to 1gb?

I can't see exactly why it is failing, unless I am missing something.

I'll fire up my 32bit VM and see if I can reproduce.

Yep:
# github.com/influxdb/influxdb/toml_test
toml/toml_test.go:24: constant<PHONE_NUMBER> overflows toml.Size
FAIL	github.com/influxdb/influxdb/toml [build failed]

OK, toml.Size is an int. Can you decrease to 1gb?

If decreasing to 1gb works (it should), I'll update master.

Does not work.

You are still seeing the overflow message? If so, I am at a loss to explain why it is complaining about 1GB overflowing 32bit.

Yeah.
# github.com/influxdb/influxdb/toml_test
toml/toml_test.go:24: constant<PHONE_NUMBER> overflows toml.Size
FAIL	github.com/influxdb/influxdb/toml [build failed]

Did you patch the test? I'm talking about doing this:
$ git diff
diff --git a/toml/toml_test.go b/toml/toml_test.go
index 18e4dab..640abbc 100644
--- a/toml/toml_test.go
+++ b/toml/toml_test.go
@@ -19,9 +19,9 @@ func TestSize_UnmarshalText_MB(t *testing.T) {
 // Ensure that gigabyte sizes can be parsed.
 func TestSize_UnmarshalText_GB(t *testing.T) {
        var s toml.Size
-       if err := s.UnmarshalText([]byte("2g")); err != nil {
+       if err := s.UnmarshalText([]byte("1g")); err != nil {
                t.Fatalf("unexpected error: %s", err)
-       } else if s !=<PHONE_NUMBER> {
+       } else if s !=<PHONE_NUMBER> {
                t.Fatalf("unexpected size: %d", s)
        }
 }

I only patched the 1g. Your patch works.

As far as this PR goes, it should be failing. I'll fix it until it fails and then rebase on the fix you are about to commit to master.

@aviau  - master has been patched, your build should pass after you rebase.

@otoolep
Alright, this works!
New artifact: test_logs_i386.txt - example
This is now ready to be merged.

Thanks @aviau
@jwilder -- can you comment on this change? It uses Docker.

LGTM :+1:

Thanks again @aviau

Thanks to you for being so responsive ;)


Extract Authentication and common logging into the specific filters

What changes are proposed in this pull request?
Extract Authentication and common logging into the specific filters
Why are the changes needed?
I added two filters, one is for authentication and another is for logging.
we have several implementations to log the request parameter, and one of them is in CompleteMultipartUploadHandler. it will confuse other developers.
And we need a common filter to perform authentication. it will be helpful for us to further develop.

is the new code tested?
@ZhuTopher  Please take a look to see if it is proper.

alluxio-bot, merge this please


http://pythonhosted.org/six/ docs are not up to date

Originally reported by: Marc Abramowitz (Bitbucket: msabramo, GitHub: msabramo)

I think http://pythonhosted.org/six/ needs to be rebuilt.
It says that Python 2 and Python 3 both have xmlrpclib which is not correct and was already fixed in e7179a1b4a63.

Bitbucket: https://bitbucket.org/gutworth/six/issue/58

@benjaminp they're outdated again - and pythonhosted appears higher in google. Can you remove it and redirect to rtfd?

I deleted the PyPI ones.


Complexity O()

What is the complexity of read write operations in SkipMap and SkipSet? These are rather important metrics that should be part of the README.md imo.

O(log n) average, O(n) worst case for lookups, insertions, and deletions. I don't think the O(n) worst case is likely to occur typically.

O(log n) average, O(n) worst case for lookups, insertions, and deletions. I don't think the O(n) worst case is likely to occur typically.

Excellent, thanks for this.


GET endpoint for single appointment by appointmentId

Description
Endpoint on appoitnments route to get one appointment back by the appointmentID
Type

[ ] This is a bugfix.
[x] This is a new feature.
[x] This is part of a feature.

Organization

[x] Have you linked this pull request to a Trello card?
[x] Have you named the branch in the format of feature/describe_feature_or_change OR bug/describe_bug_this_is_fixing

Review

[ ] Is this a work in progress?
[x]  Is this ready to be reviewed?
[ ]  Have you added two reviewers to this pull request?

@ClydeFrog04 Thanks for catching that log. removed it an switched over a few other i found to errors in the process


Units size expected with styled components

Hi there,
When I was using react-native-responsive-screen with styled-components,  I have always getting warning messages like below:
[Sat Apr 25 2020 13:50:46.110]  WARN     Expected style "width: 119" to contain units
in Context.Consumer (created by StyledNativeComponent)
in StyledNativeComponent (created by Styled(Component))
in Styled(Component) (at Card/index.js:12)
in Card (at Dashboard/index.js:43)
in Dashboard (at SceneView.tsx:98)
in SceneView (at useDescriptors.tsx:125)
in CardContainer (at CardStack.tsx:561)
in CardStack (at StackView.tsx:418)
in KeyboardManager (at StackView.tsx:416)
in Context.Consumer (at StackView.tsx:414)
in StackView (at createStackNavigator.tsx:82)
in StackNavigator (at routes.js:65)
in DashboardRoutes (at SceneView.tsx:98)
in SceneView (at useDescriptors.tsx:125)
in BottomTabView (at createBottomTabNavigator.tsx:41)
in BottomTabNavigator (at routes.js:165)
in TabRoutes (at SceneView.tsx:98)
in SceneView (at useDescriptors.tsx:125)
in CardContainer (at CardStack.tsx:561)
in CardStack (at StackView.tsx:418)
in KeyboardManager (at StackView.tsx:416)
in Context.Consumer (at StackView.tsx:414)
in StackView (at createStackNavigator.tsx:82)
in StackNavigator (at routes.js:212)
in AppRoutes (at App.js:27)
in App (at renderApplication.js:45)
[Sat Apr 25 2020 13:50:46.130]  WARN     Expected style "height: 119" to contain units
in Context.Consumer (created by StyledNativeComponent)
in StyledNativeComponent (created by Styled(Component))
in Styled(Component) (at Card/index.js:12)
in Card (at Dashboard/index.js:43)
in Dashboard (at SceneView.tsx:98)
in SceneView (at useDescriptors.tsx:125)
in CardContainer (at CardStack.tsx:561)
in CardStack (at StackView.tsx:418)
in KeyboardManager (at StackView.tsx:416)
in Context.Consumer (at StackView.tsx:414)
in StackView (at createStackNavigator.tsx:82)
in StackNavigator (at routes.js:65)
in DashboardRoutes (at SceneView.tsx:98)
in SceneView (at useDescriptors.tsx:125)
in BottomTabView (at createBottomTabNavigator.tsx:41)
in BottomTabNavigator (at routes.js:165)
in TabRoutes (at SceneView.tsx:98)
in SceneView (at useDescriptors.tsx:125)
in CardContainer (at CardStack.tsx:561)
in CardStack (at StackView.tsx:418)
in KeyboardManager (at StackView.tsx:416)
in Context.Consumer (at StackView.tsx:414)
in StackView (at createStackNavigator.tsx:82)
in StackNavigator (at routes.js:212)
in AppRoutes (at App.js:27)
in App (at renderApplication.js:45)
[Sat Apr 25 2020 13:50:46.140]  WARN     Expected style "marginTop: 11" to contain units
in Context.Consumer (created by StyledNativeComponent)
in StyledNativeComponent (created by Styled(Component))
in Styled(Component) (at Card/index.js:12)
in Card (at Dashboard/index.js:43)
in Dashboard (at SceneView.tsx:98)
in SceneView (at useDescriptors.tsx:125)
in CardContainer (at CardStack.tsx:561)
in CardStack (at StackView.tsx:418)
in KeyboardManager (at StackView.tsx:416)
in Context.Consumer (at StackView.tsx:414)
in StackView (at createStackNavigator.tsx:82)
in StackNavigator (at routes.js:65)
in DashboardRoutes (at SceneView.tsx:98)
in SceneView (at useDescriptors.tsx:125)
in BottomTabView (at createBottomTabNavigator.tsx:41)
in BottomTabNavigator (at routes.js:165)
in TabRoutes (at SceneView.tsx:98)
in SceneView (at useDescriptors.tsx:125)
in CardContainer (at CardStack.tsx:561)
in CardStack (at StackView.tsx:418)
in KeyboardManager (at StackView.tsx:416)
in Context.Consumer (at StackView.tsx:414)
in StackView (at createStackNavigator.tsx:82)
in StackNavigator (at routes.js:212)
in AppRoutes (at App.js:27)
in App (at renderApplication.js:45)
[Sat Apr 25 2020 13:50:46.150]  WARN     Expected style "marginBottom: 18" to contain units
in Context.Consumer (created by StyledNativeComponent)
in StyledNativeComponent (created by Styled(Component))
in Styled(Component) (at Card/index.js:12)
in Card (at Dashboard/index.js:43)
in Dashboard (at SceneView.tsx:98)
in SceneView (at useDescriptors.tsx:125)
in CardContainer (at CardStack.tsx:561)
in CardStack (at StackView.tsx:418)
in KeyboardManager (at StackView.tsx:416)
in Context.Consumer (at StackView.tsx:414)
in StackView (at createStackNavigator.tsx:82)
in StackNavigator (at routes.js:65)
in DashboardRoutes (at SceneView.tsx:98)
in SceneView (at useDescriptors.tsx:125)
in BottomTabView (at createBottomTabNavigator.tsx:41)
in BottomTabNavigator (at routes.js:165)
in TabRoutes (at SceneView.tsx:98)
in SceneView (at useDescriptors.tsx:125)
in CardContainer (at CardStack.tsx:561)
in CardStack (at StackView.tsx:418)
in KeyboardManager (at StackView.tsx:416)
in Context.Consumer (at StackView.tsx:414)
in StackView (at createStackNavigator.tsx:82)
in StackNavigator (at routes.js:212)
in AppRoutes (at App.js:27)
in App (at renderApplication.js:45)
[Sat Apr 25 2020 13:50:46.170]  WARN     Expected style "marginRight: 11" to contain units
in Context.Consumer (created by StyledNativeComponent)
in StyledNativeComponent (created by Styled(Component))
in Styled(Component) (at Card/index.js:12)
in Card (at Dashboard/index.js:43)
in Dashboard (at SceneView.tsx:98)
in SceneView (at useDescriptors.tsx:125)
in CardContainer (at CardStack.tsx:561)
in CardStack (at StackView.tsx:418)
in KeyboardManager (at StackView.tsx:416)
in Context.Consumer (at StackView.tsx:414)
in StackView (at createStackNavigator.tsx:82)
in StackNavigator (at routes.js:65)
in DashboardRoutes (at SceneView.tsx:98)
in SceneView (at useDescriptors.tsx:125)
in BottomTabView (at createBottomTabNavigator.tsx:41)
in BottomTabNavigator (at routes.js:165)
in TabRoutes (at SceneView.tsx:98)
in SceneView (at useDescriptors.tsx:125)
in CardContainer (at CardStack.tsx:561)
in CardStack (at StackView.tsx:418)
in KeyboardManager (at StackView.tsx:416)
in Context.Consumer (at StackView.tsx:414)
in StackView (at createStackNavigator.tsx:82)
in StackNavigator (at routes.js:212)
in AppRoutes (at App.js:27)
in App (at renderApplication.js:45)
[Sat Apr 25 2020 13:50:46.180]  WARN     Expected style "marginLeft: 11" to contain units
in Context.Consumer (created by StyledNativeComponent)
in StyledNativeComponent (created by Styled(Component))
in Styled(Component) (at Card/index.js:12)
in Card (at Dashboard/index.js:43)
in Dashboard (at SceneView.tsx:98)
in SceneView (at useDescriptors.tsx:125)
in CardContainer (at CardStack.tsx:561)
in CardStack (at StackView.tsx:418)
in KeyboardManager (at StackView.tsx:416)
in Context.Consumer (at StackView.tsx:414)
in StackView (at createStackNavigator.tsx:82)
in StackNavigator (at routes.js:65)
in DashboardRoutes (at SceneView.tsx:98)
in SceneView (at useDescriptors.tsx:125)
in BottomTabView (at createBottomTabNavigator.tsx:41)
in BottomTabNavigator (at routes.js:165)
in TabRoutes (at SceneView.tsx:98)
in SceneView (at useDescriptors.tsx:125)
in CardContainer (at CardStack.tsx:561)
in CardStack (at StackView.tsx:418)
in KeyboardManager (at StackView.tsx:416)
in Context.Consumer (at StackView.tsx:414)
in StackView (at createStackNavigator.tsx:82)
in StackNavigator (at routes.js:212)
in AppRoutes (at App.js:27)
in App (at renderApplication.js:45)
I'd always creating my styles like that:
`
import styled from 'styled-components/native';
import colors from '../../../themes/colors';
import {
heightPercentageToDP as hp,
widthPercentageToDP as wp
} from 'react-native-responsive-screen';
export const Wrapper = styled.View`
flex: 1;
background-color: ${colors.bgPrimary};

`;
export const Header = styled.View`
flex-direction: row;
background-color: ${colors.purple};
width: ${wp('90%')};
margin-left: auto;
margin-right: auto;
margin-top: ${hp('3%')};
margin-bottom: ${hp('2%')};

padding-top: ${hp('2%')};
padding-bottom: ${hp('2.2%')};

border-radius: ${hp('2%')};

`;
`

I have the same issue.

@rodrigodiasnoronha @rbalbix according to the stack trace your code gets successfully transformed to: width: 119 which is appropriate as style properties in RN expect DP or %. That being said it looks like a styled-components issue as per the warning it expects units:
WARN Expected style "width: 119" to contain units

@rodrigodiasnoronha  You can give a try to this.     width: ${${wp(90%)}px};


Add github actions test workflow

Fixes part of https://github.com/thenewboston-developers/DevOps/issues/6
Seems like https://github.com/thenewboston-developers/Website/pull/1294 is abandoned and there were errors. It would be good to set this up now as there will be more PRs coming in to create tests. Adding test to the CI pipeline will save effort from reviewers to ensure tests have no failure.
Things to note:

I'm only running the tests for node v12 and v14, I believe it's unnecessary to run node v10 and adding that will just take up more processing time for github actions (note that there are usage limits to github actions).

We can perhaps only run on one node version, which we can specify in the README file. This is so that CI runs faster and less prone to failures due to a lot of PRs trying to run github workflows at the same time.

Currently the workflow will only execute when:

it's a PR to the development branch, as well as pushes to the PR
any direct pushes to the team's repo

References:

https://github.com/yarnpkg/yarn/issues/4890 (why i added the network timeout in yarn install --network-timeout 1000000)

nice job on being proactive about this @jamessspanggg !


[Bug] '--track' Option Does Not Work Correctly With '--tac' Option

[x] I have read through the manual page (man fzf)
[x] I have the latest version of fzf
[x] I have searched through the existing issues

Info

OS

[x] Linux
[ ] Mac OS X
[ ] Windows
[ ] Etc.

Shell

[ ] bash
[x] zsh
[ ] fish

Problem / Steps to reproduce
Steps:

Generate some random text which is diverse and sufficiently large:

base64 /dev/urandom | head -c 100000 > /tmp/test_file.txt

Run

FZF_DEFAULT_COMMAND="cat /tmp/test_file.txt" fzf --track --tac

Type in some random letters and select an item.
Clear the query.

Expected Result: Similar to '--layout=reverse-list', the track option should track the selection, such that when the query is clear, the item is still selected.
Actual Result: The item is not tracked correctly.
The option works with --layout=reverse-list and no list option fine, it appears to just be a --tac problem.
I also notice that when I start a sufficiently large, active stream with fzf --tac --track, the stream scrolls by for a little bit before stopping, but it doesn't keep the selected item , or stop at the start or end of the stream, usually stopping close to the middle. I'm unsure of what the issue there is.
Steps:

Run FZF_DEFAULT_COMMAND="base64 /dev/urandom" fzf --track --tac.
Observe the scroll bar and scrolling behaviour.

I've tried to fix the bug, then I realized it can be extremely confusing to use --track with --tac.
seq 1000000 | fzf --tac --track

Scenario 1
Because of --tac, you would expect fzf to point to 1 at the beginning, the cursor is at the top of the screen. (See the scrollbar at the top-right corner)

Then you press 1, suddenly 1 becomes the match with the highest score, it is now at the bottom of the screen. (Scrollbar at the bottom-right corner)

Delete 1, and the cursor is not at the top of the list.

Scenario 2
The cursor is pointing to 1 as before.

Then you type 2, now there is no 1 in the list, then which item fzf should be pointing to now? Because fzf was previously pointing to the item with the lowest score, it is now pointing to the nearest match, which is the least significant match in the result.

Even with --no-sort?
Things are already too confusing and non-intuitive, then you add --no-sort, it's really hard to predict how fzf will perform.
So now what?
I'm thinking of disallowing --track with --tac because I don't think users will appreciate the mix.

I think disabling --track and --tac when together would make sense to me from a UX standpoint. I think the examples you've provided would indeed be confusing.
My user story here is that I'd like to be able to use track to scroll-lock and move to queries that I've found in a live input stream, but I'd also like to use tac to see the live feed scrolling by when not tracking. In furtherance of my usecase, would it be possible to have a lower-priority feature request to be able to switch between --tac and --track modes as a bind?
My expected behaviour here (and I'm not sure how realistic this is) is that when --tac is enabled, the list will act as normal, scrolling from the bottom and keeping up with the input stream. When the binding for --track is pressed, items retain their position (similar to using --layout=reverse-list --track), but tracking begin. When --tac is pressed again, the list stops tracking and begins scrolling again.
Thanks for looking into this!

I see, I'd rather not jump to a conclusion. I'll take some time and think about it.

Thanks a lot for the fix! track+clear-query works a charm for jumping around logs!


TESTING

kokoro presubmit testing, don't review, don't merge.

Codecov Report

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

@@           Coverage Diff           @@
##           master     #365   +/-   ##
=======================================
  Coverage   62.61%   62.61%
=======================================
  Files          65       65
  Lines        1701     1701
  Branches      254      254
=======================================
  Hits         1065     1065
  Misses        530      530
  Partials      106      106

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 76b51a8...1488974. Read the comment docs.


Issue #2: Adding the ability to retrieve zone statuses

This PR resolves issue #2 by adding the ability to get the status of all zones in a given location.

Awesome! Thanks! Will update pypi with both of these when I get home

Is it planned to update HomeAssistant to have sensors for Zone Status?  (Maybe this already exists, I can't find it in the documentation)

@SP410 it hasn't been added yet.  I'll try to get to it soon.


#508 add hasLogger method to Monolog\Registry

My bad, found the PR. For some reason the link in the issue sent me to your fork, weird...


Expended functionality

Add - Undolimit
Add - ADD/REMOVE popop

These modification cause a lot of problems.  Not entirely sure what is going on in RemoveRightMostDigit() now, but it definitely doesn't work properly since I tested this branch.

Thank for e-mail
I will check tais tais week-end en post an update.
Can you give me more detail this bug ?
Regards
Le 12 sept. 2016 19:34, "MrZander"<EMAIL_ADDRESS>a écrit :

These modification cause a lot of problems. Not entirely sure what is
going on in RemoveRightMostDigit() now, but it definitely doesn't work
properly since I tested this branch.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/mtusk/wpf-currency-textbox/pull/1#issuecomment-246528479,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AQTyO2UXOZ_zISZ50L00R1Op1sXvVF5Wks5qpeFrgaJpZM4HaBe5
.

This feels like a complete re-write that fulfills a need this control wasn't intended to fill.

Backspace sometimes clears the value instead of removing the right-most digit
Minimum don't appear to have any impact
The add/remove popup is an interesting interaction that I could see being useful but I feel is scope creep for the goal of this project

Humm this spécial it Word good for me...
I think is the localisation??. I use french canadien and i have developped
with this. I will put my system in english US for testing
Le 13 sept. 2016 12:22 AM, "Adam Anderson"<EMAIL_ADDRESS>a
écrit :

This feels like a complete re-write that fulfills a need this control
wasn't intended to fill.

Backspace sometimes clears the value instead of removing the
right-most digit
Minimum don't appear to have any impact
The add/remove popup is an interesting interaction that I could see
being useful but I feel is scope creep for the goal of this project

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/mtusk/wpf-currency-textbox/pull/1#issuecomment-246569713,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AQTyO9Q32QN2Bldmv3A7fSF-V_iK52qkks5qpiT4gaJpZM4HaBe5
.

Haaaa is not the updated code !
check my Fork : https://github.com/abbaye/wpf-currency-textbox
you can test package on nuget  https://www.nuget.org/packages/CurrencyTextBox/
it's work fine :)


After click on hamburger cross icon needs to align properly in mobile

Is your feature request related to a problem? Please describe.
After click on hamburger cross icon needs to align properly in mobile
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context

What problem is this feature trying to solve?
How do we know when the feature is complete?

Hello @Akshatchaube01 please assign this issue to me under gssoc 24


serversTransport.rootCAs not being honored

Welcome!

[X] Yes, I've searched similar issues on GitHub and didn't find any.
[X] Yes, I've searched similar issues on the Traefik community forum and didn't find any.

What did you do?
Trying to configure TLS on my backends by following this guide:
https://doc.traefik.io/traefik/routing/overview/#rootcas
I'm running traefik on debian 11 with systemd.
I have modified the static configuration file /etc/traefik/traefik.yml with the following, and yes, the traefik user can read the file. Logs don't show anything interesting.
serversTransport:
  rootCAs:
    - /etc/traefik/certs/self-signed-ca.pem

I keep getting 500 internal server error on all my https backends. http ones work regularly
I'm using a single service for my backend, I just changed the url: http -> https. The 500 was coming from traefik 100%, I can curl the service directly.
Nothing is even reaching the backend service, the request fails when it reaches traefik. (I checked the backend service logs)
It seems that the rootCAs rule is not honored for some reason, because when setting:
serversTransport:
  insecureSkipVerify: true

Everything works as it should, except the above flag is not production approved.
Any thoughts? This seems like a bug...
What did you see instead?
My Desktop -> Traefik

Traefik -> backend service:
$ nc -vz backend-https-host 443
backend-https-host [ip redacted] 443 (?) open

What version of Traefik are you using?
Version:      2.9.5
Codename:     banon
Go version:   go1.19.3
Built:        2022-11-17T15:04:26Z
OS/Arch:      linux/amd64
What is your environment & configuration?
config.yml:
tls:
  options:
    default:
      sniStrict: true
      minVersion: VersionTLS12
      cipherSuites:
        - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
        - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
        - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
        - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

http:
  routers:
    redacted:
      rule: Host(`sub.domain.tld`)
      entryPoints:
        - web-secure
      middlewares:
        - security-headers
      service: service1
      tls:
        certResolver: le
        domains:
          - main: "sub.domain.tld"

  services:
    service1:
      loadBalancer:
        servers:
          - url: https://backend-host:443

  middlewares:
    security-headers:
      headers:
        referrerPolicy: same-origin
        forceSTSHeader: true
        stsSeconds: 31536000
        stsIncludeSubdomains: true
        stsPreload: true
        contentTypeNosniff: true
        browserXssFilter: true
        customRequestHeaders:
          X-Forwarded-Proto: https
        frameDeny: true

traefik.yml:
providers:
  file:
    filename: /etc/traefik/config.yml
    watch: true

serversTransport:
  rootCAs:
    - /etc/traefik/certs/self-signedCA.pem # also in system trust store and readable by traefik user
  insecureSkipVerify: false

entryPoints:
  web:
    address: :80
    http:
      redirections:
        entryPoint:
          to: web-secure
          scheme: https
          permanent: true

  web-secure:
    address: :443

certificatesResolvers:
  le:
...
redacted
...

If applicable, please paste the log output in DEBUG level
No response

Hello @rwjack ,
Can you please show us the logs, with DEBUG level activated?

It seems I missed something in the debug logs, I was using an incorrect SAN name...


Add CHANGELOG

Description
Add CHANGELOG
Issues Resolved
N/A
Check List

[X] New functionality includes testing.

[X] All tests pass

[X] New functionality has been documented.

[X] New functionality has javadoc added

[X] Commits are signed as per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #800 (eeaecf3) into main (e9dd3e0) will decrease coverage by 0.33%.
The diff coverage is n/a.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@             Coverage Diff              @@
##               main     #800      +/-   ##
============================================
- Coverage     85.40%   85.08%   -0.33%
+ Complexity     1084     1076       -8
============================================
  Files           151      151
  Lines          4370     4370
  Branches        390      390
============================================
- Hits           3732     3718      -14
- Misses          463      475      +12
- Partials        175      177       +2

see 5 files with indirect coverage changes
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.