Error when building tests: Undefined reference to symbol '__c_mset4'

Hello,
I'm trying to build gdrcopy v2.4.1 with v550.54.15 of the GPU drivers and with NVHPC v24.5.
The driver itself - gdrdrv - appears to build successfully but after the build progresses to the tests I get the following error:
/work/y07/shared/cirrus-software/nvidia/hpcsdk-24.5/Linux_x86_64/24.5/cuda/12.4/bin/nvcc
-o gdrcopy_pplat pplat.o common.o
-L /work/y07/shared/cirrus-software/nvidia/hpcsdk-24.5/Linux_x86_64/24.5/cuda/12.4/lib64
-L /work/y07/shared/cirrus-software/nvidia/hpcsdk-24.5/Linux_x86_64/24.5/cuda/12.4/lib
-L /usr/lib64/nvidia
-L /usr/lib/nvidia
-L /work/y07/shared/cirrus-software/nvidia/hpcsdk-24.5/Linux_x86_64/24.5/cuda/12.4/lib64/stubs
-L /work/y07/shared/cirrus-software/nvidia/hpcsdk-24.5/Linux_x86_64/24.5/cuda/12.4/lib64
-L ../src
-lgdrapi -lcuda

/usr/bin/ld: common.o: undefined reference to symbol '__c_mset4'
/work/y07/shared/cirrus-software/nvidia/hpcsdk-24.5/Linux_x86_64/24.5/compilers/lib/libnvc.so: error adding symbols: DSO missing from command line

common.o was built prior as follows:
/work/y07/shared/cirrus-software/nvidia/hpcsdk-24.5/Linux_x86_64/24.5/compilers/bin/nvc++
-O2
-I /work/y07/shared/cirrus-software/nvidia/hpcsdk-24.5/Linux_x86_64/24.5/cuda/12.4/include
-I ../include
-I ../src
-I /work/y07/shared/cirrus-software/nvidia/hpcsdk-24.5/Linux_x86_64/24.5/cuda/12.4/include
-c -o common.o common.cpp

Confirmation that this symbol is undefined within common.o:
> nm -a common.o | grep c_mset4
                 U   __c_mset4

Can you advise on the likely cause of this and how to attempt to resolve?
Note I have tried manually editing src/Makefile to include the fix noted here:  https://github.com/NVIDIA/gdrcopy/pull/284/commits/105b8afff220b7a3d39f0c0e2e37b4b284cfb0ac
however this did not make a difference.

@aproeme please note we have never validated gdrcopy with the HPC compiler.
In any case, you seem to be mixing compilers:

compilers/bin/nvc++ to compile common.cpp
???? to compile pplat.cpp
cuda/12.4/bin/nvcc (which calls the host compiler, most probably gcc) for linking

gcc is probably linking to the libstdc++.
nvc++ may be linking with something else, I did not check.
IMO you should not be mixing toolchains.

Thank you for the quick response, you were right, simply using gcc for everything worked.


[Decompiler] Fix bitfield sets in dma-bucket

There's a bitfield set that's not being decompiled for a number of reasons in dma-buffer-patch-buckets:
    ;; read current value
    lwu a2, 8(a0)
    ld a2, 0(a2)
    ;; load mask
    ld a3, L10(fp)
    ;; clear existing bits using mask
    and a2, a2, a3
    ;; calculate value to set within bitfield
    daddiu a3, a0, 16
    ;; clear upper bits and position value
    dsll32 a3, a3, 1
    dsrl a3, a3, 1
    ;; or bitfield value
    or a2, a2, a3
    ;; compute address for store
    lwu a3, 8(a0)
    ;; store!
    sd a2, 0(a3)

This becomes:
(set! (-> bucket last 0 addr) (the-as int (&+ (the-as pointer bucket) 16)))

There are still two issues with dma-bucket:
(&+! (the-as pointer bucket) 16)

This is originally (set! (the-as pointer bucket) (&+ (the-as pointer bucket) 16)), which is wrong because of the cast on the destination. OpenGOAL will refuse to do this in general, although you could imagine cases where this could be done.  The code is
daddiu a0, a0, 16

where a0 is the same variable in both cases. This might be as easy as "don't cast a register used as a destination".
The second issue is
(+ base (the-as uint (shl idx 4))

where base is a dma-bucket (structure). No idea how this happens, everything looks good:
    dsll v1, a1, 4            ;; (set! v1-0 (sll idx 4))[0] [a1: int ] -> [v1: <value x 16> ]
    daddu v1, a0, v1          ;; (set! bucket (+ base v1-0))[1] [v1: <value x 16> a0: dma-bucket ] -> [v1: dma-bucket ]

This will be fixed in https://github.com/water111/jak-project/pull/367
The first issue was resolved by a combination of "don't cast destination registers" and "don't merge set! and + if the var has a cast when read".
The second issue was a missing case for a cast in addition.


Don't proactively say Clients are unverified because it looks insecure

Unverified terminology is a little too negative / scary. Instead we can just leave the verification status out until the client is verified (keeping pre-existing behavior).
If a user needs verification, they will know to look for the Verification status badge.

@jamilbk what the UX will be if an admin is going to a client trying to see if client is verified? He needs to remember that the row in a vertical table will disappear?

Hm, I think in the table views we just leave the badge off currently, right?
In the details/show, instead of showing in the vertical table maybe we should just show the same icon/badge?
The reason I opened this issue was because of confusion on a sales call. If we show unverified for every client, the admin was asking, "do I need to manually verify each client?" and "what happens if I don't?". I had to explain that it basically means a rogue device could authenticate and connect to your Resources.
Maybe we can call the field "device verification" or "hardware verification" instead, and currently we only support the "manual" verification method. In the future we could support "certificate" or "mdm" for example. If the device is not verified, we could just say "verification status: unknown", which might be better language to use.
I'd be curious to get @bmanifold's opinion here.

what the UX will be if an admin is going to a client trying to see if client is verified?

When an admin needs this feature, they'll look for it. The first time they click the "Verify" button in the Client details page and see the icon pop up, they'll be used to seeing that going forward.
Another option would be to show a greyed-out icon or a different icon, but that might clutter up the table view.

Yeah, I can understand where proactively saying unverified could be off putting to some admins.  I could also see some admins potentially wanting to see it to be able to easily know whether they have verified a given device.
I think the unknown status could be a good compromise.  I feel like having the row in the details be consistently there is probably a good thing.

@bmanifold SGTM. Let's roll with that then - just change the label to Unknown instead of unverified.

So many things come down to naming...

So many things come down to naming...
Indeed.  It's played a much bigger part of my career than I ever would have imagined when I was in school. 😄

What if we just call them not verified? Unknown looks ambiguous, why our client status is unknown for our own system?.. We also have a bit of space in that vertical table, so even can explain a bit more that not verified means no access if there is a policy with verification condition.

It's about the device though. Is the device verified? What does it mean to verify a client? I don't think admins are thinking in terms of clients, right? They just want to make sure an unknown device can't connect to their Resources.
Technically the client is verified to have come from Firezone, Inc. because it is signed.
What could make sense then is to move this field to device attributes and call it device_verification with status not verified. Then in the docs we can explain what this means. Bear in mind though that other systems (notably MDM) will have their own device_verification status that can disagree with ours. In that case, Not verified contradicts the MDM verification and we would want to bridge the two.
In other words, the usability problem evolves into, "how do I verify my devices?" and the answer of "clicking verify" on each client page doesn't make for a great solution, especially if you consider that the admin actually needs to match the reported Hardware ID to manually verify it to make sure it actually is the device they're expecting.
We could accept a CSV or bulk upload of known-good hardware or device serials to match against in the policy and call this feature auto-verification or something. I see that coming soon due to the usability issues above.

What about calling it "New" as in "It is a new device, not seen before"?

WDYT?

We could accept a CSV or bulk upload of known-good hardware or device serials to match against in the policy and call this feature auto-verification or something. I see that coming soon due to the usability issues above. I think most orgs would keep an asset list of this sort in their IT system.

Or we build MDM integrations. So far nobody was asking for it, device verifications right now is a minimal feature which allows companies to be compliant without having an MDM, I think we should just keep it as that until somebody is willing to pay for us to develop it further.

What about calling it "New" as in "It is a new device, not seen before"?

It can be manually de-verified by an admin, that's an extra status then, making things worse.

This one looks even better:

This one looks even better:

This should be good to iterate upon further!


Convert the manual verification function to a command

Access to more features by utilizing the discord.ext.command module.

works fine as is, if anything it helps the verification process as some people cant read properly


Add Stripe Hosted Fields support.

Here is the Postman export for Stripe Hosted Fields
Please do a thorough testing in gateway-stage before merging this PR.
Remaining TODOs before merge:
Testing:

test multi-browsers (Safari, Edge, Chrome, Firefox)
test re-auth + settlement, continuity.
test international cards and postal codes (france, us, canada, etc) & 3DS secure (success & error scenarios for 3DS) - use https://stripe.com/docs/testing#regulatory-cards
test order with 2 line items and ship one at a time to check the capture fund is correct

To be discussed:

localization/translation of the "Complete Payment" button? how?
support for google + apple pay?
move stripe.createPaymentMethod from FE to BE?

Here is the Postman export for Stripe Hosted Fields Please do a thorough testing in gateway-stage before merging this PR.
Remaining TODOs before merge:
Testing:

test multi-browsers (Safari, Edge, Chrome, Firefox)
check with karate team what they have covered with saucelabs.

test re-auth + settlement, continuity.
reauth + settlement. ensure karate team have a split order test.
continuity testing is currently done for adyen as priority. not priority of stripe currently.

test international cards and postal codes (france, us, canada, etc) & 3DS secure (success & error scenarios for 3DS) - use https://stripe.com/docs/testing#regulatory-cards
merchants responsibility to test wide range of cards in their market, we just verify the 3ds integration can be activated

test order with 2 line items and ship one at a time to check the capture fund is correct
covered above.

To be discussed:

localization/translation of the "Complete Payment" button? how?
Not possible, already a backlog item. For now suggest to can make it a variable so it can be configured outside of mapping.

support for google + apple pay?
Our method of apple / google pay integration not supported by stripe since it doesnt use standard apple/google pay cryptograms. we would need to create a new standalone payment method integration using stripes payment buttons.

move stripe.createPaymentMethod from FE to BE?
If it works, leave it.

Jira ticket created: https://cxjira.sap.com/browse/CAAS-38111
I added a new variable for the "Payment button" label, an re-ordered the html/script tags to prevent issue as seen in older PWA.


Duplicating Messages

Connected to irc-ws.chat.twitch.tv:443
Starting the spambot
[21:41:53, #xqcow, score: 157.99]: OMEGALUL
[21:42:52, #xqcow, score: 73.71]: ??????????
[21:42:52, #xqcow, score: 73.71]: ??????????
[21:42:52, #xqcow, score: 73.71]: ??????????
Received notice: msg_ratelimit
Your message was not sent because you are sending messages too quickly.
Stream ended, stopping the spam

I see you're using a version newer than the official release v1.2 and it's been going through some changes, so please make sure to update it, v1.3 is coming in a few days, so for now just pull the newest master branch update. The error inside the switch check for notice messages has already been fixed, althought I don't know what's the reason for 4x duplicate of the message.
One explanation would be that yesterday and 2 days ago Twitch was having big issues with their servers and it could have resulted in message error in the script.
If the issue persists after update please notify me again in this issue, preferably with the starting parameters if you're passing any additional ones except from npm start xqcow.

I see you're using a version newer than the official release v1.2 and it's been going through some changes, so please make sure to update it, v1.3 is coming in a few days, so for now just pull the newest master branch update. The error inside the switch check for notice messages has already been fixed, althought I don't know what's the reason for 4x duplicate of the message.
One explanation would be that yesterday and 2 days ago Twitch was having big issues with their servers and it could have resulted in message error in the script.
If the issue persists after update please notify me again in this issue, preferably with the starting parameters if you're passing any additional ones except from npm start xqcow.


"Invalid character '%' in 'FREQ' FORMAT field" in Varscan germline variant calls

Hello, I'm getting an error during an ensemble pipeline for germline variant calling. It seems that the output of varscan is incorrectly being read by Bcbio, near the end of the whole process, when the batch variant calls are computed.
I am using the latest version of Bcbio, freshly installed yesterday. Is there anything I can do to fix this, besides disabling varscan altogether?

[2017-06-27T18:43Z] multiprocessing: combine_calls
[2017-06-27T18:43Z] Ensemble consensus calls for P10w-comp: gatk-haplotype,freebayes,platypus,samtools,varscan
[2017-06-27T18:43Z] Ensemble intersection calling: P10w-comp
[2017-06-27T18:43Z] 2017-06-27 20:43:19 urga1.cerit-sc.cz INFO [bcbio.run.itx] - [W::bcf_hdr_check_sanity] GL should be declared as Number=G
[2017-06-27T18:43Z] 2017-06-27 20:43:19 urga1.cerit-sc.cz INFO [bcbio.run.itx] - [E::vcf_parse_format] Invalid character '%' in 'FREQ' FORMAT field at chrI:25
[2017-06-27T18:43Z] 2017-06-27 20:43:19 urga1.cerit-sc.cz INFO [bcbio.run.itx] - Error: VCF parse error
[2017-06-27T18:43Z] 2017-06-27 20:43:19 urga1.cerit-sc.cz ERROR [bcbio.run.itx] -
[2017-06-27T18:43Z] java.lang.Exception: Shell command failed: bcftools view -f 'PASS,.' /scratch/amizeranschi/job_54934.wagap-pro.cerit-sc.cz/allDNA-P10w-down-germline/work/gemini/P10w-comp-varscan.vcf.gz -O z -o /scratch/amizeranschi/job_54934.wagap-pro.cerit-sc.cz/allDNA-P10w-down-germline/work/bcbiotx/tmpTLY3JN/P10w-comp-ensemble-work/txtmp4312770904236230970/P10w-comp-varscan-nofilter.vcf.gz
[2017-06-27T18:43Z]                      Error: VCF parse error
[2017-06-27T18:43Z]                      [E::vcf_parse_format] Invalid character '%' in 'FREQ' FORMAT field at chrI:25
[2017-06-27T18:43Z]                                bcbio.run.itx/check-run           itx.clj:  168
[2017-06-27T18:43Z] bcbio.variation.ensemble.intersect/maybe-nofiltered/fn     intersect.clj:   69
[2017-06-27T18:43Z]    bcbio.variation.ensemble.intersect/maybe-nofiltered     intersect.clj:   69
[2017-06-27T18:43Z]    bcbio.variation.ensemble.intersect/ensemble-vcfs/fn     intersect.clj:   82
[2017-06-27T18:43Z]                                    clojure.core/map/fn          core.clj: 2622
[2017-06-27T18:43Z]                              clojure.lang.LazySeq.sval      LazySeq.java:   40
[2017-06-27T18:43Z]                               clojure.lang.LazySeq.seq      LazySeq.java:   49
[2017-06-27T18:43Z]                                    clojure.lang.RT.seq           RT.java:  507
[2017-06-27T18:43Z]                                       clojure.core/seq          core.clj:  137
[2017-06-27T18:43Z]                                 clojure.core/filter/fn          core.clj: 2679
[2017-06-27T18:43Z]                              clojure.lang.LazySeq.sval      LazySeq.java:   40
[2017-06-27T18:43Z]                               clojure.lang.LazySeq.seq      LazySeq.java:   49
[2017-06-27T18:43Z]                   clojure.lang.ChunkedCons.chunkedNext  ChunkedCons.java:   59
[2017-06-27T18:43Z]                          clojure.lang.ChunkedCons.next  ChunkedCons.java:   43
[2017-06-27T18:43Z]                                   clojure.lang.RT.next           RT.java:  674
[2017-06-27T18:43Z]                                      clojure.core/next          core.clj:   64
[2017-06-27T18:43Z]                                      clojure.core/some          core.clj: 2570
[2017-06-27T18:43Z]                                   clojure.core/comp/fn          core.clj: 2439
[2017-06-27T18:43Z]      bcbio.variation.ensemble.prep/unique-work-file/fn          prep.clj:   18
[2017-06-27T18:43Z]         bcbio.variation.ensemble.prep/unique-work-file          prep.clj:   16
[2017-06-27T18:43Z]        bcbio.variation.ensemble.vcfsample/sort-samples     vcfsample.clj:   36
[2017-06-27T18:43Z]    bcbio.variation.ensemble.vcfsample/maybe-sort-names     vcfsample.clj:   53
[2017-06-27T18:43Z] bcbio.variation.ensemble.vcfsample/consistent-order/fn     vcfsample.clj:   62
[2017-06-27T18:43Z]                                    clojure.core/map/fn          core.clj: 2622
[2017-06-27T18:43Z]                              clojure.lang.LazySeq.sval      LazySeq.java:   40
[2017-06-27T18:43Z]                               clojure.lang.LazySeq.seq      LazySeq.java:   49
[2017-06-27T18:43Z]                                 clojure.lang.Cons.next         Cons.java:   39
[2017-06-27T18:43Z]                                   clojure.lang.RT.next           RT.java:  674
[2017-06-27T18:43Z]                                      clojure.core/next          core.clj:   64
[2017-06-27T18:43Z]                                    clojure.string/join        string.clj:  186
[2017-06-27T18:43Z]      bcbio.variation.ensemble.intersect/intersect-vcfs     intersect.clj:   19
[2017-06-27T18:43Z]       bcbio.variation.ensemble.intersect/ensemble-vcfs     intersect.clj:   85
[2017-06-27T18:43Z]               bcbio.variation.ensemble.intersect/-main     intersect.clj:  140
[2017-06-27T18:43Z]                            clojure.lang.RestFn.applyTo       RestFn.java:  137
[2017-06-27T18:43Z]                                     clojure.core/apply          core.clj:  630
[2017-06-27T18:43Z]                   bcbio.variation.recall.main/-main/fn          main.clj:   34
[2017-06-27T18:43Z]                      bcbio.variation.recall.main/-main          main.clj:   33
[2017-06-27T18:43Z]                            clojure.lang.RestFn.applyTo       RestFn.java:  137
[2017-06-27T18:43Z]                       bcbio.variation.recall.main.main                  :

Thanks for the report and apologies about the issue. We do try to fix this VarScan bug in the code -- VarScan reports FREQ like 53% but the header references it as a float so parsers that check will fail. However, we haven't used it much for germline, primarily somatic calling, so must have missed something.  Is that what you're running here? Thanks much for the help debugging.

Thank you for looking into this. Yes, I am running a multi-sample variant run, doing batch calling with 5 variant callers: haplotypecaller, freebayes, platypus, samtools and varscan.

Thank you for following up and confirming the underlying issue. I pushed a fix which will correctly clean up the FREQ fields for all samples in a multi-sample run and should resolve the problem. You'll have to re-run the VarScan calls but can re-use all other callers so if you update to the latest development:
bcbio_nextgen.py upgrade -u development

then remove the VarScan calls (rm -rf varscan) and re-run it should hopefully work cleanly now. Please let us know if you run into any other issues.

I've rerun the pipeline and it finished successfully this time. However, I still notice errors during the Varscan output fixing phase, which do not fully crash the pipeline this time around:

[2017-07-01T12:13Z] 88734 bases in pileup file
[2017-07-01T12:13Z] 23 variant positions (21 SNP, 2 indel)
[2017-07-01T12:13Z] 8 were failed by the strand-filter
[2017-07-01T12:13Z] 15 variant positions reported (13 SNP, 2 indel)
[2017-07-01T12:13Z] Traceback (most recent call last):
[2017-07-01T12:13Z]   File "", line 1, in
[2017-07-01T12:13Z]     bcbio.variation.varscan.fix_varscan_output(x)
[2017-07-01T12:13Z]   File "/mnt/storage-brno3-cerit/nfs4/home/amizeranschi/bcbio/anaconda/lib/python2.7/site-packages/bcbio/variation/varscan.py", line 211, in fix_varscan_output
[2017-07-01T12:13Z]     ndat[Ifreq] = str(float(ndat[Ifreq].rstrip("%")) / 100)
[2017-07-01T12:13Z] IndexError: list index out of range
[2017-07-01T12:13Z] bgzip P10w-comp-chrXII_980075_1068809.vcf
[2017-07-01T12:13Z] tabix index P10w-comp-chrXII_980075_1068809.vcf.gz
[2017-07-01T12:13Z] GATK: VariantAnnotator

This error does not seem to appear every time the output of Varscan is being fixed. I'm wondering whether these errors could lead to some of Varscan's results to not be reported in the final set of (ensemble) variants. Looking at the results in IGV, there seem to be some large discrepancies between Varscan's output and that of other tools in certain genomic regions (where Varscan effectively finds nothing), while in other regions Varscan's output seems to match that of other tools, to a degree. Could it be that the regions with the discrepancies are those for which the bcbio.variation.varscan.fix_varscan_output() method failed to run properly?
I hope I explained the problem well enough. Please let me know if I can offer more useful information. See also the following screenshot, comparing Varscan's results (top track) with that of the ensemble VCF file (bottom track) for a chromosome IV in the yeast S. Cerevisiae:

Thanks so much for the detailed report and apologies about the problem. Failing here is definitely the issue you're seeing with missing calls and is not the correct behavior. I pushed a fix to hopefully avoid these cases, which I believe are due to how VarScan handles no-calls. Unfortunately you'll have to update and re-run VarScan again but hopefully it'll now work correctly and avoid errors in these regions. Thanks for all the help debugging and please let us know if you spot any other problems.


Process hacker 2 its virus?

Virustotal show 19 virus
why do they write that process hacker 2 is a virus?

Because False Positives are a thing. Use the search box next time please, a issue for this exact question has been asked 3 times in the last two months

Because False Positives are a thing. Use the search box next time please, a issue for this exact question has been asked 3 times in the last two months

is it safe without viruses?
are these false positives?

is it safe without viruses?

The code is completely open source and available for review and scrutiny by the community. There is zero malicious intent by the project.

are these false positives?

The classifications provided on VT or by vendors are (in most cases) not false positives, rather, the industry recognizes "Process Hacker" as a "hacking tool". Which may or may not be desirable for certain users, environments, or applications.
The project, now "System Informer", has gone through a lot of changes to harden and minimize the abuse.  The project does enable broader inspection into the system, which may be misconstrued as "malicious", but it is far from that. The project, in the right hands, enables users to identify misbehaving or malicious software in their environment. And take action against it. From the perspective of a bad actor leveraging System Informer to do legitimate harm - we have spent a lot of effort to coexist with the internals of the operating system to discourage and prevent bad actors from doing harm.


Fix Trilinos target in MIRCO

Description and Context

Trilinos target _Trilinos_all_selected_libs was not defined earlier when TRILINOS_IN_MIRCO flag was OFF. This fix creates an interface library _Trilinos_all_selected_libs and links Trilinos::all_selected_libs to it, which was found in the upstream project (BACI).
Since Trilinos::all_selected_libs is an alias, it can't be used when installing the mirco_lib target.
Related Issues and Pull Requests

Closes #82
Blocks
Is blocked by
Follows
Precedes
Related to
Part of
Composed of

How Has This Been Tested?

the branch's git tag is used when building BACI.
Checklist

[ ] My commit messages mention the appropriate GitHub issue numbers and are longer than one line where appropriate.
[ ] I have added/updated documentation where necessary.

Additional Information

Interested Parties / Possible Reviewers

@mayrmt @NoraHagmeyer @maxfirmbach @isteinbrecher @eulovi

Looks good to me, but I am no cmake expert. Maybe @sebproell can have a quick look too?

@sebproell I made the changes to use Trilinos as an IMPORTED library. This eliminates the need to install it again when installing mirco_lib. I tested this with BACI. Both MIRCO_DEVELOP and using fetchcontent, work without any issues.


Add um2netcdf conversion to configurations

The payu, conda, and um2nc infrastructure is now in place to add automated NetCDF conversion to the ESM1.5 configurations. This will involve adding a postscript to the config.yaml files, and a PBS job submission script under a scripts directory.

At the moment this is creating files with the original UM file names, e.g. aiihca.paa1jan.nc. For use with intake etc it would be better to move to the naming used in the p73 archive, so this would become aiicha.pa-010101_mon.nc . pe files would have pe-010101_dai.nc suffix.
Also change the NetCDF subdirectory to netCDF

The original CSIRO scripts renamed the UM files as part of the archiving
for fmonth in `ls aiihca.p?*`; do
        sdate=`~access/umdir/vn7.3/normal/cm1scripts/umdate -b64 ${fmonth} | cut --delimiter=" " --fields=8 | cut --delimiter="-" --output-delimiter=\0 --fields=1-3 `
        mv ${fmonth} ${archivedir}/history/atm/${RUNID}.p${fmonth:8:1}-${sdate}
done

The umdate script reads the file header
~access/umdir/vn7.3/normal/cm1scripts/umdate -b64 aiihca.pa50jan
aiihca.pa50jan:  First 1850-01-01 00:00:00,  Last 1850-01-01 00:00:00,  Interval 2019-04-11 07:40:47

Could be better done with mule these days.


Update Github Actions versions

Summary
Following advice from Github, update actions to latest versions
Details and comments

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
3056

Relevant Lines:
3484

💛  - Coveralls


[Bug] - Balanced-Kinesis plugin fails to start checkpointer

Any matching open bugs: No
Benthos Version: 3.18.0
calling
benthos -c path_to_my_yaml
returns:
"Failed to connect to kinesis_balanced: Failed to start Checkpointer: SerializationError: failed to unmarshal response error\n\tstatus code: 403, request id: fe7b59d5-d0c4-a717-a91e-d159f61c25ac\ncaused by: UnmarshalError: failed decoding error message\n\t00000000  3c 49 6e 76 61 6c 69 64  53 69 67 6e 61 74 75 72  |<InvalidSignatur|\n00000010  65 45 78 63 65 70 74 69  6f 6e 3e 0a 20 20 3c 4d  |eException>.  <M|\n00000020  65 73 73 61 67 65 3e 43  72 65 64 65 6e 74 69 61  |essage>Credentia|\n00000030  6c 20 73 68 6f 75 6c 64  20 62 65 20 73 63 6f 70  |l should be scop|\n00000040  65 64 20 74 6f 20 63 6f  72 72 65 63 74 20 73 65  |ed to correct se|\n00000050  72 76 69 63 65 3a 20 27  6b 69 6e 65 73 69 73 27  |rvice: 'kinesis'|\n00000060  2e 20 3c 2f 4d 65 73 73  61 67 65 3e 0a 3c 2f 49  |. .</I|\n00000070  6e 76 61 6c 69 64 53 69  67 6e 61 74 75 72 65 45  |nvalidSignatureE|\n00000080  78 63 65 70 74 69 6f 6e  3e 0a                    |xception>.|\n\ncaused by: invalid character '<' looking for beginning of value"}
after a few minutes.
This seems to be indicative of underlying aws library being used with the wrong scoping of the credentials (https://docs.aws.amazon.com/general/latest/gr/signature-v4-troubleshooting.html)
Config:
balanced_kinesis_config_yaml.txt

Removing endpoint from the yaml file got it working.

Hey @kamaroyl, are you using the endpoint field in order to connect to a third party service? If so are you able to share which one?

@Jeffail using the endpoint to reach the kinesis/dynamo instance from inside a firewalled off network

Found that using the env variable that's exposed by gokini, I can get the application to use the url I want.

Interesting, thanks @kamaroyl that should help narrow it down, I suspect the setting isn't being propagated but I'll need to dig into the library a little bit.

Just to update, I'm actively working on this in the background in an effort to unify the kinesis and kinesis_balanced inputs. I'm hoping to simplify the balancing logic considerably and that should fix oddities like this which I'm assuming is due to session collision.

Fantastic news, thanks @Jeffail

Hey @kamaroyl, in the latest release there's a general purpose aws_kinesis input that is intended to replace kinesis_balanced.
This component is a total rewrite, no longer relying on a third party library, and both the dynamodb and kinesis components share a credentials session. The mechanism for checkpointing is also simplified quite a bit so I'm hoping that not only should we see fewer issues but they should be easier to diagnose as well.
The table format used by this component should be compatible with the previous input so you can drop it in without any manual intervention, but I'd recommend attempting a migration with a test pipeline first, and make a back up of your table if you're going to try this new input out.

Endpoint isn't something I realised we had to support in kinesis balanced, I'd be happy to add it but the component looks to be deprecated now.
@Jeffail I'd love to merge your changes back upstream, but they're quite considerable. I've spent a lot of time improving this library and would love to make any improvements available to others.


Switch to doing the InputStream reading in Volume.

This means that if you can’t get an OutputStream to write to you can still implement a Volume as all you have todo is read from the InputStream and put is somewhere.
It also reduces code duplication and has try/finally so that we try not to leak streams.

In Sakai we don't directly write files to disk, but have an API which abstracts files away so they can be stored on disk, or in the DB. This API doesn't allow an OutputStream to be written to but instead allows the caller to supply an InputStream which the data will be read from.

i agree.
providing a outputstream is really more difficult than consuming an inputstream.


Revert derive(Debug) removal

This will ease merging until we remove debug from other related crates

Issues is tracked in #56


[BUG][AZURE] Flag delete_os_disk_on_termination has no effect when removing cluster

Describe the bug
In configuration of virtual-machines there is flag delete_on_termination set to false, but it doesn't have effect during cluster removal (epicli delete) and all of the OS disks are removed anyway. Also, when using similar flag for data disk (delete_data_disks_on_termination), it has no effect.
How to reproduce

execute epicli apply ...
execute epicli delete ... on that build

Expected behavior
When setting delete_on_termination flag to false (which is default) OS disks should not be removed during epicli delete.
Config files
Any config
Environment

Cloud provider: Azure
OS: Ubuntu 20.04.3 LTS

epicli version: [epicli --version]

2.0.0dev
all of the previous versions that use that flag

Additional context
On AWS this flag can preserve disks from being removed when removing cluster with epicli delete.
According to this comment it is because deletion of whole Resource Group.

DoD checklist

Changelog

[ ] updated
[ ] not needed

COMPONENTS.md

[ ] updated
[ ] not needed

Schema

[ ] updated
[ ] not needed

Backport tasks

[ ] created
[ ] not needed

Documentation

[ ] added
[ ] updated
[ ] not needed

[ ] Feature has automated tests
[ ] Automated tests passed (QA pipelines)

[ ] apply
[ ] upgrade
[ ] backup/restore

[ ] Idempotency tested
[ ] All conversations in PR resolved

Todo:

extend warning [prompted during epicli delete[(https://github.com/epiphany-platform/epiphany/blob/9cfb3c38462771ade5b737c69fa9ee69da6244a0/cli/epicli.py#L240)
remove delete_on_termination flag from epi schema and terraform vm definitions for Azure
update documentation (inform about behavior during removal)


feat: make listen take an array of addrs

This changes listener.listen to take an array of multiaddrs.
Implements https://github.com/libp2p/interface-transport/issues/41

I've also implemented this change at https://github.com/libp2p/js-libp2p-tcp/pull/104

Context helps :), I linked the original issue https://github.com/libp2p/interface-transport/issues/41. This is why websocket-star-multi was created, to better support multiple addresses and not fail outright if we were able to listen to at least 1 address.

Apologies I didn't get a chance to review this properly. Just revisiting it now, I just wanted to voice my concerns:
We've noted above it's not obvious what happens if the transport fails to bind to one or more of the passed addresses. We could partially solve this by updating the docs, but really an API without this ambiguity (as we had before) might be better.
Forcing transports to allow listening on multiple addresses adds a significant bookkeeping overhead for every transport module. Now, not only does the switch have to keep track of a "listener" per transport, every transport now has to also keep track of the listeners they create and ensure they all get closed and cleaned up correctly.
This kind of code can be error prone and feels to me like it might be unnecessarily repetitive.
Right now I'm not 100% convinced it's worth changing the interface in this way to solve the non fatal listen failures. Handling that problem as a separate concern feels like a better way to go. Is there a more general rule we can add to the switch - fatal error only if all listeners fail for a particular transport?
If particular transports need more specialist rules I'd actually be ok with the idea of keeping libp2p-websocket-star-multi, or even pulling that logic into a generic wrapper ignoreListenFails(new WSStar(rendezvousAddrs)) or just folding libp2p-websocket-star-multi into libp2p-websocket-star.

I've been thinking through various potential scenarios for transport usage and functions, and I think we should revert this. I think handling the abstractions elsewhere as we need them is the better approach.
I think we can still cleanly handle thinks like Transport Auto Retry just as easily without overcomplicating the transport. One thing I was thinking about was retry triggers. For example, retrying a bluetooth listener when bluetooth is turned on on a device, but this could be handled for single listeners or possibly better, a specific add-on to libp2p that retries listening. A similar mechanism could also be leveraged for computer sleep/wake ups.
Distinct addresses should likely just be handled via an additional method on the transport itself, https://github.com/libp2p/js-libp2p-switch/blob/v0.42.10/src/transport.js#L132, or by improving .filter to also handle uniqueness.


Bug on major.minor.patch.prerelease semantic version comparison?

Hi, my WUD is reporting that version <IP_ADDRESS>4-ls257 is higher than <IP_ADDRESS>4-ls258 - I've applied a wud.tag.transform=^(\d+\.\d+\.\d+\.\d+)-\w+$$, so there's seems to be some issue with the semver check.
<IP_ADDRESS>4 is lower than <IP_ADDRESS>4, so WUD should not report any updates available, however a patch update is being reported (from wud.json):
                        "updateAvailable": true,
                        "updateKind": {
                            "kind": "tag",
                            "localValue": "<IP_ADDRESS>4-ls258",
                            "remoteValue": "<IP_ADDRESS>4-ls257",
                            "semverDiff": "patch"
                        },

I've tested that if I use wud.tag.transform=^(\d+\.\d+\.\d+)\.\d+-\w+$$ (e.g. not include the prerelease for the semver check), the update is not reported (which is correct).
So maybe the problem is only when transforming/parsing major.minor.patch.prerelease ?
Additional Info:

issue reproducible on WUD versions: 6.6.1, 7.0.0
running via docker container
properties applied on the target container:

'wud.tag.include=^\d+.\d+.\d+.\d+-\w+$$'
'wud.tag.transform=^(\d+.\d+.\d+.\d+)-\w+$$ => $$1'

Found the issue after RTFM :)
To use the prerelease, WUD expects the version to follow this template $major.$minor.$patch-$prerelease.
I was converting the version to $major.$minor.$patch.$prerelease (note the minus signal instead of the dot before $prerelease), which is incorrect.
This triggers a literal string semver check, where 4.0.9 > 4.0.1.
The solution is to adapt the transform expression to: wud.tag.transform=^(\d+\.\d+\.\d+)\.(\d+)-\w+$$ => $$1-$$2


minecraft: fix JAVA_HOME

JAVA_HOME should point to the root directory of the JRE, not the bin folder.

Motivation for this change
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.

What's the motivation for this? Was there a problem without this patch?

Actually it seems that I can run minecraft without the JAVA_HOME line at all, so we should probably remove it.

What's the motivation for this? Was there a problem without this patch?

When launching Minecraft through the minecraft-launcher it to run java. This patch fixes the value of JAVA_HOME set in the wrapper, so that minecraft-launcher can use the appropriate JRE.
Unable to locate the Java runtime.
Error details: Success
Filename on disk: java
Path: /nix/store/gn29h5q4jkwqh634r2aw38vj2hcs17xw-openjdk-14.0.2-ga/lib/openjdk/bin/bin/java
Exists: Nonexistent

Actually it seems that I can run minecraft without the JAVA_HOME line at all, so we should probably remove it.

When I removed the JAVA_HOME line from the wrapper completely, minecraft-launcher seems to try and use /usr/bin/java which also doesn't exist.
Unable to locate the Java runtime.
Error details: Success
Filename on disk: java
Path: /usr/bin/java
Exists: Nonexistent

With no java installed globally on my system, the JAVA_HOME env in the wrapper is necessary for minecraft-launcher to detect which JRE to use.

Hm I can't reproduce this. For the parent commit of this PR (336fd6292016e41140c29b1657545071db87e6fd) I can build and run minecraft without problems:
$ nix-build -A minecraft
/nix/store/ndrz8jb5bjdg54102vpprd5ymm6l3v2b-minecraft-launcher-2.2.741
$ /nix/store/ndrz8jb5bjdg54102vpprd5ymm6l3v2b-minecraft-launcher-2.2.741/bin/minecraft-launcher
[1206/222512.902949:INFO:main_context.cpp(107)] CEF initialized successfully.

In the launcher, I hit "Play" with the latest version, which runs just fine, and I don't have any java installed globally.
Can you confirm that you tested with the exact same store path? If you get different behavior, something weird is going on. Also, let's compare nix-info -m output, mine is:

system: "x86_64-linux"
host os: Linux 5.4.70, NixOS, 21.03pre-git (Okapi)
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.3.7
nixpkgs: /etc/nixpkgs

That version works for me too.
$ nix-info -m
warning: unknown setting 'extra-sandbox-paths'
 - system: `"x86_64-linux"`
 - host os: `Linux 5.9.8, NixOS, 21.03.20201116.4f3475b (Okapi)`
 - multi-user?: `yes`
 - sandbox: `yes`
warning: unknown setting 'extra-sandbox-paths'
 - version: `nix-env (Nix) 2.4pre20201102_550e11f`
warning: unknown setting 'extra-sandbox-paths'
 - channels(ryantm): `""`
warning: unknown setting 'extra-sandbox-paths'
 - channels(root): `"nixos-19.03pre166987.bc41317e243"`
warning: unknown setting 'extra-sandbox-paths'
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Hm I can't reproduce this. For the parent commit of this PR (336fd62) I can build and run minecraft without problems:
$ nix-build -A minecraft
/nix/store/ndrz8jb5bjdg54102vpprd5ymm6l3v2b-minecraft-launcher-2.2.741
$ /nix/store/ndrz8jb5bjdg54102vpprd5ymm6l3v2b-minecraft-launcher-2.2.741/bin/minecraft-launcher
[1206/222512.902949:INFO:main_context.cpp(107)] CEF initialized successfully.

Building from 336fd62 gives me the same store path (/nix/store/ndrz8jb5bjdg54102vpprd5ymm6l3v2b-minecraft-launcher-2.2.741). The launcher starts and works, but when hitting Play on minecraft 1.16.4 it fails to launch.

In the launcher, I hit "Play" with the latest version, which runs just fine, and I don't have any java installed globally.

Did you by any chance have set a java runtime in the minecraft launcher, for the minecraft version you run? I confirmed by issue with a  clean system (no ~/.minecraft). After downloading 1.16.4 it fails to launch. With this patch JAVA_HOME is set correctly and it launches.

Can you confirm that you tested with the exact same store path? If you get different behavior, something weird is going on. Also, let's compare nix-info -m output, mine is:

Sure. With nixpkgs set to the parent commit, mine is:
 - system: `"x86_64-linux"`
 - host os: `Linux 5.9.12, NixOS, 21.03pre256292.296793637b2 (Okapi)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.9`
 - channels(bart): `""`
 - channels(root): `"home-manager, nixos-21.03pre256292.296793637b2"`
 - nixpkgs: `/nix/store/1pz6mkrv78hxa8gk9jfavin0k7skqpz1-336fd6292016e41140c29b1657545071db87e6fd.tar.gz`

Besides the point that for me the launcher is broken without a correct JAVA_HOME, I feel that setting JAVA_HOME in the wrapper is necessary to ensure minecraft uses the JRE set by the derivation, and makes overrides work. Other java based programs (e.g. maven [1]) set JAVA_HOME too in their wrapper.
[1] - https://github.com/NixOS/nixpkgs/blob/336fd6292016e41140c29b1657545071db87e6fd/pkgs/development/tools/build-managers/apache-maven/builder.sh

I also can't reproduce this issue, with a clean $HOME (no .minecraft) and no java on the system. And I confirm that it runs for me without JAVA_HOME set. Digging some more, I see that this was introduced in a8edf35af8, and from the commit log it looks like it was added to improve purity, not because it was needed.
For bonus, I tried to remove java from the PATH in the wrapper, and it fails to start unless I apply your change :)
So while I agree that your fix is valid, it would be nice to understand why only you seem to require it. Can you double check your environment? Are you using some kind of modding that might affect this?

I also can't reproduce this issue, with a clean $HOME (no .minecraft) and no java on the system. And I confirm that it runs for me without JAVA_HOME set.

Been doing some more investigation on this. Normally I run minecraft in a sandbox (with firejail), and it turns out it's due to firejail restrictions that the launcher cannot use java from the path. It does some weird logic for finding a java install (rather than just running java) and that is blocked by firejail.
Sorry for not testing it unsandboxed before, I could have figured this out earlier.

So while I agree that your fix is valid, it would be nice to understand why only you seem to require it.

Agreed. For purity the patch makes sense. As a bonus for me it runs in a sandbox with this patch too :)
Again sorry for not realizing this earlier on. Thank you all for helping trace this in the end.


disable pure runner logging

there's a racey bug where the logger is being written to when it's closing,
but this led to figuring out that we don't need the logger at all in pure
runner really, the syslog thing isn't an in process fn thing and we don't need
the logs from attach for anything further in pure runner. so this disables the
logger at the docker level, to save sending the bytes back over the wire, this
could be a nice little performance bump too. of course, with this, it means
agents can be configured to not log debug or have logs to store at all, and
not a lot of guards have been put on this for 'full' agent mode while it hangs
on a cross feeling the breeze awaiting its demise - the default configuration
remains the same, and no behavior changes in 'full' agent are here.
it was a lot smoother to make the noop than to try to plumb in 'nil' for
stdout/stderr, this has a lot lower risk of nil panic issues for the same
effect, though it's not perfect relying on type casting, plumbing in an
interface to check has the same issues (loss of interface adherence for any
decorator), so this seems ok. defaulting to not having a logger was similarly
painful, and ended up with this. but open to ideas

thought that might happen... 1s


getting error in custom bottom navigation bar after running

Steps to reproduce
I am customizing a bottom Navigation bar and I create a List of widgits and connect the list to bottom navigationn bar and after that I includ the bottom navigation bar to the files it need it to be included
in main.dart should I reffer my home screen as the navigation bar?
Expected results
I expected that the code will work proparly without any error and the bottom navigation bar will work perfecte
Actual results
I give me this error:
═════════════════════Exception caught by widgets library ══════════════════════════
The following assertion was thrown building ScrollNotificationObserver(state: ScrollNotificationObserverState#c1135):
'package:flutter/src/widgets/framework.dart': Failed assertion: line 5207 pos 16: 'owner!._debugCurrentBuildTarget == this': is not true.

Either the assertion indicates an error in the framework itself, or we should provide substantially more information in this error message to help you determine and fix the underlying cause.
In either case, please report this assertion by filing a bug on GitHub:
  https://github.com/flutter/flutter/issues/new?template=2_bug.yml

The relevant error-causing widget was:
    Scaffold Scaffold:file:///C:/Users/User/Desktop/Go_Gas_Flutter_and_Laravel/go_gas%20flutter/lib/Screens/Bottom%20Navigation%20Bar/home_screen.dart:20:15

Code sample
Code sample
code of bottom_nav_bar.dart:
import 'package:flutter/material.dart';
import 'package:go_gas/Screens/Bottom%20Navigation%20Bar/favorite.dart';
import 'package:go_gas/Screens/Bottom%20Navigation%20Bar/home_screen.dart';
import 'package:go_gas/Screens/Bottom%20Navigation%20Bar/more_options.dart';
import 'package:go_gas/Screens/Bottom%20Navigation%20Bar/search.dart';

class BottomNavBarScreen extends StatefulWidget {
  const BottomNavBarScreen({super.key});

  @override
  State<BottomNavBarScreen> createState() {
    return _BottomNavBarScreenState();
  }
}

class _BottomNavBarScreenState extends State<BottomNavBarScreen> {
  int screenIndex = 0;
  final screens=[
    const HomeScreen(),
    const Search(),
    const Favorite(),
    const MoreOptions(),
  ];

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: IndexedStack(index: screenIndex,
      children: screens,),

      bottomNavigationBar: BottomNavigationBar(
        currentIndex: screenIndex,
        onTap: (index) => setState(() {
          screenIndex = index;
        }),
        items: const [

          BottomNavigationBarItem(
            icon: Icon(Icons.home),
            label: 'Home',
            backgroundColor: Colors.blue,
          ),

          BottomNavigationBarItem(
            icon: Icon(Icons.search),
            label: 'Search',
            backgroundColor: Colors.blue,
          ),

          BottomNavigationBarItem(
            icon: Icon(Icons.favorite),
            label: 'Favorite',
            backgroundColor: Colors.blue,
          ),

          BottomNavigationBarItem(
            icon: Icon(Icons.more_horiz),
            label: 'More ',
            backgroundColor: Colors.blue,
          ),
        ],
      ),
    );
  }
}

code of home_screen.dart:
import 'package:flutter/material.dart';
import 'package:go_gas/Screens/Bottom%20Navigation%20Bar/bottom_nav_bar.dart';

class HomeScreen extends StatefulWidget{
  const HomeScreen({super.key});

  @override
  State<HomeScreen> createState() {

    return _HomeScreenState();
  }
}

class _HomeScreenState extends State<HomeScreen>{
  @override
  Widget build(BuildContext context) {

    return const Center(
      child:  Scaffold(
        backgroundColor: Colors.white,
        body: Text('home', style: TextStyle(fontSize: 25),),

        bottomNavigationBar: BottomNavBarScreen(),
      ),
    );
  }
}

Screenshots or Video

Screenshots / Video demonstration

Logs
Logs
[Paste your logs here]

Flutter Doctor output
Doctor output
Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel stable, 3.22.2, on Microsoft Windows [Version 10.0.19045.4529], locale en-US)
[√] Windows Version (Installed version of Windows is version 10 or higher)
[√] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
[√] Chrome - develop for the web
[X] Visual Studio - develop Windows apps
    X Visual Studio not installed; this is necessary to develop Windows apps.
      Download at https://visualstudio.microsoft.com/downloads/.
      Please install the "Desktop development with C++" workload, including all of its default components
[√] Android Studio (version 2023.3)
[√] VS Code (version 1.91.0)
[√] Connected device (4 available)
[√] Network resources

! Doctor found issues in 1 category.

@MohammedRedha126
This is a code implementation issue at your end. Below is updated runnable code sample I came up with based on code you provided.

 code

import 'package:flutter/material.dart';
import 'package:pointer_interceptor/pointer_interceptor.dart';
import 'package:flutter_web_plugins/url_strategy.dart';

void main() {
//  usePathUrlStrategy();
  runApp(MaterialApp(
    home: HomeScreen(),
  ));
}

class HomeScreen extends StatefulWidget{
  const HomeScreen({super.key});

  @override
  State<HomeScreen> createState() {

    return _HomeScreenState();
  }
}

class _HomeScreenState extends State<HomeScreen>{
  @override
  Widget build(BuildContext context) {

    return const Center(
      child:  Scaffold(
        backgroundColor: Colors.white,
        body: Text('home', style: TextStyle(fontSize: 25),),

        bottomNavigationBar: BottomNavBarScreen(),
      ),
    );
  }
}

class BottomNavBarScreen extends StatefulWidget {
  const BottomNavBarScreen({super.key});

  @override
  State<BottomNavBarScreen> createState() {
    return _BottomNavBarScreenState();
  }
}

class _BottomNavBarScreenState extends State<BottomNavBarScreen> {
  int screenIndex = 0;
  final screens=[
    const HomeScreen(),
  //  const Search(),
  //  const Favorite(),
  //  const MoreOptions(),
  ];

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: IndexedStack(index: screenIndex,
        children: screens,),

      bottomNavigationBar: BottomNavigationBar(
        currentIndex: screenIndex,
        onTap: (index) => setState(() {
          screenIndex = index;
        }),
        items: const [

          BottomNavigationBarItem(
            icon: Icon(Icons.home),
            label: 'Home',
            backgroundColor: Colors.blue,
          ),

          BottomNavigationBarItem(
            icon: Icon(Icons.search),
            label: 'Search',
            backgroundColor: Colors.blue,
          ),

          BottomNavigationBarItem(
            icon: Icon(Icons.favorite),
            label: 'Favorite',
            backgroundColor: Colors.blue,
          ),

          BottomNavigationBarItem(
            icon: Icon(Icons.more_horiz),
            label: 'More ',
            backgroundColor: Colors.blue,
          ),
        ],
      ),
    );
  }
}

And your issue is here:
 final screens=[
    const HomeScreen(),

ie you have set the HomeScreen to be a child of itself.
Closing, as this is not a bug.


:AINewChat throws an error (commit introducing the bug identified)

Hi!
First: I love this plugin and appreciate it very much. Thank you so much for this great peace of work!
dec808e78845cb981a7d8d23ac1a1c0eac58d114 introduced a bug:
Error executing Lua callback: .../share/nvim/lazy/lazy.nvim/lua/lazy/core/handler/cmd.lua:48: function vim_ai#AINewChatRun[2]..<SNR>48_OpenChatWindow, line 4: Vim:E492: Not an editor command: preset_
stack traceback:
        [C]: in function 'cmd'
        .../share/nvim/lazy/lazy.nvim/lua/lazy/core/handler/cmd.lua:48: in function <.../share/nvim/lazy/lazy.nvim/lua/lazy/core/handler/cmd.lua:16>
Press ENTER or type command to continue

I commented the code change location.
With 46e3d5a609fdaa2ddb2af6cc5cb4e754b8b39bfa all is fine.
I have too less knowledge about Vimscript to be able to fix that and come with a PR.
All best from Berlin,
Jamil

I have:
:version:
NVIM v0.9.5
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3

I beg your pardon.
Seems like a Neovim particularity, as in Vimscript a:0 ? should be the same as a:0 != 0 since a:0 is never less than zero. Well, reverting to a:0 ? or a:0 != 0 then.
Could you read the value of a:0 (say using echoerr)? Does a:0 != 0 instead of a:0 > 0 work?

Does it have anything to do with Lazy? What's the error message without using Lazy?

Could you read the value of a:0 (say using echoerr)? Does a:0 != 0 instead of a:0 > 0 work?

The value seems to be 1:

Does a:0 != 0 instead of a:0 > 0 work?

When I replace a:0 > 0 with a:0 != 0 the error message is more clear:
E492: Not an editor command: preset_
Also of interest:
AINewChat throws that error, AINewChat below does not.

Ah, another hint: I use vim-ai daily and the issue appears since approximately 3-5 days.

Does it have anything to do with Lazy? What's the error message without using Lazy?

I'll investigate that later today (latest tomorrow) and come back to you.

I find this mysterious. I replaced a:0 ? with a:0 > 0 ? because I found it easier to read as a matter of taste. Surely we can revert it to a:0 ?. Still, my curiosity is peaked, and I would not mind hearing what Neovim Lazy deems wrong with it.

This was a bit of a red hering; I accidently passed q-args, allowing for an empty string, instead of f-args, which drops a void parameter. Should be fixed with #82

Thank you!


ESP32-S3-WROOM1: Access Point Not Showing After Flashing DroneBridge Firmware

I flashed the DroneBridge firmware onto my ESP32-S3-WROOM1, and while the upload was successful, the SSID for the access point does not appear for me to connect and configure DroneBridge settings.
Steps taken:

Erased the flash and re-uploaded the firmware, but the issue persists.
Tried using another ESP32-S3-WROOM1 board, and the same issue occurred.

The access point is not discoverable, so I cannot apply any settings in either client or AP mode. Any ideas on how to resolve this?

Wrong project ->https://github.com/DroneBridge/ESP32
I have the same board and the latest release flashed via the online flasher works fine for me. Check the logs

I also tried uploading the firmware using the online flasher, but the SSID still doesn't show up. I'm not getting any output on the serial monitor either—just a solid red LED on the board. I'm not sure what I'm doing wrong. As mentioned earlier, I completely erased the board and re-uploaded the firmware, but there's still no output on the serial monitor, no SSID, and just the solid red LED on my ESP32-S3 board.


[SPARK-40663][SQL] Migrate execution errors onto error classes: _LEGACY_ERROR_TEMP_2201-2225

What changes were proposed in this pull request?

This PR proposes to migrate 25 execution errors onto temporary error classes with the prefix _LEGACY_ERROR_TEMP_2201 to _LEGACY_ERROR_TEMP_2225.
The error classes are prefixed with _LEGACY_ERROR_TEMP_ indicates the dev-facing error messages, and won't be exposed to end users.
Why are the changes needed?

To speed-up the error class migration.
The migration on temporary error classes allow us to analyze the errors, so we can detect the most popular error classes.
Does this PR introduce any user-facing change?

No
How was this patch tested?
$ build/sbt "sql/testOnly org.apache.spark.sql.SQLQueryTestSuite"
$ build/sbt "test:testOnly *SQLQuerySuite"
$ build/sbt -Phive-thriftserver "hive-thriftserver/testOnly org.apache.spark.sql.hive.thriftserver.ThriftServerQueryTestSuite"

@itholic Could you rebase it on the recent master, please.

@itholic Please, resolve conflicts.

@itholic Could you fix the test failures:
[info] - SPARK-34057: UnresolvedTableOrView should retain sql text position *** FAILED *** (139 milliseconds)
[info]   Expected exception org.apache.spark.sql.AnalysisException to be thrown, but org.apache.spark.SparkException was thrown (AnalysisTest.scala:182)
[info]   org.scalatest.exceptions.TestFailedException:
[info]   at org.scalatest.Assertions.newAssertionFailedException(Assertions.scala:472)

@itholic Please, resolve conflicts and fix tests.

@itholic Can you fix GAs? Some test failures are related to your changes:
2022-10-30 23:01:03.735 - stderr> org.apache.spark.SparkException: spark.sql.catalog.default
2022-10-30 23:01:03.735 - stderr> 	at org.apache.spark.sql.errors.QueryExecutionErrors$.noSuchElementExceptionError(QueryExecutionErrors.scala:2178)
2022-10-30 23:01:03.736 - stderr> 	at org.apache.spark.sql.internal.SQLConf.$anonfun$getConfString$3(SQLConf.scala:4839)

@MaxGekk CI passed finally..😂   Could you take a look when you find some time ?

+1, LGTM. Merging to master.
Thank you, @itholic.


Instructions on how to boot from external sdcard

Instructions on how to install on and boot from the external sdcard would be very welcome! Thank you!

@lgeek Could you please complete this task?
After checking your supported hardware table I got myself a Kobo Aura (N514). I have okreader compiled and ready to flash. Unfortunately, after opening my Kobo Aura, I realized it has an eMMC chip soldered to the PCB.
According to your comment on #8, it seems that you are running okreader on a Kobo Aura from the external sdcard. Could you please add instructions on how to prepare such card?

I believe this might be of your interest. Any feedback is appreciated.
#22

Hey, thanks for this! I haven't been able to give it a go yet but I'm planning to soon and will let you know how it goes and any feedback I have.


Connectors Implementation

Pull request
Description
Connectors are successors to onramps/offramps, sinks/sources. A connector can be a source of events and events can be sent to a connector. Not all connectors necessarily support all both the sink and source nature/trait.
This PR introduces a new config artefact
and tries to remodel the current onramp/offramp handling to move as much boilerplate and common logic from the connector implementation to the runtime (or where not possible to reasonable utilities), so that writing new connectors is getting easier, while maintaining all invariants enforced by the runtime.
Additional connector features:

Pause / Resume
Connect / Reconnect / connectivity probes
Configurable Codecs/Processors

TODOs

[ ] Create predefined reconnect strategies (e.g. randomized exponential backoff, ...)
[x] correlation metadata in RPC style connectors (moved to connectors)
[x] broadcast system metrics to all metrics connector instances
[x] look into stdin connector if we want broadcasting to all instances as well
[x] integration tests for verifying proper startup
[x] integration tests for verifying pause/resume behaviour
[x] rust in-process integration test suite for connectors (in tests folder)

getting a stream for events from out, err
getting a sender for sending events to in
verifying events send to and received from a connector
e.g. sending TCP data to it, asserting on received events

[x] only register debug connector types (exit, debug, cb, benchmark) when a certain server flag is given (--register-debug-connectors or similar)
[x] Binding Quiescence - assuming no overlaps or shared resources
[x] Connectors API - status, change status (pause, resume, ...)
[ ] Bindings API - add status, change status (pause, resume, ...) endpoints
[ ] Ensure that metrics are emitted correctly to the metrics connector, same for pipelines
[ ] Connector ports (tier 1; known to be in active use, will be prioritised for porting)

[x] discord (h)
[x] DNS (h)

[x] correlation

[x] elastic (confirmed) (m)

[x] correlation

[x] exit (m)
[x] file (please not line-based this time, both sink and src) (m)
[x] kafka-consumer (m)
[ ] kafka-producer (m)
[x] kv (h)

[x] correlation

[x] metronome (h)
[ ] otel (src + sink, confirmed)
[ ] http (rest server + client, should this include SSE?,  confirmed) (d)

[ ] correlation

[x] stdio (stdin + stdout + stderr)
[x] tcp-client (m)
[x] tcp-server (m)
[x] udp-client (h)
[x] udp-server (h)
[x] wal (h)
[ ] unix-socket (confirmed)

[ ] Connector ports (tier 2; utility, testing & debugging, this will not be prioritized on porting form sink/src to connector )

[x] benchmark connector (blaster/blackhole previously) (h)
[x] cb (m)
[ ] debug

[ ] Connector ports (tier 3; not known to be in use - low priority, but comment this issue if you are using any of these, dear readers )

[x] websocket-client (near term use cases exist) (d)
[x] websocket-server (near term use cases exist) (d)
[ ] sse (could this be part of http?)
[ ] postgres (src + sink, do we still need this?, not known to be in production use at this time )
[ ] nats (src + sink, not known to be in production use at this time )
[ ] newrelic ( community contributed by grover, not known if it is in production use at this time )
[ ] gpubsub (gsub + gpub, use cases known and expanding )
[x] crononome (ported, not in production use that we can confirm)
[ ] amqp (confirmed not used)
[ ] gcs (confirmed not used at the moment but future usecase exists)

Test expectations and conditions
Tier 1 and Tier 2 connectors should have container tests in /tests contributed with the new connector test
harness ( this helps greatly with code coverage ) and integration tests in /tremor-cli/tests/integration that
demonstrate canonical and simple use and validation of the connector in all its configuration modes ( client or server, secure and insecure etc.. ). For Tier 3, container and integration tests are preferable.
Related

RFC

Checklist

[ ] The RFC, if required, has been submitted and approved
[ ] Any user-facing impact of the changes is reflected in docs.tremor.rs
[ ] The code is tested
[ ] Use of unsafe code is reasoned about in a comment
[ ] Update CHANGELOG.md appropriately, recording any changes, bug fixes, or other observable changes in behavior
[ ] The performance impact of the change is measured (see below)

Performance

A question to the std_stream connector, I noticed that the user needs to specify what type of std_stream it is which in my mind breaks the connector concept a bit since instead of a bidirectional connection it is now a unidirectional connection that the user specifies the direction to.
Would it make sense to turn the std_stream into a connector that allows reading/writing to? behaving more like stdio?
This would require connectors to be aware when their input (sink) and output (source) ports are connected to dynamically shut down / start the corresponding subsystems but it would feel a bit more intuitive than having to write:
connector:
  - id: stdin
    type: std_stream
    config:
      stream: stdin
  - id: stdout
    type: std_stream
    config:
      stream: stdout
  - id: stderr
    type: std_stream
    config:
      stream: stderr

Once this branch goes green it would be worth merging the troy branch once both have rebased against main. Progressing the deployment language work now depends on having connectors available in the runtime.

The rebase seems to have broken something, the tests don't compile :(


fix: re-add finetunings

Details

This PR fine tunes the highlighted menu item animation durations. The original PR got reverted here due to https://github.com/Expensify/App/issues/41142.
Fixed Issues

$ https://github.com/Expensify/App/issues/39841
$ https://github.com/Expensify/App/issues/39214
PROPOSAL: N/A
Tests

Create a new workspace
Go to the workspace settings
Enable a feature.

Verify that the design requirements mentioned here are satisfied.

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

Offline tests

N/A
QA Steps

Create a new workspace
Go to the workspace settings
Enable a feature.

Verify that the design requirements mentioned here are satisfied.

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

PR Author Checklist

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

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

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

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

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

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

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

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

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

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

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

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

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

https://github.com/Expensify/App/assets/30054992/3e1e14da-61d1-4e75-bc38-b145eb7d6244

Android: mWeb Chrome

https://github.com/Expensify/App/assets/30054992/bcc359da-61a6-466a-a2a9-aaaad153b71c

iOS: Native

https://github.com/Expensify/App/assets/30054992/85b61014-1a30-47c2-8965-57772f7a9afb

iOS: mWeb Safari

https://github.com/Expensify/App/assets/30054992/a3791802-c3c0-4aeb-9710-6fa40214a611

MacOS: Chrome / Safari

https://github.com/Expensify/App/assets/30054992/bd1b9c11-191b-48bf-ace0-c8a80cee4eec

MacOS: Desktop

https://github.com/Expensify/App/assets/30054992/f16fed6c-867a-4a8a-a4ca-1dd14b7ac513

@sobitneupane will review this.

@sobitneupane can you please follow up with the review here? thanks

@allroundexperts, can you do the same for enablePolicyConnections, too? I'm closing my PR, them.

If any feature is toggled on, and you toggle it off and on again quickly, it takes a few seconds for the feature to appear in the LHN. I don't think this issue is directly related to the changes introduced by this PR, but it is worth addressing.

I think it might be from the slowness of the backend API that we're experiencing currently. But I want to make sure that this is the case. @sobitneupane, could you investigate this a little bit more and check the network tab that this is actually from the backend.
Because we have the optimistic update, I actually wonder if this is from the backend issue.

I think it might be from the slowness of the backend API that we're experiencing currently. But I want to make sure that this is the case. @sobitneupane, could you investigate this a little bit more and check the network tab that this is actually from the backend.

@hayata-suenaga The issue I mentioned is not reproducible when the user is offline.
When I toggle the switch multiple times, it waits for all the API requests to complete before making any changes. That might be the reason for the delay.
https://github.com/Expensify/App/assets/25876548/1813e063-311b-4c25-b303-02da70ff91a7

I think we need to make sure a normal/ single toggling works well as that is what 99% of users will do

I think we need to make sure a normal/ single toggling works well as that is what 99% of users will do

Yup. Normal/single Toggling is working fine.

do yo have an idea what we have to do here to fix the issue?

@hayata-suenaga I am not sure. I might have to spend some time digging it down.
But for now I think we are good to merge this PR.

Yeah I think we are good to merge this PR

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

🚀 Deployed to staging by https://github.com/puneetlath in version: 1.4.77-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/puneetlath in version: 1.4.77-11 🚀

platform
result

🤖 android 🤖
failure ❌

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/puneetlath in version: 1.4.77-11 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


gj and gk functionality

Hi, is it possible to get smooth scroll also for gj and gk?
The following MWE works:
local root = vim.fn.fnamemodify("./.repro", ":p")
for _, name in ipairs({ "config", "data", "state", "cache" }) do
  vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({ "git", "clone", "--filter=blob:none", "https://github.com/folke/lazy.nvim.git", lazypath, })
end
vim.opt.runtimepath:prepend(lazypath)

local plugins = {
    {
        'declancm/cinnamon.nvim',
        opts = {}
    }
}

require("lazy").setup(plugins, {
    root = root .. "/plugins",
})

vim.keymap.set('n', 'j', [[<Cmd>lua Scroll("j", 1, 1)<CR>]])
vim.keymap.set('n', 'k', [[<Cmd>lua Scroll("k", 1, 1)<CR>]])
vim.keymap.set('n', 'gj', [[<Cmd>lua Scroll("gj", 1, 1)<CR>]])
vim.keymap.set('n', 'gk', [[<Cmd>lua Scroll("gk", 1, 1)<CR>]])

However, while j and k work fine, gj and gk are very slow on larger lines (or lines with inlay hints)

Added them to the 'no scroll' list so it should be a lot faster when used without a count :).
Currently the gj and gk won't work smoothly when finishing on wrapped text, I need to fix that before added those keymaps to the 'extended keymaps'. I'll open another issue for that

See #32

The fix was easier than I thought, I've added 'gj' and 'gk' to the extended keymaps

Great!
Just FYI, I have successfully setup g0, g^ and g$ variants. These are not set up with extra_keymaps, but work for me anyway


Preview stuck on the loading screen

Followed the directions, but can't for the life of me get previews to work.
The preview is stuck on "loading" and the console says the following, which is crazy cause Export Event and Page is definitely on those templates. Is this only me?
./src/pages/404.js 61:12-17"export 'Event' was not found in '../templates/event.js'./src/pages/404.js 60:10-14"export 'Page' was not found in '../templates/page.js'./src/components/Header.js
my 404.js
import React from "react"
import Helmet from 'react-helmet'
import { withUnpublishedPreview } from 'gatsby-source-prismic'
import {Page} from '../templates/page'
import {Event} from '../templates/event'

// import Layout from "../components/layout"
import SEO from "../components/seo"

const NotFoundPage = () => (
  <>
    <Helmet
      bodyAttributes={{
          class: 'page page-404'
      }}
    />
    <SEO title="404: Not found" />

NOT FOUND

You just hit a route that doesn't exist... the sadness.

  </>
)

// If an unpublished `page` document is previewed, PageTemplate will be rendered.
export default withUnpublishedPreview(NotFoundPage, {
  templateMap: {
    page: Page,
    events: Event,
  },
})

my templates/page.js
import React from "react"
import { graphql } from "gatsby"
import Helmet from "react-helmet"
import ImageHero from "../components/ImageHero"
import Card from "../components/Card"
// import { SiteInfo, Events } from "../components/slices"
import SliceZone from "../components/SliceZone"
import { withPreview } from 'gatsby-source-prismic'

const Page = ({ data: { page, events, faqs, allpages } }) => {

  return (
    <>
      <Helmet
        bodyAttributes={{
          class: "post event-post",
        }}
      />

      <ImageHero
        image={require("../assets/wallpaper.jpg")}
        video={require("../assets/kk-vid.mp4")}
        title={page.data.page_title.text}
        text={page.data.page_description.text}
      />

      <SliceZone slices={page.data.body} />

    </>
  )
}

export default withPreview(Page)

export const pageQuery = graphql`
  query PageBySlug($uid: String!) {
    page: prismicPage(uid: { eq: $uid }) {
      id
      uid
      prismicId
      data {
        page_description {
          text
        }
        page_title {
          text
        }
        body {
          ... on PrismicPageBodySiteInfo {
            id
            slice_type
            primary {
              text {
                text
              }
            }
          }
          ... on PrismicPageBodyEvents {
            id
            slice_type
            primary {
              title {
                text
              }
            }
          }
        }
      }
    }
    allpages: allPrismicPage {
      nodes {
        data {
          body {
            ... on PrismicPageBodySiteInfo {
              id
              slice_type
              primary {
                image {
                  url
                }
                text {
                  text
                }
              }
            }
            ... on PrismicPageBodyEvents {
              id
              slice_type
              primary {
                title {
                  text
                }
              }
            }
          }
        }
      }
      edges {
        node {
          data {
            body {
              __typename
              ... on PrismicPageBodySiteInfo {
                id
                slice_type
                primary {
                  text {
                    text
                  }
                  image {
                    url
                  }
                }
              }
              ... on PrismicPageBodyEvents {
                id
                slice_type
                primary {
                  title {
                    text
                  }
                }
              }
            }
          }
        }
      }
    }
    events: allPrismicEvent(
      sort: { fields: [first_publication_date], order: DESC }
    ) {
      nodes {
        data {
          title {
            text
          }
          text {
            text
          }
          featured_image {
            url
          }
          date(formatString: "MM-DD-YY")
        }
        url
        uid
        id
        first_publication_date
      }
    }
    faqs: prismicFaq {
      data {
        group {
          answer {
            text
          }
          question {
            text
          }
        }
      }
    }
  }
`

linkresolver.js
const linkResolver = ({ node, key, value }) => doc => {
  if (doc.type === "event") {
    return `/events/${doc.uid}`
  }
  if (doc.type === "page") {
    return `/${doc.uid}`
  }
  if (doc.type === "team_members") {
    return `/team/${doc.uid}`
  }

  return `/${doc.uid}`
}

module.exports = linkResolver

Have you tried removing the brackets around Page and Event?
But I am also having the issue of being stuck on the loading page. I have followed the Preview HOC set up but am not seeing a preview on the load page.
Any help would be greatly appreciated!

For those coming across this now, I just ran into this issue and worked it out 🙂
What's going on is that the linkResolver as documented has a different signature than that which is expected by withPreview (it expects the func(obj) -> func(obj) -> str signature, similar to the one set in gatsby-config.js, rather than the func(obj) -> str signature exported by the linkResolver.js function in the prismic setup docs)
Long story short, replace the code found in the preview setup docs
export default withPreviewResolver(PreviewPage, {
  repositoryName: "your-prismic-repository-name",
  linkResolver,
})

with
export default withPreviewResolver(PreviewPage, {
  repositoryName: "your-prismic-repository-name",
  linkResolver: () => linkResolver,
})

A follow-up gotcha that had me, is the need to modify how I'm querying data in order for the preview data merge to work. Based on the recommendation of the previous prismic gatsby source plugin I used (gatsby-source-prismic-graphql), I had to change
allPrismicXPage {
  edges {
    node {
      ...
      data {
        ...
      }
    }
  }
}

to
prismicXPage {
  ...
  data {
    ...
  }
}

Now that I recognize it, this new syntax is far nicer anyway 😅

@angeloashmore I'm happy to open a PR to fix the docs, but I'm unsure which way is intended. Do you prefer that:

linkResolver has the signature func(obj) -> func(obj) -> str and the gatsby-config.js setup doc should change, or
linkResolver has the signature func(obj) -> str and the preview docs should change

I would be inclined to lean towards 2 because that is how prismic docs portray the linkResolver, but I don't totally understand the use of the function when curried again and called with ({ node, key, value }) -- perhaps you could shed some light on it?

Hey @bndnio, thanks for the offer to update the docs!
The link resolver function needs to have the following signature for both gatsby-config.js and the preview HOCs:
({ node, key, value }) => (doc) => string

The { node, key, value } portion is specific to this plugin and is intended to provide additional data that normally isn't available when using Prismic outside of Gatsby. This would allow you to use a different link resolver for specific fields as necessary.
In the next major version, V4, the { node, key, value } data will be removed from link resolvers as it is a common source of confusion. You can read a little bit more about the change here: gatsby-source-prismic v4 Roadmap.
You're right that the Prismic docs for Gatsby show the incorrect link resolver signature in their /src/utils/linkResolver.js example. It does correctly provide it in their gatsby-config.js.
Until V4 is out, perhaps the best solution is to add a note to the withPreviewResolver section of the docs. Something like:

The linkResolver function must be the same as the one provided in your gatsby-config.js file. This means the linkResolver function should look something like:
({ node, key, value }) => (doc) => `/${doc.id}`

Feel free to expand on that as you see fit. Thanks!


NameError: name '_C' is not defined

 51     ):
 52         ctx.im2col_step = im2col_step

---> 53         output = _C.ms_deform_attn_forward(
54             value,
55             value_spatial_shapes,
NameError: name '_C' is not defined

[Solved]
First I was doing installation using "pip install -r requirements.txt". It didn't work.
Finally I installed using this command and it worked "pip install -q -e ."
I was running on Colab

Same NameError in colab, and I solved this by following two steps:

Copy the README shared notebook into your own colab space.
After the pip installation, a "restart the runtime" button will be showed in the output, click that button.

simply install the groundingDINO with this command:
cd groundingDINO
pip install .

this will build the wheel with C++ extensions and install the whole wheel to your environment.


remove unnecessary spaces and support long: false

closes #6

Build Preview

You can find files attached to the below linked Workflow Run URL (Logs).
Please note that files only stay for around 90 days!
| Name      | Link
| Commit    | e4644f460bde0a25eb1386e54d917c1ddc305dc9
| Logs      | https://github.com/ENIB-Community/glossarium/actions/runs/6835350550
| Exemple build with 12 | https://api.github.com/repos/ENIB-Community/glossarium/actions/artifacts/1043796299/zip

Build Preview

You can find files attached to the below linked Workflow Run URL (Logs).
Please note that files only stay for around 90 days!
| Name      | Link
| Commit    | f6f6c748cf741141e1920465f7a6d80c1e03cbdf
| Logs      | https://github.com/ENIB-Community/glossarium/actions/runs/6835378846
| Exemple build with 12 | https://api.github.com/repos/ENIB-Community/glossarium/actions/artifacts/1043799223/zip

Build Preview

You can find files attached to the below linked Workflow Run URL (Logs).
Please note that files only stay for around 90 days!
| Name      | Link
| Commit    | f6f6c748cf741141e1920465f7a6d80c1e03cbdf
| Logs      | https://github.com/ENIB-Community/glossarium/actions/runs/6835390927
| Exemple build with 12 | https://api.github.com/repos/ENIB-Community/glossarium/actions/artifacts/1043800737/zip

Build Preview

You can find files attached to the below linked Workflow Run URL (Logs).
Please note that files only stay for around 90 days!
| Name      | Link
| Commit    | c4260750b1b8a1514c7763011c884ea66f7fa916
| Logs      | https://github.com/ENIB-Community/glossarium/actions/runs/6835407466
| Exemple build with 12 | https://api.github.com/repos/ENIB-Community/glossarium/actions/artifacts/1043802601/zip

Build Preview

You can find files attached to the below linked Workflow Run URL (Logs).
Please note that files only stay for around 90 days!
| Name      | Link
| Commit    | 8dd17904ec6dd6b8388229c6a7e77cbc919a6688
| Logs      | https://github.com/ENIB-Community/glossarium/actions/runs/6835417922
| Exemple build with 12 | https://api.github.com/repos/ENIB-Community/glossarium/actions/artifacts/1043804568/zip


Write up first classes

@theonlysam no code yet? Do you need any help? This issue is pretty generic, so happy to break things out into smaller steps if needed. Thanks.

this is pretty cool! https://chat.openai.com/share/ba7477cb-efbc-4109-be1b-c3fd59e025b8
HTH
Bob


go/types: should the 'newer Go version' error be reported to Config.Error?

Since go1.21, (*go/types.Checker).Files() has returned an error when a package has a GoVersion (specified in types.Config.GoVersion) that is newer than the go/types library it is compiled against. Error in question is:
	if check.version.after(version{1, goversion.Version}) {
		return fmt.Errorf("package requires newer Go version %v", check.version)
	}

x/tools/go/packages was assuming the only error not reported to types.Config.Error was types.errBadCgo. Example  downstream issue: #65590.
This issue is to decide whether this error should be reported to the types.Config.Error field, and if so how?
@griesemer @adonovan

One option that came up in code review is to report the error as a types.Error on the first package symbol and to proceed as if the GoVersion=="". This would not fail-fast and best effort types would work better for IDEs like gopls.
OTOH it is not clear whether it is acceptable to do a best effort typing when we know the package is a future GoVersion.
A minor complicating wrinkle is when all files are pinned to versions less than the version of go/types. Should there be an error on this package at all?

This issue is to decide whether this error should be reported to the types.Config.Error field, and if so how?

Yes, all errors should be reported through Config.Error, and the error returned by Checker.Files should merely be the first of them. We should re-establish the invariant that a non-zero number of calls to Error is equivalent to the package being ill-typed. The two early error returns in Checker.Files both violate this invariant. The FakeImportC one was rarely exercised, but the version check (downgraded from a panic by https://go.dev/cl/507975) is much more important. Both these errors should be reported (e.g. against the first package declaration if no other location is appropriate), but should not abort type-checking of the package.  We should document clearly in the code that early returns are not allowed.
Clients of go/types make widespread assumptions that the type-checker does the best it can with the syntax, and that well-formed declarations are annotated with types even if the package contains some type errors. For example, it is common to evaluate info.Defs[decl].(*types.Func) where decl is an *ast.FuncDecl, without needing a check.
I can send you a CL for the go/types change if you like.

Not happening for 1.23. Moving to 1.24.


allow for 31 occupied bits in vanilla BoxedSmallWord

fixes #3327

[ ] Needs a bunch more tests, since the bitwise-operations may also be affected w.r.t bit 31 in Int32.

Closing this one, since #3335 gives a similar bang for much less buck. We can reheat this if we absolutely want.


[Framework guide] Add VitePress

Alphabetized the list of frameworks and added instructions for VitePress

Howdy @timothynott, thanks for the submission!
Going to jump into this and make some changes tomorrow to align this with how the other guides are structured.

Confirmed that this carries through to the Pages presets


System.InvalidOperationException: Nullable object must have a value.

Describe the bug
I'm migrating a single node event store to a cluster event store. The migration goes well until ~8% and then stops with the following messages.
To Reproduce
Steps to reproduce the behavior:

Migrating the stream in the screenshot to the cluster event store.

Expected behavior
The replicator should not stop ?
Actual behavior
The replicator stops and wait for ever.
I don't really know if my streams/metadata are not well-formed or if it is a replicator issue.
Config/Logs/Screenshots
repl-replicator | {"@t":"2022-06-29T15:35:07.4273261Z","@m":"gRPC: Read event with id \"380dce52-dd9f-4104-befa-82668b72b733\" of type \"NoTicketFoundSecondTime\" from \"precontrol-fps--5d253f24e5__2021-07-12T15:46:10.102Z\" at \"C:64939324/P:64939324\"","@i":"4138b59c","@l":"Debug","Id":"380dce52-dd9f-4104-befa-82668b72b733","Type":"NoTicketFoundSecondTime","Stream":"precontrol-fps--5d253f24e5__2021-07-12T15:46:10.102Z","Position":"C:64939324/P:64939324","SourceContext":"EventStore.Replicator.Esdb.Grpc.GrpcEventReader"}
repl-replicator | {"@t":"2022-06-29T15:35:07.4414254Z","@m":"Unable to read metadata for stream \"precontrol-fps--88853ac4fa__2022-01-18T14:20:10.000Z\"","@i":"b7df7f78","@l":"Warning","@x":"System.InvalidOperationException: Nullable object must have a value.\n   at System.Nullable`1.get_Value()\n   at EventStore.Replicator.Esdb.Grpc.ConnectionExtensions.GetStreamMeta(EventStoreClient client, String stream) in /app/src/EventStore.Replicator.Esdb.Grpc/ConnectionExtensions.cs:line 14\n   at EventStore.Replicator.Shared.Extensions.DictionaryExtensions.GetOrAddAsync[T](ConcurrentDictionary`2 dict, String key, Func`1 get) in /app/src/EventStore.Replicator.Shared/Extensions/DictionaryExtensions.cs:line 11\n   at EventStore.Replicator.Esdb.Grpc.StreamMetaCache.GetOrAddStreamMeta(String stream, Func`2 getMeta) in /app/src/EventStore.Replicator.Esdb.Grpc/StreamMetaCache.cs:line 15","Stream":"precontrol-fps--88853ac4fa__2022-01-18T14:20:10.000Z","SourceContext":"EventStore.Replicator.Esdb.Grpc.StreamMetaCache"}
repl-replicator | {"@t":"2022-06-29T15:35:07.4420507Z","@m":"Transforming event \"NoTicketFoundSecondTime\" from \"precontrol-fps--88853ac4fa__2022-01-18T14:20:10.000Z\"","@i":"23620329","@l":"Debug","Type":"NoTicketFoundSecondTime","Stream":"precontrol-fps--88853ac4fa__2022-01-18T14:20:10.000Z","__2":null,"__3":null,"__4":null,"SourceContext":"js-transform"}
repl-replicator | {"@t":"2022-06-29T15:35:07.4426234Z","@m":"gRPC: Read event with id \"5646953a-b84b-45a4-90fc-1db023adcb4a\" of type \"$>\" from \"$et-NoTicketFoundSecondTime\" at \"C:64939642/P:64939642\"","@i":"4138b59c","@l":"Debug","Id":"5646953a-b84b-45a4-90fc-1db023adcb4a","Type":"$>","Stream":"$et-NoTicketFoundSecondTime","Position":"C:64939642/P:64939642","SourceContext":"EventStore.Replicator.Esdb.Grpc.GrpcEventReader"}

EventStore details

EventStore server version: v20 (docker)
Replicator version: 0.4.6 (docker)

I forgot to mention that I'm using a JS Transform.
function transform(original) {
    log.debug("Transforming event {Type} from {Stream}", original.EventType, original.Stream);

    if (original.EventType === "FPSToSendAdded") {
        const { address, ...rest } = original.Data

        // We patch empty address object.
        if (address && address.streetName === "" && address.cityName === "" && address.postCode === ""
            && address.cityCode === "" && address.houseNumber === "") {

            return {
                ...original,
                Data: {
                    ...rest,
                }
            }
        }

        // We patch a buggy address format.
        if (address && 'postcode' in address) {
            return {
                ...original,
                Data: {
                    ...rest,
                    address: {
                        cityName: address.city,
                        postCode: address.postcode,
                        streetName: address.street ?? address.name,
                        houseNumber: address.housenumber,
                        cityCode: address.citycode
                    }
                }
            }
        }
    }

    if (original.EventType === "ParkingZoneFound") {
        // Patch a bug where the zone configuration is wrong.
        if (original.Data.openingHours.afternoon
            && original.Data.openingHours.afternoon[0] !== undefined
            && original.Data.openingHours.afternoon[1] === undefined
        ) {
            return {
                ...original,
                Data: {
                    ...original.Data,
                    openingHours: {
                        ...original.Data.openingHours,
                        afternoon: [
                            original.Data.openingHours.afternoon[0],
                            original.Data.openingHours.afternoon[0]
                        ]
                    }
                }
            }
        }
    }

    return {
        ...original
    }
}

I solved my issue, I have projection result events with huge payload that cause Maximum Append Size of 1048576 Exceeded error. The problem was that the logs with this error was not at the bottom and I didn't notice the error.
I just ignored projections result streams using a filter rule:
...
filter:
  - type: streamName
     exclude: .*result

I can try finding out if a given stream is the projection result stream. Ideally, those streams should not be replicated.


Clean up some unused code

Removes a file that is now obsolete, and a test helper function that wasn't needed.

Also saying that this one doesn't need review. Removed stuff that didn't need to be in the repo. Merging without review.


Ignore Java 9's CONSTANT_MODULE/CONSTANT_PACKAGE

Fixes #206

Requesting a review by @retronym, but actually feedback generally welcome. 🙂

In alternative to handing the new tags, or in addition?

In addition

only parse class files with valid java names,
that would exclude the META-INF folder

module-info.class isn't in META-INF. At least not in jaxb-api-2.3.0.jar, or meant to be according to http://openjdk.java.net/projects/jigsaw/quick-start.

Ah sorry. The - in the module-info  means it can't be derived from a normal Java class.

There are classfiles under META-INF for multi-release JARs, though. The do constitute a JDK-version-dependent part of the public API, so MiMa probably should consider them.

The - in the module-info means it can't be derived from a normal Java class.

Ah right. Ok let me jump on that.
Btw I found out that mima's using pieces of nsc to get this info (Classpath or something), so perhaps some of this logic could land there eventually.

Actually, @retronym, I'm thinking we shouldn't filter out module-info.class because, even if it can't be derived from a normal Java class, it could in the future be parsed by MiMa and used to report runtime issues (e.g by dropping a package export).
As such, this is ready for review.


Clarification on DB.First(...) method

Documenting the limitation on the func (s *DB) First(out interface{}, where ...interface{}) *DB method where the column name is optional if the primary key is numeric. In other cases, the name of the column must be provided.

thank you for your pr.

Thanks, @jinzhu !


Document jq / yq usage

Document jq usage, related to https://github.com/jonnylangefeld/kubectl-mc/issues/18

Codecov Report

Merging #19 (84efbae) into master (b7bcc7c) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head 84efbae differs from pull request most recent head 53b2cde. Consider uploading reports for the commit 53b2cde to get more accurate results

@@           Coverage Diff           @@
##           master      #19   +/-   ##
=======================================
  Coverage   82.60%   82.60%
=======================================
  Files           1        1
  Lines         138      138
=======================================
  Hits          114      114
  Misses         13       13
  Partials       11       11


[USERSNAP] Please add commas to delimit thousands

Taken at: https://gov.tools/connected/governance_actions/59fd353253eb177e2104e8f23ea4c63e3d32ef95c7865d03e90d3884424dc1db#0
Fields:

Name of the idea or new feature: Please add commas to delimit thousands
Please summarize your idea or new feature: Currently, DREP vote counts are difficult to read. They show as many digits and it is touch to compare. They are seen as:

DReps yes ₳ 81570879.833413
abstain ₳ 97276671.736064
no ₳ 7386787.499895
Why not show them as: 81,570,879.833413 ?
Browser: Chrome 128 (Windows 10)
Screen size: 1926x964
Open #83 in Usersnap
Powered by Usersnap.

Different cultures use different characters to delimit numbers. It should use the user's browser locale to use the appropriate character.

This has been a persistent simple oversight. We have asked for it to be fixed. That is, add commas.

Duplicate of #2305 .