Use CUDA macro instead of NVCC.

__CUDA__ is defined in clang. Making the change won't make clang
compile xgboost, but syntax checking for *.cu from clang is at least partially
working.

Codecov Report

Merging #3539 into master will increase coverage by 0.09%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master    #3539      +/-   ##
============================================
+ Coverage     45.64%   45.74%   +0.09%
  Complexity      188      188
============================================
  Files           166      166
  Lines         13233    13233
  Branches        445      445
============================================
+ Hits           6040     6053      +13
+ Misses         6989     6976      -13
  Partials        204      204

Impacted Files
Coverage Δ
Complexity Δ

include/xgboost/base.h
100% <ø> (ø)
0 <0> (ø)
:arrow_down:

src/data/sparse_page_dmatrix.cc
92.89% <0%> (+0.59%)
0% <0%> (ø)
:arrow_down:

src/data/sparse_page_raw_format.cc
64.15% <0%> (+22.64%)
0% <0%> (ø)
:arrow_down:

Continue to review full report at Codecov.

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

Can you elaborate your reasoning for replacing __NVCC__ with __CUDA__? Does this improve compatibility?

@hcho3 To some degree. CUDA is a macro defined by clang to indicate the current scope, NVCC is a similar macro defined by NVCC. As you can see from the patch, it's not really replacing, just checking for the right one to use. With this patch clang can compile a larger portion of the code, but still not the whole project.
But the reason for myself is I can use better syntax checking and code static analyse tools from clang. Now I can see error/warning and do code navigation for CUDA interactively in my editor just like normal c++ code. NVCC provides very primitive error handling facility and confusing error message.
So the patch is mainly for easy development. :)

I'm not sure I like substituting macros with more macros. It can be a little confusing. What about doing this:
#if defined(__NVCC__) || defined(__CUDA__)

@RAMitchell Done.


Segmentation fault for several BIFs if no sufficient arguments are supplied

For several BIFs, if no sufficient arguments are supplied, Trealla will exit with segmentation fault. e.g.:
Trealla v0.1alpha, 64-bits (int=128-bits), Dec 14 2016
?- open.
Segmentation fault (core dumped)

Trealla v0.1alpha, 64-bits (int=128-bits), Dec 14 2016
?- close.
Segmentation fault (core dumped)

I find it still cause segmentation fault randomly, following is backtrace:
(gdb) bt
#0  0x000000000040f160 in get_env (q=0x7252c50, point=32680)
    at src/internal.h:430
#1  0x000000000040f48a in get_arg (q=0x7252c50,
    term=0x7fa7daea7678 <main_arena+88>, frame=1) at src/bifs.h:147
#2  0x000000000040f516 in get_next_arg (q=0x7252c50, term=0x7ffde93950f8)
    at src/bifs.h:163
#3  0x0000000000412633 in bif_iso_open3 (q=0x7252c50) at src/bifs_iso.c:727
#4  0x000000000042f215 in call (q=0x7252c50) at src/jela.c:453
#5  0x000000000040cb4f in query_run (self=0x7252c50) at src/trealla.c:2700
#6  0x000000000040e607 in trealla_run_query (self=0x7136010,
    src=0x7242b40 "main") at src/trealla.c:3236
#7  0x000000000040e275 in trealla_consult_file (self=0x7136010,
    name=0x7ffde93978eb "issues/0051.pro") at src/trealla.c:3137
#8  0x00000000004043b3 in main (ac=3, av=0x7ffde9395ff8) at tpl.c:325

If I tried it enough times I was seeing this, but after a make clean && make I can't get it all now.

Interesting. I tested in Debian (gcc 4.9.2) and CentOS (gcc 5.2.1), both crash frequently, using following code:
:- initialization(main).

main :- open.

Another way to crash (hopefully it can be reproduced constantly in this way):

type open. in REPL and type Enter.
type close. in REPL and type Enter.

Or run following code directly in shell:
./tpl <<EOF
open.
close.
EOF

BTW, if behavior of get_next_arg is changed, BIFs with variadic arguments like sys:concat also need to be adjusted.

./tpl <<EOF
open.
close.
EOF

This test case still cause segmentation fault.


Feature request: Plex Webhook Integration

Having to manually switch profiles via smartphone isn't convenient - Adding adding support for plex webhooks would be a step to full automation (Hit play in plex, webhook called to update minidsp for selected movie) https://support.plex.tv/articles/115002267687-webhooks/
Webhooks sends a client uuid, so requested can be filtered to the specific relevant client.  I'm not entirely sure about determining the audio stream portion - would need to examine the metadata payload to see what's included there.
Other media server platforms(ex jellyfin) also have webhook support - payloads may be a little different, but should be easy enough to add api support for multiple media server apps as long as they provide a client id, movie title, and audio stream format.

From the Plex example, it seems like it would need to filter on event (media.stop start) and Player.uuid (which you would add to ezbeq config) and then needs to be able to match something in the metadata with a beqcatalogue entry.  Not immediately obvious how to automatically do the last bit though there was a post on avs on this last point

Plex docs are not too clear but it seems that it does have an option to include data from themoviedb (which is what beqcatalogue includes) which may make the lookup easier.
Details from an emby user on how they did it are in https://www.avsforum.com/threads/ezbeq-use-and-development-discussion.3181732/page-147#post-61848185 in case it helps

FYI this is on my roadmap to do. I am not sure if it will be part of this app or run as a separate daemon and talk to ezbeq via api. Probably won’t be any time soon, but I definitely plan on working on it in the next few weeks

Maybe it is possible with home assistant as an automated task? Does the ezbeq have an API?

Maybe it is possible with home assistant as an automated task? Does the ezbeq have an API?

yes, go to /api/doc/ in a local installation for details

FYI almost done with this. Doing safety tests for BEQ and then I will release a preview version for testing

Almost done with this. Doing safety checks with beq and then I can release a preview version for testing.

Okay, a very alpha release is here https://github.com/iloveicedgreentea/plex-webhook-automation/tree/v0.0.4
Please read the readme as any question is likely answered there. I have tested all functions and it works, but YMMV so open issues if you find bugs. I plan on working on it more in the coming week and also adding IP based control for MadVR Envy too.

awesome job. Just trying to set it up -
Step 0 - I made the config.json in HA with information from the config shown.
Step 1 - where should i make the pull? is it on my pi where HA is set up or the pi with ezbeq installed?
Can you perhaps make a short video setting the whole thing up? :-)

where should i make the pull? is it on my pi where HA is set up or the pi with ezbeq installed?

It does not matter. Something that can run a container. If you are using HAOS on a pi I strongly recommend against doing anything on there, so use the one running ezbeq. I love HA but they are insane with their requirements for official add ons or integrations.
A video wouldn’t be a good way to do this as it will take a lot of time and be outdated later on, so no real point. If anything in the readme is unclear please open an issue and I can clarify it.
You basically need MQTT set up on HA, webhooks setup on the plex server (port and IP pointing to where you set up this server) and thats pretty much it


unittest failure in master

Issue Type
Bug report
Molecule and Ansible details
ansible 2.3.0
molecule: bf634f0755f1e3f017b8dc6ba07d66d60b599577

Molecule installation method: source
Ansible installation method: pip

Desired Behaviour
tox -e -e py27-ansible23-unit should succeed without failures
Actual Behaviour (Bug report only)
tox -e -e py27-ansible23-unit errors:
test/unit/core/test_core_docker.py::test_get_driver_name ERROR
<snip>
E           DockerException: Error while fetching server API version: ('Connection aborted.', error(2, 'No such file or directory'))

/home/steve/Tech/GITHUB/molecule/.tox/py27-ansible23-unit/lib/python2.7/site-packages/docker/api/client.py:168: DockerException
<snip>

To reproduce this run tox -e -e py27-ansible23-unit

@ashcrow thanks for the issue and sudden interest RH has with Molecule.
Was this meant for master or v2?  While I cannot reproduce the error you're seeing, I actually do have a bad unit test.

This was for v1. It was before I realized the development for the next version was in a branch 😆

Go for it.


Coin integration

Is there any js-sdk of energy web token for transaction available?
I want to integrate coin in OPOLO hardware wallet.

How to get?

The Origin SDK has nothing to do with the Energy Web Token (EWT). Closing the issue as unrelated to this repo.

For running transactions on the Energy Web Chain, you can use https://wallet.energyweb.org.

I am searching for js-sdk for the integration of energy webtoken in
hardware wallet?
Is there any discord channel available for developers?
On Sun, 18 Oct 2020, 7:23 pm Joseph Bagaric<EMAIL_ADDRESS>wrote:

For running transactions on the Energy Web Chain, you can use
https://wallet.energyweb.org.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/energywebfoundation/origin/issues/1632#issuecomment-711175014,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AMXEYFFTQCYRI37LPH73YFTSLL24JANCNFSM4SU6SQ3Q
.


Added SubtractPipe and AddPipe

I added the functions for SubtractPipe and AddPipe. These are used as:
{{ mydate | amAdd : '2' : 'hours' }}
{{ mydate | amSubtract : '2' : 'hours' }}

Looks good dustin! Can you please update package.json  and .gitignore with the new files, and add a note to README about the new pipes?

Thank you!

Released as part of 1.1.0


Petal 9, exp 254394, tile 23301 looks like bright star on stuck sky?

We should mask the affected fibers somehow. Is masking the whole amp or even petal necessary?

I think the right thing to do is to identify the affected pixels and to add them to this file
https://github.com/desihub/desispec/pull/2050
That would mean opening a preproc image and visually inspecting how much area is affected by the over-bright trace.
Someone also needs to figure out which trace was too bright and check if it's a stuck fiber or a real target.

I think the culprit TARGETID=2375903153750016, a BRIGHT_HPM secondary target on FIBER=4818:
https://www.legacysurvey.org/viewer/?ra=24.7557&dec=-17.9507&catalog=tmpm90pr_h1&zoom=14

the green circle here is from the fiberassign file, ie with the infos from the BRIGHT_PM program:
    TARGETID     TARGET_RA TARGET_DEC   PMRA   PMDEC  REF_EPOCH
---------------- --------- ---------- ------- ------- ---------
2375903153750016   24.7557   -17.9507  3385.8   532.0    2000.0

the offset in RA since 2000 is about 0.02 deg.
from the tractor-0247m180.fits file, it has these mags: (g, r, z) = (13.7, 11.9, 8.7):
objid         ra                dec          flux_g    flux_r    flux_z  ref_cat        ref_id          pmra    pmdec   gaia_phot_g_mean_mag
             deg                deg        nanomaggy nanomaggy nanomaggy                              mas / yr mas / yr         mag
----- ------------------ ----------------- --------- --------- --------- ------- ------------------- --------- -------- --------------------
 4257 24.771210452138845 -17.9477628246832 3208.1155 16876.986 324709.66      G2<PHONE_NUMBER>158739712 3182.7341 592.1038            10.806108

@geordie666: didn t we already "cleaned" this BRIGHT_PM for super-bright objects?
I can have a quick look.

Looking back at the relevant issue I think we only masked FAINT_HPM targets. Obviously that was an oversight. Let me spool through to find any BRIGHT_HPM targets and turn them off in the same manner I did for the FAINT_HPM targets.

thanks!
btw, I notice that for this specific case, there actually are two very-close matches in the tractor-0247m180.fits file, with approx. the same proper-motion:
objid         ra                dec            pmra    pmdec   ref_epoch ref_cat        ref_id         flux_z
             deg                deg          mas / yr mas / yr                                       nanomaggy
----- ------------------ ------------------ --------- -------- --------- ------- ------------------- ---------
 4248 24.771059358018583 -17.94837634531903 3385.8267 532.0398    2015.5      G2<PHONE_NUMBER>158739840  5825.545
 4257 24.771210452138845  -17.9477628246832 3182.7341 592.1038    2015.5      G2<PHONE_NUMBER>158739712 324709.66

they apparently are two different gaia ref_id, but could it be it s just the same source, detected twice in two images taken at two different epochs?
one of the match has a "more reasonable" z-mag of 13.1.
so I guess that a "matching" algorithm to identify those HPM_BRIGHT targets with high fluxes should consider something like the brightest mags of the few closest objects?

Or even every object within 5" or so. Anyway, I'll look into it and turn this one (and any other relevant targets) off.

@geordie666: for what is worth, I ve generated this two catalogs:
-rw-rw---- 1 raichoor desi 105K Sep 26 11:47 /global/cfs/cdirs/desi/users/raichoor/targets/BRIGHT_HPM-lsdr9-fluxmax-5arcsec.fits
-rw-rw---- 1 raichoor desi  18M Sep 26 11:48 /global/cfs/cdirs/desi/users/raichoor/targets/FAINT_HPM-lsdr9-fluxmax-5arcsec.fits

where I look in the tractor file (when available) at the brightest flux in grz within 5 arcsec (after having applied simple proper-motion correction to a same reference epoch -- 2024 -- for everything).
actually, maybe we d want to run that for 2025, 2026, ..., 2029? (I could do that easily).
here are the few objects I find with a brightest flux larger than 12 mag (arbitrary cut!):
d = Table.read("BRIGHT_HPM-lsdr9-fluxmax-5arcsec.fits")
d["TRACTOR_MAG_GRZ_MIN"] = 22.5 - 2.5 * np.log10(d["TRACTOR_FLUX_GRZ_MAX"])
sel = d["TRACTOR_MAG_GRZ_MIN"] < 12
d["TARGETID", "RA", "DEC", "TRACTOR_FLUX_GRZ_MAX", "TRACTOR_MAG_GRZ_MIN", "TRACTOR_OBJIDS"][sel]
# =>
    TARGETID        RA      DEC    TRACTOR_FLUX_GRZ_MAX TRACTOR_MAG_GRZ_MIN      TRACTOR_OBJIDS
---------------- -------- -------- -------------------- ------------------- ------------------------
2375903153750016  24.7557 -17.9507<PHONE_NUMBER>5   8.721261990217144 4248,4257,4621,4633,4636
2376846586937344 135.0981  21.8347      23039.310546875   11.59382630337465                3715,3737

d = Table.read("FAINT_HPM-lsdr9-fluxmax-5arcsec.fits")
d["TRACTOR_MAG_GRZ_MIN"] = 22.5 - 2.5 * np.log10(d["TRACTOR_FLUX_GRZ_MAX"])
sel = d["TRACTOR_MAG_GRZ_MIN"] < 12
d["TARGETID", "RA", "DEC", "TRACTOR_FLUX_GRZ_MAX", "TRACTOR_MAG_GRZ_MIN", "TRACTOR_OBJIDS"][sel]
# =>
     TARGETID             RA                 DEC         TRACTOR_FLUX_GRZ_MAX TRACTOR_MAG_GRZ_MIN TRACTOR_OBJIDS
----------------- ------------------ ------------------- -------------------- ------------------- --------------
39628435932319147 14.084735951824952  27.972419440213447     16158.0595703125  11.979026987694576      3499,3512
39627432759656859   41.3312169634514 -14.864961057159151       28076.24609375  11.379152398919146        411,437
<PHONE_NUMBER>951489             46.827             -13.762       37235.87890625  11.072595976806825            857
<PHONE_NUMBER>808512           198.0827             17.5179<PHONE_NUMBER>5   8.891993786898196            507
<PHONE_NUMBER>686145           199.1938              9.4242           1248962.25   7.258626720046355           4374
<PHONE_NUMBER>684864           357.8913             31.4564       23248.46484375  11.584014298537221      3860,3871

maybe you ve already turned the FAINT_HPM ones off.
also, there are 84 FAINT_HPM row with nan's for (PMA,PMDEC); same, you ve surely already cleaned those!

back to the original point of identifying in the preproc the region to be masked.
the effect is visible over all three cameras; I eye-balled that the max. region to mask:

b-camera: 2540-2555;
r-camera: 2560-2680;
z-camera: 2510-2610.

this plot shows the profile along the fiber direction (note the log scale in the y-axis):

solid thick: mean over all pixels along the wavelength direction;
solid (dashed) thin: value at y=4000 (3000), to control what s happening on the reddest wavelengths part, as this star is brighter in the red

@schlafly: makes sense?

Yes, that looks good.  Practically I think that means that the larger z band mask will apply to all of the fibers, right, so that that whole region won't end up getting put in the MTLs?  I ask because the redshifts are clearly bad over the larger region, affecting more than one or two fibers.

right.
as the mask is defined per-camera, I was trying to get the minimal masking for each camera, to save few b- and r-camera spectra.
as you say, I expect that, for MTLs, any spectra with a missing camera would be rejected, ie it would be the unions of fibers affected by the three per-camera masks -- so dominated by the z-camera masking here.
it would be good to double-check that, though, once the reprocessing is done.
for sure, at the redshift levels, a fairly broad large range of fiber are affected: I d say at least 4790 -- 4849:

if anyone wants to have a look, the spectra for fibers 4750-4999 are displayed here: https://data.desi.lbl.gov/desi/users/raichoor/spectro/daily/data-check/cframe-00254394-9.pdf.
for reference, if I m correct, the mtl-specific zwarn flags are here:
https://github.com/desihub/desispec/blob/4eae355fbae93e5a138c6ca91074d961c2558286/py/desispec/zmtl.py#L266-L274
and bad_qafstatus_mask here:
https://github.com/desihub/desispec/blob/4eae355fbae93e5a138c6ca91074d961c2558286/py/desispec/data/qa/qa-params.yaml#L40

re-thanks for your input!
you re 100% right :) sorry for this misleading first report... I m not familiar with the preproc files..
second try, much more conservative:

b-camera: 2405 -- 2596 (~25 fibers);
r-camera:  2235 -- 3004 (~100 fibers);
z-camera: 1834 -- 3371  (~200 fibers).

looking a bit more carefully at that: indeed, the wings are quite extended, but I m not really sure how to catch those...
the plots below show the preproc with saturating the colorbar, where we can see that the wings do extend pretty wide.
I picked the above values with looking at the regions between the fiber blocks (25 fibers); I thought that those regions should be kind of stable with no signal; the bottom panel shows the median values for those regions (both over all wavelengths, and over a narrower range on the red side); I just eye-balled where those seem to be not affected..
(higher-resolution plots here: https://data.desi.lbl.gov/desi/users/raichoor/spectro/daily/data-check/)
for the z-camera:

for the r-camera:

for the b-camera:

Conflating investigations a bit. Sorry! But, I'm checking into the potentially problematic targets that Anand uncovered. I did, indeed, already turn off these TARGETIDs (FAINT_HPM):
2252857029951489
2253605423808512
2253417447686145

But not the other HPM targets Anand identified. I'm still checking into why the others fell through the cracks.

Interestingly,<PHONE_NUMBER>9656859 is an MWS_NEARBY target (as well as being a FAINT_HPM target) that we've apparently successfully observed on TILEID=23829.

thanks for the follow-up!
for info, I ve "extended" my check with looking at the positions at 2025.0, 2026.0, ..., 2029.0.
it provides the same results, except one extra target pops up in the FAINT_HPM catalog:
     TARGETID             RA                 DEC         TRACTOR1_OBJIDS TRACTOR1_MAG_GRZ_MIN
----------------- ------------------ ------------------- --------------- --------------------
<PHONE_NUMBER>437696<PHONE_NUMBER>37085   -6.02558558716321            4616   11.696013328445938

(for the position at 2024.0, there are no objects closer to 5 arcsec).
sorry to add more to your plate!
also, about the 12 mag cut and 5 arcsec cut: I admit I just picked those values ~arbitrarily; at the same time, as there only are a handful of targets to exclude, I guess it s ok to be on the safe side.

@araichoor: This is such a small number of objects that I agree that I should just "turn them off" to be safe. I'll do that later today or tomorrow.
I'll probably keep digging for other corner cases (and to try to determine why desitarget isn't finding those cases) but I think turning off the targets you've found so far makes sense.

thanks @geordie666!
about implementing the masking (pinging @sbailey):
I think I ve the edited version of https://desi.lbl.gov/trac/browser/calib/desi_spectro_calib/trunk/ccd/ccd-region-mask.csv ready to commit.
I ll proceed to the commit tomorrow, during daytime, to avoid any interference with the on-going processing.
my edited file is here:
cat /global/cfs/cdirs/desi/users/raichoor/svn/desi_spectro_calib/trunk/ccd/ccd-region-mask.csv
NIGHT,EXPID,CAMERA,XMIN,XMAX,YMIN,YMAX,COMMENT
20230512,180299,b6,2048,3923,2998,3006,'large tail in serial line from cosmic ray see https://github.com/desihub/desisurveyops/issues/117'
20231208,208688,b6,2048,4096,3928,3932,'tail from cosmic impacts overscan OSTEP; see https://github.com/desihub/desisurveyops/issues/164'
20240921,254394,b9,2405,2596,0,4095,'contamination from bright star; see https://github.com/desihub/desisurveyops/issues/219'
20240921,254394,r9,2235,3004,0,4127,'contamination from bright star; see https://github.com/desihub/desisurveyops/issues/219'
20240921,254394,z9,1834,3371,0,4127,'contamination from bright star; see https://github.com/desihub/desisurveyops/issues/219'

I plan to just do:
svn commit ccd-region-mask.csv -m "bad fibers for 20240921,254394,brz9"

as a sanity chek, I ve generated preproc files with that file, here s what it looks like, with the masking regions shaded in grey:

for info, I just committed this ccd-region-mask.csv file: https://desi.lbl.gov/trac/changeset/1206/calib.
if I m correct, we should now just need to reprocess the EXPID=254394 and the TILEID=23301, right? (of course with an svn-updated version of $DESI_SPECTRO_CALIB)

@abhi0395 , @akremin , can we reprocess expid 254394 (tileid 23301)?

I've "turned off" (added the IN_BRIGHT_OBJECT flag) for the additional potentially problematic targets Anand identified. A full census of the 9 HPM targets Anand mentions above:
These two targets have already been successfully observed, so I haven't changed their state:
2376846586937344 BRIGHT_HPM
39627432759656859 FAINT_HPM
I'd already turned off these three targets:
2252857029951489 FAINT_HPM
2253605423808512 FAINT_HPM
2253417447686145 FAINT_HPM
I've now additionally turned off these four targets:
2375903153750016 BRIGHT_HPM
39628435932319147 FAINT_HPM
2253915227684864 FAINT_HPM
2253043265437696 FAINT_HPM

I've rerun the processing for the tile. There was only the one exposure on the one night. I've rerun tsnr and nightqa. Back to surveyops for QA.

@araichoor, could you please double-check this ticket for tile 23301 before we confirm the tile is OK? The new tile 23301 QA was finished 2024-10-14 and is here. There are a number of fibers in petal 9 with low EFFTIME and nonzero QAFIBERSTATUS. These are near but not on top of the bright star that was identified as the problem, as far as I can tell.

looks good to me, as far as I can say:

in tile-qa-23301-thru20240921.fits, the EFFTIME_SPEC vs. fiber distribution looks like it accounts for the missing z, or z+r, or z+r+b cameras; the FIBER range is 4725, 4924;
in zmtl-9-23301-thru20240921.fits, the related fibers have the BAD_SPECQA flag turned on.

here s a plot:

looking at the zmtl file (and picking the FIBER range from the above plot):
from desitarget.targetmask import zwarn_mask
fn = "/global/cfs/cdirs/desi/spectro/redux/daily/tiles/cumulative/23301/20240921/zmtl-9-23301-thru20240921.fits"
d = Table(fitsio.read(fn, "ZMTL"))
d["FIBER"] = 4500 + np.arange(len(d), dtype=int)
sel = (d["FIBER"] >= 4725) & (d["FIBER"] <= 4924)
d = d[sel]
assert np.all((d["ZWARN"] & zwarn_mask["BAD_SPECQA"]) > 0)

remarks:

as we re masking a block of fibers, the (ra, dec) distribution in not close to the bright star, as expected;
if I m correct, in tile-qa-23301-thru20240921.fits, there s no flag in QAFIBERSTATUS to say that some of those spectra have missing cameras; it is only reflected indirectly in the EFFTIME_SPEC; but as long as the zmtl file has the correct BAD_SPECQA info, I think we re good; if I m correct, it s the LOWEFFTIME flag that turns on the BAD_SPECQA; dumping here the fibermask names for that block of fibers:

from desispec.maskbits import fibermask
fn = "/global/cfs/cdirs/desi/spectro/redux/daily/tiles/cumulative/23301/20240921/tile-qa-23301-thru20240921.fits"
d = Table(fitsio.read(fn, "FIBERQA"))
sel = (d["FIBER"] >= 4725) & (d["FIBER"] <= 4924)
d = d[sel]
for val, count in zip(*np.unique(d["QAFIBERSTATUS"], return_counts=True)):
    print("{}\t{}".format(count, "|".join(fibermask.names(val))))

=>

184	LOWEFFTIME
2	STUCKPOSITIONER|LOWEFFTIME
3	UNASSIGNED|STUCKPOSITIONER|LOWEFFTIME
2	POORPOSITION|LOWEFFTIME
4	STUCKPOSITIONER|POORPOSITION|LOWEFFTIME
1	UNASSIGNED|STUCKPOSITIONER|POORPOSITION|LOWEFFTIME
3	BADPOSITION|POORPOSITION|LOWEFFTIME
1	VARIABLETHRU|LOWEFFTIME

Thanks for the detailed look. I think we can mark as good and close this.

I ve just updated the tiles-specstatus.ecsv file, with setting that tile to "good": https://desi.lbl.gov/trac/changeset/4223/data
closing the ticket.


VAAPI and AMD Issues

In the latest and previous releases of wolf when using h265 encoding caused the screen to turn grey within several seconds of a game loading in.
In addition the latest release has also introduced the following issues

Encoding performance for h264/h265 has dropped to about 30fps
H265 stats overlay records the screen as 3456x1440 despite moonlight client being 3440x1440. within the attach log it does however report the correct site.

Grey Screen Issus

Stats Incorrect Resolution

Changing the gstreamer.video.defaults.vaapi to the below does improve the encoding performance
h265 = ~85FPS
h264 = ~50FPS
However no where near where this card was previously hitting on earlier builds and the issue with grey screen still present for h265.
######################
# Default settings for the main encoders
# To avoid repetition between H264, HEVC and AV1 encoders

[gstreamer.video.defaults.vaapi]
video_params = """
queue !
vapostproc !
video/x-raw(memory:VAMemory), chroma-site={color_range}, width={width},
height={height}, format=NV12, colorimetry={color_space}
\
"""

For reference the machine I have has a 6900XT and GTX1080, in separate wolf stack using image "ghcr.io/stimzrx/wolf:stable" which is prior to the dev-multi-gpu branch being merged in and setup so that the nvidia card is doing encoding and 6900xt is app render  none of these issues exist and performance is easily locked at 100fps. This is using the nvenc encoder
h265_greyscreeningame.txt
h264_slowencoding.txt
Testing Setup

AMD Radeon 6900XT
CnC Kanes Wrath and Doom 2016 (so dx9 and Vulkan based games)

For reference the machine I have has a 6900XT and GTX1080, in separate wolf stack using image "ghcr.io/stimzrx/wolf:stable" which is prior to the dev-multi-gpu branch being merged in and setup so that the nvidia card is doing encoding and 6900xt is app render none of these issues exist and performance is easily locked at 100fps. This is using the nvenc encoder

Right, so that's not a fair comparison. You are comparing the Nvidia encoder with the AMD encoder but you don't know how much you were able to achieve with the previous Wolf version using just the 6900XT card, am I right?
If that's the case, you should still be able to use both cards at the same with the latest :stable, I've made two separate ENV variables now to make it easier:

WOLF_RENDER_NODE (defaults to /dev/dri/renderD128) is where the apps and the virtual compositor will run
WOLF_ENCODER_NODE (defaults to WOLF_RENDER_NODE to use the same GPU) is where the Gstreamer pipeline will run

If you tweak those two you should be able to replicate the setup that you had before.

hey @ABeltramo
That fair its not an exact 1:1 comparison with the duel gpu setup. Was noting that none of the issues were present using the nvenc encoder so seemed less likely to be a client problem thats all.
Prior the update, I was using the dev-multi-gpu build from several weeks ago which as the time I believe had only the updated gstreamer build that corrected the issue with wide screen resolutions. In the testing there, the performance was notably better.... but the grey screen issue was present.
Let me do the above testing and will report back

Hey @ABeltramo
Apologies for some confusion, I have gone back and repeated testing method better.
Hardware

NVIDIA 1080
AMD 6900XT

All tests were done using H265 and current stable wolf images
Notes

NVIDIA Only: performed at 55FPS for the stream and game play seemed to be allow low. However given the age of the card and its doing Rendering and Encoding, this performance seems in line given the age of the card, vram and it doing both tasks. Also no issue with picture going to grey

AMD Only: performed at 91fps for the video stream, but shortly after game start screen goes to grey. Interestingly if I lower games resolution down to 1920x1080 and set all quality to low the grey issue does not occur. However i can replicate similar issue across multiple games...

NVIDIA Encoding, AMD Rendering: performed at 99FPS for the video stream and no video going to grey. so basically perfect.

Going forward I will use the duel setup as seems to yield the best performance, however was reporting the AMD / VAAPI given others with AMD cards are likely to have the issue as well.
Have attached the stack config and logs for all of the tests
wolf-nvidiaonly-stack.txt
wolf-amdonly_logs.txt
wolf-amdonly-stack.txt
wolf-nvenc_amdrender_logs.txt
wolf-nvenc_amdrender-stack.txt
wolf-nvidiaonly_logs.txt

Thanks for testing this out, I'm going to keep this open as a reminder to change the default vaapi pipeline and to give it a go at testing out AMD on AWS (since I don't have an AMD GPU available).
I'm glad you are able to get some good performances using the dual GPU setup!

No problem,
If you need me to do any future testing, happy to do so, I now have 3 wolf stack pre setup to quickly test the above scenario's

Hello,
I've just installed the latest version of Wolf, but I'm encountering a black screen or an issue similar to the one shown in the first image of this thread when starting a game via Steam. My setup includes a 7950X processor and an RX 7800 XT graphics card.
To install Wolf, I used Portainer with the Docker Compose configuration provided in the Quickstart Guide.
In the wolf-wolf-1 container, I see repeated warnings like this:
(0:48:09.260856139     1 0x7f10041f9250 WARN                  appsrc gstappsrc.c:2469:gst_app_src_push_internal:<wolf_wayland_source> Dropping old item buffer: 0x7f10388e4510, pts 0:46:02.949889482, dts 0:46:02.949889482, dur 0:00:00.016666666, size 8294400, offset none, offset_end none, flags 0x0)
Additionally, here is the log from WolfSteam_10730337829953401807 for further reference.
_WolfSteam_10730337829953401807_logs (1).txt

hey @Vlekkie2005
Thanks for the information,
Any chance you can attach a screen of the issue and the logs from the wolf container. Like me you are also using portainer so  when you bring up the container logs be sure to increase the lines from default of 100 to like 10000.
The reason for the extra information is the logs include information about the gstreamer pipeline settings that were used along with the additional errors. The screen is also for context.
I have found that with different games the issues appears differently. For example game I am testing in the screenshot is CnC Kanes Wrath as it presents the issues the worst. I have found that if I lower the resolution to 1920x1080 and set the graphics quality to low the issue does present at all. In other games like Doom 2016 the issue is most noticeable in load screens

@ABeltramo > was looking through the issue list for gstreamer vah265 plugin and came across this
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1991
This could be culprit to the overshoot issue we spoke previously which we theorized may be the cause . Looking at the issue (at least for obs) switching to vaapih265enc did seem to resolve the issue. Concerningly this issue was logged nearly a year ago and doesn't appear any further comment.
I'm going to attempt building the current wolf container to include this plugin and do some testing.

hey @salty2011
Thanks for the reply.
Here are some buggy/not working things and the logs.
Here are my logs(after playing baldurs gate 3 and factorio)
_wolf-wolf-1_logs (8).txt
baldurs gate 3 = black screen (sometimes and other times it does work)
I tested factorio = buggy

and i tested multiple users but i got no video recieved error or games would just not launch (sorry that it is in dutch)

Can you confirm just a few things first?

Have you edited the config.toml with the updated pipeline for VAAPI that was posted before?

######################
# Default settings for the main encoders
# To avoid repetition between H264, HEVC and AV1 encoders

[gstreamer.video.defaults.vaapi]
video_params = """
queue !
vapostproc !
video/x-raw(memory:VAMemory), chroma-site={color_range}, width={width},
height={height}, format=NV12, colorimetry={color_space}
\
"""

Have you changed the app_state_folder to be shared between clients in the config.toml?

Have you manually changed anything else in the config file btw?

Have you tried lowering the resolution, does that help in any way like it does for @salty2011?

I just tried the updated config.toml to the updated pipeline for VAAPI. baldurs gate 3 still has the black screen and factorio still has the same problem
I have not change the app_state_folder or any other config file
in 720p factorio is a bit less  buggy and baldurs gate 3 still has a black screen
"The 'No Video Received' issue occurs when I launch Steam, another user launches Steam on the same network, and then I quit and relaunch Steam."

I have tested some additional games:
helldivers - works
hollow knight - works
hogwarts legacy - works
doom 2016 - works
dragon dogma - works
cyberpunk - black screen
I think the cause of the black screen is the windowed launcher's both cyberpunk and Baldur's gate 3 have a windowed launcher.
Only factorio has the too large packets problem that i noticed.

Thanks for the report, the multiuser issue is a silly bug; I've opened another issue to track it (https://github.com/games-on-whales/wolf/issues/109) and I'm going to fix it as soon as I have some free time in the next few days.
As for the AMD specific issues, I'll try it with an AWS instance, I'm in the middle of another PR, though, and I'd like to finish that first. Odd that it's tied to the games, I wonder if it's just because some games compress better than others.
I saw you've got AV1, is that encoder causing the same issues as HEVC? You can force it in the Moonlight client settings even if you don't have an HW decoder on your client machine.

I've pushed a fix for the multi-user issue, you can test it out by checking out the
ghcr.io/games-on-whales/wolf:dev-fix-109

image. I'll test it a bit more and merge it to :stable if nobody reports any issue

Thanks for the great work.
I did some further testing.
dev-fix-109:
When two devices are connected to wolf and one uses ctrl+alt+shif+q or alt+f4 to quit out of moonlight is causing wolf to crash from what i can see.
_wolf-wolf-1_logs (10).txt
stable build / dev-fix-109:
Forcing AV1 in moonlight gets the same error as no video received.
Games like cyberpunk/Baldur's gate 3 that launches their own launcher to launch their games

@Vlekkie2005 you are good at hunting bugs, can I run you on CI 😅
I've just pushed an additional fix for that exception that you've triggered, could you docker pull again from that branch and let me know if that fixes the multi-user issues that you're experiencing?

Thanks @ABeltramo it works perfectly as far as i can see.
And i "solved" bg3 from not launching pressing alt+f4 on the black screen with Capture system keyboard shortcuts enabled or using "--skip-launcher" in the starting parameters in steam.

Thanks for checking that out, I'm glad it works!
I'm going to merge that then, and we can keep this open for the AMD specific issues..

Hello,
I've just installed the latest version of Wolf, but I'm encountering a black screen or an issue similar to the one shown in the first image of this thread when starting a game via Steam. My setup includes a 7950X processor and an RX 7800 XT graphics card.
To install Wolf, I used Portainer with the Docker Compose configuration provided in the Quickstart Guide.
In the wolf-wolf-1 container, I see repeated warnings like this: (0:48:09.260856139 1 0x7f10041f9250 WARN appsrc gstappsrc.c:2469:gst_app_src_push_internal:<wolf_wayland_source> Dropping old item buffer: 0x7f10388e4510, pts 0:46:02.949889482, dts 0:46:02.949889482, dur 0:00:00.016666666, size 8294400, offset none, offset_end none, flags 0x0)
Additionally, here is the log from WolfSteam_10730337829953401807 for further reference. _WolfSteam_10730337829953401807_logs (1).txt

hi, i use latest image , and have this issue, i use app_state_folder in second pc have this issue, first is normal


[3.0] Add Router Snapshot Print Support

What is the purpose of the change

Add QoS Router Snapshot Print
Add Router Snapshot Print Filter for service level
Add QoS Enable service level Router Snapshot Print

Brief changelog
Verifying this change

Checklist

[x] Make sure there is a GitHub_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GitHub issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[ ] Each commit in the pull request should have a meaningful subject line and body.
[ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Check if is necessary to patch to Dubbo 3 if you are work on Dubbo 2.7
[ ] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
[ ] Add some description to dubbo-website project if you are requesting to add a feature.
[ ] GitHub Actions works fine on your own branch.
[ ] If this contribution is large, please follow the Software Donation Guide.

Codecov Report

Merging #9517 (8396128) into 3.0 (798840e) will increase coverage by 0.18%.
The diff coverage is 32.44%.

:exclamation: Current head 8396128 differs from pull request most recent head 5867c27. Consider uploading reports for the commit 5867c27 to get more accurate results

@@             Coverage Diff              @@
##                3.0    #9517      +/-   ##
============================================
+ Coverage     65.08%   65.27%   +0.18%
+ Complexity      355      296      -59
============================================
  Files          1218     1188      -30
  Lines         52648    51721     -927
  Branches       7855     7786      -69
============================================
- Hits          34268    33761     -507
+ Misses        14736    14287     -449
- Partials       3644     3673      +29

Impacted Files
Coverage Δ

.../rpc/cluster/router/mock/MockInvokersSelector.java
69.23% <0.00%> (-7.92%)
:arrow_down:

.../rpc/cluster/router/state/AbstractStateRouter.java
75.00% <0.00%> (-4.60%)
:arrow_down:

...apache/dubbo/rpc/cluster/router/state/BitList.java
78.63% <0.00%> (-5.01%)
:arrow_down:

.../rpc/cluster/router/state/RouterGroupingState.java
0.00% <0.00%> (ø)

...he/dubbo/rpc/cluster/router/state/StateRouter.java
100.00% <ø> (ø)

...ubbo/rpc/cluster/router/state/TailStateRouter.java
33.33% <0.00%> (-4.17%)
:arrow_down:

...apache/dubbo/common/constants/CommonConstants.java
100.00% <ø> (ø)

...ache/dubbo/qos/command/impl/GetRouterSnapshot.java
10.71% <10.71%> (ø)

.../dubbo/qos/command/impl/DisableRouterSnapshot.java
23.52% <23.52%> (ø)

...e/dubbo/qos/command/impl/EnableRouterSnapshot.java
23.52% <23.52%> (ø)

... and 284 more

Continue to review full report at Codecov.

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


Optimization: filter + scoring by timestamp

There are several ideas we could leverage to sort by timestamp.
When we sort AND filter a timestamp range, we end up fetching the timestamp twice.
The timestamp is often almost sorted.
A minor amount of metadata could make it possible to restrict our query.
within [t_start, t_end] implies doc in [doc_a, doc_b]

I think this is similar to what I wrote here recently https://github.com/quickwit-oss/tantivy/issues/2352#issuecomment-2067577027 :

I've been thinking if we should flag fast fields as almost sorted during creation (e.g. almost sorted in a range of 100 values) and then use that information to do a binary_search + 100 values scan.

The almost sorted check could be done during serialization and should not cost much.

Yes. Let's keep that for later though. :)


Removed quotes from Norway

Can you make the same for other languages if it's not on purpose?
P.S.: Thanks for this repository. It's extremely useful!

Tests fail. I suspect that's why we quoted it. Could you try to get the tests passing without it being quoted?

Closing because NO is translated as false by yaml


Update LastOrNone method summary in Sequence.cs

Hello!
Just a small typo fix in method's summary.
It is going to be my first PR. I hope I am doing it right.
Thanks!

Hi @mozesa , thanks for your contribution!


Unexpected method behavior upon interpolated call of "accessor-like" method.

Laravel Version: 5.6.9
PHP Version: 7.1.7
Database Driver & Version: MySQL 5.7.19

Description:
When invoking a method which is named like an "accessor/getter" through string interpolation, it will trigger the __get magic function resulting to unexpected method behavior.
Steps To Reproduce:

Create two models.
SampleModel.php, SampleRelatedModel.php

Create relationship in SampleModel.php
public function relatedModels()
{
    return $this->hasMany(SampleRelatedModel::class);
}

Create an "accessor-like" method for relatedModels in SampleModel.php
public function getRelatedModels()
{
    return "Sample Method";
}

Test the methods

Call $sampleModel->relatedModels;. This will return a collection of SampleRelatedModels related to it.

Call $sampleModel->getRelatedModels(). This will return "Sample Method" string.

Now, interpolate the previous call. "$sampleModel->getRelatedModels()".

This will cause an error saying: method getRelatedModels should return a relationship.

I've traced the method calls, it seems to me that the interpolated call triggered the magic __get method of the model.
This is the result of what I've traced.
// Model.php
public function __get($key)
{
    return $this->getAttribute($key);
}
// |
// V
// HasAttributes.php
public function getAttribute($key)
{
    ...
    return $this->getRelationValue($key);
}
// |
// V
// HasAttributes.php
public function getRelationValue($key)
{
    ...
    if (method_exists($this, $key)) {
        return $this->getRelationshipFromMethod($key);
    }
}
// |
// V
// HasAttributes.php
protected function getRelationshipFromMethod($method)
{
    $relation = $this->$method(); // <-- lastly to this
    // $method = "getRelatedModels"
    if (! $relation instanceof Relation) {
        throw new LogicException(sprintf(
            '%s::%s must return a relationship instance.', static::class, $method
        ));
    }
    ...
}

I'm not sure if this bug is PHP-specific or Laravel-specific. The bug was discussed here: https://stackoverflow.com/questions/49378402/laravel-type-error-too-few-arguments-to-function-app-productgettax-0-pa/49379823#49379823

This is neither a issue with Laravel, nor with PHP. You are just using the wrong syntax:
"$sampleModel->getRelatedModels()" is equivalent to "$sampleModel->getRelatedModels"."()".
The usage of variables in strings is limited to "$foo" and "$foo->bar". Function calls like "$foo->bar()"
don't work. You can (but shouldn't) use curly braces for that: "{$foo->bar()}"
The better solution is just simple string concatenation:
"text..." . $sampleModel->getRelatedModels() . "more text..."

Ok thanks! Got it!


Add all core exercises from Java track

Java track maintainers have established core exercises for the language some of which have been already implemented in Groovy.
I propose to add the rest:

[x] two-fer
[ ] scrabble-score
[ ] secret-handshake
[ ] matrix
[x] triangle
[ ] rotational-cipher
[x] saddle-points
[ ] flatten-array
[ ] linked-list
[x] binary-search
[ ] bank-account

It would be better to add separate PR for each exercise. And don't forget about a list of exercise topics and its difficulty score

In case it is useful, the documentation for how to implement an exercise from a problem specification is here: https://github.com/exercism/docs/blob/master/you-can-help/implement-an-exercise-from-specification.md

Checking off scrabble-score, just implemented by @mattmoss .

Closed with PR #141, which was the last core exercises from Java track needed.


Release version 15.0.2 on NuGet

I am getting this exception:
Unhandled exception: System.ArgumentException: Stream was not writable.
   at System.IO.StreamWriter..ctor(Stream stream, Encoding encoding, Int32 bufferSize, Boolean leaveOpen)
   at ClangSharp.PInvokeGenerator.<Close>g__GenerateNativeInheritanceAttribute|56_0(PInvokeGenerator generator, Stream stream, Boolean leaveStreamOpen) in /_/sources/ClangSharp.PInvokeGenerator/PInvokeGenerator.cs:line 367
   at ClangSharp.PInvokeGenerator.Close() in /_/sources/ClangSharp.PInvokeGenerator/PInvokeGenerator.cs:line 311
   at ClangSharp.PInvokeGenerator.Dispose(Boolean isDisposing) in /_/sources/ClangSharp.PInvokeGenerator/PInvokeGenerator.cs:line 1789
   at ClangSharp.PInvokeGenerator.Dispose() in /_/sources/ClangSharp.PInvokeGenerator/PInvokeGenerator.cs:line 1260
   at ClangSharp.Program.Run(InvocationContext context) in /_/sources/ClangSharpPInvokeGenerator/Program.cs:line 775
   at System.CommandLine.Handler.<>c__DisplayClass1_0`1.<SetHandler>b__0(InvocationContext context)
   at System.CommandLine.Invocation.AnonymousCommandHandler.<>c__DisplayClass2_0.<.ctor>g__Handle|0(InvocationContext context)
   at System.CommandLine.Invocation.AnonymousCommandHandler.InvokeAsync(InvocationContext context)
   at System.CommandLine.Invocation.InvocationPipeline.<>c__DisplayClass4_0.<<BuildInvocationChain>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass18_0.<<UseParseErrorReporting>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass13_0.<<UseHelp>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass20_0.<<UseTypoCorrections>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<UseSuggestDirective>b__19_0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass17_0.<<UseParseDirective>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<RegisterWithDotnetSuggest>b__6_0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass9_0.<<UseExceptionHandler>b__0>d.MoveNext()

which I suspect was fixed by #393, which was fixed in version 15.0.2. However this version does not exist on NuGet, the latest is 15.0.1. Can you release 15.0.2?

Just saw it was released. Thank you!


Handle strip_include_prefix and include_prefix attributes

These attributes use the _virtual_includes directory which is not materialized outside of the sandbox.
In this scenario, the command line generated from this project will work when --spawn_strategy=standalone was used when building the cc_* targets, but not without it.
Thanks @FaBrand for noticing this.
Related issues elsewhere:
https://github.com/bazelbuild/intellij/issues/145
https://github.com/bazelbuild/intellij/issues/510

The intellij issues have not had progress. So I have filed https://github.com/bazelbuild/bazel/issues/10845 in the bazel repo to discuss more.


[Bug] Workflow is always Running

Workflow example to reproduce the bug:
class ExampleWorkflow implements ExampleWorkflowInterface {

    public function start(): string|\Generator
    {
        $promises = [];

        foreach (range(1, 20) as $i) {
            $promises[] = Workflow::async(function () use ($i) {
                yield Workflow::timer(random_int(5, 10));
                $this->completedIds[] = $i;
            });
        }

        Workflow::async(function () {
            yield Workflow::timer(30);
            $this->completedIds[] = 21;
            $this->continue = true;
        });

        Workflow::await(
            Promise::all($promises),
            fn () => $this->continue,
        );

        return 'FINISHED';
}

Expected behavior:
After 10 seconds of execution the workflow stops since the first clause (Promise::all is resolved)
Actual behavior:
The workflow never stops 😿

I've also tried following workaround:
class ExampleWorkflow implements ExampleWorkflowInterface {

    public function start(): string|\Generator
    {
        $promises = [];

        foreach (range(1, 20) as $i) {
            $promises[] = Workflow::async(function () use ($i) {
                yield Workflow::timer(random_int(5, 10));
                $this->completedIds[] = $i;
            });
        }

        Workflow::async(function () {
            yield Workflow::timer(30);
            $this->completedIds[] = 21;
            $this->continue = true;
        });

        yield Promise::any([
            Promise::all($promises),
            Workflow::await(fn () => $this->continue),
        ]);

        return 'FINISHED';
}

It finishes the workflow. But only after Workflow::await clause resolution. But I expect to finish it after batch of promises completion.
I've tried many other identical expressions (like Promise::await(Promise:all($promises)); instead of simple Promise::all($promises);), but nothing worked as I expected
What I am trying to implement is the opportunity to stop batch of promises execution (via external workflow signal). In non-minimalist real code example these promises are allowed to never resolve at all.

Hi @OlegKuro! I think the problem is - missing yields here. With Workflow::await() and Workflow::await() you just create promises. To actually execute the code inside you need to call yield. So, your first workflow can be rewritten this way:
final class ExampleWorkflow
{
    private array $completedIds = [];
    private bool $continue = false;

    #[WorkflowMethod]
    public function handle()
    {
        $promises = [];

        foreach (range(1, 20) as $i) {
            $promises[] = Workflow::async(function () use ($i) {
                yield Workflow::timer(1);
                $this->completedIds[] = $i;
            });
        }

        yield Workflow::async(function () {
            yield Workflow::timer(30);
            $this->completedIds[] = 21;
            $this->continue = true;
        });

        yield Workflow::await(
            Promise::all($promises),
            fn () => $this->continue,
        );

        return 'FINISHED';
    }
}

Thank you for your reply! 🤗
Indeed! It works if I use yield correctly. But it resolves after both Promise and Closure completion. What if I need to create a bunch of interruptable actions? 🤔
Is there any way to implement following main function example using temporal capabilities?

JavaScript identical to what I am trying to implement snippet
You can merely paste it into a browser console and run `runAndThenInterrupt` and `runAndWaitForPromises` functions
let doContinue = false;

function sleep(ms) {
    return new Promise(resolve => {
        setTimeout(() => resolve(), ms)
    })
}

function sleepAndLog(ms, id) {
    return sleep(ms).then(() => {
        console.log(`${id} completed!`);
    })
}

async function main(interruptor) {
    async function interruptor() {
        return new Promise(resolve => {
            let intervalId = setInterval(() => {
                if (doContinue) {
                    doContinue = false;
                    console.log('interruption signal received!');
                    clearInterval(intervalId);
                    resolve();
                }
            }, 0);
        })
    }
    promises = [sleepAndLog(1000, 1), sleepAndLog(500, 2), sleepAndLog(1500, 3)];

    await Promise.any([
        Promise.all(promises),
        interruptor(),
    ]);

    console.log('promise any resolved!');
}

async function runAndThenInterrupt() {
    main();
    await sleep(700);
    doContinue = true;
}

function runAndWaitForPromises() {
    main();
}

Why this example does not work as expected? 😵

In your last example you have a missing yield keyword before the second Workflow::async:
yield Workflow::async(function () {
    yield Workflow::timer(30);
    $this->completedIds[] = 21;
    $this->continue = true;
});

yield Promise::any([
   Promise::all($promises),
   Workflow::await(fn () => $this->continue),
]);

Btw, I do not see yield before Workflow::async in example from documentation. Is it official way of using Workflow::async 🤔 ?
Coluld you please explain why sometimes Workflow::async works without yield before it?
For example, If I create array of promises with help of Workflow::async and then wait for their resolution viaPromise::allmethod, it works 🤯


Live updates are functional

Merging because Smith and Ryan gonna jump on the theming and they would like to see this


Creating images

When replacing the images I have an error 'ValueError: images do not match'. Does anyone know how the images should be saved? Any advice would be helpful. Thank you!

This usually happens when the images are not the same size.


labels without keys

Hi,
I've been trying out jiralert, and really like it but one thing I noticed is that the labels come out in KEY=VALUE format. Is it possible to specify a label value without the key?
The reason I ask is because the jira board I'm assigning tickets to, filters on a single label called "CFT".
Thanks for any help,
Ed

I found one way round this by hardcoding labels in the receiver configuration, however this seems to overwrite the jiralert label ALERT(key=value) which appears to be used to prevent duplicate tickets opening.
fields:
  labels: ["CFT"]

Further to my last post, I managed to overcome the duplicate tickets issue using the following configuration. This works though might seem a bit of a hack.
config/jiralert.yml
fields:
  labels: ["CFT", '{{ template "sm.labels" . }}']

config/jiralert.tmpl
{{ define "sm.labels" }}ALERT{alertname="{{ .GroupLabels.SortedPairs.Values | join "," }}"}{{ end }}
I now have two labels on the jira ticket:
ALERT{alertname="TestAlert"} CFT

Wow, impressive problem solving skills. (o:
Yeah, the labels should be cumulative, but I guess any label you set via fields.labels will overwrite the ALERT label used by JIRAlert to identify which alert this is.
Will need some code tweaks for special handling of custom labels added via fields.labels. Might also need to check if any other fields need similar special handling (although most of them are single-valued rather than lists, so overriding is likely the expected outcome there, even though it wouldn't make much sense).


Update sans-serif fonts list

I've updated the sans-serif font list.
Here a references that justify my changes: https://css-tricks.com/snippets/css/system-font-stack/

@pauloxnet, sorry for the delay.
I delayed this PR aside because I was working on v2, and it was a major breaking change for v1.
Would you like to update this PR against the v2 branch?
https://github.com/picocss/pico/tree/v2
https://github.com/picocss/pico/blob/v2/scss/themes/default/_styles.scss#L15-L16

Would you like to update this PR against the v2 branch? https://github.com/picocss/pico/tree/v2 https://github.com/picocss/pico/blob/v2/scss/themes/default/_styles.scss#L15-L16

I opened the new PR #436


mask can be seen on android 4.4.2

using the arc i get a black mask showing on the left and right (where the arc is) of the view this is only showing up on android 4.4.2
have tried changing the order of the views inside and outside the view group to no avail

can you send an image ?

OBVIOUSLY!!!
Reply to this email directly, view it on GitHub
https://github.com/florent37/ShapeOfView/issues/16#issuecomment-391387811,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFfQXLNNkifBQXiRga40rMz9ahTJ7WNMks5t1X6FgaJpZM4UKmxV
.


link issue in prepareModel.sh

Hi,
When I try to do prepareModel.sh I have the following error in linking anntest :
[100%] Linking CXX executable anntest
//opt/rocm/lib/libMIOpen.so.1: undefined reference to MIOpenGEMM::Geometry::initialise(bool, bool, bool, bool, unsigned long, unsigned long, unsigned long, unsigned long, unsigned long, unsigned long, unsigned long, char)@MIOPENGEMM_1' /opt/rocm/mivisionx/lib/libvx_nn.so: undefined reference to MIOpenGEMM::GemmStatus MIOpenGEMM::xgemm(bool, bool, bool, unsigned long, unsigned long, unsigned long, float, _cl_mem*, unsigned long, unsigned long, _cl_mem*, unsigned long, unsigned long, float, _cl_mem*, unsigned long, unsigned long, _cl_mem*, unsigned long, unsigned long, _cl_command_queue**, unsigned int, _cl_event* const*, _cl_event**, int)@MIOPENGEMM_1'
Any idea ?
then when I go to trafficVision and I do make test I have the following error
OK: OpenVX using GPU device#0 (gfx900) [OpenCL 2.0 ] [SvmCaps 0 0]
OK: annCreateInference: successful
TETS
Traceback (most recent call last):
File "./main.py", line 58, in
yoloNet = inference.yoloInferenceNet(yoloOpenVX.weights);
File "/home/goose/GOOSE/YOLO/trafficVision/inference.py", line 29, in init
input_info,output_info = yoloOpenVX.interface.annQueryInference().decode("utf-8").split(';')
ValueError: too many values to unpack
Makefile:8: recipe for target 'test' failed
make: *** [test] Error 1
Can you help ?
Thanks
Regards
G.

Ok I fixed it :)
it's running well now

Awesome.
You mind sharing the solution to benefit other users/developers?

I meet the same problem. And solve it myself!
yoloOpenVX.interface.annQueryInference().decode("utf-8") # print it shows, XXX;XXX;
so split(';') the result is ['XXX', 'XXX', '']
only need two elements.
so change code to
input_info,output_info = yoloOpenVX.interface.annQueryInference().decode("utf-8")[0:-1].split(';')
or change the config file text, remove the last ';'


Hotel images don't load.

Seems like it may just not be pointing to the right folder. Should be a pretty easy fix.
likehome.rentals shows a broken link when searching for hotels.


Error: Error reading response: Response does not contain content type

Hi
I am getting this error in statusCallback
I am using
  	res.status(200)     .contentType('text/html')     .send();
To send response to twilio

Hi @jimmylogic
Can you provide us more information about the problem such as the use case (making outbound calls, testing push notifications) and what is the endpoint your application is hitting?
thanks
-bobie


Rewrite setup script to be a single file

Previously we had a Ruby script to setup GOV.UK Docker, which was hard to
understand because the setup spanned multiple files and methods.
This rewrites the setup into a single script. A couple of features of the
original script haven't been carried over:

Since all the changes are necessary and isolated, we don't ask before
doing them
We only expect people to run setup once in the repo, so no more
repo/pull stuff

This also adds an extra command to ensure the system resolver picks up the
new config in /etc/resolver, which has been a problem for some.
Supersedes and closes https://github.com/alphagov/govuk-docker/pull/160.

@issyl0 so it does - I've updated the description to reflect that. We went from having no setup script at all to something quite sophisticated, and I'd like to see if we can get by with just this. Objectively, it's also quicker to setup GOV.UK Docker because that no longer requires rbenv+bundler.
Sorry, your tests were a necessary casualty :-).

I've also added an extra commit to fix a test error that popped up late-on.

I added "and closes", as "close" or "fix" is the keyword for auto-closing PRs/issues with the merging of other PRs.

You missed one:
╭─isabelllong@gds5567 ~/govuk/govuk-docker ‹rewrite-setup-command›
╰─ $ ./bin/doctor
Checking govuk-docker
Traceback (most recent call last):
	2: from ./bin/doctor:12:in `<main>'
	1: from /Users/isabelllong/govuk/govuk-docker/lib/govuk_docker/doctor/doctor.rb:5:in `messages'
/Users/isabelllong/govuk/govuk-docker/lib/govuk_docker/doctor/doctor.rb:71:in `dnsmasq_messages': undefined method `dnsmasq_conf' for GovukDocker::Paths:Class (NoMethodError)

Thanks @issyl0!


github: Added CI for linting and compiling checks

Detailed description
Adding automated checks for lint rules and making sure that the project compiles reduces the chance of incorrect code finding its way to the code base.

Your checklist for this pull request

[x] I've read the Code of Conduct
[x] I've read the guidelines for contributing to this repository
[x] It builds and lints cleanly
[x] I've tested it to the best of my ability
[x] My commit messages provide a useful short description of what the commits do
[x] I've made sure that my commits are signed/verified

Closing issues

All review items should now be addressed


Viewing any of the foliage in the Mushroom Meadow causes GPU usage to increase ~10x

Please check if your issue is not a duplicate by searching existing issues
Describe the bug
There's something wrong with the foliage there. It causes way more strain than it should on the GPU.
To Reproduce
Go to the Mushroom Meadow and zoom out. Any machine, no matter the GPU, will see a huge increase in GPU usage and a pretty big drop in framerate. I go from 50FPS/25% usage to about 20FPS/100% usage.
Expected behavior
It should have the same effect as other foliage. It can't just be the sheer amount. There's something with it that's very inefficient and harmful. It's making it impossible to do herbiboars.
Environment (please complete the following information):
Windows, latest RuneLite version, Radeon 270X.
Additional context
I'm aware some people have reported low framerates in this area, but I've actually investigated it. If I stand at the triple hardwoods and look at the grass, I'm fine. If I turn the camera, even just a little, to show the weird fungi over by the herbiboar holes, I get instant framerate drops.

Duplicate of #6528

Nope. That OP's issue was due to Intel's GPU being used. This is due to the foliage.

Its still same issue, intel gpu doesnt matter in this case

Ok, I posted it there.


Reorganization of the main process

On top of #154
Major things:

Main process code separated out into parts and put into new folder Sia-UI/mainjs to distinguish from Sia-UI/js. I'm open to a better naming scheme.
Moved Config management logic to main process. It seems more logical and makes getting and setting the config.json through ipc much simpler.
Turns

(plugin sends ipc to host/UI) ->
(pluginManager receives ipc and calls uiManager config) ->
(uiManager gets or sets and returns) ->
(pluginManager receives and sends to plugin) ->
(plugin listens on ipc)

into
(plugin sends synchronous ipc to main process) ->
(main process gets or sets and returns) ->
(plugin receives value without listening on an ipc channel)

Siad startup logic now in main process as well.
As a result, siad closes upon UI exiting. It didn't before on Linux even though it was supposed to.
Upon startup, if Sia is not detected, a series of dialog messages are shown for the user to either 1. Pick the location of their siad file or 2. Download one into their root folder

Minor things:

npm install runs npm run sia-import. Not sure why I took that out before.
Moved notification logic from uiManager to another js file
Revamped the notification system a bit
Fixed a bunch of notification errors before. It was pretty broken before
Changed notify ipc channel to notification everywhere

justGetSia.js is not a great name, what about getSia.js?

what is the difference between the mainjs and js folders?


unable to play using Xbox Controller

System : Windows 8.1 running NESbox Emulator.
steps to recreate issue:

Check task manager - ensure no running NESbox emulators are running
unplug / replug controller
Load NesBox
Run game (legend of Zelda) - game loads from restore point - cannot use controller.
Keyboard works as expected.
Try lanuching a new game not previously played
controller fails to work
Have been able to use controller for other games, and it is seen by Windows.

@computamike thank yuo for the bug reportr


Incompatible versions of the Mapbox-SDK-iOS

I am developing an application where I need to use the mapbox maps and also use the flutter_mapbox_navigation package to launch the navigation function.
I am using these versions:
mapbox_gl: ^ 0.12.0
flutter_mapbox_navigation: ^ 0.0.19
Using both, I get an error on iOS when installing Cocoapods dependencies as they use different versions of Mapbox-SDK-iOS.
mapbox_gl => Mapbox-SDK-iOS 6.3.0
flutter_mapbox_navigation => Mapbox-SDK-iOS 5.9.0
Has someone presented the same situation and managed to solve it?

@yadames Have you solved this?

Please update version of both to latest


Same configuration, but not the same behavior in Windows and Linux: Spawning language server with cmd: clangd failed.

Problem description
Spawning language server with cmd: clangd failed. The language server is either not installed, missing from PATH, or not executable.
The same configuration works fine under ArchLinux(wsl), but not under Windows
Why do you think this is an issue with mason-lspconfig.nvim?
I'm not sure if it's Mason's problem, but I wondered if there was a problem with the download
Neovim version (>= 0.7)
windows:NVIM v0.8.2
archlinux(wsl):NVIM v0.8.2
Operating system/version
windows:windows 11 /archlinux :Linux 9a3b81476179 <IP_ADDRESS>-microsoft-standard-WSL2 #1 SMP Fri Apr 2 22:23:49 UTC 2021 x86_64 GNU/Linux
I've manually reviewed the Nvim LPS client log (:LspLog) to find potential errors

[X] Yes

I've recently downloaded the latest plugin version of mason.nvim, mason-lspconfig.nvim, and nvim-lspconfig

[X] Yes

Affected language servers
clangd
Steps to reproduce

add init.lua

-- https://github.com/folke/lazy.nvim

local lazypath = vim.fn.stdpath("data") .. "/lazy/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",
        "--branch=stable", -- latest stable release
        lazypath,
    })
end

vim.opt.rtp:prepend(lazypath)

require("lazy").setup(
    {
        {
            "williamboman/mason.nvim",
            config = function()
                require("mason").setup {}
            end
        },
        {
            "williamboman/mason-lspconfig.nvim",
            config = function()
                require("mason-lspconfig").setup {
                    ensure_installed = { "clangd" },
                    automatic_installation = true,
                }
            end
        },
        {
            "neovim/nvim-lspconfig",
            config = function()
                require("lspconfig")['clangd'].setup {}
            end
        },
    }
)

nvim demo.cpp

Actual behavior

Expected behavior
On Windows can be consistent with Linux
LspInfo
Press q or <Esc> to close this window. Press <Tab> to view server doc.

 Language client log: C:\Users\Qu\AppData\Local\nvim-data\lsp.log
 Detected filetype:   cpp

 0 client(s) attached to this buffer:

 Other clients that match the filetype: cpp

 Config: clangd
 	Refer to :h lspconfig-root-detection for help.
 	filetypes:         c, cpp, objc, objcpp, cuda, proto
 	root directory:    Not found.
 	cmd:               clangd
 	cmd is executable: true
 	autostart:         true
 	custom handlers:

 Configured servers list: clangd

LspLog
No response
Healthcheck
mason: require("mason.health").check()
========================================================================
## mason.nvim report
  - OK: neovim version >= 0.7.0
  - OK: **Go**: `go version go1.19.5 windows/amd64`
  - OK: **cargo**: `cargo 1.66.0 (d65d197ad 2022-11-15)`
  - WARNING: **luarocks**: not available
  - WARNING: **Ruby**: not available
  - WARNING: **RubyGem**: not available
  - WARNING: **Composer**: not available
  - WARNING: **PHP**: not available
  - ERROR: **npm**: not available
  - ERROR: **node**: not available
  - OK: **python3**: `Python 3.11.1
`
  - OK: **pip3**: `pip 22.3.1 from C:\Scoop\apps\python\current\Lib\site-packages\pip (python 3.11)

`
  - OK: **javac**: `javac 19.0.1
`
  - OK: **java**: `openjdk version "19.0.1" 2022-10-18
`
  - WARNING: **julia**: not available
  - ERROR: **wget**: not available
  - OK: **curl**: `curl 7.83.1 (Windows) libcurl/7.83.1 Schannel
`
  - WARNING: **gzip**: not available
  - OK: **tar**: `bsdtar 3.5.2 - libarchive 3.5.2 zlib/1.2.5.f-ipp bz2lib/1.0.6
`
  - ERROR: **pwsh**: not available
  - OK: **python**: `Python 3.11.1
`
  - OK: **pip**: `pip 22.3.1 from C:\Scoop\apps\python\current\Lib\site-packages\pip (python 3.11)

`
  - OK: **7z**: `7-Zip 22.01 (x64) : Copyright (c) 1999-2022 Igor Pavlov : 2022-07-15
`
  - ERROR: GitHub API rate limit exceeded. Used: 60. Remaining: 0. Limit: 60. Reset: 2023/1/26 13:44:51.

Screenshots or recordings
No response

Hey! This is probably happening because the config hook for lspconfig executes before Mason. You need to ensure that Mason is set up before lspconfig.

I had the same issue with rust-analyzer, and I figured out that mason installs binary packages and put a wrapper shell script into a single bin directory, in this way it would only need to add one entry to the PATH environment variable. in my case, it is named rust-analyzer.cmd. this is usually fine, so long you run this command through a shell, as the .cmd suffix is recognized by the Windows shell. e.g. :lua =vim.fn.system 'rust-analyzer --version' would give me the correct version, and I can type rust-analyzer --version directly into a nvim terminal too. I guess the lsp integration somehow trys to spawn a process directly from this command name, which it can't and hence the error.
in my case, I solved it by manually set the server cmd like so:
-- pass nil will use default setting
local cmd = nil
if jit.os == 'Windows' then
	cmd = { 'cmd.exe', '/c', 'rust-analyzer' }
end
require 'lspconfig'.rust_analyzer.setup {
	cmd = cmd,
}

ps1: my lua_ls works out of the box, but rust-analyzer doesn't
ps1: I am not sure my problem is caused by setup order, as I have my setup code explictly specifying mason-lspconfig should load after mason.nvim:
packer.use {
	'williamboman/mason.nvim' ,
	config = function() require 'mason'.setup {} end,
}
packer.use {
	'williamboman/mason-lspconfig.nvim',
	requires = { 'williamboman/mason.nvim', 'neovim/nvim-lspconfig', },
	after = { 'mason.nvim', },
	config = function() require 'mason-lspconfig'setup {} end,
}
packer.use {
	'neovim/nvim-lspconfig',
	after = { 'mason-lspconfig.nvim', },
	config = function()
		local lsconfig = require 'lspconfig'
		-- server settings omitted
	end,
}

I got some error like this
Spawning language server with cmd: /data/data/com.termux/files/home/.local/share/nvim/mason/bin/intelephense failed. The language server is either not installed, missing from PATH, or not executable.
I use AstroNvim, it works on Linux Ubuntu, but it doesn't work Termux(latest build, android 14), if I run $ intelphense it show the script and I think it executable
So how to fix it?


MAISTRA-746 Set maxUnavailable to 0 for grafana, prometheus deployments

Istio 1.1 is still using the extensions/v1beta1 API definition of deployments, which defaults maxUnavailable to 1. This can lead to the operator assuming the deployments are available, when in fact they are not, e.g. due to the oauth-proxy not being able to start. This commit injects a maxUnavailable value of 0 into grafana & prometheus deployments.
Note that all other deployments already specify maxUnavailable: 0

This needs to be done for gateways as well.

You're right; I thought this was in there already, must have been looking in the wrong place. Thanks!


[Core] Move vector2 to its own file, grammar, move defs to defs

I've moved vector2 to its own file instead of having it sit in math_2d, I've tweaked some grammar, and I've moved the math constant defs such as PI and TAU to math_defs.h (and added a few).
These changes improve the readability of the math code. CC @reduz @akien-mga See: https://github.com/godotengine/godot/issues/5691

I'm not against it, but why moving Vector2 and not Rect, Transform2D, Point2i (which should be renamed Vector2i someday for consistency) or Rect2i ?
This is quite inconsistent. Either we put all classes in the same file, either we split them all.

Rect2 and Transform2D refer to each other inside of math_2d, so I'm not sure of the best way to go about splitting them. I would not rename Point2i to Vector2i because does not behave like a vector.
My idea is to eventually change all instances of Point2 into Vector2 and eventually change Point2i to Point2. I think it would be more useful to have these terms refer to different things, instead of to the same thing. And Point2 vs Point2i is only one letter difference, it would be better for readability too if we had Point exclusively refer to integers and Vector exclusively refer to floats. But this is a discussion for another thread. The first step IMO is to organize existing stuff like Vector2.

Honestly I don't think that, as is, it improves readability.
The current code organisation is fine to me. It's simple to include it as a single file, I'm not sure it's a gain splitting them, especially because it makes sinces more inconsistent in my opinion. Since, from my experience, it's rare having to use Vector2 without the remaining of the 2D tools (at least in the core/editor code)

What's inconsistent is the fact that 3D classes get their own files, but 2D is all in one.
There are plenty of times where Vector2 is used but not the rest of math_2d. For example, when working with screen positions, or when translating objects, or with texture UVs. Vector2 is used in 3D.

I found 7 other files where Vector2 is used but the rest of math_2d is not, and I've made a fixup to my commit which changes the #include of these files to "vector2.h".
I'm not sure if this helps with performance but it definitely is more organized to only include what's needed.

I made a minor fixup to move the new C# constants from MathfEx to Mathf since it's now in C++ too.

In C++ but not in GDScript ? The purpose of MathfEx is to divide the GDScript / C#(not C++) open constant/methods and extensions from each other. And whats the Math_SQRT12 and Math_LN2 ?

If you so want to add a new constant to engine than you should watch this example - https://github.com/godotengine/godot/pull/12627/files and do like this, and adding something new only to C++ does not make sense

Good point, I forgot for a bit what was the point of splitting (GDscript lacking it, not C++). I may attempt adding those to GDscript in another PR, but for now, I'll revert those Mathf/MathfEx changes.
The rest of this PR should be good, though.

At this point I'm completely lost about what PR is about

@reduz It's primarily about moving Vector2 to its own file, for consistency with Vector3 etc. I made a few other minor changes as well so I just put them in this PR (rather than making two PRs).
If you'd like, I can split the Vector2 move and everything else into two commits on this PR.

I would do something like this:

kill math_2d
move Vector2, Vector2i to vector2.h
move Rect2 and Rect2i to rect2.h
move Transform2D to transform_2d,h

move Point2 and Point2i to vector2.h too

@reduz Do you want me to do all that (killing math_2d entirely) in this pull request?

@reduz I've done all of that now, math_2d is dead!


Fatal error: Some files can't be processed by RIblast with throwing exceptions.

When comprehensive analysis has done, some input files (22 over 1524) can't be processed by RIblast with a option, "ris".
All the exception messages are the same:
"terminate called after throwing an instance of 'std::out_of_range'
what():  basic_string::substr: __pos (which is<PHONE_NUMBER>3709551615) > this->size() (which is 1)".
The input files' names are not problems because when I changed the  name of one of them into
another such as "hoge.fa" and processed it in the same command, but it failed.
And the input seq. length seems to be not a problem because one containing longer seq. length has been processed properly.
The problem should be debugged by a debugger such as GDB.
But the debug could be difficult without the fatal cases, so I uploaded them (the input files, the database) into my temporary repo (https://github.com/heartsh/riblast-ftl-css).
The command options should be default ones.

Thank you for your bug report.
I fixed your bug and updated RIblast version.


cowin_vaccine_data_districtwise unable to download

rtpcr_samples_collected, vaccine_doses_administered_statewise, cowin_vaccine_data_statewise, cowin_vaccine_data_districtwise none of the data can be downloaded

Its working fine on our end . Try switching browsers or clearing cache.


Lag in Connect Time for Proxy Store?

I have a minimal project running where there are a couple of reducers with default values running in the background. I use wrapStore immediately in the background script and immediately set up a proxy store via the Store constructor in my popup window. I noticed that this leads to an empty object state in one of my container components (when mapeStateToProps is called on it). If I set a 100ms timeout before rendering my <PopupApp> surrounded by <Provider> with the proxy store set to it, everything works.
Seems like there may be a race condition? Should I be listening for an event so I know the proxy store has established its connection correctly? Seems like onConnect is a good candidate and the proxy store object should emit some sort of event when the connection has been made and the initial state is filled in?

Check this out and let me know if it helps :)

This totally helps! Thank you man. Totally blanked on the "Docs" section at the bottom of the README. Closing this!

@vhmth Awesome :)


Added support for insecure OCI registries

Signed-off-by: Andrew Block<EMAIL_ADDRESS>What this PR does / why we need it:
Supports connectivity for insecure OCI registries.
Relates to #11352

@souleb for the comment related to the registry_login.go file, did you mean for it to reference the action package instead of cmd?

		registry.LoginOptInsecure(insecure),

I mean that we should use the insecureSkipTLSVerify flag there too, and use the option registry.LoginOptInsecure(insecure) when login.

@souleb got it. There is no actual functionality in the login process aside from the flag option, so I will work on integrating that in as part of this PR

pkg/getter/httpgetter.go should be tested I think and have its own PR.

@souleb is it just the enhancements to pkg/getter/httpgetter.go that should be in a separate PR? Just trying to determine where to split it up

@souleb is it just the enhancements to pkg/getter/httpgetter.go that should be in a separate PR? Just trying to determine where to split it up

Yes. To me that addresses insecure for https repositories.

To me here we adresses OCI registries hosting helm artifacts. An httpgetter is used to access a helm repository (with a index file). So I would say it's out of scope.

@souleb made the requested changes

Tested it, seems to be working.
https://github.com/helm/helm/issues/11683#issuecomment-1378482533


fix: added input error message and description screen reader support

📝 Description
useTextField uses useField which adds aria-describedby only when the errorMessage or `description is provided.
⛳ Current behavior (updates)
aria-describedby does not include the error message or description and thus does not get read out by screen readers.
🚀 New behavior
It gets read out by screen readers.
💣 Is this a breaking change (Yes/No):
No.
📝 Additional Information
https://github.com/adobe/react-spectrum/blob/main/packages/%40react-types/shared/src/inputs.d.ts#L77

Nvm, it actually works right now.


Fix: Remove Kanye from landing page

Putin & Assad apologist Roger Water's most famous work in place? Also 👎

Fair enough, should probably be changed to something though

https://open.spotify.com/album/6KJ8oH9XV1UqTPwU4jCiiV?si=TFZo1fEGQpSq1-UtL9zyUA
My submission:

Fixed in https://github.com/tamagui/tamagui/pull/438


Asphalt 8: Airborne+ Crash

Describe the issue
it crashes after the gameloft logo screen. no error log. tried different versions, got the ipas mainly from iphonecake.com and pdalife.to; ios 18.2
Instructions to reproduce
let it load
What version of LiveContainer are you using?
3.1.0
Other
No response

Do you use it with JIT?

i've tried both ways
On Fri 20. Dec 2024 at 17:17, Mspy1 @.***> wrote:

Do you use it with JIT?
—
Reply to this email directly, view it on GitHub
https://github.com/khanhduytran0/LiveContainer/issues/268#issuecomment-2557304324,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BMUCNS6APVXIKVNB5P5JTS32GQ7KFAVCNFSM6AAAAABT7MZN4WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJXGMYDIMZSGQ
.
You are receiving this because you authored the thread.Message ID:
@.***>

Switch to airplane mode before launching the game and see if it works

Switch to airplane mode before launching the game and see if it works

it worked, thanks. didn't know about that

Switch to airplane mode before launching the game and see if it works

it worked, thanks. didn't know about that

Great, happens with arcade games


Bug Report: Cppcheck and Splint not working

Syntastic is not working for Cppcheck and Splint.
Here are my configuration files:
Syntastic.zip

First problem:

syntastic: 4.455516: checker output: ['cppcheck: error: unrecognized command line option: "--verbose --enable=all --enable=style --enable=performance --enable=portability --enable=information --enable=unusedFunction --enable=missingInclude --inconclusive --force --suppress=missingIncludeSystem".', '']
How are you passing options to cppcheck?

For splint it would be helpful to have a test file that produces 1-2 messages that don't get displayed, rather than 30.

First problem:

syntastic: 4.455516: checker output: ['cppcheck: error: unrecognized command line option: "--verbose --enable=all --enable=style --enable=performance --enable=portability --enable=information --enable=unusedFunction --enable=missingInclude --inconclusive --force --suppress=missingIncludeSystem".', '']

How are you passing options to cppcheck?
For splint it would be helpful to have a test file that produces 1-2 messages that don't get displayed, rather than 30.

The first problem solved. Syntastic only accepts one command per line.
So changing the file .syntastic_cppcheck_config worked.
Now it looks like:
--enable=all
--enable=style
--suppress=missingIncludeSystem

How are you passing options to cppcheck?

None of the options I passed to cppcheck was invalid, otherwise, I'd not get the output from the command-line.
When I didn't redirect the command-line output from cppcheck it worked with the same options and when I did, it worked as well.
Thus,
analyze_w_cppcheck.BAT works when it is:
@echo off
REM https://linux.die.net/man/1/cppcheck
@echo on
cppcheck 2>cppcheck_output.txt --enable=all --enable=style --suppress=missingIncludeSystem *.c *.h
cmd
And, even when it l operate it from the command-line without redirecting anything, as follows:
cppcheck --enable=all --enable=style --suppress=missingIncludeSystem errorfile2.c
Even with all the options (I passed before), cppcheck had no problem. It still works.
@echo off
REM https://linux.die.net/man/1/cppcheck
@echo on
cppcheck 2>cppcheck_output.txt --verbose --enable=all --enable=style --enable=performance --enable=portability --enable=information --enable=unusedFunction --enable=missingInclude --inconclusive --force --suppress=missingIncludeSystem --report-progress *.c *.h
cmd
So, I wasn't passing any invalid argument to cppcheck.

For splint it would be helpful to have a test file that produces 1-2 messages that don't get displayed, rather than 30.

Well! I put splint to the weakest possible checker mode so that it doesn't produce many results.
Now analyze_w_splint.BAT works in the weak mode.
@echo off
REM -weak -standard -checks -strict
@echo on
splint >splint_output.txt -weak *.c
cmd
So as,
.syntastic_splint_config
-weak
What I see is that both the checkers are working internally but the output is not being redirected to any makeprog() buffer window.
Also, I changed the C file with fewer lines of code with fewer test codes.
errorfile2.c
#include <stdio.h>
#include <stdlib.h>
int main() {
char a[20];
a[20] = 0;
gets(a);
printf("a=%s", a);
fflush(stdin);
getchar();
return 0;
}
Find the attached zip file. You'll get the buffer output from :mes and SyntasticCheck.
SyntasticDebugOutput.zip

None of the options I passed to cppcheck was invalid, otherwise, I'd not get the output from the command-line.

The problem here was --verbose --enable=all --enable=style ... was lumped together in a single (very long) option, which is, of course, invalid.  And that's also why splitting the options on separate lines in  .syntastic_cppcheck_config works (this is documented, see :h syntastic-config-format).
You could do the same thing by passing the options as
let g:syntastic_c_cppcheck_args = '--verbose --enable=all --enable=style ...'

or
let g:syntastic_c_cppcheck_args = ['--verbose', '--enable=all', '--enable=style', ...]

but then they would apply to all projects.

The splint case is more interesting.  What's going on here is that because of the long path to your test file the output of splint gets split at 80 columns like this:
Q:\Code_Blocks\VS_Code\projects\helloworld\SyntasticDebugOutput\errorfile2.c(7,3
    ): Use of gets leads to a buffer overflow vulnerability.  Use fgets
    instead: gets
Q:\Code_Blocks\VS_Code\projects\helloworld\SyntasticDebugOutput\errorfile2.c(7,3
    ): Return value (type char *) ignored: gets(a)

This confuses syntastic's parser, which expects ):  to be on the previous line.
This is a bug, but it isn't one that can be fixed reasonably.  As far as I can tell splint can't be configured not to split lines after 80 columns, and fixing it in syntastic is not really possible because there way are too many cases to handle (the output of splint can be too varied).
A workaround is to use shorter (full) paths.  If that's not possible, well, you lose.  Sorry about that.  Syntastic is not a great linting framework for C / C++ anyway.

None of the options I passed to cppcheck was invalid, otherwise, I'd not get the output from the command-line.

The problem here was --verbose --enable=all --enable=style ... was lumped together in a single (very long) option, which is, of course, invalid. And that's also why splitting the options on separate lines in .syntastic_cppcheck_config works (this is documented, cf. :h syntastic-config-format).
You could do the same thing by passing the options as
let g:syntastic_c_cppcheck_args = '--verbose --enable=all --enable=style ...'

or
let g:syntastic_c_cppcheck_args = ['--verbose', '--enable=all', '--enable=style', ...]

but then they would apply to all projects.
Either way, this part was entirely on your side.
The splint case is more interesting. What's going on here is that because of the long path to your test file the output of splint gets split at 80 columns like this:
Q:\Code_Blocks\VS_Code\projects\helloworld\SyntasticDebugOutput\errorfile2.c(7,3
    ): Use of gets leads to a buffer overflow vulnerability.  Use fgets
    instead: gets
Q:\Code_Blocks\VS_Code\projects\helloworld\SyntasticDebugOutput\errorfile2.c(7,3
    ): Return value (type char *) ignored: gets(a)

This confuses syntastic's parser, which expects ):  to be on the previous line.
This is a genuine bug, but it isn't one that can be fixed reasonably. As far as I can tell splint can't be configured not to split lines after 80 columns, and fixing it in syntastic is not really possible because there way are too many cases to handle (the output of splint can be too varied).
A workaround is to use shorter (full) paths. If that's not possible, well, you lose. Sorry about that. Syntastic is not a great linting framework for C / C++ anyway.

Just turned off my machine. Writing from my Android, using the Chrome browser. Syntastic worked fine for my need for many years. Cppcheck and Splint have evolved, Syntastic failed to cope with. I guess the long path isn't really an issue with Splint, rather, it's something to do with the output it produces which cannot be fixed without effort. I have one request though, please try to fix the Cppcheck module. I can go without Splint but Cppcheck is more relevant and important.
Thanks in advance!

There is no problem with cppcheck.  You just have to pass options correctly.

There is no problem with cppcheck. You just have to pass options correctly.

I'll try. Anyways, the last time I checked it, Cppcheck results were not being redirected to makeprog() window. I'll try this again and let you know if it works.

Anyways, the last time I checked it, Cppcheck results were not being redirected to makeprog() window.

If you produce evidence of cppcheck missing messages I'll look at it.

ALE also do not have support for Cppcheck and Splint.

Could be.  It's still a more modern alternative to syntastic, that takes advantage of Vim 8 features, can do async checks, and is actively maintained.  Like I said, syntastic won't go there any time soon.

Anyways, the last time I checked it, Cppcheck results were not being redirected to makeprog() window.

If you produce evidence of cppcheck missing messages I'll look at it.

No. Cppcheck is still not working. However, Splint worked when I moved the folder to the root of the drive Q:\>. Splint was showing a stripped-down version of the total output even when I passed the -strict option.
Get the zip file. Read the debug output. You can reproduce the states if needed. So I consider that now I have the evidence at hand. Have a look at it.

ALE also do not have support for Cppcheck and Splint.

Could be. It's still a more modern alternative to syntastic, that takes advantage of Vim 8 features, can do async checks, and is actively maintained. Like I said, syntastic won't go there any time soon.

ALE works with Cppcheck but not with Splint. I'd disable asynchronous checking even if I ever have to use ALE. Asynchronous autocompletion wouldn't be not too sluggish but asynchronous checking will take too much system resources. I need to check for errors only when I save the file.
SyntasticDebugOutput.zip

Right, cppcheck has evolved too, now it shows column numbers.  Please try 9041bc76.

Right, cppcheck has evolved too, now it shows column numbers. Please try 9041bc7.

I guessed it too. What should I do now? Download from the main branch or manually insert the changes? Wait! I'll download the entire repository as a zip archive then inform you. Many many Thanks!

Right, cppcheck has evolved too, now it shows column numbers. Please try 9041bc7.

Fixed! Confirmed! Close the issue.
So many thanks! Cheers! Three pegs of whisky! Have a nice day!

Okay!


Chang in Reconciler integration test reverted

Description
Changes proposed in this pull request:

Change in Reconciler tests reverted

Related issue(s)
(https://github.com/kyma-project/kyma/issues/16454)

/retest

/testall

/test all

/test pre-main-control-plane-reconciler-e2e-latest-release

/test pre-main-control-plane-reconciler-upgrade-kyma2-latest-to-main-gardener

/test pre-main-control-plane-reconciler-e2e-latest-release

/test pre-main-control-plane-reconciler-upgrade-kyma2-latest-to-main-gardener

/test all


libev publishing subscribing issue

I have a simple multi-threaded application that is giving me trouble. In that application, I have one thread open a connection to RabbitMQ and consume messages from an exchange-key pair. The other thread also opens a connection to RabbitMQ and begins publishing to that same exchange-key pair.
At some point the two threads enter a race condition where the publishing thread takes over and the subscriber no longer receives messages.
I am using two different event loops initialized using ev_loop_new(), which, according to the man pages, is thread safe. When I run the publisher and subscriber in two different processes I have no issues; but, as far as I can tell, the connections for both threads are separate as are the ev_loop's.
My question is why I am I encountering this race condition?

I don't know. The connections and channels do not use global variables or so, so it is safe to create multiple instances in different threads. We do the same all the time.
Could you publish the smallest thinkable program (thus: really small) in which this error occurs?

#include <amqpcpp.h>
#include <amqpcpp/libev.h>
#include "thread"
#include "chrono"

struct ev_loop* loop1 = ev_loop_new();
struct ev_loop* loop2 = ev_loop_new();

void computations(AMQP::TcpChannel* chan) {
    chan->declareExchange("exchange", AMQP::topic);

    int _iterations = 0;
    while(_iterations < 2000) {
        chan->startTransaction();
        std::cout << _iterations << std::endl;
        chan->publish("exchange", "key", "message");
        chan->commitTransaction();

        std::this_thread::sleep_for(std::chrono::milliseconds(1));
        _iterations++;
    }
}

void publisher() {
    std::string host = "amqp://localhost/";
    AMQP::LibEvHandler* handler = new AMQP::LibEvHandler(loop1);
    AMQP::TcpConnection* conn = new AMQP::TcpConnection(handler, AMQP::Address(host));
    AMQP::TcpChannel* chan = new AMQP::TcpChannel(conn);

    std::thread comp(computations, chan);

    ev_run(loop1);
}

void subscriber() {
    std::string host = "amqp://localhost/";
    AMQP::LibEvHandler* handler = new AMQP::LibEvHandler(loop2);
    AMQP::TcpConnection* conn = new AMQP::TcpConnection(handler, AMQP::Address(host));
    AMQP::TcpChannel* chan = new AMQP::TcpChannel(conn);

    auto startCb = [](const std::string&consumertag) {
        std::cout << "Consumer operation started" << std::endl;
    };

    auto errorCb = [](const char *message) {
        std::cout << message << std::endl;
        std::cout << "Consume operation failed" << std::endl;
    };

    auto messageCb = [chan](const AMQP::Message &message, uint64_t deliveryTag, bool redelivered) {
        std::cout << "Message Delivered" << std::endl;
        chan->ack(deliveryTag);
    };

    chan->declareQueue("queue");
    chan->declareExchange("exchange", AMQP::topic);
    chan->bindQueue("exchange", "queue", "key");

    chan->consume("queue")
            .onReceived(messageCb)
            .onSuccess(startCb)
            .onError(errorCb);

    ev_run(loop2);
}

int main() {
    std::thread sub(subscriber);
    std::thread pub(publisher);

    pub.join();
    sub.join();
}

You start three threads in total: the publisher-thread and the computations-thread both access the same AMQP objects, which is wrong.

What would you suggest then? Extend TcpHandler for publishing? Also, why would using the object in multiple threads be wrong? There are no overtly concurrent uses of the channel.

In fact, the appropriate question is: how would you create a Handler or a Connection and use it without an event loop?

You run the event loop in one thread (ev_run inside the publisher thread), which processes all sorts of events on the AMQP Connection and Channel, and updates the internal state of these objects.
At the same time, from a completely different thread (the compulations thread) you start calling methods on the same channel object. These methods also access and update these internal state variables. This is illegal, because a channel object is not thread safe. You cannot use it from multiple threads at the same time.
You asked "how would you create a Handler or a Connection and use it without an event loop?". The answer: you can't. You always need an event loop that you associate with a connection, so that you can process incoming events on the AMQP channel (like heartbeats, or the answers from sent instructions). This event loop allows you to monitor the AMQP connection for activity.
If you want to run a long-running computation inside a different thread, you must, from that other thread, first interrupt the main event loop (using a libev synchronize watcher), and only when you're 100% sure that the event loop came to a halt, you can access the channel object from that different thread.


Add download dandiset dialog

Fixes #473. See #473 for requirements for the component.
Add a DownloadDialog component which provides DANDI CLI commands to
download dandisets.
Factor out a CopyText component to facilitate copying text
snippets and use it in the ApiKeyItem component as well.
Move ApiKeyItem into the top level components directory, as it is
also used in the DownloadDialog.
#473 dictates that download commands for dandiset 000006 work like this:

drafts: dandi download https://dandiarchive.org/dandiset/000006/draft
latest version: dandi download DANDI:000006
specific version: dandi download DANDI:000006/0.200714.1807

@mgrauer @yarikoptic can you confirm?

One more thing, can you change the text they should run to pip install "dandi>=0.6.0" so that if people have a lower version they will be sure to get the right version?

This is great, I have one last request. Could you take the pip command and put it in a copyable element like you do with the DANDI CLI download commands? Apologies for not bundling this with earlier requests.

@mgrauer Sadly no, that's not really feasible without putting the command into a text box, which de-emphasizes that it's a code snippet. It's relatively simple to copy from text inputs, but the pip install dandi thing is in a <kbd>, which is more or less impossible to copy from reliably. I don't think the effort is worth the QOL improvement.

I see. Is it possibly from a layout perspective to have a line break so that the pip install command is all on one line?
If you can do that somewhat easily, please do, otherwise let's merge this as is.