Can't drag and drop in new test suite

Describe the bug
In the test section, in the request on a test suite, is not possible to drag and drop the requests
To Reproduce

Create a design document
Create at least requests
Create a test suite with at least 2 request
Try to move a request

Expected behavior
I Expect there is a button to move the position request
Screenshots

Desktop (please complete the following information):

App version: 2021.4.1
I've installed with .exe on Windows 10 SO

Hi @sarmancoder, thank you for reporting this!
I'm not sure if we ever supported this (perhaps @wdawson or @DMarby can say if it was ever supported).
In any case this seems to be the case still. We are currently planning on revamping Insomnia's test feature and will keep this in mind for future changes. For now marking it as a possible improvement and will update you here on the issue in case we fix/improve it.
Feel free to report any other issues or feature requests here on GitHub, we are very much looking for feedback on things we can improve with Insomnia Test feature.


[Hub Generated] Publish private branch 'servicelinker/qianwens/118'

This is a PR generated at OpenAPI Hub. You can view your work branch via this link.
ARM API Information (Control Plane)
Azure 1st Party Service can try out the Shift Left experience to initiate API design review from ADO code repo.  If you are interested, may request engineering support by filling in with the form https://aka.ms/ShiftLeftSupportForm.
Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[ ] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month.
When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month.
By default, Azure SDKs of all languages (.NET/Python/Java/JavaScript for both management-plane SDK and data-plane SDK, Go for management-plane SDK only ) MUST be refreshed with/after swagger of new version is published. If you prefer NOT to refresh any specific SDK language upon swagger updates in the current PR, please leave details with justification here.

Contribution checklist (MS Employees Only):

[ ] I commit to follow the Breaking Change Policy of "no breaking changes"
[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[ ] Check this box if any of the following apply to the PR so that the label "ARMReview" and "WaitForARMFeedback" will be added by bot to kick off ARM API Review.  Missing to check this box in the following scenario may result in delays to the ARM manifest review and deployment.

Adding a new service
Adding new API(s)
Adding a new API version
-[ ] To review changes efficiently, ensure you copy the existing version into the new directory structure for first commit and then push new changes, including version updates, in separate commits. You can use OpenAPIHub to initialize the PR for adding a new version. For more details refer to the wiki.

[ ] Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If you have any breaking changes as defined in the Breaking Change Policy, request approval from the Breaking Change Review Board.
Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Additional details on the process and office hours are on the Breaking Change Wiki.
NOTE: To update API(s) in public preview for over 1 year (refer to Retirement of Previews)
Please follow the link to find more details on PR review process.

The PR is created based on the updates in the private branch. The updates in the PR has already been reviewed and approved with this PR Azure/azure-rest-api-specs-pr/10745

@raych1 could you please help approve this PR as the breaking change not released yet.

@raych1 could you please help approve this PR as the breaking change not released yet.

This PR contains more changes than this approved PR. It must be another PR reviewed too, can you paste the link here?

@raych1 could you please help approve this PR as the breaking change not released yet.

This PR contains more changes than this approved PR. It must be another PR reviewed too, can you paste the link here?

Azure/azure-rest-api-specs-pr/pull/10358
Here is the PR for another change.


WIP Dialtone V6 Component Modal Implementation

Dialtone V6 Component Modal Implementation

:hammer_and_wrench: Type Of Change

[ ] Fix
[x] Feature
[x] Refactoring
[ ] Documentation

:book: Description

Updated Modal css component
:bulb: Context

Closes #252
Pull Request Checklist

[x] Ask the contributors if a similar effort is already in process or has been solved.
[x] Review the contribution guidelines.
[ ] Ensure all gulp scripts successfully compile.
[x] Update, remove, or extend all affected documentation.
[x] Provide a description what is being changed, extended, or removed.
[x] Link to any issue(s) this request is resolving.
[ ] Ensure no private Dialpad links or info are in the code or pull request description (Dialtone is a public repo!).
[ ] Request a review from Drew Chandler, Joshua Hynes, or Ted Goas.

:camera: Screenshots / GIFs

Pending a few discussion items

@dialpad-drew Could you have a look at the background colors as they are defined as named colors in the design and hsl in the styles and let me know if they need updated.

@dialpad-drew Could you have a look at the modal background colors as they are defined as named colors in the design and hsl in the styles and let me know if they need updated.

Use the existing colors.

@dialpad-drew Made updates to reflect our discussions in the designs, looks like it should address all of your comments on the PR

Updated banner padding to address comments


What percent of our census block groups are not in a census tract of the comparison indicator?

Problem statement / question
The comparison tool already answers the question, what % of census tracts from the comparison indicator (e.g., CalEnviroScreen) include one or more census block groups from the current version of the CEJST score.
This asks an inverse question: what percent of CBGs from the current version of the CEJST score exist outside the areas prioritized by a comparison indicator? For instance, we might find that 10% of CBGs from the CEJST score are in census tracts that CalEnviroScreen does not consider disadvantaged communities.

In review in https://github.com/usds/justice40-tool/pull/266


Use overlay2 for docker storage

Use overlay2 storage driver instead of vfs. This significantly speeds up Container operations such as updating Core or installing Add-ons.
Also use a Docker volume to make sure Docker can use overlay2 properly.

Related: https://github.com/home-assistant/supervisor/pull/3337

FWIW, starting dockerd with overlay2 graph driver causes the following error when /var/lib/docker is an overlayfs by itself (e.g. inside a container):
ERRO[2021-12-06T17:11:22.279070304Z] failed to mount overlay: invalid argument     storage-driver=overlay2
INFO[2021-12-06T17:11:22.279466366Z] stopping event stream following graceful shutdown  error="context canceled" module=libcontainerd namespace=plugins.moby
INFO[2021-12-06T17:11:22.279475355Z] stopping healthcheck following graceful shutdown  module=libcontainerd
WARN[2021-12-06T17:11:23.280723316Z] grpc: addrConn.createTransport failed to connect to {unix:///var/run/docker/containerd/containerd.sock  <nil> 0 <nil>}. Err :connection error: desc = "transport: Error while dialing dial unix:///var/run/docker/containerd/containerd.sock: timeout". Reconnecting...  module=grpc
failed to start daemon: error initializing graphdriver: driver not supported


Overhaul NuGet versions to include "main" or "develop"

Overhaul NuGet versions to include "main" or "develop"

/azp run


Suggestion for the French language

Disclaimer : this might come down to geo/political preferences, but I thought the information is worth sharing.
When listening to the Meta model in the French language, I found some pronunciation/accent surprising (I am a French native speaker from France). Looking at the code, it seems the Meta model is mainly trained on the CSS10_fr dataset. So I went to listen to this dataset and indeed found the same "suprises" I heard before. Information on the internet is scarce, but it seems the speaker might be from Canada. So, although being definitely French in the grammatical sense, the pronunciation is more fr-ca than fr-fr.
So if by any chance you intended to retrain the Meta model, and are ok to make the French language + French accent sounding more "French from France", I would suggest avoiding CSS10 and using the Synpaflex Corpus ( https://www.ortolang.fr/market/corpora/synpaflex-corpus , I have seen reference to a "FrenchExpressive" corpus in the code, don't know if it is this one) or the SIWIS dataset ( https://datashare.ed.ac.uk/handle/10283/2353 , at least the subparts that are segmented).
Here are the loading functions I made (the Synpaflex one only take the utterances for which the text was normalized by the authors, but an extended version could easily be made) :
import glob
from pathlib import Path
import os

def build_path_to_transcript_dict_synpaflex_norm_subset():
    root = "/data/inputs/speech_natural/fr/synpaflex-corpus/5/v0.1/"
    path_to_transcript = dict()
    for text_path in glob.iglob(os.path.join(root, "**/*_norm.txt"), recursive=True):
        with open(text_path, "r", encoding="utf8") as file:
            norm_transcript = file.read()
        path_obj = Path(text_path)
        wav_path = str((path_obj.parent.parent / path_obj.name[:-9]).with_suffix(".wav"))
        if Path(wav_path).exists():
            path_to_transcript[wav_path] = norm_transcript
    return path_to_transcript

def build_path_to_transcript_dict_siwis_subset():
    root = "/data/inputs/speech_natural/fr/SiwisFrenchSpeechSynthesisDatabase/"
    # part4 and part5 are not segmented
    sub_dirs = ["part1", "part2", "part3"]
    path_to_transcript = dict()
    for sd in sub_dirs:
        for text_path in glob.iglob(os.path.join(root, "text", sd, "*.txt")):
            with open(text_path, "r", encoding="utf8") as file:
                norm_transcript = file.read()
            path_obj = Path(text_path)
            wav_path = str((path_obj.parent.parent.parent / "wavs" / sd / path_obj.stem).with_suffix(".wav"))
            if Path(wav_path).exists():
                path_to_transcript[wav_path] = norm_transcript
    return path_to_transcript

Thank you very much for sharing! As someone who doesn't speak French, I had no idea that the CSS10-French is not the European French. As you said, there is little documentation about this data. I will add the new french data to the next version of the toolkit which comes with an entirely new architecture, so I will also definitely re-train the large multilingual model. In general, dialects and accents are difficult in the TTS case, because those things are often poorly annotated. The multilingual librispeech for French probably also includes a lot of French that is not the variant spoken in France.

Thanks a lot ! I can leave the issue open as a reminder or close it to tidy things up, as you prefer.

Let's leave it open as reminder, I will close it once the release that supports the new datasets is out.

The data handling is now in the experimental branch that will become the new main branch once it is finished:
https://github.com/DigitalPhonetics/IMS-Toucan/blob/9a4e10330cd2253a1264ee997465dbd3c9cc1240/TrainingInterfaces/TrainingPipelines/PortaSpeech_MetaCheckpoint.py#L157
Also, since the Blizzard Challenge 2023 is based on French data, I included those datasets as well. Blizzard Challenge Datasets are usually very high quality. So hopefully the next version will speak much better european French :)

Today's release makes those datasets the new default for the French part of the multilingual setup together with the previously used Multilingual Librispeech French dataset. The model included in the new release is trained on the French-French datasets. If it still sounds like Canadian-French, it must be due to the Multilingual Librispeech French dataset, which is still the largest amount of French data in the pretraining. A demo that requires no setup is running here: https://huggingface.co/spaces/Flux9665/ThisSpeakerDoesNotExist
Can you please let me know if it still sounds Canadian to you as native speaker? In that case I'll probably separate the MLS dataset out and give it its own language ID, I did the same with European Portuguese and Brazilian Portuguese.

Congrats on the new release :) It does definitely sound better accent-wise.
I heard some things that were incorrect especially on numbers, but thanks to the new visualisation you put in place in the demo, I realised the phonemizer was to blame for that. I guess I'll have to open issues on another repository ;)
So we can close this one.
I'm waiting on some data but then will try to fine-tune with the new architecture and keep you advised if any performance / usability issues arise.
Thanks again for your work.

I remembered this discussion while I was struggling to make Meta voice pronounce "ɛ̃" (like in "dessin", or "un humain") in French from France. That's why I added a comment here.
If I generate "pas besoin de vous faire un dessin" it sounds like "pas besoin de vous faire un dessai" so the last "in" is pronounced like "ẽ" instead of "ɛ̃" although the first one (in "besoin") is OK.
https://user-images.githubusercontent.com/91517923/225521496-657699d1-7039-4c1c-b719-74194aacacc7.mp4
Nearly all ending "ɛ̃" are mispronounced in sentences. But if I give it "le matin, le patin, le gratin," the pronunciation is OK.
I tried all variant of "ɛ̃" (dessin, dessein, dessain) but the model keeps saying it like "ẽ". I am not sure about "humain" and "chemin" to be pronounced as fr-ca or fr-fr.
@tomschelsen you mentionned a phonemizer problem but here it looks like it does the right job :
~pa bəzwˈɛ də vu fˈɛʁ œ dɛsˈɛ.~#
Is there a way to make the Meta model always pronounce "ɛ̃" consistently as fr-fr or it is "soldered" onto the model for ever :wink ?

For completeness I want to mention in this thread too: There seems to be a bug with ɛ̃, which I'll investigate in the next few days.


Grafana Alloy fails to parse environment variable defined in /etc/default/alloy

What's wrong?
As part of configuring Alloy to push metrics to Prometheus, I am using the prometheus.remote_write component with basic_auth.
The configuration looks like below:
prometheus.remote_write "default" {
  endpoint {
    url = "https://prometheus-us-central1.grafana.net/api/prom/push"
    basic_auth {
      password = "${GRAFANA_CLOUD_KEY}"
      username = my_username
    }
  }
}

The GRAFANA_CLOUD_KEY environment variable is appended to the /etc/default/alloy which is pre-populated by Alloy and looks like below:
## Description: Grafana Alloy settings

# The configuration file holding the Alloy config.
CONFIG_FILE="/etc/alloy/config.alloy"

# User-defined arguments to pass to the run command.
CUSTOM_ARGS="--server.http.listen-addr=<IP_ADDRESS>:12345 --stability.level=experimental"

# Restart on system upgrade. Defaults to true.
RESTART_ON_UPGRADE=true
GRAFANA_CLOUD_KEY=my_value

After the /etc/default/alloy was changed, the systemd service for alloy was restarted and the configuration was tested. When trying to push metrics to Prometheus, the journalctl logs look like below:
Dec 09 11:15:01 ip-10-48-136-63 alloy[3236]: {"ts":"2024-12-09T11:15:01.26273779Z","level":"error","msg":"non-recoverable error","component_path":"/","component_id":"prometheus.remote_write.default","subcomponent":"rw","remote_name":"73d8a3","url":"https://prometheus-us-central1.grafana.net/api/prom/push","count":8, "exemplarCount":0,"err":"server returned HTTP status 401 Unauthorized: {\"status\":\"error\",\"error\":\"authentication error: invalid token\"}"}>

I can confirm that it is not an issue with the token that I am using because the authentication works when I am replacing the token directly in the /etc/alloy/config.alloy file without referencing the "${GRAFANA_CLOUD_KEY}" env variable.
Steps to reproduce
Define an environment variable in /etc/default/alloy and reference it in the /etc/alloy/config.alloy configuration file. See if Alloy parses the variable as expected. In my case I used an environment variable to authenticate against a Prometheus endpoint inside the prometheus.remote_write component.
System information
22.04.1-Ubuntu x86_64
Software version
Alloy version v1.5.1
Configuration
/etc/alloy/config.alloy:

logging {
  level = "info"
  format = "json"
}

otelcol.receiver.otlp "default" {
  grpc {}
  http {}

  output {
    metrics = [otelcol.processor.filter.default.input]
  }
}

otelcol.processor.filter "default" {
  metrics {
    datapoint = [
      "attributes[\"service\"] == nil",
    ]
  }
  output {
    metrics = [otelcol.processor.attributes.default.input]
  }
}

otelcol.processor.attributes "default" {
  action {
    key = "account"
    action = "upsert"
    value = "myenv"
  }
  action {
    key = "environment"
    action = "upsert"
    value = "myenv"
  }
  output {
    metrics = [otelcol.processor.batch.default.input]
  }
}

otelcol.processor.batch "default" {
  output {
    metrics = [otelcol.exporter.prometheus.grafana_cloud.input]
  }
}

otelcol.exporter.prometheus "grafana_cloud" {
  forward_to = [prometheus.remote_write.default.receiver]
}

prometheus.remote_write "default" {
  endpoint {
    url = "https://prometheus-us-central1.grafana.net/api/prom/push"
    basic_auth {
      password = "${GRAFANA_CLOUD_KEY}"
      username = "my_username"

    }
  }
}

livedebugging {
  enabled = true
}

/etc/default/alloy:

## Description: Grafana Alloy settings

# The configuration file holding the Alloy config.
CONFIG_FILE="/etc/alloy/config.alloy"

# User-defined arguments to pass to the run command.
CUSTOM_ARGS="--server.http.listen-addr=<IP_ADDRESS>:12345 --stability.level=experimental"

# Restart on system upgrade. Defaults to true.
RESTART_ON_UPGRADE=true
GRAFANA_CLOUD_KEY=my_key

Logs
Dec 09 11:14:55  systemd[1]: Started Vendor-agnostic OpenTelemetry Collector distribution with programmable pipelines.
Dec 09 11:14:56  alloy[3236]: {"ts":"2024-12-09T11:14:56.189255932Z","level":"info","boringcrypto enabled":false}
Dec 09 11:14:56  alloy[3236]: {"ts":"2024-12-09T11:14:56.156191158Z","level":"info","source":{"function":"github.com/KimMachineGun/automemlimit/memlimit.SetGoMemLimitWithOpts","file":"/go/pkg/mod/github.com/!kim!machine!gun/automemlimit@v0.6.0/memlimit/memlimit.go","line":170},"msg":"memory is not limited, skipping: %v","package":"github.com/KimMachineGun/automemlimit/memlimit","!BADKEY":"memory is not limited"}
Dec 09 11:14:56  alloy[3236]: {"ts":"2024-12-09T11:14:56.189344817Z","level":"info","msg":"no peer discovery configured: both join and discover peers are empty","service":"cluster"}
Dec 09 11:14:56  alloy[3236]: {"ts":"2024-12-09T11:14:56.189352719Z","level":"info","msg":"running usage stats reporter"}
Dec 09 11:14:56  alloy[3236]: {"ts":"2024-12-09T11:14:56.189358717Z","level":"info","msg":"starting complete graph evaluation","controller_path":"/","controller_id":"","trace_id":"3aa1ecff1759a4f5d5e3bf28d741b3ce"}
Dec 09 11:14:56  alloy[3236]: {"ts":"2024-12-09T11:14:56.189388917Z","level":"info","msg":"finished node evaluation","controller_path":"/","controller_id":"","trace_id":"3aa1ecff1759a4f5d5e3bf28d741b3ce","node_id":"otel","duration":3992}
Dec 09 11:14:56  alloy[3236]: {"ts":"2024-12-09T11:14:56.189400887Z","level":"info","msg":"finished node evaluation","controller_path":"/","controller_id":"","trace_id":"3aa1ecff1759a4f5d5e3bf28d741b3ce","node_id":"tracing","duration":7646}
Dec 09 11:14:56  alloy[3236]: {"ts":"2024-12-09T11:14:56.189410284Z","level":"info","msg":"finished node evaluation","controller_path":"/","controller_id":"","trace_id":"3aa1ecff1759a4f5d5e3bf28d741b3ce","node_id":"remotecfg","duration":120359}
Dec 09 11:14:56  alloy[3236]: {"ts":"2024-12-09T11:14:56.189421881Z","level":"info","msg":"applying non-TLS config to HTTP server","service":"http"}
Dec 09 11:14:56  alloy[3236]: {"ts":"2024-12-09T11:14:56.189442005Z","level":"info","msg":"finished node evaluation","controller_path":"/","controller_id":"","trace_id":"3aa1ecff1759a4f5d5e3bf28d741b3ce","node_id":"http","duration":17593}
Dec 09 11:14:56  alloy[3236]: {"ts":"2024-12-09T11:14:56.189452718Z","level":"info","msg":"finished node evaluation","controller_path":"/","controller_id":"","trace_id":"3aa1ecff1759a4f5d5e3bf28d741b3ce","node_id":"cluster","duration":953}
Dec 09 11:14:56  alloy[3236]: {"ts":"2024-12-09T11:14:56.189461218Z","level":"info","msg":"finished node evaluation","controller_path":"/","controller_id":"","trace_id":"3aa1ecff1759a4f5d5e3bf28d741b3ce","node_id":"livedebugging","duration":18166}
Dec 09 11:14:56  alloy[3236]: {"ts":"2024-12-09T11:14:56.189469302Z","level":"info","msg":"finished node evaluation","controller_path":"/","controller_id":"","trace_id":"3aa1ecff1759a4f5d5e3bf28d741b3ce","node_id":"ui","duration":889}
Dec 09 11:14:56  alloy[3236]: {"ts":"2024-12-09T11:14:56.189477168Z","level":"info","msg":"replaying WAL, this may take a while","component_path":"/","component_id":"prometheus.remote_write.default","subcomponent":"wal","dir":"/var/lib/alloy/data/prometheus.remote_write.default/wal"}
Dec 09 11:14:56  alloy[3236]: {"ts":"2024-12-09T11:14:56.189485584Z","level":"info","msg":"WAL segment loaded","component_path":"/","component_id":"prometheus.remote_write.default","subcomponent":"wal","segment":0,"maxSegment":1}
Dec 09 11:14:56  alloy[3236]: {"ts":"2024-12-09T11:14:56.189492831Z","level":"info","msg":"WAL segment loaded","component_path":"/","component_id":"prometheus.remote_write.default","subcomponent":"wal","segment":1,"maxSegment":1}
Dec 09 11:14:56  alloy[3236]: {"ts":"2024-12-09T11:14:56.189499318Z","level":"info","msg":"Starting WAL watcher","component_path":"/","component_id":"prometheus.remote_write.default","subcomponent":"rw","remote_name":"73d8a3","url":"https://prometheus-us-central1.grafana.net/api/prom/push","queue":"73d8a3"}
Dec 09 11:14:56  alloy[3236]: {"ts":"2024-12-09T11:14:56.189508277Z","level":"info","msg":"Starting scraped metadata watcher","component_path":"/","component_id":"prometheus.remote_write.default","subcomponent":"rw","remote_name":"73d8a3","url":"https://prometheus-us-central1.grafana.net/api/prom/push"}
Dec 09 11:14:56  alloy[3236]: {"ts":"2024-12-09T11:14:56.189515918Z","level":"info","msg":"finished node evaluation","controller_path":"/","controller_id":"","trace_id":"3aa1ecff1759a4f5d5e3bf28d741b3ce","node_id":"prometheus.remote_write.default","duration":20163235}
Dec 09 11:14:56  alloy[3236]: {"ts":"2024-12-09T11:14:56.189526981Z","level":"info","msg":"Replaying WAL","component_path":"/","component_id":"prometheus.remote_write.default","subcomponent":"rw","remote_name":"73d8a3","url":"https://prometheus-us-central1.grafana.net/api/prom/push","queue":"73d8a3"}
Dec 09 11:14:56  alloy[3236]: {"ts":"2024-12-09T11:14:56.189541885Z","level":"info","msg":"finished node evaluation","controller_path":"/","controller_id":"","trace_id":"3aa1ecff1759a4f5d5e3bf28d741b3ce","node_id":"otelcol.exporter.prometheus.grafana_cloud","duration":219983}
Dec 09 11:14:56  alloy[3236]: {"ts":"2024-12-09T11:14:56.189552371Z","level":"info","msg":"finished node evaluation","controller_path":"/","controller_id":"","trace_id":"3aa1ecff1759a4f5d5e3bf28d741b3ce","node_id":"otelcol.processor.batch.default","duration":270230}
Dec 09 11:14:56  alloy[3236]: {"ts":"2024-12-09T11:14:56.18956301Z","level":"info","msg":"finished node evaluation","controller_path":"/","controller_id":"","trace_id":"3aa1ecff1759a4f5d5e3bf28d741b3ce","node_id":"otelcol.processor.attributes.default","duration":255542}
Dec 09 11:14:56  alloy[3236]: {"ts":"2024-12-09T11:14:56.189572983Z","level":"info","msg":"finished node evaluation","controller_path":"/","controller_id":"","trace_id":"3aa1ecff1759a4f5d5e3bf28d741b3ce","node_id":"otelcol.processor.filter.default","duration":703866}
Dec 09 11:14:56  alloy[3236]: {"ts":"2024-12-09T11:14:56.189582373Z","level":"info","msg":"finished node evaluation","controller_path":"/","controller_id":"","trace_id":"3aa1ecff1759a4f5d5e3bf28d741b3ce","node_id":"otelcol.receiver.otlp.default","duration":275407}
Dec 09 11:14:56  alloy[3236]: {"ts":"2024-12-09T11:14:56.18959577Z","level":"info","msg":"finished node evaluation","controller_path":"/","controller_id":"","trace_id":"3aa1ecff1759a4f5d5e3bf28d741b3ce","node_id":"logging","duration":381370}
Dec 09 11:14:56  alloy[3236]: {"ts":"2024-12-09T11:14:56.189640839Z","level":"info","msg":"finished node evaluation","controller_path":"/","controller_id":"","trace_id":"3aa1ecff1759a4f5d5e3bf28d741b3ce","node_id":"labelstore","duration":29356}
Dec 09 11:14:56  alloy[3236]: {"ts":"2024-12-09T11:14:56.189663175Z","level":"info","msg":"finished complete graph evaluation","controller_path":"/","controller_id":"","trace_id":"3aa1ecff1759a4f5d5e3bf28d741b3ce","duration":25552368}
Dec 09 11:14:56  alloy[3236]: {"ts":"2024-12-09T11:14:56.191665229Z","level":"info","msg":"scheduling loaded components and services"}
Dec 09 11:14:56  alloy[3236]: {"ts":"2024-12-09T11:14:56.193166388Z","level":"info","msg":"starting cluster node","service":"cluster","peers_count":0,"peers":"","advertise_addr":"<IP_ADDRESS>:12345"}
Dec 09 11:14:56  alloy[3236]: {"ts":"2024-12-09T11:14:56.193454126Z","level":"info","msg":"now listening for http traffic","service":"http","addr":"<IP_ADDRESS>:12345"}
Dec 09 11:14:56  alloy[3236]: {"ts":"2024-12-09T11:14:56.193559599Z","level":"info","msg":"peers changed","service":"cluster","peers_count":1,"peers":"ip-10-48-136-63"}
Dec 09 11:14:56  alloy[3236]: {"ts":"2024-12-09T11:14:56.193736531Z","level":"warn","msg":"Using the <IP_ADDRESS> address exposes this server to every network interface, which may facilitate Denial of Service attacks.","component_path":"/","component_id":"otelcol.receiver.otlp.default","documentation":"https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/security-best-practices.md#safeguards-against-denial-of-service-attacks"}
Dec 09 11:14:56  alloy[3236]: {"ts":"2024-12-09T11:14:56.193982476Z","level":"info","msg":"Starting GRPC server","component_path":"/","component_id":"otelcol.receiver.otlp.default","endpoint":"<IP_ADDRESS>:4317"}
Dec 09 11:14:56  alloy[3236]: {"ts":"2024-12-09T11:14:56.194131341Z","level":"warn","msg":"Using the <IP_ADDRESS> address exposes this server to every network interface, which may facilitate Denial of Service attacks.","component_path":"/","component_id":"otelcol.receiver.otlp.default","documentation":"https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/security-best-practices.md#safeguards-against-denial-of-service-attacks"}
Dec 09 11:14:56  alloy[3236]: {"ts":"2024-12-09T11:14:56.194315814Z","level":"info","msg":"Starting HTTP server","component_path":"/","component_id":"otelcol.receiver.otlp.default","endpoint":"<IP_ADDRESS>:4318"}
Dec 09 11:14:57  alloy[3236]: {"ts":"2024-12-09T11:14:57.196880935Z","level":"info","msg":"Done replaying WAL","component_path":"/","component_id":"prometheus.remote_write.default","subcomponent":"rw","remote_name":"73d8a3","url":"https://prometheus-us-central1.grafana.net/api/prom/push","duration":1011088250}
Dec 09 11:15:01  alloy[3236]: {"ts":"2024-12-09T11:15:01.26273779Z","level":"error","msg":"non-recoverable error","component_path":"/","component_id":"prometheus.remote_write.default","subcomponent":"rw","remote_name":"73d8a3","url":"https://prometheus-us-central1.grafana.net/api/prom/push","count":8,"exemplarCount":0,"err":"server returned HTTP status 401 Unauthorized: {\"status\":\"error\",\"error\":\"authentication error: invalid token\"}"}

Hi, the alloy syntax expects you to use the sys.env stdlib function to retrieve an environment variable's value. See the documentation here.

Thank you @dehaansa ,the suggestion helped!


Second Html

For My Movies page

Hi, can I contribute on this repository. I am participating in Hacktoberfest. I can do any task assigned by you.

We appreciate the offer, but this is for a class assignment.

Ok, Thanks for replying.


fix: fixed bug in Dependency.List()

A bug in Dependency.List() caused all compressed charts to flag their dependencies as "missing".
Also added tests, which probably should have been there all along.
Closes #4431
Signed-off-by: Matt Butcher<EMAIL_ADDRESS>

This is marked XXL due to test fixtures.  Merge away!

There were no test charts in that testdata package.

There were no test charts in that testdata package.

Good point. I was thinking of test dependency chart which I had forgotten now reside in cmd/helm/testdata/testcharts/! 😄   I am ok either way; just wanted to avoid loading similar files if we can avoid it.

My issue with re-using test data is that you tend to then unintentionally add dependencies on your tests. If Test A and Test B both use the same data, it is possible that a change you make on the data in order to alter a test on Test A will unintentionally alter Test B. If we start using the same test data across packages, it gets harder and harder to trace those test inter-dependencies. This, in my mind, defeats the purpose of isolating test cases in unit tests.
I will take a look, though, at reducing at least the number of files in this particular PR. I can probably cut a few.


Update brace module dependency

Describe the bug
There is a vulnerability with braces 3.0.2 that has been patched with 3.0.3. Please upgrade the dependency to resolve this vulnerability.
See more here.
Versions (please complete the following information):

Chokidar version 3.6.0
Node version N/A
OS version: N/A

@paulmillr I know you've decided to focus on v4, but simply by changing the brace dependency from 3.0.2 to 3.0.3 you would instantly fix security vulnerabilities for all current users of Mocha.
If you require a major upgrade, all the users of Mocha will need to wait for Mocha to do this upgrade, and all existing installations of Mocha will continue to have this vulnerability - so seems like the cost / reward ratio for putting out a quick security patch for chokidar is extremely high!


GM! New inscriptions file uploaded with traits! 🫶

It contains the updated traits data

original digit collection is only 2digits -> 0 to 99.
we will extend this collection if the twitter account @BitcoinDigits (given in existing json), indicates that the collection is extended in size as proposed here. otherwise we do not know if this is a legit request. thank you for your understanding.

Dear Chris!
I sent the message on twitter from the official Bitcoin Digits page to @ordinalswallet.
Hello, Peter

@MillHaus33 please resolve the conflicting files issue. (inscriptions.json too big to edit in github directly it seems)
the pull request by @petershepherd is legit, i have confirmation from the discord; and @ordinalswallet should have received a confirmation on Twitter from Bitcoin Digits, see comment above.

manually added. having issues with the attributes tho. need to figure it out


Do not run tests on files not included (?)

I may be doing something wrong, by in my project I have something like:
module MyPkg
    using TestItems
    include("somefile.jl")
end

Inside somefile.jl there are some tests defined by @testitem sets.
It seems that, if I comment the line that includes somefile.jl, the tests inside somefile.jl are stil checked up, and the tests break if there are syntax errors in that file.
Is this expected?

Yes, test items are detected syntactically, they can just appear in any file anywhere.


[Peek] FilePreviewer - Error InfoBar when previewer fails to render.

Is this implemented with the FailedPreview previewer?


the yaml file wouldn't work because it was missing on: push, after adding it the pipeline worked

[Enter feedback here]

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

ID: f471d22c-2c0a-0980-7a70-08674d54612f
Version Independent ID: 3620533b-c0ca-dfa5-419b-69041bbdb263
Content: Azure Spring Cloud CI/CD with GitHub Actions
Content Source: articles/spring-cloud/spring-cloud-howto-github-actions.md
Service: spring-cloud
GitHub Login: @MikeDodaro
Microsoft Alias: barbkess

@everythingeverywhere  Does anything need to be changed in the documentation?

@everythingeverywhere Thanks a lot for reporting this, fixing.

@yucwan Thanks for the response and enhancing the doc. 👍
@everythingeverywhere Closing this issue for now. If there are further questions regarding this matter or feedback on the documentation, please do let us know and we will gladly continue the discussion.


Challenge: Fibonacci

Dynamic programming
challenge: Fibonacci

Hi Eric.
Why you close this issue ? There were no Pull Request on this challenge


prefect_work_pool creation on Prefect Server

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
Please do not leave +1 or me too comments, they generate extra noise for issue followers and do not help prioritize the request.
If you are interested in working on this issue or have submitted a pull request, please leave a comment.

Terraform Version

Terraform v1.5.5
on darwin_arm64

Affected Resource(s)

prefect_work_pool

Terraform Configuration Files

terraform {
  required_version = "1.5.5"

  required_providers {
    prefect = {
      source  = "prefecthq/prefect"
      version = "0.0.0-alpha8"
    }
  }
}

provider "prefect" {
  endpoint = "https://<redacted>"
  api_key  = "<redacted>"
}

resource "prefect_work_pool" "default" {
  name              = "default"
  type              = "kubernetes"
  paused            = false
}

Debug Output

Planning failed. Terraform encountered an error while generating this plan.

╷
│ Warning: Prefect API Key
│
│   with provider["registry.terraform.io/prefecthq/prefect"],
│   on providers.tf line 66, in provider "prefect":
│   66: provider "prefect" {
│
│ The Prefect API Key is set, however, the Endpoint is set to a Prefect server installation. Potential resolutions: set the endpoint attribute or PREFECT_API_URL environment variable to a Prefect Cloud endpoint, unset the PREFECT_API_KEY environment variable, or remove the api_key attribute.
╵
╷
│ Error: Error creating work pool client
│
│   with prefect_work_pool.default,
│   on main.tf line 1, in resource "prefect_work_pool" "default":
│    1: resource "prefect_work_pool" "default" {
│
│ Could not create work pool client, unexpected error: both accountID and workspaceID must be set: accountID is "00000000-0000-0000-0000-000000000000" and workspaceID is "00000000-0000-0000-0000-000000000000". This is a bug in the provider, please report this to the maintainers.
╵
exit status 1

Panic Output

Expected Behavior

Be able to create a work pool on Prefect Server.
Actual Behavior

Since version v0.0.0-alpha8, it is no longer possible to create a work pool when we point the provider to a running Prefect Server.
We were particularly happy in my company to see the creation of a Terraform provider compatible with Prefect Server, allowing us to easily configure Prefect, but I am now wondering if you have the objective of continuing to support different targets.
Are these things something you don't want to support with this Terraform provider? Is it primarily designed with the Cloud version of Prefect as a target?
Additionally, as you can see in the TF sample code, we were pleased to see that it was possible to set a Bearer token via the api_key variable in the provider block allowing us to take advantage of the authentication in place on our infrastructure thanks to Authentik, resolving the authentification problem, Prefect not having one.
Is this also something you have in mind to allow the provider to be configured with custom authentication systems like Basic/Bearer token, or is it just some kind of allowed hack with the current implementation?
Steps to Reproduce

terraform apply

Important Factoids

References

#0000

hey @arthur-leclerc - thanks for raising this issue. when creating the provider initialization logic + validations, we had Cloud in mind when checking for the presence of an API Key; so we did not initially consider your use case of using a separate auth provider for a self-managed Server deployment.
That being said, as you've identified - we're simply passing this API Key to an http client, and we're open to lifting this validation check out of the provider to support your use case

hey @arthur-leclerc - i just pushed a fix for this and cut a release to the provider registry. when it finishes publishing, would you give this a try with https://github.com/PrefectHQ/terraform-provider-prefect/releases/tag/v0.1.1

It works perfectly, thank you!


Impolite service termination

In the finalizer for the plugin, the current termination logic is to first kill, then terminate the proc.  This approach means that a complex service that starts its own child services will stop but leave these other processes running.

nice catch!
let's fix of course


extending shoot spec with DNS & Cert extensions

Description
Changes proposed in this pull request:

extending shoot spec with DNS & Cert extensions

Related issue(s)
https://github.com/kyma-project/control-plane/issues/875

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

/test pre-main-control-plane-gke-integration

/test pre-main-control-plane-gke-integration

/test pre-main-control-plane-gke-integration

/retest


don't see interface status field in API GET: /dcim/interfaces/?id<interafce_id>

Environment

Nautobot version (Docker tag too if applicable): 1.5.10
Python version: 3.10.6
Database platform, version: 14.6
Middleware(s):

Steps to Reproduce

call the next API: http://<nautobot_ip>/api/dcim/interfaces/?id<interafce_id>

to see status field:
"status": {
"value": "active",
"label": "Active"
},

no status field in respon!

In 1.x the REST API defaults to version 1.2 if unspecified. Try adding ?api_version=1.5 to the query, or setting Accept: application/json; version=1.5 in your headers.
We're considering changing this default behavior in 2.0, see #2799.

with api_version=1.5 is working! but why? do I need to set API version every time in a request?

Because that field was added in a newer version (https://docs.nautobot.com/projects/core/en/stable/release-notes/version-1.4/?h=interface+status#status-field-on-interface-vminterface-models-984) but for backward compatibility, we don't change behavior/responses when you upgrade to a newer version. There's no way of knowing when you first integrated with Nautobot or the first version you installed.

one more question! is it possible to filter what fields to get in a response. for example, I am just interested in status and interface name fields.

This is the main advantage of GraphQL over REST. If the full response is unwanted you may want to check that out.

thx for the hint with GraphQL.


feat: create token bridge

todos:

[ ] don't hardcode gas limit for parent chain tx
[ ] add padding to retryable fees
[ ] custom gas token support

[ ] create util for approving the retryable fees to the token bridge creator
[ ] add integration test for custom gas token

[ ] create getTokenBridgeContracts function on CreateTokenBridgeTransactionReceipt that parses logs and returns contracts

[ ] try using the registry
[ ] add assertions related to getTokenBridgeContracts to existing token bridge integration tests

[ ] clean up abi

First update:

Cleaned up TokenBridge abi (and updated it to v1.2.0)
Added createRollupFetchCoreContracts and createTokenBridgeFetchTokenBridgeContracts
Renamed createTokenBridge to createTokenBridgePrepareTransactionRequest to follow the same convention as with createRollup (actually, why do we have createRollup.ts if it's not used anywhere?)
Added some extra integration tests for the token bridge addresses (need feedback, more in the next comment)


Fix version information

Current version information is missing, apparently the rebase had a funny. Either way, the old way was mangling Lua's identifiers. A separate field has been added for ident and we change appropriate references of LUA_COPYRIGHT (etc) to PLUTO_COPYRIGHT. Not modifying LUA_COPYRIGHT (etc) also removes an unnecessary conflict in a future rebase.

Ah, I seem to have missed that, yeah. I guess this approach should be more robust.


depends_on: build.head? seems evaluated in the opposite way

brew doctor output
Your system is ready to brew.

Verification

[X] My "brew doctor output" above says Your system is ready to brew. and am still able to reproduce my issue.
[X] I ran brew update twice and am still able to reproduce my issue.
[X] This issue's title and/or description do not reference a single formula e.g. brew install wget. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.

brew config output
HOMEBREW_VERSION: 4.4.1-28-g4d4f3a2
ORIGIN: https://github.com/Homebrew/brew
HEAD: 4d4f3a2344df1616d4d953c54763d1315d9e6175
Last commit: 2 hours ago
Core tap HEAD: 65bf3b8f5917bf0c1d76fc5e8bc8f2b2e4a418f1
Core tap last commit: 6 hours ago
Core tap JSON: 15 Oct 11:27 UTC
Core cask tap HEAD:<PHONE_NUMBER>f9c9a642a3706a20ca85a2b17ea546
Core cask tap last commit: 24 minutes ago
Core cask tap JSON: 15 Oct 11:27 UTC
HOMEBREW_PREFIX: /usr/local
HOMEBREW_CASK_OPTS: []
HOMEBREW_MAKE_JOBS: 8
HOMEBREW_SORBET_RUNTIME: set
Homebrew Ruby: 3.3.5 => /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/3.3.5/bin/ruby
CPU: octa-core 64-bit icelake
Clang: 16.0.0 build 1600
Git: 2.47.0 => /usr/local/bin/git
Curl: 8.7.1 => /usr/bin/curl
macOS: 15.0.1-x86_64
CLT: <IP_ADDRESS>.1.1724870825
Xcode: 16.

What were you trying to do (and why)?
I was trying to add the following change to https://github.com/Homebrew/homebrew-core/blob/65bf3b8f5917bf0c1d76fc5e8bc8f2b2e4a418f1/Formula/l/lima.rb
diff --git a/Formula/l/lima.rb b/Formula/l/lima.rb
index c4985057c5d..2d8d8e7daca 100644
--- a/Formula/l/lima.rb
+++ b/Formula/l/lima.rb
@@ -18,7 +18,7 @@ class Lima < Formula
   end

   depends_on "go" => :build
-  depends_on "qemu"
+  depends_on "qemu" if !build.head?

   def install
     if build.head?

Because the master branch of Lima no longer needs QEMU (on macOS hosts)
What happened (include all command output)?
The qemu dependency was being installed regardless to the if !build.head? condition.
$ brew install --build-from-source --HEAD --dry-run ./lima.rb
Error: Failed to load cask: ./lima.rb
Cask 'lima' is unreadable: wrong constant name #<Class:0x0000000132678c10>
Warning: Treating ./lima.rb as a formula.
==> Would install 1 formula:
lima
==> Would install 14 dependencies for lima:
capstone dtc python-packaging<EMAIL_ADDRESS>glib jpeg-turbo libpng libslirp libssh lzo pixman snappy vde qe

However, these dependencies were not being installed after flipping if !build.head? to if build.head?.
What did you expect to happen?
depends_on FORMULA if !build.head? shouldn't be installed for --HEAD
Step-by-step reproduction instructions (by running brew commands)
- Fetch https://github.com/Homebrew/homebrew-core/blob/65bf3b8f5917bf0c1d76fc5e8bc8f2b2e4a418f1/Formula/l/lima.rb
- Change `depends_on "qemu"` to `depends_on "qemu" if !build.head?`
- Run `brew install --build-from-source --HEAD --dry-run ./lima.rb`
- Check the `Would install %d dependencies for lima` output

Probably relevant:

https://github.com/Homebrew/brew/issues/10571

Using build.head? or build.stable? outside of the install method doesn't work. If you want to scope something only to stable or head, use a stable do or head do block.
Incidentally:

$ brew install --build-from-source --HEAD --dry-run ./lima.rb

I recommend against passing paths to brew install. It maybe mostly works, but there are lots of subtle bugs.


Convert Fixed Accordian from angular-patternfly

http://www.patternfly.org/angular-patternfly/#/api/patternfly.utils:pfFixedAccordion

I'ld like to try this one. I previously worked in porting accordion and fixed-accordion components to pf-webcomponents repo.

Go for it! It will be great to have you contribute this component.
Note that the existing accordion is a directive based on an older Bootstrap component library. I suspect we will likely reuse the accordion, based on Angular 4, from ngx-bootstrap below.
https://valor-software.com/ngx-bootstrap/#/accordion
Please take a look at the components that have been converted from Angular Patternfly already. The patternfly-ng components are not necessarily a straight port from Angular Patternfly as we've done quite a bit of refactoring -- everything is now typed; objects, events, etc. It's an opportunity to clean things up.
Note the similar architecture between components, configuration setup, and attribute names. Also note that we're no longer using function callbacks, as with Angular Patternfly -- we're generating events, instead. Doesn't look like the accordion has any, yet?
For testing AOT compilation, you will need to create a Anglular CLI app, import patternfly-ng, then run 'ng build --prod'. Typically, we try to mark methods private/protected, then open things up as needed for AOT.

@dlabrecq Since the accordion from ngx-bootstrap provides all the accordion functionality, fixed accordion seems as an additional option of the accordion.
Will the use of a directive, instead of a component be acceptable here?

Yes, using a directive is fine. We have one directive in patternfly-ng already.
Take a look at the remaining chars count directive. A directive makes sense here so the underlying text area is not hidden from the user.

Closing due to inactivity.


Is it possible to set the hashed value's length?

Can I set the hash value to always be 10 characters for example?

I am also looking for the same thing but I guess we can pad the result afterward.


Document sidecar health indicators

Document additional health indicators targeted for the next release.

does next here mean the september release?

does next here mean the september release?

Wait, we wanted to make changes first.

does next here mean the september release?

Wait, we wanted to make changes first.

Alright, thank you for confirming.

does next here mean the september release?

The feature is already merged and should be delivered in next release.


react-native-checkbox-reanimated is breaking in reanimated3 - ReanimatedError: Exception in HostFunction: java.lang.ClassCastException

The package was working fine when our app was using reanimated2, when I upgraded to reanimated 3 it started breaking
Here is the error am getting
ReanimatedError: Exception in HostFunction: java.lang.ClassCastException: java.lang.Double cannot be cast to com.facebook.react.bridge.ReadableMap, js engine: reanimated

Hi, I have this problem as well. I don't think its reanimated's problem because I had it working with "react-native-reanimated": "^3.12.1" and "react-native-svg": "^12.1.0".
Once I updated react-native-svg to 15.4.0, it started raising error.


Update Python packages and pre-commit hooks

Automatic PR from repo-maintenance -> package_updates

Wonder what is getting sent as text:


Allow easy way to get Sqlite3 version

In working with better-sqlite3 we wanted to check the exact version of sqlite3 being used to ensure a feature was available or throw an error. There does not appear to be any way to get the sqlite3 version out of better-sqlite3 right now.
Suggestion of something like:
console.log(db.sqlite3Version)
// 3.44.2

https://github.com/WiseLibs/better-sqlite3/issues/1021

Thanks @Prinzhorn, I've opened a PR which addresses both this and #1124:

https://github.com/WiseLibs/better-sqlite3/pull/1124

fwiw, the build-in sqlite_version() function will return this value:
const bs = require("better-sqlite3");

function sqliteVersion() {
  let db;
  try {
    db = new bs(":memory:");
    return db.prepare("select sqlite_version()").pluck().get();
  } finally {
    db?.close();
  }
}

console.log(sqliteVersion());

Emits 3.44.2

fwiw, the build-in sqlite_version() function will return this value:
const bs = require("better-sqlite3");

function sqliteVersion() {
  let db;
  try {
    db = new bs(":memory:");
    return db.prepare("select sqlite_version()").pluck().get();
  } finally {
    db?.close();
  }
}

console.log(sqliteVersion());

Emits 3.44.2


integration_tests: Deploy also succeeds when the pods were not modified

The integration test wants to make sure that the newest gadget version is deployed to the nodes. For that it tested the output via regex for ready pods \d\/\d gadget pod\(s\) ready.
When the gadget is deployed earlier and no deployment is needed the following output is generated: The gadget pod(s) weren't modified!.
This PR adds that possibility to the regex.
Before this change:
Creating ClusterRoleBinding/gadget-cluster-role-binding...
Creating DaemonSet/gadget...
The gadget pod(s) weren't modified!

invalid command output(DeployInspektorGadget): output didn't match the expected regexp: \d\/\d gadget pod\(s\) ready
+ kubectl get pods -n gadget -o wide
NAME           READY   STATUS    RESTARTS   AGE   IP             NODE       NOMINATED NODE   READINESS GATES
gadget-85k46   1/1     Running   0          19s   <IP_ADDRESS>   minikube   <none>           <none>
.............
FAIL

IMO, that check aims to prevent users from using an already running IG by mistake. If you are aware of the already running IG and want to use it, then you should use that -no-deploy-ig flag.

Therefore, I think we should not introduce the change Burak is proposing.


Update to 1.0.8

Hi!
Are there any plans on updating this layer to version 1.0.8? I tried doing this myself and wanted to open a pull request but I encountered several issues:

The download for the .tar.gz of version 1.0.8 does not exist: https://github.com/Azure/azure-iotedge/releases/download/1.0.8/iotedge-1.0.8.tar.gz Which got me wondering why there is a separate repository containing releases for iotedge? Is it because 1.0.8 is not GA at the moment?
Using the tagged commit from the upstream branch release/1.0.8 does not work for some reason. Yocto claims that the commit in this branch does not exist, though it is available. Even specifying the master branch with the commit ID (https://github.com/Azure/iotedge/commit/f5186c42ebb721893c5a497c789236803de42fb7 or https://github.com/Azure/iotedge/commit/208b2204fd30e856d00b280112422130c104b9f0) does not work.

Can you provide any information on this?

Hi, when will this layer be updated to 1.0.8 - I've seen that 1.0.9-rc1 has been released, will 1.0.8 be skipped for meta-iotedge?
There are also Yocto build issues with version 1.0.7 and the current rust/cargo versions in the master branch of meta-rust.

Thank you!

Hi, thanks for pushing the update!
I tried building the new version for sumo, but unfortunately I'm having issues during compilation:
[ 69%] Built target hsm_client_tpm_ut_exe
Makefile:162: recipe for target 'all' failed

--- stderr
CMake Warning:
  Manually-specified variables were not used by the project:

    use_emulator

/nStack/devLicense/share/yocto/build/tmp/work/cortexa7hf-neon-poky-linux-gnueabi/iotedge-cli/1.0.8-r0/recipe-sysroot-native/usr/lib/libssl.so: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
make[2]: *** [libiothsm.so.1.0.8] Error 1
make[1]: *** [CMakeFiles/iothsm.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [all] Error 2
thread 'main' panicked at '
command did not execute successfully, got: exit code: 2

The full compile log file is attached: log.do_compile.zip
Could you please have a look?
Thanks,
Wolfgang

Can confirm that sumo does not build, but thud does.

Are you on the sumo branch`?

I'm on the most recent sumo branches:
Build Configuration:
BB_VERSION           = "1.38.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "universal"
TARGET_SYS           = "arm-poky-linux-gnueabi"
...
TUNE_FEATURES        = "arm armv7ve vfp thumb neon callconvention-hard cortexa7"
TARGET_FPU           = "hard"
meta
meta-poky            = "sumo:5ddf7fff992b065ee512878d2fe65f3e35d818cf"
meta-oe              = "sumo:8760facba1bceb299b3613b8955621ddaa3d4c3f"
...
meta-virtualization  = "sumo:ed2038c935777d1336c17989d454f4e9c95fea7f"
meta-rust            = "master:11aed43748d7dd194dc6c06a35a16104400d1090"
meta-iotedge         = "sumo:734dc718da4fe3ac39b6049f543223698897433f"

I get the same error:
ksaye@el1000:~/rpi$ bitbake core-image-base
Build Configuration:
BB_VERSION           = "1.38.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "universal"
TARGET_SYS           = "aarch64-poky-linux"
MACHINE              = "raspberrypi3-64"
DISTRO               = "poky"
DISTRO_VERSION       = "2.5.3"
TUNE_FEATURES        = "aarch64"
TARGET_FPU           = ""
meta
meta-poky
meta-yocto-bsp       = "sumo:5ddf7fff992b065ee512878d2fe65f3e35d818cf"
meta-oe
meta-networking
meta-python
meta-filesystems     = "sumo:8760facba1bceb299b3613b8955621ddaa3d4c3f"
meta-raspberrypi     = "sumo:2d40b000021bc8a9ef7f329ed0ad410f8d227b97"
meta-iotedge         = "sumo:734dc718da4fe3ac39b6049f543223698897433f"
meta-rust            = "HEAD:9487b089ea4779c2b494b17b9254219226efa539"
meta-virtualization  = "sumo:ed2038c935777d1336c17989d454f4e9c95fea7f"
I get the error shown below:
| [ 64%] Linking C shared library libiothsm.so
| CMakeFiles/iothsm.dir/build.make:543: recipe for target 'libiothsm.so.1.0.8' failed
| CMakeFiles/Makefile2:68: recipe for target 'CMakeFiles/iothsm.dir/all' failed
| [ 65%] Linking C executable edge_openssl_enc_ut_exe
| [ 65%] Built target edge_openssl_enc_ut_exe
| [ 66%] Linking C executable edge_hsm_key_intf_sas_ut_exe
| [ 66%] Built target edge_hsm_key_intf_sas_ut_exe
| [ 66%] Linking C executable edge_hsm_tpm_ut_exe
| [ 66%] Built target edge_hsm_tpm_ut_exe
| [ 66%] Linking C executable edge_hsm_crypto_ut_exe
| [ 66%] Built target edge_hsm_crypto_ut_exe
| [ 67%] Linking C executable edge_hsm_x509_ut_exe
| [ 67%] Built target edge_hsm_x509_ut_exe
| [ 68%] Linking C executable edge_openssl_pki_ut_exe
| [ 68%] Built target edge_openssl_pki_ut_exe
| [ 69%] Linking C executable hsm_client_tpm_ut_exe
| [ 69%] Built target hsm_client_tpm_ut_exe
| Makefile:162: recipe for target 'all' failed
|
| --- stderr
| fatal: not a git repository (or any of the parent directories): .git
| CMake Warning:
|   Manually-specified variables were not used by the project:
|
|     use_emulator
|
|
| /home/ksaye/rpi/rpi-build/tmp/work/aarch64-poky-linux/iotedge-cli/1.0.8-r0/recipe-sysroot-native/usr/lib/libssl.so: error adding symbols: File in wrong format
| collect2: error: ld returned 1 exit status
| make[2]: *** [libiothsm.so.1.0.8] Error 1
| make[1]: *** [CMakeFiles/iothsm.dir/all] Error 2
| make[1]: *** Waiting for unfinished jobs....
| make: *** [all] Error 2
| thread 'main' panicked at '
| command did not execute successfully, got: exit code: 2
Looking in the 'rpi-build/tmp/work/aarch64-poky-linux/iotedge-cli/1.0.8-r0/recipe-sysroot-native/usr/lib' I do not see libssl.so.1.0.8, which I guess is the problem.
ksaye@el1000:~/rpi/rpi-build/tmp/work/aarch64-poky-linux/iotedge-cli/1.0.8-r0/recipe-sysroot-native/usr/lib$ ls -all libssl*.*
-rw-r--r-- 440 ksaye ksaye 730666 Feb  3  2019 libssl.a
lrwxrwxrwx   1 ksaye ksaye     15 Oct 25 18:45 libssl.so -> libssl.so.1.0.2
-rwxr-xr-x 440 ksaye ksaye 437408 Feb  3  2019 libssl.so.1.0.2
ksaye@el1000:~/rpi/rpi-build/tmp/work/aarch64-poky-linux/iotedge-cli/1.0.8-r0/recipe-sysroot-native/usr/lib$

Did anyone solve this? I tried to add 1.0.9 RC3 in my own meta-layer for now but I run into the same error. Has to be an issue with libssl10 vs libssl or something

iotedge-cli does not have the necessary OpenSSL  dirs specified to staging dir
https://github.com/Azure/meta-iotedge/blob/sumo/recipes-core/iotedge-cli/iotedge-cli.inc
Needs:
export OPENSSL_DIR = "${STAGING_EXECPREFIXDIR}"
export OpenSSLDir = "${STAGING_EXECPREFIXDIR}"
export OPENSSL_ROOT_DIR = "${STAGING_EXECPREFIXDIR}"

I can confirm that build for Yocto Sumo is fixed by #35

I am facing same issue while building a yocto image for raspberry pi Model B. I am referring this link for the build "https://kevinsaye.wordpress.com/2019/06/21/how-to-build-a-yocto-image-for-the-raspberry-pi-running-azure-iot-edge/"  .
Have cloned meta-iotedge sumo branch and got the below error
/home/YoctoLinux/rpi/rpi-build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/iotedge-cli/1.0.8-r0/recipe-sysroot-native/usr/lib/libssl.so: file not recognized: File format not recognized
| collect2: error: ld returned 1 exit status
| make[2]: *** [libiothsm.so.1.0.8] Error 1
| make[1]: *** [CMakeFiles/iothsm.dir/all] Error 2
| make[1]: *** Waiting for unfinished jobs....
| make: *** [all] Error 2
| thread 'main' panicked at '
| command did not execute successfully, got: exit code: 2
|
| build script failed, must exit now', /home/YoctoLinux/rpi/rpi-build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/iotedge-cli/1.0.8-r0/cargo_home/bitbake/cmake-0.1.30/src/lib.rs:643:5
Please give inputs to solve the issue

I have updated the file < https://github.com/Azure/meta-iotedge/blob/sumo/recipes-core/iotedge-cli/iotedge-cli.inc>
export OPENSSL_DIR = "${STAGING_EXECPREFIXDIR}"
export OpenSSLDir = "${STAGING_EXECPREFIXDIR}"
export OPENSSL_ROOT_DIR = "${STAGING_EXECPREFIXDIR}"
and perhaps export LIBIOTHSM_NOBUILD="On"
But not resolving issue. Please let me know if any solution available

Hi all,
I have also the same issue when compiling the tool tpm_device_provision of the azure-iot-sdk-c in Yocto.
I tried to add the following lines to the recipe without any success
DEPENDS += "openssl virtual/libiothsm"
RDEPENDS_${PN} += "virtual/libiothsm"
export OPENSSL_DIR = "${STAGING_EXECPREFIXDIR}"
export LIBIOTHSM_NOBUILD="On"
INHIBIT_PACKAGE_STRIP = "1"
The last line comes from this post.
I'm using the branch "dunfell".
I've spent over a week on this issue and I'm desesperately interesting in any clue to solve it ;)
Have a nice WE

After an ultimate try, my recipe managed to compile.
The settings are the following
DEPENDS += "openssl"

export OPENSSL_DIR = "${STAGING_EXECPREFIXDIR}"
export OpenSSLDir = "${STAGING_EXECPREFIXDIR}"
export OPENSSL_ROOT_DIR = "${STAGING_EXECPREFIXDIR}"
export LIBIOTHSM_NOBUILD="On"

Have a nice WE

Cool, thanks for the update, @XIIIVI!  Closing


Rsp

Exclude royalsocietypublishing from the linkcheck
This leads at the moment to a 403

Merging to fix latest-ci


Feature: importOrderMergeDuplicateImports

This PR implements import declaration merging for duplicate imports.

I had to adjust getCodeFromAST so that we could still provide the original nodes, even if some of the nodes were being deleted.
It leverages the existing chunking logic, so if there's a side-effect import, or a prettier-ignore import, it won't merge across that boundary.
I did not implement conversion of import type { stuff } into import { type stuff } as it was not obvious when this would be wise. If we want to control that with an additional config option, something like importOrderMergeTypeStyle: "none" | "to-normal-import" | "unmerge" I could be convinced. I forsee people wanting opposite sides of the coin for that one.

Please let me know what you think and if there's any edge-cases I missed!

@IanVS PR Feedback applied to this and #20 -- happy to do another round when you get another chance to look.


Should dependency overrides be a runtime exception?

I had the following code
import org.koin.dsl.module.applicationContext
import org.koin.standalone.KoinComponent
import org.koin.standalone.StandAloneContext.startKoin
import org.koin.standalone.inject

typealias StringProvider = () -> String
typealias IntProvider = () -> Int

class Example(private val stringProvider: StringProvider,
              private val intProvider: IntProvider) {

    fun run() {
        // Output is:
        //   1337
        //   1337
        // Output should be:
        //   Hello world
        //   1337
        println(stringProvider())
        println(intProvider())
    }
}

object Main : KoinComponent {

    private val example: Example by inject()

    fun run() {
        example.run()
    }
}

fun createModule(stringProvider: StringProvider,
                 intProvider: IntProvider) = applicationContext {

    factory { stringProvider }

    factory { intProvider }

    factory { Example(get(), get()) }
}

fun main(args: Array<String>) {
    startKoin(listOf(createModule(stringProvider = { "Hello world" },
                                  intProvider = { 1337 })))
    Main.run()
}

and first was wondering why the output is
1337
1337

instead of
Hello world
1337

Since the function types in this example resolve to kotlin.jvm.functions.Function0<R> and the generic type is lost during runtime due to JVM's type erasure I'm aware that the solution to this problem is
factory("stringProvider") { stringProvider }

factory("intProvider") { intProvider }

factory { Example(get("stringProvider"), get("intProvider")) }

However before the first factory was "silently" overridden by the second factory because both resolve to Function0 (yes I know, the override is logged to console).
I suggest that Koin should have an option ("strict mode"?) that turns overrides into runtime exceptions so that all types must be either unique or have names. This should help in reducing unexpected behaviour.

Hi,
Yeah, we should prevent any accidental bean override. By default, we could be in a "strict mode" rejecting any override. We could indicate in a Koin module that we will override existing definitions with new ones.
Below, we couldn't override mainModule with noOverrideModule, but we could override it with moduleOverride
val mainModule = applicationContext {
  bean { MyComponent() }
}

val noOverrideModule = applicationContext {
  // will throw an exception
  bean { MyNewComponent() as  MyComponent }
}

// Allowed override module
val moduleOverride = applicationContext(override = true) {
  bean { MyNewComponent() as  MyComponent }
}

Sounds reasonable. I now have a use case where I actually require an override. But maybe the option should be on the bean() and factory() definition and not on the context? Maybe I just want to override specific beans? Or maybe support both? On the context to override everything or on the definitions to only override these?

Yep, that's what I had also in mind ... could be possible to specify it at definition or module level

@arnaudgiuliani Please see attached my try at this functionality. I've also added the necessary tests to OverrideTest.
However there is one issue with the last test: I thought that when a context is released the bean definitions of this context are also removed. However only the instances are dropped and the definitions are still kept in BeanRegistry. So when you reload a module with a sub context where an override is not explicitly allowed after the context has been released, you will still receive the BeanOverrideException. I'm not sure if this is a desired behaviour or not.
Also the override flag is false by default. Just to be clear: This might break a lot of applications that implicitly used overrides before!

Hello @svenjacobs, the call of StandAloneContext.releaseContext() only drop instances from InstanceFactory.

So when you reload a module with a sub context where an override is not explicitly allowed after the context has been released, you will still receive the BeanOverrideException. I'm not sure if this is a desired behaviour or not.

Sorry, I don't understand. Why reload modules?

Sorry, I don't understand. Why reload modules?

Imagine an Android environment. I want to provide the current Context via a module. So I have something like
fun createAndroidModule(private val context: Context) = applicationContext {
  context("ANDROID") {
    bean { context }
  }
}

This module is created and loaded in onCreate() of the Activity. The Koin context is released in onDestroy() so that nothing leaks. Now a second Activity should be able to "reload" this module (reinstalling it) with the new Android Context.

available in koin 1.0.0-alpha-18

Just curious, why did you rewrite this feature?

rewrite the feature? The override was not explicit and could be done without wanting it.
Koi container will detect if you allowed overriding for your definition.


Why my formValue is not a string type

❓Question
Hi ,
I'm not sure it's a bug so that's why I'm posting it as a question.
I got this following typescript error for:

Here is my code:
interface FormValues {
    birthdate: Date;
}

const BirthdateForm = (): ReactElement => {
    const maxBirthdate = moment().subtract(6, 'y').toDate();

    const minBirthdate = moment().subtract(100, 'y').toDate();

    return (
            <Formik
                initialValues={{ birthdate: undefined }}
                validationSchema={yup.object().shape({
                    birthdate: yup.date().min(minBirthdate).max(maxBirthdate).required(),
                })}
                onSubmit={(values): void => {
                      console.log(values);
                }}>
                {({
                    handleSubmit,
                    setFieldTouched,
                    initialValues,
                    values,
                    touched,
                    errors,
                    setFieldValue,
                    isSubmitting,
                    isValidating,
                    isValid,
                }: FormikProps<FormValues>): ReactElement => {
                console.log(typeof errors.birthdate); // string
                return (
                    <>
                        <DatePicker
                           // error msg is pass to a react-native-element input in DatePicker.tsx
                            errorMessage={touched.birthdate ? errors.birthdate : undefined}
                            date={values.birthdate}
                            onBlur={(): void => { setFieldTouched('birthdate'); }}
                            onDateChange={(newDate: Date): void => {
                                setFieldValue('birthdate', newDate);
                            }}
                            maxDate={maxBirthdate}
                            minDate={minBirthdate} />
                        <Button
                            disabled={
                                values === initialValues
                                || isSubmitting
                                || isValidating
                                || !isValid
                            }
                            loading={isSubmitting || isValidating}
                            onPress={handleSubmit}
                            containerStyle={styles.buttonContainer}
                            title='Continue'  />
                    </>)
                }}
            </Formik>
    );
};

In types.ts from formik, I can see this following code, what I understand is that if the error is not an object the error should be a string. I understand it like a recursive typing who makes sense.
So what I can not understand is why my error is not considered as a string.
export declare type FormikErrors<Values> = {
    [K in keyof Values]?: Values[K] extends object ? FormikErrors<Values[K]> : string;
};

Thank you guys!!

@mi-mazouz were you able to resolve this issue? I'm running in the same thing

@mi-mazouz were you able to resolve this issue? I'm running in the same thing

@graemec23 it's a bit hard to tell, but I'd guess that because his initialValues is: initialValues={{ birthdate: undefined }}, TypeScript isn't inferring a specific type to initialValues, which isn't passing an inferred type to <Formik />. If you put something else like birthdate: ''for initialValues, it should infer a type, or you can just pass your shape to<Formik />`.

@graemec23 it's a bit hard to tell, but I'd guess that because his initialValues is: initialValues={{ birthdate: undefined }}, TypeScript isn't inferring a specific type to initialValues, which isn't passing an inferred type to <Formik />. If you put something else like birthdate: ''for initialValues, it should infer a type, or you can just pass your shape to<Formik />`.


TempData values not working correctly

Sometimes when going back to a page, the last message is still there and it is confusing.

Need to figure out where the issue occurs and then see if it's fixed.


python312Packages.scmrepo: 3.3.5 -> 3.3.6

Diff: https://github.com/iterative/scmrepo/compare/refs/tags/3.3.5...3.3.6
Changelog: https://github.com/iterative/scmrepo/releases/tag/3.3.6
Description of changes

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.11 Release Notes (or backporting 23.11 and 24.05 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.

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

26 packages built:

dvc (python312Packages.dvc)
dvc-with-remotes
dvc-with-remotes.dist
dvc.dist (python312Packages.dvc.dist)
python311Packages.dvc
python311Packages.dvc-gdrive
python311Packages.dvc-gdrive.dist
python311Packages.dvc-hdfs
python311Packages.dvc-hdfs.dist
python311Packages.dvc.dist
python311Packages.dvclive
python311Packages.dvclive.dist
python311Packages.gto
python311Packages.gto.dist
python311Packages.scmrepo
python311Packages.scmrepo.dist
python312Packages.dvc-gdrive
python312Packages.dvc-gdrive.dist
python312Packages.dvc-hdfs
python312Packages.dvc-hdfs.dist
python312Packages.dvclive
python312Packages.dvclive.dist
python312Packages.gto
python312Packages.gto.dist
python312Packages.scmrepo
python312Packages.scmrepo.dist


Allow ray 2.7

Issue #, if available: https://github.com/autogluon/autogluon/issues/2687#issuecomment-1774497625
Description of changes: Allow ray 2.7 which includes critical fixes for py 3.11
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Hi @AnirudhDagar 👋 glad to hear you're already digging in! I hope they start being a bit stricter about their semantic versioning when 3.0 comes out 😅 they're doing quite some work to converge to a more stable API, e.g. https://github.com/ray-project/ray/commit/f22259bbd676a9e433c5ef0887c2a5a32887cfef was also shipped in ray 2.7

@ddelange After some more digging in and reproducing the error in a small self contained code snippet, I raised https://github.com/ray-project/ray/issues/41562, which might help us solve the issue. The ray deprecation warning about checkpoint_dir that causes the CI failure is raised incorrectly imo, which means, if right, this would take an upstream fix before we could update the versions here. And after that we will need to update the signature of hpo_trial and implement the new way to pass checkpoint_dir via ray (which is already mentioned in their dep warning).
https://github.com/autogluon/autogluon/blob/75c193ce7cc4c8ac2ddd26c1c1789a63bdba24d4/multimodal/src/autogluon/multimodal/utils/hpo.py#L32
I'll do this after the issue has been verified on the ray side. Will keep you posted, thanks for your patience!

@AnirudhDagar how about autogluon code temporarily ignores the warning with reference to that issue?

Thanks for the suggestion @ddelange. I'd be comfortable ignoring deprecation warnings for tests, only after someone at ray can validate the issue and if we can expect a fix for the same soon. Otherwise we end up bumping the dependency and testing autogluon with the latest version of ray, then all tests pass, but in reality at release time the users will run into a deprecation warning which they did not cause. This is not what we want for user experience.

if I understood his reply correctly, this specific DeprecationWarning can be safely ignored in this case, also in runtime, and will even be removed in a future ray version :+1:

Hi @ddelange sorry for the delayed response, I was vacationing. Yes you are right, with the latest info shared by ray team, that the warning will be removed in 2.10 anyway, we can add support for all the versions by temporarily suppressing those warnings. And as a TODO just add a note in the code, that we need to remove the warning suppression code later.

welcome back! do you feel like hijacking my PR?

No worries, if you're busy with other things, I can help support your PR with the rest of the required changes. Let me know, thanks!

added warning filter using the message kwarg to regex for checkpoint_dir ref https://docs.python.org/3/library/warnings.html#describing-warning-filters

Hi @AnirudhDagar :wave: can you run CI with elevated permissions?

===End Flaky Test Report=== in https://github.com/autogluon/autogluon/actions/runs/7612795659/job/20731334764?pr=3774#step:4:3062
is it indeed flaley, or can you spot a ray related error?

No this is again an issue with ray. The problem lies im the way the warning is raised as an exception and not using warnins.warn
You can try the following, even after adding a warning ignore filter, the deprecation warning will still come up as it's an Exception. Sharing a MRE below. pip install ray==2.9.1 before running the snippet below in ipython.
import warnings
from ray import tune

# try ignoring all DeprecationWarnings
warnings.simplefilter("ignore", category=DeprecationWarning)

trainable_kwargs = {'kwarg1': 1, 'kwarg2': 2}
def train_fn(config, **trainable_kwargs):
    pass

# Create the tuner without seeing the DeprecationWarning
tuner = tune.Tuner(tune.with_parameters(train_fn, **trainable_kwargs))

https://github.com/ray-project/ray/pull/42698 and https://github.com/ray-project/ray/pull/42698 (cc @suzhoum) will be released in ray 2.10.0
especially the first one is a blocking issue in all previous ray versions (autogluon wont function with them).
shall I bump the minimum ray version to 2.10 in this PR after ray releases it?

@AnirudhDagar @ddelange Looks like Ray 2.10 just released: https://github.com/ray-project/ray/releases/tag/ray-2.10.0

yes, i just saw. @ddelange can you please try updating this PR, then we can see the CI for the ray tests?

everyone so fast haha

Previous CI Run
Current CI Run

botocore==1.34.67
botocore==1.34.68

boto3==1.34.67
boto3==1.34.68

ruff==0.3.3
ruff==0.3.4

botocore==1.34.67
botocore==1.34.68

boto3==1.34.67
boto3==1.34.68

ruff==0.3.3
ruff==0.3.4

I went ahead and did some diving into the failing test cases here, as expected some of the internal dev functions which we used have been hard deprecated between the ray versions of 2.7 and 2.10, as explained specifically in this google doc https://docs.google.com/document/d/1J-09US8cXc-tpl2A1BpOrlHLTEDMdIJp6Ah1ifBUw7Y/view#heading=h.xi4qh6ve48tm
All these functions are no longer within the tune namespace and have been moved under train.get_context().
tune.get_trial_dir
tune.get_trial_id
tune.get_trial_resources

This will need some more refactoring inside the hpo utils file for multimodal. I'll share more updates, as soon as i'm able to fix the issue with the new api.

Previous CI Run
Current CI Run

google-api-core==2.17.1
google-api-core==2.18.0

google-api-core==2.17.1
google-api-core==2.18.0

-
proto-plus==1.23.0

looks like timeseries is affected by the same deprecations:
[2024-03-22T09:35:00.613Z]   File "/home/ci/autogluon/timeseries/src/autogluon/timeseries/models/abstract/model_trial.py", line 29, in model_trial
[2024-03-22T09:35:00.613Z]     model = init_model(
[2024-03-22T09:35:00.613Z]   File "/home/ci/autogluon/core/src/autogluon/core/models/abstract/model_trial.py", line 65, in init_model
[2024-03-22T09:35:00.613Z]     task_id = tune.get_trial_id()
[2024-03-22T09:35:00.613Z] AttributeError: module 'ray.tune' has no attribute 'get_trial_id'

Previous CI Run
Current CI Run

Previous CI Run
Current CI Run

That alone won't fix the issues, get_trial_checkpoints_paths has also been removed in 2.10 and I was experimenting changing the following:
https://github.com/autogluon/autogluon/blob/31bd35e82e230377e6d7e3a5b3bf1b6040fc14f2/multimodal/src/autogluon/multimodal/utils/hpo.py#L216-L219
to:
        checkpoints_paths_and_scores = {}
        best_trial_checkpoints = tune.ResultGrid(analysis).get_best_result().best_checkpoints
        for checkpoint in best_trial_checkpoints:
            checkpoint_path = checkpoint[0].path
            score = checkpoint[1][metric]
            checkpoints_paths_and_scores[checkpoint_path] = score

but this doesn't work, for some reason the trials are not saved or the path is incorrect. We need to find a replacement for the above.

Quick update: I might have figured out the issue locally (atleast the tests are passing now locally). Seems like ray is now saving the checkpoints under /Users/<username>/ray_results/.... And autogluon tries to specify its own working directory which is conflicting.

Previous CI Run
Current CI Run

@ddelange Hopefully my latest commits will fix the failing tests. Turns out ray silently also deprecated local_dir arg in https://github.com/ray-project/ray/pull/33463 at https://github.com/ray-project/ray/blob/master/python/ray/air/config.py#L656-L657 and replaced it with storage_dir. We were still using the local_dir arg which wasn't cutting it, and ray was falling back to its default save path ~/ray_results.
Note that we are using a private method _get_trial_checkpoints_with_metric to get the best trial checkpoint paths and metrics, which we could probably improve/change later (since ray is notoriously deprecating and breaking APIs with releases).

awesome finds! the beakages are a pain.. hope the API will converge after their next major release!

@Innixma it would be great if we could get this in for v1.1 release somehow. I'll wait for the reviews, since it touches core, timeseries and multimodal.

should also unblock https://github.com/autogluon/autogluon/issues/3920 (cc @suzhoum)

Here are the platform tests for this: https://github.com/autogluon/autogluon/actions/runs/8528660434

Thanks all, especially @ddelange for pushing this PR constantly for a long time. 🙌🏼

I think tests missed a deprecation somehow:
Warning: Exception caused NeuralNetTorch_BAG_L1 to fail during hyperparameter tuning... Skipping this model.
Traceback (most recent call last):
  File "/usr/share/python3/app/lib/python3.11/site-packages/autogluon/core/trainer/abstract_trainer.py", line 2159, in _train_single_full
    hpo_models, hpo_results = model.hyperparameter_tune(
                              ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/share/python3/app/lib/python3.11/site-packages/autogluon/core/models/abstract/abstract_model.py", line 1474, in hyperparameter_tune
    return self._hyperparameter_tune(hpo_executor=hpo_executor, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/share/python3/app/lib/python3.11/site-packages/autogluon/core/models/ensemble/stacker_ensemble_model.py", line 184, in _hyperparameter_tune
    return super()._hyperparameter_tune(X=X, y=y, k_fold=k_fold, hpo_executor=hpo_executor, preprocess_kwargs=preprocess_kwargs, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/share/python3/app/lib/python3.11/site-packages/autogluon/core/models/ensemble/bagged_ensemble_model.py", line 1384, in _hyperparameter_tune
    hpo_executor.execute(
  File "/usr/share/python3/app/lib/python3.11/site-packages/autogluon/core/hpo/executors.py", line 408, in execute
    analysis = run(
               ^^^^
  File "/usr/share/python3/app/lib/python3.11/site-packages/autogluon/core/hpo/ray_hpo.py", line 276, in run
    results = tuner.fit()
              ^^^^^^^^^^^
  File "/usr/share/python3/app/lib/python3.11/site-packages/ray/tune/tuner.py", line 379, in fit
    return self._local_tuner.fit()
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/share/python3/app/lib/python3.11/site-packages/ray/tune/impl/tuner_internal.py", line 477, in fit
    analysis = self._fit_internal(trainable, param_space)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/share/python3/app/lib/python3.11/site-packages/ray/tune/impl/tuner_internal.py", line 596, in _fit_internal
    analysis = run(
               ^^^^
  File "/usr/share/python3/app/lib/python3.11/site-packages/ray/tune/tune.py", line 701, in run
    raise DeprecationWarning(
DeprecationWarning: ('`chdir_to_trial_dir` is deprecated. Use the RAY_CHDIR_TO_TRIAL_DIR environment variable instead. Set it to 0 to disable the default behavior of changing the working directory.', <class 'DeprecationWarning'>)
('`chdir_to_trial_dir` is deprecated. Use the RAY_CHDIR_TO_TRIAL_DIR environment variable instead. Set it to 0 to disable the default behavior of changing the working directory.', <class 'DeprecationWarning'>)

@ddelange could you share a MRE for the above error/warning? I'm curious if this deprecation warning results in an error (like a hard deprecation warning which is raised) or is just a dep warning spit out and logged in the console during hparam tuning? In either case we'd have to fix it, but the latter might be easier.

like a hard deprecation warning which is raised

they raise it and so it short-circuits the training when installing from latest master (and thus installing ray 2.10.0)

@ddelange can you share the reproduction script, that would be really helpful? Thanks!

I'll try to find the time!

here you go (notably with hyperparameter_tune_kwargs='auto'):
# install current latest commit on master
# pip install -U 'autogluon.core @ https://github.com/autogluon/autogluon/archive/refs/heads/a48be1cda74479761161354ec7b360f9eeb7314f.zip#subdirectory=core' 'autogluon.common @ https://github.com/autogluon/autogluon/archive/refs/heads/a48be1cda74479761161354ec7b360f9eeb7314f.zip#subdirectory=common' 'autogluon.features @ https://github.com/autogluon/autogluon/archive/refs/heads/a48be1cda74479761161354ec7b360f9eeb7314f.zip#subdirectory=features' 'autogluon.tabular[tests,fastai] @ https://github.com/autogluon/autogluon/archive/refs/heads/a48be1cda74479761161354ec7b360f9eeb7314f.zip#subdirectory=tabular'

from autogluon.tabular import TabularPredictor
import pandas as pd

df = pd.DataFrame(np.random.randint(0, 2, size=(100, 100)))
df.columns = [str(col) for col in df.columns]

TabularPredictor(
    verbosity=3,
    label='0',
    path='/tmp/ag',
).fit(
    df,
    time_limit=100,
    hyperparameters={"NN_TORCH": {}},
    hyperparameter_tune_kwargs='auto',
)

Thanks @ddelange, I spent some time playing around and diving deep into the error, I can confirm the issue. This is indeed a major bug, I'll open a new issue to track it and send a fix ASAP.
Thanks again for smoking the ray upgrade, your contributions are really valuable!


Improve Scripting Examples VIs and documentation

[x] This contribution adheres to CONTRIBUTING.md.

What does this Pull Request accomplish?

Re-write all scripting example VIs to be executable and self-documenting

Add sub VI to save and close system definition files and references
Add sub VI to convert relative paths to absolute
Migrate and format documentation about each VI to the front panel
Create front panel controls for necessary inputs

Remove markdown documentation, as it will easily get out of date with the VI contents
Replace existing example system definition file with an empty one and include in build
Mark all VIs as source separated

Why should this Pull Request be merged?
As-is, none of the Scripting Examples VIs can be executed when installed by the NI Package that contains them. One should be able to, but the system definition file it references is not included in the build. The remainder are not stand-alone VIs, but rather need to be used as sub VIs or as examples of logic.
After this change, the 4 remaining examples
What testing has been done?
Built the examples locally and ran each VI

[ ]  I don't see any changes to Find Instrument Addon Custom Device.vi or Open System Definition.vi.

I changed the VI Icons of both VIs to note that they are example sub VIs and not part of the scripting API.


QString: No DisplayString and StringView view on Mac

I'm not getting the DisplayString nor the StringView in my Watch window, only a {...} using both the default  and the one from MS. The "size" and "referenced" show up on expansion.
VSCode info:
Version: 1.54.1
Commit: f30a9b73e8ffc278e71575118b6bf568f04587c8
Date: 2021-03-04T22:42:18.719Z
Electron: 11.3.0
Chrome: 87.0.4280.141
Node.js: 12.18.3
V8: <IP_ADDRESS>-electron.0
OS: Darwin x64 19.6.0

Which natvis file do you use, the default one?

Both...
--
Gyuri
On Tue, Mar 16, 2021, 14:33 Michael Aigner @.***> wrote:

Which natvis file do you use, the default one?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/tonka3000/vscode-qt-tools/issues/44#issuecomment-800620904,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AF3FUTTSY63LZVERLCSYN5DTD7FDJANCNFSM4Y4LCREA
.

Both

The default one and which other one?

The other one is the Microsoft one you link to in the docs.

On Apr 2, 2021, at 9:53 AM, Michael Aigner @.***> wrote:
Both
The default one and which other one?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/tonka3000/vscode-qt-tools/issues/44#issuecomment-812613557, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF3FUTXQCMPBJBUX5GEYTXTTGXY77ANCNFSM4Y4LCREA.

Same problem like @Merrit on GNU/Linux with QT5.
Visualizer file from https://github.com/aambrosano/qt-natvis/blob/master/qt5.natvis.xml
Version: 1.68.1
Commit: 30d9c6cd9483b2cc586687151bcbcd635f373630
Date: 2022-06-16T00:18:08.407Z
Electron: 17.4.7
Chromium: 98.0.4758.141
Node.js: 16.13.0
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 5.15.65-1-MANJARO

anything new here? having the same issue unfortunately

This extension when installed on my setup refused to let me change the natvis setting. If I tried the change automatically reset to the extensions built-in and very limited one Only removing the extension entirely resolved the string display issue because that's the only way I could get back to the Microsoft one or in my case remove the natvis setting entirely.

@reporter123 You can set qttools.injectNatvisFile to false to disable the auto-injection like mentioned in the readme.
Which Microsoft natvis file do you refer to which contains a QString?

I don't know about Mac, but on Linux setting up pretty printers helped me to enable variable visualization:
https://microhobby.com.br/blog/2023/08/13/debugging-qt-applications-on-vs-code-with-debug-helpers/

@tonka3000 maybe a little confused there. Do remember looking yours however and trying figure out what was causing the display issue. I maybe thinking of something else. At any rate for me the resolution ended up being uninstall the extension and using gdb's pretty printers. lldb is a different story as the needed pretty printers don't have an official maintained source.

I can confirm that in Linux, even with the official qt6.natvis.xml, the QString visualization does not work. I made an mr with clarifications regarding natvis: #95


[4.0.0-alpha.12] Tailwind cli can not handle large CSS / 8192 bytes limit

Describe the bug
The tailwind-cli stdout data listener only listens to the first output When you have a larger CSS the following parts are ignored because it is already processing it via lightningcss, that fails because of "Invalid token in pseudo element: WhiteSpace("  ")"
To Reproduce

Make sure the tailwind output is more than 8192 bytes
Start bundler
Node fails because of broken css data passed to lightningcss.

Expected behavior
The data listener for the Tailwind cli should handle larger css files too.

Where does the limitation of 8192 bytes come from, is this windows specific issue? I'm testing on linux/macosx on Node 16/18 and I'm receiving a single chunk >100k bytes

Fixed in alpha.15


[Question] Access to repositories information from another account

https://github.com/Azure/actions-workflow-samples/blob/master/assets/create-secrets-for-GitHub-workflows.md
How to create secret for all repositories of a GitHub account A, to use it in another GitHub account B?

No tech guru here, but hope this helps nonetheless...
/workflow/build/Deployment/Node.js | \Web.app ---> Azure(cTM) \user \profile
From your Azure fs,
+ File: .github/workflows/workflow.yml

on: push

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
    # chkout repo
    - name: 'Checkout Github Action'
      uses: actions/checkout@master

    - name: Setup Node 10.x
      uses: actions/setup-node@v1
      with:
        node-version: '10.x'
    - name: 'npm install, build, and test'
      run: |
        npm install
        npm run build --if-present
        npm run test --if-present

    - name: 'Run acct A and publish secret for @Drjacky  Azure/repo'
      uses: azure/webapps-deploy@v2
      with:
        app-name: node-rn
        publish-profile: ${{ secrets.azureWebAppPublishProfile }}
- .portal, .crypto

Follow these steps to use it on Acct B:

Download acct A's published profile for WebApp from Portal (Get Publish profile option)
Define a new secret under Acc B's repository settings, Add secret menu
Paste the contents for the downloaded publish profile file into the secret's value field
Now in the workflow file in your branch: .github/workflows/workflow.yml replace the secret for the input publish-profile: of the deploy Azure WebApp action (Refer to the example above)
Finally,
usr/cred/Azure.Srvc | usr/profile/etc

repo.git ▶ .yml, .json, .py
secrets

User-level credentials i.e., Azure Service Principal for deployment.

Define Secret/vars
Settings -> Secrets -> New secret.  Provide a secret variable Name, for example 'AZURE_CREDENTIALS'
⮕ az cli
cmd/Store/io/value/_Secret_vars
Store output as Value of secret variable
az ad command scopes service principal to a specific resource group...
{resource-group} within a specific Azure subscription {subscription-id}
V

$ az ad sp create-for-rbac --name "myApp" --role contributor \
                            --scopes /subscriptions/{subscription-id}/resourceGroups/{resource-group} \
                            --sdk-auth

  # Replace {subscription-id}, {resource-group} "resource, group, details"
  # The command should output a JSON object similar to this:

  {
    "clientId": "<GUID>",
    "clientSecret": "<GUID>",
    "subscriptionId": "<GUID>",
    "tenantId": "<GUID>",
    (...)
  }


Remove Bootstrap from draft:resource

I propose that we remove Bootstrap from draft:resource to bring it in line with the G5 resources we've been building by hand.
Rationale:

The Bootstrap that is included is easy enough to add by hand, and seeing a page become pretty step by step by your own efforts is a nice win.
draft:layout is a pretty good head start by itself (includes assets, navbar) for people who want to Bootstrap.
Even though we don't require visual prettiness, seeing Bootstrap is an easy indicator of effort invested in a final project if we don't automate it.
Handwriting styles encourages more diverse styling. Otherwise they just stick with the components and layout that are generated.

Thoughts @jelaniwoods @pmckernin ?

@raghubetina I think this is a good idea.

I also think it's a good idea. I think we started having a discussion about this a quarter or two ago, but didn't have enough time to reach a consensus I think.

@raghubetina Do you also want to remove font awesome?

Yes, that seems like a good idea.
On Fri, Aug 7, 2020 at 1:59 PM pmckernin<EMAIL_ADDRESS>wrote:

@raghubetina https://github.com/raghubetina Do you also want to remove
font awesome?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/firstdraft/draft_generators/issues/85#issuecomment-670663145,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGGBUKZA7H43O33YUJYDXTR7RFKZANCNFSM4PUFB72Q
.

@raghubetina And just to be clear we want to remove all of the bootstrap classes from all of the views.

Everything in draft:resource, yes. Not the other generators, e.g. draft:
layout.
On Fri, Aug 7, 2020 at 2:09 PM pmckernin<EMAIL_ADDRESS>wrote:

@raghubetina https://github.com/raghubetina And just to be clear we
want to remove all of the bootstrap classes from all of the views.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/firstdraft/draft_generators/issues/85#issuecomment-670668874,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGGBUKRTNK6JIUDCHHD4H3R7RGNZANCNFSM4PUFB72Q
.


K8S Doc update

Re: https://developer.fermyon.com/spin/kubernetes doc
Only the wasm-runtimeclass.yaml for AKS should have the scheduler section (still works but technically needs a tweak)

Closed by https://github.com/fermyon/developer/pull/560/files


Name Mangling Robustness for Parameterized Types

Fix issue https://github.com/dotnet/corert/issues/1964 and provide robustness for mangled type names.

you look at the GC allocation profile of the compiler right now, we allocate a ton of strings

Agree ... the name mangling needs revamp, for both correctness and overall efficiency (do not allocate as much to construct the mangled names; and make the mangled names shorter):
Here are some things that I have been wondering about:

Do we need to include the namespaces in the typenames? What if we instead just use the type simple name; and just disambiguate it if there is conflict - similar to what we do for methods.
Use shortcut for the system module or frequently used system types. E.g. The reference to System.String type today is something like: System_Private_CoreLib__System__String. What if it is just something like #String?
CppCodeGen and native codegen name mangling can be quite different

I assume that this PR is fixing a problem that Simon is running into. I would be ok with it to get things unblocked; and make the overall cleanup separately later.
@nattress Could you please add a case to tests\src\Simple\Generics\Generics.cs that fails before this change and passes with it?

Opened #2178


Only show unfinished games which have scored a single point

Currently if we start a game and exit, the server still asks if we want to continue the previous 0-0 game.  Instead, just discard 0-0 games.

I can handle this one

sweet jesus the speed!

Sometimes it helps to have Slack open while you're doing other things ¯_(ツ)_/¯


SDXL 1.0 Tutorials - Not An Issue Thread

Thank you so much for the amazing release.
I believe these tutorials will significantly help the newbies
Tutorial GitHub readme files (instruction sources I use in videos) are updated for SDXL 1.0 base and refiner model
All tested and verified
ComfyUI Master Tutorial - Stable Diffusion XL (SDXL) - Install On PC, Google Colab (Free) & RunPod

First Ever SDXL Training With Kohya LoRA - Stable Diffusion XL Training Will Replace Older Models

How To Use SDXL in Automatic1111 Web UI - SD Web UI vs ComfyUI - Easy Local Install Tutorial / Guide

How to use Stable Diffusion X-Large (SDXL) with Automatic1111 Web UI on RunPod - Easy Tutorial

i have a question，if i have all sd-xl 0.9 model weights，which model should i download in sd-xl 1.0


Cannot make my bot connect to steam

The bot doesn't want to connect to steam. All of the steam information is correct but it keeps getting wrong steam guard codes. Latest version. Also older versions as well

If you happen to set up SDA to get the secrets, and then switched to mobile, the secrets obtained from SDA will no longer be valid.
You will need to set up SDA again, get the secrets, and don't switch to mobile. Keep the SDA folder in a safe place on your PC. Make sure to not lose it, as you will need it if you want to login into your bot account on a browser, manually accept the trade, etc.
Keep in mind that you don't need to keep SDA open in the background when your bot is running.

Things that it happened when i accidentally deleted the folder with the bot in it. I will try to set up sda again tomorrow

I've set up SDA again but it still doesn't work. Same Too many wrong Steam Guard codes error

Oh my god im sorry for wasting time but it didn't work because there was a "," in between the brackets and not outside them