Start-MDATPIsolation errors on DeviceName when using DeviceID

Describe the bug
Using the Start-MDATPIsolation command with a specified DeviceID errors out when tryign to get a device name. This occurs with or without the -whatif switch.
MetadataError: C:\Users\(install location)\Documents\WindowsPowerShell\Modules\PSMDATP\1.0.0\PSMDATP.psm1:3225
Line |
3225 |          $DeviceName = $DeviceName.ToLower()
     |          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | The variable cannot be validated because the value  is not a valid value for the DeviceName variable.

VERBOSE: GET https://api.securitycenter.windows.com/api/machines with 0-byte payload
VERBOSE: received 4711333-byte response of content type application/json
VERBOSE: Content encoding: utf-8
What if: Performing the operation "Start Isolation: Full" on target "".

To Reprodce
Run a command like the below(occurs when not using -whatif switch):
Start-MDATPIsolation -DeviceID $ID -IsolationType Full -WhatIf
Desktop (please complete the following information):

OS: Windows 10
PSVersion 7.1.1

Additional context
Using version 1.0.0

Hello @RedLee3 , thanks for brining this up, I will look into this and fix it with the next update of the module.

Hi @alexverboon
I think this issue is also affecting Remove-MDATPDevice as well

Happy to test any pre-release if you need to. I wanted to clean up some devices on my estate that were test devices and can't be removed other ways. Your bundle looks to be useful and easier to use.

@alexverboon
I've fixed Remove-MDATPDevice under pull request 4) and from looking at Start-MDATPIsolation looks like the same fix tactic would work for that too. I'll submit another pull request for that file and update accordingly.


Fixed #43 : Added support for sharex & sharey params

Coverage decreased (-0.5%) to 86.957% when pulling 569c751c7ff6bb064aecb53ca341c52b53ec7d2d on ojasvajain:master into bf449b7db8b6966bcf95a0280bf2e4518f3e2419 on gtnx:master.


No Longer Works

Describe the bug
The crate no longer works with Firebase Auth
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Additional context or information
Add any other context about the problem here.

Could you give a more detailed description of "no longer works"?

Also, sorry for the less detailed description as at that time of creating the issue, I was kinda frustrated

I suspect it is that the encoding method for the currently firebase base64 has changed as in base64 to txt too, the hashes and salts doesn't work at all

Yeah, looks like it... I don't have much time to research right now, but if you make any findings feel free to make a PR or to post them here :)

Also, sorry for the less detailed description as at that time of creating the issue, I was kinda frustrated

Don't worry about it, we're here to help each other and learn

@Techie-Pi Actually I fixed it, Making a PR

Reopening until I publish the new version

Done: firebase-script 0.2.1
Thank you very much for your help! 😄


Core review to Liam's code

:tada: This PR is included in version 2.0.0 :tada:
The release is available on:

2.0.0
GitHub release

Your semantic-release bot :package::rocket:


Improve JSchema component descriptions handling

Up to 87869e191856dda8b6073aab1b9f637c6d618978, it all looks good (still missing the description info button though):

Looking for feedbacks on wether the info icon is looking good placed where it is right now.

Looking for feedbacks on wether the info icon is looking good placed where it is right now.

It does, for me.
Maybe the popover box can be a bit wider?

This is great! =D
Regarding width: That is probably one of the largest descriptions shown above. For most descriptions, it will be shorter. Not against it being a bit wider though where possible & useful.

I tested this branch myself now.
It's a big improvement, makes the interface look much cleaner! And I like their behavior on showing on click, but disappearing when I click anything else.
I don't think we need the title "Argument description". Can we just drop the title, have only the description text?
And I agree they could be a bit wider. @rkpasia Can we make them 30% wider?
After that, let's merge this into main. I think it's a much better experience than showing the full description text and I'd like to deploy this version in both places :)

The latest changes dropped the popover title and allowed the popover to span until 500px wide.
That's roughly 40% more than before.
I think we could close this one 👍🏼

This is 🎉
Thanks @rkpasia !


Two Nukies On High Pop

Description

Two rounds on Lizard had 60~ and 80 pop where there were only two nukies that spawned.

issue should be solved by https://github.com/space-wizards/space-station-14/pull/28327

we can make it if we try!


Fix/misc graph stuff

Here are some enhancements, especially for the find_path_triangulation function (mostly about removing code not needed and about improving readability).
@cducrest That's why I like you to review it.

Codecov Report

Merging #210 into develop will decrease coverage by 0.04%.
The diff coverage is 91.66%.

@@             Coverage Diff             @@
##           develop     #210      +/-   ##
===========================================
- Coverage    61.03%   60.99%   -0.05%
===========================================
  Files           43       43
  Lines         2926     2925       -1
===========================================
- Hits          1786     1784       -2
- Misses        1140     1141       +1

Impacted Files
Coverage Δ

relay/network_graph/graph.py
73.38% <100%> (ø)
:arrow_up:

relay/network_graph/dijkstra_weighted.py
89.51% <88.88%> (-0.77%)
:arrow_down:

Continue to review full report at Codecov.

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


Closed app before mp4 was saved and I lost it

I recorded a video and after I picked where to save it I closed the app since I wasn't going to record another video for the moment but I lost the first one because it takes some time to save the mp4 file. Maybe this could be fixed by just showing the save progress or something like that, not sure, but just wanted to report the issue.
Thanks

Thanks will get it asap.

Added a save indicator in 1.1.2


docs: document how to set up Tekton with Pipeline promotion events

What changed?
An extra page added to the documentation website on how to set up pipeline notifications to trigger a Tekton pipeline.

Why was this change made?
Document a feature.

How was this change implemented?
Created a new file

How did you validate the change?
Checked the page with yarn start

Release notes
NA

Documentation Changes

Could you summarise at the start what the outcome is? What do they expect to see on their cluster, their gitops repo, the wego UI, etcetc

I have no idea, other than:

At the end a Tekton Pipeline will be started on Weave GitOps Pipeline promotion events.

but that's kind of the title itself.


Issue #16: Added wordWrap in var style, and added object descriptions in json

Added descriptions to objectselection.json, added text word wrap to style in main_text.js, and altered font color.

Thanks!


Zero123: Adds lambda_normal, changes depth to rel_depth

data/image.py : Adds reading of normal image, and a lambda_normal for ref loss
Changes depth loss computation to use pearson coefficient, like in stable-dreamfusionhttps://github.com/ashawkey/stable-dreamfusion/blob/f1531ea9df793d9f7a6f8c1cad48efae73ab4803/nerf/utils.py#L577

We could decide to specify either computation of depth through an arg, open to suggestions!

I'm trying to understand the use of remove_key here. Is it because the returned ground truth normal value has the same name as the estimated normal?

Yes! geo_out and kwargs will both have normal as a key.

Could we rename the value returned by the dataset to ref_depth and ref_normal?

Could we rename the value returned by the dataset to ref_depth and ref_normal?

Sure, great idea!

@bennyguo Done!

About which depth loss to use, how about making them two losses which are controlled by two lambdas? Also we need to add torchmetrics to the requirements.

@bennyguo Done. I had to make a few other changes to accommodate this:
I moved C from utils/misc to utils/config.

Great! But may I ask why we should move C? Is it because C should stay with C_max?

@voletiv have you run a few experiments with that new code vs the previous, to confirm that changing these loss terms (e.g. using pearson) produces better or equivalent results? Once you do so, please post them in the description on top. Thanks!

@bennyguo Restored C


(WIP) External wallet: showing networks that user disabled

Checklist

[x] I have read the CONTRIBUTING guide
[ ] Good naming (as clear and simple as possible)
[ ] Correct behavior if external API endpoints are down, return 404, 504 (or no answer), 401 errors (ddos simulation)
[ ] I tested desktop/mobile resolution
[ ] I tested light/dark theme
[ ] I tested different languages
[ ] I checked the functionality once again (AFFECT MONEY)
[x] I checked the work on the Testnet
[ ] I checked the work on the Mainnet
[ ] I checked the work in the plugin
[x] I checked the PR once again

Tests
Please start auto tests as follows:

add a label swap test to start swap tests
add a label withdraw test to start withdraw tests

You can skip these tests if you completely sure that your changes aren't related to this functional
Original issue
#4817
Video / screenshot proof

builded https://testnet4820.swaponline.site ;

commit 9fc42198c rebuilded https://testnet4820.swaponline.site https://mainnet4820.swaponline.site

commit f7b0c4f52 rebuilded https://testnet4820.swaponline.site https://mainnet4820.swaponline.site


Doesn't detect failed replication controller/deployment configuration

Create example DC with:

https://paste.fedoraproject.org/350947/60028840/

Deploy DC, oc get -o yaml rc:

https://paste.fedoraproject.org/350950/60028895/

Status of pod, oc get -o yaml pod:

https://paste.fedoraproject.org/350952/28958146/
==>
As result, we think that RC is running, but pod inside RC is not running.
How do we can detect that DC not running and don't start the next build steps ?

In other words, why we don't subscribe to event of pod status ?

@livelace the "Verify OpenShift Deployment" step currently stops after seeing the RC go to Complete, but after seeing you scenario, I realize it could do better.
I'll start looking into including a monitor of the deploy pod status into that step's logic (perhaps the other deploy related steps as well - we'll review).
@bparees - FYI

@livelace perhaps you could use the http check step to confirm the pod is running?  or a readiness check in your DC that confirms the pod came up (which will block the deployment completion).

@bparees My service is not HTTP capable, I thought about this.
My case:

First build step - start service1.
Second build step - start service2.
I want to start third build step, which depend from 1/2. I get problems:

a) I don't know that service1 and service2 is up and running and all hooks completed. I can't stop Jenkins tasks, because I think that is all right.
b) I can't scale deployments to zero at the proper time, because I don't know that all tasks inside pods are completed.
I can't properly manage tasks, because I don't know about states of tasks.

Not to overly distract from this thread but I should have deployer pod
state verification working either later today or tomorrow.
On Thursday, April 7, 2016, Oleg Popov<EMAIL_ADDRESS>wrote:

@bparees https://github.com/bparees My service is not HTTP capable, I
thought about this.
My case:

First build step - start service1.
Second build step - start service2.
I want to start third build step, which depend from 1/2. I get
problems:

a) I don't know that service1 and service2 is up and running and all hooks
completed. I can't stop Jenkins tasks, because I think that is all right.
b) I can't scale deployments to zero at the proper time, because I don't
know that all tasks inside pods are completed.
I can't properly manage tasks, because I don't know about states of tasks.
—
You are receiving this because you were assigned.
Reply to this email directly or view it on GitHub
https://github.com/openshift/jenkins-plugin/issues/33#issuecomment-207021179

@gabemontero It will be great!

@gabemontero deployer pod state, or just pod state?

@bparees I'll look for both to a degree.  Testing shows the deployer pod is
prunned minimally if successful.  So I'll first see if we have a deployer
pod in a non complete state.  If a deployer pod no longer exists, I'll
confirm that a running pod  exists for the correct gen of the deployment.
On Thursday, April 7, 2016, Ben Parees<EMAIL_ADDRESS>wrote:

@gabemontero https://github.com/gabemontero deployer pod state, or just
pod state?
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/openshift/jenkins-plugin/issues/33#issuecomment-207037780

the replication controller (deployment) ought to reflect the state of the deployer pod, so i don't see the value in looking at the deployer pod.

I have not seen that yet at least on what i was previously examing from the
output provided and my duplication with the evil post start hook but I'll
double check when i get back to the office.  The deployment phase still
said complete.
On Thursday, April 7, 2016, Ben Parees<EMAIL_ADDRESS>wrote:

the replication controller (deployment) ought to reflect the state of the
deployer pod, so i don't see the value in looking at the deployer pod.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/openshift/jenkins-plugin/issues/33#issuecomment-207041360

Yep, at least with the latest level from upstream origin, @bparees is correct wrt the RC being sufficient.  Adding the same the same lifecycle: postStart sabotage, the RC ends up in Failed state per the deployment.phase annotation on the RC.  I think my earlier repo did not go far enough or something.  Could have swore I saw it go to Complete, but I now consistently see it go to Failed after several runs.
So we are either at two spots @livelace :

you could try adding a "Verify OpenShift Deployment" step and hopefully you see the same results
if your output at https://paste.fedoraproject.org/350950/60028895/ was in fact captured after the Pod failed, then I suspect your version of OpenShift is far back enough from the latest were you are seeing a difference in deployment behavior (certainly that component has evolved some this last release cycle).  If that is the case, it may be simply a matter of when you can upgrade.

Not working:

[root@openshift-master1 ~]# oc version
oc v1.1.6
kubernetes v1.2.0-36-g4a3f9c5

Jenkins console output (verbose mode), job with verification, job completed without any errors:

https://paste.fedoraproject.org/351461/91294146/

RC status:

https://paste.fedoraproject.org/351462/46009139/
[root@openshift-master1 ~]# oc get rc
NAME                                        DESIRED   CURRENT   AGE
testing-11.0-drweb-netcheck-nossl-peer1-1   0         0         17h
testing-11.0-drweb-netcheck-nossl-peer1-2   1         1         16h
testing-11.0-drweb-netcheck-nossl-peer2-1   0         0         17h
testing-11.0-drweb-netcheck-nossl-peer2-2   0         0         16h
testing-11.0-drweb-netcheck-nossl-peer3-1   0         0         17h
testing-11.0-drweb-netcheck-nossl-peer3-2   0         0         16h

Pod status:

https://paste.fedoraproject.org/351463/46009150/
http://prntscr.com/apk3ey

NAME                                              READY     STATUS             RESTARTS   AGE
testing-11.0-drweb-netcheck-nossl-peer1-2-6zkg7   0/1       CrashLoopBackOff   14         1h

"Verify whether the pods are up" in settings will be  enough :)

@livelace I'll see if I can pull a v1.1.6 version of openshift and reproduce what you are seeing, but at the moment, it appears that we are falling into category 2) from my earlier comment.  If that does prove to be true, than rather than adding the new step, we'll want you to try the existing step against v1.2.0 when it becomes available (that is the "latest version" I was testing against).

@livelace - one additional request while I try to reproduce at a lower level of code - when you reproduce, is the equivalent of the testing-11.0-drweb-netcheck-nossl-peer1-2-deploy pod from your last repro staying around long enough for you to dump its contents to json/yaml ?  If so, can you provide that as well (assuming you'll need to reproduce again to do so)
thanks

ok, I went to the same level as @livelace and could not reproduce.  One additional question did occur to me ... do you create a successful deployment, the scale it down, edit the DC to introduce the
       lifecycle:           postStart:             exec:               command:               - /bin/sh               - -c               - exit 1
and then scale to 1 and verify deployment?

@gabemontero Hello.
No, DC has hooks from the beginning.

After creating "DC" has zero count.

Creation progress - https://paste.fedoraproject.org/351916/14601346/

Error - https://paste.fedoraproject.org/351917/60134739/

After error occur I can scale down DC and to repeat all again.

I can modify script (exit 0) that runs inside hook and all be fine with DC (without any modification of configuration).

On Fri, Apr 8, 2016 at 12:58 PM, Oleg Popov<EMAIL_ADDRESS>wrote:

Creation progress - https://paste.fedoraproject.org/351916/14601346/

Hey @livelace - not sure what you mean by "creation progress".  I just see
another Pod yaml for a Pod created by a replication controller.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/openshift/jenkins-plugin/issues/33#issuecomment-207515537

"Creation progress" - scale DC to 1.

Thanks for the additional details.  I have a couple of thoughts on
reworking my repo attempts.  I'll report back when I have something
tangible.
On Fri, Apr 8, 2016 at 1:34 PM, Gabe Montero<EMAIL_ADDRESS>wrote:

On Fri, Apr 8, 2016 at 12:58 PM, Oleg Popov<EMAIL_ADDRESS>wrote:

Creation progress - https://paste.fedoraproject.org/351916/14601346/

Hey @livelace - not sure what you mean by "creation progress".  I just see
another Pod yaml for a Pod created by a replication controller.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/openshift/jenkins-plugin/issues/33#issuecomment-207515537

During hour I can grant access to my test environment, I think.

@gabemontero Do you can connect over SSH to my environment ?

OK, I've reproduced it.  I did:

before starting a deployment, added your lifecycle/podstart with exit 0
deployed, then scaled back down to 0
edited the DC, changing lifecycle/podstart to exit 1
scaled to 1 ... Pod fails, but next gen of RC says it completed successfully.

Note, if I start with the lifecycle/podstart exitting with 1 and initial replicas of 1, then the RC is marked as failed.  This is basically what my recent repo attempts did.  And now that I understand what is going on, I'm pretty positive that my very first repro attempt, where I saw the RC in complete state, was when I edited a previously used DC to added the lifecycle/podstart with exit 1 check.  So good for me that I was not imagining things originally :-).
Now, what to do about this.  It is not a given we want to address this with a new plugin step.

this could be a deployment bug that needs to get addressed, with the RC reflecting the state of the pod
the nuance of updating a DC which has been deployed one way, scaled down, editted, and redployed though could be "against current design" or some such.
certainly the lifecycle/podstart induced failure is merely a means for producing an unexpected container  start up failure, but are there some nuances wrt using that to tank the container, where a container dying on startup "naturally" will have different characteristics

@bparees:  thoughts?  ... and I thought about tagging our friends in platform mgmt now, but decided on getting a sanity check from you before officially pulling that trigger.

I'll try the exit 1, but initial replicas 0 permutation, then scale to 1, as well ... see if that is different.

It's strange, the problem exist at once after DC import in my situation. But in my situation initial replica count equals 0.

So it also occurred for me when:

create with exit 1 and replicas 0
RC is created with state "Complete", but of course now pod started up
then scale to 1, and RC stays complete when pod fails.

So one interpretation is that the openshift.io/deployment.phase annotation on the RC is only updated when the RC is initially created (as part of doing the first deployment, where replicas could be either 1 or 0).  If we cause the Pod failure in conjunction with the RC initially coming up, that annotation reflects the error.  But once the RC is created, perhaps that annotation is no longer maintained (either by design, or incorrectly, and hence a bug).  If by design, then I'm not seeing where else in the RC we could infer Pod state.  Perhaps I'm missing something, but if not, then the plugin step does in fact have to pull the Pod up directly.
Next steps from my perspective, the @bparees sanity check, followed by most likely platform team engagement, with either bug fix on their end, or the original change I was envisioning for "verify openshift deployment" to check Pod state in addition to RC state.

It is cool, thanks for your help!

@gabemontero it sounds like it's probably working correctly if i understand the scenario.  The RC did complete successfully (deployed successfully).  The fact that the RC can't be scaled up to 1 because basically you've got a bad pod definition isn't going to reverse the fact that the deployment succeeded.  (that is, scaling is not the same as deploying).
it is a bit hokey since you have to start with a count of 0 to get there.  If the original replica count was 1, the deployment never would have succeeded, as you saw.
so you can run it by platform management, but i think it's basically working as we'd expect... so the question comes back to "what, if anything, can we do about this?"
doesn't the replica count verification step handle this scenario?  that is, you can always add another step to verify that the correct number of replicas are running, which in this scenario, they won't be.

@bparees  Not sure that is "bad pod definition", because it is correctly. I set my script, which should start after pod initialization, but this script definitely can return 0/1 and DC should reflect to these probable situations.

The replica count of the RC is showing 1 in this error scenario @bparees.
I have a "live" version of the error state and that is what it is showing.
And yeah, based on what you outlined, I don't think we should pull in
platform mgmt.
Thus, I think we need to introduce the Pod state verification I had started
earlier this week.
On Fri, Apr 8, 2016 at 3:04 PM, Ben Parees<EMAIL_ADDRESS>wrote:

@gabemontero https://github.com/gabemontero it sounds like it's
probably working correctly if i understand the scenario. The RC did
complete successfully (deployed successfully). The fact that the RC can't
be scaled up to 1 because basically you've got a bad pod definition isn't
going to reverse the fact that the deployment succeeded. (that is, scaling
is not the same as deploying).
it is a bit hokey since you have to start with a count of 0 to get there.
If the original replica count was 1, the deployment never would have
succeeded, as you saw.
so you can run it by platform management, but i think it's basically
working as we'd expect... so the question comes back to "what, if anything,
can we do about this?"
doesn't the replica count verification step handle this scenario? that is,
you can always add another step to verify that the correct number of
replicas are running, which in this scenario, they won't be.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/openshift/jenkins-plugin/issues/33#issuecomment-207560919

Add it within the existing "verify openshift deployment"
On Fri, Apr 8, 2016 at 3:15 PM, Gabe Montero<EMAIL_ADDRESS>wrote:

The replica count of the RC is showing 1 in this error scenario @bparees.
I have a "live" version of the error state and that is what it is showing.
And yeah, based on what you outlined, I don't think we should pull in
platform mgmt.
Thus, I think we need to introduce the Pod state verification I had
started earlier this week.
On Fri, Apr 8, 2016 at 3:04 PM, Ben Parees<EMAIL_ADDRESS>wrote:

@gabemontero https://github.com/gabemontero it sounds like it's
probably working correctly if i understand the scenario. The RC did
complete successfully (deployed successfully). The fact that the RC can't
be scaled up to 1 because basically you've got a bad pod definition isn't
going to reverse the fact that the deployment succeeded. (that is, scaling
is not the same as deploying).
it is a bit hokey since you have to start with a count of 0 to get there.
If the original replica count was 1, the deployment never would have
succeeded, as you saw.
so you can run it by platform management, but i think it's basically
working as we'd expect... so the question comes back to "what, if anything,
can we do about this?"
doesn't the replica count verification step handle this scenario? that
is, you can always add another step to verify that the correct number of
replicas are running, which in this scenario, they won't be.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/openshift/jenkins-plugin/issues/33#issuecomment-207560919

if the pod isn't reported as running, it seems like a mistake for the RC to be reporting the replica count as 1.

@livelace if you want to prevent the deployment from succeeding, you need to use a readiness check, not a post-start hook.

On Fri, Apr 8, 2016 at 3:28 PM, Ben Parees<EMAIL_ADDRESS>wrote:

if the pod isn't reported as running, it seems like a mistake for the RC
to be reporting the replica count as 1.

I could see applying your earlier rationale to this facet as well.  Perhaps
we should engage platform mgmt here, but
I'm still coming to the mind that adding the redundancy of checking the pod
state is still a good thing irregardless, given
the complexities and on-going (at least from my perspective) evolution for
this particular area.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/openshift/jenkins-plugin/issues/33#issuecomment-207569581

@bparees I'm understand this, Not all configuration contain service. I think, that with liveness probes we can devise something, but it complicate task, instead of just detect pod status.

@kargakis with a post lifecycle hook, can the container become ready and then not ready if the hook fails? It's possible the old rolling updater will observe the first ready state and move on even though the pod will become not ready soon.

Upon closer inspection, @bparees was right with earlier statements: the example is using the default rolling params, so 25% max unavailable (for the desired replica count of 1, this means 0 is the minimum ready pods to maintain during the update is 0). So, scale-down of the old RC will proceed regardless of new RC pod readiness. The absence of a readiness check on the RC's container specs means that the new RC's active pod count will not be coupled to pod readiness, and it doesn't seem like lifecycle post hook failure will affect the RC's active replica count.
Seems like you need a readiness check to define what it means for your pod to be ready; the failure of a post hook may not necessarily imply the pod is not ready.

The rolling updater doesn't care about readiness when scaling up:/

Not working with liveness/readiness probes:

Liveness case:

nginx-live.yaml - https://paste.fedoraproject.org/352625/14602057/
RC status - https://paste.fedoraproject.org/352627/14602058/
Pod status - https://paste.fedoraproject.org/352628/20583214/

Readiness case:

nginx-ready.yaml - https://paste.fedoraproject.org/352626/46020576/
RC status - https://paste.fedoraproject.org/352629/14602058/
Pod status - https://paste.fedoraproject.org/352630/60205897/

[root@openshift-master1 ~]# cat /share/run.sh
#!/bin/bash
exit 1
[root@openshift-master1 ~]# cat /share/check.sh
#!/bin/bash
exit 0

Guys, tell me something, please :)

Two things here:

If your concern is a violation of your minimum availability requirements, use readiness checks and a >0 availability threshold. The rolling updater won't scale down below your threshold given you have readiness checks in place.
If your concern is the updater scaling up without regards to pod readiness, we'll need to take the discussion to origin/kubernetes, because the rolling updater progresses to scales up based on replica count of the RC which doesn't take readiness into account.

cc @kargakis

Hey @livelace - to build on what @ironcladlou outlined, @bparees and I have had some discussion offline.  I have a prototype for the plugin which inspects Pod state, but @bparees has convinced me that it only handles rudimentary cases, and that we should finish the path of understanding what is needed for the ReplicationController to more accurately reflect the state of the Pods.... ideally, we still want the jenkins plugin to stop its examination at the ReplicationController level, and leverage all the infrastructure in place on the DC, RC, and Pod side (and avoid duplicating similar tech in the plugin).
But let's see how @ironcladlou 's 1) and 2) progress, and then we'll level set.

@ironcladlou @gabemontero
Ok, thanks. I understood this and agree with yours conclusions. At this moment I can detect DC and hook statuses by myself (through "status" files). But I must to know, how this case will be solved.

Hey @livelace - to get resolution, at least based on my interpretation of things, they key point is 2) from https://github.com/openshift/jenkins-plugin/issues/33#issuecomment-208510550.
To that end, an issue should be opened against https://github.com/openshift/origin, referencing this issue and basically copying/pasting @ironcladlou 's item 2) from that comment.
As the end user, it would be best if you open the issue.  Are you comfortable doing that?
thanks

Quick status update:  leaving this issue open for now, and will monitor https://github.com/openshift/origin/issues/8507 to see how that progresses.  I'm anticipating things progressing so that the jenkins-plugin can continue to take its validation logic only to the replication controller level, but let's wait and see.  Ideally that occurs and I'll then close this out.

All the links are dead unfortunately. Why a readiness probe is not working for your case @livelace? There are different kinds of probes, if you cannot use http, you can run shell commands (exec) or try to open a tcp connection.

@kargakis No, readiness and liveness probes don't working in this case. I repeat @bparees statement
"the fundamental issue in my mind is that the replication controller is reporting an active count of 1 despite the fact that the only pod that exists is in a FAILED state."

Ok. Actually we want, that lifecycle hooks will be processed in context of deployment status. If hook ended with error - deployment should be considered as a failure. Main process of pod may working well and pass all tests (liveness/readiness) but if hook returned error - deployment status should be - failed, because hook is important part of pod and it readiness.

Sorry for jumping from one thread to the other but upstream deployments have no hooks yet. If your problem is that you want a failed hook to fail your deployment you can specify FailurePolicy == Abort

@livelace any news here? Did hooks work for you?

@kargakis I'm sad :(
apiVersion: v1
kind: List
items:

- apiVersion: "v1"
  kind: "DeploymentConfig"
  metadata:
    name: "test"
  spec:
    template:
      metadata:
        labels:
          name: "test"
      spec:
        containers:
          -
            name: "nginx"
            image: "nginx:latest"

            lifecycle:
              postStart:
                exec:
                  command: [ "exit", "1" ]
    replicas: 1
    selector:
      name: "test"

    strategy:
      type: "Rolling"
      rollingParams:
        pre:
          failurePolicy: "Abort"
          execNewPod:
            containerName: "nginx"
            command: [ "true" ]

[root@openshift-master1 ~]# oc get pods
NAME              READY     STATUS             RESTARTS   AGE
test-1-deploy     1/1       Running            0          8m
test-1-hook-pre   0/1       Completed          0          5m
test-1-oo71c      0/1       CrashLoopBackOff   3          6m
[root@openshift-master1 ~]# oc get dc
NAME            REVISION   REPLICAS   TRIGGERED BY
test            1          1          config

If pod inside broken - we should mark DC as failed and replica count should be 0 :(

@livelace the timeout for deployments is at 10m. If you waited 2 more minutes you would see that the deployment will be marked as failed and eventually scaled down to zero:)
[vagrant@localhost sample-app]$ oc get pods
NAME              READY     STATUS             RESTARTS   AGE
test-1-deploy     1/1       Running            0          10m
test-1-hook-pre   0/1       Completed          0          10m
test-1-utjds      0/1       CrashLoopBackOff   6          9m
[vagrant@localhost sample-app]$ oc get pods
NAME              READY     STATUS      RESTARTS   AGE
test-1-deploy     0/1       Error       0          10m
test-1-hook-pre   0/1       Completed   0          10m
[vagrant@localhost sample-app]$ oc status
In project test on server https://<IP_ADDRESS>:8443

dc/test deploys docker.io/library/nginx:latest
  deployment #1 failed 10 minutes ago

1 warning identified, use 'oc status -v' to see details.

Note that your use of the deployment hook didn't do anything and the deployment hook was complete. I think in your case you would want a post hook with Abort policy with a script that makes sure your application pod is up and running. Also readiness probes can help.
Regarding the timeout, we will make it configurable eventually.

@kargakis
The deployment hook is useful when we should be sure that new version of software working as expected and go back to working deployment if fail. But we have different situation. Our deployment should be launched and if container hook (which do some bunch of things inside, it is dynamic configuration) return error - deployment should be marked as failed.
The deployment hook isn't working for us, because it works only in deployment. But we need possibility when container hook cause an error during scaling. We need failure policy for container hook.

@smarterclayton @ironcladlou, @livelace wants container hooks to be taken into account for deployments. Thoughts?

@livelace actually can you try to run a deployment with a container postStart hook that fails and see if it works for you after 10 minutes?

@kargakis
dc/test deploys docker.io/library/nginx:latest
  deployment #1 failed 11 minutes ago

Every 1,0s: oc get pods | grep ^test-                                                                                Tue May 31 20:16:58 2016

test-1-deploy                                      0/1       Error       0          13m

[root@openshift-master1 ~]# oc get rc
NAME      DESIRED   CURRENT   AGE
test-1    0         0         17m

@bparees @gabemontero Can we detect and wait this behavior during "Scale Deployment"  in Jenkins ?

"Verify whether the specified number of replicas are up" already exist.

@livelace detect and wait for what exactly?  I still haven't seen a satisfactory answer for why the replication controller is reporting N current pods when those pods are in a failed state.

@bparees @kargakis Ok. I think, minimum two variants:

Report about replica count  on early stage (immediately after a container hook return an error).
When we do "Scale Deployment", we may wait and check that this deployment not in failed state.
?

I still haven't seen a satisfactory answer for why the replication controller is reporting N current pods when those pods are in a failed state.

Because it's not the job for a replication controller but for a deployment. The rc/rs will always report what it has created but it cannot know if those pods are running.

Report about replica count on early stage (immediately after a container hook return an error).
When we do "Scale Deployment", we may wait and check that this deployment not in failed state.

You shouldn't deploy zero replicas and scale after the fact. That's why we use deployments in the first place, otherwise we would still use replication controllers. Deployments ensure that your pods are able to run. Replication controllers cannot do that by design.

Deployments ensure that your pods are able to run. Replication controllers cannot do that by design.

Our deployments are always can run and working without any problem. Pods work excellent. But we use container hooks, which launch integration tests with other services in different pods.

But we use container hooks, which launch integration tests with other services in different pods.

Would it make sense to group all those containers together? Or are those other services independent components of your system?

And we can't hold pods online all time.

Do you really need to scale down to zero here or could you just stop directing traffic to those pods?

Would it make sense to group all those containers together? Or are those other services independent components of your system?
Yes, it is. For example: three containers, each should be set specific settings and all communicate each other + exist "external" services (not in the same pod) and they also in connection with other.

Do you really need to scale down to zero here or could you just stop directing traffic to those pods?

We need:
step 1: start/scale DC to N
step 2: wait tests completion
step 3: stop/scale DC to zero

We need:
step 1: start/scale DC to N
step 2: wait tests completion
step 3: stop/scale DC to zero

Try setting dc.spec.test=true

@kargakis Thanks, but:
``
[root@openshift-master1 11.0]# oc explain dc.spec.test
FIELD: test
DESCRIPTION:
Test ensures that this deployment config will have zero replicas except
while a deployment is running. This allows the deployment config to be used
as a continuous deployment test - triggering on images, running the
deployment, and then succeeding or failing. Post strategy hooks and After
actions can be used to integrate successful deployment with an action.
``
We need:

Scale DC1 (contain some services with some settings/tests through container hook)
Scale DC2 (contain some services with some settings/tests through container hook)
Scale DC3, which communicate with DC1 and DC2 (contain some services with some settings/tests through container hook).
Wait results.
Scale DC1/DC2/DC3 to zero

And what we have, steps:

Trigger deployment DC1. Deployment DC1 done and powered down.
Trigger deployment DC2. Deployment DC2 done and powered down.
DC3 can't communicate with DC1/DC2, because they was stopped.

There are a couple of things you can do in such a scenario. One is you can setup posthooks in DC1/DC2 to wait for DC3 to complete. DC3 comes up, runs its tests, completes, DC1 and DC2 complete. All are scaled down automatically because they have dc.spec.test=true.
You can also play around with custom deployments:
http://lists.openshift.redhat.com/openshift-archives/dev/2016-May/msg00037.html

There are a couple of things you can do in such a scenario. One is you can setup posthooks in DC1/DC2 to wait for DC3 to complete. DC3 comes up, runs its tests, completes, DC1 and DC2 complete. All are scaled down automatically because they have dc.spec.test=true.

You could also setup a prehook for DC3 to start DC1 and DC2 and wait for them to be running so you would need to run just DC3.
$ oc deploy dc3 --latest
---> DC3 prehook starts DC1 and DC2 and waits for them to be running...
---> DC1 and DC2 are running
---> Prehook exits
---> DC1 and DC2 should wait on their posthooks at this point
---> DC3 is running
---> DC3 completes, is scaled down because it has dc.spec.test=true
---> Posthooks for DC1 and DC2 exit, they complete and are scaled down because dc.spec.test=true

Complicated but it could work.

@kargakis  Thanks, I will try it later.
PS. Thorny our way :)

The thing is that by scaling deployment configs up/down to zero instead of actually deploying them, you lose all the benefits you get from using deployments. Replication controllers by design cannot detect failures and I don't think it will ever change especially in the light of ... having deployments:)

DC3 also sounds a lot like a Job:
https://docs.openshift.org/latest/dev_guide/jobs.html

The thing is that by scaling deployment configs up/down to zero instead of actually deploying them, you lose all the benefits you get from using deployments.

Actually deployments work fine, because they trigger by "image change" and it's Ok.
DC3 - it's most easy thing in configuration. I saw "Jobs" previously.

Main challenge - use multiple deployments (services inside) with each other. At this moment after scaling we just check file flag, which indicate about tests execution inside deployment (with Jenkins help). But we want more mature/right mechanism.

My interpretation is that the discussions here have circled back to https://github.com/openshift/origin/issues/8507
We also got clarification from @kargakis back with https://github.com/openshift/jenkins-plugin/issues/33#issuecomment-222936166 on why the RC was reporting what it was reporting.
And based on the discussions noted with https://github.com/openshift/jenkins-plugin/issues/33#issuecomment-208478930 , we still don't want the plugin to start interrogating Pod state.
Of course, this is still an evolving area.  If changes occur around the multiple deployment orchestration or what the RC reports wrt Pod state, we can look into associated changes in the plugin.
But with the above preamble, I'm going to go ahead and close this one out.  Please continue discussions either in https://github.com/openshift/origin/issues/8507 or new issues to be opened against origin or k8s if the discussion broadens.
Thanks.


Support Token DoubleQuoted

Link to #30
Summary
MySQL support insert value with double quoted like this :
insert into db.t values ("valuess");

but now, next_token not impl double quoted case. '"' just a char.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

32 of 48 (66.67%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.1%) to 89.366%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/tokenizer.rs
18
34
52.94%

Totals

Change from base Build<PHONE_NUMBER>:
-0.1%

Covered Lines:
7051

Relevant Lines:
7890

💛  - Coveralls


[ARM] Fix #19124: az deployment what-if: Handle unsupported and no effect change types

Description
Fixes #19124.
Testing Guide
az deployment group/sub/mg/tenant what-if ...

History Notes

[Component Name 1] BREAKING CHANGE: az command a: Make some customer-facing breaking change.
[Component Name 2] az command b: Add some customer-facing feature.

This checklist is used to make sure that common guidelines for a pull request are followed.

[ ] The PR title and description has followed the guideline in Submitting Pull Requests.

[ ] I adhere to the Command Guidelines.

[ ] I adhere to the Error Handling Guidelines.

ARM

@shenglol Could you solve the issue of CI style and ensure that this feature passes the tests of edge build?


Feature: Add a progress indicator to the wiki

This shows a progress indicator in the footer on the Wiki, so you can tell when everything's loaded. I've tried to make it general enough that the same code could be run on the Hallway.

I've been testing in Firefox, but it looks odd in Chrome & Safari. Gonna test some more.

Fixed.
It seems Webkit doesn't like it when rules are shared between -webkit and -moz selectors. So something like this:
::-webkit-thing, ::-moz-thing { background: #777 }

…must be changed to:
::-webkit-thing { background: #777 }
::-moz-thing { background: #777 }

🙃


Deprecation warning in PHP8

On PHP8, this warning is displayed when generating secret and QR code
Deprecated: rawurlencode(): Passing null to parameter #1 ($string) of type string is deprecated in ProjectFolder\vendor\robthree\twofactorauth\lib\TwoFactorAuth.php on line 275

We've had this fixed in master, but I was trying to wait for #84 before releasing. I'll try and get it finished and released today.

Composer is still not picking up this version. Is this normal? I'm running composer update. The version I have is 1.8.

1.8.1 is showing up in packagist https://packagist.org/packages/robthree/twofactorauth
do you need to do composer require robthree/twofactorauth ^1.8.1 ?

That worked. Thanks

good to know, unfortunately composer update needs a helping hand sometimes


support for azure monitoring

I'm interested in helping out on integrating metrics from the azure monitoring datasource.
Any thoughts on support for azure monitoring? It doesn't look like a typical storage/db but rather a service

Hello,
I think it is a data source plugin in Grafana for monitoring Azure.
In loudml grafana app - you may fork repository and then add in extractors.js a parsers for Azure.
Feel free to ask me sny help when th it,
V.

21 лют. 2021 р. о 22:56 Cherchercher<EMAIL_ADDRESS>пише:

I'm interested in helping out on integrating metrics from the azure monitoring datasource.
Any thoughts on support for azure monitoring? It doesn't look like a typical storage/db but rather a service
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.


Save internal switch info directly into Calibration

Since the Calibration object is supposed to be fully self-contained, it would be useful to actually save the internal switch data directly into it, rather than keeping it as a file path.
As it stands, this will require a bit of re-plumbing, since the io.SwitchingState object itself requires passing a filename, not in-memory data. I think it would be best to set it up to create an edges-cal based object, which may require adding a .from_data() method to it. There are a few functions in edges-analysis that expect an io.SwitchingState that might then need to be changed to the edges-cal SwitchingState.

This is done, at least in a hacky way


Support FQDN in host field for controlPlaneConfiguration

What happened:
Specifying fqdn for host under controlPlaneConfiguration is currently not supported.
What you expected to happen:
host name might be misleading as eks-a only actually supports ip right now. Cluster-api also supports fqdn.
How to reproduce it (as minimally and precisely as possible):
Specify fqdn for host
Anything else we need to know?:
This is a known limitation of eks-a with the intention of adding support to it just like cluster-api does.
Environment:

EKS Anywhere Release:
EKS Distro Release:

Relates to #6863


fill out field from previous request by default in session request tool

Description
Rather then having a button to retrieve all info from the previous session request, can we maybe just by default fill out the field from based on the previous request (and rather have a "clear all fields" button instead)?
It's really easy to miss that button. I always start filling out the first fields until I see that no conflicts are show and have to use that button...
Code of Conduct

[X] I agree to follow the IETF's Code of Conduct

@lars - I'd need the IESG to ask for this if you think it's right. Previous IESGs explicitly wanted the fill-from button, thinking it would cause people to think about whether the conflicts were still correct.
Maybe the form should automatically fill in things from the last request, but have "I've verified these conflicts are still correct" annoyance-checkboxes?


Fix aggregation filter expression processing in the absense of projection

After #14510 some queries become unplannable; like:
select count(1) filter (where __time > date '2023-01-01')
from druid.foo where 'a' = 'b'

The reason behind it was that the initial plan of
LogicalAggregate(group=[{}], EXPR$0=[COUNT() FILTER $0])
  LogicalProject($f1=[>($0, 2023-01-01 00:00:00)])
    LogicalFilter(condition=[=('a', 'b')])
      LogicalTableScan(table=[[druid, foo]])

was simplified by  some RelBuilder usage and PruneEmptyRules.PROJECT_INSTANCE into
LogicalAggregate(group=[{}], EXPR$0=[COUNT() FILTER $0])
  LogicalValues(tuples=[[]])

which become unplannable because the FILTER clause processing put a hard constraint on the existence of a Project in the actual plan here
Proposed solution is to use Expressions.fromFieldAccess to optionally use the project - or use a direct field access that's absent.
This PR has:

[x] been self-reviewed.
[x] added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.

it's a bit weird that we were not doing this already. Though the change makes sense to me so I am approving it.

Thank you for reviewing the changes :)
the original bail-out goes back beyond 2018 - so it was handled like this for historical reasons :cowboy_hat_face:

Thank you Somu and Abhishek for reviewing these changes!


Feat: entry points with override methods

The new entry point fromager.override_methods lists all fromager override methods by name and their default implementation. This allows consumers to get a list of known override methods and compare function signatures.
Also address some typing issues in override methods and helpers.

I like this. We could document using entry_point_inspector for listing them.
This is relevant to #196, too, @shubhbapna


How to register existing containers

I'm attempting to run a SkyDNS2-based deployment with a bunch of web app containers fronted by Nginx. After launching SkyDNS and Registrator, my expectation was that it would sync its state with Etcd, loading all existing containers before watching for new events. This doesn't appear to be the case, though.
Is it possible to have Registrator load all currently-running containers into SkyDNS before it begins watching for new events?

+1 to this, just had a similar issue. Tried connecting to a consul backend with consul://consul (consul container linked). This failed with some confusing messages about being unable to reach /v1/agent/services on port 80. Everything worked when I used consul://consul:8500 instead.

I believe #115 resolved the main issue here. The "Ping" method will attempt to connect to the registry and give an error at startup if it cannot be reached.


OCM-9005 | fix: Update ocm-sdk-go to fix Windows SSL certificate issues

This PR updates the version of the ocm sdk to include the fix for Windows SSL certificates.

/cherrypick release_1.2.41

/test coverage


[WIP] CSS hotpatching support

This patch provides support for css hotpatching. Right now, it's more of a proof-of-concept, and I intend to polish it over a few iterations to get it to a more mature state suitable of being merged.
At this moment, the code is pretty much a copy of the js patching code with a few changes made to patch css instead. This results in a lot of duplication. I think it would generally be a good idea to move the common code (e.g. finding the source file on disk, creating a file read stream) into some helper module, so that not only js/css but document/image in the future can take advantage of it.
What's in:

Preliminary css hotpatching support. To try it, clone the repo, head to examples/mithril, and run npm start. As you edit stylesheet/app.css, the changes should be reflected in browser.

What's missing:

Test suite.
Proper CLI option. Right now it just piggybacks on --hot

Questions:

Should css patching get its own CLI option? I think @caspervonb you mentioned that you considered stylesheets and images just another part of document patching, so should all of the three together get one CLI flag instead?

I'm a bit sick at the moment so I'll skip the code review for now, I'm sure it'll be thrown upside down when the "rest" of the dom is added anyway.

•Should css patching get its own CLI option? I think @caspervonb you mentioned that you considered stylesheets and images just another part of document patching, so should all of the three together get one CLI flag instead?

Everything that is "live dom reloading" should be the same module, a fnmatch pattern can be used to exclude things. (e.g if you only include *.html then obviously only *.html will be matched)
The reason they belong in the same module/plugin is simply because you cannot have any of them without having a DOM, e.g an image change can mean a bunch of things, in a game engine maybe you'll have to re-create textures. In the context of the dom it means cache busting and reloading. All resources should get the same treatment IMHO (audio, video, sound, object, embed).
As for the cli option, I'm going through a pretty hefty rewrite separating "services" and "modules/plugins", I might extract out hotpatch into a "sanctioned module", where the  usage will be.
amok --plugin amok-hotpatch

My plan for this would be the same
amok --plugin amok-livedom # or whatever name


Change cell delimiter?

I know it may break earlier code, but is there anyway we can change the cell delimiter to something else besides /n/n?
Two newlines is very common, things shift, and I think this (along with accidently opening as a normal sql txt) seem to be causing an error that my cells are CONSTANTLY collapsing into one monolithic cell.  (Also I suspect that it may be introducing merge conflicts when I rebase.)
Wouldn't something like:
--#vscode-sql-notebook
or anything really that would help retain cell formatting after  presses, pushed and pulled from repos and opening in other editors.

I'll see what it is so particular about my workflow that I keep running into issues.  It's not an easy issue to debug, but if I'm very careful to watch the file for changes as I use git rebase and opening and closing with vscode maybe I'll notice something.
I agree \n\n is the most portable for sure, but unfortunately there is no standard or convention of sql authors.  I think \n\n is a good first guess of most authors to designate "this section is a new query or separate 'code block'". But even though that's what most people use, it's probably only 30% (wild guess) of the authors are that rigorous.  If most people are like me, you put in 1, 2, 3 or n newlines with comments and all sorts of mess.   Moreover, most people who have sql files never intended to use them as cell-based workflow.  What you are doing with this databricks/juupyter-style workflow is very avant garde (kudos btw).  But most data engineeers I've seen have this horrible copy-to-notebook++ right out of their DB Admin tool of choice workflow.  Few, in my estimation, are doing a juypter/zepplin/databricks notebook-style SQL editing.   So it seems like the desire to auto-parse any .sql that was never intended for cell-based workflow into cells probably has limited ( but yes real) use.
Yeah I wouldn't have the serialize/deserialize operations be different.
Maybe there's a way to allow for both parsings?  Maybe a config in the UI to allow power users to use a standard (or specify their own) delimiter?  Then the plugin would try its best to auto-cell any sql file that you throw at it, but it would allow us power users to force their cells where they like with complete control (and hopefully avoid multiple-editor, git issues).
As an aside, if you're not aware, this question of "additional markup" must have been on the minds of the juypter folk too.  But they made some poor choices in my mind that broke any version control and other important workflow (just parsing/cating files). So I think your intuition to build on top of standard plain sql files solid.  Both Pycharm and VSCode have worked around juypter's file format issues by introducing their own parsing markup.  Pycharm calls this scientific mode, and you can annotate any cell you want with #%%
https://blog.jetbrains.com/pycharm/2018/04/pycharm-scientific-mode-with-code-cells/
VSCode Also adopted a similar convention with # %% (not sure how the space differs in both):
https://code.visualstudio.com/docs/python/jupyter-support-py
This allow sthem to have a cell-based workflow without relying on Jupyter's horrible  xml- (or json?)-based file format that is impossible to version control and gets you little (in my mind), since I believe both still retain markdown.

My apologies for the delayed response. @jpmorris lots of great thinking there, I appreciate the depth.

Maybe there's a way to allow for both parsings? Maybe a config in the UI to allow power users to use a standard (or specify their own) delimiter?

This is a good suggestion, but thinking through the implementation details, I think it would add unnecessary complexity for the user. Consider the UX of opening a shared notebook with a collaborator

do they need to coordinate delimiter selection?
if the extension tries to auto detect delimiters, what happens when multiple are used in the same document?
if I change delimiter selection does it attempt to coerce and overwrite existing delimiters?

Few, in my estimation, are doing a juypter/zepplin/databricks notebook-style SQL editing. So it seems like the desire to auto-parse any .sql that was never intended for cell-based workflow into cells probably has limited ( but yes real) use.

Upon further rumination, I think you're correct. And since a configurable delimiter isn't worth the UX overhead for the reasons listed above, I think the best path forward is to replace the current \n\n with --#sql-cell. This also feels generic enough that it could be adopted by other tools (as compared to --#vscode-sql-notebook).
Of course, this will collapse all existing sql notebooks into a single cell. So long as we call out this breaking change in the changelog, I think it's fine. We can even provide a little bash command in the release notes that will replace all instances of \n\n with --#sql-cell.

Yes if you want to pick a standard then I would say that's better than user customization.  I would only say that user-defined delimiter is better keeping it ONLY \n\n   Teams have to use all sorts of tools (linters, IDEs, config files, git hooks and ,git line ending handlings, tab vs space coding standards, coding widths, workflows and dockerfiles etc) I don't see this being that different.  The team would coordinate on a delimiter and they don't care about other delimiters (so the extension would only need to prefer user-config and no coercion necessary).  But, again, if you want to pick a standard that's better than letting the user decide.
Part of the reason the issue you raised is because there's no standard here.  If there was a standard then people would mostly abide by that standard.  (User-defined delimiter would also probably be unnecessary, or if there were 2 standards--like line endings or tab v space, or even auto-formatters (like python black)--the config would be a simple dropdown like many of the settings in vscode UI.)
I think --#sql-cell sounds good.  I was thinking you might consider the current 'standard' (as much as it can be) that I mentioned that is trying to be established by VSCode and Pycharm of using #%% for non-jupyter cell-based notebooks/workflow. But since you'll need to put the two dashes in front to make it a sql comment I don't think it gets you much since you're not REALLY adopting their cell-delimiter standard.    Databricks (and I think zepplin) do support SQL notebooks, but all the cell delimiting happens through the UI.  They can export in certain formats like html (for presentation) and I think they can export as a more usable format.  If you care at all to match ANY standard you could launch their free databricks trial and see if their exported notebooks have some sort of delimiter you can be consistent with.   I wouldn't be surprised if it was a propitiatory format or a non-extendable json/xml source though.  Or maybe just google to see if ANYONE is doing anything like you and see if they want to coordinate on a standard. If not, then you're in that unique spot that you get to pick a standard.
Thanks for all the hard work and continual development on this.  Do you have a tip jar someone can donate to?


I faced error usv_water_current/GetSpeed.h: No such file or directory

Hello I'm trying  to build and simulate your usv project...
I already set build environment for building your project. But when building usv_water_current the error occured.
Error message is
"usv_sim_lsa/src/usv_water_current/src/main.cpp:11:40: fatal error: usv_water_current/GetSpeed.h: No Such file or directory"
I'm trying to find GetSpeed.h header file in your project I cannot find...
Can you tell me how to solve that problem?
Thank you

Hello JeimeRhee
I couldn't reproduce your error, but I updated the master branch. So I hope you will not face that error again.
Please, download again the repository and compile it. Let me know if you have any other error.
Thank you,
Marcelo

Hello Marcelo
I really appreciate your help!
I download again the repository, compilation success
Thank you
JeimeRhee


Integration not loaded in version 2024.7.1

Detailed description
The error says that something wrong about import_module.
Same as other integrations HACS and native;
Google Nest: https://github.com/home-assistant/core/issues/121521
HACS pod_point : https://github.com/home-assistant/core/issues/121284
HACS omnic convertor: No issue raised jet
Context
The integration won't load anymore after update from 2026.6.4 to 2024.7.1
Diagnostics
Sorry, because I did a restore I can not get to the logs anymore

Seems related with;
https://github.com/home-assistant/core/issues/119223

I'm on 2024.7.2 and everything is working fine, sorry but without logs I cannot do anything :/

Thanks for the update! I saw the 2024.7.2 version advertising, but this time I though I wait a bit to see if others don't have problems😎.
So will give it a try now🤞

Assuming this is fixed, i'm closing this


bug: Uncaught DOMException: Failed to execute 'replaceChild' on 'Node'

Uncaught TypeError: Cannot read properties of undefined (reading '__t')
    at Block.p (million.52d69b41.mjs:779:1)
    at ArrayBlock.p (million.52d69b41.mjs:516:1)
    at react.mjs:84:1

and
Uncaught DOMException: Failed to execute 'replaceChild' on 'Node': The node to be replaced is not a child of this node.
    at Block.p (http://localhost:3000/static/js/bundle.js:1078098:29)
    at ArrayBlock.p (http://localhost:3000/static/js/bundle.js:1077859:16)
    at http://localhost:3000/static/js/bundle.js:1077131:67

Unable to understand why the error is occurring, this should be the problem code:
          if (newValue && typeof newValue === "object" && "foreign" in newValue) {
            const scopeEl = el[TEXT_NODE_CACHE][k];
            if ("unstable" in newValue && oldValue !== newValue) {
              const newScopeEl = newValue.current;
              el[TEXT_NODE_CACHE][k] = newScopeEl;
              replaceChild$.call(el, newScopeEl, scopeEl);
            } else {
              newValue.current = scopeEl;
            }
            continue;

inside of class Block.
I tried to // million-ignore all of the functions in the components where the error occurred but the error didn't go away.
Potential solution, Conditional Replacement: Check if oldChild is actually a child of parentNode before using replaceChild. You can verify with parentNode.contains(oldChild)
if (parentNode.contains(oldChild)) {
  parentNode.replaceChild(newChild, oldChild);
} else {
  // Handle the case when oldChild is not a child of parentNode
}

Hi can you provide a repro!

@jalexanderII, are you there?

Hey team. I do not know how to reproduce. I am not sure why this is occurring or what in my code is triggering the problem. All I know is the source of the error from the error message.

@tobySolutions & @aidenybai

I am facing the same issue for my site. Here is the error in console -

This is my vite.config.js

This is main App.js file

I'm not sure where the error is coming from though. Any help would be highly appreciated.

I'm also facing the same issue.
here is the url of StackBlitz repo https://stackblitz.com/edit/vitejs-vite-ofx7tf?file=package.json

I'm also facing the same issue. I'm rendering same component 4 times, but it's only showing 1 time.

sample code url: https://stackblitz.com/edit/vitejs-vite-ofx7tf?file=src%2FApp.tsx

Thanks for the reproduction. I'll definitely check it and get back to you!

I'm also facing the same issue. I'm rendering same component 4 times, but it's only showing 1 time.

sample code url: https://stackblitz.com/edit/vitejs-vite-ofx7tf?file=src%2FApp.tsx

Thanks for the reproduction. I'll definitely check it and get back to you!

Hey there @vimalsonara, so I made tweaks and I used manual mode to make the optimizations for MonthDaysDisplay, I had to ignore automatic mode for the MonthDaysDisplay component: https://stackblitz.com/edit/vitejs-vite-hjcfai?file=src%2FMonthDaysDisplay.tsx

I'm also facing the same issue. I'm rendering same component 4 times, but it's only showing 1 time.

sample code url: https://stackblitz.com/edit/vitejs-vite-ofx7tf?file=src%2FApp.tsx

Thanks for the reproduction. I'll definitely check it and get back to you!

Hey there @vimalsonara, so I made tweaks and I used manual mode to make the optimizations for MonthDaysDisplay, I had to ignore automatic mode for the MonthDaysDisplay component: https://stackblitz.com/edit/vitejs-vite-hjcfai?file=src%2FMonthDaysDisplay.tsx

Thank you @tobySolutions
It's working now.

I'm also facing the same issue. I'm rendering same component 4 times, but it's only showing 1 time.

sample code url: https://stackblitz.com/edit/vitejs-vite-ofx7tf?file=src%2FApp.tsx

Thanks for the reproduction. I'll definitely check it and get back to you!

Hey there @vimalsonara, so I made tweaks and I used manual mode to make the optimizations for MonthDaysDisplay, I had to ignore automatic mode for the MonthDaysDisplay component: https://stackblitz.com/edit/vitejs-vite-hjcfai?file=src%2FMonthDaysDisplay.tsx

Thank you @tobySolutions It's working now.

My pleasure @vimalsonara!


issue 6 Added text animation

https://github.com/user-attachments/assets/a838c32c-d84a-40dc-a2bb-6f4a22f3e2c7

Why did you change the background, please make the background as it was earlier

Can you list all the changes you have made in the code as I can see alot of changes
list all the changes in all files that you did
I can see 8 files changed for this

Specifically, I made changes to Home.jsx by adding a TypingAnimation component with the following code:

The other modified files were likely added as a result of downloading the TypingAnimation from MagicUI as you can see in typing-animation.jsx in components/ui

Resolve merge conflicts @gurliv21

@gurliv21  Resolve the merge conflicts to get the PR merged


fix: Wrong example heading under New Enemy Problem section

Overview
New Enemy Problem section is referring to Zanzibar paper's snippet but the heading of Example B is shown in place of Example A

What's Expected?
Heading for the first example should be Example A: Neglecting ACL update order as referred in the Zanzibar paper here.
Since,this is just a typo, it won't require a lot of changes. Therefore, I would like to pick this issue and fix. Thanks!

Good catch! Please create a PR and I'll work with you to get it merged.

Merged, thanks for the contribution!

Glad to help 😄


v5.19.1

Updated Python runtime to 3.10
Added searchSOSL and searchOneSOSL sfInvokeAPI methods
Removed contact lens dependency on transcribe bucket
Removed unused Brazil dependencies
Lower CTREventSourceMapping BatchSize, allow users to modify BatchSize via cloudformation parameters.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

just as a process note, if you have to do this in the future it's usually best to fork the repo under your account and put the changes there rather than putting the draft changes in a topic branch in the main repo


filename: style box, stay on one line

fix issue whereby file extension would be split over 2 lines
fix issue whereby EMPTY tag would overlap with menu
Issue: KBFS-4198

cc @buoyad

@jakob223 can you merge master / rebase?

@buoyad done

Cool, file extensions aren't wrapping anymore, but also TLF names are gone on mobile:

@buoyad That was fixed in https://github.com/keybase/client/pull/17836. I've rebased on master again, so that fix is now in this branch.


Connections to nyc-lane.wj32.org

When I started processhacker first time, I saw some connection to nyc-lane.wj32.org - this is @wj32 domain name
I don't think this is some malicious activity, maybe I need to disable update checks, but ... how about to completely disable ANY processhacker network activity by default, and allow it only if user agrees? And where in the source code that "nyc-lane.wj32.org" domain? I don't see it there.

completely disable ANY processhacker network activity by default

You would need to disable these two settings in the options window:
Options > General > Resolve network addresses
Options > Updater > Check for updates automatically

Resolving network addresses sends queries to the DNS server for IP address hostname.
Downloads a JSON file from the build server (sourceforge.net and wj32.org)

where in the source code that "nyc-lane.wj32.org" domain? I don't see it there.

wj32.org is the domain for the A and AAAA records.
nyc-lane.wj32.org is the domain for the PTR record.


Feature parity between basic_context and hyper_basic_context

It would be nice if those contexts were drop-in replacements for one-another if I wanted to switch between backend implementations.

We have more or less achieved this, hurray!


undefined method `after' for main:Object

So got everything set up and working when I'm using capistrano, but outside of that, when I try to run a normal rails rake task (e.g. rake routes) I'm getting:

NoMethodError: undefined method `after' for main:Object
/opt/twitter/rvm/gems/ruby-2.2.0/gems/slackistrano-0.1.6/lib/slackistrano/tasks/slack.rake:76

rails 4.2
capistrano 3.4
slackistrano 0.1.6
I was able to fix this in my Gemfile by doing:
gem 'slackistrano', :require => nil
But I figure there must be a better way since I haven't had to do this for any other cap plugins. Just thought I'd post my solution here and see if anyone could translate that into a patch!

I've always used gem 'slackistrano', require: false.  Do your other cap plugins add rake tasks?  Point me to one and I'll see if I can make an adjustment.

https://github.com/capistrano/rails/
https://github.com/capistrano/rvm/blob/master/lib/capistrano/tasks/rvm.rake
etc. I think those both seem to have the after requirements in them too, but handle it differently via namespacing?

So, the difference is that the above gems don't load an task files by default.  That is gem 'capistrano-rvm' doesn't really require anything.  Which is why the instructions say to add require 'capistrano/rvm' to your Capfile.  Slackistrano doesn't do it that way so the require: false is necessary.  I could change it, but it would mean having to make everyone change their Capfile to load some other file as well.  Going to leave it as is for now.


KAFKA-9181; Maintain clean separation between local and group subscriptions in consumer's SubscriptionState (#7941)

Reviewers: Jason Gustafson<EMAIL_ADDRESS>Guozhang Wang<EMAIL_ADDRESS>(cherry picked from commit a565d1a182cc69c9994c4512b5e9877e97f06cdf)
More detailed description of your change,
if necessary. The PR title and PR message become
the squashed commit message, so use a separate
comment to ping reviewers.
Summary of testing strategy (including rationale)
for the feature or bug fix. Unit and/or integration
tests are expected for any behaviour change and
system tests should be considered for larger changes.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

Had conflicts in suppressions.xml and ConsumerCoordinatorTest.java.

ok to test


[ENH] Include maven/gradle declarations for the native artifacts in the release description.

Is your feature request related to a problem? Please describe.
No.
Describe the solution you'd like
A spoiler in the release description for the native artifacts.
Describe alternatives you've considered
None.
Additional context
It would be handy if these artifact/group ids were readily available for those of us who bundle our natives rather than have them get fetched at runtime.

@e3ndr I included the native artifact ids in the release builder. Also the issue with input stream closing should be fixed now.


How the object data bulk changes

Vue.js version
2.0.2
v-for batch cycle of commodity information, batch modify information, how do I pass parameters, two-way binding doesn't work。

Hi, please make sure to follow the Issue Reporting Guidelines before opening an issue. Thanks!


Update the Terraform Azurerm Provider Resource Contribute.md

Terraform code style, code sample, variable definition and corresponding code reference link has changed. We need to refresh and update the content to guide how to contribute to Azurerm Provider
Test with local build is not exactly how it works, I have changed to how it works now.

@yupwei68 This looks fine to me. The only change I would suggest is to change the anchor text where you're using verbiage like "this page". I would recommend using the actual product being installed as the anchor text. f

Hi @WodansSon @TomArcherMsft Thanks for your comments. Corresponding changes have been pushed. Please continue reviewing.


Refine UI to be responsive

Is your feature request related to a problem? Please describe.
The current UI is not responsive and it is hard to use the app in a small window or in mobile devices.
Describe the solution you'd like
The UI should be responsive and easy to follow with new features.
Additional context
Making the UI responsive can be done after fixing current issues

merged, closing the issue


Customizing  multi camera streaming pipeline

Hi, Thanks for your great work. I have a query regarding the multi-camera stream pipeline.  In my case, I have a config file having 4 video sources in which I am applying object detection using Yolov5.  Later after detecting objects, I have to calculate distances and had to do other customization on bounding boxes and acquired frames. How can I acquire this data in my python script? Any suggestion, please?  @Joxis

Hi @sharoseali! Glad you like the repository 🙂
Could you provide a bit more information on what exactly you want to achieve? Do you need the timestamps at which objects were detected? With the current implementation you can already access frames and detections via a probe.

Thanks for the reply

Could you provide a bit more information on what exactly you want to achieve? Do you need the timestamps at which objects were detected?
Ans: I want to access the frames and bounding boxes like (x1 y1 x2 y2) or (w, h)

With the current implementation you can already access frames and detections via a probe.
I want to get boxes to calculate distances and other operations, redraw customized boxes and data on the frames and show them again on the screen as deep stream shows in normal cases. Moreover, I want all of this in the same performance (FPS) as deep stream performs normally.

@Joxis  Any response, please?
Explaining a bit more I wanna use my YOLOV5 config file with python to extract boxes using deep stream. Meanwhile, I need two things to customize my detector output.  1 -Camera frame (I will draw a circle using open CV) and bounding boxes (x1 y1, x2, y2) to plot them differently. Sorry, if you don't understand my last comment.

The current implementation does not support multiple video streams yet. Most code is already in place to make this possible but some final adjustments are needed. Did you already manage to get the boilerplate working with multiple streams? Or did you only use the standard sample application?

Meanwhile, I am still trying to manage multistream in python. I want to ask is there any specific thing that I have to edit in app/pipeline.py. Also the current implementation is with tracker but I don't need it for now. So how should I replace my pipeline without a tracker? Thanks

The _create_source_bin function should already create a bin supporting multiple streams. You will, however, have to adjust how it is called (the index parameter is currently not used). An example can be found here.
With respect to the tracker, the easiest method is to just use the IOU Tracker. It is fast and should not impact performance too much. If you really want to remove the tracker you would have to remove this line. You can also subclass the base pipeline and overwrite the _create_tracker function to perform nothing.

Thanks for the details that you provided. I start to make changes. I wanna ask one question that while creating  source_bin using _create_source_bin function, gow many times we  have to call _create_element function. In offical implimentation the statement elm = Gst.ElementFactory.make(factory_name, name) is used one time while creating each element but boilerplate implimentation calls _create_element function multiple times. How can I mange while creating source bins in a loop. I m going in this way: I also highlighted  _create_element calls by comment and dots
def _create_elements(self, num_elements):

        for index in range(num_elements):

            self.source_bin = self._create_source_bin(index)
            self.streammux = self._create_streammux()

            self.pgie = self._create_element("nvinfer", "primary-inference", "PGIE") # ....... 1 time
            self.pgie.set_property('config-file-path', self.pgie_config_path)
            self.tracker = self._create_tracker()

        # Use convertor to convert from NV12 to RGBA (easier to work with in Python)
            self.nvvidconv1 = self._create_element("nvvideoconvert", "convertor1", "Converter 1") #  ..........  2 time
            self.capsfilter1 = self._create_element("capsfilter", "capsfilter1", "Caps filter 1") # ............. 3 time
            self.capsfilter1.set_property("caps", Gst.Caps.from_string("video/x-raw(memory:NVMM), format=RGBA"))

        if self.enable_osd:
            self.nvosd = self._create_element("nvdsosd", "onscreendisplay", "OSD") #  .......... 4 time

        self.queue1 = self._create_element("queue", "queue1", "Queue 1") # ............ 5 time

        if self.output_format.lower() == "mp4":
            self.sink_bin = self._create_mp4_sink_bin()
        if self.output_format.lower() == "rtsp":
            self.sink_bin = self._create_rtsp_sink_bin()

        if not is_aarch64():
            # Use CUDA unified memory so frames can be easily accessed on CPU in Python.
            mem_type = int(pyds.NVBUF_MEM_CUDA_UNIFIED)
            self.nvvidconv1.set_property("nvbuf-memory-type", mem_type)
            self.tiler.set_property("nvbuf-memory-type", mem_type)
            self.nvvidconv2.set_property("nvbuf-memory-type", mem_type)


[New Feature] ES VectorStore

Description
已经验证通过的功能：
1）可以新建知识空间（支持英文数字组合，全中文组合的名称； 不支持中英文或者中文和数字字符混合的名称）
2）可以上传文档进行EMBEDDING。
3）可以逐个删除上传的每一个文档。
4）可以搜索对话。(引入了jieba分词算法jieba.analyse.textrank，后续可以根据语义优化，以便于更精准查找。)
How Has This Been Tested?
.env 文件里面配置如下四个变量后，其余的使用流程同"chat knowledge"知识对话使用流程。
VECTOR_STORE_TYPE=ElasticSearch
ElasticSearch_URL=<IP_ADDRESS>
ElasticSearch_PORT=9200
ElasticSearch_USERNAME=elastic
ElasticSearch_PASSWORD=i=+iLw9y0Jduq86XTi6W
为了方便方便查看es搜索匹配到的知识内容，elastic_store.py 代码文件写了一个“es_search_results.txt”到项目根目录下，若不需要，注释代码即可 (关键词：result_file) 。
Checklist:

[ ok ] My code follows the style guidelines of this project
[ ok ] I have already rebased the commits and make the commit message conform to the project standard.
[ ok ] I have performed a self-review of my own code
[ ok ] I have commented my code, particularly in hard-to-understand areas
[ ok ] I have made corresponding changes to the documentation
[ ok ] Any dependent changes have been merged and published in downstream modules

@IamWWT  Hi, the Code style check failed. please use the black . and make fmt command to fix this.  If you have problem about this, you can communicate with us at any time.

@IamWWT Hi, the Code style check failed. please use the black . and make fmt command to fix this. If you have problem about this, you can communicate with us at any time.

新的分支： 8b8a9b92a17de89f10fa36efdcfb9af53fa1aea4
新的分支代码fix的执行方式：
1）black .
2）yapf  -i dbgpt/storage/vector_store/elastic_store.py

hi, @IamWWT, I saw that you formatted other files that are not related to es_vector_store. Can you modify the files related to es?

hi, @IamWWT, I saw that you formatted other files that are not related to es_vector_store. Can you modify the files related to es?


Page is broken

The HTML on this page is broken at the moment (verified on Edge and Chrome).

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

ID: b3e9b04c-e93b-7ea5-4ac7-39276428241e
Version Independent ID: a715ee2f-c518-ffd7-1d2f-3faf264877e9
Content: Deploy hybrid connectivity between Skype for Business Server and Skype for Business Online
Content Source: Skype/SfbServer/skype-for-business-hybrid-solutions/deploy-hybrid-connectivity/deploy-hybrid-connectivity.md
Product: skype-for-business-itpro
GitHub Login: @CarolynRowe
Microsoft Alias: crowe

@TobieFysh - thank you very much for taking the time to report this. We recently migrated all the content from TechNet to this open source system on GitHub and surfaced on docs.microsoft.com. This must have been a result of that migration. We are working to get this resolved. Thanks again for taking the time to report and make the docs better for the community!

I just had a look at the page, and the problem seems to be resolved now. Please reopen if this isn't the case.


Prisma doesn't work in the Cloudflare Miniflare 2 Jest test environment

Bug description
Hey folks, when instantiating Prisma in the Miniflare 2 Jest environment, this error is displayed:
PrismaClient is unable to run in this browser environment, or has been bundled for the browser (running in `node`).

Reproduction: https://github.com/vladinator1000/prisma-miniflare-2-bug
I'm not sure what's causing this for me, I know Prisma has an extensive test suite and I wonder how you've handled your Cloudflare tests. Looks like Cloudflare are all in on Miniflare 3, but the testing story is still in development. They just redirect to the Miniflare 2 testing docs:

Miniflare 3 page that recommends legacy: https://miniflare.dev/testing
Miniflare 2 testing docs: https://legacy.miniflare.dev/testing
How to reproduce

Clone this reproduction repo https://github.com/vladinator1000/prisma-miniflare-2-bug
Run npm run itest

Expected behavior
Prisma connects to the database in the Miniflare environment.
Prisma information

Any minimal schema can be used
generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

model User {
  id   Int    @id @default(autoincrement())
  name String @db.VarChar()
}

import { PrismaClient } from "@prisma/client"

describe('static import', () => {
  test('can instantiate Prisma', async () => {
    const prisma = new PrismaClient()
    expect(prisma).toBeTruthy()

    await prisma.$disconnect()
  })
})

Environment & setup

OS: WSL
Database: Postgres
Node.js version: v21.6.1

Prisma Version
5.9.1

Prisma currently does not work in Cloudflare Workers, except if you use Prisma Accelerate or are part of an Early Access for Edge Function support (which you can register for via the survey here: https://github.com/prisma/prisma/issues/21394). Let me know when you signed up, and I can fast track you to make sure you can see if that makes it work via miniflare 2.

@janpio The reproduction repo is for local testing with the normal Prisma with Jest, yup. Miniflare shouldn't care what Prisma is used in my opinion, for testing ergonomic reasons.
For what it's worth, I spent my morning porting my project to Vitest and it worked! I took my learnings and created this example: https://github.com/vladinator1000/prisma-vitest-miniflare
I'm happy to close this issue now, I hope it's useful to someone!

I assume that miniflare 2 is both telling Prisma that it is a browser like environment like workers, but also that it is running on Node - which leads to the slightly confusing error message you got.
Would be nice if you could try the early access I just sent you an email about with that old miniflare 2 setup, if that also solves that problem that existed with that. I expect some users will still need to use miniflare 2 with Jest for the ner future.

@janpio a little update on Prisma + vitest-pool-workers in case you're interested: https://github.com/cloudflare/workers-sdk/issues/5127#issuecomment-1981520239


Bower error: Package retext-keywords not found

When running bower install retext-keywords, I get the error ENOTFOUND Package retext-keywords not found. I would also appreciate some help on getting retext-keywords running on the client-side as per the demo.

It seems i’ve forgotten to publish to bower. I just did, so you should be able to download retext-keywords from the registry.
However, as bower is just a package manager, you still need to combine the scripts you want (retext-keyword’s, and retext’s dependencies, and your script) into one file. I recommend using something like webpack or browserify. Script tags won’t work as retext and retext-keywords use CommonJS, thus, a build step.
To do that, I recommend using duo:
git clone git@github.com:wooorm/retext-keywords.git
cd retext-keywords
git checkout gh-pages
duo --stdout index.js > build.js

And then just open the index.html file in a browser.

Thank you @wooorm - will give it a shot. Love the work you've done.

Your steps explain everything I needed to know - thanks again.

Great to hear :) Just create a PR or e-mail me if you’ve got more questions!


fix mkdocstrings usage/reqs

also removed some unnecessary CSS
For the record, Sphinx is the better choice for API docs; mkdocs is very limited in comparison. I've been working on a Sphinx theme called sphinx-immaterial that is forked from mkdocs-material theme, but we are still in beta...

I modified the mkdocs CI to run on all branches and verify mkdocs build isn't broken. It will only publish the docs (to the gh-pages branch) from the master branch, like it has been.


[docs]Fix runtime error README.md example

version
langchain==0.2.5
langchain-anthropic==0.1.20
langgraph==0.1.9

AS-IS (Error)
# Define the tools for the agent to use
@tool
def search(query: str):
    """Call to surf the web."""
    # This is a placeholder, but don't tell the LLM that...
    if "sf" in query.lower() or "san francisco" in query.lower():

        return ["It's 60 degrees and foggy."]
    return ["It's 90 degrees and sunny."]

BadRequestError: Error code: 400 - {'type': 'error', 'error': {'type': 'invalid_request_error', 'message': 'messages.2.content.0.tool_result.content.0: Input should be a valid dictionary or object to extract fields from'}}
To-be
# Define the tools for the agent to use
@tool
def search(query: str):
    """Call to surf the web."""
    # This is a placeholder, but don't tell the LLM that...
    if "sf" in query.lower() or "san francisco" in query.lower():

        return "It's 60 degrees and foggy."
    return "It's 90 degrees and sunny."

Result:
"Based on the search results, I can tell you that the current weather in San Francisco is:\n\nTemperature: 60 degrees Fahrenheit\nConditions: Foggy\n\nSan Francisco is known for its microclimates and frequent fog, especially during the summer months. The cool temperature and foggy conditions are quite typical for the city. Remember that the weather can change throughout the day, so if you're planning any activities, it's a good idea to dress in layers and be prepared for potential changes in temperature and visibility.\n\nIs there anything else you'd like to know about the weather in San Francisco or any other information I can help you with?"
Done😎

great catch, thanks! could you please also update in libs/langgraph/README?

Done :)


"Request-URI Too Long" error when calculating code coverage

I am running into this error when ApexUnit is trying to calculate the cove coverage from the manifest file specified. I'm assuming it's because we have 100's of classes in the manifest file. Here's a snippet from the log:
[com.sforce.cd.apexUnit.ApexUnitRunner.main()] INFO com.sforce.cd.apexUnit.client.fileReader.ApexManifestFileReader - Reading from Manifest files: sourceClasses.txt
[com.sforce.cd.apexUnit.ApexUnitRunner.main()] INFO com.sforce.cd.apexUnit.client.fileReader.ApexManifestFileReader - Reading Manifest file from location : sourceClasses.txt
Mar 13, 2017 8:48:06 PM org.apache.commons.httpclient.HttpMethodBase getResponseBody
WARNING: Going to buffer response body of large or unknown size. Using getResponseBodyAsStream instead is recommended.
[com.sforce.cd.apexUnit.ApexUnitRunner.main()] INFO com.sforce.cd.apexUnit.client.codeCoverage.WebServiceInvoker - Status code : 414   Status message from the get request:Request-URI Too Long Reason phrase: Request-URI Too Long
[com.sforce.cd.apexUnit.ApexUnitRunner.main()] ERROR com.sforce.cd.apexUnit.ApexUnitUtils - Code coverage metrics not computed. Null object returned while processing the JSON response from the Tooling API
[com.sforce.cd.apexUnit.ApexUnitRunner.main()] INFO com.sforce.cd.apexUnit.ApexUnitUtils - Shutting down ApexUnit

blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px #715FFA solid !important; padding-left:1ex !important; background-color:white !important; } I will setup a meeting with you to get details about the job running the build and depot.
Sent from Yahoo Mail for iPhone
On Monday, March 13, 2017, 7:01 PM, roby-handinhand<EMAIL_ADDRESS>wrote:
I am running into this error when ApexUnit is trying to calculate the cove coverage from the manifest file specified. I'm assuming it's because we have 100's of classes in the manifest file. Here's a snippet from the log:
[com.sforce.cd.apexUnit.ApexUnitRunner.main()] INFO com.sforce.cd.apexUnit.client.fileReader.ApexManifestFileReader - Reading from Manifest files: sourceClasses.txt
[com.sforce.cd.apexUnit.ApexUnitRunner.main()] INFO com.sforce.cd.apexUnit.client.fileReader.ApexManifestFileReader - Reading Manifest file from location : sourceClasses.txt
Mar 13, 2017 8:48:06 PM org.apache.commons.httpclient.HttpMethodBase getResponseBody
WARNING: Going to buffer response body of large or unknown size. Using getResponseBodyAsStream instead is recommended.
[com.sforce.cd.apexUnit.ApexUnitRunner.main()] INFO com.sforce.cd.apexUnit.client.codeCoverage.WebServiceInvoker - Status code : 414 Status message from the get request:Request-URI Too Long Reason phrase: Request-URI Too Long
[com.sforce.cd.apexUnit.ApexUnitRunner.main()] ERROR com.sforce.cd.apexUnit.ApexUnitUtils - Code coverage metrics not computed. Null object returned while processing the JSON response from the Tooling API
[com.sforce.cd.apexUnit.ApexUnitRunner.main()] INFO com.sforce.cd.apexUnit.ApexUnitUtils - Shutting down ApexUnit
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

@alexiswilliams is this triaged?

Yes, we have a bug to track this issue internally.
On Mon, Mar 13, 2017 at 7:01 PM, roby-handinhand<EMAIL_ADDRESS>wrote:

I am running into this error when ApexUnit is trying to calculate the cove
coverage from the manifest file specified. I'm assuming it's because we
have 100's of classes in the manifest file. Here's a snippet from the log:
[com.sforce.cd.apexUnit.ApexUnitRunner.main()] INFO
com.sforce.cd.apexUnit.client.fileReader.ApexManifestFileReader - Reading
from Manifest files: sourceClasses.txt
[com.sforce.cd.apexUnit.ApexUnitRunner.main()] INFO
com.sforce.cd.apexUnit.client.fileReader.ApexManifestFileReader - Reading
Manifest file from location : sourceClasses.txt
Mar 13, 2017 8:48:06 PM org.apache.commons.httpclient.HttpMethodBase
getResponseBody
WARNING: Going to buffer response body of large or unknown size. Using
getResponseBodyAsStream instead is recommended.
[com.sforce.cd.apexUnit.ApexUnitRunner.main()] INFO
com.sforce.cd.apexUnit.client.codeCoverage.WebServiceInvoker - Status
code : 414 Status message from the get request:Request-URI Too Long Reason
phrase: Request-URI Too Long
[com.sforce.cd.apexUnit.ApexUnitRunner.main()] ERROR
com.sforce.cd.apexUnit.ApexUnitUtils - Code coverage metrics not
computed. Null object returned while processing the JSON response from the
Tooling API
[com.sforce.cd.apexUnit.ApexUnitRunner.main()] INFO
com.sforce.cd.apexUnit.ApexUnitUtils - Shutting down ApexUnit
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/forcedotcom/ApexUnit/issues/62, or mute the thread
https://github.com/notifications/unsubscribe-auth/AR0thhG8JGfrFnTvWgYqdHu70_GSGYqtks5rlcq2gaJpZM4Mb7Lu
.

FYI @awillia2 - I committed a fix for this to my fork of the repo here if you'd like to have a look, I simply batched up classes into groups of 100 (if there were > 100) for code coverage queries.
https://github.com/robymathew/ApexUnit/commit/12fc46cf63b8408cb493151f75bab1c898f3d9c4
Thanks,
Roby

This issue is fixed.


Pass location of source code in oracle context

This is a small change/experiment:

allowing limiting which languages a custom check oracle supports
if this list of languages is present, pass the location of the source code to the custom check functions of the programmed oracles.

The intended use of this would be to provide a semi-supported way of doing static analysis of the code of the submission. The reasons for doing this are:

We do have demand for this (and other, proper, solutions is long-term research: #392 )
We do not have to point people wanting to do this to the Python judge if this is implemented.
The maintenance burden and backwards compatibility story for us is very minimal: we just pass the path to the submission in the oracle context. We are not committing to allowing static checks specifically.

An alternative, doing this in the language-specific oracles forces the use of language-specific oracles, which are much harder to properly implement than the programmed ones.
I would certainly not include an example of using this for static checks in the documentation: we do not want to encourage this. The main question is thus do we actually want to make this possible or not?

I am inclined to merge this, as it introduces almost no maintenance overhead for us, and allows researching a better solution in peace (as this is provides a non-horrible workaround).


Support for bfloat16 in OpenBLAS

To discuss about PR
https://github.com/xianyi/OpenBLAS/pull/2559

Merged the PR after the last issues seen on Appveyor were confirmed fixed after moving the "Windows/CL" build to Azure CI. (Appveyor jobs are still shown as queued, these should provide final confirmation eventually).
It is important to note that any bfloat16 BLAS functions outside SHGEMM - even trivial functions like MIN/MAX or SUM are almost guaranteed to be wrong right now, as they are simply mapped to the corresponding single-precision implementations without even a proper cast.

Hi @martin-frbg ,
Is it possible add something like BFLOAT16 makefile flag? If the user wants BFLOAT16,  make BFLOAT16=1. By default, it is disabled.

This should certainly be possible, if one is concerned about library size. I must admit I did not see an immediate need as there should be no other cause of problems when the bfloat16 code is present but not called by user code.

Just to clarify, shgemm() is enabled by default now.

The CMAKE build already has a concept of BUILD_* options for the various data types (but I am not sure if this was ever actually tested or just seemed like a good idea), but the Makefiles do not.
My presumption was that storage-limited platforms would likely be wanting bfloat16 support for AI applications (but this is not an area I am familiar with)

Option added in #2590 - this could also be expanded to support BUILD_SINGLE etc. like netlib LAPACK does for both BLAS and LAPACK


Added prefix tag to Chrome 29

I'm working in a project I'm working in a project in which we need to develop for Chrome 29 :( and, when we used display:flex we detected that, without the prefix, the display property is not valid. I'm testing with a Chromiun 29 and I need to set the browserlist compatibility to Chrome 28 in order to get the correct prefixes.
Here there are some screenshot in order to verify the problem:

With the prefix works perfectly

That doesn't match my own test using Chrome 29 nor any other information out there (checked MDN and other information sources). Perhaps there's a difference with Chromium and Chrome in that regard, since your screenshot shows Chromium?
Also may I ask why you need to support such an old version?

We are working for an old device and  it seems that the internal browser is similar to Chrome 29.
How do you test in that Chrome version? I mean... where can I find that chrome version? not the Chromium one? I will try to figure out what is the difference between browsers but, anyway is not a big deal, we just set Chrome 28 in our browserslist and everything will work fine.

I use BrowserStack, which is a paid service that allows you to test on older browser versions. Sounds like the device you refer to is using a custom version of Chromium, which could explain the difference. Glad you have a workaround anyway!


Support Application Sharing in the console

We would need a way to share a SASS application across it's sub organizations. This should have the followings

[ ] Button to open a modal to share application
[ ] Organization selector which list out sub organization's under the given organization

Closing as a duplicate of https://github.com/wso2/product-is/issues/14293