Proof request credentials do not group properly

Description of problem

proof request details does not properly group 'From your wallet' sections and 'Missing from your wallet' sections, currently all credentials in a proof request appear under the same header
'Not in your wallet' text is currently not displaying correctly for credentials that are missing

Expected behavior

Proof requests that contain credentials that exists and do not exists in the users wallet should be "grouped"
Missing credentials say "Not in your wallet"
Attributes for missing labels do not say " is missing"
Multiple examples in the image attached

Steps to reproduce

Issue a proof requests containing a credential that does not exist in the users wallet and a credential that does
See proof request

Screenshots and/or log output
Environment

[x] Occurs on Android
[x] Occurs on iOS

Build #:
Android Device Model:
iOS Device Model:
Workaround
Severity

[ ] High
[ ] Medium
[ ] Low

Verified fixed


OCPBUGS-24400: Only recreate etcd if hasn't ever been ready

What this PR does / why we need it:
Which issue(s) this PR fixes (optional, use fixes #<issue_number>(, fixes #<issue_number>, ...) format, where issue_number might be a GitHub issue, or a Jira story:
Fixes #
Checklist

[ ] Subject and description added to both, commit and PR.
[ ] Relevant issues have been referenced.
[ ] This change includes docs.
[ ] This change includes unit tests.

/test unit

/lgtm

/retest

/jira refresh


Update large-instance-os-backup.md

Documentation was incorrect, added the link to the correct documentation.

@kbhalaki : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@kbhalaki : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@kbhalaki : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@mamccrea can you please review this PR?


Error in mapping for v<IP_ADDRESS>

Dear chhylp123:
I installed BitMapperBS v<IP_ADDRESS> via conda and successfully indexed hg38, but encountered error during mapping as following:
$bitmapperBS --search /pub/iGenomes/Homo_sapiens/UCSC/hg38/Sequence/BitMapperBS/genome.fa --seq1 ../sh_OE.trimmed.first10w.R1.fq --seq2 ../sh_OE.trimmed.first10w.R2.fq -t 1 --bam -o sh.bitm.bam
fileName[0]: /pub/iGenomes/Homo_sapiens/UCSC/hg38/Sequence/BitMapperBS/genome.fa
fileName[1]: /pub/iGenomes/Homo_sapiens/UCSC/hg38/Sequence/BitMapperBS/genome.index
Read qualities are encoded by Phred+33...
GapOpenPenalty: 5, GapExtensionPenalty: 3, MistMatchPenaltyMax: 6
MistMatchPenaltyMin: 2, N_Penalty: 1
 Read files are in FASTQ format...
Open /pub/iGenomes/Homo_sapiens/UCSC/hg38/Sequence/BitMapperBS/genome.fa.index sucessfully!
Start load hash table!
refGenLength =<PHONE_NUMBER>
Open /pub/iGenomes/Homo_sapiens/UCSC/hg38/Sequence/BitMapperBS/genome.fa.index.bs.pac sucessfully!
shapline=1698406910
BWT has been loaded!
hash table has been loaded!
SA_length=1904980163
sparse_suffix_array_length=774993433
SA_flag_iterater=121092726
high_occ_table_length=189208
段错误(吐核)

Thanks for your help.

Resolved.
I re-complied bitmapperbs from source, with gcc/g++ v7.3.1 (devtoolset-7 in centos7), and this remind me that errors have occurred during the first compilation  by gcc v4.
before I compiled from source, the conda installed version errs  as the above.
Thanks and hope this helps.

Resolved.
I re-complied bitmapperbs from source, with gcc/g++ v7.3.1 (devtoolset-7 in centos7), and this remind me that errors have occurred during the first compilation  by gcc v4.
before I compiled from source, the conda installed version errs  as the above.
Thanks and hope this helps.


Another color input option

Hello, I ran into such a problem that using it through one plugin, the HEX code is replaced with a color at once before executing the command. Please add another spelling of the command, for example
before
/ nick <gradient: # 1eae98: # d8b5ff> Majekdor
after
/ nick <gradient: 1eae98: d8b5ff> Majekdor

I don't fully understand. So another plugin is removing the # so the gradient isn't working?

No. The ChatControl plugin, when used in it, replaces this
<gradient: # 1eae98: # d8b5ff> Majekdor
On this
gradient:: Majekdor   - after "gradient" there is already colored text
You can add another kind of use without #, for example
<gradient: 1eae98: d8b5ff> Majekdor

There's nothing I can really do about that. It's just a plugin conflict because you're currently using two completely different methods of parsing color. I use MiniMessage and for the color parsing and that's just how the tags work. Also the fact that ChatControl is taking plain hex codes and translating them to color is pretty silly. The "community standard" since hex codes were introduced was to do something like &#aabbcc, not just parse any hex code seen.


Sort API and Examples docs

API docs are already kept pretty well alphabetical in the Wiki, but this enforces it. Examples on the other hand are not sorted at all, this should make it a little easier to find things.

Hm. I've been manually selecting order of examples in programs.json... Sometimes I want to push a newer example to the top of given topic.

@rwaldron Should have mentioned this actually only sorts the topics, so you
can still manually sort individual examples.
I find myself hunting for classes, but I get it if you want to have more
control.
On Apr 6, 2016 5:53 PM, "Rick Waldron"<EMAIL_ADDRESS>wrote:

Hm. I've been manually selecting order of examples in programs.json...
Sometimes I want to push a newer example to the top of given topic.
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/j5js/johnny-five.io/pull/89#issuecomment-206587326


Launching Zoom

Description of the new feature / enhancement
I just created a workspace that includes Zoom. Fails to launch. Can this be added? Maybe launch a specified Zoom link?
Scenario when this would be used?
When I host Zoom meetings, I also open and position a clock so I can time meditations. And position the Zoom Participants window where it is convenient for me to see. Would be cool to do this with one click of the mouse.
Supporting information
Are there wrinkles to using Zoom that makes the Workspaces tool unable to launch Zoom? Or can you steer me to some documentation, how to launch Zoom?

@RelativeRon  Please retest with PT 0.86 version. If the issue persists, please send a /bugreport Thanks!

Yes, this works now. Thanks for your attention to this.


Clean up storage/volume-attributes-classes.md

Tweak long lines
Fix minor grammar issues

/approve


Use Ubuntu's clang-format package

woops meant to do this on my fork sorry 'bout that

No problem :) I think it might indeed be faster with Ubuntu's own package rather than installing LLVM.  You would not be getting the latest and greatest features though ;)


Cam't reinstall

Amy ideas?
npm ERR! Unexpected end of JSON input while parsing near '...Ns8V+L3tEk8U8Un7vCvgi'
npm ERR!   What command were you executing?  What versions of NodeJS and npm do you use?  On what platform?  Please attach the logfile.
Do you have any free space left on your disk?

Will post later.
It seems there is a problem with NPM at the moment. Many homebridges have problems to load the plugins overview in configui. Iam also in contact with onzu about this issue. Your package seems to be affected by this.

Had the same error this morning.
Yesterday i installed homebridge-hue v.0.11.24. This takes a very long time (10min+).
This morning I updated an other homebridge plugin a got this error to.
sudo npm cache clean --force solved it for me.

Thanks. This exactly solved the issue for me as well.
Was relegated to incomplete pulls due to npm server issues. Works fine now.
Please close


multiple accounts feature

x auth -a elon -- continue authentication
x auth -a yoyo -- continue authentication
x switch -a elon >> post from elon
x switch -a yoyo >> post from yoyo

Suggesting the following UX, once auth is complete in both accounts:
+ -l                          lists logged in accounts
+ -d "username"   set's an account as default

+ x "text"                              post a tweet with the default account
+ x -a "username" "text"    post a tweet with the specified account
-  -t "text"   	                     post a tweet

Also consider:
- auth                     start authorizing your X account
+ -i (--log-in)       log-in to your X account
- auth --url            get auth url if it didn't open browser after running 'x auth'
+ --url                    get auth url if it didn't open browser after running 'x -i'
- auth -v                 verify authorization after running 'x auth'
+ -s                        (status) ... check sessions tatus and perhaps more info ...
-  -c              	       clear authorized account
+ -o                        log-out to your X account


HDDS-7743. [Snapshot] Implement snapshot disk usage: Exclusive size and more

What changes were proposed in this pull request?
The change proposes to add exclusive size for a snapshot. PR #5175 address Reference Size calculation for each Snapshot. I have linked a PDF in the JIRA explaining the design. I have summarized it below for future reference. A Snapshot has 4 size,

Reference Size, it is explained here #5175
Total Size - Refers to the sum of shared size and exclusive size of the snapshot. This is nothing but the bucket size during snapshot.
Shared Size - Refers to data shared between snapshots. Hence this size can’t be quantified as data held by one snapshot but shared between 2 or more snapshots.
Exclusive Size - Refers to the data held only by that snapshot.

Calculations:
Total Size
We can get Total Size from the bucketInfo omBucketInfo.getUsedBytes()  in the Snapshot. This gives the total size used by the snapshot.
Note: This give the size of the bucket after replication.
Shared Size
Once we get the Total Size and Exclusive Size we can calculate Shared Size.
Shared Size = Total Size - Exclusive Size
Exclusive Size
To calculate Exclusive Size for current snapshot, Check the next snapshot deletedTable if the deleted key is referenced in current snapshot and not referenced in the previous snapshot then that key is exclusive to the current snapshot.
An example is discussed in the attached Doc in the JIRA.
Things to do in follow-up PRs

Expand deletedDirTable for all the snapshot.
Update the code to accommodate files moved to deleteTable and calculate Exclusive size.

What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-7743
How was this patch tested?
Added New Unit Test and Integration test.

Thanks for the review @hemantk-12 I will be updating the PR shortly with the suggestions. For the questions,

Correct. The last snapshot will not have exclusive size. For the last snapshot, we should calculate it using Active DB's deletedTable. The Active DB is constantly changing and we would be iterating through the deletedTable every time the KeyDeletingService runs, This takes hold of deletedTable lock and we will be constantly holding this lock even though there is nothing to update it.
Yes, It will be eventually calculated. Not immediately when the snapshot is taken.

For some weird reason, The test case testSnapshotExclusiveSize() is failing. I'll fix it before merging this PR.

Thanks for the patch @aswinshakil and @smengcl for review.


Engine GetInstance "string input was not in correct format"

Hello,
I have a simple code that runs all right in my computer but returns the error "string input was not in correct format" in the server.
The error happens when I call the GetInstance()
What can I do?

Apparently the problem was the R version. Did not worked with the 3.2.4-revised. I just installed the 3.2.3 and worked fine.


Genotype and MHCGenotype are too deeply nested

Both Genotype and MHCGenotype are nested more deeply than typical for the schema.  MHCGenotype.mhc_alleles and and Genotype.*_alleles could be pulled out into top level objects with refs in Genotype and MHCGenotype.

Making receptor_genotype_set and mhc_genotype_set independent properties of Subject makes sense to me as these are independent objects.
I am less sure of the logic behind splitting documented_alleles, undocumented_alleles and deleted_genes into high-level objects., These are inherent related components of the genotype. Is there a need to reduce the depth of nesting to a specific level? If so could you articulate the reason please, so that we can consider options.

The reason is mostly stylistic. In the rest of the schema, objects live in other objects via $ref:s not by nesting the definition. They would still be inherent related components if their definition was at the top level. But, it should be easier to validate if we use the same style throughout.
Aside from that, we might be able to apply some abstraction to documented_alleles, undocumented_alleles, and deleted_genes. Not sure on that. We'd have to discuss.

Thanks, @williamdlees. I think for this particular issue, we can just focus on the style fix and maybe the allele abstraction question.  The validation should follow from that. If the style is right, the validation should be fine, but, if not, then we'll need to fix the validation.

undocumented_alleles.allele_name should be renamed to label, but we'll need to check if this breaks backwards compatibility in the ADC and therefore needs to wait until v2.0 (likely yes).

@javh Can you deprecate and add label in with v1.4.2? That way I can start using label now.

Deprecation and changing a label breaks backwards compatibility so it shouldn't be part of v1.4.2, no? Any field name/type changes shouldn't be a part of a minor release...

Deprecation and changing a label breaks backwards compatibility so it shouldn't be part of v1.4.2, no? Any field name/type changes shouldn't be a part of a minor release...

Right, yeah minor release should just be software and minor fixes. Could be a v1.5.x then. I wasn't sure if saying v2.0 because the change required a new version of MiAIRR, or there's just an expectation to get v2.0 released before a v1.5...

De-nesting Germline schema: De-nesting shouldn't break anything, so we can include this is v1.4.2.

As long as the "path" to the object doesn't change - which de-nesting should not do - then things should be fine.
So subject.genotype.mhc_genotype_set.mhc_class should not change after the de-nesting.
The above is how one queries for this field, so if the path changes then we are breaking compatibility...

From the call:

Create a new issue for the label and receptor_genotype_* field renames for milestone v1.5.0.

De-nesting Germline schema: De-nesting shouldn't break anything, so we can include this is v1.4.2.

As long as the "path" to the object doesn't change - which de-nesting should not do - then things should be fine.

The term de-nesting seems to be used in two contexts. For Subject.genotype, the de-nesting is changing the "path"
So subject.genotype.mhc_genotype_set.mhc_genotype_list.mhc_class --> subject.mhc_genotype_set.mhc_genotype_list.mhc_class and thus queries would change.
The other de-nesting is making stylistic changes to the schema, e.g. #669 and these shouldn't affect the "path"

So where do we stand on this for v2.0?

Subject.genotype: Fine to de-nest by moving receptor_genotype_set and mhc_genotype_set up a level. However, this will break backwards compatibility so it needs to wait until v2.0. Additional issues to address in v2.0: (1) should these be arrays and (2) should they be in Repertoire instead of Subject (as they are downstream from DataProcessing).

Personally, I am not sure I understand why we want to move these "up a level". Logically they are both genotype of a subject, so why do we not want to have them represented that way? This is a minor detail, and I don't really care that much, but it seems odd that this is viewed as "better". For v2.0 I would lean toward keeping the subject.genotype but I am not highly invested either way.

Subject.genotype: Fine to de-nest by moving receptor_genotype_set and mhc_genotype_set up a level. However, this will break backwards compatibility so it needs to wait until v2.0. Additional issues to address in v2.0: (1) should these be arrays and (2) should they be in Repertoire instead of Subject (as they are downstream from DataProcessing).

It doesn't make sense to me to have subject genotype logically stored only at the repertoire level since biologically they are related to the subject. We feel strongly that we need the ability to store both MHC and Receptor genotype at the subject level if they are known. That is what these fields are for. If you don't know subject level genotype you don't have to store anything!
I admit our experience is more with MHC Genotype for the studies that are looking at MHC/peptide binding, but it is  always subject specific so it would not make any sense to group it with a repertoire.
It is my understanding that in the ideal world, we would know the Subject receptor_genotype_set and that is what would be used for sequence annotation to get the most accurate annotation of a Repertoire for that subject. The experimenter can store their best estimate of what the receptor_genotype_set is for this subject if it has been determined. To me that is the intent of these subject MHC and Receptor Genotype fields.
I am pretty sure I have suggested this before, but if we need the ability to store a receptor_genotype_set as inferred from a Repertoire with that Repertoire, and that can not be considered the Subject receptor_genotype_set then I would suggest we need another field. Maybe another data collection as @schristley suggests, It is this type of receptor_genotype_set that is downstream of DataProcessing (inference_process = repertoire_sequencing). I am not saying this isn't needed...
But that should not detract from the fact that if the experimenter has determined a Subject receptor_genotype_set (e.g. using inference_process = genomic_seqeuncing) they should have the ability to store that with the Subject.

So subject.genotype.mhc_genotype_set.mhc_genotype_list.mhc_class --> subject.mhc_genotype_set.mhc_genotype_list.mhc_class and thus queries would change.

Up one level. So still a property of Subject as per @schristley's comment above

So where do we stand on this for v2.0?

Subject.genotype: Fine to de-nest by moving receptor_genotype_set and mhc_genotype_set up a level. However, this will break backwards compatibility so it needs to wait until v2.0. Additional issues to address in v2.0: (1) should these be arrays and (2) should they be in Repertoire instead of Subject (as they are downstream from DataProcessing).

Personally, I am not sure I understand why we want to move these "up a level". Logically they are both genotype of a subject, so why do we not want to have them represented that way? This is a minor detail, and I don't really care that much, but it seems odd that this is viewed as "better". For v2.0 I would lean toward keeping the subject.genotype but I am not highly invested either way.

"better" only in that the data structure is simpler, and yes it is a minor detail about syntax. The semantics aren't in question. I would ask the reverse question, how are these two field paths:
subject.genotype.mhc_genotype_set.mhc_genotype_list.mhc_class
subject.genotype.receptor_genotype_set.genotype_class_list.locus
better than these two field paths?
subject.mhc_genotype_set.mhc_genotype_list.mhc_class
subject.receptor_genotype_set.genotype_class_list.locus
There doesn't seem to be any specific advantage to the deeper structure with the longer field path.
In other place in the schema, we try to only create these composite objects when it creates a meaningful composite. As William indicated, these two concepts are independent enough that composing them into genotype doesn't seem to add anything.

Ultimately any genotype is going to be derived from experimental data and may, to a greater or lesser extent, be partial. I think it’s important that the underlying data is explicitly referenced. This could be a reference to one or more repertoires, and/or to genomic sequencing, or even a snp array perhaps, together with some indication of the protocol and scope. I’m ok with the idea of storing all genotypes at the subject level. If a genotype has been used to annotate a repertoire, the repertoire should point back to the genotype that was used. I think we should try to avoid any implication that a particular repertoire is comprehensive or otherwise and stick to the description of how it was obtained, as standards will continue to change over time.WilliamOn 8 Feb 2024, at 21:05, Brian Corrie @.***> wrote:
Subject.genotype: Fine to de-nest by moving receptor_genotype_set and mhc_genotype_set up a level. However, this will break backwards compatibility so it needs to wait until v2.0. Additional issues to address in v2.0: (1) should these be arrays and (2) should they be in Repertoire instead of Subject (as they are downstream from DataProcessing).
It doesn't make sense to me to have subject genotype logically stored only at the repertoire level since biologically they are related to the subject. We feel strongly that we need the ability to store both MHC and Receptor genotype at the subject level if they are known. That is what these fields are for. If you don't know subject level genotype you don't have to store anything!
I admit our experience is more with MHC Genotype for the studies that are looking at MHC/peptide binding, but it is  always subject specific so it would not make any sense to group it with a repertoire.
It is my understanding that in the ideal world, we would know the Subject receptor_genotype_set and that is what would be used for sequence annotation to get the most accurate annotation of a Repertoire for that subject. The experimenter can store their best estimate of what the receptor_genotype_set is for this subject if it has been determined. To me that is the intent of these subject MHC and Receptor Genotype fields.
I am pretty sure I have suggested this before, but if we need the ability to store a receptor_genotype_set as inferred from a Repertoire with that Repertoire, and that can not be considered the Subject receptor_genotype_set then I would suggest we need another field. Maybe another data collection as @schristley suggests, It is this type of receptor_genotype_set that is downstream of DataProcessing (inference_process = repertoire_sequencing). I am not saying this isn't needed...
But that should not detract from the fact that if the experimenter has determined a Subject receptor_genotype_set (e.g. using inference_process = genomic_seqeuncing) they should have the ability to store that with the Subject.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

apologies, I meant to say “any implication that a particular genotype is comprehensive…”, not “any particular repertoire”.On 8 Feb 2024, at 22:47, William Lees @.> wrote:Ultimately any genotype is going to be derived from experimental data and may, to a greater or lesser extent, be partial. I think it’s important that the underlying data is explicitly referenced. This could be a reference to one or more repertoires, and/or to genomic sequencing, or even a snp array perhaps, together with some indication of the protocol and scope. I’m ok with the idea of storing all genotypes at the subject level. If a genotype has been used to annotate a repertoire, the repertoire should point back to the genotype that was used. I think we should try to avoid any implication that a particular repertoire is comprehensive or otherwise and stick to the description of how it was obtained, as standards will continue to change over time.WilliamOn 8 Feb 2024, at 21:05, Brian Corrie @.> wrote:
Subject.genotype: Fine to de-nest by moving receptor_genotype_set and mhc_genotype_set up a level. However, this will break backwards compatibility so it needs to wait until v2.0. Additional issues to address in v2.0: (1) should these be arrays and (2) should they be in Repertoire instead of Subject (as they are downstream from DataProcessing).
It doesn't make sense to me to have subject genotype logically stored only at the repertoire level since biologically they are related to the subject. We feel strongly that we need the ability to store both MHC and Receptor genotype at the subject level if they are known. That is what these fields are for. If you don't know subject level genotype you don't have to store anything!
I admit our experience is more with MHC Genotype for the studies that are looking at MHC/peptide binding, but it is  always subject specific so it would not make any sense to group it with a repertoire.
It is my understanding that in the ideal world, we would know the Subject receptor_genotype_set and that is what would be used for sequence annotation to get the most accurate annotation of a Repertoire for that subject. The experimenter can store their best estimate of what the receptor_genotype_set is for this subject if it has been determined. To me that is the intent of these subject MHC and Receptor Genotype fields.
I am pretty sure I have suggested this before, but if we need the ability to store a receptor_genotype_set as inferred from a Repertoire with that Repertoire, and that can not be considered the Subject receptor_genotype_set then I would suggest we need another field. Maybe another data collection as @schristley suggests, It is this type of receptor_genotype_set that is downstream of DataProcessing (inference_process = repertoire_sequencing). I am not saying this isn't needed...
But that should not detract from the fact that if the experimenter has determined a Subject receptor_genotype_set (e.g. using inference_process = genomic_seqeuncing) they should have the ability to store that with the Subject.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

subject.genotype.mhc_genotype_set.mhc_genotype_list.mhc_class subject.genotype.receptor_genotype_set.genotype_class_list.locus
better than these two field paths?
subject.mhc_genotype_set.mhc_genotype_list.mhc_class subject.receptor_genotype_set.genotype_class_list.locus
There doesn't seem to be any specific advantage to the deeper structure with the longer field path.

I don't see the need for the change - which requires work 8-) It is not insignificant work in that it breaks backwards compatibility. AIRR v1 and AIRR v2 files with genotype will no longer be compatible. Repositories need to change, the Gateway needs to change, etc.
I also feel that logically they belong together since they are both genotype. I will bow to your wisdom in terms of whether biologically this is an important concept that is worthy of capturing in the schema. It was my understanding that subject genotype was important.
You can see the redundancy in the naming, which you don't really need in either case - e.g. you could have:
subject.genotype.mhc_set.class_list.class
subject.genotype.receptor_set.class_list.locus
Bottom line is I am fine however the group want to do this. I would suggest that you  clean up some of the redundancy in the naming in either case when you make the changes.

subject.genotype.mhc_genotype_set.mhc_genotype_list.mhc_class subject.genotype.receptor_genotype_set.genotype_class_list.locus
better than these two field paths?
subject.mhc_genotype_set.mhc_genotype_list.mhc_class subject.receptor_genotype_set.genotype_class_list.locus
There doesn't seem to be any specific advantage to the deeper structure with the longer field path.

I don't see the need for the change - which requires work 8-) It is not insignificant work in that it breaks backwards compatibility. AIRR v1 and AIRR v2 files with genotype will no longer be compatible. Repositories need to change, the Gateway needs to change, etc.

Yeah, it's already "out in the wild". If not I'd push to clean it up but now I'm fine with leaving it as the churn isn't likely worth it. Structurally and semantically it is fine, just a little verbose. Besides, it wouldn't be a real spec without a few quirks! ;-D

So have we decided to leave this as is for AIRR 2.0?

From the call:

Not ideal, but let's leave it as is because needless effort.


OpenSslEngine.getSupportedCipherSuites() must return java names as well.

Motivation:
At the moment OpenSslEngine.getSupportedCipherSuites() only return the original openssl cipher names and not the java names. We need also include the java names.
Modifications:
Correctly return the java names as well.
Result:
Correct implementation of OpenSslEngine.getSupportedCipherSuites()

@nmittler @Scottmitch PTAL

Cherry-picked into 4.1 (7c1374dd54fda385ceb384c3d27c6a8d9bab3d10) and 4.1 (77350b7)


use QSerialPortInfo to detect presence of a serial port (fix #836)

Summary

ProviderRs232: checking for existence of device file does not work on windows.

instead: construct QSerialPortInfo from device name and check, if it is not null.
When constructing QSerialPortInfo from device name, this constructor finds the
relevant serial port among the available ones according to the port name name,
and constructs the serial port info instance for that port.
(https://doc.qt.io/qt-5/qserialportinfo.html#QSerialPortInfo-2)

Fixes: #836
What kind of change does this PR introduce? (check at least one)

[x] Bugfix
[ ] Feature
[ ] Code style update
[ ] Refactor
[ ] Docs
[ ] Build-related changes
[ ] Other, please describe:

If changing the UI of web configuration, please provide the before/after screenshot:
Does this PR introduce a breaking change? (check one)

[ ] Yes
[x] No

If yes, please describe the impact and migration path for existing setups:
The PR fulfills these requirements:

[x] When resolving a specific issue, it's referenced in the PR's body (e.g. Fixes: #xxx[,#xxx], where "xxx" is the issue number)

If adding a new feature, the PR's description includes:

[ ] A convincing reason for adding this feature
[ ] Related documents have been updated (docs/docs/en)
[ ] Related tests have been updated

To avoid wasting your time, it's best to open a feature request issue first and wait for approval before working on it.
Other information:

@heikobihr Thanks for the update.
I am currently in the process refactoring the Led-Devices's code which included the Rs232 one.
I have incorporated your input (plus some minor additions).
As it seems you have a serial device running with windows, would you mind testing my development branch from a Windows/Rs232 perspective?
That would be very much appreciated!
Many thanks in advance!

@Lord-Grey
Yes, I am running an adalight serial Port device with hyperion.ng on windows. I'll run a test of your development branch tonight.

I would like it if the available serial devices were transferred to the JsonAPI. With this one could create a drop down field in the WebUI and select connected devices. Examples can be found in the V4L2 Grabber.
QSerialPortInfo Enumerator Example

@paulchen-Panther This is already available as part of my LedDevice Refactor Branch.
When I am back at my PC, I can quickly tell, how you could test it.

@Lord-Grey
I tested your LedDevice Refactor Branch, successfully. Hyperion.ng connects to my adalight and shows rainbow swirl startup effect.

Thank you for contribution and testing.


nodejs  version upgradation from 12 to 14 using ansible scripts

nodejs  version upgraded from 12 to 14 in angular ansible tasks.

Task Completed


broken link

The following link :  see Console Applications (https://docs.microsoft.com/en-us/cpp/windows/console-applications-in-visual-cpp?view=vs-2019) redirects back to this page.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 8c828ff7-367e-cdb9-7573-69e3f87f27a2
Version Independent ID: 39f4562b-606c-4a6a-150a-eade928a85da
Content: Overview of Windows Programming in C++
Content Source: docs/windows/overview-of-windows-programming-in-cpp.md
Product: visual-cpp
Technology: cpp-windows
GitHub Login: @mikeblome
Microsoft Alias: mblome

thanks @eventura1 ! Link has been fixed to go to a better topic. Should be visible by Sept 19


Getting an Invalid Chip in Esp Insights Dashboard

Hello, I am getting an 'Invalid Chip' error in the ESP Insights Web Portal under Nodes.
I have also tried idf.py -DIDF_TARGET=esp32 reconfigure but no luck. Using ESP-IDF 5.1.1 (stable)
I have these in sdkconfig:
CONFIG_IDF_TARGET_ARCH_XTENSA=y
CONFIG_IDF_TARGET_ARCH="xtensa"
CONFIG_IDF_TARGET="esp32"
CONFIG_IDF_TARGET_ESP32=y
CONFIG_ESP_INSIGHTS_ENABLED=y
CONFIG_ESP_INSIGHTS_COREDUMP_ENABLE=y

looks like I had to perform: idf.py -DIDF_TARGET=esp32 reconfigure. I think every time you delete the build folder (or fullclean) the env that sets idf_target gets erased. CONFIG_IDF_TARGET="esp32" doesn't seem to work even though during the build it will say IDF_TARGET is not set, guessed 'esp32' from sdkconfig

Upon investigating looks like on initial call on this block of code it gives the 'invalid chip' error.
However, on the subsequent calls it gets fixed and the Chip shows as ESP32, Project and Chip version also gets populated.
char* sensorPin = get_sensor_pin();
esp_insights_config_t config = {
.log_type = ESP_DIAG_LOG_TYPE_ERROR | ESP_DIAG_LOG_TYPE_WARNING | ESP_DIAG_LOG_TYPE_EVENT,
.node_id = sensorPin,
.auth_key = insights_auth_key_start,
};
esp_err_t ret = esp_insights_init(&config);

@antoniuschan99 thanks for reporting. We will try to reproduce the issue and fix it.
Do you always get this issue once the node is up? Or is it a random issue?

always getting it. I haven't looked into it further as it isn't a showstopper. If you need more info let me know!

Hi @antoniuschan99 as one of the very message after reboot OR on the first boot, sent by ESP-Insights is the boot time data which contains the chip_id.
BTW, can you please let me know if char* sensor_pin = get_sensor_pin(); yields an unique ID and is consistent across reboots?

Hi @antoniuschan99 I am able to re-produce the behaviour.
Here is what I see:
When node starts appearing on the dashboard, it shows the chip as Invalid Chip.
This is just for few seconds and if you refresh the dashboard after, say 5 seconds, it'll show a valid chip.
This behaviour is because, the information is received by Insights' cloud in different message and it might take few seconds till it populates this information. This doesn't need the device to reboot in between, and I think you are mis-interpreting it as getting fixed after reboot.
To make sure, that you are seeing the same as the issue, can you please wait on Invalid chip page for few seconds and if the information changes after the page refresh? (without rebooting the device in between).

ok just saw this. Will test and update you in next few days. thanks!

I will close this issue for now!


How can I disable automatic rendering completely

In my application I am showing mathematical notation with modal flashcards.I am trying to completely disable automatic rendering by setting skipStartupTypeset: true in config. But I found on each click on my divs it renders automatically all residing latex notation. I have removed all my MathJax.Hub.Queue(["Typeset",MathJax.Hub]); codes from my project. But still dont know how typesetting is triggered automatically?
I found that calling MathJax.Hub.Queue(["Typeset",MathJax.Hub]); too many times  my equations get displayed twice and sometimes vanishes. However this always happens with bootstrap modal divs. So for now I am trying to keep a flag and always call MathJax.Hub.Queue(["Typeset",MathJax.Hub]); myself.

If you set skipStartupTypeset: true then MathJax will not typeset (anything) automatically. So I suspect there's some other piece of code triggering MathJax. Without having a live sample, there's not much else to say.


openssl: fix static compilation on windows

Motivation for this change
With the recent MinGW version bump of openssl (https://github.com/NixOS/nixpkgs/pull/108170), the tests no longer build statically for windows. Everything else seems to work. I have not tested the actual functionality of openssl though, just that it builds, and things that depend on it build
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Never mind, I got mixed up. This is not necessary, openssl just works.


Update README.md

:warning: This is a Pull Request Template :warning:

Checkout all the things you've done by placing an x within the square braces below.

Proposed Changes

[x] I've read the CODE OF CONDUCT and abide to it.
[x] I've read the CONTRIBUTING.md
[x] I've forked the repository.
[x] I've created a branch and made my changes in it.
[x] I understand opening a PULL REQUEST doesn't mean it will be merged for sure.

PR #1000 🎉 🎉 🎉 🎉

sorry for the mistake.........I have corrected it! Thank you!!


Source SCSS and js files have version 4.0.0 in the name.

Source SCSS and js files have version 4.0.0 in the name.


Use deepEqual only when needed, optimize multipleOf

Same method implemented better, prefer inlining.
Both have had history inherited back from imjv :-).
Also cleaner code for compare().

Codecov Report

Merging #116 into master will decrease coverage by 0.00%.
The diff coverage is 100.00%.

Impacted Files
Coverage Δ

src/index.js
98.82% <100.00%> (+<0.01%)
:arrow_up:

src/scope-functions.js
100.00% <100.00%> (ø)

multipleOf optimization here is unsafe, i.e may cause false negatives. Will recheck.


Settings screen to choose inputs/outputs (cam/mic/speakers)

What is the feature that you would like to see in the app? Please describe.
A settings screen where the user can choose which inputs/outputs (cam/mic/speakers) are used.
Is your feature request related to a problem? Please describe.
When users have multiple inputs/outputs (like a laptop + external display with built-in cam/mic/speakers), they might want to switch between them for optimal audio/video.
Describe alternatives you've considered
Users might be able to change the cam/mic through their system settings, but this is not ideal.
Additional context
Of course one can implement this themselves, but it would be nice to have it in the demo, as it’s a commonly used feature.

Hey @jhogervorst
You'll be happy to know this feature is actively in development. We will be sure to reference this ticket in any upcoming PRs. Feel free to provide any feedback in PRs as well.
Thanks!

@aaalaniz is there an ETA? Looking to implement this myself also, but may hold off if its coming out within the new few days.

@jhogervorst @RusseII This feature has been merged to master. You can see the PR here: https://github.com/twilio/twilio-video-app-react/pull/185


Add data sharing agreement to the sign up page

Need to add a check box at the bottom of the sign up page with the following text:

[ ] I agree that all of the data I post to this site will be made public according to the Creative Commons Attribution Share Alike License (CC-By-SA).

You should also add the appropriate creative commons license badge/icon below the text:
https://licensebuttons.net/l/by-sa/4.0/88x31.png
Details of the license at: https://creativecommons.org/licenses/by-sa/4.0/
This URL should be linked in some way to the text and/or icon.
If a user does not check this box, do not create an account for them, pop up a message that says:
"To post data to this site, you must agree to the open data license."

Moved this to the next milestone since it was the only one left on 0.1.0.

This is complete, right?


Use model-level scrolling API if available

Depends on https://github.com/atom/atom/pull/9444

For backwards compatibility, this uses the old code-path if if TextEditor::setFirstVisibleScreenRow is not defined.


Move "Edit" cells window to lower position

Modal window, that opened by cells "Edit", should be lower, to be able to see full string you edit (just to size of one row lower of current position).

@wetneb , I'd like to take on this while waiting for feedback on the other issue. Is that okay?


[Bug]:  cannot import name 'Protocol' from 'typing'

Bug Description
After installing by the follwing command: "pip install llama-index"
I got an error of cannot import name 'Protocol' from 'typing'

Many thanks for your reading and support.
Version
0.5.9
Steps to Reproduce
Error after running an install command
Relevant Logs/Tracbacks
No response

Python3.7 is not supported. Can you try updating to a new version? (conda is really good for this, but up to you on how to upgrade)

Many thanks for your reply. I updated my Python to 3.11.0 and it works well. Have a nice day.


Move number_of_shards and number_of_replicas param out of index setting

Signed-off-by: Ankit Kala<EMAIL_ADDRESS>Description
Move the number_of_shards and number_of_replicas as we observed few test runs and these aren't getting honoured.
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 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 #392 (4bc5524) into main (e0dbe95) will decrease coverage by 4.17%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##               main     #392      +/-   ##
============================================
- Coverage     74.90%   70.72%   -4.18%
+ Complexity      996      958      -38
============================================
  Files           141      141
  Lines          4554     4554
  Branches        504      504
============================================
- Hits           3411     3221     -190
- Misses          828     1001     +173
- Partials        315      332      +17

Impacted Files
Coverage Δ

...rch/replication/action/status/ShardInfoResponse.kt
35.29% <0.00%> (-56.31%)
:arrow_down:

...cation/action/changes/TransportGetChangesAction.kt
63.49% <0.00%> (-26.99%)
:arrow_down:

...lication/action/status/TranportShardsInfoAction.kt
80.00% <0.00%> (-20.00%)
:arrow_down:

.../action/status/TransportReplicationStatusAction.kt
79.34% <0.00%> (-18.48%)
:arrow_down:

...ch/replication/task/index/IndexReplicationState.kt
51.66% <0.00%> (-15.00%)
:arrow_down:

...ication/action/setup/TransportSetupChecksAction.kt
59.52% <0.00%> (-14.29%)
:arrow_down:

...ication/seqno/RemoteClusterRetentionLeaseHelper.kt
80.00% <0.00%> (-11.67%)
:arrow_down:

...tion/repository/RemoteClusterMultiChunkTransfer.kt
90.24% <0.00%> (-9.76%)
:arrow_down:

.../replication/metadata/store/ReplicationMetadata.kt
62.96% <0.00%> (-8.65%)
:arrow_down:

...earch/replication/metadata/UpdateIndexBlockTask.kt
74.19% <0.00%> (-6.46%)
:arrow_down:

... and 18 more

Continue to review full report at Codecov.

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


MPNotificationServiceExtension crash when mp_media_url is empty string

Integration Method: CocoaPods
Xcode Version: 11.4.1
Library Version: 3.6.1
Platform: App Extension
Language: Objective-C
Description:
The MPNotificationServiceExtention will cause an uncaught exception if the payload contains an empty string for payload field "mp_media_url":
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[__NSPlaceholderArray initWithObjects:count:]: attempt to insert nil object from objects[0]' *** First throw call stack:
To create an empty "mp_media_url" payload:

In the Mixpanel message creator, enter any text into "Image url" field.
Save the message.
Remove text from "Image url" field. Note that the UI now shows the default, example url in this field now.

This message will now send the empty "mp_media_url".
Expected Behavior:
No crash if "mp_media_url" is an empty string.

Mixpanel is deprecating Messaging and Mobile A/B testing features(more details), please contact our support if you need to continue the conversation for any critical issues. Sorry for the inconvenience.


Adds the ClientInfo object + fields to TokenResponse

Creates the POJO for ClientInfo, adds it as a field on AzureActiveDirectoryTokenResponse

Also adds fields ext_expires_on -> 'Resiliency' and not_before token issuance tracking


Unable to provide different values of spring.config.import.configserver since 2020.0.4

Describe the bug
Spring Cloud version = 2020.0.4+
Issue
When providing multiple values as list for config server url, the last URL is only used.
The call is also tried 4 times because 4 imports have been provided.
My expectation is at any time only 1 of the 4 placeholders will have value and the springboot app will be automatically be able to use that to call the config server of that environment level.
Sample
Providing configuration in application.yml
spring:
  config:
    import:
      - optional:configserver:\${vcap.services.config-service-development.credentials.uri}
      - optional:configserver:\${vcap.services.config-service-integration.credentials.uri}
      - optional:configserver:\${vcap.services.config-service-volume.credentials.uri}
      - optional:configserver:\${vcap.services.config-service-production.credentials.uri}

Logs:
{"timestamp":"2021-12-07T15:43:14.969Z","msg":"The following profiles are active: local","logger":"c.l.MyApplication","thread":"main","level":"INFO","app":"my-app}
{"timestamp":"2021-12-07T15:43:15.015Z","msg":"Could not locate PropertySource ([ConfigServerConfigDataResource@fff25f1 uris = array['\${vcap.services.config-service-production.credentials.uri}'], optional = true, profiles = list['local']]): Invalid URL: \${vcap.services.config-service-production.credentials.uri}","logger":"o.s.b.c.c.ConfigDataLoader","thread":"main","level":"WARN","app":"my-app"}}
{"timestamp":"2021-12-07T15:43:15.015Z","msg":"Could not locate PropertySource ([ConfigServerConfigDataResource@263f04ca uris = array['\${vcap.services.config-service-production.credentials.uri}'], optional = true, profiles = list['local']]): Invalid URL: \${vcap.services.config-service-production.credentials.uri}","logger":"o.s.b.c.c.ConfigDataLoader","thread":"main","level":"WARN","app":"my-app"}}
{"timestamp":"2021-12-07T15:43:15.015Z","msg":"Could not locate PropertySource ([ConfigServerConfigDataResource@2ca47471 uris = array['\${vcap.services.config-service-production.credentials.uri}'], optional = true, profiles = list['local']]): Invalid URL: \${vcap.services.config-service-production.credentials.uri}","logger":"o.s.b.c.c.ConfigDataLoader","thread":"main","level":"WARN","app":"my-app"}}
{"timestamp":"2021-12-07T15:43:15.015Z","msg":"Could not locate PropertySource ([ConfigServerConfigDataResource@5a021cb9 uris = array['\${vcap.services.config-service-production.credentials.uri}'], optional = true, profiles = list['local']]): Invalid URL: \${vcap.services.config-service-production.credentials.uri}","logger":"o.s.b.c.c.ConfigDataLoader","thread":"main","level":"WARN","app":"my-app"}

Can you provide a complete, minimal, verifiable sample that reproduces the problem? It should be available as a GitHub (or similar) project or attached to this issue as a zip file.

Attaching the zip file as requested. It is a simple springboot app initialized from the spring initializer with spring cloud config client dependency.
cloud-config-issue-sample-app.zip

The problem appears to be here https://github.com/spring-cloud/spring-cloud-config/blob/main/spring-cloud-config-client/src/main/java/org/springframework/cloud/config/client/ConfigServerConfigDataLocationResolver.java#L122

Will this fix be available in 2020.0.5 or the latest version planned for that release as well ?

We can try and port it to the 2020.0.x release train as well.


Improve acronym function names

Task
Resolves: #221
Description
IAMBinding -> iamBinding
IamAuditConfig -> iamAuditConfig
OrganizationPolicy -> organizationPolicy
This one is a bit awkward, but it's not our fault they called it VMware instead of Vmware:
VMwareCluster -> vMwareCluster

For the record, here is the list with "tricky" type/resource names for providers supported by pulumi-kotlin (kudos to @jplewa for generating it):
Open the list

AAAARecord
AADDataConnector
AATPDataConnector
ACIService
ACL
ADCCatalog
ADLSGen1FileDataSet
ADLSGen1FolderDataSet
ADLSGen2FileDataSet
ADLSGen2FileDataSetMapping
ADLSGen2FileSystemDataSet
ADLSGen2FileSystemDataSetMapping
ADLSGen2FolderDataSet
ADLSGen2FolderDataSetMapping
AFDCustomDomain
AFDEndpoint
AFDOrigin
AFDOriginGroup
AKSService
APIService
APIServiceList
APIServicePatch
ARecord
ASCDataConnector
AScript
CACertificate
CNameRecord
CRL
CSIDriver
CSIDriverList
CSIDriverPatch
CSINode
CSINodeList
CSINodePatch
CSIStorageCapacity
CSIStorageCapacityList
CSIStorageCapacityPatch
DBAuditInstance
DBCluster
DBClusterLakeVersion
DBClusterParameterGroup
DBInstance
DBParameterGroup
DBProxy
DBProxyEndpoint
DBProxyTargetGroup
DBSubnetGroup
DHCPOptions
DNSSEC
DRTAccess
EC2Fleet
EIP
FHIRDatastore
GCPolicy
HAVip
HAVipAttachment
HBaseCluster
IAMAuditConfig
IAMBinding
IAMCustomRole
IAMMember
IAMPolicy
IPAM
IPAMAllocation
IPAMPool
IPAMPoolCidr
IPAMResourceDiscovery
IPAMResourceDiscoveryAssociation
IPAMScope
IPAddress
IPAddressList
IPAddressPatch
IPGroup
IPGroupCIDR
IPSet
IPv6FirewallRule
IVPCEConfiguration
MCASDataConnector
MDATPDataConnector
MECRole
MHSMPrivateEndpointConnection
MLTransform
MSIXPackage
OIDCProvider
PTRRecord
SAMLProvider
SAPApplicationServerInstance
SAPCentralInstance
SAPDatabaseInstance
SAPVirtualInstance
SRVRecord
SSLCertificate
SSLPolicy
TIDataConnector
URLMap
VCenter
VMWareReplicationPolicy
VMwareCluster
VMwareCollector
VMwareNodePool
VNetPeering
VPC
VPCConnection
VPCDHCPOptionsAssociation
VPCEConfiguration
VPCEndpoint
VPCEndpointService
VPCEndpointServicePermissions
VPCPeeringConnection
VPNConnection
VPNConnectionRoute
VPNGateway
VPNTunnel
WCFRelay
WCFRelayAuthorizationRule

I'm wondering how we handle these:

IPv6FirewallRule
IPGroupCIDR
EC2Fleet

I'm wondering how we handle these:

IPv6FirewallRule
IPGroupCIDR
EC2Fleet

IPv6FirewallRule -> iPv6FirewallRule
IPGroupCIDR -> ipGroupCIDR
EC2Fleet -> eC2Fleet
The first two seem fine to me. iPv6FirewallRule is a bit awkward, but I'd say it's correct looking at the actual class name. Tbh, the actual class name is weird to me, since I'd rather call the class Ipv6FirewallRule (see: https://stackoverflow.com/questions/34529999/camel-case-name-for-class-with-ipv4). The only one I'm wondering about is EC2Fleet. Maybe the rule should be "make upper case letters lowercase until you encounter the final upper-case letter or a number"? So that we end up with ec2Fleet?

LGTM. Left a couple of minor comments, but feel free to merge now.

Can't merge, because this is branched off of https://github.com/VirtuslabRnD/pulumi-kotlin/pull/241 ;)


Bump Torchserve version to 0.7.0

Upgrade Torchserve version to v0.7.0
Upgrade KServe version to v0.9.0
Support PyTorch 1.13

Torchserve Release Notes: https://github.com/pytorch/serve/releases/tag/v0.7.0
Signed-off-by: Jagadeesh J<EMAIL_ADDRESS>
What this PR does / why we need it:
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Type of changes
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Feature/Issue validation/testing:
Please describe the tests that you ran to verify your changes and relevent result summary. Provide instructions so it can be reproduced.
Please also list any relevant details for your test configuration.

[ ] Test A

[ ] Test B

Logs

Special notes for your reviewer:

Please confirm that if this PR changes any image versions, then that's the sole change this PR makes.

Checklist:

[ ] Have you added unit/e2e tests that prove your fix is effective or that this feature works?
[ ] Has code been commented, particularly in hard-to-understand areas?
[ ] Have you made corresponding changes to the documentation?

Release note:

Thanks @jagadeeshi2i
/lgtm
/approve


Generate NGen symbols in parallel

@sharwell, this one makes sense when you are running on a machine with few resources, but I am concerned that on production machines where the machines may be running quite hot, that this is going to have an adverse impact on the workloads on the machine.  I would be OK making this an opt-in if you have cases where it makes a huge difference and you control the environment, but I don't want to make this the default.

This primarily improves the time to complete a Merge and Zip operation the first time. My concern is that we implement this change only to have it not improve the time it takes for end users to complete this operation on demand. Do you have a suggestion for how we can implement this? Perhaps an opt-out instead of an opt-in?

I hear you.  The concern that I have is that there is a trade-off here.  If the machine is not loaded, then this might be OK, and will complete the merge and zip faster.  But if the machine is loaded, then this could impact availability, and still likely won't complete much faster.  Today, most people that I talk to have an expectation that capturing a trace will have a small impact on latency, but that's about it.  I realize we're not running under a job object (perhaps this is something we should consider), but I still want to make sure that we are not hogging too much in the way of resources.  Do you have specific scenarios that you're trying to improve the speed on?  Perhaps there is a way for us to detect this and run concurrently.

The three cases of most interest to me are:

Merge and/or Zip from within the PerfView UI.
Merge and/or Zip that occurs when PerfView is launched from the command line with -merge and/or -zip.
Merge and Zip that occurs during post processing of a recording captured by the Report a Problem tool in Visual Studio. I'm not sure this one is implemented directly by this repository, so it may or may not be covered directly by this PR.


kernel module build

I want to develop a misc character device as the interface between a user application (such as the hook application in src_extended_examples_hook) and the protected kernel. I have complete the lkm source code,but, I wonder how can I compile the driver`s source code along with the extended source code(in src_extended_hook_example)?  for example, after configuration, I just need to run make , the module`s makefile can be executed as well.
I study the way that you build bareflank.ko, but is there some way to compile my module with modifying the code in directory src_* but not the hypervisor.
thanks!!!

I note that tools/scripts has benn removed, I used this hypervisor in ubuntu16.04 by  modifying the setup_ubuntu.sh, which works with cmake  version 3.5.1, how can solove the problem mentioned above thanks

There really isn't a way to compile a userspace application using the kernel build system, they have to be treated as two different projects as their build systems are vastly different.
Using CMake, you can however treat them as different projects, while still compiling them with a single make command. To do this, you will need three CMakeLists.txt files. One to compile userspace code, one to compile kernel code, and then a third that uses ExternalProject_Add for both projects to compile both using a single make command. We basically do that today, with the one exception that the driver has to still be explicitly compiled (although at one point we had make compiling everything). Just depends on what you add to the ALL target.
Hope that helps.


Panic: "failed to update wallet"

Current Behavior
ERROR	data	failed to persist data usage	{"error": "transaction failed (attempt 30): failed to track ingress: failed to insert stat: database is locked"}
PANIC	wallet	failed to update wallet	{"error": "transaction failed (attempt 30): failed to set last wallet change: database is locked", "changeID": "26ab4e3ea842d16cb13a5925ba44ead37c095133ac2abf73341798fd16d5a878", "height": 59961}
panic: failed to update wallet
goroutine 12017740 [running]:
go.uber.org/zap/zapcore.CheckWriteAction.OnWrite(0x80?, 0x3?, {0x3?, 0x0?, 0x0?})
go.uber.org/zap@v1.26.0/zapcore/entry.go:196 +0x78
go.uber.org/zap/zapcore.(*CheckedEntry).Write(0x4000aa0000, {0x4001176480, 0x3, 0x3})
go.uber.org/zap@v1.26.0/zapcore/entry.go:262 +0x2c0
go.uber.org/zap.(*Logger).Panic(0x6cd142a83e4eab26?, {0xf96734?, 0x40?}, {0x4001176480, 0x3, 0x3})
go.uber.org/zap@v1.26.0/logger.go:284 +0x54
go.sia.tech/hostd/wallet.(*SingleAddressWallet).ProcessConsensusChange(_, {{0x26, 0xab, 0x4e, 0x3e, 0xa8, 0x42, 0xd1, 0x6c, 0xb1, ...}, ...})
go.sia.tech/hostd/wallet/wallet.go:749 +0x13e0
go.sia.tech/siad/modules/consensus.(*ConsensusSet).updateSubscribers(0x40000d6b00, {{0x0, 0x0, 0x0}, {0x40010d19e0, 0x1, 0x1}})
go.sia.tech/siad@v1.5.10-0.20230228235644-3059c0b930ca/modules/consensus/subscribe.go:136 +0x244
go.sia.tech/siad/modules/consensus.(*ConsensusSet).managedAcceptBlocks(0x40000d6b00, {0x40005b1c78, 0x1, 0x1})
go.sia.tech/siad@v1.5.10-0.20230228235644-3059c0b930ca/modules/consensus/accept.go:318 +0x5bc
go.sia.tech/siad/modules/consensus.(*ConsensusSet).threadedRPCRelayHeader.func5.(*ConsensusSet).managedReceiveBlock.func1({0x1a5bd18?, 0x400223ab20})
go.sia.tech/siad@v1.5.10-0.20230228235644-3059c0b930ca/modules/consensus/synchronize.go:535 +0xfc
go.sia.tech/siad/modules/gateway.(*Gateway).managedRPC(0x400054c900, {0x400017c2d0, 0x13}, {0xf851c2, 0x7}, 0x400058ac30)
go.sia.tech/siad@v1.5.10-0.20230228235644-3059c0b930ca/modules/gateway/rpc.go:70 +0x26c
go.sia.tech/siad/modules/gateway.(*Gateway).RPC(0x400054c900, {0x400017c2d0, 0x13}, {0xf851c2, 0x7}, 0x40001b0460?)
go.sia.tech/siad@v1.5.10-0.20230228235644-3059c0b930ca/modules/gateway/rpc.go:83 +0xb0
go.sia.tech/siad/modules/consensus.(*ConsensusSet).threadedRPCRelayHeader.func5()
go.sia.tech/siad@v1.5.10-0.20230228235644-3059c0b930ca/modules/consensus/synchronize.go:465 +0x15c
created by go.sia.tech/siad/modules/consensus.(*ConsensusSet).threadedRPCRelayHeader in goroutine 12017738
go.sia.tech/siad@v1.5.10-0.20230228235644-3059c0b930ca/modules/consensus/synchronize.go:463 +0x39c
Expected Behavior
No panic
Steps to Reproduce

Version
0b73159
What operating system did the problem occur on (e.g. Ubuntu 22.04, macOS 12.0, Windows 11)?

Anything else?
Reported by newOne on Discord

This should get better when we reduce the number of active database writers in #264


Question on: unique.seqs

Hi,
I have a total of 14430026 sequences after screen.seq. But after unique.seq, there is only 618,368 unique sequences. Is it normal when I have around 4% unique sequences?
It is soil, rhizosphere and root samples and I used V4.
Thank you,
Dung

That seems reasonable.

On Jun 9, 2021, at 10:15, dungtran2612 @.***> wrote:
Hi,
I have a total of 14430026 sequences after screen.seq. But after unique.seq, there is only 618,368 unique sequences. Is it normal when I have around 4% unique sequences?
It is soil, rhizosphere and root samples and I used V4.
Thank you,
Dung
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/mothur/mothur.github.io/issues/59, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJUUBFBTT26QW3RV7P6UQ3TR5ZORANCNFSM46MEJBWA.

Thank you, Dr. Schloss.
After finishing all commands in your SOP, I have a total of 202,238 sequences. The chimera step removed 25% of my data. I used chimera.uchime command. In your SOP, you mentioned 8% is a reasonable using vsearch. Is it normal 25% of data to be flagged as chimeric?
Thank you.

We sometimes see up to 25 or 30% of all sequences being flagged as chimeric. If you have questions about the pipeline, I’d encourage you to post them to the forum.
THanks,
Pat

On Jun 9, 2021, at 11:00, dungtran2612 @.***> wrote:
Thank you, Dr. Schloss.
After finishing all commands in your SOP, I have a total of 202,238 sequences. The chimera step removed 25% of my data. I used chimera.uchime command. In your SOP, you mentioned 8% is a reasonable using vsearch. Is it normal 25% of data to be flagged as chimeric?
Thank you.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/mothur/mothur.github.io/issues/59#issuecomment-857771668, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJUUBC6SBNUG4V3YYYAM3TTR562RANCNFSM46MEJBWA.


tf_trt_models's 'camera_tf_trt.py'

I was carring out tf_trt_models. I don't know how to leave a question there, so I ask a question here.
I always get 'python3 camera_tf_trt.py' error when I do this.
2020-04-13 17:11:35.407792: E tensorflow/compiler/tf2tensorrt/utils/trt_logger.cc:41] DefaultLogger (Unnamed Layer* 3) [Convolution]: at least three non-batch dimensions are required for input
2020-04-13 17:11:35.423809: E tensorflow/compiler/tf2tensorrt/utils/trt_logger.cc:41] DefaultLogger (Unnamed Layer* 9) [Convolution]: at least three non-batch dimensions are required for input
Segmentation fault (core dumped)
I want to know how to get rid of this error.

What version of tensorflow and TensorRT are you using?  And which platform or which GPU are you running the code with?

Tensorflow : 1.14.0
TensorRT : <IP_ADDRESS>
platform : JestonTX2

I have no idea why you get this error.  Would you be able to reproduce the error with my tf_trt_models code?  Please show me the procedure to reproduce the error.

git clone tf_trt_models
create a new directory(ssd_mobilenet_v2_face) in tf_trt_models/data.
Put the .ckpt file, .config file, .frozen_inference_graph.pb, object-detection.pbtxt file in the that directory.
Add my model to the 'egohands_models.py'  file in tf_trt_models/utils.
'ssd_mobilenet_v2_face': {         'config_path': 'data/ssd_mobilenet_v2_face.config',         'checkpoint_path': 'data/ssd_mobilenet_v2_face/model.ckpt-22275',     },
run python3 camera_tf_trt.py --image --filename image1.jpeg --model ssd_mobilenet_v2_face --labelmap data/object-detection.pbtxt --num-classes 1 --build

Just running this code makes the same error
: python3 camera_tr_trt.py --usb --model ssd_mobilenet_v1_coco --build

python3 camera_tf_trt.py --image --filename image1.jpeg --model ssd_mobilenet_v2_face --labelmap data/object-detection.pbtxt --num-classes 1 --build
2020-04-13 16:53:12.396494: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcudart.so.10.0
2020-04-13 16:53:24.173083: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcudart.so.10.0
INFO:main:called with args: Namespace(conf_th=0.3, do_build=True, do_tensorboard=False, filename='image1.jpeg', image_height=480, image_width=640, labelmap_file='data/object-detection.pbtxt', model='ssd_mobilenet_v2_face', num_classes=1, rtsp_latency=200, rtsp_uri=None, use_file=False, use_image=True, use_rtsp=False, use_usb=False, video_dev=0)
INFO:main:reading label map
WARNING:tensorflow:From /home/hyebin/.local/lib/python3.6/site-packages/object_detection-0.1-py3.6.egg/object_detection/utils/label_map_util.py:131: The name tf.gfile.GFile is deprecated. Please use tf.io.gfile.GFile instead.
INFO:main:building TRT graph and saving to pb: ./data/ssd_mobilenet_v2_face_trt.pb
WARNING:tensorflow:From /home/hyebin/.local/lib/python3.6/site-packages/slim-0.1-py3.6.egg/nets/inception_resnet_v2.py:373: The name tf.GraphKeys is deprecated. Please use tf.compat.v1.GraphKeys instead.
WARNING:tensorflow:From /home/hyebin/.local/lib/python3.6/site-packages/slim-0.1-py3.6.egg/nets/mobilenet/mobilenet.py:389: The name tf.nn.avg_pool is deprecated. Please use tf.nn.avg_pool2d instead.
WARNING:tensorflow:From /home/hyebin/tf_trt_models/tf_trt_models/detection.py:154: The name tf.ConfigProto is deprecated. Please use tf.compat.v1.ConfigProto instead.
WARNING:tensorflow:From /home/hyebin/tf_trt_models/tf_trt_models/detection.py:158: The name tf.Session is deprecated. Please use tf.compat.v1.Session instead.
2020-04-13 16:53:26.036398: W tensorflow/core/platform/profile_utils/cpu_utils.cc:98] Failed to find bogomips in /proc/cpuinfo; cannot determine CPU frequency
2020-04-13 16:53:26.037794: I tensorflow/compiler/xla/service/service.cc:168] XLA service 0x27fdc820 executing computations on platform Host. Devices:
2020-04-13 16:53:26.037913: I tensorflow/compiler/xla/service/service.cc:175]   StreamExecutor device (0): ,
2020-04-13 16:53:26.056882: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcuda.so.1
2020-04-13 16:53:26.189656: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:972] ARM64 does not support NUMA - returning NUMA node zero
2020-04-13 16:53:26.190243: I tensorflow/compiler/xla/service/service.cc:168] XLA service 0x295e2c70 executing computations on platform CUDA. Devices:
2020-04-13 16:53:26.190357: I tensorflow/compiler/xla/service/service.cc:175]   StreamExecutor device (0): NVIDIA Tegra X2, Compute Capability 6.2
2020-04-13 16:53:26.191407: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:972] ARM64 does not support NUMA - returning NUMA node zero
2020-04-13 16:53:26.191818: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1640] Found device 0 with properties:
name: NVIDIA Tegra X2 major: 6 minor: 2 memoryClockRate(GHz): 1.02
pciBusID: 0000:00:00.0
2020-04-13 16:53:26.191992: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcudart.so.10.0
2020-04-13 16:53:26.192243: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcublas.so.10.0
2020-04-13 16:53:26.192414: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcufft.so.10.0
2020-04-13 16:53:26.192566: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcurand.so.10.0
2020-04-13 16:53:26.231992: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcusolver.so.10.0
2020-04-13 16:53:26.255495: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcusparse.so.10.0
2020-04-13 16:53:26.255963: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcudnn.so.7
2020-04-13 16:53:26.256444: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:972] ARM64 does not support NUMA - returning NUMA node zero
2020-04-13 16:53:26.257075: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:972] ARM64 does not support NUMA - returning NUMA node zero
2020-04-13 16:53:26.257316: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1763] Adding visible gpu devices: 0
2020-04-13 16:53:29.166914: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1181] Device interconnect StreamExecutor with strength 1 edge matrix:
2020-04-13 16:53:29.167239: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1187]      0
2020-04-13 16:53:29.167399: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1200] 0:   N
2020-04-13 16:53:29.168219: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:972] ARM64 does not support NUMA - returning NUMA node zero
2020-04-13 16:53:29.168838: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:972] ARM64 does not support NUMA - returning NUMA node zero
2020-04-13 16:53:29.169174: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1326] Created TensorFlow device (/job:localhost/replica:0/task:0/device:GPU:0 with 256 MB memory) -> physical GPU (device: 0, name: NVIDIA Tegra X2, pci bus id: 0000:00:00.0, compute capability: 6.2)
WARNING:tensorflow:From /home/hyebin/.local/lib/python3.6/site-packages/object_detection-0.1-py3.6.egg/object_detection/exporter.py:374: The name tf.gfile.MakeDirs is deprecated. Please use tf.io.gfile.makedirs instead.
WARNING:tensorflow:From /home/hyebin/.local/lib/python3.6/site-packages/object_detection-0.1-py3.6.egg/object_detection/exporter.py:130: The name tf.placeholder is deprecated. Please use tf.compat.v1.placeholder instead.
WARNING:tensorflow:From /home/hyebin/.local/lib/python3.6/site-packages/object_detection-0.1-py3.6.egg/object_detection/exporter.py:327: to_float (from tensorflow.python.ops.math_ops) is deprecated and will be removed in a future version.
Instructions for updating:
Use tf.cast instead.
WARNING:tensorflow:From /home/hyebin/.local/lib/python3.6/site-packages/object_detection-0.1-py3.6.egg/object_detection/core/preprocessor.py:2340: The name tf.image.resize_images is deprecated. Please use tf.image.resize instead.
WARNING:tensorflow:From /home/hyebin/.local/lib/python3.6/site-packages/object_detection-0.1-py3.6.egg/object_detection/meta_architectures/ssd_meta_arch.py:390: The name tf.variable_scope is deprecated. Please use tf.compat.v1.variable_scope instead.
WARNING:tensorflow:From /home/hyebin/.local/lib/python3.6/site-packages/object_detection-0.1-py3.6.egg/object_detection/core/box_predictor.py:704: The name tf.logging.info is deprecated. Please use tf.compat.v1.logging.info instead.
INFO:tensorflow:depth of additional conv before box predictor: 0
INFO:tensorflow:depth of additional conv before box predictor: 0
INFO:tensorflow:depth of additional conv before box predictor: 0
INFO:tensorflow:depth of additional conv before box predictor: 0
INFO:tensorflow:depth of additional conv before box predictor: 0
INFO:tensorflow:depth of additional conv before box predictor: 0
WARNING:tensorflow:From /home/hyebin/.local/lib/python3.6/site-packages/object_detection-0.1-py3.6.egg/object_detection/core/box_list_ops.py:687: add_dispatch_support..wrapper (from tensorflow.python.ops.array_ops) is deprecated and will be removed in a future version.
Instructions for updating:
Use tf.where in 2.0, which has the same broadcast rule as np.where
WARNING:tensorflow:From /home/hyebin/.local/lib/python3.6/site-packages/object_detection-0.1-py3.6.egg/object_detection/exporter.py:356: get_or_create_global_step (from tensorflow.contrib.framework.python.ops.variables) is deprecated and will be removed in a future version.
Instructions for updating:
Please switch to tf.train.get_or_create_global_step
WARNING:tensorflow:From /home/hyebin/.local/lib/python3.6/site-packages/object_detection-0.1-py3.6.egg/object_detection/exporter.py:402: The name tf.train.Saver is deprecated. Please use tf.compat.v1.train.Saver instead.
2020-04-13 16:54:39.451085: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:972] ARM64 does not support NUMA - returning NUMA node zero
2020-04-13 16:54:39.451470: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1640] Found device 0 with properties:
name: NVIDIA Tegra X2 major: 6 minor: 2 memoryClockRate(GHz): 1.02
pciBusID: 0000:00:00.0
2020-04-13 16:54:39.451730: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcudart.so.10.0
2020-04-13 16:54:39.451860: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcublas.so.10.0
2020-04-13 16:54:39.451982: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcufft.so.10.0
2020-04-13 16:54:39.452079: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcurand.so.10.0
2020-04-13 16:54:39.452174: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcusolver.so.10.0
2020-04-13 16:54:39.452268: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcusparse.so.10.0
2020-04-13 16:54:39.452384: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcudnn.so.7
2020-04-13 16:54:39.452825: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:972] ARM64 does not support NUMA - returning NUMA node zero
2020-04-13 16:54:39.453349: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:972] ARM64 does not support NUMA - returning NUMA node zero
2020-04-13 16:54:39.453577: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1763] Adding visible gpu devices: 0
2020-04-13 16:54:39.458367: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:972] ARM64 does not support NUMA - returning NUMA node zero
2020-04-13 16:54:39.458778: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1640] Found device 0 with properties:
name: NVIDIA Tegra X2 major: 6 minor: 2 memoryClockRate(GHz): 1.02
pciBusID: 0000:00:00.0
2020-04-13 16:54:39.458958: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcudart.so.10.0
2020-04-13 16:54:39.459068: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcublas.so.10.0
2020-04-13 16:54:39.459163: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcufft.so.10.0
2020-04-13 16:54:39.459255: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcurand.so.10.0
2020-04-13 16:54:39.459351: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcusolver.so.10.0
2020-04-13 16:54:39.459444: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcusparse.so.10.0
2020-04-13 16:54:39.459535: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcudnn.so.7
2020-04-13 16:54:39.459865: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:972] ARM64 does not support NUMA - returning NUMA node zero
2020-04-13 16:54:39.460401: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:972] ARM64 does not support NUMA - returning NUMA node zero
2020-04-13 16:54:39.460646: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1763] Adding visible gpu devices: 0
2020-04-13 16:54:39.460755: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1181] Device interconnect StreamExecutor with strength 1 edge matrix:
2020-04-13 16:54:39.460808: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1187]      0
2020-04-13 16:54:39.460854: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1200] 0:   N
2020-04-13 16:54:39.461287: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:972] ARM64 does not support NUMA - returning NUMA node zero
2020-04-13 16:54:39.461843: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:972] ARM64 does not support NUMA - returning NUMA node zero
2020-04-13 16:54:39.462122: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1326] Created TensorFlow device (/job:localhost/replica:0/task:0/device:GPU:0 with 256 MB memory) -> physical GPU (device: 0, name: NVIDIA Tegra X2, pci bus id: 0000:00:00.0, compute capability: 6.2)
WARNING:tensorflow:From /usr/local/lib/python3.6/dist-packages/tensorflow/python/training/saver.py:1276: checkpoint_exists (from tensorflow.python.training.checkpoint_management) is deprecated and will be removed in a future version.
Instructions for updating:
Use standard file APIs to check for files with this prefix.
INFO:tensorflow:Restoring parameters from data/ssd_mobilenet_v2_face/model.ckpt-22275
2020-04-13 16:55:31.360851: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:972] ARM64 does not support NUMA - returning NUMA node zero
2020-04-13 16:55:31.361197: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1640] Found device 0 with properties:
name: NVIDIA Tegra X2 major: 6 minor: 2 memoryClockRate(GHz): 1.02
pciBusID: 0000:00:00.0
2020-04-13 16:55:31.361361: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcudart.so.10.0
2020-04-13 16:55:31.361467: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcublas.so.10.0
2020-04-13 16:55:31.361562: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcufft.so.10.0
2020-04-13 16:55:31.361654: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcurand.so.10.0
2020-04-13 16:55:31.361752: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcusolver.so.10.0
2020-04-13 16:55:31.362002: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcusparse.so.10.0
2020-04-13 16:55:31.362099: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcudnn.so.7
2020-04-13 16:55:31.362456: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:972] ARM64 does not support NUMA - returning NUMA node zero
2020-04-13 16:55:31.363060: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:972] ARM64 does not support NUMA - returning NUMA node zero
2020-04-13 16:55:31.363315: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1763] Adding visible gpu devices: 0
2020-04-13 16:55:31.363428: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1181] Device interconnect StreamExecutor with strength 1 edge matrix:
2020-04-13 16:55:31.363482: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1187]      0
2020-04-13 16:55:31.363531: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1200] 0:   N
2020-04-13 16:55:31.363924: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:972] ARM64 does not support NUMA - returning NUMA node zero
2020-04-13 16:55:31.364453: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:972] ARM64 does not support NUMA - returning NUMA node zero
2020-04-13 16:55:31.364730: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1326] Created TensorFlow device (/job:localhost/replica:0/task:0/device:GPU:0 with 256 MB memory) -> physical GPU (device: 0, name: NVIDIA Tegra X2, pci bus id: 0000:00:00.0, compute capability: 6.2)
INFO:tensorflow:Restoring parameters from data/ssd_mobilenet_v2_face/model.ckpt-22275
WARNING:tensorflow:From /home/hyebin/.local/lib/python3.6/site-packages/object_detection-0.1-py3.6.egg/object_detection/exporter.py:96: convert_variables_to_constants (from tensorflow.python.framework.graph_util_impl) is deprecated and will be removed in a future version.
Instructions for updating:
Use tf.compat.v1.graph_util.convert_variables_to_constants
WARNING:tensorflow:From /usr/local/lib/python3.6/dist-packages/tensorflow/python/framework/graph_util_impl.py:270: extract_sub_graph (from tensorflow.python.framework.graph_util_impl) is deprecated and will be removed in a future version.
Instructions for updating:
Use tf.compat.v1.graph_util.extract_sub_graph
INFO:tensorflow:Froze 344 variables.
INFO:tensorflow:Converted 344 variables to const ops.
INFO:root:2384 ops in the final graph.
2020-04-13 16:55:45.608605: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:972] ARM64 does not support NUMA - returning NUMA node zero
2020-04-13 16:55:45.608934: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1640] Found device 0 with properties:
name: NVIDIA Tegra X2 major: 6 minor: 2 memoryClockRate(GHz): 1.02
pciBusID: 0000:00:00.0
2020-04-13 16:55:45.609108: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcudart.so.10.0
2020-04-13 16:55:45.609212: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcublas.so.10.0
2020-04-13 16:55:45.609316: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcufft.so.10.0
2020-04-13 16:55:45.609407: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcurand.so.10.0
2020-04-13 16:55:45.609500: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcusolver.so.10.0
2020-04-13 16:55:45.609635: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcusparse.so.10.0
2020-04-13 16:55:45.609730: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcudnn.so.7
2020-04-13 16:55:45.610061: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:972] ARM64 does not support NUMA - returning NUMA node zero
2020-04-13 16:55:45.610551: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:972] ARM64 does not support NUMA - returning NUMA node zero
2020-04-13 16:55:45.610841: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1763] Adding visible gpu devices: 0
2020-04-13 16:55:45.610948: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1181] Device interconnect StreamExecutor with strength 1 edge matrix:
2020-04-13 16:55:45.610998: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1187]      0
2020-04-13 16:55:45.611041: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1200] 0:   N
2020-04-13 16:55:45.611398: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:972] ARM64 does not support NUMA - returning NUMA node zero
2020-04-13 16:55:45.611879: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:972] ARM64 does not support NUMA - returning NUMA node zero
2020-04-13 16:55:45.612138: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1326] Created TensorFlow device (/job:localhost/replica:0/task:0/device:GPU:0 with 256 MB memory) -> physical GPU (device: 0, name: NVIDIA Tegra X2, pci bus id: 0000:00:00.0, compute capability: 6.2)
WARNING:tensorflow:From /home/hyebin/.local/lib/python3.6/site-packages/object_detection-0.1-py3.6.egg/object_detection/exporter.py:285: The name tf.saved_model.builder.SavedModelBuilder is deprecated. Please use tf.compat.v1.saved_model.builder.SavedModelBuilder instead.
WARNING:tensorflow:From /home/hyebin/.local/lib/python3.6/site-packages/object_detection-0.1-py3.6.egg/object_detection/exporter.py:288: build_tensor_info (from tensorflow.python.saved_model.utils_impl) is deprecated and will be removed in a future version.
Instructions for updating:
This function will only be available through the v1 compatibility library as tf.compat.v1.saved_model.utils.build_tensor_info or tf.compat.v1.saved_model.build_tensor_info.
WARNING:tensorflow:From /home/hyebin/.local/lib/python3.6/site-packages/object_detection-0.1-py3.6.egg/object_detection/exporter.py:294: The name tf.saved_model.signature_def_utils.build_signature_def is deprecated. Please use tf.compat.v1.saved_model.signature_def_utils.build_signature_def instead.
WARNING:tensorflow:From /home/hyebin/.local/lib/python3.6/site-packages/object_detection-0.1-py3.6.egg/object_detection/exporter.py:300: The name tf.saved_model.tag_constants.SERVING is deprecated. Please use tf.saved_model.SERVING instead.
INFO:tensorflow:No assets to save.
INFO:tensorflow:No assets to write.
INFO:tensorflow:SavedModel written to: .generated_model/saved_model/saved_model.pb
WARNING:tensorflow:From /home/hyebin/.local/lib/python3.6/site-packages/object_detection-0.1-py3.6.egg/object_detection/utils/config_util.py:171: The name tf.gfile.Open is deprecated. Please use tf.io.gfile.GFile instead.
INFO:tensorflow:Writing pipeline config file to .generated_model/pipeline.config
INFO:tensorflow:Linked TensorRT version: (5, 1, 6)
INFO:tensorflow:Loaded TensorRT version: (5, 0, 6)
WARNING:tensorflow:TensorRT mismatch. Compiled against version 5.1.6, but loaded 5.0.6. Things may not work
2020-04-13 16:56:30.869236: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:972] ARM64 does not support NUMA - returning NUMA node zero
2020-04-13 16:56:30.869602: I tensorflow/core/grappler/devices.cc:55] Number of eligible GPUs (core count >= 8, compute capability >= 0.0): 0
2020-04-13 16:56:30.869968: I tensorflow/core/grappler/clusters/single_machine.cc:359] Starting new session
2020-04-13 16:56:30.871556: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:972] ARM64 does not support NUMA - returning NUMA node zero
2020-04-13 16:56:30.871899: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1640] Found device 0 with properties:
name: NVIDIA Tegra X2 major: 6 minor: 2 memoryClockRate(GHz): 1.02
pciBusID: 0000:00:00.0
2020-04-13 16:56:30.872109: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcudart.so.10.0
2020-04-13 16:56:30.872230: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcublas.so.10.0
2020-04-13 16:56:30.872327: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcufft.so.10.0
2020-04-13 16:56:30.872421: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcurand.so.10.0
2020-04-13 16:56:30.872615: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcusolver.so.10.0
2020-04-13 16:56:30.872754: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcusparse.so.10.0
2020-04-13 16:56:30.872848: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcudnn.so.7
2020-04-13 16:56:30.873183: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:972] ARM64 does not support NUMA - returning NUMA node zero
2020-04-13 16:56:30.873671: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:972] ARM64 does not support NUMA - returning NUMA node zero
2020-04-13 16:56:30.873923: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1763] Adding visible gpu devices: 0
2020-04-13 16:56:30.874077: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1181] Device interconnect StreamExecutor with strength 1 edge matrix:
2020-04-13 16:56:30.874132: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1187]      0
2020-04-13 16:56:30.874210: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1200] 0:   N
2020-04-13 16:56:30.874580: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:972] ARM64 does not support NUMA - returning NUMA node zero
2020-04-13 16:56:30.875163: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:972] ARM64 does not support NUMA - returning NUMA node zero
2020-04-13 16:56:30.875441: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1326] Created TensorFlow device (/job:localhost/replica:0/task:0/device:GPU:0 with 256 MB memory) -> physical GPU (device: 0, name: NVIDIA Tegra X2, pci bus id: 0000:00:00.0, compute capability: 6.2)
2020-04-13 16:56:40.628278: I tensorflow/compiler/tf2tensorrt/segment/segment.cc:460] There are 156 ops of 29 different types in the graph that are not converted to TensorRT: Fill, Merge, ConcatV2, Switch, Range, ZerosLike, Identity, NonMaxSuppressionV3, Minimum, StridedSlice, ExpandDims, Unpack, TopKV2, Cast, Transpose, Placeholder, Mul, Reshape, ResizeBilinear, Squeeze, Add, Pack, Const, Sub, Greater, Shape, Where, NoOp, GatherV2, (For more information see https://docs.nvidia.com/deeplearning/dgx/tf-trt-user-guide/index.html#supported-ops).
2020-04-13 16:56:40.936112: I tensorflow/compiler/tf2tensorrt/convert/convert_graph.cc:735] Number of TensorRT candidate segments: 1
2020-04-13 16:56:41.096326: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcudart.so.10.0
2020-04-13 16:56:41.111189: E tensorflow/compiler/tf2tensorrt/utils/trt_logger.cc:41] DefaultLogger (Unnamed Layer* 3) [Convolution]: at least three non-batch dimensions are required for input
2020-04-13 16:56:41.111684: E tensorflow/compiler/tf2tensorrt/utils/trt_logger.cc:41] DefaultLogger (Unnamed Layer* 9) [Convolution]: at least three non-batch dimensions are required for input
Segmentation fault (core dumped)

I cannot determine possible root cause by looking at the log above.  But I think you should fix the following problem first.
INFO:tensorflow:Linked TensorRT version: (5, 1, 6)
INFO:tensorflow:Loaded TensorRT version: (5, 0, 6)
WARNING:tensorflow:TensorRT mismatch. Compiled against version 5.1.6, but loaded 5.0.6. Things may not work

Thanks.. I'll try.


entityId should default to null

Having entityId default to "localhost" causes the default configuration of to disagree with the default configuration of Spring Security SAML which is surprising. Leaving it set to null ends up with an entityId of <entityBaseUrl>/saml/metadata as expected. See https://docs.spring.io/autorepo/docs/spring-security-saml/1.0.4.RELEASE/reference/html/configuration-metadata.html

This change allowed my application to authentication with my IdP, so I think it's a solid and worthwhile improvement.

thanks, that makes sense, I pretty much left all the defaults untouched, don't remember why I defaulted entityID to localhost. Probably a selfish act of convenience for my sample apps...

can you also please update the properties doc?

Done! I've updated this PR.


Question: How does the demo work in the browser?

It seems that you're doing the "one-time setup" on the server, but then handling rasterization on the client by using the shaders directly.  (i.e. no ASM.js or WASM)
Is that correct?  Thanks.

Yes.


Use MultivaluedMap (interface) instead of concrete class for method signatures

Some methods in HttpClient incorrectly use MultivaluedHashMap (a concrete class) rather than the general MultivaluedMap interface in their signatures.

Good to go.


asnavfor causes an unwanted scroll

The problem I encounter is that every time the slide is done, the scroll page automatically returns to the top slides while I'm browsing the bottom of the page. when I remove asnavfor, nothing scrolls wrongly
use this jsfiddle to reproduce the bug.
https://jsfiddle.net/ArnOz/g6jjfoww/
====================================================================
Steps to reproduce the problem

...  just run and scroll down for read the content of the page

====================================================================
What is the expected behaviour?
...  the two sliders works with asnavfor
====================================================================
What is observed behaviour?
...  the page is scrolling me to the top every time the slider scrolls
====================================================================
More Details

Which browsers/versions does it happen on?
observed on chrome and firefox, not tested others
Which jQuery/Slick version are you using?
current slick version
Did this work before?
no

Add the options accessibility: false on the second slider, target of the asnavfor seems to solve the problem temporary...

Should be fixed on latest release


SAIC_PHONE_COUNTRY_CODE not present in 0.5.10

Hi,
Version addon used : 0.5.10 stable (not pre-release)
SAIC_PHONE_COUNTRY_CODE is not present in the configuration tab in home assistant, but in the documentation we can read that this parameter shoud be here.
Can you please help ?
Thanks

Sry... My fault. Please reinstall the Addon.

uninstall it, search for updates in the ha addon store, press F5 to refresh the store and reinstall it


Fixes unit_amount for zero_decimal_currencies

Notion card
Summary

Preview

Earlier:

After fix:

Type of change
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

Checklist:

[x] I have manually tested all workflows
[x] I have performed a self-review of my own code
[ ] I have added automated tests for my code

@shivamsinghchahar Can you please review this?


leveldbutil segfaults

Original issue 143 created by humdumdedum on 2013-02-04T21:07:22.000Z:
What steps will reproduce the problem?

run: $ leveldbutil

What is the expected output? What do you see instead?
? / Segmentation fault: 11
What version of the product are you using? On what operating system?
1.9 / Mac OS X 10.8.2 / clang-425.0.24 based on LLVM 3.2
Please provide any additional information below.

I believe this is old (OK on Linux). Please reopen if still occurring.


suffix support

https://github.com/PolymerLabs/polybuild/issues/5

This LGTM with the change made. Will wait to hear if @azakus is down with this update.

LGTM 2, if you can update the README with the new options :)

@azakus updated ;) tell me if i miss something! And thanks for that awesome Polymer tool (and many other)!

@azakus already updated, but i can't test it now :bug:, pls if you can

@azakus last commit with updated bin file for suffix and updated deps, i tested, working excellent :yum:

LGTM for a merge. Thank you, @arturparkhisenko! :cake:


[Event Request] CU90 Purch. Post

Hello,
can we please add:
`
local procedure PostItemChargePerRcpt(PurchHeader: Record "Purchase Header"; var PurchLine: Record "Purchase Line")
var
PurchRcptLine: Record "Purch. Rcpt. Line";
TempItemLedgEntry: Record "Item Ledger Entry" temporary;
ItemTrackingMgt: Codeunit "Item Tracking Management";
Sign: Decimal;
DistributeCharge: Boolean;
begin
if not PurchRcptLine.Get(
TempItemChargeAssgntPurch."Applies-to Doc. No.", TempItemChargeAssgntPurch."Applies-to Doc. Line No.")
then
Error(ReceiptLinesDeletedErr);
    Sign := 1;
    if PurchRcptLine."Item Rcpt. Entry No." <> 0 then
        DistributeCharge :=
          CostCalcMgt.SplitItemLedgerEntriesExist(
            TempItemLedgEntry, PurchRcptLine."Quantity (Base)", PurchRcptLine."Item Rcpt. Entry No.")
    else begin
        DistributeCharge := true;
        ItemTrackingMgt.CollectItemEntryRelation(TempItemLedgEntry,
          DATABASE::"Purch. Rcpt. Line", 0, PurchRcptLine."Document No.",
          '', 0, PurchRcptLine."Line No.", PurchRcptLine."Quantity (Base)");
    end;
    //added

    OnPostItemChargePerRcptOnBeforePostCharge(PurchHeader, PurchLine, PurchRcptLine);

[IntegrationEvent(false, false)]
local procedure OnPostItemChargePerRcptOnBeforePostCharge(PurchHeader: record "Purchase Header"; PurchLine: Record "Purchase Line"; var PurchRcptLine: record "Purch. Rcpt. Line")
begin
end;
`
This would allow to run custom code before posting item charge.
Thanks,
Bartek

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


Merge from @jblandino to @marcosfermin

Hello @psanders, @cuesto and @marcosfermin .
I made this pull request doing several refactoring to the source code of the project that I found interesting.
Do not use Docker so I did not have time, they can skip the application/config/database.php file completely.
I have many changes which are:

[x] Hooks Creation (Check user session, check if the system is under maintenance).
[x] Add new Global Helper with functions: mask_string and format_number.
[x] New custom configuration file.
[x] New ajax file with available methods (in construction 😄  ).
[x] Refactoring views with img, site_url, anchor and input tags.
[x] Turn off the CSRF security for now and change parameters in config.php file.

Last more time repairing the redirection of the users depending on their credentials and where they are, if they navigate to admin/dashboard without being logged in, they will be able to notice that in the URL a new index called next appears this is to send the Driver where the user was.

Thanks!


DuckDB catalogs config option doesn't commit changes

Context: https://tobiko-data.slack.com/archives/C044BRE5W4S/p1706126317634699
Commit with repro: https://github.com/plaflamme/sqlmesh/commit/0b50c8bb877892053fcc1a4fe6585b316b6667b1
Summary: basically, running sqlmesh plan and immediately running sqlmesh fetchdf … fails when using the catalogs configuration (at least on some models).

@plaflamme This should now be fixed with 0.69.0: https://github.com/TobikoData/sqlmesh/releases/tag/v0.69.0