Introduces manifest.yaml that is the "last working world state"

This introduces "the manifest" (manifest.yaml) that describes the complete state of the jax stack to allow for reproducible nightly builds and reproducible presubmit CI. The manifest (and patches) are staged in a "trial branch" each night, and if the build succeeds, we can merge the trial branch into main (TODO: GH Issue tracking automating merge). The presubmit CI runs on the PR's git-ref and so unless the author has committed a custom patch/manifest, they will always be running from the "last working state".
Description of manifest.yaml
The manifest allows specifying/pinning libraries that serve different purposes:

git repos: libraries that need their source checked out at a particular SHA
pip VCS constraints: VCS dependency specs that need to be pinned like fiddle @ git+https://github.com/google/fiddle
pip constraints: Python packages we need to constrain or pin to address one-off fixes, e.g., addressing a CVE

Here are example entries of each of these in the manifest.yaml
Git repos
jax:
  url: https://github.com/google/jax.git
  tracking_ref: main
  latest_verified_commit: b032a0271e3e2ea8d0df64d2f3f1a1e450a38dc9  # 2023-11-15
  mode: git-clone

url: This is the url to lookup the latest git ref
tracking_ref: This is the git-ref to lookup the latest commit SHA. Usually it’s main, but in some cases like lingvo, it’s master
latest_verified_commit: SHA
mode:

git-clone: Whether to clone the repo or not

Git repos with patches
flax:
  url: https://github.com/google/flax.git
  mirror_url: https://github.com/nvjax-svc-0/flax.git
  extra_dir: null
  tracking_ref: main
  latest_verified_commit: a572f6af2fef565c0f9ba2fc12b781e9e3385140
  mode: git-clone
  patches:
    pull/3340/head: file://patches/flax/PR-3340.patch # Add Sharding Annotations to Flax Modules

mirror_url: a git url where we can pull patches that start with ^mirror/
extra_dir: an optional local dir to pull patches not found in upstream or the mirror. Useful for private repos
patches: a dictionary where keys are git-refs and values are URIs for the local patch. The reason for the value is the git-ref can be rebased or be updated and the SHA will change; this makes patches a moving target when using git refs. So each file:// URI will be a patch committed into Jax-Toolbox's VC to ensure reproducibility

VCS Constraint
clu:
  url: https://github.com/google/CommonLoopUtils.git
  tracking_ref: main
  latest_verified_commit: 89c2face3474a7482358068d7a00d9bb6e4b31fe
  mode: pip-constraint

These aren't cloned (in fact get-source.sh will error if you try to clone). These are used in pip-finalize.sh to pin VCS dependencies like
clu @ git+https://github.com/google/CommonLoopUtils#egg=clu

# To

clu @ git+https://github.com/google/CommonLoopUtils@89c2face3474a7482358068d7a00d9bb6e4b31fe

Pip constraint
pydantic:
  mode: pip-constraint
  version: X.Y.Z

mode: pip-constraint

Adds a pip constraint during pip-compile

version: If ${package}.version is present, then we can treat this as a pip constraint. This allows us to hotfix any python package in case we discover a bug or CVE.

Changes to the CI

Nightly JAX Build bumps the manifest.yaml and patches and commits them to a trial branch. If the tests pass, this trial branch should be merged to main

introduces bump.sh that bumps the world state given the manifest

No more REPO_* and REF_* build args, since they are all specified in the manifest.yaml
get-source.sh and create-distribution.sh now take the manifest
Rename pip-tools "manifests" to "requirements-*.in` to avoid confusion and use the same terminology as pip-tools

Not addressed in this PR

[ ] Automating the merging of the trial branch at the end of a successful nightly run
[ ] Running presubmit on latest world state (currently only will run on last-known working state)
[ ] Move lingvo patches to the manifest (#409 )
[ ] Move xla arm neon patch to the manifest
[ ] Add a cleanup.sh script to remove things like ~/.gitconfig
[ ] Have not implemented mode: pip-constraint since there was no dep that needed a constraint

The history looks a bit weird. Maybe a rebase is needed? 😀

Some nitpicks mostly around naming:

Would ref be better named latest_verified_commit  or something along the line?
mirror_url -> mirrors: turn it into a list instead of a single string?
extra_dir -> patch_dir to be more explicit?

Try to rebase/merge to main again (or create another clean PR), because it is pretty difficult to get an idea what changes are yours vs what changes came from add-pip-compile PR

SG. I've rebased (preview: #406 ), but it was a pretty gnarly rebase. Without reparenting, just squashing had conflicts. I need to test that I haven't broken anything, but once I've tested, I'll force push here

Migrating comments from #406:
https://github.com/NVIDIA/JAX-Toolbox/pull/406#discussion_r1413408975

given that the baking (pip-compile + pip-sync) step will be independent between the upstream and rosetta containers, it is technically possible to let the upstream JAX/T5X/PAX/etc packages use free-floating VCS installs and rosetta containers use pinned VCS installs. Whether it will bring in any advantage is another question, though.

Both rosetta and upstream containers will use free-floating VCS installs in the nightlies since bump.sh will always be run. It's just that if you try to rebuild the nightly from an existing mealkit, you'll get pinned unless you call bump.sh, or edit the manifest, yourself.

Re:

extra_dir -> patch_dir to be more explicit?

@yhtang I've thought about this a little more and I don't like my suggestion of changing it to mirror_dir since currently I rely on mirror_url mapping to the mirror remote and extra_dir mapping to the extra remote, so if they both start with mirror_, it may be confusing. I documented the different sources of git-refs here: https://github.com/NVIDIA/JAX-Toolbox/pull/405/files#diff-bd111b2b880c006c97875516974cf4373b7fc486778ecb6f3b47e0b322911c53R52. Is this clear or if not, how would you suggest naming it?

Summarizing the topic/concerns @yhtang and I were discussing offline regarding the manifest file and --build-args
Current state
The current implementation has a --build-arg to accept the manifest in the first build (Dockerfile.jax), and takes away the other --build-args that added the (REPO_REF)_.* args.

Why: This was done b/c it was simpler and b/c there was no way to pass the trial branch between workflow_runs without adding logic to propagate parent artifacts, or adding logic to trace the root workflow that triggered this tree of workflows

Concern
The concern is that introducing the manifest makes it difficult to understand what's happening in each dockerfile, since the manifest is presumed to be there and its contents are not visible unless inspecting the base container (from Dockerfile.jax)
Proposals
(1) Keep --build-arg MANIFEST_FILE for this PR, but later re-introduce --build-arg (REPO|REF)_ once CI is consolidated (#416) to override the manifest
(2) Keep --build-arg MANIFEST_FILE for this PR, but later re-introduce --build-arg (REPO|REF)_ and derive them from the manifest once CI is consolidated (#416)
I am okay with either (1) or (2), but the point is I think it's best to keep --build-arg MANIFEST_FILE for now since the current state of the CI is not ready to handle REPO|REF --build-args. Anything I write here will be throw-away and undone with @DwarKapex tackles #416
@yhtang are you okay with keeping the PR as is, and @DwarKapex  tackling your --build-arg concern in the follow up PR? I presume what you had in mind was more like (2) than (1).

Weekly base build:  https://github.com/NVIDIA/JAX-Toolbox/actions/runs/7147399495
*
Nightly Jax Build:

Image:

Nightly JAX Unit Test:
Nightly Pax Build:

image:

Nightly Pax MGMN Test:
Nightly T5x Build:

image:

Nightly T5x MGMN Test:
Nightly Rosetta t5x build and test:
Nightly Rosetta pax build and test:

I feel that the way that we pass the version bump targets around could be better streamlined. The current trial branch approach seems a little risky. Admittedly, this could be done much more easily if the presubmits and the nightlies can be converged first.

I feel that the way that we pass the version bump targets around could be better streamlined. The current trial branch approach seems a little risky. Admittedly, this could be done much more easily if the presubmits and the nightlies can be converged first.

@yhtang I don't think there's any risk b/c the ability to merge the trial branch isn't included in this change-set. Nightlies will continue to be built via bump.sh. If nightlies and presubmits converged, I agree this would be more easily done, but I think we can address that after this is in. If we wait for the converge PR, that'll add +N weeks and then this change needs to be rebased after N weeks of changes and that seems like avoidable dev-work.
I am in favor of merging this in as it works and the converge PR can make use of the mechanism I am introducing here.

I'll move to merge this PR once the new tests are done after the rebasing. Follow-up work could include:

Converge the pre-submit and nightly workflows, which will automatically solve the following issues

Existing issue: the logic to decide whether to publish a nightly badge depends on upstream status (hidden dependency)
New issue: a workflow can use a manifest file from a branch other than the one that it is triggered on

Avoid creating trial branches for pre-submits. Currently, a trial branch seems necessary if we want to test the edge/latest versions. This will be problematic if we matricize the CI, considering the number of trial branches that will be created by each matrix.

Related issue: the name of a trial branch is passed between various nightly workflows. A better approach is to always use the manifest file from the same branch that triggers the workflow. This should be fixed automatically if we complete (1).

Merging as the remaining tests are all matrix MGMN tests (with partially confirmed success) and there are ~200 backlog jobs in the queue at this moment.


Follow the Bitcoin guidelines for transparency

Suggested by Calis Cihan
https://twitter.com/CalisCihan/status/1580519668439080961

I have added here: https://github.com/dogecoinfoundation/dogecoin.com/pull/239


Index.html re-factoring

Make "Show names" enabled by default.
Remove Live Editor feature.
Clean the code.

Done in 0.3.0


Error "This site cannot provide a secure connection" when logging in

The site is trying to run https on port 80 for some people and not for others. Screenshots are from both Firefox and Chrome:

It seems to be an intermittent issue, and I tried the workaround from the old site, but it didn't seem to work. Thanks!

Oh that's a weird one.
I just reproduced it.
It looks like CloudFlare is getting confused by https....:80.
As for what is incorrectly appending the :80, I'm investigating.

OK the new caching set-up doesn't seem to be forwarding the port number in the way that the login plug-in was expecting.
I've changed the code to address that.
Please try to log in now.

👍🏾 thank you much, Rob! Seems to be working now.

You're welcome. :-) That's good to hear.


Async example won't work at global level

About this example:
https://learn.microsoft.com/en-au/azure/ai-services/openai/how-to/migration?tabs=python-new%2Cdalle-fix#async
That shows using await outside of a function, but that won't work, since await must be called inside an async function. The usual approach is to use asyncio.run() to run an async def function.

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

ID: 7c35af32-f410-9214-4292-18397d232fd5
Version Independent ID: b238814c-5b36-19b1-d33b-5876b2b60ea5
Content: How to migrate to OpenAI Python v1.x - Azure OpenAI Service
Content Source: articles/ai-services/openai/how-to/migration.md
Service: azure-ai-openai
GitHub Login: @mrbullwinkle
Microsoft Alias: mbullwin

@pamelafox thanks for catching that. The example in the docs has been updated to:
import os
import asyncio
from openai import AsyncAzureOpenAI

async def main():
    client = AsyncAzureOpenAI(
      api_key = os.getenv("AZURE_OPENAI_KEY"),
      api_version = "2023-10-01-preview",
      azure_endpoint = os.getenv("AZURE_OPENAI_ENDPOINT")
    )
    response = await client.chat.completions.create(model="gpt-35-turbo", messages=[{"role": "user", "content": "Hello world"}])

    print(response.model_dump_json(indent=2))

asyncio.run(main())

The change is merged internally and will go-live in the next publish to live of the docs at 4 AM (UTC-8)

@pamelafox
Thanks for your feedback! We will investigate and update as appropriate.

This update is now live.

@pamelafox
We are going to close this thread. if there are any further questions regarding the documentation, please tag me in your reply and we will be happy to continue the conversation.


Duplicating Alert and Reports folder  with same knowledge objects

I don't know if this is intended or a bug.
When I save the knowledge objects, I see that alerts  and reports folders have exactly same KOs. I think its pulling both(alerts and reports) in two alerts folders and then again pulling both knowledge objects in reports folder.
I am using 2.7.0 of pickaxe

That sounds like a bug. Reports and Alerts are both just saved searches though the UI makes them look very distinct. We likely need to add some smarts when saving objects to filter out based on config if its an alert vs report


Nested SUBSTRING fails with INVALID_ARGUMENT error

This works, both with positive and negative indexes:
SELECT
    repository_id,
    remote_fetch_url,
    SUBSTRING(remote_fetch_url, 18)
FROM remotes;

SELECT
    repository_id,
    remote_fetch_url,
    SUBSTRING(SUBSTRING(remote_fetch_url, 18), -4)
FROM remotes;

But this fails from gitbase-web with error:
Query Failed - unknown error: Code: INVALID_ARGUMENT syntax error at position 69 near 'substring'

Running gitbase-0.20.0-rc1

First we need to merge the fix in vitess: https://github.com/vitessio/vitess/pull/4867

Just for reference, doing a second SUBSTRING in a subquery serves as a workaround. For example:
SELECT SUBSTRING(repository_id, 1, ARRAY_LENGTH(SPLIT(repository_id, ''))-4) AS b
FROM (
SELECT SUBSTRING(remote_fetch_url, 18) AS repository_id
FROM remotes
) AS q

Yep, this is clear. The problem is SQL grammar - SUBSTRING expects static string or column name, so SUBSTRING(REPLACE(...)...) should not also work.


feat: improve errors outputted to console

Summary
The error in #453 was caused by the @rspress/plugin-auto-nav-sidebar, which can't generate configs correctly if locales are not configured. Promise here is rejected because the value of the name field is undefined

Not sure if we should add this to the suitable part of the documentation and where the "suitable part" is
Related Issue
#453

Checklist

[x] I have added changeset via pnpm run change.
[ ] I have updated the documentation.
[ ] I have added tests to cover my changes.

Thank you.

👍👍


add ci process

Adding the github CI process, which:

make some linting check on yaml and csv file at each commit
generate the docker image and test it on push and merge request to the master
push the docker image to the eurobench  docker hub on release

This gihub process is common to all metric repo we are handling in Eurobench.
For the second point, a test_plan is defined in tests/test_plan.xml
As stated in https://github.com/eurobench/eb_hum_bench/blob/ci/.github/workflows/push.yml#L36, a python file is downloaded. It will launch the docker image according to the test plan file. And it verifies whether generated files correspond to the reference output file stored in the repo.
Regarding the last CI process, I still need to add some secrets to the repo, but I will do so once the code is fully eurobench compatible.
This is unclear how long the docker image generation will last for this repo. If it is too long, I will have to look for other strategies.

Well, the docker image generation only takes 15 minutes!
To get the integration test working, I had to adjust a digit in this reference file: https://github.com/eurobench/eb_hum_bench/pull/3/commits/68d4f0f232776aea3737bd8190c8aedbd26e2039
I assume this is ok.
The test plan may need to be adjusted when the other items are solved.


Remove Badd Boyz Hosts

Just wondering why?

Badd-Boyz is a good list with exceptional curation activity that comes only from dedicated, conscientious oversight that I wish all lists would possess.
So, no.
Closing.   😄

^ That makes no sense.

Sorry, @StevenBlack @rautamiekka @Jezza-x3  some guy really irking me on https://github.com/mitchellkrogza/Badd-Boyz-Hosts/issues about my list having a "whole bunch" of incorrectly blocked domains but cannot seem to provide any evidence or contribute anything valuable.
Probably just trying to wind me up and on a Saturday night when I'm relaxing I get easily wound up by guys trying to stir the pot. Thanks for trusting in me and my list, I work damn hard to make sure it's clean as can be.


Allow client resolvers

Description
I am expecting to have some time to work on the client project #444 again in the coming months and want to implement the changes in the core that will enable the work to progress.
In the end I decided that a client resolver collection would be the best way to deal with clients. This will permit clients to be registered with the actor system in the same way as remotes are registered.
Clients can be addressed with a scheme like:
{
address: "{clienthostaddress}",
Id: "$client/{guid}/$2"
}
The rest of the cluster does not need to know that it is communicating with a client.
Purpose
This pull request is a:

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

Checklist

[x] I have added tests that prove my fix is effective or that my feature works

Can you elaborate on this one?
When you say client, you mean another remote node?
For cluster we can spawn up nodes that can communicate with the cluster, while not joining themselves.
e.g.
Cluster.StartClientAsync() vs Cluster.SpawnMemberAsync()
Is this change part of making it possible to call back w/o opening a backwards connection to the calling client?

Yes It is part of making it possible to call back w/o opening a backwards connection to the calling client?
Perhaps we need different terminology here but for now I will use the following definitions.
ClientHost - an actor system that can accept client connections without a backwards connection to the calling client.
Client - a calling client that is connected to the ClientHost
The flow will go something like this:

ClientHost is started just like a normal remote but it has an additional grpc service for accepting Client connections that is started on a different port (ClientHostProxy Port)

Client connects to ClientHost Proxy Port, client is issued a guid and clientHost registers a clienthostresolver that will handle any messages addressed to:

{
address: "{clienthostaddress}",
Id: "$client/{guid}/*"
}
I have included * in the id above to indicate that it will handle anything that starts with $client/{guid}/

The root context on the client is given the Id

{
address: "{clienthostaddress}",
Id: "$client/{guid}/"
}
so that all actors on the client have an address of the form listed above

When a client communicates with any other node, it always does so through this client proxy connection, with the ClientHost forwarding the messages to the destination.

When other nodes send a message back to a client actor, they are unaware that they are sending to a client, the just send their messages to the clienthostaddress and the clienthostresolver collection takes care of mapping the ids to the correct client proxy connection.

Thanks for the explanation,
So:
address: "{clienthostaddress}",
Id: "$client/{guid}/"

the $client/guid part is used to match that this is should be looked up by the clienthost resolver, correct?
What if we remove that part, and instead have something in the address instead?
That way it should be possible to resolve this via the HostResolvers, just like the remoting layer does.
Address<EMAIL_ADDRESS>Id: "MyActor"
something like that.
Also, the guid, why is that needed if the client has an address?
is it to disambiguate a restarted client that happens to be on the same host+port as a previous client?

IMHO an addressing scheme like Address<EMAIL_ADDRESS>looks more logical but I have some concerns about it. All nodes participating in the cluster would need to be aware of the addressing scheme. So, would need to have a host resolver on every single node to handle the resolution of the client:// scheme or some hardcoded awareness of the client:// scheme that re-routes the request to the appropriate client host. Each of the other implementations of protoactor would also need to be aware of the scheme too.
If we were going to make a change in all implementations, I would be in favour of a scheme like:
Address: "client://{guid}"
Id: "MyActor"

With the lookup of the client location to be handled by a directory (or maybe piggyback on some of the cluster directory functionality). That way, we could handle clients being disconnected and reconnecting to a different clienthost without changing the identity of the actors on the client.
While I am in favour of an approach like this, it's a bigger project than I had in mind for the coming months but I would be happy to work with someone on it.
An implementation like
address: "{clienthostaddress}",
Id: "$client/{guid}/"

is just the lightest touch implementation that I could come up with. The strength of this approach being that it is a simple implementation, the weakness of this approach is handling client's reconnecting to different clienthosts. (It could still be done, but it is a bit messy)
The reason for using a guid instead of something like 352353532 is so that the client can create it's own guid for an identity without having to request it's identity from the clienthost. The guid saves some startup time for the client (not mutch) but makes for bigger pids with a long guid instead of an integer identifier. I would be happy with either approach really.

I'm following now. I'm just dense.
{
address: "{clienthostaddress}",
Id: "$client/{guid}/*"
}

In this case, the address is the address of the member node that received the client connection, correct?
So all other nodes only knows about this normal node, and any response to such pid would go to the the node that knows about the client, and this node would then send it back to the correct client.
This is actually brilliant!

I'm merging this in :-)

Yeah, that's correct.
Thanks for the merge, glad to hear you like the approach.


No source rpms in the repos

vscode makes rpm repos available at https://packages.microsoft.com/yumrepos/vscode. This repo does not have any of the source rpms. They should be there so that people can use the os provided way of downloading source code (dnf download --source code).

There is a difference between the OSS version of code that you can build yourself and the official VS Code package, see https://github.com/Microsoft/vscode/issues/60#issuecomment-161792005


RBL ends up displaying unnecessary messages when prompted to install/upgrade ipykernel

Ensure you have ipykernel 5 or you have a notebook with a selected kernel that doesnt' have ipykernel installed
Now try RBL
You'll end up with the message Install, Change Kernel, Cancel
When selecting Change Kernel/Cancel I still get the message ipykernel setup required for this feature (now I need to click cancel twice)
Also Clicking install and then cancelling the installationn will also throw the same message ipykernel setup required for this feature all over again.
Clicking cancel should not display any message, it should just exit from the entire workflow.

Change kernel and cancel are not working correctly.


storage: Fix chunkIndexToStartSeek calculation

With a high enough shrink ratio and enough chunks to persist, the
cutoff point could be outside of the file, which wreaks havoc in the
storage.
@mtanda

@beorn7
Sorry for lack understanding about the code...
Thanks for fixing it.


Move --keywords argument to the primary group

Hello.
I see that --keywords argument does not belong to any of nox argparse group that why argparse is placing it in optional arguments by default. As nox is using argparse groups for any other arguments, we should consider moving --keywords to primary group and force using group in Option class, ihmo.
Describe the bug
optional arguments:
  -k KEYWORDS, --keywords KEYWORDS
                        Only run sessions that match the given expression.

How to reproduce
$ nox -h :smiley:
Expected behavior
Primary arguments:
  These are the most common arguments used when invoking Nox.

  -h, --help            Show this help message and exit.
  --version             Show the Nox version and exit.
  -l, --list-sessions, --list
                        List all available sessions and exit.
  -s [SESSIONS [SESSIONS ...]], -e [SESSIONS [SESSIONS ...]], --sessions [SESSIONS [SESSIONS ...]], --session [SESSIONS [SESSIONS ...]]
                        Which sessions to run. By default, all sessions will run.
  -k KEYWORDS, --keywords KEYWORDS
                        Only run sessions that match the given expression.
  posargs               Arguments following ``--`` that are passed through to the session(s).

More improvements in help message
One more thing to consider that can improve the readability of the help message is to instead of having primary/additinal groups we could split the arguments into more functional-oriented groups e.g.:

general: --help, --version, --verbose, --noxfile, posargs
reporting: --nocolor, --forcecolor, --report
collection: --list, --session, --keywords
environment: --envdir, --reuse-existing-virtualenvs, etc.
execution: --stop-on-first-error, --install-only, --non-interactive, etc.

I based above on pytest --help
Best regards,
Maciej

I would be happy to see a PR moving things in to functional-oriented groups.

Great :) I'll create a separate ticket for having functional-oriented groups and in this one, we can simply prevent using group=None.

Here is a new ticket #305

This was done in https://github.com/theacodes/nox/pull/306


cursor.copy silent failure

When executing cursor.copy(copyStmt, input) with the malformed 'input' - e.g. containing extra comma-separated fields, the statement fails to write to the DB while not raising any error in Python. Suggest that this either changed to raising an error, or at least an option given to either ignore or raise.
Otherwise, there's no way to guarantee copy or see that it failed and why, short of writing additional code.

@eugene-rozman This is not controlled by python client. Can you try to add ABORT ON ERROR to the end of copyStmt sql? E.g. "COPY tbl (a, b) FROM STDIN DELIMITER ',' ENFORCELENGTH ABORT ON ERROR". Please see Vertica documentation for COPY syntax about error handling.

Closed. Reopen if you have further questions.


After the update, there's something on top blocking me.

I'm sure it's the problem of rgthree, because it's okay after I delete it.

I tried to adjust it in the settings but to no avail, for example, I canceled the progress bar, but this thing is still here.

Try disabling the ComfyUI-N-Sidebar
The new Comfy UI menu is interfering with ComfyUI-N-Sidebar
https://github.com/Nuked88/ComfyUI-N-Sidebar/issues/79
Now that rgthree progress bar was updated to be compatible with the new Comfy UI menu, it's probably also interfering with the ComfyUI-N-Sidebar too.
https://github.com/rgthree/rgthree-comfy/issues/275

I can't seem to reproduce this exactly even with workspace manager, but I just made a change to be more backwards compatible with the old, non-beta, layout. Can someone who is experiencing this pull the latest and try?

Try disabling the ComfyUI-N-Sidebar, or enabling the new [ Beta ] Comfy UI menu in the settings.
The new Comfy UI menu is interfering with ComfyUI-N-Sidebar, but it may also be due to some interactions with other extensions ( e.g. 3D-Pack ) Nuked88/ComfyUI-N-Sidebar#79
Now that rgthree progress bar was updated to be compatible with the new Comfy UI menu, it's probably also interfering with the ComfyUI-N-Sidebar too. #275

Currently I haven't encountered any conflict situations between N-Sidebar or 3dpack and the new menu of ComfyUI. What I have a conflict with is Crystools and rgthree-comfy. To be exact, there is no conflict with Crystools, but its stacked UI makes the new menu very high.

I can't seem to reproduce this exactly even with workspace manager, but I just made a change to be more backwards compatible with the old, non-beta, layout. Can someone who is experiencing this pull the latest and try?

Thank you very much. I just updated and the issue has been fixed : )


Fail to compile webrtc demo code on Ubuntu

Hi,
I'm new to gstreamer and looking for help on the following issue.  I have installed gstreamer 1.16.2 on Ubuntu 20.04. I got the following error when try to compile the webrtc-sendrecv demo code. Can anyone tell me how to solve this issue?
Thanks,
yx
gst-inspect-1.0 --version
gst-inspect-1.0 version 1.16.2
GStreamer 1.16.2
https://launchpad.net/distros/ubuntu/+source/gstreamer1.0
gcc webrtc-sendrecv.c $(pkg-config --cflags --libs gstreamer-webrtc-1.0 gstreamer-sdp-1.0 libsoup-2.4 json-glib-1.0) -o webrtc-sendrecv
Package gstreamer-webrtc-1.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing gstreamer-webrtc-1.0.pc' to the PKG_CONFIG_PATH environment variable No package 'gstreamer-webrtc-1.0' found Package gstreamer-sdp-1.0 was not found in the pkg-config search path. Perhaps you should add the directory containing gstreamer-sdp-1.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'gstreamer-sdp-1.0' found
Package libsoup-2.4 was not found in the pkg-config search path.
Perhaps you should add the directory containing libsoup-2.4.pc' to the PKG_CONFIG_PATH environment variable No package 'libsoup-2.4' found Package json-glib-1.0 was not found in the pkg-config search path. Perhaps you should add the directory containing json-glib-1.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'json-glib-1.0' found
webrtc-sendrecv.c:9:10: fatal error: gst/gst.h: No such file or directory
9 | #include <gst/gst.h>
|          ^~~~~~~~~~~
compilation terminated.

You are missing more devel packages - libgstreamer-plugins-bad1.0-dev and libsoup2.4-dev and libjson-glib-dev

Thanks Jan for the quick response. It works :-)


Add support for CSS custom properties (variables)

Hello, first of all thanks for the great library!
My project required the color picker to support binding swatches to CSS custom properties.
Loading custom properties into swatches was already functional, but the color value behind the property was not being parsed correctly when clicking on the swatch.
I have implemented support for custom properties in this fork https://github.com/kj-ivy/Coloris  (See CSS Variable swatches in examples.html)
If you would be interested in supporting this feature officially I could open a pull request.

Hello, thank you for your kind words, and sorry for the late reply, it's been a busy couple of months.
Unfortunately I have no plans to support non CSS color values in the color picker, but feel free to modify your own version or even release it publicly if you so wish.


Rename inconsistent policy files

Overview/Summary
Fixed issue with couple of Policy Definitions file names to align with the actual name of the policies
This PR fixes/adds/changes/removes

Renamed following files:
Audit-PrivateLinkPrivateDnsZones.json  --> Audit-PrivateLinkDnsZones.json
DenyAction-ActivityLogSettings.json --> DenyAction-ActivityLogs.json
DenyAction-DiagnosticSettings.json --> DenyAction-DiagnosticLogs.json

Breaking Changes

N/A

Testing Evidence

Testing URLs
Azure Public

As part of this Pull Request I have

[x] Checked for duplicate Pull Requests
[x] Associated it with relevant issues, for tracking and closure.
[x] Ensured my code/branch is up-to-date with the latest changes in the main branch
[x] Performed testing and provided evidence.
[x] Ensured contribution guidance is followed.
[x] Updated relevant and associated documentation.
[x] Updated the "What's New?" wiki page (located: /docs/wiki/whats-new.md)

Nice work @rozkurt
I checked all files and policies with the below script and you've got them all covered 👍

# get all of the policies in src/resources/microsoft.authorization/policyDefinitions and check the file name, wihtout the extension, matches the policy name in the propoerty of the json file

$policyDefinitions = Get-ChildItem -Path .\src\resources\microsoft.authorization\policyDefinitions -Filter *.json -Recurse -Exclude *.AzureChinaCloud.json, *.AzureUSGovernment.json

$policyDefinitions | ForEach-Object {
  $policyDefinition = Get-Content $_.FullName | ConvertFrom-Json
  $policyName = $policyDefinition.name
  $fileName = $_.Name.Replace(".json", "")
  if ($policyName -ne $fileName) {
    Write-Host "Policy name '$policyName' does not match file name '$fileName' in file '$($_.FullName)'" -ForegroundColor Red
  }
  else {
    Write-Host "Policy name '$policyName' does match file name '$fileName' in file '$($_.FullName)'" -ForegroundColor Green
  }
}

# get all of the policies in src/resources/microsoft.authorization/policySetDefinitions and check the file name, wihtout the extension, matches the policy name in the propoerty of the json file

$policySetDefinitions = Get-ChildItem -Path .\src\resources\microsoft.authorization\policySetDefinitions -Filter *.json -Recurse -Exclude *.AzureChinaCloud.json, *.AzureUSGovernment.json

$policySetDefinitions | ForEach-Object {
  $policyDefinition = Get-Content $_.FullName | ConvertFrom-Json
  $policyName = $policyDefinition.name
  $fileName = $_.Name.Replace(".json", "")
  if ($policyName -ne $fileName) {
    Write-Host "Policy name '$policyName' does not match file name '$fileName' in file '$($_.FullName)'" -ForegroundColor Red
  }
  else {
    Write-Host "Policy name '$policyName' does match file name '$fileName' in file '$($_.FullName)'" -ForegroundColor Green
  }
}


fix Issue 14760 - Clear content-length for libcurl

content-length must be set to allow follow-up
post/put/trace requests with empty body

reset content-length to 0 after _basicHTTP

LGTM

@MartinNowak looks better :)

Auto-merge toggled on


Add type-erased AnyError for generic contexts

In Swift 3, Error should be widely used instead of NSError. So the type should be useful to wrap arbitrary Error instances for uses in generic contexts.
This is an additive, non-breaking change.

See also https://github.com/apple/swift-package-manager/blob/swift-DEVELOPMENT-SNAPSHOT-2016-11-12-a/Sources/Basic/Result.swift#L62-L74.

Any other thoughts? @antitypical/result

Thanks for the review comments! I'll merge this once CI passes, then cut a new release.

@davidgreens


METRON-231: Snort parser should throw exception

Snort parser returns null when we should be throwing an exception in the event of an improperly formatted message.  An exception will result in the message being sent to the error queue.

+1 - ran on quick-dev-vagrant, worked like a champ.

+1 Looks good


object detection and image orientation

Hi,
I am training the yolo net with image data, where I use portrait training images for some classes and landscape images for other classes. When I test the model against landscape images I get significantly better results for classes that were trained with landscape images.
Is that reasonable, is that how it works or do I miss something?
kind regards
Roman

It seems theoretically possible for the aspect ratio to matter somewhat, but in practice our data augmentation pipeline randomly samples cropped versions of the raw images, and aspect ratio of the cropped version is mostly independent of the original aspect ratio (subject just to some constraints on fit).
Is it possible this has more to do with the classes that happen to have landscape training examples versus the ones that happen to have portrait training examples?
Are you measuring accuracy using a test/validation set, or is this anecdotal based on what is deployed to Core ML?

Thx for the reply!

Is it possible this has more to do with the classes that happen to have landscape training examples >versus the ones that happen to have portrait training examples?
 Measured against the trained model inside turicreate.

Let me do some more tests.

Hmm, ideally there isn't a systematic difference between the training and test images. What happens if you combine them and then randomly split them? Or do you have just one (close-up) training image per class?

I think I have an idea what's happening.
The breakfast sample uses a 640x480 detection view and stretches it to the device bounds.
I think when one feeds an image to the coreml model this image is distorted when using the camera in landscape mode or distorted and rotated if you use the camera in portrait mode. Therefore one gets better results while using the app in landscape mode (the difference is big)(maybe the banana class doesn't show this, because of the symmetries of the sample class). The solution of #1016 helps but is not optimal.
If I am right, you should do a little rework on the sample app.
Hmm?

Ah, that makes sense. Just to follow up here, I'm not sure about the confidence values you're seeing, but ultimately we're tracking that problem with #2093


MetaMask throws error when used via SDK via ESM (JsDelivr)

Current Behavior
Our issue in a nutshell: When relying just on the injected wallets like this:
const wallets = [injectedModule()]
we can easily connect via chrome browser on desktop, but on smartphone, no MM is shown.
When importing the web3-onboard MM module and extending the wallets by
const wallets = [metamask, injectedModule()]
We get this Error: Uncaught (in promise) SyntaxError: The requested module<EMAIL_ADDRESS>does not provide an export named 'EventEmitter2' (at jsdelivr-header.js:7:1)
Beside of that, my code is like the Get Started ()
Important note: I import all these libraries via ESM (jsdelivr.com, the latest versions)
Due to the fact i can connect with MM, even with smartphone, when using this Example: , is assume the reason is a misconfigured/mis-bundled ESM
Expected Behavior
It works like in the example of Blocknative
Steps To Reproduce
No response
What package is effected by this issue?
@web3-onboard/injected-wallets
Is this a build or a runtime issue?
Runtime
Package Version
the latest (2.23.0)
Node Version
No response
What browsers are you seeing the problem on?
Chrome
Relevant log output
Uncaught (in promise) SyntaxError: The requested module<EMAIL_ADDRESS>does not provide an export named 'EventEmitter2' (at jsdelivr-header.js:7:1)

Anything else?
No response
Sanity Check

[ ] If this is a build issue, I have included my build config. If this is a runtime issue, I have included reproduction steps and/or a Minimal, Reproducible Example.

To make it better understandable - you can find our "prod" code below:
✅ Works with Chrome (MetaMask extension installed)
❌ Doesn't work with Chrome on Smartphone although MetaMask App is installed
❌ Doesn't work with Chrome Ikognito Mode
When clicking "Connect" on this example here: https://onboard.blocknative.com/examples/connect-wallet :
✅ Works with Chrome (MetaMask extension installed)
✅ Works with Chrome on Smartphone -> MetaMask App is being recognized and triggered as expected
✅ Works with Chrome Ikognito Mode somehow, at least the typical MetaMask SDK window is being shown
(Maybe interesting) side info: When the page itself is populated (using the code below), i instantly get this errors logged:
Uncaught (in promise) TypeError: Cannot read properties of null (reading 'type')
at Ln. (inpage.js:247:166515)
at Generator.next ()
at ae (inpage.js:247:165403)
**-> The line at inpage.js:247:166515 is: this.hardware = N.type === hu.HARDWARE**

Uncaught (in promise) TypeError: Cannot read properties of undefined (reading '$$')
at vn (index-94d40e1f.js:1840:50)
at new Ae (Index-d8463bd4.js:1440:3)
at bt (index-94d40e1f.js:1002:12)
at index-94d40e1f.js:10218:21
at zi (index-94d40e1f.js:10169:39)
at o (index-94d40e1f.js:1602:47)
at index-94d40e1f.js:1637:13
**-> The line at index-94d40e1f.js:1840:50 is: root: options.target || parent_component.$$.root**

import Onboard from 'https://cdn.jsdelivr.net/npm/<EMAIL_ADDRESS>import injectedModule from 'https://cdn.jsdelivr.net/npm/<EMAIL_ADDRESS>import { ethers } from<EMAIL_ADDRESS>
const wallets = [
		injectedModule()
	]

	const chains = [
	  {
		id: '0x1',
		token: 'ETH',
		label: 'Ethereum Mainnet',
		rpcUrl: 'https://ethereum-rpc.publicnode.com'
	  },
	  {
		id: '0xaa36a7',
		token: 'ETH',
		label: 'Sepolia',
		rpcUrl: 'https://rpc.sepolia.org/'
	  }
	]

	const appMetadata = {
	  name: 'PayLink Protocol',
	  icon: '<svg></svg>',
	  description: 'Connect your wallet to make purchases over PayLink.'
	}

	const onboard = Onboard({
		wallets,
		chains,
		appMetadata
	})

	const wallet = await onboard.connectWallet();

	let ethersProvider
	try {
		ethersProvider = new ethers.BrowserProvider(wallet[0].provider, 'any')
	} catch (exception) {
		console.log(exception)
		resetButton(button, originalText)
		return;
	}

    const signer = await ethersProvider.getSigner()


viceroy: 0.4.0 -> 0.4.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/fastly/viceroy/releases.
meta.description for viceroy is: Viceroy provides local testing for developers working with Compute@Edge
meta.homepage for viceroy is: https://github.com/fastly/Viceroy
Updates performed

Rust version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.4.1 with grep in /nix/store/mq2gq8hkbr8m2rx8vv4axqazzcjnyd1w-viceroy-0.4.1
found 0.4.1 in filename of file in /nix/store/mq2gq8hkbr8m2rx8vv4axqazzcjnyd1w-viceroy-0.4.1

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

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath
fastly
viceroy

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/mq2gq8hkbr8m2rx8vv4axqazzcjnyd1w-viceroy-0.4.1 \
  --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 viceroy https://github.com/r-ryantm/nixpkgs/archive/07b7e7950206791b4fc5c74a804fccbb07b5e959.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/mq2gq8hkbr8m2rx8vv4axqazzcjnyd1w-viceroy-0.4.1
ls -la /nix/store/mq2gq8hkbr8m2rx8vv4axqazzcjnyd1w-viceroy-0.4.1/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:

fastly
viceroy

Maintainer pings
cc @ereslibre @shyim for testing.

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

2 packages built:

fastly
viceroy


Do I need an extra database for my Identity server 4 project?(persistent storage implementation)

Sorry if this questions has been raised..
So I have three projects in my solution;
1: My Web API (authority is Identity Server4)
2: Identity Server 4
3:API consumer client
I have a database associated with my Web API already. And now with Identity Server I am going to replace the in-memory storage with persistent storage (https://docs.identityserver.io/en/latest/quickstarts/7_entity_framework.html?highlight=storage)
Seems like I need an extra database.
The question is, what is considered a good practice, create a brand new database only for Identity server 4? Or I can consider just adding some tables for the existing database used by the Web API?

http://docs.identityserver.io/en/latest/topics/deployment.html


Allow overriding of path for editorconfig

@malandrew
opts.cwd is defaulted to process.cwd() if omitted. I'd like to be able to change the directory for use in an atom linter plugin.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Willyham seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Where is path() ?

The documentation refers to the path() grouping function but I seem to not find it available neither in IDE nor in github master branch. Who is wrong ?

@rjpereira path is not a member of Javalin, but lives in ApiBuilder (for the syntax to work in Java a temporary static instance has to be created). If you add import static io.javalin.ApiBuilder.*; to your imports everything should work.


Update minimum dependency version for DevHome

Related to https://github.com/microsoft/winget-cli/issues/3668

Microsoft Reviewers: Open in CodeFlow

cc @denelon Is MinimumVersion validation not enabled in the pipelines? 👀 It passes validation locally -

@wingetbot run

Not sure if this is the expected result but putting this here just in case 🤔 Maybe I'm incorrectly using the field

@mdanish-kh that's correct. Until more than half the clients on devices in the wild have the latest client, we don't update the validation pipelines.


Vim9: body of broken function not cleared when using ":silent!"

Describe the bug
In Vim9 script, :silent! might prevent Vim from clearing the body of a broken function.
To Reproduce
Run this shell command:
vim -Nu NONE -S <(cat <<'EOF'
    vim9script
    def Func()
        var x = 0 + {}
    enddef
    sil! Func()
    def Func
EOF
)

E1051 is raised:
E1051: Wrong argument type for +

This is expected.
The body of the function – as given by :def Func – remains the same:
   def <SNR>1_Func()
1          var x = 0 + {}
   enddef

This is not expected.
Expected behavior
The body of Func() is empty.
Environment

Vim version: 8.2 Included patches: 1-2741
OS: Ubuntu 16.04.7 LTS
Terminal: xterm(367)

Additional context
silent! doesn't prevent Vim from clearing the body of a broken function for other errors.
For example, if we try to re-declare a variable:
vim9script
def Func()
    var x = 0
    var x = 0
enddef
sil! Func()
def Func

function <SNR>1_Func()
endfunction

Or if we try to execute an invalid command:
vim9script
def Func()
    invalid
enddef
sil! Func()
def Func

function <SNR>1_Func()
endfunction

Or if we try to change the type of a variable:
vim9script
def Func()
    var x: number = 0
    x = ''
enddef
sil! Func()
def Func

function <SNR>1_Func()
endfunction

Notice that in all these snippets, Func() was invoked with silent! which correctly suppressed the error raised during the compilation.  And notice that afterward, in all of them, the body of the function was empty.
If silent! does not prevent Vim from clearing the body of a broken function for these 3 errors, I would expect it does not prevent Vim from doing the same for the first one (E1051).

The fact that Vim clears the body of a function for which an error has been raised at compile time is neat.  It's especially useful when the latter is invoked frequently; e.g. in an autocmd:
vim9script
def Func()
    invalid
enddef
Func()
au TextChangedI * Func()

This snippet raises E476 because of the initial Func() invocation on line 5:
E476: Invalid command: invalid

This is expected.  But afterward, whenever a character is inserted, no error is raised.  That's because Vim has cleared the body of the function after an error was raised during its compilation; which makes sense, if it can't be compiled, it will never work, and there's no reason to run anything; that would only bother the user whenever they try to insert a character.
This definition clearing should be done consistently and whenever possible.  That's not the case when the error is E728:
vim9script
def Func()
    var x = 0 + {}
enddef
sil! Func()
au TextChangedI * Func()
feedkeys('ii')

E728: Using a Dictionary as a Number

Notice that this error is raised by the TextChangedI autocmd.  And it will be repeated on every single keypress.  This is useless.  The function will never work; its definition should have been cleared during the compilation on its first invocation, regardless of whether silent! was used then.

E1051 is raised:
E1051: Wrong argument type for +

This is expected.

Sorry, the error is not raised; it's suppressed by silent!.  That doesn't change the rest of the report.

Something else looks a bit weird.
When we ask for the definition of a broken :def function, Vim uses the keyword :function, not :def.
And when we invoke a broken function (because of E1051),  which has not been cleared (because of :silent!), E728 is raised.  Notice that E1051 is a new Vim9 error, while E728 is a "legacy" one (I mean it already existed before Vim9).
All of this suggests that a broken function is redefined as a legacy one.  But that's not the case:
vim9script
def Func()
    echo (() => 123)()
    var x = 0 + {}
enddef
sil! Func()
au TextChangedI * Func()
feedkeys('ii')

This snippet correctly prints 123, which means that the new lambda syntax was correctly parsed, which would not be possible in a legacy function

I actually think we should not delete the function body.  This can be useful when the error message isn't clear and perhaps the script where it was defined is not easy to find.  We then use a separate flag to specify that the function has an error and can't be executed.
This does mean that for an autocommand you get an error every time.  That's not different from using a not compiled function though.

The error message is different depending on whether the first invocation (when the function was compiled) was prefixed with silent! or not:
vim9script
def Func()
    var x = 0 + {}
enddef
Func()
au TextChangedI * Func()
feedkeys('ii')

Error detected while processing TextChangedI Autocommands for "*":
E1091: Function is not compiled: <SNR>1_Func

vim9script
def Func()
    var x = 0 + {}
enddef
sil! Func()
au TextChangedI * Func()
feedkeys('ii')

Error detected while processing TextChangedI Autocommands for "*"..function <SNR>1_Func:
line    1:
E728: Using a Dictionary as a Number

This seems inconsistent.  I think the second message should tell us that Func() was not compiled, just like the first one.

That was fixed with patch 8.2.2743


AnimeGO

Source name
AnimeGO
Source link
https://animego.org/
Source language
Russian
Other details
No response
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a title with source name.
[X] I have checked that the extension does not already exist on the website extensions list or the app.
[X] I have checked that the extension does not already exist by searching the GitHub repository and verified it does not appear in the code base.
[X] I will fill out all of the requested information in this form.

As we were hit with a dmca takedown notice, we will not accept new source requests, unless they're for self-hosted stuff.


Prevents UglifyJs from exploding because something is not being trans…

…piled first

Coverage remained the same at 60.471% when pulling 31cacec4d613a190ff2f16c4ef0705af414c0c26 on James-Crean:bandaid_for_webpack into adce9d2fddaff07bc129df9ac6a06377a98d501c on UV-CDAT:master.


<IP_ADDRESS> build error in coins.cpp: base operand of ‘->’ has non-pointer type ‘const CCoins’

This is with the current Arch Linux build stack: QMake 3.0 using Qt  5.7.1, boost 1.62, gcc 6.2.1.
My build command was:
./autogen.sh
./configure --with-incompatible-bdb
make

Build fails at:
  CXX      coins.o
coins.cpp: In member function ‘double CCoinsViewCache::GetPriority(const CTransaction&, int)’:
coins.cpp:191:18: error: base operand of ‘->’ has non-pointer type ‘const CCoins’
         if (coins->nHeight <= nHeight) {
                  ^~
coins.cpp:192:84: error: base operand of ‘->’ has non-pointer type ‘const CCoins’
             dResult += (double)(coins.vout[txin.prevout.n].nValue) * (nHeight-coins->nHeight);
                                                                                ^~

I reported the coins.cpp issue seperately in #127.

Theres a couple of things that might help
If you checkout 0.9.6 do you get the same problem (i.e. its fixed)
If you do, can you pass us the makefile, we don't maintain  the arch set-up, is there a link?
so we can try and reproduce the error.

@wrapperband
coins.o in 0.9.6 builds fine as of f6cbba726e8f70a9aed2e738f5a6f13e941ebd91.
Build fails at net.o now. The error:
  CXX      net.o
net.cpp: In function 'void ThreadMapPort()':
net.cpp:1098:68: error: invalid conversion from 'int*' to 'unsigned char' [-fpermissive]
     devlist = upnpDiscover(2000, multicastif, minissdpdpath, 0, 0, &error);
                                                                    ^~~~~~
net.cpp:1098:74: error: too few arguments to function 'UPNPDev* upnpDiscover(int, const char*, const char*, int, int, unsigned char, int*)'
     devlist = upnpDiscover(2000, multicastif, minissdpdpath, 0, 0, &error);
                                                                          ^
In file included from net.cpp:25:0:
/usr/include/miniupnpc/miniupnpc.h:62:1: note: declared here
 upnpDiscover(int delay, const char * multicastif,
 ^~~~~~~~~~~~
make[3]: *** [Makefile:899: net.o] Error 1
make[3]: Leaving directory '/tmp/feathercoin/Feathercoin/src'
make[2]: *** [Makefile:921: all-recursive] Error 1
make[2]: Leaving directory '/tmp/feathercoin/Feathercoin/src'
make[1]: *** [Makefile:675: all] Error 2
make[1]: Leaving directory '/tmp/feathercoin/Feathercoin/src'
make: *** [Makefile:510: all-recursive] Error 1

An easy way to try reproducing this on Arch Linux for you would be in Docker. Follow the simple procedure on https://github.com/czka/archlinux-docker to create a current Arch Linux Docker image, run a container from it, install FTC dependencies with pacman -Syu package_name1 package_name2 ... in the container, clone FTC Git repo and try a build.

@allesklaar
0.9.6 should build perfectly with Qt 5.7.1, boost 1.62, gcc 6.2.1.
The only difference is I've never used QMake.  I'm going to create a Arch Linux VM and do a build, I'll write down my steps and post back here.

@allesklaar
Please note Feathercoin v0.9.6 is still a development/pre-release version, I still recommend you wait for this to be a full release before building.
I was able to build 0.9.6 with this:
VMware Player: Arch Linux 2017.01.01
Dependency Versions:
autoconf 2.69-4
automake 1.15-2
gcc 6.3.1-1
boost 1.63.0-1
qrencode 3.4.4-1
protobuf-3.0.2-3
qt5 5.7.1-1
miniupnpc 2.0-1
cmake 3.7.1-1
Step 1: Install dependancies:
pacman -S git
pacman -S autoconf
pacman -S automake
pacman -S gcc
pacman -S db
pacman -S boost
pacman -S qrencode
pacman -S protobuf
pacman -S qt5
pacman -S miniupnpc

Needed for Zxing
pacman -S cmake
Step 2, build and install Zxing (needed if you want QRcodes in Feathercoin-QT)
git clone https://github.com/glassechidna/zxing-cpp.git
cd zxing-cpp
mkdir build
cd build
export CXXFLAGS="-fPIC"
cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Release ..
make
make install

You then need to go and edit the LuminanceSource.h  file in /usr/local/include/zxing  and change line 30 to "public:"   instead of private
nano /usr/local/include/zxing/LuminanceSource.h
Step 3: Build Feathercoind + Feathercoin-QT
git clone -b 0.9.6 https://github.com/FeatherCoin/Feathercoin.git FTC096
cd FTC096
./autogen.sh
./configure --prefix=/home/feathercoin --disable-tests --with-gui=qt5 --with-incompatible-bdb --without-miniupnpc
make
make install

Let me know how you get on.
I hope this helps someone.

Thanks Aciddude, I see you've add that information to the guides on the forum.
http://forum.feathercoin.com/topic/8786/guide-build-feathercoind-feathercoin-qt-v0-9-6-on-arch-linux-2017-01-01

Solved in 0.9.6


Come up with an alternative means of describing message type

Possibilities:

Considering possibly removing "Success, Error, Info, Warning" from message body.
Tag on an extra parameter to allow more dynamic options instead of options listed above.

Solved in a03c8d0


deprecate kubeadm alpha in 1.21

xref kubernetes/kubeadm#2292

/assign @neolit123 @sftim

/assign @neolit123 @sftim

/assign @neolit123

/assign @neolit123

/assign @neolit123

/assign @neolit123

/retitle kubeadm: remove deprecated alpha commands

/retitle kubeadm: remove deprecated alpha commands

This PR is held - is that hold still relevant?

This PR is held - is that hold still relevant?

This PR is held - is that hold still relevant?

no
/hold cancel

This PR is held - is that hold still relevant?

no
/hold cancel

Thanks @carlory & SIG Cluster Lifecycle
/approve

Thanks @carlory & SIG Cluster Lifecycle
/approve


ARROW-3143: [C++] CopyBitmap into existing memory

Codecov Report

Merging #2526 into master will increase coverage by 1.12%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #2526      +/-   ##
==========================================
+ Coverage   87.65%   88.78%   +1.12%
==========================================
  Files         372      310      -62
  Lines       57868    54243    -3625
==========================================
- Hits        50724    48159    -2565
+ Misses       7070     6084     -986
+ Partials       74        0      -74

Impacted Files
Coverage Δ

cpp/src/arrow/util/bit-util.h
98.81% <ø> (ø)
:arrow_up:

cpp/src/arrow/util/bit-util-test.cc
99.53% <100%> (+0.03%)
:arrow_up:

cpp/src/arrow/util/bit-util.cc
97.88% <100%> (+0.4%)
:arrow_up:

rust/src/record_batch.rs

go/arrow/datatype_nested.go

rust/src/util/bit_util.rs

go/arrow/math/uint64_amd64.go

go/arrow/internal/testing/tools/bool.go

go/arrow/internal/bitutil/bitutil.go

go/arrow/memory/memory_avx2_amd64.go

... and 55 more

Continue to review full report at Codecov.

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


[ssl] individual SSL certs for workers. Each worker cert's IP SANS is…

… provisioned only for that worker's IP address.  Node common names are of the form kube-{role}-{node_ip}.

@aaronlevy pretty pretty please

Couple nits:
-break up commit message / see CONTRIBUTING doc.
-we also have an init-ssl script int he single-node dir. Can we combine these to just use your new version?
Otherwise, LGTM

Should be good to go. Would have liked to break up the first commit in two, but the consolidation and worker cert SANS happened in parallel


add .vscode to .gitingore

Coverage decreased (-94.7%) to 0.0% when pulling 474080ba8d3bc232302d817db4691c793ff5e71e on vaibhavmule:patch-1 into f4462bb64278e091011e6612feac295bf46d1136 on un33k:master.

Travis fails. files removed.


Fix typo in parser.go

andSeprator -> andSeparator

@motet-a FWIW, since you seem also interested in the JS flavor for expressions https://github.com/nexB/license-expression/ is being ported to JS by @all3fox

@pombredanne Yes, I'm watching this.


[BUG]

panic: wrong Theme version, GoAdmin v1.2.15 required Theme version are >=v0.0.38
anyone known how to fix this problem?

@linkaituo The new version will be released today.


Deleting threads from users

Hi, im glad to contribute in this project for the first time :) !
The purpose of this PR is to complete this issue.
As an admin you can now delete all the threads from an user with a new option on the users table.

As an admin or moderator you can now delete all threads from user when banning them just checking delete threads on the modal.

[!TIP]
By including the string Resolves #1156 in your PR body, you can link the issue directly so that it's closed if this PR is merged.

Thanks a bunch for this one @franbarbalopez!

@franbarbalopez Thanks, I just used it for the first time, and it works good and save me a lot of clicks.

@driesvints @tvbeek Thank you both for your words! The project was easy to setup and work with, really good work <3


Keep comments on the production elm output file

Currently all comments seem to be removed from the output elm file generated by the conversion logic. These should be kept.

Seems to relate to stil4m/elm-syntax/issues/32


Simple text file pull not working

    return fetch('https://gist.githubusercontent.com/MarkusPint/6a0f2b01ae74b79a379f21117a618909/raw/75ea7fd20a6b65f1b504030eeb1b4e56245cc20c/test.js', {
      mode: 'no-cors'
    }).then(function (res) {
      return res.text();
    }).then((text) => {
      console.log(text.length); // 0
    });

In order to fetch content from other domains, that domain has to explicitly allow it by setting CORS headers. The gist.githubusercontent.com doesn't, as evident if you curl -i <URL> it. So, there's no way you can load content from it from your site that I can see.


Making clang-format be a part of creating a new project. This makes n…

…ew project's code format more consistent

I tried this out on my side. The newly created project had the .clang-format file in it.

Btw, I just copied the format file from fprime repo.


Activity bar: active item decoration lost when hovering

Steps to Reproduce:

open a viewlet like search
notice how the viewlet shows in white
hover in and out

=> the active is no longer indicated
=> looks like the item looses the "active" class too easily
Maybe a regression from the global action work?

Caused by https://github.com/Microsoft/vscode/commit/2328998d5a311519f8b67edf7bafc432640f2569


Week 5’s second reading “Data recipes using pipes”

I have a lot of question in week 5’s second reading “Data recipes using pipes”. Apologies in advance for the long post.

In “building a recipe to identify the top 10 male names of baby boomers”
To keep only the most popular year for each name, we used: distinct(Name, .keep_all = T). How is this this keep ONLY the MOST popular year? What does .keep_all = T OR F do?

In the alternative approach of the “building a recipe to identify the top 10 male names of baby boomers”
To count the total number of men given each name during this period we used: dplyr: summarize(total = sum(count)). Could we have used the mutuate(total = sum(count)) function instead?

Why do we use ungroup() after group_by()?

In ggvis package
a.	Does stroke = ~ identify the variable we’re examining?
b.	Does layer_lines() identify the type of graph? If yes, are there other types that coule be used?

In the hipster.names section, I did not understand how the calculations were done in the summarize(total = sum(count), peak = max(count)) function.
a.	Is the total summing the count in df1, df2, and df3 for each name per year?
b.	Is the peak choosing from the count, the highest count belonging to a specific year?

Thank you in advance! @gmcirco

@CynthiaLteif Lots of good questions here:

Let's look at the code for this question:

names %>%    filter( Gender =="M" & Year >= 1946 & Year <= 1964 ) %>%   arrange( desc( Count ) ) %>%   distinct( Name, .keep_all=T ) %>%   top_n( 10, Count ) %>%   select( Name, Year, Count ) %>%   pander()
There are lot of things happening here. arrange( desc( Count ) )  sorts the names from highest to lowest by their counts. distinct( Name, .keep_all=T )  gets the unique names PER YEAR. You will notice that the names are sorted by Year-Name, so we only want the unique name-year combination (for example, James in 1947). The .keep = T just tells R to retain all the columns because by default distinct will throw away any columns you don't specify.

You can use mutate, but in this case we want to combine the rows together. Mutate will give you a column with the counts,  but it will be repeated over the groups you have in group_by

It is often good practice to ungroup after using group_by because in R any subsequent functions on that dataframe will be grouped. We might not want to perform a group operation, so ungrouping makes sure that you are starting on a normal dataframe.

That's correct. The tilde refers to specific variables that are being mapped to the visualization. You then add additional layers afterwards. layer_lines() is probably the most appropriate one here, but you can see it would look different if you added a bar chart via layer_bars().

The example in this section first finds subsets of names that meet certain criteria in df1, df2, and df3 (corresponding to: " (1) They were popular when your grandmother was young. (2) They were unpopular when your parent were young. (3) They have recently become popular again." ) You are correct that they are the name-year combinations. The peak variable finds the value, for each name, that it reached its highest value that year.

Thank you @gmcirco. Much clearer.
I have a couple of questions relating to Lab #5 Part 2, question 2.

I have followed the same steps as given in the "instructions" example yet I'm receiving the "n" to be completely different which is of course affecting the proportion. Instead of n = 77 for age = 16-18 at 7AM, I'm getting 157 (which is identical to sum(dat$age == "Age 16-18" & dat$hour12 == "7 AM", na.rm = TRUE). What is the n = 77 representing? (find picture attached)

What are n.hour, p, and p.hour and why are we expected to find them? (considering the question is reporting the proportion of accidents at "7 AM" for each age group.)

@gmcirco using "hour" instead of "hour12" fixed the issue. Thanks! But I'm still unsure why it's needed to find n.hour and p.hour.

@CynthiaLteif
The question is a bit ambiguous about this, but the intention is that:
p = proportion of accidents for each age group at that hour
n.hour = number of accidents for that hour
p.hour = proportion of accidents for that hour

If I understand correctly, there formulas for p and p.hour are identical, correct? @gmcirco

Yes, that is correct! (Unusual but correct. Personally, I do not like this
question very much)
On Wed, Feb 9, 2022, 3:17 PM Cynthia @.***> wrote:

If I understand correctly, the formulas for p and p.hour are identical,
correct? @gmcirco https://github.com/gmcirco
—
Reply to this email directly, view it on GitHub
https://github.com/Watts-College/cpp-526-spr-2022/issues/32#issuecomment-1034155151,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ATZ5TJ46Z7KARCHDAJQ5FULU2LDVVANCNFSM5NVKPD2A
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID:
@.***>

Thank you very much. Was my least favorite too, haha! @gmcirco


feat(form): wizard implementation

Please always provide the GitHub issue(s) your PR is for, as well as test URLs where your change can be observed (before and after):
Fix #340
Test URLs:

Before: https://main--mammotome--hlxsites.hlx.page/us/en/products/breast-biopsy-markers/
After: https://wizard--mammotome--hlxsites.hlx.page/us/en/products/breast-biopsy-markers/

@review @vdua

Looks good.


Generate query return type

I'm using the typescript-apollo-angular plugin to generate types and services for my queries.
When generating services a type for the query is generated as well. However, there is no simple type definition generated for the actual data that is returned. This would make typing easier when using the queries.

You can do type GetPersonsQueryData = GetPersonsQuery["getPersons"]
Or use fragments which will also generate the desired type

Of course I can define the type myself but why should I when already using a generator?
I didn't try using fragments, could you maybe elaborate with a simple example?

@sroettering
fragment PersonFragment on Person {
  id
  fullName
}
query GetPersons {
  getPersons {
    ...PersonFragment
  }
}

import * as React from "react";
import { PersonFragment } from "./generated-types";

const MyComponent: React.FC<{ persons: PersonFragment[] }> = ({ persons }) => {
  return null;
};

I do not understand why this library should generate an additional type for this.
You can still do something like this:
import * as React from "react";
import { GetPersonsQuery } from "./generated-types";

const MyComponent: React.FC<{ persons: GetPersonsQuery["getPersons"] }> = ({ persons }) => {
  return null;
};

Using fragments works for me. So I will close this issue.
The other solution GetPersonsQuery["getPersons"] is too verbose IMHO.

You could also write your own plugin to achieve this without fragments. From my perspective, I do not think that GetPersonsQuery["getPersons"] is verbose. You are just using a typescript language feature.

@sroettering you can also add the typescript-compatibility plugin, it will generate bridge types (because in the past we had those)

What about array query return types? How can you easily refer to the type of the array if GraphQL Codegen generates them inline using the Array<{...}> inline object type syntax?
E.g. if you have:
extend type Query {
  parent: Parent
}

type Parent {
  id: ID!
  children: [Child!]!
}

type Child {
  id: ID!
  title: String
  description: String
}

query GetParent {
  parent {
   children {
      id
      title
      description
    }
  }
}

Then GraphQL Codegen generates something like:
export type GetParentQuery = {
  parent: {
     __typename: 'Parent';
     id: string;
     children: Array<{
        __typename: 'Child';
        id: string;
        title: string | null;
        description: string | null;
     }>;
  }
};

If I have function which refers to the element type of children ({         __typename: 'Child';         id: string;         title: string | null;         description: string | null;      }), how can I refer to it e.g. in JSDoc comments?
/**
 * @param {???} child - What should I put here? `child` is the object of the `children` array returned by the GetParentQuery...
 */
function doSomethingWithChildOfParent(child) {
  // Do something with `child`...
}

In this case something like @param {GetParentQuery.parent.children} child won't work, because GetParentQuery.parent.children is the array of children, but I need to target the child/element type of the children array.
How can I target it? Is the only solution using a fragment on Child?
Thanks!

@antonvialibri1 I agree! We need a better solution to generate types only for data that has been asked. The current solution creates more bugs if certain data is not being fetched but exists in the type.
It is simple to get the type for a result but what about the child?

Is there any update to this?


Missing FaceUP and FaceDown

It would appear you are not currently listening to the
UIDeviceOrientationFaceDown or UIDeviceOrientationFaceUP in the case statement so those values are returning UNKNOWN
Not sure if Android provides the option which might be why it was left out but having false unknowns wasn't preferred here.  I think that it probably makes the most sense to modify the style to return an object to the listener personally.
{ orientation: portrait, direction: normal }
{ orientation: portrait, direction: up }
{ orientation: landscape, direction: down }
{ orientation: portrait, direction: upsidedown }
etc, just a thought!

Modified the Orientation.m file:
- (NSString *)getOrientationStr: (UIDeviceOrientation)orientation {
  NSString *orientationStr;
  switch (orientation) {
    case UIDeviceOrientationFaceUp:
      orientationStr = @"FACEUP";
      break;
    case UIDeviceOrientationFaceDown:
       orientationStr = @"FACEODWN";
       break;
    case UIDeviceOrientationPortrait:
      orientationStr = @"PORTRAIT";
      break;
    case UIDeviceOrientationLandscapeLeft:
    case UIDeviceOrientationLandscapeRight:

      orientationStr = @"LANDSCAPE";
      break;

    case UIDeviceOrientationPortraitUpsideDown:
      orientationStr = @"PORTRAITUPSIDEDOWN";
      break;

    default:
      orientationStr = @"UNKNOWN";
      break;
  }
  return orientationStr;
}

- (NSString *)getSpecificOrientationStr: (UIDeviceOrientation)orientation {
  NSString *orientationStr;
  switch (orientation) {
    case UIDeviceOrientationPortrait:
      orientationStr = @"PORTRAIT";
      break;

    case UIDeviceOrientationLandscapeLeft:
      orientationStr = @"LANDSCAPE-LEFT";
      break;

    case UIDeviceOrientationLandscapeRight:
      orientationStr = @"LANDSCAPE-RIGHT";
      break;

    case UIDeviceOrientationPortraitUpsideDown:
      orientationStr = @"PORTRAITUPSIDEDOWN";
      break;

    case UIDeviceOrientationFaceUp:
      orientationStr = @"FACEUP";
      break;

    case UIDeviceOrientationFaceDown:
      orientationStr = @"FACEDOWN";
      break;

    default:
      orientationStr = @"UNKNOWN";
      break;
  }
  return orientationStr;
}

@bradennapier if you could create a PR for this would be great


Problems with 0.3.3

Just noticed some issues with someone using version 0.3.3:

typing mad_chatter from command line does not mention new command
mad_chatter new chatroom should create new chatroom directory but actually created in the current directory
calling mad_chatter start/preview should give a better explanation of where to go next

found the problems. this will be fixed in next release

fixed in 0.3.4


 In my case, this prevents us from being able to read ELF files that perform floating point trigonometric methods on a 32-bit platform with hard-float support.
The issue seems to originate in src/build/elf.rs:146 and onwards, where the alignment of the first section with PT_LOAD is latched through builder.load_align.
            if segment.p_type(endian) == elf::PT_LOAD {
                let p_align = segment.p_align(endian).into();
                if builder.load_align != 0 && builder.load_align != p_align {
                    return Err(Error::new("Unsupported alignments for PT_LOAD segments"));
                }
                builder.load_align = p_align;
            }

The alignments are stored per-segment in the lines following, so it seems odd to be storing it at the builder level when I can only find references to builder.load_align in the rewrite crate.
            builder.segments.push(Segment {
                id,
                delete: false,
                p_type: segment.p_type(endian),
                p_flags: segment.p_flags(endian),
                p_offset: segment.p_offset(endian).into(),
                p_vaddr: segment.p_vaddr(endian).into(),
                p_paddr: segment.p_paddr(endian).into(),
                p_filesz: segment.p_filesz(endian).into(),
                p_memsz: segment.p_memsz(endian).into(),
                p_align: segment.p_align(endian).into(),
                sections: Vec::new(),
                marker: PhantomData,
            });

Is there a reason that I'm missing for the PT_LOAD segments to be homogenous in alignment as a requirement? If not, I'm happy to open a PR to fix this issue.
Thanks!

My assumption was that all PT_LOAD segment were page aligned, but that's clearly wrong. load_align would be better named page_size, and the requirement for all PT_LOAD segments to use it should be changed. We'll need a new way of determining the page size for cases where PT_LOAD segments don't use it as their alignment.
It seems that the program headers you gave don't satisfy the requirement that "loadable process segments must have congruent values for p_vaddr and p_offset, modulo the page size", so I guess there are some processors for which this is not a requirement?
I don't have much experience in this area, so if I have further wrong assumptions here then please correct me.

To elaborate, the congruence requirement comes from https://docs.oracle.com/cd/E23824_01/html/819-0690/chapter6-83432.html, but it does seem to be talking about something that is likely processor specific. We currently implement that requirement in Segment::add_load_segment, and the alignment passed in there is expected to be builder.load_align, as is done in the rewrite crate, so whatever fix we do will need to still handle this requirement for cases where it is needed.

I think you're right in that it's processor-dependent. This is specifically for the Cortex M4F (thumbv7em-none-eabihf), as found on the STM32G4 lineup. I've got something workable for now but it breaks the rewrite crate, so I'll have a look and see if I can fix whatever's required on the other side to make that work, too

See if #659 meets your needs.


Broadcast Flush Command does not take into account broadcast_id

Needs some cleanup to get gvm flush broadcast working properly again.

I think this was fixed by 2bca60be9d182fa68ff4e9d4a9d5658d012dbe16.


compose.service.NoSuchImage error running docker-compose up

Docker Engine
Server version: swarm/1.1.0
Server API version: 1.22
Go version (server): go1.5.3
Git commit (server): a0fd82b
OS/Arch (server): linux/amd64

Docker Compose
docker-compose version 1.8.0-rc2, build c72c966

Issue
When I run docker-compose up -d I'm getting the following output / error
Pulling registry (library/registry:2.4.0)...
swarm-agent-3D55F3B3000000: Pulling library/registry:2.4.0... : downloaded
Pulling proxy (library/nginx:1.9)...
swarm-agent-3D55F3B3000000: Pulling library/nginx:1.9... : downloaded
deploy_log_1 is up-to-date
deploy_mysql_1 is up-to-date
deploy_ui_1 is up-to-date
deploy_jobservice_1 is up-to-date
Pulling registry (library/registry:2.4.0)...
swarm-agent-3D55F3B3000000: Pulling library/registry:2.4.0... : downloaded

ERROR: for registry  Image 'library/registry:2.4.0' not found
Traceback (most recent call last):
  File "<string>", line 3, in <module>
  File "compose/cli/main.py", line 60, in main
  File "compose/cli/main.py", line 111, in perform_command
  File "compose/cli/main.py", line 814, in up
  File "compose/project.py", line 398, in up
  File "compose/parallel.py", line 60, in parallel_execute
compose.service.NoSuchImageError: Image 'library/registry:2.4.0' not found
docker-compose returned -1

Cheers,
Trevor Sullivan
Microsoft MVP: Cloud & Data Center Management
https://trevorsullivan.net
https://twitter.com/pcgeek86

Deployment on swarm is not tested, do you see the same issue when deploying on the stand alone docker daemon?

@reasonerjt We've abandoned the Docker Swarm cluster for now, and just built up a stand-alone Docker Host running Ubuntu 16.04 Xenial Xerus LTS. We're not seeing the same problem thus far, but ran into another issue. I'll close this issue as "unsupported on Swarm."


Upgrade aruba

Let's see what travis tell us. Locally it ran fine.

So has assert_partial_output been removed?

Not yet, but it will be removed with 1.0.0. Now all assert_*-methods are deprecated.

This new form seems much much messier

I'm every well aware that. Unfortunately today I've no idea how to solve it differently because I would like to have code which is

easy to extend, single place for code
flexible in use, handles partial and full matching
has only one interface to do similar things, e.g expect(command).to have_output /partial/, expect(command).to have_output 'full'

I don't think I'd ever be able to come up with that and even now I don't understand the reason for all of it.

Mix of assert_*, check_*-methods + even some expect()-calls

If you have a look at the old aruba-sources, you will see, that there was a mix of assert_*, check_*-methods + even some expect()-calls from RSpec. We decided to replace all this through RSpec-matchers to make the code easier to maintain and to use.

Following the Single responsibility principle

Having a look at #unescape you will see that it does two things:

unescaping \n \e and the like
extracting text from strings containing ANSI escape sequences

To make those use cases clear, I split up the method. Plus it was originally bound to some instance variable which controls if ansi escape sequences should be removed which is now controlled via a configuration option.

Using matchers + #values_match?

There were quite a few methods, which "have a look" at the same thing, but only matching partial or full.  Using #values_match? in our matcher we could get rid of all that methods. Although you may already know: _We get a string from cucumber, that's why we need to convert it to a Regex to make partial matching possible.
Most of those methods were only helper methods, which were used behind the scenes and littered the aruba-API.

for all of it.

I'm not sure what you mean with "for all of it". Just in the context of the change given above or all changes made recently to aruba? If you like and have time we can discuss this in IRC or even by voice call? I would like to understand your concerns. If you prefer, I could ask @mattwynne to be around as well.
To sum it up: If you have any suggestion I happy to take that into account.
Cheers,
Dennis

Maybe I've got an implementation which fits your needs better. Will update this PR soon.

If you like and have time we can discuss this in IRC or even by voice call? I would like to understand your concerns. If you prefer, I could ask @mattwynne to be around as well.

I don't have the time, sorry.
Anyhow, my concern is basically that assert_partial_output was a good, simple API.  I understand the desire to move in the direction of more composable pieces (e.g. matchers) but could assert_partial_output remain and simply delegate to:
expect(...).to have_output Regexp.new(Regexp.escape(extract_text(unescape_text(string))))

IMO, that would be better and less disruptive to users.
Alternately, if have_output can handle all that complexity internally so that it is:
expect(...).to have_output(string)

Or would this work?
expect(...).to have_output(a_string_including(string))

?

Good morning... :-) The idea with expect(...).to have_output(a_string_including(string)) sounds interesting. I will have a look into that. Thanks a lot.

In aruba#master are now some new matchers hiding those messy steps.
I will re-open this PR when I released 0.10.0 and changed the implementation here.

I will re-open this PR when I released 0.10.0 and changed the implementation here.

:+1:


New patch for es_regwen

Hi Mark,
The issue seems to be that when editing a patch (e.g. hw/top_englishbreakfast/util/sw_sources.patch), the original contents of the patch has to be exactly the same as the file it is patching.   The line number tags also need to be the same.  Log story short, patch files should not be hand edited.
Long story below:
Its a pain to make this patch.  You have to:

Make your edits to everything except the patchfile.
2a. Try to apply the original patch using git apply <patch-file>.  If it succeeds, go to step 3.
2b. Remove any references to failing files from the patch (here sw/device/lib/testing/test_rom/test_rom_start.S)
2c. Apply the patch again
2d. Make the desired changes to that file to get the result the patch would have achieved.
You now have something special: a snapshot of what your repo would look like, but for some other FPGA build.  You can now make a patch for this, to capture these deltas.  Start by making a new branch git checkout -b es_regwen_english_breakfast
Commit all the changes to this new branch.
Use git format-patch --stdout HEAD~1 > new_patch to capture the new and improved (and functional) patch file
Last step: use meld (meld new_patch  hw/top_englishbreakfast/util/sw_sources.patch) to clean up the new patchfile, moving the important changes from the new_patch to the "official patch"
Go back to your "real" branch (i.e., es_regwen) and commit the updated patch.

You may ask, why is there a patch in the repo?  Well this is how they decided to have software support for multiple FPGA builds (top_earlgrey and top_englishbreakfast) in the same repo.  It's pretty messy if you ask me though.
All the same, I went through the CI procedure for english breakfast and this worked.   Go ahead and merge it into es_regwen and see if it helps.
Signed-off-by: Martin Lueker-Boden<EMAIL_ADDRESS>

BTW: I also removed some spaces in a couple files to make this all easier to understand.  This is one place where getting your stray spaces correct really does matter


Dart complains about "unnecessary cast" that is necessary (when combining enum values)

Problem/Repro
I am using VSCode 1.77.3, on MacOS 12.6.5, with the Dart/Flutter extension pack (my dart --version is 2.19.6). With that said, let's say I have three classes, defined as such:
class Namable {
    final String name;

    const Namable(this.name);
}

enum Colors implements Namable {
    red("red"),
    yellow("yellow"),
    blue("blue");

    final String name;

    const Colors(this.name);
}

enum Shapes implements Namable {
    square("square"),
    triangle("triangle"),
    circle("circle");

    final String name;

    const Shapes(this.name);
}

Now, let's say I wish to store a list of all the Namables I've created:
final List<Namable> allNamables = Colors.values + Shapes.values;

The compiler complains that "The argument type 'List<Shapes>' can't be assigned to the parameter type 'List<Colors>'" for Shapes.values. So I specify a cast for Colors.values:
final List<Namable> allNamables = (Colors.values as List<Namable>) + Shapes.values;

Except now the compiler warns me that I'm performing an unnecessary cast. As far as I'm aware, this is a necessary cast to write two enum value lists together like this (although I am somewhat new to the dart language, so this might be a false assumption).
Solution (I think)
I believe the problem here is that the warning about an "unnecessary cast" pops up when it shouldn't. I know there are other ways to express allNamables the way I want, I just happened to find this strange scenario that I think is just an edge case that needs to be addressed.
It's also possible I'm misunderstanding the warnings/errors, so the solution in this case might be a change of wording. But in either case, something feels off to me here.
I appreciate the hard work from you guys! Dart is an awesome language, and I dare say it's my most favorite to work with in all the languages I've written code in (and that's a decent list).

The "unnecessary cast" is a warning from the analyzer. You get that for almost all up-casts, and it can be annoying, because there are a lot of places where an up-cast does change the behavior of the program.
It's just not particularly easy for the analyzer to know that, because it doesn't try to remove the cast and analyze the entire program again, to see if it makes a difference. So it guesses. Sometimes (fairly often) it guesses incorrectly.
The cast isn't as much unnecessary here, as it is wrong. You can cast Colors.values to List<Namable>, but it will still fail at runtime if you try to add a List<Shapes> to it, because the argument to List<Colors>.operator+ has type List<Colors>. The cast just hides the incompatibility behind the unsafe covariance of generics.
You can do instead do Colors.values.cast<Namable>() + Shapes.values, or what I'd recommend:
  final List<Namable> allNamables = [...Colors.values, ...Shapes.values];

Oh perfect, I didn't even realize dart had a spread operator. That's definitely more sensible than casting and +ing lists together. Thanks for the thorough explanations guys!


kubelet: set kubelet parameters via an intermediate configuration file

Description of changes
Kubelets have deprecated using arguments such as --address, and we should
instead use the KubeletConfiguration struct as specified in
https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/#kubelet-conf-d.
This is a work in progress.

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

It seems like the only deprecation warning for the kubelet now is:
machine1 # [    9.025319] kubelet[1116]: Flag --pod-infra-container-image has been deprecated, will be removed in a future release. Image garbage collector will get sandbox image information from CRI.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-already-reviewed/2617/1461


Add RPC call concurrency restrictions to deploy command options

Errors often occur in RPC call quotes while executing mud deploy command, so I want to limit the number of calls at a time to suppress errors.
For example

Option: --rpcConcurrency
Meaning: Limit the concurrency of RPC calls
Type: number
Default value: 1000

https://mud.dev/cli/deploy

great suggestion!
prob best to do this at the viem client level, maybe with a custom transport, and could lean on something like p-queue for it

Thanks, it does indeed look like a good idea to use custom transport. I already have one implemented in a naive way, can I submit it to PR once I have it? If it is not a good implementation, I will re-implement it with custom transport.

Thanks for taking a stab at this! And sorry to jostle you around, but I do think a custom transport with throttling built in would be better and general purpose for ~any viem user!

Understood.
I made it once because I needed it right at hand, but I'll fix the PR later when I have more time👍

@hourglasshoro A question for you: https://twitter.com/indexsupply/status/1754924224375095349


Build fail with unknown feature const_atomic_bool_new

Hi.
cargo build --release is fail with below error. And cargo update is also failed.
Any ideas?
cargo build
$ cargo build --release
   Compiling typenum v1.9.0
   Compiling scopeguard v0.3.3
   Compiling rayon-core v1.3.0
   Compiling libc v0.2.34
   Compiling winapi-build v0.1.1
   Compiling either v1.4.0
   Compiling lazy_static v0.2.11
   Compiling void v1.0.2
   Compiling cfg-if v0.1.2
   Compiling nodrop v0.1.12
   Compiling lazy_static v1.0.0
   Compiling winapi v0.2.8
   Compiling version_check v0.1.3
   Compiling constant_time_eq v0.1.3
   Compiling regex-syntax v0.4.2
   Compiling utf8-ranges v1.0.0
   Compiling cc v1.0.3
   Compiling matches v0.1.6
   Compiling byte-tools v0.2.0
   Compiling serde v1.0.27
   Compiling unicode-normalization v0.1.5
   Compiling fake-simd v0.1.2
   Compiling dtoa v0.4.2
   Compiling fnv v1.0.6
   Compiling yansi v0.3.4
   Compiling safemem v0.2.0
   Compiling same-file v0.1.3
   Compiling siphasher v0.2.2
error[E0635]: unknown feature `const_atomic_bool_new`
 --> /Users/conao/.cargo/registry/src/github.com-1ecc6299db9ec823/yansi-0.3.4/src/lib.rs:1:40
  |
1 | #![cfg_attr(feature="nightly", feature(const_atomic_bool_new))]
  |                                        ^^^^^^^^^^^^^^^^^^^^^

   Compiling itoa v0.3.4
error: aborting due to previous error

For more information about this error, try `rustc --explain E0635`.
error: Could not compile `yansi`.
warning: build failed, waiting for other jobs to finish...
error: build failed

cargo update
https://github.com/SergioBenitez/Rocket/issues/433 is recommends running cargo update, but it also fails.
$ cargo update
    Updating git repository `https://github.com/SergioBenitez/ring`
    Updating crates.io index
    Updating git repository `https://github.com/SergioBenitez/Rocket`
error: failed to select a version for the requirement `untrusted = "^0.5"`
  candidate versions found which didn't match: 0.6.2
  location searched: crates.io index
required by package `ring v0.11.1 (https://github.com/SergioBenitez/ring?branch=v0.11#267d0500)`
    ... which is depended on by `cookie v0.9.1`
    ... which is depended on by `rocket v0.3.17 (https://github.com/SergioBenitez/Rocket?branch=v0.3#5ee9fbd2)`
    ... which is depended on by `rocket_codegen v0.3.17 (https://github.com/SergioBenitez/Rocket?branch=v0.3#5ee9fbd2)`
    ... which is depended on by `tokei_rs v0.1.0 (/Users/conao/Develop/git/tokei_rs)`

rustup show
$ rustup show
Default host: x86_64-apple-darwin

installed toolchains
--------------------

stable-x86_64-apple-darwin
nightly-x86_64-apple-darwin (default)

active toolchain
----------------

nightly-x86_64-apple-darwin (directory override for '/Users/conao/Develop/git/tokei_rs')
rustc 1.35.0-nightly (26b4cb484 2019-03-09)

Thank you for your issue! This should no longer be the case as the dependencies are now up to date.

OK. Thanks!


⚠ Turnos 24x7 has degraded performance

In 19224e9, Turnos 24x7 (https://reservas-dev.alternativasinteligentes.com/) experienced degraded performance:

HTTP code: 200
Response time: 906 ms

Resolved: Turnos 24x7 performance has improved in 66ccc4c.


[reopened] Automatic Re-connection to MongoDB on Node-RED Startup - v2.2.1

I refer to my old closed issue #20
Hi steineey,
thanks for your replay, i've tested this version (v2.2.1) but unfortunately it doesn't seem to be functioning as expected.
I've done some tests and with MongoDB service stopped, it returns an "connect ETIMEDOUT" error (with node status reporting "operation failed") followed by a "Topology is closed" error (if i trigger a new mongodb query), which is the correct behavior when the database is offline.
Unfortunately, even after starting the database service, the Topology error persists and the node status still reporting "operation failed".

If i restart Node-Red or re-deploy the flows, the MongoDB node start working as expected.
To reproduce the error I did the following steps:

Turned off the MongoDB service and restarted Node-RED.
Executed a query on MongoDB through Node-RED.
Waited for the initial "operation failed".
Started the MongoDB service.
Attempted to perform a new query on MongoDB via Node-RED.

Here an example flow with the basic config i use for Node-Red:
[
    {
        "id": "c2a7c2a49b026b4f",
        "type": "mongodb4",
        "z": "b2dbc784a62faa82",
        "clientNode": "56940934ae60a779",
        "mode": "collection",
        "collection": "TEST",
        "operation": "findOne",
        "output": "toArray",
        "maxTimeMS": "",
        "handleDocId": false,
        "name": "",
        "x": 500,
        "y": 440,
        "wires": [
            [
                "058529797128eb9f"
            ]
        ]
    },
    {
        "id": "604ed2e4f2616592",
        "type": "inject",
        "z": "b2dbc784a62faa82",
        "name": "",
        "props": [
            {
                "p": "payload"
            },
            {
                "p": "topic",
                "vt": "str"
            }
        ],
        "repeat": "",
        "crontab": "",
        "once": false,
        "onceDelay": 0.1,
        "topic": "",
        "payload": "",
        "payloadType": "date",
        "x": 160,
        "y": 440,
        "wires": [
            [
                "71998d2ef11883d1"
            ]
        ]
    },
    {
        "id": "058529797128eb9f",
        "type": "debug",
        "z": "b2dbc784a62faa82",
        "name": "debug 13",
        "active": true,
        "tosidebar": true,
        "console": false,
        "tostatus": false,
        "complete": "false",
        "statusVal": "",
        "statusType": "auto",
        "x": 680,
        "y": 440,
        "wires": []
    },
    {
        "id": "71998d2ef11883d1",
        "type": "function",
        "z": "b2dbc784a62faa82",
        "name": "function",
        "func": "msg.payload = { ID_VALUE: 100 };\nreturn msg;",
        "outputs": 1,
        "noerr": 0,
        "initialize": "",
        "finalize": "",
        "libs": [],
        "x": 320,
        "y": 440,
        "wires": [
            [
                "c2a7c2a49b026b4f"
            ]
        ]
    },
    {
        "id": "56940934ae60a779",
        "type": "mongodb4-client",
        "name": "MongoDB test",
        "protocol": "mongodb",
        "hostname": "<IP_ADDRESS>",
        "port": "27017",
        "dbName": "TEST",
        "appName": "",
        "authSource": "",
        "authMechanism": "DEFAULT",
        "tls": false,
        "tlsCAFile": "",
        "tlsCertificateKeyFile": "",
        "tlsInsecure": false,
        "connectTimeoutMS": "30000",
        "socketTimeoutMS": "0",
        "minPoolSize": "0",
        "maxPoolSize": "100",
        "maxIdleTimeMS": "0",
        "uri": "",
        "advanced": "{}",
        "uriTabActive": "tab-uri-simple"
    }
]

I appreciate your attention to this matter and would be grateful for any further assistance or suggestions.
Best regards,
polu

Hi polu,
thank you for testing and feedback. I can reproduce your error.
Please check out this fix<EMAIL_ADDRESS>

Hi Steineey,
I have tested your new version in various scenarios, and it works perfectly! Thank you so much for your efforts.
I'm eagerly looking forward to the final version being available on the Node-RED repository (the current available version is v2.0.0) and npm.
Best regards,
Polu

Hi Polu,
thank you for testing.  I published the final v2.2.2 and updated the Node-RED repository.
npm install --save --omit=dev<EMAIL_ADDRESS>
Best regards
Steineey