Can't seem to close an issue

print git.editissue(chosen_Project, j, state_event="close")
print git.editissue(chosen_Project, j, state='closed')
print git.editissue(chosen_Project, j, **{'state_event' : "close"})
print git.editissue(chosen_Project, j, **{'state' : "closed"})

The API wrapper is working great for me except I can't seem to close an issue.   Each line of the code above returns false & from what I understand lines 1 & 3 should be working.

Is this still an issue?


acquiring the right image on the right channel, local, UDO or TCP - p…

…utting accordingly the proper constants

hey @kelu124 could we agree on a merge period of 48H max for the moment ? (perhaps more will be needed later)
the issue that the more we wait, the more the commits accumulates, and the review might become more difficult !

@benchoufi sure -- and I would still maintain the need to have a maintainer for each repo "a gate keeper" specialist of the language being written =)
I guess the approval process is on the todo-list of saturday.

ok, I can be one of these for java and web languages, I am going to ask some buddies in the area of work of the app


EBI-25570228?

is there something broken about EBI-25570228?
in the JSON for it (https://www.ebi.ac.uk/intact/ws/graph/export/interaction/EBI-25570228?format=miJSON), there are sequenceData attributes with "participantRef": "3" and "participantRef": "10",
but there are no participants with id "3" or "10"?

@jmedinaebi would you have time to investigate that?


GQLException: [{'message': 'service error', 'path': ['channel', 'viewerDropCampaigns']}]

Encountering new issue when launching the app, deleting cookies.jar did not help.

15:51:57: Fatal error encountered:
15:51:57:
15:51:57: Traceback (most recent call last):
15:51:57:   File "main.py", line 155, in main
15:51:57:   File "twitch.py", line 587, in run
15:51:57:   File "twitch.py", line 747, in _run
15:51:57:   File "twitch.py", line 1656, in bulk_check_online
15:51:57:   File "asyncio\tasks.py", line 571, in _wait_for_one
15:51:57:   File "twitch.py", line 1387, in gql_request
15:51:57: exceptions.GQLException: [{'message': 'service error', 'path': ['channel', 'viewerDropCampaigns']}]
15:51:57:
15:51:57: Exiting...
15:51:57:
15:51:57: Application Terminated.
15:51:57: Close the window to exit the application.

Getting the exact same error message.

Duplicate of #415.
This is the third one I'm closing today. Please really do use the search feature before posting.


Add options argument to String#camelcase and String#underscore

That are the only methods that upcase or downcase a string internally and don't have an options argument. Because what if you speak Turkish and want to camelcase "interesting_integer" to "İnterestingİnteger" instead of "InterestingInteger"? And String#capitalize has it too so I don't see why these shouldn't have it.

Can you update the documentation as well?

I added two turkic examples and fixed String#underscore to properly work with case options.


Discussion on criteria of being in the webring

I guess this is just a question, but I've wondered a couple times if there is any criteria on what should or should not be in the webring. We do explicitly say:

Single page websites, and websites acting only as portals to other social platforms, will be rejected.

and we also mention that wiki's,diaries, blogs, etc are welcome, but do we want to be a bit more explicit on what is actually included? What if someone has a site with like extreme violence or something on there. I know as part of the webring I'd be a bit iffy on someone navigating from my site to that. Should we potentially be a bit more specific on the type of blog, wiki, etc that we'd like to be part of the webring, or keep it wide open?

I also wanted to open an issue like this when I became a moderator. I think we definitely need it, the same way as Merveilles.town has its own rules where we can point to if something's not right, without any personal opinion involved.

I agree.
So far I've been going by feel, and message. In terms of topics, I'm thinking if someone has found its way to the webring's repository and has the knowledge to actually make a PR with their own website, then that means this person has walked part of the way.
I general, No violent content, no racism, sexism or speciesism. I usually do the rounds once every few days, I check what people have been up to, and I think I have each RSS feed into my reader, giving me a bit of an overview. I have not yet found something that made me think someone has violated this.
There was this PR which linked to an incredibly deep website, which I could not be sure it didn't have some kind of potential bad message, so I have not yet merged it. I noticed there were some religious topics and I kind of hold off.
There are some sites that had a blog or a wiki at some point and reverted to a single pager, which I want to remove from the ring, but I would like to get in touch with the person before.

I know what you mean about the PR you mentioned @neauoire, and that's sort of a hard one to gauge. One other related thing, which you touched on, is if a site reverted back to a single page, should we just reach out to the person to potentially see if they have another site they'd possibly like to link to, and if not, remove it from the webring in violation of the no single page rule?
Sort of similar, what if a site goes down? For example there has been a site giving a 503 almost the past week? I sort of feel at the week mark we should reach out and see if they are just doing maintenance or something. If there isn't a response, it may be best to remove it after a week or so in order to not have a dead link in the chain.

We should open an isse and tag that person if we don't have their email, if they don't answer, we remove it yeah.

Sounds good. I'll close this for now. If need be, we can revisit this in the future.

Already revisiting this since I have a question for the both of you (@neauoire  @kodedninja ) which #186 brings up. How do we want to approach sites that are selling services? I know for myself, I really don't want to be browsing the webring and trying to be sold something.
One other question. How do we feel about trackers on sites?

@ckipp01 services are one point, but I would generally try to keep the sites somehow connected (in topic, in style, etc.), which doesn't mean that we should refuse all that are different, but at least keep the transformation natural (by accepting more sites with small differences, even a bigger difference will feel natural over time). This way we can also keep the direction in which the Webring's going in hands.
About trackers: of course, I hate them, but I do understand that some people do like them. So instead of not letting tracked sites into the ring, I would go with "the Webring prefers non-tracked sites". Owners would have to note if the site is tracked and this would be visible in the list. And also, I would exclude them from the random site redirect.
This would encourage owners to remove the trackers, while still keeping the Webring open for them.

@kodedninja Again, I agree with what you're saying. I'm just sort of scratching my head over how exactly to enforce that. For example, @neauoire mentioned #87, which in my opinion falls in line with what you're saying. I don't feel like it fits the webring. I really want to come up with some type of way to make that judgement call rather than it being just a gut reaction. I'm going to assume the way any of the maintainers may approach that call may be a bit different, so it'll be helpful to have something more concrete.
I agree with making a note about "the Webring prefers non-tracked sites". As for the noting it in the sites.js file, I don't know how I feel about that. I'll defer to @neauoire

Good call on the business site PR, that would have been a no for me. The website is a place for personal websites, this found itself too far in the impersonal range of the spectrum.
Actually, I like the idea of not allowing tracked websites, I mean, we have the opportunity here to try and stear toward our "ideal web", let's not make any concessions. Tracked websites cannot be part of the webring. Do you use Firefox Lightbeam for that?

I use a combination of uBlock Origin and Privacy Badger to block and see what third party calls are being made (Chromium is my main browser). I just did a sort of informal check, and there is actually more sites than I thought that are using tracking. For example in the first 30 sites of the webring there is at least 6 that have google analytics. So if we are going to enforce that type of rule, we'll have to figure out how we approach that. Do we just enforce it moving forward?


📑 dictionary lookups can return none

Fixes #68.
this branch makes some follow-up changes to #61, modifying the hostcall so that we return a None status code when a dictionary entry does not exist.

  = note: LINK : fatal error LNK1285: corrupt PDB file 'D:\a\Viceroy\Viceroy\target\debug\deps\http_semantics-39397fc60f086e09.pdb'; delete and rebuild

i'm guessing latent CI failure, we shall see :recycle:


add confirmation box on exit button click

Added a dialog box to confirm data deletion on exit button click.

Fixes #130


portFFT integration

Description
Introduces the portFFT backend, a pure SYCL implemenation.
Checklist
All Submissions

[ ] Do all unit tests pass locally? Attach a log.
[ ] Have you formatted the code using clang-format?

merged upstream


[RF] Modify consensus loop to avoid downloading blocks that we already have in the block store

Consensus loop is designed to flush the coinview only when headers tip is equal to consensus tip:
// We really want to flush if we are at the top of the chain.
// Otherwise, we just allow the flush to happen if it is needed.
bool forceFlush = this.Chain.Tip.HashBlock == blockValidationContext.ChainedBlock?.HashBlock;
await this.FlushAsync(forceFlush).ConfigureAwait(false);

And in the CachedCoinView we have
public const int CacheFlushTimeIntervalSeconds = 60;

So the cache is flushed every 60 seconds OR when we are at the tip.
When the cache is flushed a new instance of RewindData is created and persisted.
RewindData is used for rewinding the consensus in case of a reorg.
When we rewind consensus we may actually rewind several blocks in a single RewindCoinViewLockedAsync() call.
Now here is the problematic scenario:
Let's say that consensus tip is behind headers tip by some blocks and we are advancing. A 1 block reorg happens at the very tip of the chain. Our consensus recognizes it and rewinds itself. After a rewind we may be 3000 blocks behind (actually depends on the syncing speed. Basically we can be as many blocks behind as we are able to download in 60 seconds).
Now instead of getting 2999 blocks from the block store and downloading 1 new block we will download all of those blocks using the lookahead block puller and signal them again to all the components.
There are 2 fixes to this that I can think of:

after a reorg check first if we have those blocks in the store and if we do- get them from it instead of the puller
create 1 rewind data for every block (but that will require more space on the hard drive and we will need to refactor the coinview)

I think elegant way to fix this would be to flush not only at the tip, but when ever we are close to the tip. So I would check if Max reorg rule is in place on the current network. If it is then flush if distance to the tip is less then Max reorg. If it is not, then flush if the currently process the block time is not more than 2 weeks from the tips time

This solution would allow us to keep the performance during IBD and only slowdown the sync at the end of the chain

When we rewind consensus we may actually rewind several blocks in a single RewindCoinViewLockedAsync() call.

What? I did not know this is the behaviour of coinview rewind.
I think apro solution is not bad, during IBD rewinds are not expected so rewinding intervals of two weeks (or even based on the size of the pending rewind, store a rewind point every 10mb or so), close to the tip we can store more frequently.
But perhaps the best solution is to keep a rewind point on every block.

after a reorg check first if we have those blocks in the store and if we do- get them from it instead of the puller

This is problematic for pruned nodes but doable.

we want that max reorgs blocks anyway for headersEx, so that is why i think it is reasonable to go with that and for bitcoin ... well two weeks should be just fine even for pruned node

But perhaps the best solution is to keep a rewind point on every block.

That may result in having larger rewind data set (rewind data instance for 10 blocks is smaller than 10 rewind data instances for every block). Though the difference shouldn't be that crucial.
Also we shouldn't do it this way until we fix #5 and refactor the coinview because this fix will slow down advancing a lot.

This issue should be tested (a new integration test should be created):

Fixed with activation merge.


Grid ufunc refactor

Next step towards #344:

Defines various grid ufuncs in the file gridops.py
Moves the GCMDataset class that was in that file to a new file gcmdataset.py (do we even still need that code? @jbusecke said that was some of your old code @rabernat ?)
Starts work on a new Grid._grid_ufunc_dispatch method that aims to eventually replace the existing Grid._grid_func method and everything that calls below (including Grid._neighbour_binary_func etc.).
Sketches out a mechanism to search through all the grid ufuncs defined in gridops.py (but the searching doesn't actually work yet, still a WIP) this now works, next step is to add support for a boundary kwarg so that some of the tests actually pass.

Builds on top of #362, so actually there are far fewer changes than this looks like (I don't know why this still lists test_grid_ufunc.py as a new change...)

[x] Continues work towards #344
[ ] Tests added
[ ] Passes pre-commit run --all-files
[ ] User visible changes (including notable bug fixes) are documented in whats-new.rst
[ ] New functions/methods are listed in api.rst

do we even still need that code?

No. It's very old and unused.

No. It's very old and unused.

Okay I'll just delete the whole class then.

So I'm adding the boundary kwargs, and I would have liked to have a gridops.py module that looked like this:
@as_grid_ufunc(signature="(X:center)->(X:left)", boundary="fill")
def diff_center_to_left(a):
    return a - np.roll(a, -1)

@as_grid_ufunc(signature="(X:center)->(X:left)", boundary="extend")
def diff_center_to_left(a):
    return a - np.roll(a, -1)

where you have identically-named functions distinguished only by their keyword arguments to the decorator.
However I don't think this is possible, as despite the members of this module being different instances of the GridUFunc class, python refers to both these functions via their name (diff_center_to_left), and so the second one ends up overwriting the first, and I have to give each function different names even if they are distinguished by their decorator arguments, i.e.
@as_grid_ufunc(signature="(X:center)->(X:left)", boundary="fill")
def diff_center_to_left_fill(a):
    return a - np.roll(a, -1)

@as_grid_ufunc(signature="(X:center)->(X:left)", boundary="extend")
def diff_center_to_left_extend(a):
    return a - np.roll(a, -1)

so the second one ends up overwriting the first, and I have to give each function different names even if they are distinguished by their decorator arguments

This might be suggesting our abstraction is wrong.
First let's talk carefully about what we mean by boundary conditions. I distinguish between two different types of boundary:

The global array boundary: obviously our array has a finite size (Ny, Nx). We need to decide what to do at the boundaries of that array. This is what xgcm's current "boundary" kwarg is about. Those boundaries may or may not have any physical meaning. For example, on a lat lon grid, the X-axis array boundary has zero physical meaning--it just happens to be where we sliced the sphere. This is ultimately a topological issue. Our implementation of face connections has some very fancy treatment for the global array boundaries, e.g. for cubed-sphere grids.
The physical boundary: ocean models (and probably other FV models) have actual boundaries, where there is no fluid, i.e. land. We often want to do something distinct on these boundaries, like apply a no-flux boundary condition. These may or may not correspond with the global array boundary. This is discussed in #324. Also closely related to #293. Currently not supported in xgcm.

It's very useful to think about what real GCMs do. GCMs parallelize the grids over many MPI processes, each operating on a "tile." Each title only knows about its local data, so the concept of global array boundaries is not relevant. (Example)
Instead, each tile has an "overlap" or "halo" region that is duplicated with its neighbors, plus a land mask.

I would like to suggest that as_grid_ufunc should be unaware of global array boundaries but possibly aware of physical boundaries. Global array boundaries can be handled separately. For example, when we call Grid.diff, we might imagine taking the following steps.

Build halo region around the array
Apply diff_center_to_left array_ufunc
Remove halo region

So there are a two issues here - we're not quite talking about the same thing:

How should grid ufuncs with the same signature be distinguished? This is what my comment was about, rather than specifically about the boundary kwarg, because we will have this naming issue whether or not it's metric or fill_value or boundary that distinguishes the grid ufuncs. (It is possible though that the correct abstraction doesn't have any kwargs other than signature in the @as_grid_ufunc decorator, and everything else is either always attached to grid or handled before/after the ufunc...)

Which keyword arguments do grid ufuncs need to be aware of? This is what your comment discusses @rabernat . My understanding is that you're basically saying that we might need something like @as_grid_ufunc(signature, physical_boundary={'X': 'dirichlet'}), but we shouldn't need @as_grid_ufunc(signature, boundary='fill'), because that should instead be handled by code that wraps the application of the grid ufunc? In that model is the current boundary kwarg any different to the boundary kwarg that dask.array.map_blocks accepts?

I've actually realised that I have a more immediate design problem to solve first though: how do I check that two signatures are functionally equivalent? i.e. "(X:center)->(X:right)" and "(Y:center)->(Y:right)" are equivalent, in the same way that for normal ufuncs (i)->(i) and (j)->(j) are equivalent.

For example, when we call Grid.diff, we might imagine taking the following steps.

Build halo region around the array
Apply diff_center_to_left array_ufunc
Remove halo region

Isn't this literally what dask.array.map_overlap does? If so then can we just use that?
If we do then the boundary question mostly becomes whether the call to map_overlap should be part of the grid ufunc or not. There are a few options I can see:

Call dask.array.map_overlap inside each grid ufunc. This is currently supported, and there is actually a test for this case in #362. The main disadvantage is potentially duplicated code within many (if not all) of the pre-defined ufuncs in gridops.py. It would also mean that boundary needs to be an argument to each grid ufunc, which I think conflicts with your recommendation above @rabernat .

Automatically wrap each grid ufunc with dask.array.map_overlap. If we know all pre-defined grid ufuncs should have the same behaviour and options with respect to internal boundaries, then we can take the supplied numpy ufunc, wrap it in dask.array.map_overlap, and then feed the resulting function into xarray.apply_ufunc. We could do this within the apply_as_grid_ufunc call, so it would happen within the as_grid_ufunc decorator, and not be mentioned at all in the grid ufunc definition. The disadvantage is that this approach relies on the assumption that the underlying numpy implementation of the grid ufunc is independent of the choice of boundary={'fill', 'extend', 'extrapolate'}. It might also complicate the implementation of different physical boundaries.

If xarray implements map_overlap then that might end up being a better way? See https://github.com/pydata/xarray/issues/3147. I don't think this is the correct solution for us though.

One problem with this idea of using dask.array.map_overlap though is that while xgcm's 'fill' is essentially dask's constant value option, and xgcm's extend is essentially dask's 'nearest' options, it doesn't look like dask.array.map_overlap has any equivalent of xgcm's 'extrapolate' option.

Isn't this literally what dask.array.map_overlap does? If so then can we just use that?

Not quite.

map_overlap as is is not sufficiently flexible to handle the really global array boundary conditions. It supports the following boundary conditions:

‘reflect’, ‘periodic’, ‘nearest’, ‘none’, or any constant value like 0 or np.nan.

It can't deal with cubed sphere, tripolar grid, etc. So we may have to vendor this function and augment it with special options.

Xgcm should work without Dask! It has always supported an eager evaluation mode.

However, we can overlook these in the short term if we want to just move forward with an implementation.

how do I check that two signatures are functionally equivalent? i.e. "(X:center)->(X:right)" and "(Y:center)->(Y:right)" are equivalent, in the same way that for normal ufuncs (i)->(i) and (j)->(j) are equivalent.

It seems like a regex could handle this, no?

It can't deal with cubed sphere, tripolar grid, etc.

Hmm okay.

we may have to vendor this function and augment it with special options.

I haven't heard the word "vendor" used in this context before - what exactly do you mean? Make our own version of map_overlap?
I think if we had our own function to perform a similar job (e.g. map_over_faces or something) then we would still have to choose between my (1) and (2) above.

However, we can overlook these in the short term if we want to just move forward with an implementation.

This might be a good idea - use dask.array.map_overlap to get the basic test cases with just 'fill' and 'extend' working, and then re-evaluate.

It seems like a regex could handle this, no?

Probably, but so far my solution has been to call _parse_grid_ufunc_signature (so re-using my previous regex in a way) and then replace dummy variables. There is probably a neater regex way though.
https://github.com/xgcm/xgcm/pull/368/files#diff-3af42ae01706abd10c8c0a6185e2598b72bacfe3ef33eb162ae8da1a9d61a257R307-R335

I think you want to build Grid.pad first so then making the halo is a call to Grid.pad (accounts for tripole, cubed-sphere, periodic etc.); then pass to map_overlap(..., boundary=None) so map_overlap only takes care of communicating between blocks; then remove the halo region.

I like the suggestion by @dcherian above. This would take care of the 'data_boundaries' (which are not physical) and then 'internal_boundaries' e.g. actual land in the data should be handled internally (at the numpy level) in the ufunc. The latter would be a new feature (to be implemented after this refactor?) and we could discuss if we want to implement that with an additional keyword or with another subset of ufuncs.

I think you want to build Grid.pad first so then making the halo is a call to Grid.pad (accounts for tripole, cubed-sphere, periodic etc.); then pass to map_overlap(..., boundary=None) so map_overlap only takes care of communicating between blocks; then remove the halo region.

Thanks @dcherian , that was a really helpful suggestion.
So in the latest commit I added a prototype of a grid.pad method, which is called within apply_as_grid_ufunc, and pads the given dataarrays by a number of elements specified by a new boundary_width argument to the @as_grid_ufunc decorator. (Thanks to @jbusecke for a very helpful pair programming session on that on Friday.)
We also identified the simplest existing failing test case that needs to pass in order to prove that this approach works: xgcm/test/test_grid.py::test_grid_ops[nonperiodic_1d_left] - I was trying to debug via some other tests before.
The padding seems work for basic cases (though I still need to write tests that will isolate that method), but the test above still doesn't pass, instead failing with an error I told it to raise when the ufunc output hasn't been trimmed:
ValueError: conflicting sizes for dimension 'XG': length 101 on <this-array> and length 100 on {'XG': 'XG'} - does your grid ufunc correctly trim off the same number of elements which were added by padding using boundary_width={'X': (1, 0)}?

I think the problem is that @jbusecke the boundary_width kwarg we added to diff_center_to_left in gridops.py isn't correct: when diff is called with boundary='fill' by the test, this ends up padding, then applying the ufunc, but the ufunc does not automatically trim the new elements back off the data, so the result is the incorrect length.
@as_grid_ufunc(signature="(X:center)->(X:left)", boundary_width={"X": (1, 0)})
def diff_center_to_left(a):
    return a - np.roll(a, -1)

If this particular ufunc isn't supposed to have any elements padded when applying boundary conditions, then I need another example ufunc which does. In general it would be helpful if I were actually sure what the ufuncs in gridops.py for the various diff_* variations were actually supposed to be!

but the ufunc does not automatically trim the new elements back off the data, so the result is the incorrect length.

So the implementation needs to change
@as_grid_ufunc(signature="(X:center)->(X:left)", boundary_width={"X": (1, 0)})
def diff_center_to_left(a):
    return a[..., 1:] - a[..., :-1]

Thanks @rabernat - I expect that will work.

So the implementation needs to change

There is possibly another option, where I add a trim_after argument to@as_grid_ufunc, that defaults to false. That would allow people to define ufuncs which don't trim the padded elements, and trim for them instead.

There is possibly another option, where I add a trim_after argument to@as_grid_ufunc, that defaults to false. That would allow people to define ufuncs which don't trim the padded elements, and trim for them instead.

I am actually not against that. It would enable both types of workflow and might make these 'basic' ufuncs cleaner to read?

a[..., 1:] - a[..., :-1]

I think this is actually better from a memory perspective two, since we create two slices instead of one extra copy with np.roll
:+1: for a trim_after argument, though the analogous argument in map_overlap is just trim

My general point is that, if padding is handled separately, our grid ufuncs should never roll arrays or do anything else that requires global array boundary communication. They should always assume they are operating on a "local tile" of data.
I agree that trim may be needed, depending on the particular implementation. Perhaps this can be optional, for the grid ufunc writer to choose?

My general point is that, if padding is handled separately, our grid ufuncs should never roll arrays or do anything else that requires global array boundary communication.

I think that now all our basic ufuncs are just going to look like slices, e.g. a[..., 1:] - a[..., :-1]. The global array communication, if needed, is being handled (in a dask-aware way) by DataArray.pad now.

Perhaps this can be optional, for the grid ufunc writer to choose?

Yes I meant as an additional option for someone writing a custom ufunc.

For some reason now the trimming works in 1D but has an off-by-one error in 2D :confused:
xgcm/test/test_grid.py::test_grid_ops[nonperiodic_1d_outer] PASSED                                                                                [ 10%]
xgcm/test/test_grid.py::test_grid_ops[nonperiodic_1d_inner] PASSED                                                                                [ 20%]
xgcm/test/test_grid.py::test_grid_ops[periodic_1d_left] PASSED                                                                                [ 30%]
xgcm/test/test_grid.py::test_grid_ops[nonperiodic_1d_left] PASSED                                                                                [ 40%]
xgcm/test/test_grid.py::test_grid_ops[periodic_1d_right] PASSED                                                                                [ 50%]
xgcm/test/test_grid.py::test_grid_ops[nonperiodic_1d_right] PASSED                                                                                [ 60%]
xgcm/test/test_grid.py::test_grid_ops[periodic_2d_left] FAILED                                                                                [ 70%]
xgcm/test/test_grid.py::test_grid_ops[nonperiodic_2d_left] FAILED                                                                                [ 80%]
xgcm/test/test_grid.py::test_grid_ops[xperiodic_2d_left] FAILED                                                                                [ 90%]
xgcm/test/test_grid.py::test_grid_ops[yperiodic_2d_left] FAILED                                                                                [100%]

FAILED xgcm/test/test_grid.py::test_grid_ops[periodic_2d_left] - ValueError: conflicting sizes for dimension 'YG': length 199 on <this-array> and length 200 on {'XC': 'XC', 'YG': 'YG'} - ...
FAILED xgcm/test/test_grid.py::test_grid_ops[nonperiodic_2d_left] - ValueError: conflicting sizes for dimension 'YG': length 199 on <this-array> and length 200 on {'XC': 'XC', 'YG': 'YG'}...
FAILED xgcm/test/test_grid.py::test_grid_ops[xperiodic_2d_left] - ValueError: conflicting sizes for dimension 'YG': length 199 on <this-array> and length 200 on {'XC': 'XC', 'YG': 'YG'} -...
FAILED xgcm/test/test_grid.py::test_grid_ops[yperiodic_2d_left] - ValueError: conflicting sizes for dimension 'YG': length 199 on <this-array> and length 200 on {'XC': 'XC', 'YG': 'YG'} -...

For some reason now the trimming works in 1D but has an off-by-one error in 2D :confused:
xgcm/test/test_grid.py::test_grid_ops[nonperiodic_1d_outer] PASSED                                                                                [ 10%]
xgcm/test/test_grid.py::test_grid_ops[nonperiodic_1d_inner] PASSED                                                                                [ 20%]
xgcm/test/test_grid.py::test_grid_ops[periodic_1d_left] PASSED                                                                                [ 30%]
xgcm/test/test_grid.py::test_grid_ops[nonperiodic_1d_left] PASSED                                                                                [ 40%]
xgcm/test/test_grid.py::test_grid_ops[periodic_1d_right] PASSED                                                                                [ 50%]
xgcm/test/test_grid.py::test_grid_ops[nonperiodic_1d_right] PASSED                                                                                [ 60%]
xgcm/test/test_grid.py::test_grid_ops[periodic_2d_left] FAILED                                                                                [ 70%]
xgcm/test/test_grid.py::test_grid_ops[nonperiodic_2d_left] FAILED                                                                                [ 80%]
xgcm/test/test_grid.py::test_grid_ops[xperiodic_2d_left] FAILED                                                                                [ 90%]
xgcm/test/test_grid.py::test_grid_ops[yperiodic_2d_left] FAILED                                                                                [100%]

FAILED xgcm/test/test_grid.py::test_grid_ops[periodic_2d_left] - ValueError: conflicting sizes for dimension 'YG': length 199 on <this-array> and length 200 on {'XC': 'XC', 'YG': 'YG'} - ...
FAILED xgcm/test/test_grid.py::test_grid_ops[nonperiodic_2d_left] - ValueError: conflicting sizes for dimension 'YG': length 199 on <this-array> and length 200 on {'XC': 'XC', 'YG': 'YG'}...
FAILED xgcm/test/test_grid.py::test_grid_ops[xperiodic_2d_left] - ValueError: conflicting sizes for dimension 'YG': length 199 on <this-array> and length 200 on {'XC': 'XC', 'YG': 'YG'} -...
FAILED xgcm/test/test_grid.py::test_grid_ops[yperiodic_2d_left] - ValueError: conflicting sizes for dimension 'YG': length 199 on <this-array> and length 200 on {'XC': 'XC', 'YG': 'YG'} -...

For some reason now the trimming works in 1D but has an off-by-one error in 2D :confused:
xgcm/test/test_grid.py::test_grid_ops[nonperiodic_1d_outer] PASSED                                                                                [ 10%]
xgcm/test/test_grid.py::test_grid_ops[nonperiodic_1d_inner] PASSED                                                                                [ 20%]
xgcm/test/test_grid.py::test_grid_ops[periodic_1d_left] PASSED                                                                                [ 30%]
xgcm/test/test_grid.py::test_grid_ops[nonperiodic_1d_left] PASSED                                                                                [ 40%]
xgcm/test/test_grid.py::test_grid_ops[periodic_1d_right] PASSED                                                                                [ 50%]
xgcm/test/test_grid.py::test_grid_ops[nonperiodic_1d_right] PASSED                                                                                [ 60%]
xgcm/test/test_grid.py::test_grid_ops[periodic_2d_left] FAILED                                                                                [ 70%]
xgcm/test/test_grid.py::test_grid_ops[nonperiodic_2d_left] FAILED                                                                                [ 80%]
xgcm/test/test_grid.py::test_grid_ops[xperiodic_2d_left] FAILED                                                                                [ 90%]
xgcm/test/test_grid.py::test_grid_ops[yperiodic_2d_left] FAILED                                                                                [100%]

FAILED xgcm/test/test_grid.py::test_grid_ops[periodic_2d_left] - ValueError: conflicting sizes for dimension 'YG': length 199 on <this-array> and length 200 on {'XC': 'XC', 'YG': 'YG'} - ...
FAILED xgcm/test/test_grid.py::test_grid_ops[nonperiodic_2d_left] - ValueError: conflicting sizes for dimension 'YG': length 199 on <this-array> and length 200 on {'XC': 'XC', 'YG': 'YG'}...
FAILED xgcm/test/test_grid.py::test_grid_ops[xperiodic_2d_left] - ValueError: conflicting sizes for dimension 'YG': length 199 on <this-array> and length 200 on {'XC': 'XC', 'YG': 'YG'} -...
FAILED xgcm/test/test_grid.py::test_grid_ops[yperiodic_2d_left] - ValueError: conflicting sizes for dimension 'YG': length 199 on <this-array> and length 200 on {'XC': 'XC', 'YG': 'YG'} -...

This now passes for 2d data too (despite not knowing what is wrong with https://github.com/xgcm/xgcm/pull/371#issuecomment-926220770)...
xgcm/test/test_grid.py::test_grid_ops[nonperiodic_1d_outer] PASSED
xgcm/test/test_grid.py::test_grid_ops[nonperiodic_1d_inner] PASSED
xgcm/test/test_grid.py::test_grid_ops[periodic_1d_left] PASSED
xgcm/test/test_grid.py::test_grid_ops[nonperiodic_1d_left] PASSED
xgcm/test/test_grid.py::test_grid_ops[periodic_1d_right] PASSED
xgcm/test/test_grid.py::test_grid_ops[nonperiodic_1d_right] PASSED
xgcm/test/test_grid.py::test_grid_ops[periodic_2d_left] PASSED
xgcm/test/test_grid.py::test_grid_ops[nonperiodic_2d_left] PASSED
xgcm/test/test_grid.py::test_grid_ops[xperiodic_2d_left] PASSED
xgcm/test/test_grid.py::test_grid_ops[yperiodic_2d_left] PASSED

but only up to a transposition. Specifically, I had to add
if axis_name == "Y":
    assert da_diff.T.equals(da_diff_ax)
else:
    assert da_diff.equals(da_diff_ax)

to the test to get all the [*periodic_2d_left] tests to pass. This is because xarray.apply_ufunc always transposes so that the axes being acted over are the last axes in the data.
Now I'm not sure what to do here because I could:

Write some code that attempts to transpose the result back - unfortunately I think this is not a trivial problem, given that a grid ufunc can create and remove arbitrary axes. It might not always be clear which dim has been shifted to create which new dim...
Change the test - I've not changed any tests at all yet, and don't want to. But it is interesting that this would pass if xarray's assert functions didn't care about dimension order, as you suggested in https://github.com/pydata/xarray/issues/5733 @jbusecke .
Leave it for now - this particular test only compares grid.diff to axis.diff, and the latter is still using the old code path. I expect that when everything has been refactored internally then this particular tests will pass (though any other tests elsewhere that apply over multidimensional data will presumably fail with the same problem).

I tested this with dask in this notebook, but found that confusingly applying these two functions behave differently with respect to dask:
def diff_center_to_left(a):
    return a[..., 1:] - a[..., :-1]

def manual_diff(array):
    return array - np.roll(array, 1, axis=-1)

The former complains about chunking along a core dim
ValueError: dimension x_c on 0th function argument to apply_ufunc with dask='parallelized' consists of multiple chunks, but is also a core dimension. To fix, either rechunk into a single dask array chunk along this dimension, i.e., ``.chunk(dict(x_c=-1))``, or pass ``allow_rechunk=True`` in ``dask_gufunc_kwargs`` but beware that this may significantly increase memory usage.

whilst the latter doesn't. I don't really understand why that is. Currently this PR uses the former definition in the gridops.py file, which is why you see the same behaviour when calliing grid.diff in the notebook.
Using bare apply_ufunc behaves the same way as apply_as_grid_ufunc so I don't think it's my code causing any difference in behaviour.
Additionally I tried the former function but with dask='allowed' instead of 'parallelized' - that runs but gives a surprisingly complex task graph :confused:
So it appears that a grid ufunc defined with np.roll is most dask-streamlined, but I thought we were expecting the opposite?
Note: This is all before I attempt to call map_overlap anywhere - currently all that happens is a dask.pad (if boundary_width is nonzero) and then an xarray.apply_ufunc.

this would be a good time for a review / input before I try to move any further forward I think

I just put this on my calendar in my next free spot, in the morning of Oct. 4.

Is the graph just as complex if you called the second one with dask="allowed"?  It should  be...
The graph for dask="parallelized" is neat because it's just applying it blockwise; but that  can only work if there's a single chunk along that axis.
You're getting a chunk error for the second one because pad inserts an extra chunk IIRC with the padded  values.
Anecdotally, I know dask slicing can get weirdly complex, but don't really understand why. Isn't that why we're doing this refactor in the first place?
I think should try dask="allowed" with map_overlap and the first function to get a real sense of the before/after improvement (if any).

Is the graph just as complex if you called the second one with dask="allowed"? It should be...

You actually get a 3rd different graph, of moderate complexity :confused: I've updated the gist with it.

Anecdotally, I know dask slicing can get weirdly complex, but don't really understand why. Isn't that why we're doing this refactor in the first place?

I think should try dask="allowed" with map_overlap and the first function to get a real sense of the before/after improvement (if any).

I can do that - I can define the grid ufunc to call map_overlap within it, like this:
from dask.array import map_overlap

def diff_center_to_left(a):
    return a[..., 1:] - a[..., :-1]

def diff_overlap(a):
    return map_overlap(
        diff_center_to_left,
        a,
        depth={'X': (1, 0)},
        boundary=None,
        trim=True,
        meta=np.array(())
    )

bar_manual_diff = grid_test.apply_as_grid_ufunc(
    diff_overlap,
    ds_test.bar,
    axis='X',
    signature="(X:center)->(X:left)",
    boundary_width={"X": (0, 0)},
    boundary="fill",
    dask="allowed",
)
bar_manual_diff

which gives a nice streamlined graph. (I am a bit confused by why I needed to put trim=True and boundary_width={'X': (0,0)} to make this compute an array of the correct length - I thought I would need to put trim=True and boundary_width={'X': (1,0)}...)
Still, I think the before / after graph comparison (so using this map_overlap code above) looks like this
(before)

(after)

Merging this for now. We can keep iterating on the dask optimizations in future PRs.


accessibility tasks to work through

https://docs.google.com/document/d/1S5O4ph0tDveHKFSXjL2KypYKb1gIUEmecadoBFY1X3k/edit

Duplicate of #330


Issue with k8s.io/docs/concepts/configuration/secret/#security-properties

This is a Bug Report

Problem:
The documentation under the Protections heading states "A secret is only sent to a node if a pod on that node requires it." However, the documentation under the Risks heading states "It is a planned feature to only send secrets to nodes that actually require them, to restrict the impact of a root exploit on a single node." This is confusing as these statements appear to conflict, making it unclear which one is accurate for the current version of Kubernetes.
Proposed Solution:
Update this documentation to reflect the currently implemented method of sending secrets to nodes. If Kubernetes does indeed only send secrets to nodes that actually require them, a proposed solution would be removing the sentence "It is a planned feature to only send secrets to nodes that actually require them, to restrict the impact of a root exploit on a single node." from the Risks section. If Kubernetes sends secrets to all nodes, but if it is a planned feature to only send secrets to a node if a pod on that node requires it, a proposed solution would include editing the Protections sentence to "Secrets are currently sent to all nodes, but it is a planned feature to only send secrets to a node if a pod on that node requires it."
Page to Update:
https://kubernetes.io/docs/concepts/configuration/secret/

i am working on this... since i am new here, looks like a good start

@Shappenny Would you like to open a PR for this?

/priority backlog
/language en

/reopen
We had some confusion over this exact part of the documentation come up in an audit recently.
It appears that Node Authorization takes care of this issue and makes the below sentence true:

A secret is only sent to a node if a pod on that node requires it.

This appears to be enabled by default for EKS - I tested that the following curl gives a 403 for secret not associated with a pod bound to the node, but gives 200 for a secret that is used by a pod on that same node:
curl -H "Authorization: Bearer ${TOKEN}" "${API_SERVER}/api/v1/namespaces/${NAMESPACE_NAME}/secrets/${SECRET_NAME}"

I'd be happy to do a docs PR for this if one of the k8s security folks could confirm+review.
I apologize if reopening a very old issue like this is a breach of etiquette - if I should file a new issue or take some other action please let me know.

/reopen
We had some confusion over this exact part of the documentation come up in an audit recently.
It appears that Node Authorization takes care of this issue and makes the below sentence true:

A secret is only sent to a node if a pod on that node requires it.

This appears to be enabled by default for EKS - I tested that the following curl gives a 403 for secret not associated with a pod bound to the node, but gives 200 for a secret that is used by a pod on that same node:
curl -H "Authorization: Bearer ${TOKEN}" "${API_SERVER}/api/v1/namespaces/${NAMESPACE_NAME}/secrets/${SECRET_NAME}"

I'd be happy to do a docs PR for this if one of the k8s security folks could confirm+review.
I apologize if reopening a very old issue like this is a breach of etiquette - if I should file a new issue or take some other action please let me know.


Discuss: add one end-to-end test to the bond (or swap) package

Since we moved to unit tests only for bonds/swaps, I am a bit concerned that this PR is not completely covered by tests:
https://github.com/digital-asset/daml-finance/pull/394
Even though nothing changed in the test results, maybe the resulting Effect could have issues during settlement?

This also relates to https://github.com/digital-asset/daml-finance/issues/215

Closing this, after team discussion we are fine with testing only up to the Effect step in the Bond/Swap package, since lifecycling/settlement are tested elsewhere.


Fix typos in algo_walkthrough.rst

Fix typos.

Good catch, thanks for fixing this!
you will have to sign off the commit, best with:
git commit --signoff --amend
Also can you rebase this to the master branch, please?
and then force push one more time!

Good catch, thanks for fixing this!
you will have to sign off the commit, best with:
git commit --signoff --amend
Also can you rebase this to the master branch, please?
and then force push one more time!

I'm not sure whether I did it correctly, since this is my first time. 😃

Good catch, thanks for fixing this!
you will have to sign off the commit, best with:
git commit --signoff --amend
Also can you rebase this to the master branch, please?
and then force push one more time!

I'm not sure whether I did it correctly, since this is my first time. smiley

well you did not quite do what I expected but it still worked out :)
With rebase I meant to do:
git rebase origin/master

and then
git push --force

Thanks for fixing this!

@johuber If you click on the "details" link of the DCO check, it shows you a page with exact instructions how to sign all the commits. I usually just tell the commiter to have a look there, it's easier.


Support HTML aria attribute completion

http://www.w3.org/TR/wai-aria/

I notice there's a TODO in htmlTags.ts for this.


Monitoring - some units fail on a standby server

OmniDb  2.12.0, Windows
At least the "Standby: Replication Lag (Size)" and "CPU Usage" units fail to render, giving the error message:
cannot execute CREATE TABLE in a read-only transaction

Hi @stevenwinfield ,
Today we released 2.16.0. These monitoring units, when executed against a standby server, will give you an appropriate message.
Keeping this open for a few more days, any feedback would be much appreciated.
Regards,
William

I'm still seeing the "cannot execute CREATE TABLE message"


HELP WANTED - How to stop downloading or uploading

I tried in every way, but I still could not understand how to stop the download or upload of one or more files. Can you help me?
Why if I press stopAction the func fileProvider( doesn't respond?
Where am I wrong?
If I press stopAction, I would like the download or upload of all files to be stopped.
I have this code.
class ViewController: UIViewController {
    let server: URL = URL(string: "https://webdav.pcloud.com")!
    let username = "xxxx@yyyyy"
    let password = "aaaaaa"
    let imagesRemotePath = ["test/Firenze.jpg","test/Melbourne.jpg","test/Milano.jpg","test/Singapore.jpg"]
    let imagesLocalPath = ["Firenze.jpg","Melbourne.jpg","Milano.jpg","Singapore.jpg"]

    var webdav: WebDAVFileProvider?
    var progress: Progress?

    @IBOutlet weak var numberOfFiles: UITextField!

    @IBOutlet weak var uploadProgressView: UIProgressView!
    @IBOutlet weak var uploadLabel: UILabel!

    @IBOutlet weak var downloadProgressView: UIProgressView!
    @IBOutlet weak var downloadLabel: UILabel!

    override func viewDidLoad() {
        super.viewDidLoad()
        let credential = URLCredential(user: username, password: password, persistence: .permanent)
        webdav = WebDAVFileProvider(baseURL: server, credential: credential)!
        webdav?.delegate = self as FileProviderDelegate
    }

    override func didReceiveMemoryWarning() {
        super.didReceiveMemoryWarning()
    }

    @IBAction func stopAction(_ sender: UIButton) {
        progress?.cancel()
    }

    @IBAction func download(_ sender: Any) {
        guard let numberOfFiles = Int(self.numberOfFiles.text!) else {
            return
        }
        let group = DispatchGroup()
        for i in 0..<numberOfFiles {
            let localURL = FileManager.default.urls(for: .documentDirectory, in: .userDomainMask).first!.appendingPathComponent(imagesLocalPath[i])
            let remotePath = imagesRemotePath[i]
            group.enter()
            progress = webdav?.copyItem(path: remotePath, toLocalURL: localURL, completionHandler: { (error) in
                if let error = error as? FileProviderHTTPError {
                    print("Error: \(error.code)")
                    return
                }
                group.leave()
            })
        }
        group.notify(queue: .main) {
            print("Hai effettuato il download di \(numberOfFiles) photo.")
        }
    }

    @IBAction func upload(_ sender: Any) {
        guard let numberOfFiles = Int(self.numberOfFiles.text!) else {
            return
        }
        let group = DispatchGroup()
        for i in 0..<numberOfFiles {
            let localURL = FileManager.default.urls(for: .documentDirectory, in: .userDomainMask).first!.appendingPathComponent(imagesLocalPath[i])
            let remotePath = imagesRemotePath[i]
            group.enter()
            progress = webdav?.copyItem(localFile: localURL, to: remotePath, completionHandler: { (error) in
                if let error = error as? FileProviderHTTPError {
                    print("Error: \(error.code)")
                    return
                }
                group.leave()
            })
        }
        group.notify(queue: .main) {
            print("Hai effettuato l'upload di \(numberOfFiles) photo.")
        }
    }
}

and delegate file:
import UIKit

 //MARK: Files Operation Delegate
extension ViewController: FileOperationDelegate {

    func fileProvider(_ fileProvider: FileProviderOperations, shouldDoOperation operation: FileOperationType) -> Bool {
        print("func shouldDoOperation \(operation)")
        return true
    }

    func fileProvider(_ fileProvider: FileProviderOperations, shouldProceedAfterError error: Error, operation: FileOperationType) -> Bool {
        print("func shouldProceedAfterError \(operation) and error: \(error)")
        return true
    }
}

    //MARK: FilesProvider Delegate
extension ViewController:FileProviderDelegate {
    func fileproviderSucceed(_ fileProvider: FileProviderOperations, operation: FileOperationType) {
        switch operation {
        case .copy(source: let source, destination: let dest):
            print("\(source) copied to \(dest) success.")
        case .remove(path: let path):
            print("\(path) has been deleted.")
        default:
            if let destination = operation.destination {
                print("\(operation.actionDescription) from \(operation.source) to \(destination) succeed.")
            } else {
                print("\(operation.actionDescription) on \(operation.source) succeed.")
            }
        }
    }

    func fileproviderFailed(_ fileProvider: FileProviderOperations, operation: FileOperationType, error: Error) {
        switch operation {
        case .copy(source: let source, destination: let dest):
            print("copying \(source) to \(dest) has been failed.")
        case .remove(path: let path):
            print("File: \(path) can't be deleted.")
        default:
            if let destination = operation.destination {
                print("\(operation.actionDescription) from \(operation.source) to \(destination) failed.")
            } else {
                print("\(operation.actionDescription) on \(operation.source) failed.")
            }
        }
    }

    func fileproviderProgress(_ fileProvider: FileProviderOperations, operation: FileOperationType, progress: Float) {
        switch operation {
        case .copy(source: let source, destination: let dest) where dest.hasPrefix("file://"):
            downloadProgressView.progress = progress
            downloadLabel.text = "Downloading \((source as NSString).lastPathComponent): \(progress * 100) completed."
        case .copy(source: let source, destination: let dest) where source.hasPrefix("file://"):
            uploadProgressView.progress = progress
            uploadLabel.text = "Uploading \((source as NSString).lastPathComponent) to \((dest as NSString).lastPathComponent): \(progress * 100) completed."
        case .copy(source: let source, destination: let dest):
            print("Copy \(source) to \(dest): \(progress * 100) completed.")
        default:
            break
        }
    }
}

Your progress variable only holds progress object for last operation in for loop. Perhaps you should use an array to hold all progresses and cancel them?

What you say is right, but I do not understand why when I press stopAction Button, func fileprovider (_ from FileOperationDelegate does not activate (I do not see the print of the operation from print("func shouldDoOperation \(operation)") and when un error occurred I don't see the print from print("func shouldProceedAfterError \(operation) and error: \(error)").
Can you give me an example?
Thank you.

These functions are not what you think. 'shouldDoOperation()is called before begining of an operation, andshouldProceedAfterError()` is not implemented in http-based providers like webdav as they neither support batch operations nor folder's recursive copying is handled by client. Frankly these delegate methods are useless for http-based providers.
Furthermore stoping an operation is not an error!

Sorry, I did not notice your answer. Very clear. I will change the code according to your explanations. Thank you.


Fix turbo frame behaviour with various links

In accordance with #103, fix turbo frame integration

Looks great, thank you


Improve mypy type checking

This turns on most of the recommended mypy checks, and fixes a few things. There are two options that I've disabled in the config that I think would be more effor than they're worth to fix, because they involve interactions with stuff we're importing from outside packages that have incomplete typing.
Fixes https://github.com/matplotlib/napari-matplotlib/issues/81

I guess ideally we would fix them in the future, but they're not high priority now, which is why I put the TODOs there.


Support for wildcard ssl certificates

Hi @garutilorenzo,
first of all thank you very much for publishing this project. It's simple and effective and worked out of the box. Just like good solutions should be 💪
Is there a chance you could add support for wildcard ssl certificates?
I'm using the ssl-termination mode and would like to dynamically make multiple services in my cluster reachable through https using a single wildcard certificate covering *.my-domain
Ideally, it would be great if I could crate the secrets for cert and key only once and attach them to the ingress service only once initially and make the ingress service use those secrets for all domains (or maybe as a fallback if no secrets are found which exactly match the domain name? or maybe allow the services to specify which existing cert and key they would like to use among existing ones?)
My problem right now is that if I add a new service to my cluster (happens dynamically on a regular basis) and make it register a new domain, I have to create new secrets for it (using the same cert and key I'm already using for other services) and mount those new secrets to the ingress service (making its compose config longer), update the ingress service etc.
Does this make sense?

My problem is basically these two lines and the fact that crt and key are expected under a specific path bound to the host config of the specific service. It would be enough to make this somehow configurable
https://github.com/garutilorenzo/docker-swarm-ingress/blob/7543679d5f5a223bae53fab647eba40ebb8a9eaf/nginx-ingress/ingress/nginx.tpl#L161

Hi @knx-am,
yes I think we can add a specific label for this. If this label is not present we can fallback to the original value "{{ service['virtual_host'] }}"
I can open a PR with this new feature.

Hi @knx-am I have just opened this PR #4.
The PR is not tested, you can test this PR with this image:
garutilorenzo/docker-swarm-ingress:dev

Hi @garutilorenzo,
the dev version is unable to start because of a dependency issue with docker-py and the requests library.
Looks like the issue was fixed 3 days ago and we just missed the fix. Could you trigger a new build? Then I can test again. Thanks!
https://github.com/ansible-collections/community.docker/issues/611

Hi @knx-am,
just pushed a new container version with docker-py version 1.10.6.

Thank you but I think it should be 6.10.0 and not 1.10.6. The current dev version is still failing on startup with the same error

Here is the link to the release notes:
https://github.com/docker/docker-py/releases#:~:text=Support for requests 2.29.0%2B and urllib3 2.x

Hi @knx-am,
this project uses docker-py module, not docker.
The problem here is the requests and urllib modules compatibility, the old unsupported docker-py hasn't been updated.
I will open in the future a new PR to replace docker-py with docker python module.
I have pushed a new dev version on the registry with an old version of requests and urllib, please test it.

I see now that both docker-py and docker redirects to the same GitHub page...
There is some confusion about this python modules... but they are different.
I will open a new PR to fix the problem


feat: add tree-crasher implementation for solidity

Adds support for the Solidity programming language in tree-crasher
Adds script to generate seed corpus scripts/corpora/sol.sh

@0xalpharush I'd love to hear if you're able to find bugs with it! I'd also welcome another example for the usage docs!


[BUG] fps not capping higher than 60

Acknowledgement of preliminary instructions

[x] I have read the preliminary instructions, and I am certain that my problem has not already been addressed.

What problem did you encounter?
fps not changing, always caps at 60 no matter what i change it to. i click save and allat but nothing works. idk if this is a bug on my end or not

Are you setting it to 0?

Are you setting it to 0?

nah i set it to 240

Are you using a laptop? Are you using exclusive fullscreen? Are your other flag changes applying (e.g. escape menu version)?

Are you using a laptop? Are you using exclusive fullscreen? Are your other flag changes applying (e.g. escape menu version)?

no laptop. dont know what exclusive fullscreen is, so probably not. no other flag changes.

oh wait i fixed it, just had to mess around with the mod folder


WebIDL and Example Update - Vehicle Controllers - Wheeled, Motorcycle, Tank

Implements Examples of the 3 subtypes of Vehicle Controllers from main JoltPhysics.
Implements Wheeled Vehicle controller with optional 4-wheel-drive and optional roll-bar settings.
Tank and Car decorative additional geometry is not physics based.
The tank demo of actually wiring up hinges and fire/recoil/aiming was not implemented. This means the group-filter in that file can probably be removed.
The driving control and camera control is based on the same one used for Character Virtual (updated to use key instead of codes, easier to read), and controller Input instructions based off the C++ Repo Samples.
Motorcycle, Tank, and Car all update positioning and sizing of wheels based on WheelSettings and active steer, rotation-angle, and suspension (hard coded to the -1 y-axis in demo). Wheels are textured with an inlined data-uri checkerboard texture to allow visibility of rotations on the moving vehicle.
The 'track' data-storage is clunky since it was converted from a Trenchbroom-editor quake-MAP I had created and parsed into convex-hull brushes collections with one of my other JS repos. I had been tempted to just swap it for a height-map to simplify or actually make it into a larger track, but the collection of int arrays is a little ugly. I don't want to detract with excess complications.

Thanks a lot for implementing all of this! I'll release a new version tomorrow.


az webapp config set --generic-configurations failed

This is autogenerated. Please review and update as needed.
Describe the bug
When adding in --generic-configuraitons "{"clientAffinityEnabled": false}" to the webapp config set commands I receive an unexpected error.
Command Name
--generic-configurations "{"clientAffinityEnabled": false}"
Errors:
not enough values to unpack (expected 2, got 1)
Traceback (most recent call last):
azure/cli/core/util.py, ln 244, in shell_safe_json_parse
    return json.loads(json_or_dict_string)
lib/python3.6/json/__init__.py, ln 354, in loads
    return _default_decoder.decode(s)
lib/python3.6/json/decoder.py, ln 339, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
lib/python3.6/json/decoder.py, ln 355, in raw_decode
    obj, end = self.scan_once(s, idx)
json.decoder.JSONDecodeError: Expecting property name enclosed in double quotes: line 1 column 2 (char 1)

...

cli/command_modules/appservice/custom.py, ln 788, in update_site_configs
    config_name, value = s.split('=', 1)
ValueError: not enough values to unpack (expected 2, got 1)

To Reproduce:
add --generic-configurations into the webapp config set command

Put any pre-requisite steps here...
az webapp config set -g {} -n {} --generic-configurations {"clientAffinityEnabled": false} --slot {stagging} --ftps-state {Disabled} --php-version {5.6} --http20-enabled {true}

Expected Behavior
Update the ARR Affinity setting to false
Environment Summary
Linux-4.9.184-linuxkit-x86_64-with
Python 3.6.4
Shell: bash

azure-cli 2.0.71

Extensions:
interactive 0.4.3

Additional Context

@MyronFanQiu the documentation example is misleading on the usage here to use --generic-configurations, add the JSON object to a son file & run the command as az webapp config set -g {}-n {} --generic-configurations @test.json & see if that works.
@yugangw-msft looking at the code the usage of the command as given in the documentation incorrect az webapp config set -g MyResourceGroup -n MyUniqueApp --generic-configurations "{"alwaysOn": true}" I wanted to check with you if this was originally supported & got regressed, since you originally implemented it. Please comment. Thanks!

The command missing the wrapping quotes: "{\"clientAffinityEnabled\": false}"
We have a doc here with suggestions of how to handle quotes.
Right now, we need to fix the sample from -h which misses the quotes
 turn on "alwaysOn" through a json with content '{"alwaysOn", true}'
        az webapp config set -g MyResourceGroup -n MyUniqueApp --generic-configurations
        "{"alwaysOn": true}"

I've updated the command as indicated above 👆 but there is no change on the portal for webapp config for clientAffinityEnabled

then we will use this issue to track the doc issue on az webapp config set

clientAffinityEnabled is a site Object property so we use this command https://docs.microsoft.com/en-us/cli/azure/webapp?view=azure-cli-latest#az-webapp-update
--set is the equivalent of --generic-configurations so you can try using that as well.

@yugangw-msft The help changes got undone in the commit after yours: https://github.com/Azure/azure-cli/commit/573d0640d1b738bd1fb57d674f583da0ad5a608d#diff-40e30572983a53c248e7106702aabcc2L867 - so it's again not ok.
The suggested doc regarding handling quotes was helpful though!

As of June 2021, --generic-configurations doesn't seem to be working, what is the current status?
az webapp config set -g myGroup -n myAppName --generic-configurations '{ "managedPipelineMode": "Classic" }'
Errors :
`The command failed with an unexpected error. Here is the traceback:
not enough values to unpack (expected 2, got 1)
Traceback (most recent call last):
File "/opt/az/lib/python3.6/site-packages/azure/cli/core/util.py", line 506, in shell_safe_json_parse
return json.loads(json_or_dict_string, strict=strict)
File "/opt/az/lib/python3.6/json/init.py", line 367, in loads
return cls(**kw).decode(s)
File "/opt/az/lib/python3.6/json/decoder.py", line 339, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/opt/az/lib/python3.6/json/decoder.py", line 355, in raw_decode
obj, end = self.scan_once(s, idx)
json.decoder.JSONDecodeError: Expecting property name enclosed in double quotes: line 1 column 3 (char 2)
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/opt/az/lib/python3.6/site-packages/azure/cli/command_modules/appservice/custom.py", line 1169, in update_site_configs
json_object = get_json_object(s)
File "/opt/az/lib/python3.6/site-packages/azure/cli/core/util.py", line 466, in get_json_object
return _convert_to_snake_case(shell_safe_json_parse(json_string))
File "/opt/az/lib/python3.6/site-packages/azure/cli/core/util.py", line 531, in shell_safe_json_parse
raise InvalidArgumentValueError(msg, recommendation=recommendation) from json_ex
azure.cli.core.azclierror.InvalidArgumentValueError: Failed to parse JSON: { managedPipelineMode: Classic }
Error detail: Expecting property name enclosed in double quotes: line 1 column 3 (char 2)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/az/lib/python3.6/site-packages/knack/cli.py", line 231, in invoke
cmd_result = self.invocation.execute(args)
File "/opt/az/lib/python3.6/site-packages/azure/cli/core/commands/init.py", line 657, in execute
raise ex
File "/opt/az/lib/python3.6/site-packages/azure/cli/core/commands/init.py", line 720, in _run_jobs_serially
results.append(self._run_job(expanded_arg, cmd_copy))
File "/opt/az/lib/python3.6/site-packages/azure/cli/core/commands/init.py", line 691, in _run_job
result = cmd_copy(params)
File "/opt/az/lib/python3.6/site-packages/azure/cli/core/commands/init.py", line 328, in call
return self.handler(*args, **kwargs)
File "/opt/az/lib/python3.6/site-packages/azure/cli/core/commands/command_operation.py", line 121, in handler
return op(**command_args)
File "/opt/az/lib/python3.6/site-packages/azure/cli/command_modules/appservice/custom.py", line 1175, in update_site_configs
config_name, value = s.split('=', 1)
ValueError: not enough values to unpack (expected 2, got 1)`
I also tried passing in as a json object --generic-configurations `@pipeClassic with the .json consisting of
{ "managedPipelineMode": "Classic" }
Error :
azure.cli.core.azclierror.InvalidArgumentValueError: Failed to parse JSON: @pipeClassic
Error detail: Expecting value: line 1 column 1 (char 0)
..ValueError: not enough values to unpack (expected 2, got 1)
Thanks,
AT

@poplaar Your problem seems to be with your json input syntax. A Syntax like below worked to me in a Cmd/Win terminal. Hope it helps.
az webapp config set -g myGroup -n myAppName --generic-configurations "{\ "managedPipelineMode\": \"Classic\" }"

@mvitor Thanks for the tip, but even with the syntax you suggest I receive an error 'Error detail: Expecting property name enclosed in double quotes: line 1 column 2 (char 1)' and 'ValueError: not enough values to unpack (expected 2, got 1)'
Also mentioning 'ValueError: not enough values to unpack (expected 2, got 1')
I have uploaded an image of how the Azure Cloud Shell app displays the command after typing it on the command line. Note where some of the text is in blue, indicating it is not quite able to parse it.


Update OpenSSL to 1.0.2r

Update OpenSSL to 1.0.2r and make it compile

update openssl binaries and headers
use separate modulemaps for iOS vs macOS

This branch has a problem with building for 'armv7' architecture.
I'm not sure why this is. It is reproducible by setting valid archs of the iOS framework target to armv7, and trying to build the framework.

This will be replaced by a newer version


Updated .travis.yml to be the same as atom/ci

.travis.yml was updated in atom/ci seemingly to fix the new Linux Beta issue referenced in #33

The checks have passed so I guess this has fixed it until the next time it breaks

Thanks mate! This really helps, at least the badge won't be red any longer!


"The 'path' argument must be of type string. Received undefined" when using next-auth

Describe the bug
I initially raised a bug on the next-auth repo here: https://github.com/nextauthjs/next-auth/issues/1311
I am using next-on-netlify with next-auth. I am able to enter my email address at /api/auth/signin, but the following page (/api/auth/signin/email) shows the following runtime error:
{"errorType":"Runtime.UnhandledPromiseRejection","errorMessage":"TypeError [ERR_INVALID_ARG_TYPE]: The \"path\" argument must be of type string. Received undefined","trace":["Runtime.UnhandledPromiseRejection: TypeError [ERR_INVALID_ARG_TYPE]: The \"path\" argument must be of type string. Received undefined","    at process.<anonymous> (/var/runtime/index.js:35:15)","    at process.emit (events.js:314:20)","    at processPromiseRejections (internal/process/promises.js:209:33)","    at processTicksAndRejections (internal/process/task_queues.js:98:32)"]}

The full logs on Netlify show the following:
11:22:40 PM: 2021-02-13T23:22:40.108Z	b4c355c3-801b-4f2e-b1a4-9c1fc1f1ef88	INFO	[request] /api/auth/signin

11:22:40 PM: Duration: 25.63 ms	Memory Usage: 133 MB	Init Duration: 632.42 ms

11:22:45 PM: 2021-02-13T23:22:45.318Z	754432c8-0294-4ed2-b94e-09ee1c1657bb	INFO	[request] /api/auth/signin/email

11:22:45 PM: 2021-02-13T23:22:45.825Z	754432c8-0294-4ed2-b94e-09ee1c1657bb	WARN	Warning: no saslprep library specified. Passwords will not be sanitized

11:22:46 PM: 2021-02-13T23:22:46.115Z	754432c8-0294-4ed2-b94e-09ee1c1657bb	ERROR	Unhandled Promise Rejection 	{"errorType":"Runtime.UnhandledPromiseRejection","errorMessage":"TypeError [ERR_INVALID_ARG_TYPE]: The \"path\" argument must be of type string. Received undefined","reason":{"errorType":"TypeError","errorMessage":"The \"path\" argument must be of type string. Received undefined","code":"ERR_INVALID_ARG_TYPE","stack":["TypeError [ERR_INVALID_ARG_TYPE]: The \"path\" argument must be of type string. Received undefined","    at validateString (internal/validators.js:120:11)","    at Object.dirname (path.js:1128:5)","    at find_package_json (/var/task/src/nextPage.js:132745:23)","    at find_package_json_with_name (/var/task/src/nextPage.js:132762:20)","    at require_optional (/var/task/src/nextPage.js:132797:13)","    at Object.<anonymous> (/var/task/src/nextPage.js:153355:53)","    at Generator.next (<anonymous>)","    at asyncGeneratorStep (/var/task/src/nextPage.js:153264:103)","    at _next (/var/task/src/nextPage.js:153266:194)","    at processTicksAndRejections (internal/process/task_queues.js:97:5)"]},"promise":{},"stack":["Runtime.UnhandledPromiseRejection: TypeError [ERR_INVALID_ARG_TYPE]: The \"path\" argument must be of type string. Received undefined","    at process.<anonymous> (/var/runtime/index.js:35:15)","    at process.emit (events.js:314:20)","    at processPromiseRejections (internal/process/promises.js:209:33)","    at processTicksAndRejections (internal/process/task_queues.js:98:32)"]}

11:22:46 PM: Duration: 805.37 ms	Memory Usage: 136 MB

11:22:46 PM: Unknown application error occurred

I can't make much of what's going on, but digging through node_modules it seems the validateString() method mentioned in the logs above belongs to the Next.js library.
Any ideas on whether this is a next issue, next-auth issue, or a next-on-netlify issue?
To Reproduce
Steps to reproduce:

Navigate to https://next-on-netlify-auth.netlify.app/api/auth/signin
Enter email
See error message

The same steps above work without error on localhost (both npm run dev and netlify dev).
Here is a repo with the code: https://github.com/zaarheed/next-on-netlify-auth. Run it locally or deploy to Netlify. Remember to add environment variables in .env (example provided) or in the Netlify dashboard.
Versions
"next": "10.0.6"
"next-auth": "3.4.1"
 "next-on-netlify": "2.8.7"

@zaarheed hey! thanks so much for providing such a detailed issue. i wish it was enough but unfortunately i need a little bit more. i'd love to help you but don't have the time to set up the env vars that seem to be needed/legitimate in order to exactly repro what you're seeing. if you can provide valid "mock" values for EMAIL_FROM, EMAIL_SERVER_ADDRESS and IDENTITY_DB_URL, i can handle NEXTAUTH_URL and NEXT_PUBLIC_BASE_URL (obv, as they'll be my own site's url). feel free to dm me @levlinds if you want to share your original personal ones with me, but it's not in my scope to navigate around next-auth in order to repro unfortunately :( hope you understand!

@lindsaylevine totally understandable. I've DM'd you with all the env vars you need to recreate the issue. Once you're done I'll delete them.
If anyone else needs access to the vars to investigate, feel free to DM at @zaarheed me and I'm happy to provide.
Appreciate any insight and guidance on this issue :)

@zaarheed hello! so i believe this may actually be a next-auth issue after all... but not totally sure next-on-netlify is absolved of all responsibility quite yet. cc @balazsorban44
what i do know is that the root of the issue starts here: https://github.com/nextauthjs/next-auth/blob/82dd6ba3e4ba481c5003c918eb1d2fa95f7d76dd/src/adapters/typeorm/index.js#L101
in the lambda that Next.js generates for your API route /api/auth/next_auth (aka what we host in a netlify function), there's the require_optional call for 'mongodb', which eventually takes us to the line that's failing:

location = path.dirname(location);
id argue that the condition that allows this line to run is a bug (aka } else if (location !== '/') {). this condition will pass when location is undefined, causing path.dirname to error out with the error we're seeing.
that said, i acknowledge this code likely never expected location to be undefined. this is where the fault could be on netlify's side. i'll have to do a bit more digging there to know for sure, but i'm not sure right now why this require_optional logic is necessary.

@lindsaylevine Interesting, thanks for taking a look. It sounds very similar to this issue I saw on the next-auth repo earlier.

if you include package.json in the list of files that get bundled and deployed and that should resolve the issue - I think there are some old issues (possibly closed now) that cover this.

interesting comment from @iaincollins ... i'm not sure this is a fair expectation? traditionally the package.json is excluded from bundles and publish dirs on purpose 🤔

@zaarheed hey hey - i hate to send you on a wild goose chase. it's frustrating bouncing between repos, for sure. that said, i don't think there's anything left i can do on netlify's end. this is an issue specifically with next-auth and how next is bundling/generating this lambda representing /api/auth/[...nextauth]. when i log currentModule in the source at this point i get:

this of course means currentModule.filename is undefined, causing location to be defined. the module value comes from the way this lambda is generated by next.js. i could possibly help you personally with a patch, unrelated to netlify, to unblock you, but i'm not sure what we can do on our end :/. if you wanted to temporarily use patch-package to move forward, let me know, and we can try to figure that out together. yk how to reach me on twitter as well!
if a next or next-auth maintainer can prove past what i've proven that this is in fact netlify specific, i'll be happy to dig deeper into their findings!!

To say something here, I don't like require_optional, and would like to move to something like peerDependenciesMeta. We are also in the process of moving out the adapters into their own packages. (https://github.com/nextauthjs/adapters)
Related issue: https://github.com/nextauthjs/next-auth/issues/1012


Errors are not reported when multiple statements are executed in a query

When cursor.execute is passed a query that has multiple statements, (delimited by semicolon) and one of the statements results in a database error, that error is not raised (unless it is the first statement).
Here's an example of a query that when run on its own raises a MissingColumn exception:
import vertica_python
params = get_default_db_params()
connection = vertica_python.connect(**params)
cursor = connection.cursor()
cursor.execute('select a;')  # bad query to raise and exception
When this query is among multiple statements (and not the first statement) no error is raised.
cursor.execute('select 1; select a;')
The expected results is a MissingColumn exception.
Tested with vertica_python 0.7.3 on Python 3.5.0, with Vertica 9.0.x db.
This was an issue(#124 ) that has been closed but this issue still exists in the latest vertica_python 0.7.3

I think this is a dup of #185.

This works as expected. See https://github.com/vertica/vertica-python/issues/124#issuecomment-301279343. vertica-python streams data results, so you have to iterate through results with nextset() to get the MissingColumn exception.

I have the opposite problem, I have a statement that drops the table if it exists and then creates the table again with a long query.  As soon as it Drops the table, it moves on in the python to the next part, not waiting for the second query to complete.  Is it the same solution?

I have the opposite problem, I have a statement that drops the table if it exists and then creates the table again with a long query. As soon as it Drops the table, it moves on in the python to the next part, not waiting for the second query to complete. Is it the same solution?

@hannahshachar Based on your description I think the answer is yes. Please read up to the README, especially the nextset() section: https://github.com/vertica/vertica-python#nextset


Improve type for assert using overloads to indicate the error message returned

Fixes #980
Note that library.md would have to be updated to accommodate this change, though I was unsure whether to include it in the PR

Closed because I forgot to run the checks beforehand and just assumed the syntax was the same as Luau. Will reopen once fixed.


Guide not clear: when does Skera occur in a MAS seq workflow?

Hey! I'm working through the MAS seq workflow, and that workflow (here https://isoseq.how/umi/cli-workflow.html ) has the wording:

Step 1 - Input
HiFi Reads
Each sequencing run is processed by ccs to generate one HiFi read from productive ZMWs. After CCS is performed, you can use the hifi_reads.bam as input. The hifi_reads.bam contains only HiFi reads, with predicted accuracy ≥Q20. No additional filtering is required.
Segmented Reads
HiFi reads that have been segmented using skera as a part of the MAS-Seq single cell application can also be used.

I am focussing on this point:

Segmented Reads
HiFi reads that have been segmented using skera as a part of the MAS-Seq single cell application can also be used.

Reading the document from top to bottom, there isn't a clear "if you are using the MAS seq workflow and need to segment, do Skera first". Instead, it just sort of skips past that part.
Do I need to do Skera first? If so, can you put that up at the top as a Step1: doing MAS seq? Then Skera. If not, proceed to Step 2, primer editing (or whatever). The docs for Skera at https://skera.how/ also don't give me a sense of how the output of that command interfaces with the downstream workflow on https://isoseq.how/umi/cli-workflow.html ; it sounds like I'm going to get a bunch of .bam files, do I need to then run each following step on CLI workflow up to 16 times on each bam? Or what?
Since these commands aren't really verbose in the terminal, I can't tell if they are running or not without just waiting a long time for them to run, and I don't want to find out that I messed up after conjuring a meeting with a PacBio tech and waste their time ':)
Thanks for any clarity!

Anyways, I just gambled and chose to do Skera first, then proceeded. The guide writing could use enhanced clarity on this point, but looks like I didn't break anything with my guess.


Porting issue due to unitialized static variables

Hi Gabor,
First of all, I haven't many experience with your library (playing with it for 3 days) but seems great (i.e. easy to understand), flexible and already implementing lots of features.
So I'm porting your library in an already existing project on TI C6000 DSP attached with a monochrome 128x64 LCD (hence I upvote for this kind of LCD support, but side story and will comment on appropriate issue). I started, cool simple init, driver registration and the flush callback to write! But it revealed to be not that easy. First run: the program gone crazy by jumping to random address. Solved by initializing static function pointers to null. Started working but faced another problem: depending on the code size, it worked or not. I tracked it down (by simply compiling or not an unused buffer) and it revealed to be that the lv_style_scr.body.empty is not initialized and it happened to be 0 or 1 depending on the variable place in memory. Once more due to a static variable not initialized. Solved by memsetting to 0 the lv_style_scr in lv_style_init.
Static variable go to a section commonly called .bss. While some argue that C standard impose unitialized variables to be set to 0 (or NULL), many compilers do it but that's not the case of the TI C6000 compiler in COFF legacy mode.
Of course I can force to set the .bss section to 0 (did not managed to as of now) but I think it would be better that the library does not rely on the linker behavior of setting to 0 the unitialized static variables. This would increase portability, ease of use (does not need to track this kind of problem), and compiler/linker independence.
What do you think?
Best regards

Uninitialized variables should be set to 0 via the startup code, it's quite common practice.  Likely you can find or create some linker script and startup code to do this.
Having to initialise every variable to 0/null is generally frowned upon by many on projects I've worked on.  The main reason is that a) developers forget, b) it creates uncertainty, b) it causes code bloat.
Likely other libraries that you use also expect unitialized variables to be 0.
However, I would suggest the any porting instructions mention this requirement.

Hi,
As far as I know, it's a C standard to initialize all global variables to zero. I googled on it and others state the same. Maybe it's a bug in your SDK?

I found this: http://e2e.ti.com/support/development_tools/compiler/f/343/p/142730/841284

Here's a couple of examples on the STM32 platform, for reference
https://github.com/cleanflight/cleanflight/blob/master/src/main/startup/startup_stm32f40xx.s#L114-L124
https://github.com/cortexm/baremetal/blob/master/src/startup/startup.cpp#L31-L37

Hi all and thanks for your answers.
You're right, it seems to be C standard to initialiaze all global variables; I had a doubt after reading discussions with people debating whether it's standard or not.
But it's not a bug in the SDK, it's stated as this in the TI documentation:

In ANSI C, global and static variables that are not explicitly initialized must be set to 0 before program execution. The C/C++ EABI compiler supports preinitialization of uninitialized variables by default. This can be turned off by specifying the linker option --zero_init=off. COFF ABI does not support zero initialization.

Unfortunately, the project I am working on uses the COFF ABI and is not going to be translated to EABI soon.
@hydra Thank you for the links, I already did that using gcc on an ARM platform; but here I discover the C6000 world. I'll investigate more on that, I have read that I can put a fill: 0 in front of the section in the linker script.
By the way, I understand your a) and c) points but why do you state b) it creates uncertainty?
Maybe @hydra is right and it would just require a warning in the porting guide

b) because if you see initialisation to zero where it is not needed see it you might continue to repeat it where it is not needed, leaving readers of the code wondering why it's there.

According to our discussion, this issue seems quite specific to your compiler and should be solved by some compiler settings.
Because of it, I close this issue.
@Zahriman If you found a solution, please share here to help others. Thank you!
I will add a remark about it to the porting guide.


Badges and tests

As discussed in internal ticket VT-1069, here are some badges and some sample unit tests

I don't have merge rights on this repo.

I have reworked the Docker build setup and removed multiarch support for Docker. Care to review again?

wait...pipeline will fail for master

As discussed with @srueg , we will not do docker pushes on master branch anymore, only tags. As such, I have adapted the pipeline so that docker builds & pushes also happens with goreleaser


Fix for Issue#37

Version 1.0.3 fixed Issue#37 : certainty attributes now have a "level" parameter.


Fix stuck service discovery when looking for different services

Subsequent calls to discoverServices method in Peripheral with different services UUIDs causing it to return an empty sequence instead of success. This happens because after the first call the peripheral already has some discovered services and in the next call the comparison between sets of services identifiers fails if you ask to discover another service

Hi,
Great catch. Will look at it tomorrow, and probably release it with other bug fixes.
Thanks! :-)

Hello,
I looked at it with a bit of delay.
I think that your intention was rather to check it on the other way, so instead of:  Set(identifiers).isSubsetOf(Set(uuids)) it would look like that:
Set(uuids).isSubsetOf(Set(identifiers)). So it'll work in a way that if you requested services A,B,C and A was already discovered, so method returns only B,C.
Thank you very much for discovering this - it's an issue and it'll be resolved today.
Have a great day :-)

Hi! 'identifiers' is a list of identifiers which I pass to the discoverServices, this Set can contain less identifiers than already discovered, so it's a subset of already discovered services Set. But it also should work in other way - if you request more services than you have now, you should only request missing services, so probably my fix should be extended for this case.

Hello,
We've been thinking about it and i think that we've found optimal solution.
Basically - now we're not taking into consideration services that are given by the delegate method.
So basically: When you have already discovered service A, and asked about services A, B, C - behavior is that you'll receive all of them, when B, C will be discovered.
Just to be sure - this is behavior you're expecting?
Thank you for feedback :-)

This will be fixed by #40

You are describing one case, it also should be handled. But in my case I have A,B,C discovered and I request only A in the next call.

So why do you want to call discoverServices while every one of them is already discovered? :-)

Because peripheral contains this information about these services in cache, so this call should succeed in my case

Ok, that's right - but you could also check it's services property and simply read it. Why not?
But i think that we could implement pre checking - so if every one of requested services is already in cache it'll be wrapped in observable and returned without calling any discover.

You are right, I can do that. But this call shouldn't simply stuck if someone will not do this check.

I agree with you that this should work - so i'll implement the following behavior: if someone specifies concrete array of identifiers, these will be returned if already in cache.
Thank you for feedback, it's really valuable :)


[LEVELER] New fonts doesn't supports Cyrillic characters.

Aww, ok I'll try to find a workaround. For now, you can change the font back by replacing the font_bold.tff file in the data folder with the old one.

Wait, did it work before?

Yep

Font has been changed back.


GH - 69 - Fixed PopOver styles

Fixes #69

Thank you very much for this! This problem was killing me for a while now. The colors are not perfectly consistent with the rest of the theme, however this was a much needed fix. Can you tell me where exactly are you reading the new documentation from? It's been hard, to go over the whole thing again, back and forth, with the inconsistent documentation for theming. (I am right now, looking at other themes for inspiration, however I would like to do this more properly, like, going step by step via a documentation).


Replacement of Moment.js

Discussion 🗣
Accord needs to replace Moment.js. Diana Lease has done some great work investigating replacement options.  Diana presented findings at the Tech WG on Wed 28-October comparing Moment.js with Day.js and Luxon. She is recommending Day.js
Context
Moment.js is being deprecated. Moment.js is used throughout the Accord stack. A replacement library will need to implemented at some stage to replace the deprecated Moment.js stack.
Detailed Description
See issue #205 and TechWG Call Recording for 28-Oct for further details.

Technology WG has discussed this issue at length and decided to switch from moment to dayjs.
Initial change is already in Concerto 1.0. See corresponding PR here: https://github.com/accordproject/concerto/pull/218
Rest of the AP stack still needs to be migrated (notably Cicero and Ergo)

Technology WG has discussed this issue at length and decided to switch from moment to dayjs.
Initial change is already in Concerto 1.0. See corresponding PR here: https://github.com/accordproject/concerto/pull/218
Rest of the AP stack still needs to be migrated (notably Cicero and Ergo)

Handled by Tech WG. Resolved.

Handled by Tech WG. Resolved.


Ensures Cedar.Thm.Partial.Expr is actually built

Issue #, if available:
N/A
Description of changes:
Cedar.Thm.Partial.Expr wasn't actually being built. This caused some drift where it no longer actually verified.
Both are fixed, and updates batteries to new rev while I was here.

No longer needed due to a refactoring


julia.withPackages: handle non-archive artifacts (fixes #277410)

Description of changes
This fixes #277410 by distinguishing between archive and non-archive artifacts. The former are treated the same as before: extracted and fixed up to correct RPATHs and such. The latter are fetched with a plain fetchurl call.
This fixes the following environment command:
nix run --impure --expr 'with import ./. {}; (julia_19.withPackages ["Plots" "DifferentialEquations"])'

CC @fedeinthemix.
Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[X] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[X] Fits CONTRIBUTING.md.

@thomasjm  I've tested the PR and works fine for me. Thanks for the quick fix!


Remove .DS_Store files

This removes all .DS_Store Files and adds them to .gitignore.

In the Apple OS X operating system, .DS_Store is a file that stores custom attributes of its containing folder, such as the position of icons or the choice of a background image.
-- https://en.wikipedia.org/wiki/.DS_Store

@jpbernius Thanks


[package request] vita3k

Project description
An experimental PSV emulator
Metadata

homepage URL: https://vita3k.org/
source URL: https://github.com/vita3k/vita3k
license: gpl2Only
platforms: linux

Tried to package it but didn't succeed (yet?): https://github.com/NixOS/nixpkgs/pull/195556


render outside the pager is slow after onPageChange

Hi, I'm trying to update a value in onPageChange so it matches the current page but the new value renders really late.
From my tests I think it's due to my update being queued behind all the pages rendering, any idea how I could improve this? The value has to be outside the pager.

@computerjazz would it be possible to add something like onPageWillChange? So that I can update my value before the pager starts a new render.

At the individual page level you can listen to animated values passed to your PageComponent: https://github.com/computerjazz/react-native-infinite-pager/blob/main/src/index.tsx#L308-L310
You could use pageAnim or focusAnim in a useAnimatedReaction to trigger some side effect when the values pass some threshold (maybe using Math,round()).
Or pass in a pageCallbackNode and do the same thing at the parent level: https://github.com/computerjazz/react-native-infinite-pager/blob/main/src/index.tsx#L47

It works!! Thank you for the feedback!


Incorrect example in 'Remove a single secret'

[Enter feedback here]
The example below:
'The app's secrets.json file was modified to remove the key-value pair associated with the MoviesConnectionString key:'
appears to be incorrect.
It says:
{
"Movies": {
"ServiceApiKey": "12345"
}
}
It should be:
{
"Movies:ServiceApiKey": "12345"
}

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

ID: 9c99993c-c983-6fda-6c3a-ce4ec8c1d5db
Version Independent ID: ba688ac2-e90e-fce5-f60d-40c2553c3efd
Content: Safe storage of app secrets in development in ASP.NET Core
Content Source: aspnetcore/security/app-secrets.md
Product: aspnet-core
Technology: aspnetcore-security
GitHub Login: @Rick-Anderson
Microsoft Alias: riande

You can flatten them per the doc but they're the same.


build: change mempool infra test mod inclusion

This change is

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 48.68%. Comparing base (d392733) to head (cbb33b0).

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #186   +/-   ##
=======================================
  Coverage   48.68%   48.68%
=======================================
  Files          23       23
  Lines         910      910
  Branches      910      910
=======================================
  Hits          443      443
  Misses        446      446
  Partials       21       21

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