Update cardano-api to <IP_ADDRESS>

Changelog
- description: |
    Update cardano-api to <IP_ADDRESS>
# uncomment types applicable to the change:
  type:
  # - feature        # introduces a new feature
  # - breaking       # the API has changed in a breaking way
  - compatible     # the API has changed but is non-breaking
  # - optimisation   # measurable performance improvements
  # - improvement    # QoL changes e.g. refactoring
  # - bugfix         # fixes a defect
  # - test           # fixes/modifies tests
  # - maintenance    # not directly related to the code
  # - release        # related to a new release preparation
  # - documentation  # change in code docs, haddocks...

Context
Fixes https://github.com/IntersectMBO/cardano-cli/issues/705
Checklist

[ ] Commit sequence broadly makes sense and commits have useful messages
[ ] New tests are added if needed and existing tests are updated. See Running tests for more details
[ ] Self-reviewed the diff

This previous run shows that the new step cabal test all does indeed catch golden files errors: https://github.com/IntersectMBO/cardano-cli/actions/runs/8702482757/job/23866620767?pr=720 (this pipeline ran on a state where the golden metadata file hadn't been adapted).


Comma is not needed

[The client.svc web service in SharePoint handles the HTTP request (the comma is not needed here) and serves the appropriate response in either Atom or JavaScript Object Notation (JSON) format.]

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

ID: 3aa0c9cd-d807-8d1b-1eb0-66373fa254b9
Version Independent ID: 409a88a8-7ae9-afde-d66c-81529ad15669
Content: Get to know the SharePoint REST service
Content Source: docs/sp-add-ins/get-to-know-the-sharepoint-rest-service.md
Product: sharepoint
GitHub Login: @VesaJuvonen
Microsoft Alias: vesaj

Thanks for the suggestions, but please feel free to contribute to the docs by submitting PR's with your suggested changes.


Generate dart classes based on schema definitions

I am wondering if gql is capable in any way of generating types based on schema definitions? I cannot seem to find any documentation or related questions on this.
for example:
Given the following piece of scheme:
type Person {
    age: Int
    name: String!
}

Can it be converted to sound null safe dart class like this:
class Person{
  int? age;
  String name;

  Person({this.age, required this.name});

  Person.fromJson(Map<String, dynamic> json){
    age = json['age'];
    name = json['name'];
  }

  Map toJson(){
    Map _data = {};
    _data['age'] = age;
    _data['name'] = name;
    return _data;
  }
}

This features is not added in this package. You have to write your own code generator for it.


unable to setup helidon test example to-do app

trying to setup helidon to-do example app on local machine , but getting following error
Environment Details

Helidon Version:
Helidon SE or Helidon MP MP
JDK version:1.8
OS:Oracle Linux 7
Docker version (if applicable):18.09.1-ol, build c3ab8a8

Problem Description
following steps to setup the to-do app https://github.com/oracle/helidon/tree/master/examples/todo-app  and gettign the following error when running the docker build for backend
Steps to reproduce
docker build -t helidon-examples-translator-backend backend/
Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[FATAL] Non-resolvable parent POM for io.helidon.examples.todos:helidon-examples-todo-backend:[unknown-version]: Could not find artifact io.helidon.applications:helidon-mp:pom:2.0-SNAPSHOT and 'parent.relativePath' points at wrong local POM @ line 24, column 13
 @
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR]   The project io.helidon.examples.todos:helidon-examples-todo-backend:[unknown-version] (/helidon/pom.xml) has 1 error
[ERROR]     Non-resolvable parent POM for io.helidon.examples.todos:helidon-examples-todo-backend:[unknown-version]: Could not find artifact io.helidon.applications:helidon-mp:pom:2.0-SNAPSHOT and 'parent.relativePath' points at wrong local POM @ line 24, column 13 -> [Help 2]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
[ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
The command '/bin/sh -c mvn package -DskipTests' returned a non-zero code: 1

You are trying to build the build from master. Please see this https://github.com/oracle/helidon/blob/master/examples/README.md.
If you want to build an example from the master branch you have to build the Helidon source code first. Building the example docker images from master requires extra steps, see https://github.com/oracle/helidon/blob/master/docs-internal/dockerbuild-local-snapshots.md.
I strongly recommend you to simply use the latest release tag (1.4.0)


locode-db: generate locode new command for locode.db generation

Move pkg/util/locode from the neofs-node repository to this repository. A new command for locode.db is introduced here: locode-db generate.
Closes #15 .

There is some problem with DCO though.


browser.get() not working for some URLs

Hi,
I'm trying to scrape some public linkedin urls (ill use mine as an example) using:
val browser = new Browser
browser.get("https://www.linkedin.com/in/piercelamb").
This code is returning:
"org.jsoup.HttpStatusException: HTTP error fetching URL"
And in some cases, returning a "status=999" which doesn't make sense. I can parse that link using pure Jsoup code, i.e.
Jsoup.connect("https://www.linkedin.com/in/piercelamb").get() just fine.
I tried updating from the 0.1.1 version of your artifact to 0.1.2. Also dug into the code somewhat and saw that you seemed to separate out a trait for Browser and 2 classes, though this doesn't appear to be reflected in the artifact. The only difference from base Jsoup code appears to be your executePipeline(...) function which im trying to understand since it is likely causing the problem. Perhaps its the default cookies you pass in defaultRequestSettings?

Hi! Yes, the master branch may be significantly different from v0.1.2, as I'm releasing v1.0.0 this week and that section has gone a major refactoring.
This is very strange... I'm experiencing the same error in v1.0.0, but it seems to be non-deterministic. Sometimes I repeat the request and it works well. Other times I execute the request directly using jsoup and I get the same exception you mentioned. Using the new HtmlUnitBrowser, based on HtmlUnit, an alternative to jsoup, I got:
org.apache.http.conn.HttpHostConnectException: Connect to www.linkedin.com:443 [www.linkedin.com/<IP_ADDRESS>, www.linkedin.com/2a04:f540:1:0:0:0:b93f:930a] failed: No route to host

By doing ping www.linkedin.com, I'm getting some very high latencies and even downtime periods:
64 bytes from <IP_ADDRESS>: icmp_seq=70 ttl=50 time=54.975 ms
64 bytes from <IP_ADDRESS>: icmp_seq=71 ttl=50 time=54.439 ms
64 bytes from <IP_ADDRESS>: icmp_seq=72 ttl=50 time=73.677 ms
64 bytes from <IP_ADDRESS>: icmp_seq=73 ttl=50 time=687.475 ms
64 bytes from <IP_ADDRESS>: icmp_seq=74 ttl=50 time=917.092 ms
64 bytes from <IP_ADDRESS>: icmp_seq=75 ttl=50 time=240.519 ms
64 bytes from <IP_ADDRESS>: icmp_seq=76 ttl=50 time=56.649 ms
64 bytes from <IP_ADDRESS>: icmp_seq=77 ttl=50 time=53.005 ms
64 bytes from <IP_ADDRESS>: icmp_seq=78 ttl=50 time=52.787 ms
64 bytes from <IP_ADDRESS>: icmp_seq=79 ttl=50 time=101.565 ms
Request timeout for icmp_seq 80
Request timeout for icmp_seq 81
Request timeout for icmp_seq 82
64 bytes from <IP_ADDRESS>: icmp_seq=80 ttl=50 time=3209.547 ms
64 bytes from <IP_ADDRESS>: icmp_seq=81 ttl=50 time=3328.162 ms
Request timeout for icmp_seq 85
Request timeout for icmp_seq 86
Request timeout for icmp_seq 87
64 bytes from <IP_ADDRESS>: icmp_seq=82 ttl=50 time=6410.486 ms
64 bytes from <IP_ADDRESS>: icmp_seq=83 ttl=50 time=6534.423 ms
64 bytes from <IP_ADDRESS>: icmp_seq=84 ttl=50 time=6383.424 ms
64 bytes from <IP_ADDRESS>: icmp_seq=85 ttl=50 time=6383.393 ms
64 bytes from <IP_ADDRESS>: icmp_seq=86 ttl=50 time=6143.081 ms
64 bytes from <IP_ADDRESS>: icmp_seq=87 ttl=50 time=5794.032 ms

Maybe this is a temporary problem with LinkedIn?

Interesting, yeah I'll try again tomorrow morning and see if anything has changed

Hi again @piercelamb! I have just tried yesterday's experience and it looks pings are now stable and I don't see any problems using Browser#get. Can you try it on your end?

Tried at it works fine. Definitely must have been on linkedin's end. Appreciate the quick replies.


configure redis latency stat to emit in micro seconds

Typically redis latencies are captured in micro seconds. This PR configures redis proxy to emit latency stats in micros.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: ramaraochavali
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: zackbutcher
If they are not already assigned, you can assign the PR to them by writing /assign @zackbutcher in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

pilot/pkg/networking/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Hi @ramaraochavali. Thanks for your PR.
I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@rshriram can you PTAL? I think default to micros is fine here, but you think it needs to be user configurable, I can make that change.

/ok-to-test

@rshriram can you please take a look at this when you time?

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: ramaraochavali, rshriram
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

pilot/pkg/networking/OWNERS [rshriram]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@ramaraochavali: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
c1fc50931d031e0aaa04a04afc601a9b7613eb4e
link
/test istio-unit-tests-master

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test istio-unit-tests-master

/test istio-unit-tests-master

@howardjohn @fpesce Could you please add the label for this PR as well to cherry pick to 1.2 release branch?

@howardjohn @fpesce @rshriram Looks like 1.2 is out - can we consider this for 1.2.1 patch? Can you please add the label for auto merge to 1.2.1?

@hzxuzhonghu Can you please also add label to this PR as well? With these two PRs we will get the complete redis support

Hi @ramaraochavali , mergify failed to create the PR to cherrypick this change without conflict, please submit a manually cherrypicked PR to 1.2!
Thanks!


Compact histograms on ingestion

This is only for the sparsehistogram branch!
This evolved into a bit of yak shaving.
Summary:

Compact for (integer) Histogram was relatively easy thanks to generics. (I'm now considering getting rid of more duplicated code, but that's for another PR.) Note, however, that the delta buckets of integer Histograms had to be treated specially.
While refining the doc comment for the Compact method, I realized that we probably shouldn't do the maxEmptyBuckets==3 thing, so I removed it (by setting it to 0, not by removing the feature, it might still turn out useful).
Finally I added the Compact call for both Histogram and FloatHistogram in the parser, which appeared to me to be the most reasonably place.
Since I expect in most cases that the Compact call in the parser will be a no-op, I added a fast path to it for that case to minimize the performance impact.

Hmmm, our golangci-lint doesn't know Go1.19 yet. That's why we cannot get all test pass.

I'll just switch to Go1.18 then. Enough for generics.

I realized there is a bug in the code. Will fix ASAP. Stay tuned…

OK, it works now. Please review now. :o)

Review hint: The actually important differences are just in the compactBuckets function. The diff isn't displaying that well. I recommend to copy out the old and new version of the function and diff them with a tool of your choice. Then you see all the special-case handling for delta buckets, and the rest is pretty much the same.


misskey: init at 2024.5.0 & nixos/misskey: init module

Description of changes
This adds the Misskey blogging platform by providing a package and accompanying NixOS module.
Source code: https://github.com/misskey-dev/misskey
Homepage: https://misskey-hub.net/en/
This PR is largely inspired by https://github.com/NixOS/nixpkgs/pull/296697.
TODO / Nice to have:

[x] Add the ability to pass secrets via files that are read at runtime.

Currently only for settings.{db.pass,redis.pass,meilisearch.apiKey}.

[x] Correctly type all config options in the NixOS module, as there aren't that many.

Created typed options with defaults for the most important options, while leaving the rest freeform.

[x] Split out the config options that affect PostgreSQL/Redis/Nginx/Caddy instead of reading them from the untyped settings field.

Not split out from settings, but all relevant fields are properly typed now.

[x] Assert the settings to be in a state where Misskey doesn't crash at runtime, e.g. when certain options are null.

All relevant fields have proper types and defaults and can't be null.

[x] Automatically configure SSL for Nginx (I never used Nginx before).

[ ] Potentially detect if SSL is even necessary by checking if settings.url starts with https:// or http://. This seems quite error prone, so a seperate toggle for SSL in nginx might make sense. Luckily, Caddy handles this automatically based on the URL type.
[ ] Alternative: Remove the option for auto-configuring a Nginx reverse proxy and let the user set it up completely themselves. This seems less ergonomic, but would leave the specifics of setting up SSL (among other things) to the user.

Feedback is welcome for any of the remaining (or even completed) TODOs.
Things done

Built on platform(s)

[x] 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

[x] 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

[x] 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
[x] 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
[x] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

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

Before merging please squash your changes so that there is one that adds yourself as maintainer, one that adds the package, one that adds the module

Thanks a lot @feathecutie!

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/2024-summer-of-nix-program-updates/46053/4


Added link to mina-docker-compose. Added new category 'Installation scripts and bundles'.

Added link to mina-docker-compose. Added new category 'Installation scripts and bundles'.

Hey there, thanks for adding your tool, it looks pretty nice! I would add it to the node scripts category, once it gets too big we can separate it into smaller sub-categories, but currently there isn't much disorganization :)


fix: remove sinon and enable image preload for random project

follow-up from: #77, #33

Ready for review, if anyone would like to review this :))

Also, just noticed that the color for the language is not consistent (this is flaky behaviour) - do you think this followed #33?

@mattxwang I think it's fine at least after this PR? I tried it on local env


Paths in option files are resolved relative to cwd

Search terms
Relative path, working directory
Expected Behavior
Paths in option files should be resolved relative to the options file
Actual Behavior
Paths in option files are resolved relative to the cwd.
Steps to reproduce the bug
npx typedoc --options .config/typedoc.json

Where .config/typedoc.json contains:
{
  "out": "../docs"
}

Should result in documentation in the current directory, not one directory up.
Fix
Introduce a new options type - Path, which behaves identically to String except readers have a hint that they should resolve it relative to the config file, and change appropriate options to use this option type.
Environment

Typedoc version: 0.20
TypeScript version: 4.1.3
Node.js version: 12
OS: Windows

This is trickier than I thought at first... because of plugins. Here we want to resolve "./foo/index.js", but not "bar" because bar is a npm-installed plugin...
{
  "plugin": [ "./foo/index.js", "bar" ]
}

This is trickier than I thought at first... because of plugins. Here we want to resolve "./foo/index.js", but not "bar" because bar is a npm-installed plugin...
{
  "plugin": [ "./foo/index.js", "bar" ]
}

Yep.. after further investigation. Not going to do this, too many edge cases.

Yep.. after further investigation. Not going to do this, too many edge cases.

Reopening because I do want to do this, and we just need two new option types - Path, and Module... not committing to 0.21 though.


prayer: fix dose indicator not accounting for super restores or sanfews

Currently, the Prayer Dose indicator will show when you can drink a prayer potion, even if you're using Super Restores or Sanfews which both restore more prayer. This leads to lost prayer points. The indicator now uses the most dominant potion type in the inventory (by spots used).

This also applies to sanfew serums, wasting 2.

Updated to include Sanfews, also now it uses the dominant potion type (as in the updated OP). ty @Lucwousin


Refactor hide logic for fields on DynDNS edit page

The Dynamic DNS edit page included a hide/show logic for username field only for few providers, which meant that if a provider with the hide logic was selected, then the field was lost for all others too.
This PR (or specifically one commit) refactors that logic, so that the default hide/show state is set always and only fields with different states are changed per service.
 I can drop this commit, if that change is not wanted or shouldn't be included in the PR.

[x] Redmine Issue: https://redmine.pfsense.org/issues/11840
[x] Manually tested that same fields are shown before and after the changes
[x] Ready for review

The sorting and whitespace and other changes should be a separate PR, let's keep this one to just the show/hide changes and nothing else.

Sounds good!

The sorting and whitespace and other changes should be a separate PR, let's keep this one to just the show/hide changes and nothing else.

First, should I make a PR for the whitespace or is that something we should just skip? If I create a PR, do I create a redmine issue too?
Second, is the sorting something that should be done, so should I make a PR of that?

I wanted to convince my self, that the change shouldn't break anything, so I verified that added and removed lines match (i.e., there are no such lines removed, which wouldn't have a matching line added).
diff \
  <(git show 5479afd0f9|grep '^-\s\+'|sed 's/^-\s*//'|sort -u) \
  <(git show 5479afd0f9|grep '^+\s\+'|sed -e 's,//.*$,,' -e 's/^\+\s*//' -e 's/\s*$//' -e '/^$/d' |sort -u)

Above yields empty output, as it's supposed to. Or wiht -y flag for the diff, it yields two identical lists of line contents.

Suggest you make a separate PR that contains both whitespace and sorting. Accompany it with a redmine ticket stating "Compliance with pfSense style guide" or similar.

@raphendyr #4523 was merged.  Please rebase your work

@rbgarga I think this PR was manually merged in https://github.com/pfsense/pfsense/commit/0e4202b77b98e748a321547ee39a2026baacb70b
This was my first PR, so I wasn't sure if it was supposed to stay open (e.g. close at release), hence I didn't say anything.


[question] Is it possible to generate js client code to avoid accessing openapi doc which should not published on production for safety reasons?

First thanks to this wonderful tool, I've tested it in my vue project,  and get rid of lots of boilerplate js codes used to request api with axios.
The only thing I'm worried about is the openapi doc must be published to browser for doing runtime request, It doesn't feel safe to publish all apis on production.

found another repository in typescript: openapi-typescript-codegen


update translated tours jsons

Description
Please include a summary of the change or which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[X] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

@mikeangelsilva @testradav , please review this PR. In this PR we will not proceed tours.json content translation along with UI resource. Instead, we'll merge localized tours and replace translated title/description/details information when fetching hike data, this is same way we'll implement in hike engine localization.


Update Coverage / Fix Broken Links

Update transit coverage to reflect coverage as of 1/10/22. Fixed some broken URLs.

Docs Build status updates of commit 24db28b:
:warning: Validation status: warnings

File
Status
Preview URL
Details

BingMaps/coverage/transit-coverage/europe.md
:warning:Warning
View
Details

BingMaps/coverage/transit-coverage/africa.md
:bulb:Suggestion
View
Details

BingMaps/coverage/transit-coverage/asia-australia-pacific-islands.md
:bulb:Suggestion
View
Details

BingMaps/coverage/transit-coverage/index.md
:bulb:Suggestion
View
Details

BingMaps/coverage/transit-coverage/north-america.md
:bulb:Suggestion
View
Details

BingMaps/coverage/transit-coverage/south-america.md
:bulb:Suggestion
View
Details

BingMaps/coverage/transit-coverage/europe.md

Line 608, Column 14: [Warning: file-not-found - See documentation] Invalid file link: 'http://www.Autocars_S.A.S.A.I.B..com'.
Line 2, Column 1: [Suggestion: description-missing - See documentation] Missing required attribute: 'description'.

BingMaps/coverage/transit-coverage/africa.md

Line 2, Column 1: [Suggestion: description-missing - See documentation] Missing required attribute: 'description'.

BingMaps/coverage/transit-coverage/asia-australia-pacific-islands.md

Line 2, Column 1: [Suggestion: description-missing - See documentation] Missing required attribute: 'description'.

BingMaps/coverage/transit-coverage/index.md

Line 2, Column 1: [Suggestion: description-missing - See documentation] Missing required attribute: 'description'.

BingMaps/coverage/transit-coverage/north-america.md

Line 2, Column 1: [Suggestion: description-missing - See documentation] Missing required attribute: 'description'.

BingMaps/coverage/transit-coverage/south-america.md

Line 2, Column 1: [Suggestion: description-missing - See documentation] Missing required attribute: 'description'.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


doc: gov doc revamp

TODO:

[x] include late quorum voting period extension
[x] include constitution amendments and law proposals
[x] add new params
[x] check other md files

We also need to add constitution amendments

@tbruyelle this should be done, please review

@giunatale LGTM


optimize Effect.zip{Left,Right}

LGTM but we should use andThen more often that is directly using flatMap

LGTM but we should use andThen more often that is directly using flatMap

Hah yes, need to force the habit.


Basic BFG telemetry

Add timing and completeness (TODO) telemetry logic for BFG
Test plan
TODO; how can I test this without polluting prod telemetry?

@bobheadxi you probably want to coordinate on this for Telemetry V2 if you are not already.
@SuperAuguste depending on the test kind, there is vscode/test/fixtures/mock-server.ts and loggedEvents. You need to point the logger to the mock server endpoint.


inlang: update translations

adding 2 new translations for pt-br

@Andrew-Chen-Wang
Hi. Could you check this PR, please?

@samuelstroschein ^

Referring to @jannesblobel who write the .po plugin.
From what I know, .po is a hassle to work with and the .po plugin got abandoned. Hence, you are probably better off removing inlang.

Hi thanks for the feedback, how can i add new translations?

Please use the basic django-admin commands https://docs.djangoproject.com/en/4.2/topics/i18n/translation/


Symfony 2.8., 3. compatibility

Fixes;

In Symfony 3 the option to override the Router class is removed from the config file. Using setClass on the definition resolves this issue. #17

The Twig loader was missing the implementation of findTemplate which caused issues with the profiler and debug bar on at least Symfony 2.8+. #16

Hey, thank you very much for your contribution.
I need to make a couple of modifications to this bundle, and I'll release a new version (0.2.0). Thanks for contributing!

I forgot to mention: project is now tested on multiple versions of PHP/Symfony (see here).
Once again, THANKS!


Want to delete also Tag Images

Want to delete also Tag Images ?

Yes, this tool check the feature image for tags as you can find at ghost-purge-images/lib/ghost/tags.js
Let me know if you have any question or find any issue


attr.NOTHING seems likely like it should be private

Is there a reason this is exposed? Seems like it's just attrs' internal fix for Python's no missing arg wart.
(I just found some [external] code that checks for whether a field default is NOTHING, which would have been more obviously wrong to the person who wrote it if it wasn't a thing they should have been touching).

Well it appears all over the API so I think it's correct to be public?  It gives us a language and people can use it to conditionally set attribute values…

Hmm interesting, so there's a reason an external user would want to touch that? What's conditionally setting attribute values?

If you're inspecting the attributes for whatever reason, you need to know about attr.NOTHING, so it should be public. Inspecting the attributes is a very interesting use case; cattrs does it for sure.

That, and with conditionally I meant something like: attr.ib(default=whatever or NOTHING).  You simply may want to be able to explicitly set a field to “not set”.
Closing now, feel free to discuss further once you arrive in Cape Town. :D


glide: Loosen prometheus/client_golang constraint

This loosens our constraint on prometheus/client_golang to support the
1.x release series.

I don’t believe anyone is authorized to merge in this repository.


[DISCUSS] maintainers for tlc-pack/ci repos

Hi all,
Over the past few months some TVM community members have worked diligently to replace the previously-undocumented CI system with one we can maintain collectively as a group. We’ve now upstreamed the Infrastructure-as-Code into public repos underneath the tlc-pack repo. Although this part has been finished, changes to the Jenkins infra now go through the following process:

A contributor (namely, @konturn or @driazati) forms the PR and tests against a staging instance (currently this instance is maintained by OctoML privately).
A TVM committer (namely, me) needs to review and merge PRs to this infra into the relevant upstream repos
The maintainers of the CI (namely, @konturn ) launch devops tools such as Terraform and Ansible locally to apply those changes to prod.

To fully realize our dream of shared ownership of the CI, we need to migrate the steps in (3) to GitHub Actions. Doing this with any measure of practicality requires write access to the ci repos so that there is no additional human in the debug loop. We also need to upstream documentation and train a set of tvm committers in maintaining Jenkins. This doesn't strictly require write permission, but is harder to do without it as the documentation may need to be placed in a different location than the repo.
We therefore need to address the loose end of: “how shall we grant write permissions to tlc-pack/ci repos?” Traditionally, write access is granted by TVM Committership, and it is the case today that the set of folks with write access to tlc-pack/ci repos is equal to the set of folks with write access to apache/tvm repos. Committership is a process that requires establishing merit and trust in the project via a track record of contributions. At present, this process tends to take O(6 months) at best. By contrast, an oncall rotation is typically a well-defined set of people whose membership can change quickly--for example, it's fairly typical in my experience for folks to join an oncall rotation 3-6 weeks after joining a team.
I'd assert that these two processes are not compatible with one another. To ground this in reality, the folks who need write access in order to move us forward here are @konturn and @driazati. @konturn has been working publicly on the TVM CI for only 2 months, and driazati has been working on TVM a bit longer, but none of them are yet Reviewers. Directly proposing committership to those folks as a way forward here seems inconsistent with past commitership promotions given the length of their track record. And while their contributions have both had outsize impacts on the project, there were a lot of low-hanging fruit that may not be present the next time we need to expand the oncall rotation.
Therefore I propose the following:

A new tlc-pack group ci-maintainers is created
We adopt as project policy that ci-maintainers can include folks working directly with a committer on CI, subject to PMC approval
ci-maintainers is granted enough access to tlc-pack/ci repos such that regular CI maintenance duties, as documented on those repos, can be carried out.

There has been some concern over whether establishing an alternative way to gain write permissions is inconsistent with Apache project governance. I think it's important to note here that we are not granting write permissions to the TVM project, and that the purpose of the CI repos is to automate running scripts that live inside the apache/tvm repo. Relying on non-committers to maintain the CI is also in line with the way that tvm doesn't require GitHub Actions' infrastructure to be open-sourced, and that we rely on GitHub employees to maintain the service.
With that said, this isn't GitHub Actions--it's a piece of infastructure engineered to specifically test TVM, and contributions here should be counted as credible contribution to the overall TVM project, and a source of merit which we should consider as grounds for granting committership to TVM.
Please let me know your thoughts!
Thanks,
Andrew
cc @tlc-pack/tlcpack-committer @driazati @konturn

I agree that we need to enable mechanisms and create opportunities for people to contribute in different ways -- in this case maintaining ci infra, jenkins related management and other daily routines are part of useful contribtions. In the meantime,  let us also work to find aways to recognize folks that contributed in this way sooner.

just wanted to ping a few different folks to make sure this has been seen widely enough. i'd like to proceed here if there are no objections.
cc @leandron @Mousius @manupa-arm @comaniac @junrushao1994 @kparzyszek-quic @masahi

Thanks for the ping @areusch, one of the disadvantages of this not being in the apache/tvm repo is that it's easy to miss things going on over here 😅

To fully realize our dream of shared ownership of the CI, we need to migrate the steps in (3) to GitHub Actions. Doing this with any measure of practicality requires write access to the ci repos so that there is no additional human in the debug loop.

Isn't this a short-term requirement rather than a long-term one to get the repo setup? Once it's setup correctly then we can begin following the usual flow with PRs checking using plan before roll out - can you expand on why this requires long term write access permissions?

We therefore need to address the loose end of: “how shall we grant write permissions to tlc-pack/ci repos?” Traditionally, write access is granted by TVM Committership, and it is the case today that the set of folks with write access to tlc-pack/ci repos is equal to the set of folks with write access to apache/tvm repos. Committership is a process that requires establishing merit and trust in the project via a track record of contributions. At present, this process tends to take O(6 months) at best. By contrast, an oncall rotation is typically a well-defined set of people whose membership can change quickly--for example, it's fairly typical in my experience for folks to join an oncall rotation 3-6 weeks after joining a team.

Could you expand on why the on-call rotation has been brought up here? Your initial point is around a single event that is getting the repository setup with GitHub Actions. We've had outages in this system (Jenkins disabled, nodes not scaled and credentials missing) which weren't dealt with until office hours resumed outside our timezone (BST); these outages could've been dealt with by TVM Committers but no guidance nor permissions have been given as far as I know (apologies if it was and I just missed it). It would be better to ensure TVM Committers are in a position to deal with issues rather than a new group of individuals outside the Apache project.

There has been some concern over whether establishing an alternative way to gain write permissions is inconsistent with Apache project governance. I think it's important to note here that we are not granting write permissions to the TVM project, and that the purpose of the CI repos is to automate running scripts that live inside the apache/tvm repo. Relying on non-committers to maintain the CI is also in line with the way that tvm doesn't require GitHub Actions' infrastructure to be open-sourced, and that we rely on GitHub employees to maintain the service.

With that said, this isn't GitHub Actions--it's a piece of infastructure engineered to specifically test TVM, and contributions here should be counted as credible contribution to the overall TVM project, and a source of merit which we should consider as grounds for granting committership to TVM.

This is contradictory, either this is "infrastructure engineered to specifically test TVM" or it's a service provided to the TVM Community to run CI?
If it's testing infrastructure for TVM, it's a core part of the TVM project as it's relied on for each contribution, which should be governed in the same way as the TVM project. There's also the commitment made as part of the original RFC to move the CI repo under the apache namespace, do we have a way do that with the additional write access?
If it's an external service which TVM uses, then it should not be used as evidence for the TVM project to consider committership in much the same way we should not consider those working on GitHub Actions.

@Mousius thanks for your comments here. did @ tlcpack/tlcpack-committer not work for you? i do want to make sure folks can see issues over here.

To fully realize our dream of shared ownership of the CI, we need to migrate the steps in (3) to GitHub Actions. Doing this with any measure of practicality requires write access to the ci repos so that there is no additional human in the debug loop.

Isn't this a short-term requirement rather than a long-term one to get the repo setup? Once it's setup correctly then we can begin following the usual flow with PRs checking using plan before roll out - can you expand on why this requires long term write access permissions?

kind of--you're right that upstreaming a GitHub Actions flow is a single work item. However, in my experience (and I think @driazati and @konturn would agree), Infrastructure-as-Code repos tend to operate a bit differently than traditional source control repos. Specifically--it's really hard, if not impossible, to be confident that a deploy is going to go precisely as it's spec'd in IaC. Obviously, the goal is that it does, but this is a complex enough process that stuff tends to go wrong. Servers are not quite in the state you expect, or a past deployment gone wrong can leave a datafile or control file (e.g. pidfile) in a place that wasn't planned for. Correcting a problem like this while remaining inside the Infrastructure-as-Code paradigm requires a follow-on PR written against the state of the production system.
Because of this limitation, I don't really see any one commit here as a single work item. Debugging such a situation as a non-committer places a TVM committer in the debug loop. I'm strongly opposed to codifying any such situation where a second human needs to be in the debug loop. Not only is it a waste of time, it's a frustrating system to work underneath. I think I speak for both @konturn and @driazati in saying that there is no desire on their part to work under such constraints.

Could you expand on why the on-call rotation has been brought up here? Your initial point is around a single event that is getting the repository setup with GitHub Actions.

What I mean by an on-call rotation is an example of a system that's designed to spread the burden of managing a production service across a team. I agree with you point that TVM CI doesn't ever need high-SLA oncall. However, in reality, @konturn is devoting cycles to CI outages right now. We need some analogue of an on-call here, so that:
a) folks like yourself have the freedom to investigate/fix CI issues when we're asleep
b) there is a way to coordinate amongst ourselves
c) @konturn can take vacation :)

It would be better to ensure TVM Committers are in a position to deal with issues rather than a new group of individuals outside the Apache project.

I do want to point out here that my goal with this proposal is to enable more people to help with CI so that the system can continue to be managed in the event someone is out of office. I would be very happy if those folks were committers, and equally happy if existing TVM committers stepped up to help here! The reason I'm proposing to also grant write access to designated folks who work with TVM Committers is due to the workflow.
At the moment, the system is operating normally and the highest priority work items are codifying the deployment flow in GitHub Actions. As discussed above, this task already might require a couple of PRs to get right. So far though, this is the same problem we might have in implementing something in TVM, but there is one additional wrinkle: the CI is never going to adequately model all problems that could occur in deployment.
As with any production system, an outage could occur at any time. We would then have a new higher priority task: unbreak production.  Unbreaking CI requires a degree of familiarity with the CI repository and an uninterrupted stretch of time during which a committer can coordinate remedies, such as a redeploy or reapplication of Ansible config, plus restarting any broken CI jobs. Whoever is working on this should ideally be familiar with the process of pushing changes. And for expediency, there is no point in having a human in the debug loop--that human should just be debugging the problem at that point.
At present, the number of TVM committers who have both this knowledge and time is ~0. And, considering that folks may go on vacation or otherwise be out of office from time to time, the number of TVM committers who need to know how to work with this system needs to be much larger. The process by which someone gains TVM committership is by merit--either by contributing improvements to the IaC, improving the documentation, or otherwise participating in the community.
The problem here is that the typical way someone might begin participating in this ci repo is by helping to run the system itself. As I've covered earlier, doing this typically means a TVM committer is in the loop to help with debugging and run deployments. But if the committer is in the loop, why don't they just do whatever the new person is doing themselves? It's much more time-efficient that way, and the new person isn't really learning anything when they're just watching someone click buttons for them. Requiring someone to attain TVM committership means that the training wheels don't come gradually off--instead they come off all at once and much later in the process than I think is likely to make for a scalable way to add folks here. Finally, TVM committership is also something we don't take away from folks after granting it--so, the bar for being a committer is deservedly high. I don't see a way to allow folks to help out in running CI without write access here.

This is contradictory, either this is "infrastructure engineered to specifically test TVM" or it's a service provided to the TVM Community to run CI?

I don't believe that it's contradictory. It's true that we rely on Jenkins to provide testing of PRs, and that we require Jenkins to pass in order to merge PRs. However, the specific tests aren't encoded in this repository--they are encoded in the Jenkinsfile in tvm itself. You are free to spin up a Jenkins instance internally without using this repo, configure it with the Jenkinsfile in the tvm repo, and reproduce the tests for yourself.
This repository is configuration data that allows us to run this Jenkins service for the tvm project. Because it doesn't include Jenkinsfile which specifically configures that infrastructure to test TVM, I believe it is just infrastructure which is provided to the TVM project.

If it's an external service which TVM uses, then it should not be used as evidence for the TVM project to consider committership in much the same way we should not consider those working on GitHub Actions.

Actually let me refine my statement, because I agree with the idea that code contributions outside of the apache repos shouldn't necessarily be used as grounds for establishing merit for TVM committership. I do think that folks working on this service should be considered for TVM committership based on their involvement on the forum and in GH issues, their support of TVM CI, and changes made to the CI system itself to further TVM's development. However, these should be considered as merit based on support for the project, and not based on the implementation of the code. This point should be taken up separately by the PMC to make it an official project policy.

There's also the commitment made as part of the original RFC to move the CI repo under the apache namespace, do we have a way do that with the additional write access?

The commitment was to make an attempt to move the CI repo under apache. We can't do that right now because we have yet to resolve the question of how to grant folks serving in an oncall rotation TVM Committer privileges, and as I covered earlier, I'm not optimistic that those two models of granting write access are truly compatible. Meanwhile, we have made little improvement away from our previous situation of having CI maintained by a single person. I prefer to move forward here and expand the set of folks involved with TVM CI. I'm not convinced we can resolve the committer privileges with any expediency.

chime in here about two things:

We do consider "contributions of all forms"(https://tvm.apache.org/docs/contribute/community.html#committers). Infrastructure maintaince, including doing on-call, and nightly service help on jenkins -- even if they do not leave as a trace on any code repos, can be considered as contributions to the PMC. For same spirit, things like giving talks and advocation do not necessarily leave code trace and are factors to be considered. It is unlikely that we want to be super rigid about circling what contributions counts or not.

There seems to be need of mechanisms to enable people to start making contributions in different way, specifically the CI and infra maintainace, and that seems to be a net positive -- so people can start contributing and get merit to be nominated as committers

There are a couple separate issues falling out here:

People working on the CI (i.e. me and @konturn) have been contributing to TVM for months but still don't have the access  to do certain things we need to (the GitHub Actions work is just one example)
As a result of point 1, we aren't able to make the CI fully open since we can't deploy it via mechanisms in-repo, instead we have to rely on side-channels like the fact that we just so happen to have the AWS credentials to the CI infra. We certainly could do better on the documentation side in onboarding other TVM committers to learn about CI but again 1 makes everything more difficult

Rather than this band-aid fix, the other solution here is to follow the normal path, including CI contributions as "normal" contributions, and improve/accelerate the committer promotion process as @tqchen mentions.

Discussed a bit with @leandron and @driazati and @konturn.
So overall one missing piece from this is the motivation of: "why do folks who are not committers need write access?" The reason is that we do not push-on-merge or push-on-green--it is manual. In order to trigger a deploy GH Action, you need to be a collaborator in the repository. I believe under the apache model, only Committers could trigger this deployment directly from the GH site.
We could consider an alternative way to relieve this burden, and this might allow us to work with the ACLs enforced in the apache/ namespace. This could work as follows:

There is a file in this repository called CONTRIBUTORS.md (or MAINTAINERS.md or something of the like) which lists a set of GH users who are allowed to trigger deployments. It would be expected that this list could contain folks who are not committers, but modifying the list would require the traditional code review process and therefore it would need to be approved by a committer.
Persons in that file would be allowed to comment e.g. "@tvm-bot deploy" (or perhaps "deploy ") and a GitHub Action would launch the deployment workflow if a) the PR was merged and therefore reviewed by a TVM Committer; and b) the author of that comment was in the CONTRIBUTORS.md file.

This keeps the requirement that changes are approved by folks who have been nominated via the same process as is used for Apache TVM while removing the need for that person to be in the debug loop.
It means that the flow for becoming a contributor to the CI project would work as follows:

At first, newcomers would create PRs which would need to be reviewed, merged, and deployed by a TVM Committer.
As that person gains trust in the community, a committer (or possibly the PMC) could propose that person be granted permission to deploy reviewed code on their own.
Since all changes are via the traditionally-respected review process, changes to the CI repo would serve as merit-based grounds on which someone could be nominated for TVM Committer following the typical process.

I think this could also be workable--we do need to figure out how to work with secrets under this arrangement, but I think that's a solvable problem.

I think that's a great idea @areusch 😸  it seems to help us move under apache which unblocks that activity as well so win win?
I'm uncertain if we need to be as heavy handed as adding a CONTRIBUTORS.md file given a committer has approved the PR but accept this might be a good added layer of protection until people are up to speed on the processes. As this will be driven from the PR thread itself, will it need to coordinate multiple PRs which haven't been deployed and ensure they're all marked as deployable?
Bonus question, can we get the terraform plan / infrastructure delta in the PR thread as well to help decide if we want to deploy?

In keeping with our previous approach, I'd suggest we get this all working in this repo (keeping the ACLs as they are), and then propose a move to apache/tvm to see what exactly is necessary from ASF infra.

@areusch apologies I missed these replies, that makes sense to me, DEPLOYERS.md makes more sense to describe what it does 😸 Otherwise, I agree we can get this working and port it to apache/tvm (or apache/tvm-ci (or whatever)) later, under the understanding we're still committed to migrating it later.
Given this fulfils the fundamental requirements of being Apache-compatible and empowering people to deploy independently, we should aim to set the bot up as soon as possible?

One note about the bot is that it will be much easier to make once everything is consolidated into one repo, so it might make more sense to do that then expand deployment capabilities (especially since we have a line to several committers right now that can push the buttons on GitHub for us)

@driazati I'm admittedly a bit dubious on the utility of combining the repos into one--each repository features a distinct deploy process and release cycle, and consolidating them could complicate the Actions setup, cause pipeline runtime to balloon, and hamper our ability to deploy to different components of the infrastructure independently.

Discussed a bit with @driazati, and came to the conclusion we can go monorepo with this if we structure our repository like so:

Subfolder for each repo we have today (so packer, terraform, ansible).
Use change detection on the PR to prevent workflows from unnecessarily triggering.
Serialize the deployment so that terraform apply occurs before ansible steps.

I'll add this item to https://github.com/tlc-pack/ci/issues/25

The discussion here is mostly done (and much of the discussion implemented!) aside from where the CI repo should live, so closing this but if there is more to deliberate we can do that in #25


add protocol to open collective link

without it some terminals dont understand that it is a link.
When they do it is very convenient to just click on it see what's there.
Perhaps it can drive up the conversion of donations (I hope it does at least a little bit)

I think "master" shouldn't be a default branch if de facto it is a "develop" branch

Develop goes away as soon as we launch v4

Thank you!


Select: Placeholder theming configuration has no effect

Environment

Operating System: Darwin
Node Version:     v21.5.0
Nuxt Version:     3.9.1
CLI Version:      3.10.0
Nitro Version:    2.8.1
Package Manager<EMAIL_ADDRESS>Builder:          -
User Config:      modules, ssr, devtools, typescript, imports, ui,
Runtime Modules<EMAIL_ADDRESS><EMAIL_ADDRESS>Build Modules:    -

Version
v2.12.0
Reproduction
https://stackblitz.com/edit/nuxt-ui-isptnw?file=app.vue
Description
Theming the placeholder of the select component has no effect.
<USelect
  placeholder="This text should be red"
  :ui="{ placeholder: 'text-red-600 dark:text-red-600' }"
/>

In addition, the default style of the placeholder is kind of off compared to regular input fields

There is a typo in your example: placholder -> placeholder.

Sorry! I've updated the example.
The issue is not related to the typo though.

You're absolutely right, the ui.placeholder is not taken into account on the Select component 🤔

The reason is that the placeholder doesn't work the same on a <select> and cannot be styled like an <input>. The text-gray-900 dark:text-white from the white color is what's styling the select. The placeholder key should not exist in the select config.

Thank you for the suggestion, but this would also change the color for the text when a value is selected.
I think that a separate color for the placeholder as well as a consistent style for the different input elements would be really beneficial.

If you don't want to change the implementation to be more inline with the default <select> element (which has no placeholder), how about moving the placeholder key to the SelectMenu component?
This could be easily applied here.

Here you go! I've applied the placeholder to the button / select when a placeholder prop is passed and nothing is selected.


[1.9.x] Bump to Mesos 1.2.2-rc1.

High Level Description
What features does this change enable? What bugs does this change fix? High-Level description of how things changed.
Related Issues

DCOS_OSS- Foo the Bar so it stops Bazzing.
DCOS- Foo the Bar so it stops Bazzing.

Checklist for all PR's

[ ] Included a test which will fail if code is reverted but test is not. If there is no test please explain here:
[ ] Read the DC/OS contributing guidelines
[ ] Followed relevant code rules Rules for Packages and Systemd

Checklist for component/package updates:
If you are changing components or packages in DC/OS (e.g. you are bumping the sha or ref of anything underneath packages), then in addition to the above please also include:

[ ] Change log from the last version integrated (this should be a link to commits for easy verification and review): example
[ ] Test Results: [link to CI job test results for component]
[ ] Code Coverage (if available): [link to code coverage report]

PLEASE FILL IN THE TEMPLATE ABOVE / DO NOT REMOVE ANY SECTIONS ABOVE THIS LINE
Instructions and Review Process
What is the review process and when will my changes land?
All PRs require 2 approvals using github's pull request reviews.
Reviewers should be:

Developers who understand the code being modified.
Developers responsible for code that interacts with or depends on the code being modified.

It is best to proactively ask for 2 reviews by @mentioning the candidate reviewers in the PR comments area. The responsibility is on the developer submitting the PR to follow-up with reviewers and make sure a PR is reviewed in a timely manner. Once a PR has 2 ship-it's, no red reviews, and all tests are green it will be included in the next train.

@mesosphere-mergebot bump-ee

@mesosphere-mergebot bump-ee

@sambatyon Why update the README SHAs if the same old cherry-pick SHAs still apply cleanly to the new Mesos branch? I thought the point of the README is just to make sure the correct patches are applied on top, not to track the absolute latest SHAs of each cherry-pick.

Fair point, then let's ignore my comment.

No other pull request is currently labeled with the 1.9.3 milestone and the ship-it label. Proceeding with the integration.

@mesosphere-mergebot bump-ee


Add core tests back to CI

What do these changes do?

The core tests for some reason were removed from CI. In this PR I do the followings:

adding back the Core Tests to CI
removing the im2col tests where the impl. was originally removed in #208

How Has This Been Tested?

N/A
Benchmark Results

N/A
Related issue number

N/A

I think the only test that is still relevant is "packbits_tests".
The other tests ("bconv2d_tests", "bgemm_tests", "fused_bgemm_tests") are for outdated code that is not used anymore.

I think the only test that is still relevant is "packbits_tests".
The other tests ("bconv2d_tests", "bgemm_tests", "fused_bgemm_tests") are for outdated code that is not used anymore.

the bgemm_functor is used in the bgemm_impl_ref.h' which is the ref impl. for RUY and it will not be removed (only the ref. impl. that uses the TF op impl. will be removed). The bconv2dand fused_bgemm_functor` will be removed in a future PR.


quill-cassandra-zio isn't published in maven repository

I can't found quill-cassandra-zio in https://mvnrepository.com/search?q=quill-cassandra-zio.

There for 3.7.2 but still not there for 3.7.1. I want to keep the issue open until I fix that.


Try to fix a problem: Error: EMFILE: too many open files

Expected Behavior
webpack build successfully.
Actual Behavior
03:51:24 $ yarn && node --stack_size=8192 --max-old-space-size=8192 ./node_modules/.bin/webpack --env.buildcache --env.hash --env.sourcemap hidden-nosources-source-map
03:51:24 [1/5] Validating package.json...
03:51:24 [2/5] Resolving packages...
03:51:25 success Already up-to-date.
03:51:26 Happy[js]: Version: 5.0.0. Threads: 4 (shared pool)
03:51:26 (node:3642) DeprecationWarning: Tapable.plugin is deprecated. Use new API on `.hooks` instead
03:51:26 Happy[js]: All set; signaling webpack to proceed.
03:51:26 Happy[lessModule]: Version: 5.0.0. Threads: 4 (shared pool)
03:51:26 Happy[lessModule]: All set; signaling webpack to proceed.
03:51:26 Happy[less]: Version: 5.0.0. Threads: 4 (shared pool)
03:51:26 Happy[less]: All set; signaling webpack to proceed.
03:51:26 Happy[sourcemap]: Version: 5.0.0. Threads: 4 (shared pool)
03:51:26 Happy[sourcemap]: All set; signaling webpack to proceed.
03:51:26 [hardsource:2513388c] Tracking node dependencies with: yarn.lock, node_modules/*.
03:53:35 Error: EMFILE: too many open files, open '/var/lib/jenkins/workspace/basic-job/node_modules/.cache/hard-source/2513388c9b471d25f64e53cafc9ec34abb0934723d7d4fda903190a8bc7f97e1/stamp'
03:53:35
03:53:35 error Command failed with exit code 1.
03:53:35 info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Modules infomation
There're 6,000+ modules in our project.
Possible solution
Replace all native node fs with graceful-fs.
It actually helps us fix this problem.
Code: https://github.com/LeetCode-OpenSource/hard-source-webpack-plugin/commit/93143ca4e0e4ff069e5606ffba8c2d26565c2965
Is this a right way? And should I create a PR for this?

I guess this problem is mainly related to webpack itself, and just crash when hard-source-webpack-plugin wanna open some more files.


Try GitHub actions as a replacement for Travis CI

Having fewer service dependencies is pretty appealing to me, so let's see if I can drop a dependency on Travis CI in favour of dependening on GitHub Actions instead.

Coverage decreased (-0.04%) to 47.139% when pulling 18d631f9d76e7c6069a526c1e0bee885565677e2 on jlfwong/github-actions into f758130455eddf061951386e10ae928724ece9be on master.


Allow for non default, non optional properties in Swift

I would like to have a model that doesn't have any default values nor optionals. But I cannot figure out how to do it and I guess it's simply not possible.
What I want to do is basically:
class Person: RLMObject {
    dynamic var name: String
    dynamic var age: Int

    init(name: String, age: Int) {
        self.name = name
        self.age = age
        super.init()
    }
}

This crashes at runtime due to: Person.swift: 12: 7: fatal error: use of unimplemented initializer 'init()' for class 'RealmTryout.Person'

Hi Petaren! Currently with Realm you do need to have default values for each property you create. Hope this helps

To add a bit more context here, Realm uses Swift's runtime reflection to determine the layout of your model classes. Because Swift's reflect(_:) requires to pass in an instance, Realm will require that calling init() on your model class actually returns an instance that can be reflected.
So you can still use custom initializers (e.g. init(name: String, age: Int)) as long as you also implement init(). However, you can choose to never call init() in your own code.
If you'd like this situation to be improved, please file a radar at http://bugreport.apple.com so that Apple can make Swift reflection flexible enough to allow introspecting classes without having to create an instance.

Thank you for your comments!

@jpsim can you please show here some working example with custom initializer? I'm trying to build it and init() seem not enough.
12: 7: fatal error: use of unimplemented initializer 'init(realm:schema:)'

Model
class MyModel: Object {
  dynamic var stringProperty = ""

  convenience init(stringProperty: String) {
      self.init()
      self.stringProperty = stringProperty
  }
}

Usage
let realm = Realm()
realm.write {
  realm.add(MyModel(stringProperty: "abcd"))
}
println(realm.objects(MyModel))
// Prints:
//
//Results<MyModel> (
//    [0] MyModel {
//        stringProperty = abcd;
//    }
//)

@jpsim  fatal error: use of unimplemented initializer 'init(realm:schema:)' for class 'MyModel'
the full code must override init() and  init(realm: RLMRealm, schema: RLMObjectSchema) to work.
import RealmSwift
import Realm

class MyModel: Object {
  dynamic var stringProperty = ""

  override init() {
      super.init()
  }

  override init(realm: RLMRealm, schema: RLMObjectSchema) {
      super.init(realm: realm, schema: schema)
  }

  convenience init(stringProperty: String) {
      self.init()
      self.stringProperty = stringProperty
  }
}

It's not currently possible to override Object.init(). This is something we'd like to fix. We're tracking this issue as #1849.
If you change your model definition to this, your convenience initializer should work:
class MyModel: Object {
  dynamic var stringProperty = ""

  convenience init(stringProperty: String) {
      self.init()
      self.stringProperty = stringProperty
  }
}

You shouldn't have to import Realm when using Realm Swift. If you find yourself needing something from the Realm module that's missing from RealmSwift, please file an issue here. We aim to have feature parity across both frameworks.

@jpsim my fault.

@krzyzanowskim don't worry about it, we understand the expectation is for this to just work, and we'll continue to do our best to reduce the number of "rough edges" like these.


A bug when decompile obfuscated code

Describe the bug
Unable to output correct decompilation results.
To Reproduce
Use ghidra to decompile a simple code:
00401009  | 68 07679D2F       | push 0x2F9D6707
0040100E  | 68 9BB115D9       | push 0xD915B19B
00401013  | 68 27104000       | push 0x401027
00401018  | 8B4C24 06         | mov ecx,dword ptr ss:[esp+6]
0040101C  | C7840C EB26F898 0 | mov dword ptr ss:[esp+ecx-6707D915],501000
00401027  | 58                | pop eax
00401028  | C3                | ret

Expected behavior
After executing the code,EAX should be 0x501000.
However, the output result of ghidra is 0x401027
Additional context
I think the reason for the error is ghidra performed constant propagation prematurely before performing stack variable detection.

Describe the bug Unable to output correct decompilation results.
To Reproduce Use ghidra to decompile a simple code:
00401009  | 68 07679D2F       | push 0x2F9D6707
0040100E  | 68 9BB115D9       | push 0xD915B19B
00401013  | 68 27104000       | push 0x401027
00401018  | 8B4C24 06         | mov ecx,dword ptr ss:[esp+6]
0040101C  | C7840C EB26F898 0 | mov dword ptr ss:[esp+ecx-6707D915],501000
00401027  | 58                | pop eax
00401028  | C3                | ret

Expected behavior After executing the code,EAX should be 0x501000. However, the output result of ghidra is 0x401027
Additional context I think the reason for the error is ghidra performed constant propagation prematurely before performing stack variable detection

FWIW, the emulator returns EAX = 0x501000 with the bytes
68 07 67 9D 2F 68 9B B1 15 D9 68 27 10 40 00 8B 4C 24 06 C7 84 0C EB 26 F8 98 00 10 50 00 58 C3

In fact, I already understand the cause of the problem.This is an article I wrote in Chinese.
https://bbs.kanxue.com/thread-278727.htm
You may need to read it through a translator.
I just want to report some issues.....so developers may notice more when writing decompilers


⚠ Bofrost.at has degraded performance

In 37e2bef, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1561 ms

Resolved: Bofrost.at performance has improved in 6469b43 after 6 minutes.


Localization Issue

The localization file does not appear to work properly for custom items.
The script functions perfectly to create custom items in-game, and there is no issue with texture files either. Here is part of the script (the rest is just replicated with different variables and unlocalized names):
#loader contenttweaker
import mods.contenttweaker.VanillaFactory;
import mods.contenttweaker.Item;
var motor1 = VanillaFactory.createItem("basicmotor");
motor1.maxStackSize = 16;
motor1.register();
This script works to load the new item in-game. However, the localization appears to be broken. I followed the instructions on the ContentTweaker section of the CraftTweaker documentation to produce this line in the localization file:
item.contenttweaker.basicmotor=Basic Fluxfield Motor
In-game, however, the item is named "Basic Fluxfield Motor.name" and I can find no way of removing the ".name" from the in-game localization. The same thing happens for all other custom items I have attempted to register.

It is possible to localize items with crafttweaker.

You need to add .name at the end of that unlocalized string @eloquentJane
item.contenttweaker.basicmotor.name=Basic Fluxfield Motor

Here's an example from my own pack file:
item.contenttweaker.fluxdust.name=Flux Dust
item.contenttweaker.fluxblend.name=Flux Blend
item.contenttweaker.bitumen.name=Bitumen

Yep like Lanse said you need to add .name to your localization tags in the file.


[Icon Requests from Feather] camera-lens

As per https://github.com/lucide-icons/lucide/issues/119 and https://github.com/feathericons/feather/issues/221:

First is the original suggestion, I think that looks a bit too much like an orb as opposed to lens.
Personally not sure whether this icon is needed at all, all in all, I prefer the simplicity of the last one, albeit named focus instead of lens.

I understand your concerns. I agree. Let go with focus!


Moved 2 timing sensitive try_lock libcxx thread tests to unsupported

With PR #949 , 2 of the timing sensitive try_lock libcxx thread tests were removed from tests.supported.default. Saw one of these tests fail with the libcxx ENABLE_FULL_LIBCXX run on the Jenkins server run today. Hence moving them to tests.unsupported.

bors try

bors r+


fix for #5 out of memory on esp8266

Fix for https://github.com/tayfunulu/WiFiManager/issues/5
Modified handle_root to send the response incrementally with as little memory required as possible.  I was able to connect with 12 SSIDs in the list.  At some point this will break with more SSIDs, but it's a start.
According to some research you don't need to send Content-Length if you call client.close() when finished.  So I made that optional in send_header()

i applied. thanks.


Does codeium support Common List, or Emacs Lisp?

With support I mean is the AI trained with those languages? On the main web page I've seen support for "LISP" but as we all know there are many different Lisps.

It does support elisp and seems to be aware of Emacs functions.

Thanks


Typo "Microsoft Teams Room"→"Microsoft Teams Rooms"

https://docs.microsoft.com/en-us/microsoftteams/rooms/recovery-tool
https://github.com/MicrosoftDocs/OfficeDocs-SkypeForBusiness/blob/live/Teams/rooms/recovery-tool.md
#PingMSFTDocs

Docs Build status updates of commit f8b3f76:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

Teams/rooms/recovery-tool.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

@dstrome PR has been copyedited and is ready for final review, could you please check and merge? Thanks!


Added Out-Excel Command

This is a function I set up because I found myself using a lot of the same parameters with Export-Excel, and just wanted a clean spreadsheet quickly.
Out-Excel expects input from the pipeline, and only requires a path. If .xls/.xlsx extension is not specified, .xlsx will be automatically added.
If no TableStyle is specified, Medium2 TableStyle is used.
If no WorksheetName is specified, "Data" is used.
Freeze Top Row, AutoSize, and AutoFilter are used by default.
WorksheetName is used for TableName by default.
Excel opens the file automatically after processing, unless the 'DontOpen' switch is used.
'Force' switch can be used to overwrite existing file path.
Syntax can be as simple as:
Get-Service | Out-Excel C:\Temp\Services
Or, as complex as:
Get-Service | Out-Excel -Path C:\Temp\Services-Processes.xlsx -Sheet "Services" -TableStyle Light3 -Force -DontOpen
Get-Process | Out-Excel -Path C:\Temp\Services-Processes.xlsx -Sheet "Proccesses" -TableStyle Light4

Thank you!
Dom Ruggeri

I think this is redundant as we already have now mode that fulfills the same purpose:
Get-Service | Export-Excel
after this fixes https://github.com/dfinke/ImportExcel/issues/657 this is the same thing.
The only difference is that now mode use -AutoFilter by default and you propose using -TableName Data and -FreezeTopRow by default which is a personal preference.
In my personal preference -FreezeTopRow is unnecessary with -TableName as Excel already "Fixes" the column names in Table mode instead if showing A, B, C...
Regarding -TableName being use by default instead of -AutoFilter I support that but I don't know if we are the majority on this one?

I glanced at this early and it seemed like Export-Excel -Now and the -Now can be left off to get the same behavior. IIRC I built -AutoFilter first and that is why it's the default. Changing that to -Tablename feels better, it has a nicer layout. It's a breaking change but seems reasonable.
Allowing a -WorksheetName also seems reasonable. Specifying the -Path bypasses the -Now and  -show:$false does not work.
Seems like a bunch of work that could be troublesome and I'm not sure if any tests are in place to test this dance.
So, naming the file, the worksheet and getting a TableName.  Tablename with a random name seems straightforward, but the devil is in the details.
Out-Excel could be added as an example.

@ili101, @dfinke Thanks for reviewing this.
I see what you guys are saying, and I agree this can be accomplished with the -Now parameter, and other adjustments as @ili101 has proposed in #661
Thanks!

@DomRRuggeri Thanks for the PR, much appreciated. Feel free to do more, plus, ask questions in the issues of the repo. This is good collaboration.


Replace [L2R'] with [M'L] etc.

These are marginally easier to perform.

[L2R'] -> [M'L]
[L2R] -> [M2R']
[R2L] -> [M'R']
[R2L'] -> [M2L]

They rotate the cube though.

Also consider replacing the other 180 degree combos.


finalize will not get to lock outputs because verify_slate_payment_proof is called first

Current behaviour:
trying to finalize a slate that was generated by owner api, results in error message
Expected bevaviour:
finalize should succeed.
Steps to reproduce:
Create a slate via api:
curl -u mwc --request POST --data-raw '{"jsonrpc":"2.0","method":"init_send_tx","params":{"args":{"src_acct_name":null,"amount":100000000, "minimum_confirmations":1,"max_outputs":20,"num_change_outputs":1,"selection_strategy_is_use_all":false,"message":"Take money, please!","target_slate_version":null,"estimate_only":null,"send_args":null,"exclude_change_outputs":false, "minimum_confirmations_change_outputs": 1,"payment_proof_recipient_address":null,"ttl_blocks":1000}},"id":1}' http://<IP_ADDRESS>:3420/v2/owner
receive slate with another wallet.
finalize with first wallet:
mwc-wallet finalize -i slate.tx.response
You will see:
Wallet command failed: LibWallet Error, Payment Proof generation error: TxLogEntry with original proof info not found (is account correct?)

Works fine now.


[IOTDB-519] Apache IoTDB integration with Prometheus

support prometheus write data to iotdb

Please create or link an issue to describe the intent of this PR, So that people can understand your work better.
I remember there one issue and one design document link to this PR. please link here.

Please create or link an issue to describe the intent of this PR, So that people can understand your work better.
I remember there one issue and one design document link to this PR. please link here.
i have modified

Please create or link an issue to describe the intent of this PR, So that people can understand your work better.
I remember there one issue and one design document link to this PR. please link here.
i have modified

Where is the design document?


add direction source parameter

this resource's defaults for source (incoming) vs. destination (outgoing) repo/branch are opposite for cloud vs. server.
server has a direction query param, which defaults to incoming corresponding to destination.
the resource's cloud code path was using .source.branch.name, which corresponds to source.
this change allows unconfigured direction to continue old resource behavior for backwards compatibility, while also allowing the user to specify incoming/outgoing as needed.
see: https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/{workspace}/{repo_slug}/pullrequests#get
see: https://docs.atlassian.com/bitbucket-server/rest/7.2.4/bitbucket-rest.html#idp280

Hi, @sooncj. Thanks for contribution!


Server crashes when requesting a container as application/ld+json

If you do a GET request to a Solid container, with any of the following headers, it crashes ldnode.

Accept: application/ld+json
Accept: application/nquads
Accept: application/n-quads

This is partly caused by the RDFs list in lib/handlers/get.js#25 -- it tries to parse the container, which eventually ends up calling lib/utils.js / stringToStream() with an undefined value.
This results in an uncaught type error:
Uncaught TypeError: Cannot read property 'length' of undefined

To do:

Harden stringToStream() -- needs to return if the argument is not actually a string.
Fix the handling/parsing of application/ld+json on containers.
Fix or remove application/nquads and application/n-quads from the list in the get handler.

See PR #223 for failing test.

Fixed by https://github.com/linkeddata/ldnode/pull/225
Closing.


migrate poolmon to extendedtools

This PR migrates PoolMon from the plugins-extra into ExtendedTools.

poolmon needs updated for theme support


Microsoft.CodeAnalysis in search shows wrong version

Searching for Package Microsoft.CodeAnalysis (https://www.nuget.org/packages?q=Microsoft.CodeAnalysis) on the nuget.org gallery shows version 2.0.0, but the 2.0.0 package is not available.
Clicking on the package page shows the proper versions.

There was an issue with propagating deletions that has since been fixed.


Implement eth_maxPriorityFeePerGas RPC method

Description
Implement the  eth_maxPriorityFeePerGas RPC method as defined by the official specification https://ethereum.github.io/execution-apis/api-documentation/

some extra context in #5658

this feature it is already implement in GraphQL, so should be simple to expose it as RPC methods as well

closing as duplicate of #5658


Fix non-ascii characters files disappear in the VirtualBox Shared Folder

Fix http://blog.ecoteki.com/webservice/post-2638/
Related to https://github.com/boot2docker/boot2docker/commit/0de3b8e705a426f19d956241f63f3c2eb5cf1a6c

これって Windows でも大丈夫でしょうか？

Do you mean this commit might occur errors on Windows?

このコミットで Windows がエラー起こすかもしれないということですか？

I believe this is not harmful on Windows, but I'm just not sure what will happen on Windows with this.

And it seems not to need this on Windows.
https://twitter.com/K_akiya/status/738625712295288832

Thanks!
Yes, I also saw that tweet. I'll ask Akiya to help me test this.

hi ixkaito,ailispaw.
I tested with mount_options: ["iocharset=utf8"], 'mounting share folders' succeeded in my Windows10.
I could boot Wocker and start default container.

Thanks @ailispaw @akiya64 !


unickq.seleniumhelper throwing errors while compiling

trying to run it locally for two browsers.
Made changes to app.config but while building it is throwing errors:
Could not find schema information for the element 'unitTestProvider'.
Could not find schema information for the attribute 'allowDebugGeneratedFiles'.
my app.config file:

@sharmaabhin what version and specflow version do you use?

i am using latest version 1.1.3 of unickq.seleniumhelper and using specflow 2.2.0
nuget package manager automatically resolves all the dependencies upon installing unickq.seleniumhelper nuget package.

1.1.3 doesn't support 2.2.0.
Try betas 2.0.0


Declared environment variable ALLURE_CLEAN_AGEDAYS, not getting considered for cleanup.

Environment variables have been set as below.

Still when I start the server on my local, I am getting below message during startup and my config, doesn't get picked up. Am i doing something wrong here?

was an issue in https://github.com/kochetkov-ma/allure-server/releases/tag/v2.11.3
what version do you use? use latest https://github.com/kochetkov-ma/allure-server/releases/tag/v2.11.4
and attach the logs with prefix [ALLURE SERVER CONFIGURATION]

Using https://hub.docker.com/r/kochetkovma/allure-server latest docker image.


Python: formater->formatter

Fix an annoying typo spread around in the python beautifier.
This would the config of existing users. I don't know what your policy is on this.

+1

Thank you for contributing!

Published to v0.32.0

While you're on this, could you maybe take a look at #1897, which is probably the more interesting of the two?

Thanks for the notice @nathdwek . I missed #1897. I'll try to get it in the next release 😄


Syncing LDAP groups with Django

Hi All!
I would like to know if it is possible to synchronize only specific groups from LDAP to Django?
According to Django documentation it can be done via AUTH_LDAP_MIRROR_GROUPS, as the documentation states the following:
"This can also be a list or other collection of group names, in which case we’ll only mirror those groups and leave the rest alone."
Could you please tell if this functionality has already been implemented or not?
I've tried to add a list of group names, but it doesn't work:
findGroupPerms: true
mirrorGroups: ['group1', 'group2']
mirrorGroupsExcept: null

I'm currently using:
Chart: netbox-5.0.0-beta.103
Netbox: v4.1.1-3.0.2
Thanks!

Thanks for filing this issue, @Denis-themenace.
That being said, it has nothing related to the chart.
As explained by the documentation page you linked, AUTH_LDAP_MIRROR_GROUPS (thus mirrorGroups) is a boolean value (only true or false).

Thanks for the info Leo @LeoColomb
For those who will also be looking for an answer to this question. This feature is working if there is no spaces between the group names:
mirrorGroups: ['group1','group2',group*’]
Once user logs into Netbox via LDAP, Django will automatically create/mirror only those groups that are mentioned in the list above and will add this user as a member of this new group(s). All new users will also be placed in the groups they belong to.


Webview renders empty

Describe the bug
Hello i've tried example in my project and web view renders empty
and problem is not with the webview compnent because i've tested it. with other sources and it worked ok.
and also webview dosen't call onError method instead it loads the page perfectly but display blank.
"react-native-react-bridge": "^0.11.2",
"react-native-webview": "^13.8.6",
"react-dom": "^18.2.0",
"react": "18.2.0",
"react-native": "0.71.18",

and when i console.log webapp it will return this:
(file was too long so i've uploaded via zip)
outt.html.zip
and i saved that file to html file and opening it with browser it also returns blank page.

@inokawa it's not triggering onLoadError, If you check zip file thats the output of the library of the webpage

@inokawa my project was native project then i added expo support to my project here are my config files :
metro.config.js
const {getDefaultConfig} = require('metro-config');
const {
  createSentryMetroSerializer,
} = require('@sentry/react-native/dist/js/tools/sentryMetroSerializer');

module.exports = (async () => {
  const {
    resolver: {sourceExts, assetExts},
  } = await getDefaultConfig();
  return {
    transformer: {
      babelTransformerPath: require.resolve('./customTransformer.js'),
      getTransformOptions: async () => ({
        transform: {
          experimentalImportSupport: false,
          inlineRequires: true,
        },
      }),
    },
    resolver: {
      assetExts: assetExts.filter(ext => ext !== 'svg'),
      sourceExts: [...sourceExts, 'svg'],
    },
    serializer: {
      customSerializer: createSentryMetroSerializer(),
    },
  };
})();

and customTransformer.js
const reactNativeReactBridgeTransformer = require('react-native-react-bridge/lib/plugin');
const svgTransformer = require('react-native-svg-transformer');

module.exports.transform = function ({src, filename, options}) {
  if (filename.endsWith('.svg')) {
    return svgTransformer.transform({src, filename, options});
  } else {
    return reactNativeReactBridgeTransformer.transform({
      src,
      filename,
      options,
    });
  }
};

@inokawa thanks


managed identity: Azure Firewall Policy Preview

Details on managed identity availability for Azure Firewall Policy resource. Currently available in preview in public cloud.

@gersner : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@gersner : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@gersner : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@gersner : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#sign-off

#sign-off


chore-get-and-clean-data

chore-get-and-clean-data
Data collection and cleaning in which the following tasks have been performed:

Extraction of NBA matches data from the database
Selection of a fixed sample of matches belonging to 1980 or later years
Extraction of the columns selected for the development of the project
Elimination of matches that have not been played

Pull request status - Accepted


Issue after upgrading to 0.1.13

After upgrading this happend. Python 3.5.1
>>> from typing import Type
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: cannot import name 'Type'

$ apistar run
Traceback (most recent call last):
  File "/usr/local/bin/apistar", line 7, in <module>
    from apistar.main import main
  File "/usr/local/lib/python3.5/site-packages/apistar/__init__.py", line 8, in <module>
    from apistar.app import App
  File "/usr/local/lib/python3.5/site-packages/apistar/app.py", line 7, in <module>
    from apistar import commands as cmd
  File "/usr/local/lib/python3.5/site-packages/apistar/commands/__init__.py", line 2, in <module>
    from apistar.commands.new import new
  File "/usr/local/lib/python3.5/site-packages/apistar/commands/new.py", line 8, in <module>
    from apistar import schema
  File "/usr/local/lib/python3.5/site-packages/apistar/schema.py", line 2, in <module>
    from typing import Any, Dict, List, Tuple, Type, Union  # noqa
ImportError: cannot import name 'Type'

Yay! Fixed in 0.1.14 :dancing_men:

We do need to be careful tho - the tests locally and on travis didn't pick this up, don't want to reintroduce it at a later date! 😐

Which Python versions are Travis testing with currently?


Refactor/rename fails

Whenever I try to use the "rename" command, I get the following error:

dartlang version: 0.4.15
Dart SDK version: 1.13.0-dev.7.4
/cc @devoncarew

Does this work for you on trivial projects?
And, what project is this failing for you on, and what folder did you open in atom?

I opened the whole flutter repo in Atom and I was trying to rename the filePath parameter to ensureDirectoryExists
https://github.com/flutter/flutter/blob/master/packages/flutter_tools/lib/src/file_system.dart#L10

I have this problem both on a Mac and on a Linux box.

Thanks! Will investigate.


Feature/support hosted galaxy

Support hosted Galaxy workflows.
Kept logic mostly the same.
Moved functions into a service.
Add tests (~92% coverage).
Ran strictNullChecks on the file (which is why it looks so complicated)
A lot of the existing logic is odd. but for better or worse, keeping it the same for now.

Hmm...I have a few unused parameters.


Make Uiua LSP work on ".ua" files instead of ".uiua" files

.ua is the file type this is supposed to work on.

can you provide a reference and perhaps insight as to why @ckafi may have chosen the other way?

Here is a list of various Uiua modules. Note that these all use ".ua".
@ckafi probably didn't know that the most-used file extension was ".ua".

@JoaoFelipe3 you're mixing concepts here. filetype is not the same as the file ending. If you open a main.rs for example, the filetype will be rust not rs.

Oh my god


Incompatibility with Android RN master TimingModule

Describe the bug
FYI: It looks like at least 2 things the Detox android implementation depends on are no longer true in RN master in regards to the timers implementation.

That there's a class called com.facebook.react.modules.core.Timing. It's been renamed to TimingModule (changed in https://github.com/facebook/react-native/commit/e9b50fa4ee087ea0f2f09c01a0a9c1d85a638f54#diff-591535399526875d82f1fcd15406678a)
That the timing module class impl has a field named 'mTimers'. The module has been refactored to hold this timer information in an instance of a new class called JavaTimerManager. (changed in https://github.com/facebook/react-native/commit/4d774bdc0db0547fec5123ebb88e1994b271271c#diff-591535399526875d82f1fcd15406678a)

To Reproduce
Test Detox against react native master and run into these build issues.
cc @cs01

@rodrigos-facebook wow, a big thank-you for this!!! We'll make the proper adaptation.
As I understand it (looking at the commits log) we ought to expect these changes to apply starting RN .62.0, right?

FYI we have added internal land-blocking tests at facebook that ensure iOS compatibility between Detox and React Native. We are planning to add similar tests for Android once a new Detox version with fixes for the issues Rodrigo described have been published.

This is very exciting. Great to hear!

I've put up a PR to add a new API to TimingModule that should expose the information that Detox needs: https://github.com/facebook/react-native/pull/27539
If that API does what we need, then we should be able to use that instead of updating Detox to refer to the new class name. I basically just copied what Detox does in TimersIdlingResource based on the discussion in #907.

Just a thought about everything going on in here (at 01:04 AM), if we are already getting help from Facebook on this, setting up RN to fit Detox's needs, we might as well want to think of official espresso Idling resources like APIs, which are event based and not polling based, integrating idling resources inside RN itself, like described here https://developer.android.com/training/testing/espresso/idling-resource#integrate-recommended-approach
Disclaimer: I haven't read the whole thread or web over the PR, but want to make sure we're moving in the recommended espresso way. I will read everything and revise this comment if needed.

@rotemmiz
I'd definitely be interested in looking into using proper idling resources in RN for in the future, but I don't think I want to try to make that change right now - I'm working on rewriting some pieces of our infra to no longer use the bridge, so I'd probably try to make that change as part of that effort, rather than refactoring our existing code. With this PR I was just trying to do a simple fix so that Detox doesn't have to rely on reflection (since I broke that by renaming + refactoring the Timing class).
What do you think? Is that PR a good step forward for now, or would you rather just keep using reflection for now, and update the class name, etc.?

I'd choose to avoid reflection as much possible, but it's for @d4vidi to decide on this question.

@ejanzer There's no real need for reflection here but for the sake of accessing internals. Seems like your changes in https://github.com/facebook/react-native/pull/27539 will eliminate usage of reflection altogether!
Anyways again as I already mentioned in https://github.com/facebook/react-native/pull/27539, it's IMO ok to first fix this part, then when we're ready for the transition to event-based implementations, well we already know what we're up against.
The question I'm asking my self now is whether this can be closed until your https://github.com/facebook/react-native/pull/27539 is merged in. wdyt?

We have product teams at FB using Detox to test against master. Unfortunately this is currently broken because of the timer refactor. While an event based API might be architecturally best, it will take longer to make happen as @ejanzer doesn’t have the bandwidth to work on it.
I’d like for us to move forward if possible with the existing PR to get detox working as quickly as possible against 0.62 so we can reenable our product team’s tests. Any support we could get to do so would be greatly appreciated.

@TheSavior I'd be more than happy to move forward -- I wasn't suggesting to wait for the rearchitecture, just basically asking whether we could wait for https://github.com/facebook/react-native/pull/27539 to be merged in so as to avoid reimplementing this twice.

Well as https://github.com/facebook/react-native/pull/27539 has been merged, I'll switch to using the newly interrogation timers API by @ejanzer. Cool with everyone?

Yep, that's what I meant. Moving forward with the new API seems like a good idea

consider it done


How to debug every step in compiled so

❓ General Questions
Background: I want to add hexagon backend support for mlc -llm but I'm running into a problem. When I converted out the model and successfully built llm.hexagon.so and I successfully loaded so via load module . When I started executing prefill func for the first time, my code returned an error at the location of the yellow box in Picture 1, but there was no error message. It only tells me that the program dies when it runs to a certain operator. I got it by printing in c_runtime_api.cc. All the data sent to prefill can be printed normally.
Question: My question is how do I add some print log near the code in the red box in picture 2

You may use set_instrument in RelaxVM.

More documentation for RelaxVM instrument: https://github.com/apache/tvm/blob/unity/python/tvm/runtime/relax_vm.py#L342


hey

Title: syntax error
Body:when i run it it says syntax error -1
Problem:

Steps to Reproduce:
List out the steps you took to come upon the error.
config.json:
Most of the problems arise due to badly edited config.json. Hence post the contents of it within codeblocks. (Select the contents here and press code button on top.)
Traceback and Screenshots:
Paste the Traceback/Error here using codeblocks.
Post relevant screenshots.
Specs.
OS:
Bot Version:
Python Version:

help

You need Python 3.6, not Python 3.7.
Also, do not run the bot as admin.
Re-run setup.bat after you change your python version.


Turn off Colors' svg display of color matrices (fixes #548)

This should fix the last part of #548. CC @tlnagy.

Coverage increased (+0.05%) to 78.718% when pulling 7769d0b380554784ce0d762d8fa3ff2edaa50918 on teh/writemime_matrix2 into e843952ee215cc618fa7d59e175c7915903fcbde on master.


Store Image Presentation

Images continually collapse when adding Flexdirection set to  column, rather than remaining in a row when the window size is large enough to accommodate for it.

Added @media code that would cause the change to happen when the screen width was below 1200 pixels, additionally, changed the flex code to be in a column/row style.


add gicv3 feature check before use

Why: gic driver requires system register support,
it would be safe to check before use
How: add feature check before using
Notes: it might be able put feature read together
incase read sysreg multiple times
Signed-off-by: Cao Jianlong<EMAIL_ADDRESS>

@JianlongCao thanks for the PR and sorry for the huge delay in looking at this.
The check you are adding makes sense, but I'm curious on what you motivation for it was. Are you running bao on a platform that does not support sysreg access to the GIC interface?

The gicv3 driver is also used in aarch32 based systems, but since the sysreg you are checking does not exist for this architecture compiling for it fails (e.g. compiling with PLATFORM=fvp-r). This needs to be fixed.

How should we go about doing this?
I see two approaches:
1- Define architecture specific code e.g., arch_gicc_cpu_has_gicv. For aarch32 we would simply return false.
2- Add pre-processor macros and conditionally compile this check based on the architecture.

@JianlongCao thanks for the PR and sorry for the huge delay in looking at this.
The check you are adding makes sense, but I'm curious on what you motivation for it was. Are you running bao on a platform that does not support sysreg access to the GIC interface?

Apologies for the delayed response. I am considering adding this feature primarily from a functional safety perspective. In similar scenarios, we have added safety mechanisms in the past, although in reality, I have not encountered such a fault scenario.

I think it is ok to merge this. It performs a sanity check that is useful when porting to new platforms, and it is not in any critical path. Agree @DavidMCerdeira?
@JianlongCao I'd just ask you to merge the full PR in a single commit with a message following the conventional commits structure.

@JianlongCao sorry for being pedantic here, but the commit message it is still not in conventional commit form and we do plan to start following this and add CI pipeline checks. May I suggest: "feat(armv8/gicv3): add feature check before use"

Looks good to me!
One note regarding your commit message, could you please write this more clearly: "it might be able put feature read together incase read sysreg multiple times". Honestly, I'm not sure I understand what you mean.

Looks good to me!
One note regarding your commit message, could you please write this more clearly: "it might be able put feature read together incase read sysreg multiple times". Honestly, I'm not sure I understand what you mean.

Explain to the notes: To create a function in init to check all the arm features available and use a feature flag array for furthur component init.
I have deleted the notes, maybe dont have to put it in commit msg.

This is also not compiling for aarch32 platforms.

@JianlongCao I'm closing this PR due to inactivity. Please let me know if you want to proceed and I'll re-open it.


Allow QR code text using carriage return (\r) line ending

The Swiss Implementation Guidelines for the QR-bill explicitly forbids CR as line ending:

All data elements must be present. If the data element has no content, at least a new line must be present (CR + LF or LF, but not CR alone)

But some QR-bills were found in practice using CR as line ending. ¯_(ツ)_/¯

Thanks for the PR. I will look into it.
Do you have more information about the QR bills with CR only? Where did come from? Did they contain other errors?