Gulp@1 doesn't respect projects in subfolders

Required Information
Type: Bug
Enter Task Name: Gulp@1 & Gulp@0
Environment

Azure Pipelines?

account: aconn
project: Voitanos.azure-pipelines-spfx-templates

Agent - Hosted & Private: (both)

Hosted: Hosted Ubuntu 1604 / ubuntu-latest
Private: Ubuntu 16.04

Issue Description
I'm creating reusable templates for a specific project type (SharePoint Framework). Most consumers of the templates (such as this test project) will have their projects in the root repo. However, I've added another project to my repo that contains the templates. To support both scenarios, I support the consumer of the template to specify the working_directory as a path to the subfolder of the project if it is not in the root of the repo.
Task Gulp@1 does not respect the workingDirectory or gulpFile input parameters to set the path to a subfolder in the repo; it always looks for the gulpfile.js in the root of the current repo.
Task Gulp@0 does respect the gulpFile input parameter to set the path to a subfolder in the repo (IOW, this works & is what I'm doing now), but workingDirectory is not respected.

See this thread in the DevOps forum where someone from MSFT confirms the issue: https://developercommunity.visualstudio.com/content/problem/716337/unable-to-set-workingdirectory-on-gulp.html

If you look at the highlighted code in this specific commit, you'll see two tasks: script & Gulp@0. This commit is working, but it shows how the workingDirectory folder on the script task is working as expected, CD'ing into the subfolder before executing the command. However, I can't do the same thing with Gulp@*, rather I have to explicitly set the path to the gulpfile.js
From my POV, on the Gulp@1 task, the workingDirectory input property should cause the task to CD into the folder specified before running gulp or gulpjs, similar to how the ShellScript task works. As it's working now, workingDirectory is ignored in both v0 & v1 of the task & setting the gulpFile input property on v1 does not work. Further, the use of workingDirectory is not consistent in the Gulp@* tasks compared to other tasks.

@andrewconnell I'm not seeing what you're seeing, but I don't want to toss this back as "can't repro". Can you provide logs for a failing build? Run with system diagnostics enabled. Thanks!

I can still repro it... did you notice the link to the public forum post where someone from MSFT was also able to repro it?
Here's a project that shows it in action: https://github.com/Voitanos/azure-pipelines-spfx-templates. It is a public repo that contains job templates for a specific type of dev. The sample in the project demonstrates the issue.
Working sample using "Gulp@0" + workaround
The project within ./sample contains the pipeline... the master branch uses the task Gulp@0 without the workingDirectory property and building the path to the gulpfile.js using the gulpFile property as suggested for a workaround in the public forum referenced in my OP.
You can see a working build from the master branch: https://dev.azure.com/aconn/Azure Pipelines SPFx Templates/_build/results?buildId=501&view=logs&s=6884a131-87da-5381-61f3-d7acc3b91d76
Repro sample using "Gulp@1" that doesn't work using the workingDirectory property
The same exact project, except it uses Gulp@1 & the workingDirectory property. This fails as it doesn't incorporate the working directory. You'll find this in the branch repro-gulp-task-build. This commit shows what I changed from the working sample above.
You can see a breaking build from the repro-gulp-task-build branch (this has the diagnostic logging turned on... the immediate preceeding pipeline run is without diag logging turned on):  https://dev.azure.com/aconn/Azure Pipelines SPFx Templates/_build/results?buildId=568&view=logs&s=6884a131-87da-5381-61f3-d7acc3b91d76&j=412f6483-90be-5dc3-b7d8-26e9cdfda42a

If you look at the task source, you'll see that we check for the existence of the gulpfile before we set the current working directory based on the input parameter. The difference between your two pipelines is that you're setting a full path to the gulpfile for your Gulp@0 pipeline, but only relying on the working directory in the Gulp@1 pipeline. If you present the same options to the Gulp@0 task, it will fail in the same way.
Technically this is a breaking change, but Gulp@1 is still in preview and it's probably ok for me to fix this so that it sets the working folder first. I will talk to the primary maintainer on the Tasks repo and get back to you. --Also, while I'm here, it's annoying that the gulpFile input is "required" but we also provide a default value. Those are conflicting specifications in my view, and I'll fix that at the same time.

Makes sense... thanks for looking into it.
FWIW, when setting the workingDirectory parameter, I would expect the task would essentially  change the PWD => that folder before continuing to look for the gulpfile.js, similar to what the Script tag does (ex: how I'm using it)
Agreed on the requested part about the gulpFile parameter. A default value (where I suspect 99.999% of all projects use the name gulpfile.js) should make it optional.

No problem! Agreed, I'm going to change Gulp@1 to set the PWD before searching for the gulpfile. The fix will go out with our next round of deployments, which is about three weeks out.

Fixed with #11361.


ListView not Allowing Selection

In your Terminal example code, ListView with AllowMarking value is True renders checkboxes and return mark values in the list, Source.IsMarked. I use your Nuget and the ListView with AllowMarking set to True doesn't do anything. No checkbox beside list fields show up at all.

Had the same issue. Looks like the version on github is .25, but it's not on nuget yet. See:
https://github.com/migueldeicaza/gui.cs/blob/master/Terminal.Gui/Terminal.Gui.csproj
In release notes you can see:
0.25: Added new TimeField from Jörg Preiß;
Fixes for Backtab by Martin Björkström;
ListView now supports simple selection;
Bug fixes by giladlevi, Daniel Cazzulino and Marius Ungureanu;
New Application.Run of T entry point by Daniel Cazzulino;
Added various View methods to bring forward, backwards and move views in the hierarchy;
Switch to Portable PDBs by Daniel Cazzulino;
Dims can now be compared by Daniel Cazzulino; OnMenuOpen handler by giladlevi;
Various memory usage optimizations by giladlevi;
FileDialog.FilePath is now a full path by Yanwei Wang;
ISupportInitialize/ISupportInitializeNotification is now supported thanks to the work from Daniel Cazzulino;
Support for non-modal TopLevels by Daniel Cazzulino and Adrian Alonso;

I believe this is fixed. Closing.


Add a suggestion to convert keyfiles to PEM format

This commit adds additional output to the following Error
message informing the user they need to convert their existing
ssh_host key files to PEM format.
Error: Unsupported OpenSSH key type
Error reading key from '/etc/ssh/ssh_host_rsa_key'
Error: Unsupported OpenSSH key type
Error reading key from '/etc/ssh/ssh_host_ecdsa_key'

I found the suggestion to convert the existing keys to PEM format in
an issue[1] for systemd-tool and I've converted the suggestion to an
echo statement during a failure to convert the keys when running
mkinitcpio when dropbear hook is enabled.
Also this change stops swallowing this error. The new behavior is,
if dropbear convert was unable to convert any existing ssh_host
key files then generate_keys will be run. This prevents an initramfs
being generated without any host keyfiles. This is the same behavior
that occurs when NO existing ssh_host keyfiles exist.
[1] random-archer/mkinitcpio-systemd-tool#83

@grazzolini Any chance this can be merged?

There is more that could be done, but at least this helpful output would be a good stop-gap while a longer term solution is considered. I agree this should be merged.
c.f. #12.


run tests with go1.17 and go1.18

Summary

run tests with go1.17 and go1.18
follow-up https://github.com/sigstore/sigstore/pull/374/files#r845966876

Ticket Link
n/a
Release Note
NONE

need to update the required checks to replace unit tests to test / unit tests (1.18.x)/ test / unit tests (1.17.x)

Any idea why the test didn't run?

OH - is this because you renamed the test?

OH - is this because you renamed the test?

yes, need to update the checks, but I don't have admin permission for that (https://github.com/sigstore/sigstore/pull/380#issuecomment-1094296006)


python310Packages.pytest-testmon: 2.0.13 -> 2.1.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python310Packages.pytest-testmon is: Pytest plug-in which automatically selects and re-executes only tests affected by recent changes
meta.homepage for python310Packages.pytest-testmon is: https://github.com/tarpas/pytest-testmon/
meta.changelog for python310Packages.pytest-testmon is: https://github.com/tarpas/pytest-testmon/releases/tag/v2.1.0
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.1.0 with grep in /nix/store/h8mp27rbaf3xxs52x3z9hq92wdi53364-python3.10-pytest-testmon-2.1.0
found 2.1.0 in filename of file in /nix/store/h8mp27rbaf3xxs52x3z9hq92wdi53364-python3.10-pytest-testmon-2.1.0

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath
python310Packages.pytest-testmon
python311Packages.pytest-testmon

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/h8mp27rbaf3xxs52x3z9hq92wdi53364-python3.10-pytest-testmon-2.1.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python310Packages.pytest-testmon https://github.com/r-ryantm/nixpkgs/archive/dc1af8a4366507a8732150a2197d704b2cd0729f.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/dc1af8a4366507a8732150a2197d704b2cd0729f#python310Packages.pytest-testmon

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/h8mp27rbaf3xxs52x3z9hq92wdi53364-python3.10-pytest-testmon-2.1.0
ls -la /nix/store/h8mp27rbaf3xxs52x3z9hq92wdi53364-python3.10-pytest-testmon-2.1.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

2 packages built:

python310Packages.pytest-testmon
python311Packages.pytest-testmon

Maintainer pings
cc @dmvianna for testing.

The license is changed to MIT from AGPL3.
https://github.com/tarpas/pytest-testmon/commit/e6fd3abcb423ae7dae91c286981c0ca0fd822e88

Result of nixpkgs-review pr 266779 run on x86_64-linux 1

4 packages built:

python310Packages.pytest-testmon
python310Packages.pytest-testmon.dist
python311Packages.pytest-testmon
python311Packages.pytest-testmon.dist


wont let me build a branch name with "@" in it

& I wanna.

Apparently this is a limitation of docker tags, which must match [a-z0-9]+(?:[._-][a-z0-9]+)*. We could disable the branch tag if it doesn't match this regex, but then we'll lose the caching advantage. Might be better to just error out with a better error message.

Another option would be to just use a hash of the branch name for the cache tag (but still push the branch for convenience, if it matches that regex).


Workshop version does not include all content

On a fresh linux srcds install and a clean GMod installation it seems like it does not properly mount content from Workshop.
On first join, there were missing UI textures and error models (roaches). After a server restart, I had the UI textures but the roaches were still errors.
I unpacked the .gma and it seems to be packed properly.

With the previous update the content folder structure was altered which caused the assets to load only on server if the workshop version was used.
Fixed in PR #214


Unable to run demo.ipynb on google collab

I am trying to run the demo file on collab but no view is being loaded on the viewer.
Can anyone please help me out. It's showing training is finished but I can't see anything in the viewer.

Did you refresh the viewer?

I refreshed it at that time but then also it didn't work but now I ran the collab again and it's working fine now.


Change url used in getActionRequest

The url use should be "https://nla.zapier.com/api/v1/dynamic/" when calling an action.
If not we have a 400 Bad Request Error.

@agola11 check this one

@GautierT I'm not getting any bad request errors, everything is still working for me with the existing endpoint. In fact, even the Zapier team wrote our python integration and even they used the non-dynamic endpoint in their wrapper: https://github.com/hwchase17/langchain/blob/master/langchain/utilities/zapier.py
Where did you see that it should be v1/dynamic?


Prune tasks that don't have the specified command

With this change, turbo will no longer schedule tasks for which no scripts entry exists. This includes not scheduling dependencies of those tasks.
Note that this is a breaking change. Some tasks that are run currently (dependencies of non-existent tasks) will no longer be run. The workaround is to add no-op scripts to packages to opt into the old behavior.
Fixes #937

We should cut 1.2.9 latest before merging

Marking as 'on hold' until I get a chance to add a flag to the new behavior

This includes not scheduling dependencies of those tasks.

How does this work out with transitive dependencies? If a package has no "build" script but has dependencies that do, and the pipeline specified "^build", would it do anything? If a package has a "test" script and the pipeline depends on "build", would it then fail to test because it has no empty "build" script?
If that line of thinking is correct, this change feels a little counterintuitive. If I mark that a task has a dependency in my configuration it doesn't feel like I should have to pass a flag to get Turbo to do the thing I asked it to. Does this make any sense?

@ObliviousHarmony I understand where you're coming from. The way it works right now, transitive dependencies will be run, even if the actual thing you asked for doesn't exist. This allows for packages to implicitly act as "synthetic" tasks by virtue of their dependencies.
This change would require you to make those cases explicit. If you have a package foo with no build script, running turbo run build --filter=foo would be a no-op. You asked to build foo, but foo has no build, so there is nothing to do. If, on the other hand, what you really want is to build foo's dependencies, you can specify that: turbo run build --filter=foo^.... That will run build on all of foo's dependencies (that have a build script defined).
For your test example, if you need your dependencies built, but not the package you are testing (because it doesn't have a build script), depend on ^build.
The benefit is that for tasks that don't exist, you will no longer be doing the dependency work that will end up being irrelevant. You can see some of the confusion caused by the current behavior in #937
I would encourage you to chime in on that issue with your perspective. Is the existing behavior something you are currently relying on? If you can share, I'd like to hear what the use case is, and whether or not an adjusted --filter or synthetic no-op task would suffice as a workaround, or if it's a larger issue. If there is a situation where you cannot express what tasks you want run, we should a) know about it and b) consider a flag going forward to opt in to the current behavior, if that is solving the problem for you now.

Thanks for the reply @gsoltis, I went ahead and left a comment on the issue to contain the discussion there.

At this point it would have far-reaching consequences to change this behavior and it's not going to land from this PR:

This is in Go.
Many users explicitly rely on inserting synthetic tasks into the graph.

In order to consider doing this we would need to:

Write this behavior in Rust.
Introduce "just ^".

And, to get people out of the current state, one of these things has to happen:
a. Create a codemod that inserts empty script tasks into package.jsons. (This feels gross since it has consequences all over the repo.)
b. Provide a way to opt-in to the "don't schedule noneffective tasks." Create a codemod that splits the graph into "effective" and "noneffective" graphs. Reserialize the graph into dependsOn after exposing the complexity to the user.
I'm closing this PR since this PR in particular doesn't have a path to production. The possibility of doing this work still remains.


Mandatory fields check

JIRA link (if applicable)
https://tools.hmcts.net/jira/browse/PRL-918
Change description
DA refactoring
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[x] No

Closing, will be merged as part of https://github.com/hmcts/prl-cos-api/pull/225


Remove "pybullet build time" stamps

This is annoying
pybullet build time: Sep 20 2020 23:49:22
pybullet build time: Sep 20 2020 23:49:22
│              0/100 │               3.99 │                202 │              39.89 │            4lane_t │      basic.rou.xml │<PHONE_NUMBER>51023167 │ 185.39 - Agent-007 │
pybullet build time: Sep 20 2020 23:49:22
pybullet build time: Sep 20 2020 23:49:22
pybullet build time: Sep 20 2020 23:49:22
│              1/100 │               4.72 │                202 │              47.25 │            4lane_t │      basic.rou.xml │<PHONE_NUMBER>51023167 │ 185.39 - Agent-007 │
pybullet build time: Sep 20 2020 23:49:22
pybullet build time: Sep 20 2020 23:49:22
pybullet build time: Sep 20 2020 23:49:22

This was addressed with #203.


Player with black bars on the sides

Boa tarde. Gostaria de uma ajuda para o meu player que fica com essas barras laterais ao lado.
A parte do código:

site: http://sejamaiorlab.web2335.uni5.net/diferencial_criativa/

no css da pagina vc pode fazer isso:
video {
   object-fit: fill;
}

@thiagopnts @pqray talvez seja melhor usar
video {
    object-fit: cover;
}

Dessa forma não há distorção da imagem devido à mudança de aspecto

@pqray gostaria apenas de te pedir para abrir issues em inglês, se possível. Temos usuários de vários lugares do mundo, então o ideal seria que todos pudessem entender os problemas e como solucioná-los.
Posso editar essa issue para traduzi-la para o inglês?
Translating: I'd like to ask you to open issues in english whenever possible. We have users from all over the world, so it would be better if everyone can understand the issues and how to fix them.
May I edit this issue to translate it to english?

Pode sim!

Muito obrigada gente, resolveu!!!

I still have a problem. In mobile, the video does not start automatically, the user has to click play to start even with autoplay on the desktop. What do I do?

@pqray On iOS and Android, playback of video must be initialized with a user action, meaning a tap or click. Therefore, autostart is not possible for mobile, but it should work on desktop if autoPlay parameter is set to true.

@pqray do you see any errors on console? have you tried this?

@kslimani I made a pull request solving the autoplay issue on iOS (and some Android devices).
https://github.com/clappr/clappr/pull/1260

@tomas2387 I think your PR has a good point about playinline video element.
I think you are referring to Safari 10.0 release note :

When the playsinline property is specified, Safari on iPhone allows videos to play inline. Videos without the property will commence playback in fullscreen, but users can pinch close on the video to continue playing the video inline.
On iOS, videos without audio tracks or with disabled audio tracks can play automatically when the webpage loads.

Maybe if "html5" playback option has playInline property set to true, we should also add the playsinline video element attribute (in addition of x-webkit-playsinline attribute).
I have not tested yet, so i don't know if this would introduce bugs. Maybe open a new issue for this.

About autoplay, i think (but i may be wrong !) that your current PR breaks the default player behaviour. Maybe you should propose something like this :
If player autoPlay property is set to true and meet the following conditions :

resolved playback is "html5_video" (or extends HTML5Video ?)
current browser is Safari and version is greater than or equal to 10
player mute property is set to true

Then starts video when playback constructor is done.
Maybe also open another issue for this.


Update description in setup.py

Description
The description in setup.py was outdated and I've aligned it with the one within the repository.

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.


[GSSoC'23] Restyle the Nabvar

Items in the navbar are not aligned properly and there is no proper spacing. I would to work on this issue.
Please assign this issue to me under gssoc23.

I want to work for on this issue under jwoc , please assign me


Enhance controller setup based on available CRDs

What this PR does / why we need it:
This enhances the setup of the InferenceService controller and the InferenceGraph controller. Instead of relying on the defaultDeploymentMode configuration to determine what CRDs to watch, the setup now checks whether KNative Services and Istio VirtualServices are available in the cluster and setup the watches (invoke Owns) accordingly.
This enhancement has the following advantages:

A crashloop is prevented if the CRDs are missing in the cluster. The user would still be able to create InferenceServices by taking care of annotating the ISVC for RawDeployment mode.
If RawDeployment mode is configured as the default mode, the controllers would still watch for KNative and Istio resources if these components are available. This will let the controller watch for changes for the dependent resources if the user uses Serverless mode for some of the InferenceServices.
In the InferenceService controller, the watch for the VirtualServices is still conditioned to the value of the disableVirtualHost configuration.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #3470
Type of changes
Please delete options that are not relevant.

[x] New feature (non-breaking change which adds functionality)

Feature/Issue validation/testing:

Install KServe in a cluster where Istio and KNative are missing, and still configure Serverless as default deployment mode. See the controller outputting in the logs messages like The InferenceGraph controller won't watch serving.knative.dev/v1/Service resources because the CRD is not available. and verified there no errors are logged.

Verify that InferenceServices with the RawDeployment mode annotation deploy successfully.

Do a regular Serverless install but change the default deployment mode to Raw

Verify that an InferenceService can both be created in Raw mode and Serverless mode.
For the InferenceService deployed in Serverless mode, verify that modifying the KServe created VirtualService and/or the KNative Service would trigger a reconcile and KServe would fix the resources.

Checklist:

[ ] Have you added unit/e2e tests that prove your fix is effective or that this feature works?
[ ] Has code been commented, particularly in hard-to-understand areas?
[ ] Have you made corresponding changes to the documentation?

@israel-hdez
Nice job with the PR, I have a couple of questions

What about a scenario where Knative/Istio are not installed when KServe is installed but then they are? I think it is fine to mention this scenario is not supported for now if it makes too complex this PR, I just want to understand the overall behaviour.
Have you tested the error if a user tries to deploy a Serverless deployment InferenceService without having Knative after this PR? Before the PR the controller was failing checking the CRD but what about now? I would expect a proper error in the InferenceService status/event to mention that it is not possible to deploy but at least that the controller doesn't crash and the IS status reports the failed status

@israel-hdez Nice job with the PR, I have a couple of questions
* What about a scenario where Knative/Istio are not installed when KServe is installed but then they are? I think it is fine to mention this scenario is not supported for now if it makes too complex this PR, I just want to understand the overall behaviour.

I think detecting the change in the setup would add some complexity. I'm not sure if it is worth to do that work, given changes to the stack may not be that common.
For this PR, if a Serverless setup is done after KServe is installed, the only additional action needed would be to restart the KServe controller pod and it should start using KNative as normally.

* Have you tested the error if a user tries to deploy a Serverless deployment `InferenceService` without having Knative after this PR? Before the PR the controller was failing checking the CRD but what about now? I would expect a proper error in the `InferenceService` status/event to mention that it is not possible to deploy but at least that the controller doesn't crash and the IS status reports the failed status

I just tried it. There is no crash, although the controller will try to reconcile continuously. I do see that it tries to write something in the status field, but it fails for some reason (looks like a bug) - so, looks like the error message is hidden by another one.
I agree that it should fail more gracefully. Given the detected CRDs it shouldn't reconcile continuously a Serverless InferenceService when the stack is absent. I'll do the needed code changes for this.

I would expect a proper error in the InferenceService status/event to mention that it is not possible to deploy

I just added some code to abort reconciliation early and log an Event that should be visible with kubectl describẹ .

@Jooho @terrytangyuan @spolti The code is ready. Please, do another review round.
I added tests around the impacted Reconcile functions.
I failed to find a way to add tests for the SetupWithManager functions. If you know how to do it, I'll appreciate your advice.

@terrytangyuan @spolti I finally had time to finish this PR.
Please, take another look at this.

/lgtm

I pushed an empty commit to re-run CI, which is now passing.
@spolti @terrytangyuan Please, re-approve if you are still OK with this PR.

Per prow instructions:
/assign @yuzisun

/lgtm

@yuzisun This is rebased, and CI is passing.

Thanks @israel-hdez for the nice PR descriptions for easier review!
/approve


feat: beacon api

https://ethereum.github.io/beacon-APIs
using parent of this commit for union deps: unionlabs/union@4b1b221

The latest builds are failing because there is no space left in the action runners.
There was an error validating Starlark code
Error while validating final environment of script
        Caused by: Failed fetching the required image 'chainsafe/lodestar:latest'.
        Caused by: An error occurred pulling image 'chainsafe/lodestar:latest'
 --- at /home/circleci/project/container-engine-lib/lib/backend_impls/metrics_reporting/metrics_reporting_kurtosis_backend.go:38 (MetricsReportingKurtosisB
ackend.FetchImage) ---
Caused by: An error occurred fetching image 'chainsafe/lodestar:latest'
 --- at /home/circleci/project/container-engine-lib/lib/backend_impls/docker/docker_manager/docker_manager.go:1310 (DockerManager.FetchImage) ---
Caused by: Failed to pull Docker image 'chainsafe/lodestar:latest' from remote image repository
 --- at /home/circleci/project/container-engine-lib/lib/backend_impls/docker/docker_manager/docker_manager.go:1251 (DockerManager.FetchImageIfMissing) ---
Caused by: Tried pulling image 'chainsafe/lodestar:latest' but failed
 --- at /home/circleci/project/container-engine-lib/lib/backend_impls/docker/docker_manager/docker_manager.go:1641 (DockerManager.pullImage) ---
Caused by: ImagePull failed with the following error 'failed to register layer: write /usr/app/node_modules/@types/dns-packet/node_modules/@types/node/trac
e_events.d.ts: no space left on device'
 --- at /home/circleci/project/container-engine-lib/lib/backend_impls/docker/docker_manager/docker_manager.go:2334 (pullImage) ---

Looking through tmate session, the target directory takes up to 8.4 GB of data.

Currently, it takes around 15 mins to run the tests. Should we run the tests in parallel? We probably just need to assign unique enclave names to each kurtosis runs.


Bridgy Publish to Flickr: ignore fallback content inside video tags

Minor nit, not sure of the best way to fix this:
This POSSE copy: https://www.flickr.com/photos/tantek/24235088549/
starts with the text "a video", which is from inside the <video> tag with u-video.
According to HTML5, if a user agent (browser, crawler - Bridgy's HTML parsing code in this case) supports the video tag, then it must ignore the content inside, since that's only for browsers / UAs that don't support the video tag.
Alternatively you could pushback and say Bridgy requires no text content inside video tags, which is a bit limiting for publishers, but may actually be the 90%+ case (no idea, just guessing).

good point! thanks for filing.

Looks like the "Preview" view when manually submitting a URL to POSSE on https://brid.gy/flickr/39039882@N00# still starts with "a video".

fixed. thanks for reporting!


AMD graphical glitch on newer kernels (6.7+)

Describe the bug
A graphical glitch that happens semi-randomly, something that may be triggering it is moving a window from a Screen to another, the glitch can come and go for while moving windows but once it has been triggered a first time, it stays.
I can say with confidence that this bug started happening after the 6.7 kernel release, and only on the newer kernels (after triggering it many times and it not being triggered when i launch an lts kernel, when my workload has been practically the same)
Couldn't find anything alarming when reading the systemd journal
Unfortunately, also couldn't find something related on https://bugs.kde.org/
Operating System: NixOS 24.05
KDE Plasma Version: 5.27.10
KDE Frameworks Version: 5.113.0
Qt Version: 5.15.12
Kernel Version: 6.7.1
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 7840U w/ Radeon 780M Graphics
Memory: 30.6 GiB of RAM
Graphics Processor: AMD Radeon Graphics

Screenshots
Not really a screenshot, it's a picture of the screen since the glitch is not visible on screenshots.
It does however appear on both of the connected displays (one of which is the laptops internal display), but not necessarily both at the same time.

Notify maintainers
Not sure exactly who to ping, I think @K900 might be concerned (sorry if not) I couldn't find the plasma default.nix

Add a :+1: [reaction] to [issues you find important].

That just looks like a link issue, have you tried kernel 6.7.2 yet? There's some amdgpu DisplayPort fixes in there.

I was able to reproduce this glitch on 6.7.2 kernel.
Additional information
Disabling one of both displays, seem to fix the glitch (until the display is re-enabled) so it does seem to be closely related to having multiple displays.

I'm pretty sure it's an AMD issue:  https://gitlab.freedesktop.org/drm/amd/-/issues/3097
Will try the patch soon
Should I close this issue ?

I can confirm that the patch indeed fixed the issue

I can confirm that the patch indeed fixed the issue

I have the same issue. What patch exactly worked for you?

The 3 patches are now upstream, on 6.8-rc5 (which  linux_testing now follows)
Otherwise you can apply them manually: https://gitlab.freedesktop.org/drm/amd/-/issues/3097#note_2267750


run_rustc respect j option

It respects desires -j option for make which calls it, and doesn't owerride it by -j 3.
Thus, it also uses ?= to initialize value of MRUSTC and MINICARGO that allows to override it to system installed mrustc and minicargo.
And it adds all paths which can be overriden to system one to .PHONY.

This PR is required and used by https://github.com/macports/macports-ports/pull/13817

Side note - This PR doesn't seem to do anything about handling -j properly, can you rename it to something more fitting of the content?
Also - Please don't force push so often, I get a notification for every one with no indiciation of what changed.

@thepowersgang to make things simpler: I've split this PR into two. This one that matches the naming and https://github.com/thepowersgang/mrustc/pull/237
I also significant simplified it and avoid touching dependencies


Created a Web Demo using Gradio

Changes:

added demo.py for launching a local gradio demo
requirements.txt (instead of requirement.txt) with gdown, pillow, gradio and correct versioning for torchvision
example_images/ for the web demo
changed the readme to include the (permanent) link for the hosted demo and a gif of the interface.

Do you need to keep files in .idea?
If not, I will delete these.

You can delete them

Please feel free to change the README


Generators support

Would be very useful and insanely cool, if AVA supported generators by default. I am ready to implement this right away. What does everyone think of that?

What does that entail? Can you show an example test of how it would look? What changes would need to be made in AVA?

Sorry, should've clarified things more. No major changes are required to make this work and the API would remain exactly the same.
Example test with generators:
const test = require('ava');
const fs = require('mz/fs'); // promisified fs

test('generator support', function * (t) {
  let content = yield fs.readFile('/path/to/some/file', 'utf-8');

  t.same(content, 'expected content of the file');
});

To support generators, co module would be used, because it's the most mature and simple. I've been using it for almost a year now and never encountered any issues.
Also, because Ava already supports promises, I expect generator support to be very easy to add, because co returns a simple promise to run a generator function:
const co = require('co');

function * exampleTest () {
  // body of generator function
}

// to run a generator, simply pass it to co
co(exampleTest).then(function () {
 // generator function completed execution
}).catch(function (err) {
  // generator function threw an error
});

I believe I will have some free time to build a PR today

As a workaround, I currently do the following:
const ava = require('ava');
const co = require('co');

test ('generator fn', function * (t) {
  // wow
});

function test (title, fn) {
  ava(function () {
    return co(fn.apply(null, arguments));
  });
}

It would be easy if use async-done + co combo under the hood. But if it's done, we should forget "sync" test - in which i dont see value and dont see problem. But also with that it comes other problem - assertion, it cant stay as it is now (passing t to the test) - in which, again, i dont see problem, because this would be possible
var test = require('ava');

// which would be just `claim`
var assert = test.assert;

// or you can just use any other assertion library
// by requiring it.

test('foo bar', function (done) {
  assert.true(true, true)
  done() // like `t.end()`
})

Or default (builtin) assertion can be in the context of the test function - i chose that way and built benz - which is thin layer on top of async-done and now-and-later (tools behind undertaker) with passing custom context.

@vdemedes Still not sure what's needed to do in AVA. Would AVA have to have co as a dependency? With the recent builtin ES2015 support, wouldn't generators just work out of the box? AVA already support promises, which is what co returns.

@sindresorhus
What's needed to do in AVA?

AVA would need to detect if a test is a generator function using is-generator-function and if it is, convert it to a promise using co. And that's it, since AVA already supports promises.
Would AVA have to have co as a dependency?

Yes, co would need to be added as a dependency.
With the recent builtin ES2015 support, wouldn't generators just work out of the box?

Nope, they wouldn't and here's why ;) Generators are just functions that can be run step-by-step:
function * generator () {
  yield 1; // blocks until .next() is called
  yield 2; // blocks until .next() is called
  yield 3; // blocks until .next() is called

  // all done
}

let fn = generator();

fn.next().value; // 1
fn.next().value; // 2
fn.next().value; // 3
fn.next().value; // undefined, function completed

This functionality in its "plain" form does not give us many benefits, but the brilliant co library uses generators to allow writing asynchronous code in a synchronous style. Normally, you would pass generators to co, but it can also accept promises:
const co = require('co');

function * generatorFn () {
  return 'some value';
}

function promiseFn () {
  return Promise.resolve('some value');
}

// yield does not work outside of generators
co(function * () {
  let first = yield generatorFn(); // 'some value'
  let second = yield promiseFn(); // 'some value'
});

In practice, generators allow me to avoid code like this:
User.findOne({ email<EMAIL_ADDRESS>})
  .then(function (user) {
    let name = user.get('name');

    console.log('My name is', name);
  })
  .catch(function (err) {
    // error
  });

and write code like this:
try {
  let user = yield User.findOne({ email<EMAIL_ADDRESS>});
  let name = user.get('name');

  console.log('My name is', name);
} catch (err) {
  // error
}

Hmm, wouldn't it be better to enable the async/await Babel transformer? async/await is the future of async programming, not hacked up generators.

The thing is, nobody uses async/await yet and god knows when it will land in node.js. But generators are widely used today and there are many packages for them. There is also a wonderful Koa framework, specifically for apps that use generators.
Also, it will not add any overhead to AVA, because the implementation would be fairly trivial. I will send a PR later today to demonstrate this, so you can see the end result ;)

Alright. PR welcome :)

The thing is, nobody uses async/await yet and god knows when it will land in node.js.

:+1:
One fairly simple and built in seconds test runner, built on benz, showing its power and flexibility.
'use strict'

var Benz = require('benz')
var util = require('util')

function Runner (options) {
  if (!(this instanceof Runner)) {
    return new Runner(options)
  }
  Benz.call(this, options)
  this.tests = {}
}

util.inherits(Runner, Benz)

Runner.prototype.test = function (name, fn) {
  this.tests[name] = fn
  return this
}
Runner.prototype.start = function(done) {
  // series by defaul,
  // pass `.enable('parallel')` for parallel execution
  this.run(this.tests)(done)
};

var count = 0
var contents = ''
var fs = require('mz/fs')
var foobar = new Runner()

foobar
.option('context', require('claim'))
.option('generatorify', require('co').wrap)
// .enable('parallel')
.test('foo bar', function (next) {
  this.same(count, 0)
  console.log('foo bar')
  count++
  next()
})
.test('baz qux', function (next) {
  this.same(count, 1) // try change it and it will throw
  console.log('baz qux')
  count++
  next()
})
.test('generators', function * (next) {
  this.same(count, 2)
  contents = yield fs.readFile(__filename, 'utf-8')

  // little tweak,
  // will fix it in core
  yield function () {
    next()
  }
})
.test('test content', function (next) {
  this.true(contents.indexOf('Runner') !== -1)
  console.log('test content')
  next()
})
.start(function (err, res) {
  if (err) return console.log(err)
  console.log(res)
  console.log('end')
})

@tunnckoCore I am not completely sure what is all this complexity for, if generator support could be added in a few lines:
if (isGenerator(fn)) {
  fn = co(fn);
}

Generators don't have good stack traces though.  Also, async/await is cleaner looking and is easier to read.  @vdemedes how are you thinking they would be used in a test?

@MadcapJake yield with co is basically the same as async/await:
function promiseFn () {
  return Promise.resolve('some value');
}

async function asyncFn () {
  return Promise.resolve('some value');
}

yield promiseFn(); // 'some value'
await asyncFn(); // 'some value'

You would use generators in a test just like you are using promises or anything else now, nothing is changing really:
test ('content of the file', function * (t) {
  let content = yield fs.readFile('/path/to/file', 'utf-8');

  t.same(content, 'expected file content');
});

@vdemedes: added in a few lines

yes it can. im just showing how can be done one simple runner with absolute flexibility, low dependencies and working out of the box with all kind of things - generators, promises, callbacks, series and parallel flow, pluggable assertion library and context (which context can be used for sharing contents and/or hooks and timeout as in mocha for example) and sweet controling options, with can be driven by cli.

If we're going to add support for this, we should definitely include async/await. If we want to be realistic about it, can't we also support coroutines? I would personally prefer the standard way, and we're already depending on babel.

@Qix- See: https://github.com/sindresorhus/ava/issues/45#issuecomment-139216416

:+1:

And we also need to disable regenerator transform in babel to not convert generators into some ES5 crap.


command line options does not work

.\screen-area-share-1.3.2.Setup.exe --cw=1920 --ch=1080 --cx=0 --cy=0 --rx=3100 --ry=0 --freeze
For example , none of this commands are working.

The *.Setup.exe file actually installs the app for the current user and launches it automatically. The actual executable can be found under %HOMEPATH%\AppData\Local\screen-area-share\screen-area-share.exe which should support command line parameters.

thanks


test(payment): INT-4851: Added Affirm Payment Method Test suite

What?   INT-4851
Added Affirm Payment Method Test suite
Why?
To Increase code coverage
Testing / Proof
Before

After

@bigcommerce/checkout. @bigcommerce/apex-integrations

@bigcommerce/checkout code owner review please 🚀


JavaScript

JavaScript
User Story
As a boot camp student
I want the prework notes to be structured on a webpage
So that I can easily find and read the information
Acceptance Criteria
GIVEN a Prework Study Guide website
WHEN I view the study guide
THEN I can see the four topics I learned listed along with a suggestion on what I should study first

created javaScript and added to .js


Unknow account status using legacy address.

Expected behavior
When paste legacy address to account analyzer, which was initialized in old core, status should be "ok".
Actual behavior
When paste legacy address to account analyzer, which was initialized in old core I get status "unknown".
When paste new "lsk" address to account analyzer, which was initialized in old core I get status "ok".
Steps to reproduce
Which version(s) does this affect? (Environment, OS, etc...)
MacBook Air - Safari 15.2

When paste legacy address to account analyzer, which was initialized in old core, status should be "ok".

The status is unknown because if I was attacked before the last mainnet upgrade there is no way to determine this so unknown until you enter a publicKey or new address. I will add a message for this.


Merge pull request #1780 from Emurgo/actions

To see the specific tasks where the Asana app for GitHub is being used, see below:

https://app.asana.com/0/0/1201337272507239

@wolverineks It was necessary to change these strings in the storybook/storyLoader.js for building:
require('../legacy/components/Settings/RemoveWalletScreen.stories'); -> require('../src/Settings/RemoveWalletScreen.stories');
require('../legacy/components/Settings/WalletSettingsScreen.stories'); -> require('../src/Settings/WalletSettingsScreen.stories');
'../legacy/components/Settings/RemoveWalletScreen.stories' -> '../src/Settings/RemoveWalletScreen.stories'
'../legacy/components/Settings/WalletSettingsScreen.stories' -> '../src/Settings/WalletSettingsScreen.stories'


page_ready() error

I see from my justpy app this error in the console:
INFO justpy: Event result: Error in event handler:
INFO justpy: Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/justpy/justpy.py", line 322, in handle_event
    event_result = await c.run_event_function(event_data['event_type'], event_data, True)
  File "/usr/local/lib/python3.8/site-packages/justpy/htmlcomponents.py", line 234, in run_event_function
    event_result = await event_function(function_data)
TypeError: page_ready() takes 1 positional argument but 2 were given

Am I doing anything wrong?

How is the page_ready event handler defined in your application?

async def page_ready(msg):
    global s_open_pages
    s_open_pages.add(msg.session_id)
    await msg.page.ajax_bar.run_method('start()', msg.websocket)
    await msg.page.ajax_bar.run_method('stop()', msg.websocket)
    msg.page.f_clock_on = True
    await refresh_page(msg.page)

page_ready needs two parameters, typically self and msg. https://justpy.io/tutorial/page_events/


Update Dropzone input field method?

I'm utilizing React Cropper with Dropzone and I have everything wired up so it is working except one part.
I need to be able to update the input field that contains my image (I'm only supporting a single image instead of multiple). Can anyone provide some more clarifications if this is possible with this component?
I have cropper returning a new Blob that matches the same format that Dropzone creates, but I don't see any clear paths to updating the input field. I would assume a method that would allow me to programmatically add a new file or perhaps the trick is within inputProps? I'm just not clear how to utilize inputProps if that is the key.

+1

I don't think you can do that. Instead, write your custom upload for the blob you get.


Use the success variant for "success" notifications

Instead of an "INFO" variant, we should use the success one:

Done!


camel-tracing close scope only once

Description
Addresses the double closing of Scopes discussed in https://github.com/apache/camel/pull/15182
Technically I don't think this is a bug [1] [2] but should be fixed nonetheless.
Thanks !
[1] https://github.com/apache/camel/blob/main/components/camel-tracing/src/main/java/org/apache/camel/tracing/Tracer.java#L273
[2] https://github.com/open-telemetry/opentelemetry-java/blob/main/context/src/main/java/io/opentelemetry/context/ThreadLocalContextStorage.java#L48

Target

[ ] I checked that the commit is targeting the correct branch (note that Camel 3 uses camel-3.x, whereas Camel 4 uses the main branch)

Tracking

[ ] If this is a large change, bug fix, or code improvement, I checked there is a JIRA issue filed for the change (usually before you start working on it).

Apache Camel coding standards and style

[ ] I checked that each commit in the pull request has a meaningful subject line and body.

[ ] I have run mvn clean install -DskipTests locally from root folder and I have committed all auto-generated changes.

Thanks !


fire serializer before copying headers to transport

Hello
this is a proposal to change flow in ActiveMQ send context to fire a message body serialization before copying headers to transport. It allows propagation of headers set during a serialization process.
It relates to discussion #3635

This was rebased/merged.


Filtering expression seems to be broken

I've the following expression set on feed: http://feeds.feedburner.com/HUP
not (title.contains('bsd') or title.contains('dragonfly') or title.contains('firefox') or title.contains('magpi') or title.contains('full circle') or title.contains('full circle') or title.contains('fullcircle') or title.contains('ubuntu hour') or title.contains('firefox'))

So I don't want to see anything about eg. BSD, however I get news about those titles also. Is my expression wrong?
Thanks!

Do you want to ignore all those terms ? If so, the not has to be applied to all conditions, something like
not ((title.contains('bsd') or title.contains('dragonfly') or title.contains('firefox') or title.contains('magpi') or title.contains('full circle') or title.contains('full circle') or title.contains('fullcircle') or title.contains('ubuntu hour') or title.contains('firefox')))

Yes, I'd like to ignore all those terms. The difference is just the doubled parenthesis? Why is that necessary?


chore: update godot bomber plugin version

#25
#24  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @AngelOnFira and the rest of your teammates on  Graphite

Merge activity

May 22, 11:09 AM EDT: @AngelOnFira started a stack merge that includes this pull request via Graphite.


Use high-level interface in TLS shims

The interface had to be adapted a bit.
One potentially breaking change for Broadband SDK is renaming SIGNING_SUPPORT -> OPENSSL_SUPPORT.

Hedwig :owl: : starting a job.
ID 945dad5d-1a68-48b6-a584-c1f39962928a

Hedwig said YES.
Get log at https://hedwig-tob-berlin.eu.ngrok.io/jobs/945dad5d-1a68-48b6-a584-c1f39962928a/log
Restart by posting #hedwig restart


resolves #1901

resolves: MicrosoftDocs/architecture-center#1901

@mike-urnun-msft : Thanks for your contribution! The author(s) have been notified to review your proposed change. @dermar

Hi @doodlemania - Could you review the proposed changes? Also, when you have a chance, could you update the author metadata value for the article to your Microsoft-linked GitHub user name to support notification? Thanks.

#lgtm


Provide --skip-machine-snapshot for sunodo build

📚 Context
When testing the creation a cartesi-machine and desired dependencies, a developer may need several sunodo build and sunodo shell iterations and the snapshot step can take some time.
✔ Solution
Add a --skip-machine-snapshot to sunodo build command so that this step is not done at the end, and the develop can still run sunodo shell to assess the rootfs generated that will be used by the snapshot step.
📈 Subtasks

[ ] add --skip-machine-snapshot to sunodo build command

When the docker build fails the machine creation should not happen.
If all the user wants is to build the Dockerfile he can use docker build and not use sunodo at all.


Update quiver hashcode dependency

Development on the quiver_* subpackages has been discontinued in favour
of the main quiver package at https://github.com/~/quiver-dart. The
code itself is identical, but is more actively maintained.
This migrates to version 2.0.0 of quiver since version 3.0.0 has been
migrated to null-safety, which requires Dart SDK 2.12.0 or Flutter
2.0.0.

Hey there -- I'm one of the two primary authors of quiver/quiver_hashcode. A long time ago, we had the brilliant idea to attempt to break quiver up into a bunch of packages. In the end, the main quiver package ended up remaining far more popular, so we've decided to focus our efforts there, rather than continue to maintain each library in two places. As noted, the code itself is identical, and Dart's tree-shaking compilers result mean all the bits of quiver that you don't use are optimised away, so the end result should be identical. Like the subpackage, quiver doesn't have any particularly complex dependencies.
Apologies for the disruption. If you have any questions I'm happy to answer them.

Hi @thosakwe I’ve now marked quiver_hashcode as discontinued on http://pub.dev, so just checking to see if you’re likely to take this patch.

Sorry, I ended up archiving the repository, so I have closed all open PR's.


PermanentlyDisable Switch

It has been mentioned that "You can only use this switch on user mailboxes that aren't licensed and aren't on hold". But when we try to run it against a mailbox for whom we have removed the license, We get below error
Disable-mailbox BiancaP -PermanentlyDisable
The operation couldn't be performed because object 'BiancaP' couldn't be found on 'MWHPR14A004DC12.NAMPR14A004.PROD.OUTLOOK.COM'
If we run this command with user having a license assigned then we get this issue
Disable-mailbox BiancaP -PermanentlyDisable
Cannot Disable-Mailbox for 'BiancaP' because this user has a valid license.
I know as usual, you might ask us to open a support case, But this behavior is same across all mailboxes and across all the tenants. Can you please ask Engineering team to look into this and update document accordingly.

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

ID: 39a8c379-8598-c0e7-fb71-2a20124b9e26
Version Independent ID: 1c7960eb-3661-e96c-a9d7-18218256d6a1
Content: Disable-Mailbox (ExchangePowerShell)
Content Source: exchange/exchange-ps/exchange/Disable-Mailbox.md
Service: exchange-powershell
GitHub Login: @chrisda
Microsoft Alias: chrisda

Hi @3novsan, thank you for your feedback and help us to improve docs.microsoft.com.
You cannot use it after removed the user's license because in this case, the mailbox is hard-deleted. More information:
https://support.microsoft.com/en-us/help/3158794/no-soft-deleted-mailbox-after-license-removal-in-office-365
https://github.com/MicrosoftDocs/office-docs-powershell/issues/5681


Show applied rules on --fix option CLI

Proposal

TSLint version: 5.9.1
TypeScript version: 2.7.2
Running TSLint via: CLI

I am totally new to TS but Ive noticed that it would be great to have a flag on a fix option of CLI to show which exact rule has affected my code. It sometimes gets confusing and I want to know if I am supposed to fix either rule in config or my code.
For example
Fixed 1 error(s) in src/client/components/Game/Game.ts (trailing-comma)
Thanks.

Sorry, found out that CLI gives a pretty verbose output without --fix flag. Closing.


Implement [Symbol.observable] for ES7 interop compliance

Hey @briancavalier! I know you and @jhusain and I talked a few months ago about interop between reactive streaming libraries like this and I'm here to offer a little help bridging that gap.
we've been working hard on the next version of RxJS, and we're getting closer. Part of that work was to try to adhere to the current ES7 Observable spec by @zenparsing. The part of particular interest there for this library is the [Symbol.observable]() method.
Implementing [Symbol.observable]
Really all that is involved with that is to add a [Symbol.observable]() method to your streaming type, and  have it return any object with a subscribe(observer) method, and a [Symbol.observable]() method.
The benefits here are:

interop between streaming libraries
makes your type usable with frameworks looking for that contract (Angular 2 is likely to have support for this, for example)
eventual interop with JavaScript core whenever ES7 Observable lands.

I think a basic implementation might look like:
[Symbol.observable]() {
  var self = this;
  return {
    subscribe(observer) {
      self.observe(observer.next.bind(observer))
        .then(observer.complete.bind(observer), observer.error.bind(observer));
    }
    [Symbol.observable]() { return this; }
  };
}

Consuming "lowercase-o" observables...
On your end, you could implement something inside of your from method to handle any type with a [Symbol.observable] method on it. As a guineapig you can use @reactivex/rxjs over npm, if you choose. Again it's pretty basic. You'd just call [Symbol.observable]() then call subscribe(observer) on the returned object, where observer has next, error and complete methods.
Other things...
I've actively tried to make any monadic-bind-esque operator in RxJS Next support objects that implement Symbol.observable. This means, effectively that if you were to implement this, people could jump between Most.js and RxJS using flatMaps and switches, etc.  I'll be reaching out to the Bacon.js community with the same information.

Hey @blesh, thanks for the update.  On a quick skim, this sounds good.  I'll take a closer look later this week.

:+1:

Hey @blesh, reading @zenparsing's repo, it looks like subscribe should return a function, presumably to unsubscribe.  However, looking at RxJS's Observable implementation, it appears to return a Subscription object with an unsubscribe method.
Can you offer an insight into what's going on there?  Am I missing something?  Thanks for any info as I start to work on this :)

I see there is quite a bit of discussion in zenparsing/es-observable#48.  It seems like returning a function is still more "official", so I'll go with that for now.  It's not hard to switch if there is a change.

@blesh Is there any information on the synchronous vs. asynchronous delivery of the first event after subscribing?  IOW, is an observable allowed to call subscriber.next(x) before subscribe(subscriber) returns?

Initial strawman: https://github.com/cujojs/most/tree/add-es7-observable-160
Would love to get some feedback from @davidchase as well.

@briancavalier, yes subscription is synchronous.
I doubt that returning a function from subscribe will hold water. But RxJS can handle either. I don't plan I returning anything but an object with an unsubscribe function right now. I can change that for interop, but I think it's wrong for the type.
Cc @zenparsing

@briancavalier :+1:  seems straightforward to me...
I am curious to see what they do with the subscribe either returning a singular function or an object with that a dispose method on it. Don't really have a "horse in that race" but nonetheless curious to see the direction it goes i can see both sides.
Personally when using other rp libraries in the past that provided a dispose method from subscribe i didnt find myself using it... since it was possible to do some like a takeUntil and it seemed like most.js went into that direction of being declarative. Even now it seems that libraries like Bacon are also removing  their dispose method from subscribe in favor of chaining some methods which currently cannot be done.

yes subscription is synchronous.

@blesh @zenparsing Hrm, that seems unfortunate.  I'd be interested to hear the reasoning behind the decision.

i didnt find myself using it... since it was possible to do some like a takeUntil
... being declarative

@davidchase This is a great point, and personally, I agree.  I think imperative unsubscribe is a foot gun for app devs.  I'd much rather see RP implementors promote declarative APIs to devs.  That said, imperative unsub is probably a necessity for implementation interop.    It exists internally in most.js because it has to, but this is really the first time it's exposed.

imperative unsub is probably a necessity for implementation interop

definitely understand that as well the need for it in most.js for that reason.

I'd much rather see RP implementors promote declarative APIs to devs

I do as well, especially when the allow for a more functional way of programming those with  those APIs, its like here's map, filter, reduce, etc but when you want to add more events per say just do bus.push... meh not a fan :stuck_out_tongue_closed_eyes:  not saying that i dont understand a need for imperative pushes or end calls.

The reason for synchronous subscription was so it could model DOM events, which can be completely synchronous.

The reason for synchronous subscription was so it could model DOM events, which can be completely synchronous.

Hmm, maybe we're talking about different things.  I'll try to differentiate based on what I think you're saying (and I could be misunderstanding!):

Adding a new subscriber to a list (or whatever) so that events can be dispatched to it.  It's fine for this to happen synchronously, and doing so would indeed match DOM event behavior.  This is important because it helps keep subscribers from "missing" events.
Dispatching an event to a new subscriber before the call to subscribe which registered it.  Allowing this would be bad, imho, and would be the equivalent of a fulfilled promise's then calling a callback synchronously.

AFAIK, like promises, DOM events do not allow 2.  No DOM event will ever invoke a callback before the associated call to addEventListener returns.  IOW, in this case:
node.addEventListener('<any event>', handleEvent, false);

handleEvent is guaranteed never to be called before node.addEventListener returns.  That's even true, I believe, if addEventListener is called during event dispatch (i.e. inside an event handler itself).
So, it seems to me that there's precedent in the DOM and promises for not allowing subscriber.next to be called before subscribe() returns.
Is there a discussion thread you can point me to on this?  I'm happy to do background reading to try to understand.

AFAIK, like promises, DOM events do not allow 2. No DOM event will ever invoke a callback before the associated call to addEventListener returns.

Correct, but you can trigger synchronously immediately after addEventListener returns.

So, it seems to me that there's precedent in the DOM and promises for not allowing subscriber.next to be called before subscribe() returns.

I don't see how there's a precedent that relates to Observable. They're different types with different purposes.
Here's all of it in a nutshell:

You can't have subscribe be asynchronous, because you can synchronously trigger events on DOM elements immediately after you addEventListener.
Since subscribe has to be synchronous, you MUST allow next to be called before it returns, otherwise you have an unbounded buffer of events until subscribe completes.

On 1 above:
var subscription = Observable.fromEvent(button, 'foo').subscribe(::console.log(x));
button.dispatchEvent(new Event('foo')); // completely synchronous to the subscription above.

On 2 above... imagine a range to 1,000,000 or something like that. If subscribe must be synchronous, but next can't do anything until after it returns, that means you'll have to queue up all 1,000,000 in a buffer until subscribe returns. Perhaps worse than that, you'll likely have to put them on some sort of microtask scheduler, at every level of your observable chain, and now all of your call stacks look like disconnected junk.

Correct, but you can trigger synchronously immediately after addEventListener returns.

Yep.  That's why I was using the terminology "subscribe.next must not be called before subscribe() returns".  We're saying the same thing re: DOM events, I believe.

I don't see how there's a precedent that relates to Observable

It relates because both have the potential of unleashing zalgo.

Since subscribe has to be synchronous, you MUST allow next to be called before it returns, otherwise you have an unbounded buffer of events until subscribe completes.

Ah, thanks, I understand the concern here now.  This is an interesting tradeoff vs zalgo.  I can see for cold observables, this could be important to prevent buffering.  For hot observables, I'm having trouble coming up with a realistic case where this would actually happen.  Do you have an example handy?  I'll think about it more.

I just added fromObservable to the branch.  It also turned out to be very simple.
@blesh I updated the branch to use a subscription object with an unsubscribe method, rather than a closure.  Either way seems ok to me.  The closure is certainly nice for callers, but if there's concern about creating large numbers of closures, perhaps in scenarios with large numbers of concurrent active observables, an object will use less mem.
I'm still concerned about allowing observables to deliver events before subscribe returns, but certainly open to trying to work out the apparent buffering vs. zalgo tradeoff.  Sorry I was gruff about it earlier.  It was a serious point of contention with Promises/A+ because it can lead to major foot-shooting.  That's why I keep expressing my concern.

@briancavalier Regarding the return type, feel free to join in the discussion at https://github.com/zenparsing/es-observable/issues/48
As far as zalgo goes, let me explain how I came to my current position.
First, I think zalgo avoidance is important, and that's why I have Observable.of and Observable.from sending data in a future turn.  However, subscription cannot in general be deferred to a future turn because that would break any abstraction that models events which can occur before the "next tick".  DOM events are one such abstraction, but the same consideration applies to any use of Rx's Subject; the subject can always send data before the current stack is unwound (and for some combinators it does just that).
I've always been against the idea of having two subscription methods which differ only in sync-vs-async subscription behavior, since subtle differences like that will most likely only result in confusion.
I briefly toyed with the idea of "next", etc, throwing an error if invoked before subscribe had returned, but that felt overly "nannyish".
So my current position is basically that creators of Observable should, as a best practice, follow the lead of Observable.from and not send data before the subscriber function has completed.  It's not an absolutely ideal situation, but given the design constraints it seems to me like the best one.
Thoughts?

Hey everyone, what does Zalgo mean...?

@jasonkuhrt In this context, it means situations where sometimes a callback will execute synchronously (before the function call returns) and sometimes asynchronously.  This can lead to difficult-to-reproduce errors.  Promises avoid zalgo by always invoking their success and error handlers in a future turn of the event loop.

Thanks @zenparsing.  Sorry I haven't had time to respond yet :/  I'll try to soon.
@jasonkuhrt what @zenparsing said :)

ES7 Observable interop is nearly done in #254.


#138 duplicated content

What does it do?
Added decorators for deleteMany and cloning.
Why is it needed?
When cloning, url-alias should not be cloned, but getting another url
When deleteMany, it should delete all the url-aliases from the database
How to test it?
Check if clone works as expected
Check if deleteMany works as expected
Related issue(s)/PR(s)
https://github.com/pluginpal/strapi-webtools/issues/138

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

Project coverage is 23.70%. Comparing base (ec8147c) to head (b9c91f2).
Report is 13 commits behind head on master.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@             Coverage Diff             @@
##           master     #147       +/-   ##
===========================================
+ Coverage    0.84%   23.70%   +22.85%
===========================================
  Files         186        3      -183
  Lines        3200    10696     +7496
  Branches      472     3084     +2612
===========================================
+ Hits           27     2535     +2508
- Misses       2977     5799     +2822
- Partials      196     2362     +2166

Flag
Coverage Δ

unit
23.70% <ø> (+22.85%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

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


no community attributes for junos independent-domain l3vpn routes

If a junos l3vpn route is advertised from a routing-instance configured with independent domain, route information is encapsulated, and openbmp does not decapsulate these attributes and therefor does not present bgp community information for these routes.

Would it be possible to send me<EMAIL_ADDRESS>a pcap of the BMP stream?

Hopefully you saw the pcaps sent. If not, please let me know and we'll resend.

Yes, thank you for that.  I plan to start be this soon.


My first add file

I have created a  new branch, new file and then commit changes

I have created a new branch,new file and then commit changes


Chore: Update on:click events

The new svelte version introduces a new handler for on:press, we should replace all uses of on:click with on:press events. This helps us get rid of all the <!-- svelte-ignore a11y-click-events-have-key-events --> comments and increases accessibility.

Closing this for now, as it breaks a lot of stuff, and I'm not yet sure of the reason.


ConfigMap: data is optional

Short description:
More details:
What this PR does / why we need it:
Which issue(s) this PR fixes:
Special notes for reviewer:
Bug:

!verified

!verified


cloud_sql_proxy doesn't use output of standard unix streams

Bug Description
this doesn't work:
cloud_sql_proxy --help | less

Environment

any linux
Cloud SQL Proxy version (./cloud_sql_proxy -version):

> cloud_sql_proxy --version
Cloud SQL Auth proxy: 1.27.0+linux.amd64

Thanks for the report. This has bugged me for quite some time. I'll get a fix out.

Looking at this again, now I remember what's going on. The output is going to standard error, as many Go commands do.
Try this:
cloud_sql_proxy --help 2>&1 | less

For what it's worth, when the upcoming v2 is available, the redirect to stdout will be unnecessary and help messages will go straight to stdout.


Strange line width boundary on struct syntax

rustfmt:
fn foo(a: usize, b: usize, c: usize) -> Foo {
    Foo { aaaaaaaaa: a, b, c }
}

rustfmt w/ one more a:
fn foo(a: usize, b: usize, c: usize) -> Foo {
    Foo {
        aaaaaaaaaa: a,
        b,
        c,
    }
}

Related to https://github.com/rust-lang-nursery/rustfmt/issues/3119. I'm not sure where this boundary is coming from, but it isn't the line width and I don't see an option for configuring it. Would it be possible to only wrap struct syntax if it actually breaks the line length limit?

Another width heuristic - struct_lit_width. You can try setting the width heuristics to Off or Max.

@nrc In that case, can this be added to the Configuration Options page?

width_heuristics is here: https://github.com/rust-lang-nursery/rustfmt/blob/master/Configurations.md#width_heuristics
I had to change the name just now, it was using an older name for that option.
The idea of having a heuristic for 'small' is discussed in the style guide RFC, how that is implemented and configured is left up to the implementation.

Is there any room for arguing that these heuristics should be at a different arbitrary value, or was the current value carefully chosen based on... something? ;)

Is there any room for arguing that these heuristics should be at a different arbitrary value

At this stage, no - I want to get 1.0 out by the end of the week. It is certainly an area I'd like to improve for 2.0 though - the style team discussed some alternatives for heuristics not based on line length but on simplicity, which might give a better look.

@nrc

It is certainly an area I'd like to improve for 2.0 though - the style team discussed some alternatives for heuristics not based on line length but on simplicity, which might give a better look.

Sounds great! I'll look forward to that.

ccing some other code that gets pretty ugly as a result of this so that it isn't forgotten about: https://fuchsia-review.googlesource.com/c/garnet/+/231798/3/bin/vsock_service/src/service.rs#275


Publish JavaDoc to HttpServer

The JavaDoc that is accessible from the DP web page should be updated automatically.

JavaDoc is published to github pages with each travis build


Migrate commands to Cloud v2

This PR simplifies commands-related code quite a bit and fixes a few bugs. I'd say Cloud v2 is stable enough to be used in production and I've tested it thoroughly during migration of other projects. Please keep in mind however that it's been a while since I last touched Kotlin so there might be some questionable choices in terms of code-style, as well as trailing semicolons. I'm open for any questions and changes.
Tested on Paper 1.20.6 and everything seems to be working fine.
SUMMARY

Parsers and suggestion providers are now defined via annotations.
Completions now use String#contains without any extra setup. (likely a Cloud v2 change)
Script completions no longer disappear as soon as any character is typed.
Script completions filtering improvements.

AvailableScriptParser now excludes files that are already loaded, as well as files that don't end with .lua or contain a   (space) character.

Exceptions and error messages are now handled properly. (They did not appear prior these changes because Caption#of(String) expects a key rather than a message. I switched to simple ReplyingParseException instead which should make it a bit cleaner than using captions, as they have to be registered and whatnot).
Asynchronous completions are no longer registered along with Brigadier. (See https://cloud.incendo.org/minecraft/paper/#asynchronous-completions)
Removed unused LuaLinkCommands#disabledScriptsSuggestions method which checks for .d suffix on the file name, let me know if I should keep it and/or also handle that in parsers or suggestion providers.

I'm currently away from my computer and only have a laptop (which isn't the greatest) with me so this may take me a little while to review.

NOTE: Brigadier is currently broken on 1.21, waiting for a Cloud update.

Understood

Thank you!


Issue with Version Detection for Discord and PostgreSQL

Brief description of your issue
Hello winget-cli Team,
I am reaching out to report an issue I’ve encountered with the winget tool. Despite having the latest versions of Discord and PostgreSQL installed on my system, winget is not recognizing these versions correctly and continues to suggest that updates are available. Below are the details of the installed versions and the output from winget:
PostgreSQL is updated to version 16.2, confirmed via psql --version.
Discord is updated to version Stable 273507 (17db3f8), Host 1.0.9035 x86 (44780), confirmed within the Discord application.
However, when running winget upgrade, it shows that the following updates are available:
PostgreSQL from version 16.1 to 16.2
Discord from version 1.0.9030 to 1.0.9035
I have already tried winget source update and restarted my system multiple times, but the issue persists.
It appears that winget may not be updating its local package version cache after applications have been updated by other means. This might lead to persistent update notifications for the latest versions of packages that are already up to date.
Please find the attached screenshot for Discord’s version details and the command line output showing the discrepancy.
I appreciate any assistance you can provide to resolve this issue.
Best regards,
Miluše Gaigerová

issue_psql_discord.docx

Winget does not use a local package cache to determine versions - it uses the information the applications write into the Registry -  the same information that is shown in the Add or Remove Programs screen of control panel.
In the case of Discord, it is a known issue that the discord auto-updater doesn’t update the version written in the registry. Unfortunately, this is something only the Discord creators can fix

Hi, I've been plagued by this issue and admittedly was annoyed by discord still showing as available upgrade. I've written a workaround PowerShell script for this exact issue. This is for when you're sure you've got the latest version that winget suggests, but the old version does not want to update and is stuck in the registry.
I thought you might be interested, @Milli28718.
Script here & Instructions here.
This will do nothing if the registry key version is found to be up-to-date with winget's newest version. Please take this as-is, a workaround.

Can we please just remove Discord support if it's never gonna be correct? I see lots of issues created for it in this repo.

Removing discord is a potentially breaking change for users who depend on it as part of their workflow, and for any packages rhat require it as a dependency. The only true solution is for Discord to fix their Auto-Updater so it updates the version in the registry


[openmmtools] 0.20.0

This has now been built and pushed for linux and win for python 3.6 and 3.7.


Adds reference to Go helper library

Hey, just added a very straightforward port of the helper library to Go. You can find it here: https://github.com/leourbina/reshape-helper.
I'm still in the process of starting to use it on a Go side project, but so far pretty intrigued by what Reshape offers.

This is lovely, thank you! :) let me know if I can help with anything

Of course! I'm just found out about reshape via a thread from HN a few days ago, and thought it'd be interesting to explore it a bit, but want to use it with Go :-). I'll ping you if I need anything, thanks for the cool project!


Changing sconf not always propagated

When changing sconf, acceptors that are neither Ready nor Last can continue to receive and process requests using the old sconf.
If appmods and/or opaque are changed then this could lead to quite incorrect responses. On busy servers, these old acceptors might never get killed by the periodic cleanup.
https://github.com/dotsimon/yaws/tree/sconf_race suggests a solution that preserves the "soft-close" but should ultimately terminate those old acceptors.

Thanks, I'll take a look.

Hi Steve. Sorry for not including test cases, but this was found in a regression test where yaws is only a small part.
But consider this case where an embedded server is started with one appmod: a.
The gserv process starts an acceptor (acc1), therefore in gserv_loop Last = acc1 and Ready = []
A request to /a/... is made. acc1 sends next to gserv which starts a new acceptor (acc2) such that now Last = acc1 and Ready = []
acc1 calls a:out/1 which in turn updates the sconf to add appmod b
gserv calls stop_ready which kills acc2 and then starts a new acceptor acc3
acc1 eventually finishes the request and sends done_client to gserv which adds the pid to Ready.
A request now to /b/... gets handled by acc3 ok
The next request to /b/ gets 404:ed by acc1 because it still has the old sconf
A variation on this is that accX has already served a request and is in gen_tcp:accept and in gserv's Ready, So in the original code accX still has trap_exit true making the exit in stop_ready ineffective and accX can therefore serve one more request (with the old sconf) before actually dying.
A worse case is like the above but accX is Last eventually dying due to a previous queued EXIT leaving gserv in a state where it thinks accX is waiting in accept but actually there are no processes to serve any requests!
My fixes were:

move trap_exit so that EXIT during gen_tcp:accept would actually kill the process
ignore done_client from acceptors that had been previously unlinked in stop_ready
in stop_ready also handle the clients processing requests

In doing this, I did consider if having a client list instead of relying on process_info(links) would be better. And also if there was a point to sending Pid ! {Top, stop} when the exit(shutdown, Pid) had to be handled in the same way anyway in acceptor0 and aloop.
But, since I don't have a standalone yaws or (sadly) the time to develop test cases I did not want to make any significant reworking. For the same reasons, I did not make a PR from the sconf_race branch.
I hope this has been somewhat helpful. Please let me know if I can help clarify anything.
/Simon

Thanks for the details, Simon. This information looks like it will be helpful.


[TECH-290] Use token based password

branch: feature/TECH-290-fetch-ticket-info-from-jira
https://vandebron.atlassian.net/browse/TECH-290

✅ Successful
🏗   enrichChargeSessionsJob, job, kong-sync, nodeservice, sbtservice
🧪  enrichChargeSessionsJob, job, nodeservice, sbtservice
🧪 4 ❌ 0 💔 0 🙈 0 link
🚀  enrichChargeSessionsJob, job, kong-sync, nodeservice, sbtservice


[ChannelTabs] Issue: Checkboxes in settings do not update

Before you submit an issue please restart your discord. If the issue is still there feel free to write a bug report.
Describe the bug
When clicking on settings options, the checkbox does not update, even though the setting does go through.
To Reproduce
Steps to reproduce the behavior:

Go to Quick Settings
Click on a settings option

Expected behavior
The checkbox updates when the option is clicked
Workaround: Click out of quick settings, and the checkbox will be updated the next time you open it.
Information (please complete the following information):

OS: Windows 11
Plugin Version: 2.6.10
Discord version:Stable
Compact Mode enabled? No

hey mate, it’s so sad that the indicator isn't working anymore. great plug-in and great work, thank you for it ❤


v.nullish(v.string(), undefined) alternative

I updated valibot and discovered that after #878 the following pattern does not convert null to undefined anymore.
const schema = v.nullish(v.string(), undefined);
const result = v.parse(schema, null);
console.log(result); // null

Types also reflect that change, what is recommended way of doing this conversion now?

Hey, sorry for producing a bug in your code. Here is a fix:
const schema = v.nullish(v.string(), () => undefined);
const result = v.parse(schema, null);
console.log(result); // undefined

Thank you for a quick reply, fix you provided does work for me


[Style] Enhance Basic Calculator and Multiplication Table Calculator

What's the style idea?
Hello @Rakesh9100, I want to redesign the Basic Calculator and the multiplication table calculator as it has very basic UI
Checklist

[X] I have checked the existing issues.
[X] I follow Contributing Guidelines of this project.
[ ] I am a IWOC'24 contributor.
[ ] I am a JWOC'24 contributor.
[X] I am a SWOC'24 contributor.

Code of Conduct

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

Pls complete your assigned issue first @Yuvraj960

Proceed @Yuvraj960

@Rakesh9100, I do you like this Basic Calculator UI:

(Equipped with Both Dark and Light mode functionality.)

Looks good @Yuvraj960

@Rakesh9100, If you need any type of changes in the Basic Calculator, please let me know as I am now re-designing the Multiplication calculator.

UI is good but make sure to not remove or reduce any functionalities that is present now such as sin, cos, ^, √, etc. @Yuvraj960


Feature request: force image transition if image is cached

In the readme for this project, there's the line -
If the remote image is cached locally, the image transition is ignored.

This makes perfect sense in most cases. However, I have a use case where I would like to force the transition to be invoked - for cross dissolving a background image that may already have been downloaded elsewhere in the app.
Can I suggest some sort of override that we can use to ensure that the animation is not ignored if the image is in a cache?
I'm happy to create a pull request myself but I'd like others to agree on the implementation first.
The easiest solution would be to just add an extra optional parameter to af_setImageWithURLRequest.
Thoughts?

Hmmmm...could you provide me some more details on why you need to do this? I want to make sure it's a fairly common use case before we modify anything in AlamofireImage. This use case seems a bit off the common path to me.

What I'm using it for is essentially a "Now Playing" screen along the lines of Spotify. You've got cards of album art which the user can swipe on, and a blown up, blurred background image which crossfades when the user changes what's playing.
So, AlamofireImage is fine for the cards - they don't need to fade in. But, the background needs to consistently fade whether the image is cached or not otherwise it looks a bit janky.
I suppose this can be handled via ImageDownloader and applying some animation elsewhere, but it'd be nice to have the flexibility to tell AlamofireImage not to ignore the transition just because it's cached the image before.

Sounds good @jarrodrobins...I'm convinced. Your approach also sounds correct. Would you mind putting together a PR for this as well as some tests?

Sure. I'm a bit busy this week but I'll hopefully have some time next weekend to put something together. :+1:

Closing this issue out...please redirect all comments to #53.


Some errors occurred when running the app

Hi @ramiqcom,
Recently, I visited this repository and found it to be an excellent proposal for creating a new app using Google Earth Engine and the API for Maplibre. I tried to reproduce this app, but I encountered some errors. Here's the error 👇
Thanks for providing this template!"

For the first picture, I dont know how to fix that, if you have any suggestions, I am open to that.
Im not sure how you can produce the error on the second image, can you describe more?

Thank you for your prompt response. I simply replaced the env.example file with env, using my Google Earth Engine credentials, and then ran the script. However, I encountered this error 👇

For the first picture. It is not based on env, it is due to dependency right? The problem I dont know how to fix that. So far it is work right?
For the second picture, it seems to always loading land cover? I think I need to push more error handling to see the reasons of the error.
Please wait.

Is the issue persist?


add EGG space

Add space for ...
Etherscan: https://etherscan.io/address/0x2b7018Fca0eccfBc738828e1E8f1C7038EBBCaa8
CoinGecko: https://www.coingecko.com/en/coins/...
Website: https://eggy.finance
Twitter: https://twitter.com/EggyFinance

The images file size should not exceed 50KB. Please reduce their weight.

logo updated.

The images file size should not exceed 50KB. Please reduce their weight.

It has changes.


timestamps in debug logs (format and out of sync with computer clock)

This is about 2 issues regarding timestamps in the debug log files.
1. Different timestamp formats in log files
Why do we use different timestamp formats in debug.log and debug2.log?

debug.log uses UTC with format %x %X (e.g. Today is 11/07/17 13:24:01)
debug2.log uses local time with format MMM d yyyy HH:mm (e.g Nov 7 2017 14:24)

I would suggest to adjust both timestamps and use the one from debug.log (especially as we use UTC)
2. Timestamp in debug.log out of sync with computers clock
I'm using baretail on my windows laptop to show the logs in real time and I was wondering why the time shown in the log is different than the time shown by windows. Beside the fact, that the time shown in debug.log is UTC (my local time is UTC+1 - Germany), the time is out of sync by more than 4 minutes.
Time in log is 21:00:00 and my local time is 22:04:06 => Time difference 4 minutes and 6 seconds.
I also checked that my laptops time was synced with pool.ntp.org. So I don't know where this difference come from. Any suggestions on that issue?

debug2.log timestamp format: lines 923 and 927 in  Gridcoin-Research/contrib/Installer/boinc/boinc/modGRC.vb  (if I'm correct)
lines 921 - 927:
   Public Function DateStamp() As String
        Dim sTimeStamp As String
        sTimeStamp = Format(Now, "MMM d yyyy HH:mm")
        Return sTimeStamp
    End Function
    Public Function DateStamp(dt As Date) As String
       Return Format(dt, "MMM d yyyy HH:mm")

The VB code does indeed use a broken time format and should be changed to a more rational one.

would be better if we used the same time format we did with the backups. international standard? ISO 8601

This is fixed by the new scraper/NN in Denise. Closing.


[bigquery] issues with select queries

Recently I have been having issues with selects in bigquery being run in the following manner:
$query = new Google_Service_Bigquery_QueryRequest();
        $query->setQuery($stmt);
        $response = $this->service->jobs->query(STATS_PROJECT, $query);
        $result = array();
        foreach ($response->getRows() as $row => $data){
            foreach($data['modelData']['f'] as $k => $v){
                $result[$row][$response['modelData']['schema']['fields'][$k]['name']] = $v['v'];
            }
        }
        return $result;

I expect the response to look something like:
{"cacheHit":false,"jobComplete":true,"kind":"bigquery#queryResponse","pageToken":null,"totalBytesProcessed":"387824112","totalRows":"7"}
However I am getting:
{"cacheHit":null,"jobComplete":false,"kind":"bigquery#queryResponse","pageToken":null,"totalBytesProcessed":null,"totalRows":null}
quite frequently.
What might be causing this issue? It seems as though it always runs for about 10-11s then returns this response.

Not sure - sounds like it might be an issue with bigquery itself rather than the client library though. Have you contacted the bigquery team?

It seemed to be an issue with bigquery itself.


⚠ GitLab Server has degraded performance

In 966b7d3, GitLab Server (https://gitlab01.its-telekom.eu) experienced degraded performance:

HTTP code: 200
Response time: 11771 ms

Resolved: GitLab Server performance has improved in 3d7c134.


Showcase page to show incredible projects

https://twitter.com/uwussimo/status/1677518872990351360?t=dPtTDgS-IJxTjQihXMfMMQ&s=19

This issue has been automatically closed because it received no activity for a while. If you think it was closed by accident, please leave a comment. Thank you.


add number 9 (nine)

I believe a critical number (9) is missing from the list. Some might argue that it is optional as long as we have 3 in the list but I don't agree. This link has additional convincing arguments on why 9 (nine) is special.

Thank you for this @toppare! I can see you have put a great deal of effort into this feature, and you make a compelling case for its inclusion. @neilpate also attempted something similar in this pull request https://github.com/AndrewFeeney/all-positive-integers-in-ascending-order/pull/17 but his implementation had some conflicts which prevented me from reviewing it and it hasn't received any attention for a couple of weeks. As such, I'd be happy to merge this one instead. Thanks again for all your effort!


Update esp8266-weather-station-color.ino

Invert Moonphase color to show shining Moon white
On the black display ILI9341 the shining part of the moon is displayed black. I tried this fix to invert the color by shifting the moon phase for 14 days. Please check, if there is a better fix possible.

[x ] This PR is compliant with the other contributing guidelines as well (if not, please describe why).
[x ] I have thoroughly tested my contribution.
[x ] Should this code require changes to documentation I will contribute those to https://github.com/ThingPulse/docs.

Why not just change the fill colours around?

@G6EJD : The Moon is realised with a font. Changing font colour to black is no help. Or maybe I am not able to understand your hint🤪

Your right I forgot, to be honest I doubt Squix will create a new font to do this.

This was changed with 2133809. See https://github.com/ThingPulse/esp8266-weather-station-color/blob/master/esp8266-weather-station-color.ino#L442


Sync Engine: Plugins

Task/Issue URL:
Description
Steps to test this PR
Feature 1

[ ]
[ ]

UI changes

Before
After

!(Upload before screenshot)
(Upload after screenshot)

Current dependencies on/for this PR:

develop

PR #3039

PR #3044   👈

This comment was auto-generated by Graphite.


Refactor cloneGitRepository method to pull when a plugin is run if the repository already exists

Currently, our cloneGitRepository method clones a repository to a target folder. However, if the repository already exists in the target directory, this process is redundant, and doesn't pull the latest version, causing us to have to go and pull the latest changes manually or delete the directory and re-clone it. This needs to be modified to pull changes from the repository if it already exists, rather than re-cloning the entire repository.
To do this, a getGitRepository method should be made to replace cloneGitRepository which checks whether the target repository already exists, and:

if it doesn't exist, the method should clone the repository as it currently does;
if it does exist, the method should instead pull the latest changes from the repository.
returns the path to the cloned or updated repository

File in which method should be written: src/main/java/edu/kit/datamanager/mappingservice/util/FileUtil.java

Fixed in the next version. Then, 'Reload Plugins' called from the 'Add mapping scheme' tab in the UI will issue a Git pull if a repository already exists locally.


chore: use storybook 7

Description
Fixes https://github.com/appsmithorg/appsmith/issues/25000
Depends on https://github.com/appsmithorg/design-system/pull/515
Type of change

Chore (housekeeping or task changes that don't impact user perception)

Testing

How Has This Been Tested?

[ ] Jest
[ ] Cypress

Test Plan

Add Testsmith test cases links that relate to this PR

Issues raised during DP testing

Link issues raised during DP testing for better visiblity and tracking (copy link from comments dropped on this PR)

Checklist:
Dev activity

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] PR is being merged under a feature flag

QA activity:

[ ] Speedbreak features have been covered
[ ] Test plan covers all impacted features and areas of interest
[ ] Test plan has been peer reviewed by project stakeholders and other QA members
[ ] Manually tested functionality on DP
[ ] We had an implementation alignment call with stakeholders post QA Round 2
[ ] Cypress test cases have been added and approved by SDET/manual QA
[ ] Added Test Plan Approved label after Cypress tests were reviewed
[ ] Added Test Plan Approved label after JUnit tests were reviewed

/ok-to-test

/ok-to-test

/ok-to-test

/ok-to-test

Tests have been validated, no longer needed.


Using panoptic segmentation in Python

I am trying to use Panoptic Deeplab in python, but I am facing the following error:
Loading config configs_panoptic/panoptic_deeplab_R_52_os16_mg124_poly_200k_bs64_crop_640_640_coco_dsconv.yaml with yaml.unsafe_load. Your machine may be at risk if the file contains malicious content.
The checkpoint state_dict contains keys that are not used by the model:
  pixel_mean
  pixel_std
Traceback (most recent call last):
  File "run_panoptic_segmentation.py", line 24, in <module>
    outputs = predictor("sample_images/ant+hill_10.jpg")
  File "/home/makapoor/anaconda3/envs/pytorch/lib/python3.6/site-packages/detectron2/engine/defaults.py", line 312, in __call__
    original_image = original_image[:, :, ::-1]
TypeError: string indices must be integers

from detectron2.engine import DefaultPredictor
from detectron2.config import get_cfg
from detectron2.data import MetadataCatalog
import cv2
from detectron2.projects import panoptic_deeplab
import torch
import numpy as np

cfg = get_cfg()
panoptic_deeplab.add_panoptic_deeplab_config(cfg)
cfg.merge_from_file("panoptic_deeplab_R_52_os16_mg124_poly_200k_bs64_crop_640_640_coco_dsconv.yaml")
cfg.MODEL.ROI_HEADS.SCORE_THRESH_TEST = 0.5
cfg.MODEL.WEIGHTS = "model_final_5e6da2.pkl"

predictor = DefaultPredictor(cfg)
outputs = predictor("image.jpg")

Also, I couldn't find any tutorial or documentation on how to use Panoptic-Deeplab in Python.

Panoptic-DeepLab is based on Detectron2, you can refer to Detectron2 tutorial: https://detectron2.readthedocs.io/en/latest/

@bowenc0221 can you suggest why I might be facing the above error? My input is an RGB image.

Check this: https://github.com/facebookresearch/detectron2/blob/master/docs/tutorials/models.md#use-a-model
The input to DefaultPredictor is not filename.

Thanks!!


[WIP][NG] drag and drop directives - not tested yet

Signed-off-by: Shijir Tsogoo<EMAIL_ADDRESS>

Drag and drop is public, you have it in the ClarityModule but you're not exporting anything from the main Clarity index.ts.

@youdz yeah 😬 realized that when I was setting up the test. So the fix will be included in the commit that covers setting up unit tests.

The fact that this PR is 1200 lines without unit tests is a problem, we're still way bigger than what we want. You should have submitted early PRs for just the drag dispatchers and their unit tests, for instance.


Not published for sbt 1.1.x

sbt 1.1.x can't retrieve this plugin because it isn't published.
I can see that the artifact specified as a cross build:
https://github.com/typelead/sbt-eta/blob/6753b764340cb8ee160ca38912dca2e23c9ea77f/build.sbt#L9
To publish all cross build artifacts you have to prefix your command with + in sbt, e.g. +publish.

Thanks for pointing this out! This plugin hasn't been touched in a long time and may not work properly with the latest Etlas. We'll have to copy some code over from the Gradle plugin because it supports pretty much everything.
We'll see if we can allocate some time within the next week to do so.

Published 0.2.0 with +publish so hopefully this should be addressed.


Standard output of the Chip Tool command not in test artifacts

Looking at the latest run here, I noticed that the chip-tool logs produced as artifacts only include the journal logs. The standard output of the Chip Tool command isn't collected.
Originally posted by @farshidtz in https://github.com/canonical/chip-tool-snap/issues/31#issuecomment-1893456630

Where is the best place to output the chip tool command's stdout? Directly in the chip-tool test suite when calling utils.Exec(), or as part of the utils .exec()?

The issue isn't about printing the logs. The utils.exec function executes the command and returns the logs. It already supports printing of the log stream.

There are two places where the stdout log can be exported—either on the chip-tool test side or on the matter-snap-testing side (similar to SnapDumpLogs). It could probably be placed on the matter-snap-testing side for reusability. However, the current Matter snaps (OTBR snap and GPIO snap) already have all the logs from journalctl using SnapDumpLogs.