bug(release): Fail to push the remote cache

Description
Failed to publish the image cache.
Ref https://github.com/tensorchord/envd/actions/runs/3165101028/attempts/1
Reproduction
Additional Info

Message from the maintainers:
Impacted by this bug? Give it a 👍. We prioritise the issues with the most 👍.

fixed by #985


404 The application could not process your request

This popup message informs me every time I press export.
 Everything goes well until I press the export button:
404 The application could not process your request
How to proceed?
Thank you!

I don't need a commercial code. You can write a minimal example that reproduces your error. Otherwise, we will only guess the reason for the error.

I have solved


Switch default DNS plugin to CoreDNS

Feature Description

One-line feature description (can be used as a release note): Switch default DNS plugin to CoreDNS
Primary contact (assignee): @johnbelamaric
Responsible SIGs: sig-network, sig-cluster-lifecycle
Design proposal link (community repo): https://github.com/kubernetes/community/pull/1100
Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred: @bowei @thockin
Approver (likely from SIG/area to which feature belongs): @thockin
Feature target (which target equals to which milestone):

Alpha release target: 1.12

xref: #427
/kind feature
/sig cluster-lifecycle
/sig network
/assign @johnbelamaric

Hi, thanks for filing this feature!
I have a couple of questions/concerns though.
Why is this marked alpha? It sounds more like it should be stable/GA when it's a default.
I don't think this even needs to be a separate features issue. The common practice is to use one issue (in this case https://github.com/kubernetes/features/issues/427) to track the full lifecycle.
If your goal is to have CoreDNS as the default DNS plugin in v1.12, I'd just adjust https://github.com/kubernetes/features/issues/427 to be "stable/GA target: v1.12"
Cheers :smile:

The reasoning behind the split was, that in order to make it default later on the actual plugin needs to be stable/GA already. That was the prerequisite after a bigger discussion. The result was the split into two feature issues and making the default alpha first. (Alpha might not be the best thing so.)

Reading all your other comments on the other thread (https://github.com/kubernetes/features/issues/427#issuecomment-387485724) your comment is much clearer in my head. As CoreDNS is such a central place it make still make sense to track the state of being the default.

@johnbelamaric @cmluciano --
It looks like this feature is currently in the Kubernetes 1.12 Milestone.
If that is still accurate, please ensure that this issue is up-to-date with ALL of the following information:

One-line feature description (can be used as a release note):
Primary contact (assignee):
Responsible SIGs:
Design proposal link (community repo):
Link to e2e and/or unit tests:
Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred:
Approver (likely from SIG/area to which feature belongs):
Feature target (which target equals to which milestone):

Alpha release target (x.y)
Beta release target (x.y)
Stable release target (x.y)

Set the following:

Description
Assignee(s)
Labels:

stage/{alpha,beta,stable}
sig/*
kind/feature

Please note that the Features Freeze is July 31st, after which any incomplete Feature issues will require an Exception request to be accepted into the milestone.
In addition, please be aware of the following relevant deadlines:

Docs deadline (open placeholder PRs): 8/21
Test case freeze: 8/28

Please make sure all PRs for features have relevant release notes included as well.
Happy shipping!
/cc @justaugustus @kacole2 @robertsandoval @rajendar38

I assume this is beta in v1.12? kubeadm has used it on a GA/beta level already since v1.11 fwiw

@johnbelamaric / @cmluciano / @luxas / @thockin --
So this is a case where the "graduation" of the feature is actually flipping the bit for it to be the default DNS plugin.
As CoreDNS is already GA, what should we do here?

Straight to GA?
Set to Beta to soak for a release and then graduate to GA?
Something else entirely?

/assign @johnbelamaric
/remove-stage alpha

As the point for switching the flip was mainly to separate GA of CoreDNS and the actual config switch it seems like moving to beta is another step, that might not be necessary especially considering it's already GA/beta in kubeadm.
Should go GA in v1.12 in my view fwiw.

Just to clarify for passerbys...
Adding CoreDNS as a DNS plugin was tracked on #427. There is a process for moving features through stages (alpha --> beta --> stable), which again was tracked on #427.
This Feature issue is unique in the fact that here, we're not actually tracking the development state of the feature (as it's already been developed), but instead we're tracking the process of deciding in which release it should be enabled as the default DNS plugin. AFAIK, we don't have an official graduation process for "flipping a bit".
While developing kubeadm is a separate concern, @stp-ip is right; this has already had some soak time as CoreDNS was selected as the default DNS plugin for kubeadm in Kubernetes 1.11.
FWIW, I would also vote to mark this as GA for 1.12, but I'll wait for the powers (@kubernetes/sig-network-misc) that be to make a call on that.

How does this process relate to the KEP process?
The KEP for graduating CoreDNS to default DNS server, is here ...
https://github.com/kubernetes/community/blob/master/keps/sig-network/0012-20180518-coredns-default-proposal.md

I agree that switching to default based on kubeadm results is great progress. Do we have any preliminary results from cloud-providers or other large deploys on stability.
It may be a "flipping in bit" in docs, but often features are not used in k8s until they reach beta stage.

@johnbelamaric @cmluciano -- we still need to make a call on this. I'm tentatively setting this to GA on the sheet, but let me know if you feel differently.
/stage stable
cc: @kacole2 @wadadli @robertsandoval @rajendar38

The KEP lists the following criteria for graduating coredns to "default"...

Add CoreDNS image in a Kubernetes repository (To Be Defined) and ensure a workflow/process to update the CoreDNS versions in the future.
Have a certain number (To Be Defined) of clusters of significant size (To Be Defined) adopting and running CoreDNS as their default DNS.

The first is, I believe, satisfied.
For the second, we (CoreDNS team + CNCF) are conducting a survey of k8s+coredns users to gauge coredns adoption in large clusters. Just pushed it out recently. We do not have survey results yet.

@justaugustus : I try to push an email on this subject with Tim, John, I will add @cmluciano .. but I cannot find any email for yourself. Can your provide one ? Thanks !

for info, the survey for feedback on CoreDNS adoption is available here : https://www.surveymonkey.com/r/SKZQSLK

Going GA with this feature means deprecating kube-dns, I think we need to wait until 1.13 at the earliest for this, to gather enough data.

Going GA with this feature means deprecating kube-dns, I think we need to wait until 1.13 at the earliest for this, to gather enough data.

Agree.

Going GA with this feature means deprecating kube-dns

I was thinking that first CoreDNS would become default, then in a following release, kube-dns would become officially deprecated.   Kube-dns deprecation schedule is not covered in the KEP, or this feature.  I think it's acceptable to have two supported GA DNS solutions during transition time (as we have now in k8s 1.11).

Hey there! @justaugustus I'm the wrangler for the Docs this release. Is there any chance I could have you open up a docs PR against the release-1.12 branch as a placeholder? That gives us more confidence in the feature shipping in this release and gives me something to work with when we start doing reviews/edits. Thanks! If this feature does not require docs, could you please update the features tracking spreadsheet to reflect it?

Thanks. @rajansandeep can you take a look at what we need beyond the
rollback piece? Certainly we need to mention it is the default. Last
release we discussed reworking some of the documentation around configuring
DNS options - we should take a look at those docs and revise as needed.
On Mon, Aug 27, 2018 at 1:22 AM Jim Angel<EMAIL_ADDRESS>wrote:

@johnbelamaric https://github.com/johnbelamaric @cmluciano
https://github.com/cmluciano Bump for docs ☝
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/features/issues/566#issuecomment-416152542,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJB4s9h21emz7GNr8NIlDw7zZp0ydDPfks5uU6wvgaJpZM4T1q8D
.

It's not noted on here so let me just be sure everyone is aware we are moving forward with CoreDNS as the default in 1.12 per last week's sig-network meeting.

Awesome @johnbelamaric! Is there a place this needs to be updated in k/website?

These two articles will need replacing for CoreDNS at some point, since kube-dns is getting deprecated:
https://kubernetes.io/docs/tasks/administer-cluster/dns-horizontal-autoscaling/
https://kubernetes.io/docs/tasks/administer-cluster/dns-debugging-resolution/
also https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/#config-coredns

@zparnold @nikopen @johnbelamaric
I am working on getting this page updated/rewritten:
https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/

Perfect, thanks! Please update here with the PR link. :)
On Tue, Sep 4, 2018 at 7:41 AM Sandeep Rajan<EMAIL_ADDRESS>wrote:

@zparnold https://github.com/zparnold @nikopen
https://github.com/nikopen @johnbelamaric
https://github.com/johnbelamaric
I am working on getting this page updated/rewritten:
https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/features/issues/566#issuecomment-418392999,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AE81SFlTcrRBBtV5NRgs4oKEXBXbme8Hks5uXpEogaJpZM4T1q8D
.

I’m looking into the auto scale and debugging articles.

@justaugustus I think we can wait a cycle or so to deprecate kube-dns. Originally I was pairing the two but that's not strictly necessary.

@justaugustus I think we can wait a cycle or so to deprecate kube-dns. Originally I was pairing the two but that's not strictly necessary.

@johnbelamaric -- Got it. Noting again that we need to coalesce a plan for kube-dns deprecation sooner rather than later, as it's a multi-release event.

Hi @rajansandeep, @johnbelamaric,
How are docs looking for this? Is there a PR open in k/website?

I forgot to refer the PR for this.
https://github.com/kubernetes/website/pull/10228 is ready for review.

... and kubernetes/website#10200 and kubernetes/website#10201.

warning this is now at risk, see:

/milestone v1.13

@AishSundar : We have been investigating the scale issue and memory constraint. We found some optimization and know now we can make it. However we need to wrap up the changes and publish a new release of CoreDNS.
I cannot provide a date yet, but I expect to be by Oct 15th.
We then need:

re-publish the PR for CoreDNS as default, with the new image. (pretty simple - no delay)
e2e test will validate after that merge. (2 PR already presented - see below)
about doc, I think all docs expected were finally merged in 1.12 (because still valid whatever CoreDNS is default or not for GCE). We may need to have another look.

I agree completely on the need to have this feature checked-in asap. We had a sync-up with @thockin from SIG-Network last Tuesday on this subject.
Thanks to remind the code slush date. I plan to be much ahead of these dates.
PR needed for validation e2e tests at scale:

https://github.com/kubernetes/kubernetes/pull/69283 (already merged)
https://github.com/kubernetes/test-infra/pull/9445

Thanks @fturib for the detailed status and good to know that we have a path forward. I will check on the status again post Oct mid.

Thanks @fturib for the confirmation. @rajansandeep once you have the doc PRs plz link them here as well. Thanks.

@AishSundar The PR is here. https://github.com/kubernetes/website/pull/10923

@tfogo


Add timeout rplidar driver if successful scans are not recieved

Sometimes the rplidar ros driver hangs without publishing.  Now if no scans are received for 5 seconds rplidar_ros kills itself and respawns

have you successfully tried this?
my fear is that when it hangs, the main loop might be blocked, and thus you may never hit the timeout check

Yeah... Maybe you could try this checking in a separate thread?

we should have the driver publish diagnostics and the app kill it if the diagnostics stall

I was thinking that the diagnostic monitor would be a good place for it too, but that seems a little more involved of an implementation for the demo esp. since Vikram is a bit overloaded at the moment.
But when you have the bandwidth again Vikram, I believe you'll only need to subclass TopicRateMonitor and hook it up with roslaunch so that it knows which process to kill. Maybe a good way to do it is to have a TopicRateMonitor subclass take a call back function so that the complicated killing & restarting logic can be configured all in the main gizmo.py class instead of being in diag.py.

Okay to answer Paul's first question I tested this by unplugging the rplidar after I had started the app.  The node timed-out, died, and respawned successfully.  I havent been able to replicate the bug where the rplidar driver hangs naturally so I'm not sure if this is a good fix. Do we still want to keep this change or do we want to move all this logic to somewhere around gizmo.py

Work out proper solution later. This branch is harmless and is on the demo robots.  We can setup a proper fix later.


feat: PD Form fields- Airgap

Overview
As a PD user, I would like to be able to choose Air Gap as an Aspirate advanced setting for Transfer steps
Design
Form fields:
https://www.figma.com/file/0dTEbGNsKYgNwKEW6LLfzJ/Airgap-Delay?node-id=50%3A850
Tooltips:
https://www.figma.com/file/0dTEbGNsKYgNwKEW6LLfzJ/Airgap-Delay?node-id=104%3A0
Acceptance criteria

Enable Air gap checkbox in advanced settings
When checked, air gap should generate a text field for uL
Air gap should have a tooltip explaining what the setting does
If 'OT_PD_ENABLE_AIR_GAP_AND_DELAY' is not turned on, the field should remain disabled (as on edge)

Oops, 5fd5f4d closed #6046 but I typed the wrong number in the commit itself (PR #6048 correctly says it closes #6046)


NetworkAnimator bug - Endless loop between two animations when the framerate is low on the server

Hi, when the framerate is unstable NetworkAnimator makes AI Animator enter in a endless loop between two random animation states. I've searching the source of this bug for months, I have tried more than 5 different AI systems(Behaviour trees, State Machine, GOAP), And I have tested this with many different versions of mirror(since version 9), Currently my project is using Mirror 30, and the problem still happens.
I have found that the problem is not in my code, it is on the NetworkAnimator component. Because, when i remove the NetworkAnimator component from the AI this bug never happens.
Adding Exit time between the animation states, makes the bug less frequent, but it still hapens
I'll send videos of the bug happening(See bellow)
Videos
[Video]Bug happening: https://www.dropbox.com/s/nz8o6ks6nif699u/0000_bug_happening.mp4?dl=0
[Video]Fixing the bug by removing Network Animator: https://www.dropbox.com/s/p04wvxh10szxy49/001_what_happens_when_i_remove_network_animator.mp4?dl=0
OBS: This bug happens with any AI system that I use(Made by me or third party AI Library)
OBS: This bug happens in Any version of Unity that i use(since 2018.3) Currently I'm using 2019.4.11
OBS: This bug is always fixed by removing Network Animator at runtime.
Steps to reproduce the behavior:

Create a basic AI with some animation states and with Network Animator
Reproduce an envirioment where the frame rate is unstable
Wait, and some time this will happen

Thanks.

@techtuxbr any chance you could try to debug it?
I don't use networkanimator myself and don't even want it to be in mirror :)
but people still use it

I noticed this bug on host when i was trying to find cause of another animator bug which was also fixed by disabling NetworkAnimator.
This loop in my case happens also on low FPS.
Looped states have one frame "animation" and two way transition with "has exit time" disabled and conditions set.
This loop transition should not happen since (first) parameter does not change .
Here is video:
https://gfycat.com/fastgaseousdassierat
My second  bug might be related to this loop.
I noticed that all animations on host will restart after few frames and are played again, it is clearly visible only when stepping frames.
OnStateEnter will also fire twice.
I thought this bug was related to https://github.com/vis2k/Mirror/issues/1508 , but i trigger it in editor with mouse:
here is video: (in 5.36s is that restart)
https://gfycat.com/highleveleagerhound
Sorry about low quality of videos, but text should be readable (chek if HD is enabled)

keeping this open since we have a decent video here.
we need to build a networkanimator example for mirror and then try to reproduce this

I am unable to replicate, would need more project/setup details, or a repo project.

we are going to close this since we can't reproduce it.
if anyone finds their way here into the future: please let us know how to reproduce, then we can reopen and fix it.


[Aio] Async IO manager deadlock with current API

Current gRPC Python API will deadlock using Async IO manager. This problem needs to be solved before merging the first PR.
Reproduction script:
import grpc
import asyncio
from grpc.experimental import aio

async def main():
	print('===Testing Aio Channel===')
	async with aio.insecure_channel('localhost:50051') as channel:
		print(await channel.unary_unary(b'')(b''))
	print('===Finish Aio Channel===')

	print('===Testing Normal Channel===')
	with grpc.insecure_channel('localhost:50051') as channel:
		print(channel.unary_unary(b'')(b''))  # <- deadlock
	print('===Finish Normal Channel===')

aio.init_grpc_aio()
asyncio.get_event_loop().run_until_complete(main())

Log:
I0814 16:23:13.264381376  220688 call.cc:1927]               grpc_call_start_batch(call=0x564af3f8b4a0, ops=0x564af3f69a50, nops=6, tag=0x7f0903e0dc50, reserved=(nil))
I0814 16:23:13.264387822  220688 call.cc:1526]               ops[0]: SEND_INITIAL_METADATA(nil)
I0814 16:23:13.264392291  220688 call.cc:1526]               ops[1]: SEND_MESSAGE ptr=0x564af3dcbc20
I0814 16:23:13.264396790  220688 call.cc:1526]               ops[2]: SEND_CLOSE_FROM_CLIENT
I0814 16:23:13.264401459  220688 call.cc:1526]               ops[3]: RECV_INITIAL_METADATA ptr=0x7f0903e1ee88
I0814 16:23:13.264406097  220688 call.cc:1526]               ops[4]: RECV_MESSAGE ptr=0x7f0903e58f20
I0814 16:23:13.264411516  220688 call.cc:1526]               ops[5]: RECV_STATUS_ON_CLIENT metadata=0x7f0905300bf8 status=0x7f0905300c10 details=0x7f0905300c18
D0814 16:23:13.264423396  220688 dns_resolver.cc:242]        Start resolving.
I0814 16:23:13.264452976  220688 completion_queue.cc:963]    grpc_completion_queue_next(cq=0x564af3f17fd0, deadline=gpr_timespec { tv_sec:<PHONE_NUMBER>, tv_nsec: 464450963, clock_type: 1 }, reserved=(nil))
I0814 16:23:13.464982891  220688 completion_queue.cc:963]    grpc_completion_queue_next(cq=0x564af3f17fd0, deadline=gpr_timespec { tv_sec:<PHONE_NUMBER>, tv_nsec: 664976288, clock_type: 1 }, reserved=(nil))
I0814 16:23:13.665982102  220688 completion_queue.cc:963]    grpc_completion_queue_next(cq=0x564af3f17fd0, deadline=gpr_timespec { tv_sec:<PHONE_NUMBER>, tv_nsec: 865976002, clock_type: 1 }, reserved=(nil))
I0814 16:23:13.866982076  220688 completion_queue.cc:963]    grpc_completion_queue_next(cq=0x564af3f17fd0, deadline=gpr_timespec { tv_sec:<PHONE_NUMBER>, tv_nsec: 66976175, clock_type: 1 }, reserved=(nil))

Turned out if the main thread is blocking wait on cq_next, the asyncio manager will deadlock due to unable to execute another coroutine.

As discussed with @gnossen , potentially there are 4 solutions:

Change C-Core to support binding IO manager to each channel;
Switch current API to use callback stack (so both of them is using asyncio);
Introducing an open source event manager (like libuv based);
Wrap async API to simulate current API.

It seems the first solution is the least effort and the most clean one.

Regarding the options,
1 - Having the feeling - maybe I'm wrong - that solving this issue by adding the ability to run channels with different iomgr instances is not gonna be trivial, or at least the changes in the core won't be negligible. But True, that it would simulate perfectly the mixture of an async API with the sync one, where the sync one uses a different network stack which blocks the asynchronous one. Is the core team aligned with this? do they have in mind using this future feature in other use cases?
2- You mean by replacing the usage of the cq_next for the pure callback completion queue? If so, having the feeling that you would end up by doing what we were saying in the beginning, having the synchronous API build on top of the asynchronous one, having as the main problem the incapacity of keeping compatibility with Python 2.
3- IMO this would be the easiest one, if and only if this open source event manager already exists and is battle-tested. This would mean zero changes in the core, and for the Aio package would mean throwing away the current custom iomgr. True that we would be forced to run all callbacks triggered by the callback completion queue by using threadsafe operations which might have some performance impact, I would still consider this as a viable solution. Also, consider that implementing a POC based on that solution should be relatively easy to do.
4 - I dont get it.

For option 1, this is on the road map of C-Core team. It is possible that they will provide SWE to do it. I agree it is non-trivial, but it will benefits all wrapper languages. Particularly, the migration cases.
The RuntimeError solution should serve as a fallback plan. For now, I agree it is better to throw an exception, after all, exception with a reason is much nicer than deadlock.

@lidizheng could you create an issue for the fallback plan?

@pfreixes Filed #19985

Does this need to be added as part of the gRPC Async board?

After a closer look, it looks like the application thread is deadlock calling asyncio_pollset_vtable.poll which currently is an empty function (pass). The flow goes like Python -> Cython -> cq.next() -> C-Core -> Cython (pollset_poll) -> Python (asyncio).
However, the execution permission is never handed back to the event loop. The shortest path here to fix it is find out a way to make the cq.next() yield something if it is in the event loop. To be investigated.

We could explore still the solution of running the IO operations in another thread but still using an Asyncio loop. This theoretically would allow us to block the current thread while the one that holds all IO operations remains unblocked.
So, in the end, we will be having two different Asyncio loops, one for the IO operations and another one where callbacks would be executed.
The main down-side effect could be the performance, but this should be double-tested since the way both loops would have cooperation will be with a simple local pipe [1]
Another option, based on the same idea, would offload all IO operations that belong to client/server synchronous implementation to this isolated IO thread. If this could be done, only IO operations belonging to synchronous operations would be penalized. Moreover, replicate the semantic of run_once could be easier to implement and less disruptive with the other loop. But in any case, I do not see right now a way for identifying the context of the IO operations, so figuring out if they come from the asynchronous or the synchronous one.
WDYT on trying to make a POC of the first option? It should be something similar to the work that you already did for testing the cooperation between the EV and Asyncio, but without requiring a busy loop.
[1] https://github.com/python/cpython/blob/master/Lib/asyncio/base_events.py#L793

I've been working with a proof of concept [1] for running the IO operations in its own Asyncio loop and thread. Seems that it works, the synchronous client is still working even when the Aio module has been installed [2].
For that proof of concept I didn't bother about the asyncio_run_loop which semantically would need to do return the control only when a gRPC event has happened or the timeout has been reached, leveraging on the fact that internally the cq_next iteration would iterate calling the asyncio_run_loop as many times as needed till the timeout is reached. So the function  asyncio_run_loop` is still doing nothing with the hope that eventually the Asyncio IO loop will do its job for processing the IO operations.
I've made a performance comparison between running a pure async client against a CPP server for testing the likely footprint of having this dedicated IO loop. The results are promising, there is no noticeable impact.
The bad news is that I've detected a regression of the client performance comparing it with the original POC [3] once it gets compared with the current master. Something has been introduced in the current Aio code that slowed down the performance making it almost twice slower. This would need to be investigated.
In any case, this POC tells us that this is a doable effort. I'm wondering if we could do the same using the Event Source IO manager. Theoretically, correct me if I'm missing something @lidizheng, the same implementation could be done but having the Event Source running the separated IO loop, not needing any busy loop and having compatibility with all of the OS systems.
WDYT? /cc @gnossen @lidizheng
[1] https://github.com/Skyscanner/grpc/commit/996636ac853acd2ce60afbb8843181321a9915b4
[2] https://gist.github.com/pfreixes/08086d17fe8357b1b75cee5aac20d561
[3] https://github.com/Skyscanner/grpc-asyncio

The regression noted. After the cancellation mechanism is done, I will look into automating the performance benchmark.
Well, I think Skyscanner@996636a is a great solution that it allows old stack and new stack to co-exist and doesn't have bad performance impact. You should make it a PR.
About using the same pattern against Event Manager, it depends on what logic we put into the callback. If the callback contains any Python object, it would be kind of messy to run in a C spawned thread. In previous experiment, it is possible to manually grab the lock and release after work. It takes time to debug all corner cases.
For the progress of Event Manager, @guantaol should be able to comment. To me, I think what you have proposed is a good enough solution to make new stack compatible with old stack, the integration of Event Manager can be a bonus item. The AsyncIO custom IO manager should be able to work with and without Event Manager.

The regression noted. After the cancellation mechanism is done, I will look into automating the performance benchmark.

IMO we should try to find what was the root cause of this regression and fix it if its possible. Do you agree? If so, could we add an issue to the gRPC board for tracking this issue? are you planning on working on fixing this regression?

Well, I think Skyscanner/grpc@996636a is a great solution that it allows old stack and new stack to co-exist and doesn't have bad performance impact. You should make it a PR.

Ok, Ill do that once the interceptors PR is done.

@pfreixes Yes, I think fixing the regression is a must, and we also need the mechanism to prevent further regression. So, it is not my top priority right now until we have monitoring (I'm on it, one of the block is credentials https://github.com/grpc/grpc/pull/21351).
Can you help me create the issue? I found I can't provide concrete data in the issue description, you might have more context than I do.

Added https://github.com/grpc/grpc/issues/21594, I would prefer to have this issue fixed before making any change like the one proposed for isolating the IO operations to an isolated loop, so if after the interceptors PR this issue is not yet fixed I will work on this first.

@pfreixes Thanks ahead for taking this task 👍

I'm planning to start coding the solution for supporting the synchronous stack on top of the Aio package Today, for circumventing the "deadlock" issue. The solution would be basically inspired by the POC that I made for having the io loop running in a separated thread [1].
Just for having all on the same page, the solution proposed would allow us to:

Run synchronous client requests on an already existing an initialized Aio environment.

The solution wouldn't provide support for:

Run the Aio package on an already initialized synchronous environment.

I'm still considering the implications of having a synchronous server running on top of an already initialized Aio environment, and most important if it does make sense. Initially, I would be tempted to not trying to give support to this use case.
Also, I'm considering on removing the need of having to initialized explicitly the Aio package by calling the grpc_init_aio function, so doing this behind the scenes when either an Aio channel or an Aio server is created. For unsupported combinations, an Exception would be raised. This theoretically would help also to close these issues [2] [3]
/cc @gnossen @lidizheng
[1] hthttps://github.com/grpc/grpc/issues/20806tps://github.com/Skyscanner/grpc/commit/996636ac853acd2ce60afbb8843181321a9915b4
[2]
[3] https://github.com/grpc/grpc/issues/19985

@pfreixes I think implicit grpc_init_aio is a good idea that prevents the application from hanging. As you suggested, we should support former case first.

@pfreixes +1 to the implicit grpc_init_aio() call as long as we have very clear error messages when a failure occurs as a result of this call.

I'm still considering the implications of having a synchronous server running on top of an already initialized Aio environment, and most important if it does make sense. Initially, I would be tempted to not trying to give support to this use case.

I don't think it particularly matters how we accomplish it in terms of implementation. The use case that we're enabling here is coexisting synchronous gRPC and asyncio gRPC in the same process. People need this in order to incrementally migrate from their existing sync stack to asyncio.
As for testing, it would be great if we could figure out a way to run all of the existing synchronous tests with something async added into the test process. Then we can be 100% sure that things are compatible. You might consider adding a new test runner for this.

good idea @gnossen, reuse the current sync tests definitely would be the way to go.
I guess that in the same idea of the Gevent test suite, where most likely we would need to disable the forking tests since for now we are not supporting forking in Aio.

This bug should be fixed by #22258.


Confusing in doc of 'OAuth2 Authentication'

Confusing

Options

{
    idField: '<provider>Id', // The field to look up the entity by when logging in with the provider. Defaults to '<provider>Id' (ie. 'facebookId').
    path: '/auth/<provider>', // The route to register the middleware
    callbackURL: 'http(s)://hostname[:port]/auth/<provider>/callback', // The callback url. Will automatically take into account your host and port and whether you are in production based on your app environment to construct the url. (ie. in development http://localhost:3030/auth/facebook/callback)
    successRedirect: undefined,
    failureRedirect: undefined,
    entity: 'user', // the entity that you are looking up
    service: 'users', // the service to look up the entity
    passReqToCallback: true, // whether the request object should be passed to `verify`
    session: false, // whether to use sessions,
    handler: function, // Express middleware for handling the oauth callback. Defaults to the built in middleware.
    formatter: function, // The response formatter. Defaults the the built in feathers-rest formatter, which returns JSON.
    Verifier: Verifier // A Verifier class. Defaults to the built-in one but can be a custom one. See below for details.
}

I wonder where should I put the above 'Options'? Is it an authentication options or an oauth2 options?
// Setup authentication
app.configure(authentication({ secret: 'super secret' })); // <-- here?
app.configure(jwt());
app.configure(oauth2({ //<-- or here?
  name: 'facebook',
  Strategy: FacebookStrategy, //<-- or here when initializing FacebookStrategy?
  clientID: '<your client id>',
  clientSecret: '<your client secret>',
  scope: ['public_profile', 'email']
}));

I found the options seems to be the settings of oauth2

I hope the doc could be clearer for newbie to read, thanks.


Create one outcome per path for Nicaragua

In order to simplify the maintenance of marriage abroad smart answers, we are going to create one outcome per path for Nicaragua.
Trello: https://trello.com/c/BqtzqHmG/738-marriage-abroad-create-one-outcome-per-path-for-nicaragua

@ikennaokpala 👍 let me know if that is ok now


I 'm working multiple API Post Requests using Insomnia. Is there a way I can save all of the responses in one go by a click of the button?

Right now I'm creating multiple API requests and each one of them has a response in the right monitor. Now to further analyse each response, I would like to copy all of them in an excel or somewhere. But I don't think there is some feature like that unless I'm missing something.

There is no supported way to do this but you could create a plugin. I haven't tested it out yet, but it looks like there might be one for this already, although it's undocumented https://insomnia.rest/plugins/@munenaga/insomnia-plugin-save-response/


Allow CODECOV_TOKEN to be passed via env

Allow CODECOV_TOKEN to be passed via env

This has been here since day 1.


[Bug]: CI nextest failed by timeout

Description about the bug
There was a case that nextest failed by timeout found on github workflow. When I reruned the code without modifing any  code, the failure disappeared.
It's a rare error that cannot be reproduced stably. And It can be either the code bug or a nextest bug.
Version
0.6.1 (Default)
Relevant log output
the failed CI: https://github.com/xline-kv/Xline/actions/runs/10003614333/job/27650819920?pr=905
the success(rerun) CI: https://github.com/xline-kv/Xline/actions/runs/10003614333?pr=905
The failed test is: curp::it server::shutdown_rpc_should_shutdown_the_cluster
There're a lot of RpcTransport(()) error
Code of Conduct

[X] I agree to follow this project's Code of Conduct

That might caused by the following:

A put client opens a thread and sends 10 Put requests one by one.
Another client proposed shutdown to cluster
The putclient waits for a response, exceeding the time limit. now the cluster may have shut down successfully, and RPC closed.
The put client retries, and gets an RpcTransport error, keep retrying. Each put request may retry 3 times, 10.5s.
each 10 put request retry for at most 105s, exceed 30s test timeout.


Changing batch size

Hello
I tried to change the batch size from 1500 to 100, since I am using different features.
The input dimension of my features are 4096 instead of your 128.
But this causes the problem of Resource exhausted. So, I tried to reduce the batch size. But now the problem is that I am getting this error
ValueError: Cannot feed value of shape (100, 4) for Tensor u'Placeholder_1:0', which has shape '(?, 14)'
Thank You in advance for the help.

hey,
i'm stuck on the same issue, did you figure it out?

Nope, I changed my implementation on keras.
I would recommend you to use that.

Thanks for the quick reply!
Can you maybe share your work?
It can help me a lot!

The ValueError you get seems like you have changed the dataset in a bad way. The shape "?" means that the placeholder can accept any size for that dimension, which is the batch_size.
Looking at the placeholders, they are defined like this:
# Graph input/output
x = tf.placeholder(tf.float32, [None, n_steps, n_input])
y = tf.placeholder(tf.float32, [None, n_classes])

So it is the "y" that you have problems with. You probably have successfully changed the batch size. However, your problem is that you have changed the "n_classes". You are now classifying on 14 classes rather than 6 classes. But you try to give 4 classes to the neural network rather than 14. Fix your input dimensions for the "y" variable.
By the way, I've tried many deep learning libraries, and for now, the best are TensorFlow, Keras, and PyTorch in my opinion, if using Python. I like TensorFlow for it to be the most popular framework. I like Keras because it's simple. But be careful, simplicity is limiting. And I like PyTorch for it enabling dynamic graphs rather than static graphs.

@guillaume-chevalier I understand the part of code where the problem occurs. Every batch doesnt take features from all the classes. So, this creates the problem training the LSTM.
If you are working with LSTMs, I would recommend to use keras since it is simpler in such case. But for other deep learning tasks you should choose the library wisely. Even CNTK and Torch can be beneficial in some cases. @ron-weiner Are you in real hurry for the code? I can upload it on next wednesday with proper documentation.

Thanks @srijandas07 , Wednesday can be great for me, I am trying to use plstm methodology in the meanwhile.
But if you don't have time for the documentary I can try to manage without.
Thanks again !

ok sure!! by wednesday, it will be uploaded and I will intimate you.
By plstm, you mean parts LSTM from NTU right?

I'm not sure what is an ntu but I plstm is phase-long-short-term-memory.
It should be a possible solution to use lstm advantages over a case with a long time span and bif amout of time steps.
Kind of a sliding window over time that in each step we implement lstm architecture.

hey @srijandas07!
happy wednesday :)
did you manage to make a progress?

@ron-weiner can you give your mail id?

@srijandas07
here:
<EMAIL_ADDRESS>Thanks!!!

Hey @srijandas07 and @ron-weiner,
I had the same issue come up. It resulted from the batch not containing every single class, which is more likely to happen with a small batch size.
One_hot in the below line then only encodes for the classes found in the batch.
batch_ys = one_hot(extract_batch_size(y_train, step, batch_size))

A quick fix that worked for me was to just check the length of the returned one_hot encoding against the number of expected classes. As this only happens when the highest numbered classes are missing you can then just pad it out with zeroes as below:
    if len(batch_ys[0]) < n_classes:
        temp_ys = np.zeros((batch_size, n_classes))
        temp_ys[:batch_ys.shape[0],:batch_ys.shape[1]] = batch_ys
        batch_ys = temp_ys

Thanks, I'll fix this issue later, probably this summer. It really looks like the one_hot function is broken with small batch sizes, take a look at how n_values is set:
def one_hot(y_):
    # Function to encode output labels from number indexes
    # e.g.: [[5], [0], [3]] --> [[0, 0, 0, 0, 0, 1], [1, 0, 0, 0, 0, 0], [0, 0, 0, 1, 0, 0]]

    y_ = y_.reshape(len(y_))
    n_values = int(np.max(y_)) + 1
    return np.eye(n_values)[np.array(y_, dtype=np.int32)]  # Returns FLOATS

harcoding n_values = 6 should fix the problem. In fact, it's already the n_classes defined above. This should work, but I didn't test it:
def one_hot(y_, n_classes=n_classes):
    # Function to encode output labels from number indexes
    # e.g.: [[5], [0], [3]] --> [[0, 0, 0, 0, 0, 1], [1, 0, 0, 0, 0, 0], [0, 0, 0, 1, 0, 0]]
    y_ = y_.reshape(len(y_))
    return np.eye(n_classes)[np.array(y_, dtype=np.int32)]  # Returns FLOATS


Halt

@swift-ci please test

The failure seems unrelated to this change.

Ping?

I'm reluctant to merge anything in while we're still trying to figure out the root cause of the CFNumber failure currently hitting CI.

I didn't realize that there were still CI issues.  Sorry for the noise (I thought they had been resolved and this was just forgotten).

I think the CI problem is cleared up now (compiler bug). I'll try this again.

@swift-ci please test


squid:S2974 - Classes without "public" constructors should be "final"

This pull request is focused on resolving occurrences of Sonar rule squid:S2974 - Classes without "public" constructors should be "final"
You can find more information about the issue here: https://dev.eclipse.org/sonar/coding_rules#q=squid:S2974
Please let me know if you have any questions.
M-Ezzat

Thanks for your contribution!
This is normally the kind of change that I'd be very happy to accept (i.e.: correctness/best practice fixes), but in this case I'm going to decline the PR.
Final classes and final methods only really need to be marked as such when it is imperative that behavior does not change in a subclass.  That's not really the case here, and I don't want to make the code less flexible for consumers of the API when it doesn't really buy us anything.
If you have other changes along these lines though, please submit them!


feat: port RingTheory.ClassGroup

Some proofs are really slow and need a  lot of heartbeats to complete (up to 600000).

Thanks :tada:
bors merge


Upgrade Kusto SDK to Latest to Avoid a Rare Parsing Issue

Hi @vplauzon, we are facing an issue using this tool to parse a long function in our Kusto cluster. After troubleshooting, found this issue is from KustoCode.Parse() call. Though can't find any release notes from that package, by upgrading the NuGet version to latest (11.5.4), the issue resolved. If you want more details, please ping me internally on Teams<EMAIL_ADDRESS>so I can share the code, thanks!

Please review this PR (https://github.com/microsoft/delta-kusto/pull/169) for this issue, thanks in advance.


Add postsubmit check for macOS

This commit add postsubmit checks for macOS. It uses our
own self-hosted Mac Mini to run the jobs.

It runs successfully after manually triggered: https://github.com/openxla/iree/actions/runs/4327020994.


Jinja2 prompt template

Feature request
WE want to store prompts files like in https://github.com/griptape-ai/griptape/tree/main/griptape/templates/prompts, e.g. https://github.com/griptape-ai/griptape/blob/main/griptape/templates/prompts/tool.j2
We want to replace our prompts (e.g. https://github.com/OpenAdaptAI/OpenAdapt/blob/main/openadapt/strategies/stateful.py#L102) with this pattern.
Let's try to use https://github.com/griptape-ai/griptape/blob/main/griptape/utils/j2.py by either importing as dependency, or copy (include attribution at the top) if necessary
Motivation
https://github.com/OpenAdaptAI/OpenAdapt/issues/365

Refer also to https://github.com/OpenAdaptAI/OpenAdapt/issues/393#issuecomment-1643936501


GIT Clone fails when i try cloning from clone repository but works when i run the same command in terminal

GIT Clone fails when i try cloning from clone repository but works when i run the same command in terminal
fatal could not create work tree dir invalid argument
below command works fine in VSCode terminal. It works fine from gitbash as well. just doesn't work from GIT CLONE bar.
git clone "ssh://user@repo"

@yogeshaggarwals, apologies for not getting back to you on this until now. As we have made several improvements in this area since the issue has been filed, I was wondering if you are still able to reproduce the tissue with the latest version of VS Code Insiders. Thank you!

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


[otbn,dv] Use clocking block to spot instruction execution

Note: This is reasonably urgent because all of our nightly tests will fail this evening if it's not merged!
This fixes a problem caused by us switching to spotting STATUS changes
on the negedge of the clock (in commit bfe59f0a8).
The problem was that you execute a final ECALL instruction or similar.
The model immediately reports that STATUS gets cleared, which is
spotted on the next negedge of the clock. Then (with some schedulings
from the simulator) we only see the ECALL instruction on the following
posedge, by which time the scoreboard thinks we've stopped execution.
This causes the check on line 290 of otbn_scoreboard.sv to explode.
Note that there's work afoot to flop the STATUS register. This problem
will go away anyway when that lands, but it seems cleaner to use a
clocking block to get rid of the race.

Note: This also fixes the otbn_reset failures that we've been seeing in our nightly tests for a few days. In those, VCS was scheduling things so that we spotted an instruction run on the following posedge. Again, it wouldn't have been a problem except that a reset hit in between and we ignored the pending instruction from the trace machinery until we came out of reset. The clocking block handles this nicely because it's "atomic": there's no way for a reset to happen between the start of the posedge, when we run the code in otbn_core_model.sv and the "end" of the posedge, when the clocking block runs.
(This note is mostly for my reference when I next get confused about what's going on!)


Import the auth plugin package for gcp

The auth plugin package for GCP isn't included not allowing Rio to be installed to GKE clusters. #234
Vendor packaging needs to be updated - unsure if this should be done as part of commit.

@bstick12 Thanks for your contribution! We use trashhttps://github.com/rancher/trash to manage go dependency internally. So if you download and run trash at the root directory of Rio project it should update the dependency for you.


C9.io npm run errors (ubuntu)

I've been using laravel with the online c9 ide for awhile now which you are most likely familiar with. All of the webpack commands will not work for some reason and this is a huge issue due to the fact this is the life line for compiling our scripts. I’m no webpack expert but hopefully this will get fixed soon. Cheers!
this is the error I get when running "npm run dev":
_$ npm run dev

@ dev /home/ubuntu/workspace
node node_modules/cross-env/bin/cross-env.js NODE_ENV=development node_modules/webpack/bin/webpack.js --progress --hide-modules --config=node_modules/laravel-mix/setup/webpack.config.js

/home/ubuntu/workspace/node_modules/laravel-mix/setup/webpack.config.js:120
let extractPlugin = new plugins.ExtractTextPlugin(
^^^
SyntaxError: Block-scoped declarations (let, const, function, class) not yet supported outside strict mode
at exports.runInThisContext (vm.js:53:16)
at Module._compile (module.js:373:25)
at Object.Module._extensions..js (module.js:416:10)
at Module.load (module.js:343:32)
at Function.Module._load (module.js:300:12)
at Module.require (module.js:353:17)
at require (internal/module.js:12:17)
at requireConfig (/home/ubuntu/workspace/node_modules/webpack/bin/convert-argv.js:96:18)
at /home/ubuntu/workspace/node_modules/webpack/bin/convert-argv.js:109:17
at Array.forEach (native)
npm ERR! Linux 4.8.2-c9
npm ERR! argv "/home/ubuntu/.nvm/versions/node/v4.6.1/bin/node" "/home/ubuntu/.nvm/versions/node/v4.6.1/bin/npm" "run" "dev"
npm ERR! node v4.6.1
npm ERR! npm  v4.1.2
npm ERR! code ELIFECYCLE
npm ERR! @ dev: node node_modules/cross-env/bin/cross-env.js NODE_ENV=development node_modules/webpack/bin/webpack.js --progress --hide-modules --config=node_modules/laravel-mix/setup/webpack.config.js
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the @ dev script 'node node_modules/cross-env/bin/cross-env.js NODE_ENV=development node_modules/webpack/bin/webpack.js --progress --hide-modules --config=node_modules/laravel-mix/setup/webpack.config.js'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the  package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node node_modules/cross-env/bin/cross-env.js NODE_ENV=development node_modules/webpack/bin/webpack.js --progress --hide-modules --config=node_modules/laravel-mix/setup/webpack.config.js
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR!     /home/ubuntu/workspace/npm-debug.log_

Update node

I had the same problem, and updating node from 4.1.x to 7.5.0 fixed it for me. (I'm now hitting a different error, but hey, that's a fix.)


Alphavantage update interval ?

While we should be getting 5 requests per minute I am getting like 5 per day instead (last updated shows few hours ago). Is that normal ?

Are you getting messages from the module via npm start dev? You should receive a console log like "Error: API Call limit exceeded."

Sorry for late reply. Could you show me your configuration about MMM-AVStock?


Make kubelet work directory overridable via single chart parameter

/var/lib/kubelet directory appears multiple times in node component
configuration. node.kubeletWorkDirectory parameter allows overriding
them all in concert, which is useful for deplyment on microk8s where
/var/snap/microk8s/common/var/lib/kubelet directory needs to be used
instead.
This is an alternative to #407. Either one can be used to solve the problem of deployment on microk8s cluster described in #406. This PR is larger but provides more streamlined user experience: only 1 string property to override instead of 4, 3 of which require structured values.

@rkrzewski
We took a look at this PR and have a concern about there is necessary to write down all volumes section if the lvmd socket path is changed. This is a similar issue to your motivation for the PR, so I think #407 is better, as well as in terms of simplicity.

#407 is indeed simpler in terms of implementation, but more complicated in usage. Helm offers path manipulation functions so generating correct mounts etc for a modified node.lvmdSocket can be implemented with little effort.
Before I delve into it I'd like to understand the requirements better
lvmd.socketName is /run/topolvm/lvmd.sock by default. The predefined volumes / volume mounts agree with the default value, but need to be overridden if the directory part of lvmd.socketName is changed. This could be improved.
node.lvmdSocket is /run/lvmd/lvmd.sock by default. It appears to disagree with default value of lvmd.socketName
lvmd-socket-dir volume for node component refers to /run/topolvm so it agrees with default socket location but disagrees with node.lvmdSocket location. It is then mounted at /run/lvmd location in the topolvm-node container. At the same time
--lvmd-socket={{ .Values.node.lvmdSocket }} is passed to the process. As long as directory part of node.lvmdSocket is not changed, it works albeit in a roundabout way.
I thought it would be more natural to set node.lvmdSocket a default value of /run/topolvm/lvmd.sock, use {{ dir .Values.node.lvmdSocket }} host path for lvmd-socket-dir volume and mount it at the same path in the container, however there is a problem: /run/topolvm path in the container is used for node-plugin-dir volume mounted from /var/lib/kubelet/plugins/topolvm.cybozu.com/node at the host. --csi-address=/run/topolvm/csi-topolvm.sock is then passed to CSI sidecar containers.
Okay, after following through the paths and mounts carefully and writing the above I have a plan for improvement. I'll add a couple more commits to PR for your consideration.

Thanks for the review @daichimukai. I have applied the requested changes.

@rkrzewski
Thank you for your update!
I confirmed that deployment-scheduler.yaml and storage-capacity.yaml  can be also updated as well as daemonset-scheduler.yaml. Would you fix them?

I've submitted the requested changes. Holding fingers crossed for the CI!
Would you like me to squash the changes before merging? There is some back-and-forth in those commits that won't provide much value from historical perspective.
There's one more thing that struck me while working with the CI manifests: there's a discrepancy between parameter names: lvmd.socketName vs node.lvmdSocket. Shouldn't the latter be node.lvmdSocketName? I realize this is a non-backwards compatible change and should be performed in a separate PR (if at all). Just wanted to put it out there.

Would you like me to squash the changes before merging? There is some back-and-forth in those commits that won't provide much value from historical perspective.

Ok. I'll notify you to ready to squash.

There's one more thing that struck me while working with the CI manifests: there's a discrepancy between parameter names: lvmd.socketName vs node.lvmdSocket. Shouldn't the latter be node.lvmdSocketName? I realize this is a non-backwards compatible change and should be performed in a separate PR (if at all). Just wanted to put it out there.

Agreed. BTW, I think this PR already breaks backward compatibility because this changes lvmdSocket value, so if someone tweaks volumeMounts, topolvm-nodes may not work properly. Therefore, I intend to release this feature as major update, I think the renaming can be done in this PR too.
@daichimukai Do you have any concerns about it?

I thought about it for a while, but I think it would be better to separate the PRs to make the intent clearer.

@rkrzewski
I have no other comments except this, please fix this and squash them.

Now the changes (with deletion of trailing white space) look good to me. I'll approve PR when a squashed commit is pushed.
I have no objection on changing node.lvmdSocket to node.lvmdSocketName in the new PR :)

I've squashed the changes to a single commit and amended the commit message. If you have any further suggestions, please let me know.

Thank you, I really enjoyed working on this :)
I'll post the PR for renaming node.lvmdSocket to node.lvmdSocketName as discussed.


Performance: Use AddRange(...) in *Controls.Children (AvaloniaList) instead of single Add(...)

Hi, this is a little performance patch :D.
This change the single Add(...) of controls to AddRange(...), because Add(...) fires for every single item the CollectionChangedEvent.
Now is bundled.

Nice! Thanks for the improvements.


Crush/Hang when using Hebrew characters in the payload field

After some highlighting text attempts, the following payload makes the app freeze (It contains Hebrew characters):
START c=node:CategoryNameIdx('name:(אחת~0.7 AND שתיים~0.7)')
return s

It is possible that the CodeMirror library (that is used to highlight the code) is crashing.
I need investigate it.

In case it could help, before you started updating the version, it didn't crash

In new version of the app I've changed the library that is highlighting the code. I tried the text you provided and it didn't crashed and displayed the text without an error. I guess it helped.
The app is in beta right now but soon enough will be released. If you'd like to try it by yourself before the release you can do it joining ARC beta program. More info here: http://restforchrome.blogspot.co.uk/2016/03/join-advanced-rest-client-beta-program.html


[OWL-ViT v2] Is the model support LoRA training paradigm?

Thank you for your great work[OWL-ViT].

I have a question, is this model capable of fine-tuning by LoRa technology to adapt to downstream other tasks while keeping the original model unchanged?
Are there any fine-tuning techniques that can efficiently adapt to downstream tasks, such as 10 categories, with 60 images in each category?

Thank you again.

We have not tried LoRA with this model but I see no fundamental reason why it shouldn't work. Please let us know how it goes if you try it!
We have had good results fine-tuning the models on small datasets. Small datasets may only require very few training steps and will over-fit otherwise, so I would do a sweep of training durations, e.g. 100, 200, 400, 800 ... steps and pick the best one.
You can also try the image-conditioned detection we describe in https://arxiv.org/pdf/2205.06230.pdf, where you get semantic embeddings for the target objects in your training images and use them instead of text queries. You can use multiple examples by averaging the embeddings for all the examples of a given category. This colab section has an example for how to do image-conditioned detection: https://colab.research.google.com/github/google-research/scenic/blob/main/scenic/projects/owl_vit/notebooks/OWL_ViT_minimal_example.ipynb#scrollTo=8-hhGqbZzVfX

Thank you for such a quick reply. My doubts have been resolved. Thank you. @mjlm

Thank you for such a quick reply. My doubts have been resolved. Thank you. @mjlm


Static Web App managed identity support

Static Web Apps support managed identity which is not mentioned in the documentation.

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

ID: 726adac9-1848-01a6-9586-842c81f820f7
Version Independent ID: 249db438-8c95-8e69-f69e-8e48fcd0b359
Content: Azure Services that support managed identities - Azure AD
Content Source: articles/active-directory/managed-identities-azure-resources/services-support-managed-identities.md
Service: active-directory
Sub-service: msi
GitHub Login: @barclayn
Microsoft Alias: barclayn

Hello @lniedzielski , thanks for taking time to share your valuable feedback! We are taking a look into this and will get back to you soon.

@lniedzielski, Managed Identity is currently not supported: #88. Let me know if this answers your question.

Hello!
Just checking to see if you have had a chance to see the previous response. Kindly let us know if it answers your question and if you need further assistance on this issue.

Hi,
I'd like to check whether we are talking about the same thing, as managed identity can be turned on for Static Web App. This is a screenshot from my tenant's portal.

Here is the link to the docs descibing connection to Key Vault using MI:
https://docs.microsoft.com/en-us/azure/static-web-apps/key-vault-secrets

Assigning to @barclayn for more insights on this.

@lniedzielski  thank you for your feedback. We are aware of the need to update the status article. We have an open internal work item to address that  but unfortunately I don't have an ETA at this time. #please-close


Initial message doesn't work

[x] Push old build up

[x] Wait

[x] Triage

[x] Fix

Fairly certain it's due to a wrong window used while querying users to send to, but I'll need specifics. It's not a bug that shows up in dev.

The bug occured on carryover from one day to the next, a value wasn't properly reset. Should be fixed now.


Removing outdated doc

What does this PR do?
Removes outdated documentation.
Motivation
Small clean of the doc.

Can you also update this paragraph? https://github.com/DataDog/datadog-agent/blob/5774f2cef7c6fd9ef734c5c39fb91db7d68586e5/docs/agent/downgrade.md#downgrade-back-to-agent-5

(let's merge as soon as the 6.12 freeze has ended)


need way to specify in that component accepts 0, 1, or many children

perhaps just 3 more macros:
expects_no_children
expects_one_child
expects_children

Rationale:  React.js has a similar mechanism...
The "children" are part of the interface of the component.  Does this component expect to receive children?  How many?
I would update the above with an :optional keyword (as in expects_one_child :optional
or we could skip it ?

Normally, I'm all for explicit declaration, but I think this one place in particular where React gets it wrong.
In React, this.props.children is an opaque data structure. React provides some top level API utilities for interacting with that data structure, but the behavior is surprising.
The name children would make you think it's always going to be a collection. But it's not:

Sometimes children is populated with many children. Like an array with multiple items.
Sometimes children is just a single child element. Not an array at all.
Sometime children is null.

This means you have to do type checking and other probing to figure out how to proceed.  Wouldn't it be less surprising if children were always an array, even if the array is sometimes empty or just a single child?
children = []
children.each do |child|
  child.do_some_thing # => with an empty array, this is skipped right over. Nice!
end

The current implementation of children fixes it by always returning an enumerable object even if it's empty. I think that's a big improvement.
Right now the params validator automatically adds a rule to optionally accept the children param. If we want to tighten this up and allow children to be represented in a declaration, we could add the ability to define the children param as required. Then there will be a warning if no children are passed.

Yes you talked me out of it.  You are right we have a more robust interface and it encourages more robust component design.  If a component takes children it should be obvious from its function (DialogBox for example would almost have to take children or would have a required React::Element type param)
And a well crafted component that takes children should act sensibly no matter if there is zero, one, or many children.
So case closed.

This issue was moved to reactrb/reactrb#102


what is the recommended replacement?

could you leave a line in the README as to what captivationsoftware is using now that is better than react-sticky, and what other alternatives have been considered?
any hints greatly appreciated.  sorry to see this orphaning out, thanks for the good work!

Not really sure what a good alternative is - if anyone has suggestions I'd be happy to update the README.
FWIW, we still use react-sticky on our projects. In fact, we exclusively use the 6.x API. The current offering is by no means broken - it works as intended, and is a very powerful, customizable lib. We simply don't have the bandwidth to keep up with user demands, especially as the React community continues to grow.
Anyway, thanks for saying thanks! Quick aside - as the core contributor of this project, it was always a little discouraging to see people's negative comments show up in issues / PRs on occasion, and that is a (small) part of the reason Captivation is turning its attention elsewhere. A helpful reminder to everyone: be considerate of the efforts of open source contributors - these are people working for free for you!

oh good, glad to hear it's still in use.
thanks again (-:

Not really sure what a good alternative is - if anyone has suggestions I'd be happy to update the README

I've been wondering whether to use React Sticky or to opt for a more lightweight solution relying more on CSS, and maybe on very little Javascript logic to coordinate the triggering of all the style changes.
I interpreted the discontinuity in the maintenance of React Sticky as a sign that more lightweight solutions were now preferred, but this conversation made me realise that it's a matter of effort.
Even in a context where the CSS rules are defined by the user and are more customised, the bits of Javascript logic should be wrapped in a component, and that will probably look like some core parts of React Sticky. That would be smaller and probably more maintainable.
Are you aware of any similar effort? While i ask, let me use the opportunity to say thanks as well, for sharing this component with all of us :heart:

The AutoAffix from react-overlays is worth a shot. I've been using it for some time, and it works well. But it's a little buggy, so I wanted to find a better alternative, and landed here - sad to see this fall out of maintenance. Will try this out over the weekend to see whether this works better than AutoAffix.

I've switched to https://github.com/gm0t/react-sticky-el - had some issues, but works like a charm now. Highly customizable and supports stick-to-bottom!

that looks promising.  thanks, we'll take a look!

https://github.com/yahoo/react-stickynode
This one is pretty nice as well, it was a really smooth transition for me.

thanks!
meanwhile we've switched to a css-only solution, and it turned out to be extremely simple (essentially, just add position: sticky to the right one or two classes) and flexible (if you need stickiness state inside react, just update it in the DOM event handlers).
now i'm wondering if there is a reason for react libraries at all.  support for old / bad browsers?

That is one reason why all of these might have fallen out of maintenance. I'm also using a css-only solution, and patching IE's implementation.


[SUPERMASSIVE_EXAMPLE] supermassive upgraded and code modified

Somewhat related, can you make sure that when we run yarn build from the root of the repo there are no unignored artefacts?

LGTM, let's merge with Eloy's suggestion.


Add the ability to choose whether to save hints from history or not

Hi! Please add checkbox to choose whether to save hints from history or not.
Additional context

Duplicate of #478.

Duplicate of #478.

This is not a duplicate. Perhaps I didn’t put it correctly - I mean the ability to completely disable or enable saving hints from the history on start page (what I googled) in the omnibox (as I noted in the screenshot) so as not to delete them manually.

Sorry. I misunderstood. That is definitely a different issue.

Can I get at least some feedback from the developer?


Freesurfer not working on NeuroDesk Trial (test server)

Hi @stebo85 ,
I tried testing out the neurodesk to use the freesurfer tool via the link you supplied and there seems to be a license issue. Do I need to add another license file as indicated ? Here is the shown error message below
ERROR: FreeSurfer license file /usr/local/freesurfer/.license not found.   If you are outside the NMR-Martinos Center,   go to http://surfer.nmr.mgh.harvard.edu/registration.html to    get a valid license file (it's free).   If you are inside the NMR-Martinos Center,   make sure to source the standard environment.   A path to an alternative license file can also be   specified with the FS_LICENSE environmental variable.

Dear @Andjelaaaa,
Yes, what you see is expected and the reason is that the Freesurfer Team does not allow a license file to be distributed and you need to apply for your own license if you want to use Freesurfer in Neurodesk.
This is described in the help when you open Freesurfer in Neurodesk:

For testing proposes you can do exactly what it says there:
echo<EMAIL_ADDRESS>> 21029
>  *Cqyn12sqTCxo
>  FSxgcvGkNR59Y" >> ~/.license

then
export FS_LICENSE=~/.license

then you can run all Freesurfer tools as expected.
Of you course instead of using my freesurfer license you need to apply for your own.
Can you please let me know if this works for you?
(make sure the license file doens't contain > in the beginning of the line!)

Thank you for your response! By following these steps, it now indeed works!


Style properties are ignored when a View is rendered with undefined backgroundColor inside of a ForeignObject

Bug
When a View is rendered inside of a ForeignObject, and its backgroundColor is not set (or set as undefined), then justifyContent and alignItems style properties are ignored.
Consider following code:
        <Svg>
          <Rect x={100} y={100} width={200} height={200} stroke='black' strokeWidth={1} />
          <ForeignObject x={100} y={100}>
            <View style={{
              height: 200,
              width: 200,
              justifyContent: 'center',
              alignItems: 'center',
              backgroundColor: undefined, // set to null (or any color) as a workaround
            }}>
              <Text>Hello World</Text>
            </View>
          </ForeignObject>
        </Svg>

Actual behavior

Expected behavior

Unfortunately I cannot check whether the issue could be reproduced on ios
Null background color (or any other real color) can be used as a workaround. Also, we use typescript in our main project, and background color does not accept null (should be casted to any as another workaround).
Here is a small project to reproduce the issue:
https://github.com/egorshulga/ReactNativeSvgIssue/tree/foreign-object-view (note the foreign-object-view branch)
Environment info
React native info output:
info Fetching system and libraries information...
System:
    OS: Windows 10 10.0.18362
    CPU: (4) x64 Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz
    Memory: 1.26 GB / 7.86 GB
  Binaries:
    Node: 12.18.0 - C:\Program Files\nodejs\node.EXE
    Yarn: Not Found
    npm: 6.14.4 - C:\Program Files\nodejs\npm.CMD
    Watchman: Not Found
  SDKs:
    Android SDK:
      API Levels: 28, 29, 30
      Build Tools: 28.0.3, 29.0.3, 30.0.1
      System Images: android-29 | Intel x86 Atom_64, android-29 | Google APIs Intel x86 Atom, android-30 | Google APIs Intel x86 Atom
      Android NDK: Not Found
  IDEs:
    Android Studio: Version  <IP_ADDRESS> AI-193.69<IP_ADDRESS>26763
  Languages:
    Java: javac 14
    Python: 3.8.3
  npmPackages:
    @react-native-community/cli: Not Found
    react: 16.13.1 => 16.13.1
    react-native: 0.63.2 => 0.63.2
  npmGlobalPackages:
    *react-native*: Not Found

Library version: 12.1.0

Ran into this and can confirm this exists and adding a background color does fix the centering. Also RIP hours fighting this...


HBASE-28420 persist the procedure's field to store on remoteProcedureDone for ServerRemoteProcedure

There is one more PR for this JIRA. Difference here in both is.
This PR has better solution for now as we should complete the procedure in execute method not while getting the completion report from RS.
But this solution is not fully compatible. While release we might face some issue if master handover happens from master with new bits to master with old bits.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
2m 31s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+0 :ok:
prototool
0m  0s
prototool was not available.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 13s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 15s
master passed

+1 :green_heart:
compile
3m 32s
master passed

+1 :green_heart:
checkstyle
0m 45s
master passed

+1 :green_heart:
spotless
0m 46s
branch has no errors when running spotless:check.

+1 :green_heart:
spotbugs
3m 44s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 11s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 57s
the patch passed

+1 :green_heart:
compile
3m 32s
the patch passed

+1 :green_heart:
cc
3m 32s
the patch passed

+1 :green_heart:
javac
3m 32s
the patch passed

-0 :warning:
checkstyle
0m 34s
hbase-server: The patch generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0)

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
5m 38s
Patch does not cause any errors with Hadoop 3.3.6.

+1 :green_heart:
hbaseprotoc
1m 11s
the patch passed

+1 :green_heart:
spotless
0m 44s
patch has no errors when running spotless:check.

+1 :green_heart:
spotbugs
3m 59s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 17s
The patch does not generate ASF License warnings.

41m  4s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5857/1/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/5857

Optional Tests
dupname asflicense cc hbaseprotoc spotless prototool javac spotbugs hadoopcheck hbaseanti checkstyle compile

uname
Linux 4c8afe4d9ef9 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 52e0a8cdaf

Default Java
Eclipse Adoptium-11.0.17+8

checkstyle
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5857/1/artifact/yetus-general-check/output/diff-checkstyle-hbase-server.txt

Max. process+thread count
83 (vs. ulimit of 30000)

modules
C: hbase-protocol-shaded hbase-server U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5857/1/console

versions
git=2.34.1 maven=3.8.6 spotbugs=4.7.3

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
2m 47s
Docker mode activated.

-0 :warning:
yetus
0m  2s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
2m 53s
master passed

+1 :green_heart:
compile
1m 22s
master passed

+1 :green_heart:
shadedjars
5m 27s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 33s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 10s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 45s
the patch passed

+1 :green_heart:
compile
1m 21s
the patch passed

+1 :green_heart:
javac
1m 21s
the patch passed

+1 :green_heart:
shadedjars
5m 24s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 33s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
0m 31s
hbase-protocol-shaded in the patch passed.

+1 :green_heart:
unit
216m 33s
hbase-server in the patch passed.

245m  6s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5857/1/artifact/yetus-jdk17-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/5857

Optional Tests
unit javac javadoc shadedjars compile

uname
Linux fa6ee54e4ee6 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 52e0a8cdaf

Default Java
Eclipse Adoptium-17.0.10+7

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5857/1/testReport/

Max. process+thread count
5842 (vs. ulimit of 30000)

modules
C: hbase-protocol-shaded hbase-server U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5857/1/console

versions
git=2.34.1 maven=3.8.6

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 20s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 12s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 32s
master passed

+1 :green_heart:
compile
1m 30s
master passed

+1 :green_heart:
shadedjars
6m  2s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 48s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 13s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m  9s
the patch passed

+1 :green_heart:
compile
1m 25s
the patch passed

+1 :green_heart:
javac
1m 25s
the patch passed

+1 :green_heart:
shadedjars
6m  7s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 54s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
0m 47s
hbase-protocol-shaded in the patch passed.

-1 :x:
unit
329m 39s
hbase-server in the patch failed.

360m 26s

Subsystem
Report/Notes

Docker
ClientAPI=1.45 ServerAPI=1.45 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5857/1/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/5857

Optional Tests
unit javac javadoc shadedjars compile

uname
Linux 0d37d865350a 5.4.0-174-generic #193-Ubuntu SMP Thu Mar 7 14:29:28 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 52e0a8cdaf

Default Java
Temurin-1.8.0_352-b08

unit
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5857/1/artifact/yetus-jdk8-hadoop3-check/output/patch-unit-hbase-server.txt

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5857/1/testReport/

Max. process+thread count
4349 (vs. ulimit of 30000)

modules
C: hbase-protocol-shaded hbase-server U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5857/1/console

versions
git=2.34.1 maven=3.8.6

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

added these changes in PR


Add example typing for "Function Module" pattern

Many node modules such as rimraf, debug, mkdirp, etc. export a single
function by default that can then be used by clients. This commit adds
an example of writing a typing for this pattern. Node module authors
will be able to look at this example and immediately understand how to
write a type defintion for their package.
Fixes #141.

Thanks!


Not available for macOS less than 10.15

The new app with the content blocker is fabulous. When I attempt to download the DuckDuckGo extension on the Mac App Store on macOS 10.13, however, it gives me an error stating that it is only available for version 10.15. Presumably this is not a necessary restriction, given that Safari 13.1 is still being updated for 10.13.

Hi @adunning, thanks for the feedback.
Unfortunately we use a UI component that is only available in macOS 10.15 or newer.
If you're interested in the code we published that today and you can find it here: https://github.com/duckduckgo/privacy-essentials-safari
Thanks!


"google is not defined"

Hi :)
I'm loving the new site so far! But sometimes the map on the frontpage doesn't load. Seems like you have a timing problem with the google maps JS file and your app.js. You probably shouldn't embed google maps with async and defer so it's always there when you want to show the map. That's just a guess though.

Feel free to create a new PR :)


Use shared memory to store temporary computation results

Allocate buffer and store computation results there

Couldn't make faster


Openebs not deleting old pods

Deleting a dynamic PVC of openebs-jiva-default class does not empty the pods in openebs namespace.

Hi @turowicz
Sorry what do you mean by not deleting the pods?  Thanks.

@balchua
When I create a pod with an OpenEbs storage requirement, except for the PVCs, microk8s also spins up pods on each node. These pods remain even after the deployment has been deleted and I need to go through them and delete them manually.

Oh that, you can ask the openebs folks about it. But may also be intentional to do so, openebs cannot assume that deleting a deployment means it doesn't need the data anymore.
I am going to close this issue for now.


Fix Dependencies Missing from DependencyManagement

Based on the report, we seem to have many cases where we have dependencies in use that are not managed by the Parent POM dependencyManagement section. We should resolve these, and then modify the dependency checker tool to emit a nonzero exit code when any inconsistency is detected.

Considering the work that @mitchdenny and @JimSuplizio have done on this, I think this issue is obsolete.

@kurtzeborn @bsiegel @mitchdenny
Yes, with the centralization of external dependencies and removal/disallowing of dependencyManagement sections in POM files, the dependencies are in a much better state.


Move initialization code from main.go to the registry package

This makes it easier to embed a registry instance inside another
application.
Related to #215.

I realize this will be a little hard to review because of the code movement. The main change to the code is the addition of the Registry object and its Serve method. Also, a few things were changed to return errors instead of panicing or logging with Fatalf.

@aaronlehmann I thought the idea was to have the entire main command move into this package. I thought the idea was to support a MainCmd that can be import from registry. I'm not opposed to this move, but I am reticent about adding a new object call Registry.

I was thinking that adding cobra support could be a followup PR.
That said, now that I think about it some more, it would be quite useful to expose a complete main function in the registry package (for people implementing new storage drivers and such out-of-tree).
What about splitting NewRegistry into NewRegistryFromConfig and NewRegistryFromConfigFile? The latter would incorporate the config file parsing. When we add a cobra Command struct, its Run function would be a small wrapper around NewRegistryFromConfigFile.
Registry may be a bad choice of name - do you have any suggestions?

What about splitting NewRegistry into NewRegistryFromConfig and NewRegistryFromConfigFile? The latter would incorporate the config file parsing. When we add a cobra Command struct, its Run function would be a small wrapper around NewRegistryFromConfigFile.

Let's just have NewRegistry. Parsing a configuration file is easy. If you need it all together, use the main command. If not, parse it yourself, it is easy.

Registry may be a bad choice of name - do you have any suggestions?

I actually like the name. Changed my mind.

Added the cobra command and changed main.go to use it.

@ncdc PTAL. You may like what we're doing here.

Thanks, I'll be back Monday and can look then.
On Thu, Aug 20, 2015 at 7:48 PM Stephen Day<EMAIL_ADDRESS>wrote:

@ncdc https://github.com/ncdc PTAL. You may like what we're doing here.
—
Reply to this email directly or view it on GitHub
https://github.com/docker/distribution/pull/909#issuecomment-133213122.

Looking good so far! I'll do a more thorough review next week.

@aaronlehmann @stevvooe this may be the wrong place to discuss this, but I'd like to make sure that the appropriate extension points exist for being able to do a couple of things we've hacked into OpenShift's vendored copy of docker/distribution:

Add custom routes to the http handler (e.g. we added /healthz)
Add custom access records for the custom routes
Get access to the various storage backend paths so we can do pruning

In our vendored copy, we hacked in some custom routes to support deleting blobs, layer links, and repos. We're looking at refactoring our pruning a bit, so we won't need the custom routes, but we'll still need to be able to hard delete the blobs, layer links, and repos that we've identified for pruning.
If there's a better place to hash this out, please let me know. Thanks!

@ncdc This is an appropriate venue for that discussion but this PR is more of a stopgap on the way to that story.
@aaronlehmann Could you ensure we have captured these requirements in the description of #215?

Most of these are captured in https://github.com/docker/distribution/issues/215#issuecomment-106348220. I added a comment about access to backend storage paths.

Looks like we would not be able to merge this PR because of merge conflicts. Please rebase, fix conflicts, and force push to your branch.

Moved the debug server to the cobra command, and changed the Serve function to ListenAndServe (it will now create the listeners).
I appreciate all the other feedback. These seem like good ideas. I think it's best to merge this incremental step, and then improve on it.

LGTM

LGTM


Homepageview #63

Current coverage is 57.54%

Merging #77 into master will not affect coverage as of 0730bfc

@@            master     #77   diff @@
======================================
  Files           13      13
  Stmts          179     179
  Branches         0       0
  Methods          0       0
======================================
  Hit            103     103
  Partial          0       0
  Missed          76      76

Review entire Coverage Diff as of 0730bfc

Powered by Codecov. Updated on successful CI builds.


⚠ HawkeUno has degraded performance

In cf9bb46, HawkeUno ($UNO) experienced degraded performance:

HTTP code: 403
Response time: 4866 ms

Resolved: HawkeUno performance has improved in 7c43835 after 25 minutes.


Bookmarks are not persisting

Hey @chentoast thanks for the awesome plugin.
I have been playing around with this today and really find this useful, I was trying out the bookmarks feature although bookmarks are being set correctly, as soon as I am closing neovim they disappear. which I believe is not intended and probably something wrong on my end.
Can you please share some tips to point me in the right direction.
I am on Neovim 0.10 and so far I have tried using both set_bookmark_1 and toogle_bookmark_1 methods with lua.

Have noticed the same issue. It's not stated in docs that they should persist but I really wish they would.

Unfortunately, bookmarks do not persist in neovim instances. File marks (upper case and numbered marks) are saved by neovim, but there is no way to stash custom plugin data in the shada file containing the mark data.
The solution would be to serialize bookmark data in some other file, but there should be some thought into how it's implemented, i.e. how to update bookmarks when file paths are changed, whether loading in bookmarks also loads in the buffers, or how to only load in a set of bookmarks when in a specific directory. It might not be high priority for me since I wouldn't use bookmarks like that, but PRs are totally welcome.

@chentoast I'll try to dig into this then, will open up a PR if I get it working

Hmm. Questionable to call them bookmarks if they're ephemeral. Bookmarks stay put when you put down the book for coming back to them later. That's their entire function...
Also if marks are persistable out of the box it would be nice to be able to add annotations to regular marks too. But i guess we'd run into the same issue of needing a way to actually make that work.


Add documentation for syntax nodes and their children

As part of #1528, documentation needs added to some syntax nodes. This PR adds documentation to the following syntax nodes and their children:

AssociatedtypeDeclSyntax
ClassDeclSyntax
ImportDeclSyntax
IsExprSyntax
ProtocolDeclSyntax

@ahoppen Thanks for the quick feedback! I've added in your suggestions.

@swift-ci Please test


Undefined is not an object (evaluating '_reactNative.Keyboard.addListener')

I get this error when I try to use
Happens with native-base ^0.5.4
and react-native: 0.26.1

Which component is causing this error?

the Content component

Do you have a code sample? Something we can try? Also it is recommended that you use the later versions of react-native with native-base. If upgrading from 0.26 is not possible, please consider using older versions of native-base (0.4.*)


Add segment counts to network statistics

What does this PR do?
Adds segment (packet) counts to network statistics.
Additional Notes
Only implemented in runtime-compiled
At present, when using precompiled bpf programs, the statistics are always zero.  It was proposed that we would not implement on statically compiled.
In order to implement for static-compiled, would need to do the offset computation for the TCP field of the TCP sk-buf that's used for calculation.  (UDP uses a different method, but is still left unimplemented for consistency)
UDP considerations.
The method used counts successful send/recv calls.  Since UDP is datagram based, each successfully sent packet represents a datagram that was sent/received.  This will have two potential problems.

In the case where the stack successfully receives a packet, but later discards before the application can consume the packet, the packet will not be counted.  We will count only packets received by the application, not the host/stack
In the case where a datagram is fragmented, a single large datagram will be counted as 1 instead of N (where N is the number of packets that the datagram was fragmented into).

still TODO
Update for windows as well.
Describe your test plan
Write there any instructions and details that should be tested during the QA.

Redone as https://github.com/DataDog/datadog-agent/pull/8067


Implement ftp file listener in Ballerina

Purpose
Implement ftp file listener in Ballerina by using ftp module.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

These guides were updated in the PR https://github.com/wso2-ballerina/module-ftp/pull/54.


warn user if specified sync-mode does not match expected values

For example, this command starts a fast sync
besu --sync-mode="bogus"
as does this
besu --sync-mode="-XSNAP"

Hi , i would like to work on this issue. Would you guide me a bit more on what needs to be done?

The help text in BesuCommand tells exactly what the options are.
      --sync-mode=<MODE>     Synchronization mode, possible values are FULL,
                               FAST, X_SNAP (default: FAST if a --network is
                               supplied and privacy isn't enabled. FULL
                               otherwise.)

If something else is specified, I would like a warning message similar to what you get if you specify a network name that's not in the list eg:
besu --network=bogus
Invalid value for option '--network': expected one of [MAINNET, RINKEBY, ROPSTEN, SEPOLIA, GOERLI, KILN, DEV, CLASSIC, KOTTI, MORDOR, ECIP1049_DEV, ASTOR] (case-insensitive) but was 'bogus'

So something like:
"Invalid value for option '--sync-mode': expected one of ... but was '...'"

Hi @macfarla I've added a PR for this issue. (https://github.com/hyperledger/besu/pull/4017)
This is my first contribution to the project.
Please let me know if I've missed anything.


Position of Background of Slider Doesn't Update when Volume Buttons are used

Need to Have Volume Buttons update CSS just like dragging the slider does.

Ended up removing the volUp and volDown buttons for a mute/unmute toggle. Problem therefore is nonexistent and resolved
However the problem was present when I created the seek bar. To solve this I needed to add a new property to the seekbar input element. I called this 'getValue'  and  used a getter and setter. Using get: and set: I was able to mimic for all intents and purposes, a variable change event listener. Using this I could have the background update whenever the 'getValue' property was changed. the GetValue property would then run a function which changes the 'value' property to the same number entered into 'getValue' and would also run the function which updates the background of the range input.
Object.defineProperty(seekRange, 'getValue', {
    get: function() {
        return value;
    },
    set: function(value) {
        seekRange.value = value;
	melodiiBtns.animateSliderBg(null, false, seekRange);
    }
});


Bringing the package up to speed with newer versions of Haskell

Is there any chance we could have an upgrade of this 6 year old package so that it works with the latest version of Haskell and Hackage?

I wasn’t aware there was anything broken. It works fine for me with GHC 8.6.5 and GHC 8.8.1 (with a handful of harmless build warnings). What specifically isn’t working for you?

Hmmm, I'll try again and let you know. It might be a problem with my Haskell setup (although I use an updated version of Haskell from Homebrew).

“Doesn’t work” is never an actionable report, but if you can provide any information about what went wrong, including the commands you ran and any error messages you got, I’m happy to see if I can help.

Will do when I get a minute. Thanks. Just to be sure, if you take a reasonably recent version of Haskell, the library "just works" for you? Because if that's the case I should debug on my side before I report back to you.

 You are welcome to debug yourself or ask for help here—but to help you I’ll need to see more than zero information about what went wrong.

Ok, thanks. (And apologies for reporting a problem the way my students do it to me.)


setOpacity of Image undefined

V: 3.8.2
In the debug version I can use setOpacity of Image (which sets "opacity_") but in the min version, it's undefined (I have to set "v")
ol.style.Image.prototype.setOpacity = function(opacity) {
  this.opacity_ = opacity;
};

setOpacity is not part of the API currently: http://openlayers.org/en/v3.8.2/apidoc/ol.style.Image.html so it gets minified /renamed in the production build.
Anybody see any reason not to add it to the API?

+1 for adding setOpacity to the API.

thanks @ahocevar I'll attach a PR then.

PR attached

Thanks. Please merge when Travis says so.


crash in latest commit

I have no idea what the crash actually means so I've attached the crash report
crash-2021-01-13_13.47.07-server.txt

I think it was fabric api

I think it was fabric api


feat(tidb): enable trigger for tidb pull-integration-e2e-test

Enable trigger for tidb pull-integration-e2e-test.

The test has been running stably for three weeks. Check the link https://prow.tidb.net/?repo=pingcap%2Ftidb&type=postsubmit&job=pingcap%2Ftidb%2Fmerged_integration_e2e_test

/cc @bb7133

/hold
wait for review

/unhold
Already communicated and confirmed with the owner.


Upload-only import into Chef 12 fails when default organization isn't set

When performing a manual upload into Chef server 12 using the command chef-server-ctl chef12-upgrade-upload -e <data_path> -o <org_name> -u
After all the data has uploaded, the following error occurs:
WARNING: Skipping user ACL update. To update user ACLs, remove --skip-useracl or upgrade your Enterprise Chef Server.
Open source Chef 11 server data successfully uploaded to Chef 12 server
INFO: Using configuration from /tmp/knife-ec-backup-config.rb
INFO: Starting RBAC Permissions Update
INFO: Fixing Permissions for Clients on Node Objects
INFO: HTTP Request Returned 404 Not Found:
ERROR: The object you are looking for could not be found
Response: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-sransitional.dtd">

  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />
  <title>Chef - 404 Not Found</title>
  <link media="all" rel="stylesheet" type="text/css" href="/css/all.css" />

      Chef

404 - Not Found

Sorry, I can't find what you are looking for.

        © 2010 – 2014 Chef Software, Inc. All Rights Reserved

Failed to update permissions for migrated organization.

This happens when the default_organization is not manually set in chef-server.rb due to the code which sets this default option being bypassed for upload-only commands in https://github.com/chef/opscode-omnibus/blob/master/files/private-chef-ctl-commands/chef12_upgrade_upload.rb#L77

Closing this since Chef Server 11  is  EOL'ed.


Bug: SingleFile method fail (run forever) with new Chromium versions (121.0.6167.139-1~deb12u1) on Debian 12

Describe the bug
SingleFile method fail with new Chromium versions. The issue is here since less than 2 month I think.
I'm on a Debian 12.6 (aarch64) with Chromium version 128.0.6613.84-1~deb12u1.
If I downgrade Chromium to version 121.0.6167.139-1~deb12u1 everything works as expected.
So maybe something changed in Chromium causing this issue.
Steps to reproduce

Ran ArchiveBox with a config allowing SingleFile method with Chromium version 128.0.6613.84-1~deb12u1
Add a webpage to snapshot (via CLI or webUI)
Watch Chromium running forever without exiting and the webUI go 404
Kill Chromium process
Downgrade chromium (and chromium-common of course) package to version 121.0.6167.139-1~deb12u1
Add the same webpage to snapshot
Watch Chromium running for less than a minute and the page is successfully snapshoted

Screenshots or log output
The errors.log don't show anything.

We are using an older version of singlefile (1.5.x) that is no longer supported, it's likely fixed in their more recent 2.x.x releases.
The reason we haven't already updated to 2.x.x. is because single-file-cli switched from using node to deno, so it requires a lot of work (currently ongoing in the v0.8.x dev branch) to adadpt ArchiveBox's packaging system.
If the old singlefile is now failing that means I now have added urgency to finish this work!

Actually I noticed in your log that you're using an even older version of singe-file instead of the latest known good version 1.1.54. You should try updating to a slightly newer version first:
cd /data/1/webarchive/archivebox

npm install<EMAIL_ADDRESS>

Oh you're right, I forgot to update node dependencies!
Running archivebox setup again fix the issue with Chromium 128.0.6613.84-1~deb12u1.
Thanks for your help.
Feel free to close this issue if it's not relevant anymore.


CSS prefixes order fixes & 'suffix' output argument support in Multicolor control

Property without prefix should be at the end
Before/after:
  - - - ->

suffix support in multicolor control is needed to be able to append !important to color value (and maybe for something else)

good catch...
Merged.
Thank you!


Questionable links

The URL docs.microsoft.com/en-us/archive/blogs/jimoneil/http-301-this-is-no-longer-the-blog-you-were-looking-for contains URL links/directs to questionable site (maybe it was okay at the time).

@ll3v3ll Thank you for letting us know! I've asked the appropriate team to remove that page/link.

The page has been taken down. Thanks again for alerting us!


[Bug] Document web is dead

Get Started with MLC-LLM
Please check our documentation to start the journey with MLC-LLM.
this link can't be opened.
https://mlc.ai/mlc-llm/docs/get_started/try_out.html

We confirmed that the page is alive. If you’re in China then the documentation page is banned by GFW though, unfortunately.

We confirmed that the page is alive. If you’re in China then the documentation page is banned by GFW though, unfortunately.

well... that's a pity.. thank you.
BTW, I notice that masahi have some commits from FasterTransformer llama int4 repo, do you know where the repo is?  Thank you!

BTW, I notice that masahi have some commits from FasterTransformer llama int4 repo, do you know where the repo is?

Sorry I’m not sure actually. Are you referring to the FastTransformer int4 quantization offloading? If yes you may check out https://github.com/mlc-ai/mlc-llm/pull/661.

BTW, I notice that masahi have some commits from FasterTransformer llama int4 repo, do you know where the repo is?

Sorry I’m not sure actually. Are you referring to the FastTransformer int4 quantization offloading? If yes you may check out #661.

Seems yes,  I'll check it . thank you!