[FancyZones] Editor multi monitor support

Summary of the Pull Request
Multi-monitor support.
PR Checklist

[x] Applies to #6435
[x] CLA signed. If not, go over here and sign the CLA
[x] Tests added/passed

Info on Pull Request
Layout and layout settings could be selected for each monitor. Any change would be saved after clicking Apply. For now, the Apply button doesn't close the editor window.
On the active monitor selection, layout and settings are shown accordingly to the monitor (except switching Templates and Custom tabs)

Displays are presented with their relative dimensions.

Validation Steps Performed
Use the editor with different desktops configurations.
Verify:

settings were saved properly for each desktop.
zones are placed properly for each desktop

in the editor preview
while editing
after being applied

grid and canvas editors don't crash.
template settings (Zone count, Show space around zones, Space around zones) are saved individually for each desktop and those values are changed on the desktop switch in the editor.

Awesome work. Thanks

Great idea and work. 👍
One question:
I am not sure if it is possible to span zones over multiple monitors at the moment. But if so, van the user also select both monitors at the same time?

I am not sure if it is possible to span zones over multiple monitors at the moment. But if so, van the user also select both monitors at the same time?
How does it behave with Virtual Desktop?

Thanks!
In the current implementation, it's not possible to select both monitors at the same time. Spanning zones overs monitors is possible if you use the Allow zones to span across monitors option.
Regarding VD, the temp file with layouts data using by the editor contains layouts only for active VD. This way you can open the editor on any VD and see corresponding data.

@htcfreek

I am not sure if it is possible to span zones over multiple monitors at the moment. But if so, van the user also select both monitors at the same time?

If Allow zones to span across monitors is on, only one monitor will be available and it will allow to create zones that span across monitors.
We will not implement a feature that will allow to select multiple monitors in the editor.

How does it behave with Virtual Desktop?

As @SeraphimaZ said, nothing changes compared to the current behavior. If you want to edit the layout for a VD, first switch to that VD and then open the FZ editor.

/azp run

can't wait to try this out :)

On a system with two monitors, put a 6-zone grid layout on one monitor and a 8-zone grid layout on the other, then switch between the two monitors a few times. The displayed preview will get mixed up.

On a system with two monitors, put a 6-zone grid layout on one monitor and a 8-zone grid layout on the other, then switch between the two monitors a few times. The displayed preview will get mixed up.

fixed

When using 100% scaling on the left monitor and 125% scaling on the right monitor, zone layouts are not shown where they're supposed to, they're shifted to the left, partially covering the left monitor.

The number 2 is clipped

When using 100% scaling on the left monitor and 125% scaling on the right monitor, zone layouts are not shown where they're supposed to, they're shifted to the left, partially covering the left monitor.

fixed

@SeraphimaZ @ivan100sic
the UI glitches regarding the "selected desktop" graphics can be fixed later and not block this PR.
There are other changes I would like to make to it, like relative position and DPI scaling, right now the DPI is not taken into account and the monitor is not scaled and also the resolution is always the native resolution.

I open the editor on the primary monitor (in my case monitor n. 2)
I switch to external monitor 4K with 150% DPI (monitor n. 1)
The current layout is priority  grid with 4 zones and it's shifted has you can see in screenshot

When using 100% scaling on the left monitor and 125% scaling on the right monitor, zone layouts are not shown where they're supposed to, they're shifted to the left, partially covering the left monitor.

fixed

I ran git clean and then built the entire solution, but I still have this problem.

I deleted my previous comment because it was not accurate.

Reposting the problem. It happens when opening the editor on the primary monitor (the one on the right) and then switching to the 4K.
If both monitors are at 100% DPI everything works.
When I set the 4K monitor to 150%, or any other scaling factor > 100%, after I switch to the 4K monitor, the zones are shifted.

But if the primary monitor has also a scaling factor at 125%, and 4K is at 125% or 150%, it works. Not if the primary monitor is at 125% and the 4K at 200%.
So there is a strange relation between scaling factors.

Same scenario as before, two monitors left one 100% scaling, right one 125% scaling.
When previewing e.g. the Grid zone layout on the left monitor, it's 20 pixels (half of taskbar height) towards the bottom.
When editing a custom zone layout on the second monitor, the zones can go off-screen to the bottom and to the right.
When editing a grid layout, after clicking cancel, the main window is gone but the zones are still shown and you have to quit using (Alt+F4)

/azp run

I believe that the spelling errors listed above are fixed in master and will disappear when you rebase.

Spelling - I'll create an issue for:

hmon
IMonitor
scrollviewer
VDId

@SeraphimaZ: great, to make the bot happy for the last bit, you'll either want to run the command inside the To accept these changes (if you have Perl), or if not, just add those 4 items to https://github.com/SeraphimaZ/PowerToys/blob/fz_editor/.github/actions/spell-check/expect.txt
(Personally, I amend commits instead of adding new commits for things like this -- especially the spelling fixes, but I'm not sure about this repo's approach.)
And thanks for bearing with us, this project only got this action a few days ago, so they're still getting used to it.

New misspellings found, please review:

hmon
IMonitor
netcore
scrollviewer
VDId

These have been already added to master, a rebase is enough to fix the warning.


Switch to using Quinoa for UI backend, rather than Node.js + express

Resolves #87.
Here's what I've done:
Code changes (the easy part!)

Replaced node.js express app server with Quarkus app server
Set up pom.xml for Quinoa
Moved Angular app to location Quinoa expects
Converted logic for serving environment variables from node.js to Java
Removed express dependency from package.json

Testing

Tested locally with quarkus dev
Tested locally with mvn package and java -jar target/quarkus-app/quarkus-run.jar
Tested locally with mvn package -Pnative and ./target/ui-super-heroes-1.0-runner … the front end starts in 27 ms on my machine, which is pretty awesome
Tested locally with docker-compose -f deploy/docker-compose/app.yml up, although that gives me the old image which is still using node.js, so doesn’t tell me much

Deployment and automation

Removed custom docker files and replaced them with standard Quarkus ones
Added  Quarkus Kubernetes extensions into the UI pom.xml
Removed the special casing for UI projects in generate-k8s-resources
Removed the special UI build steps from the GitHub workflows and added the ui project to the matrix builds. (The same matrix seems to be repeated three times, so I wonder if it should be common?)
Updated app.openshift.io/runtime: nodejs to specify quarkus in all the Kubernetes .ymls, but I wasn’t sure how to test this

Documentation

Updated readme (including architecture diagrams)
Updated the azure instructions for running the UI app locally
Updated automation documentation to remove special-casing of UI app. I hand-updated a diagram with a workflow screencap but we might want to regenerate it when this is merged and the workflows are running.

In both the k8s script and the automation docs we list out each project individually, to be able to exclude the UI project. That’s not needed anymore, so we may want to do some *-ing or “all” in the text, but I didn’t make those changes. We may also spot some other simplifications that come from having a homeogenous stack across all projects.
I’m not totally sure I have the instructions for Azure Static Web Apps right, but it’s hard to test. We’re still generating the same static app as we were before. Before it would ask a node.js server for its config, now it asks a Quarkus server for its config, so I’m not sure how either model exactly works with a static deployment.

Thank you @holly-cummins ! I'll take a closer look tomorrow or Friday, but first thing I noticed is that you shouldn't manually change anything in a folder named deploy, whether at the root of the project or inside one of the application folders. Everything in those folders are generated as part of the CI/CD process.

Ah, thanks, @edeandrea. It seemed wrong to leave the wrong values in source control. :)
I assume CI/CD will just overwrite what's there with new content (which would be the same as what I generated), so my changes wouldn't do any harm?

I assume CI/CD will just overwrite what's there with new content (which would be the same as what I generated), so my changes wouldn't do any harm?

Yeah the CI process will essentially do an rm -rf **/deploy/**, regenerate everything, and then commit it back into source control.
Just for future reference - no need to ever touch anything inside any directory named deploy :)
I'll take a closer look at this tomorrow/friday and comment on it.

We could. I tried to make it obvious by having a README file in each directory saying not to manually modify anything in there as it'll be overwritten by the CI process.
Apparently I failed there too :)

Yeah you'd never want to run the build-push-container-images workflow on a fork because of that. It requires the token. Really only the simple-build-test (to verify the app is ok), but we don't have a good way of verifying that all the k8s yamls/etc all "look" right unfortunately.

One other thing I noticed that I forgot to mention in the review - you'll need to modify the simple-build-test workflow and add the ui-super-heroes app to both of the matrix jobs.

I spent some time going through all of this and have made some comments in-line.
I also think that the docker compose stuff is missing. See src/main/docker-compose from some of the other apps as well as the scripts/generate-docker-compose-resources.sh. There probably need to be modifications in there as well.

Done!
For another WI, do you think it's possible to reduce the volume of docker compose files? I was a bit perplexed by the relationship between rest-fights/deploy/docker-compose/native.yml and rest-fights/src/main/docker-compose/native.yml, for example. One seems to be generated and the other is hand-maintained? For the UI project they're basically identical, but for others there's overlap, but also different content. I couldn't figure out the intention from a search of the readmes. (And a readme probably isn't the right place for that kind of information, because people might not be able to find it mixed in with all the other content, and when they need is when they're looking at the file, trying to understand if it's ok to update or if it's generated.)

Also you should check the scripts/deploy-to-azure-containerapps.sh script and verify nothing needs to change there.

Good point, and done! I think because the externals of the UI container are exactly the same, no changes are needed.

For the docker compose stuff, yes src/main are hand maintained "snippets" whereas in the deploy directory is the "real" docker compose file. It's done this way so that we can have the root /deploy/docker-compose with an uber compose file that had everything from all the apps in it.
It was done that way to try and mimic the kubernetes extension. If we did away with that we'd have to hand craft 2 sets of compose files - 1 individually for each app and 1 uber compose file, both for jvm (and perhaps multiple jvm versions) and native.

For the docker compose stuff, yes src/main are hand maintained "snippets" whereas in the deploy directory is the "real" docker compose file. It's done this way so that we can have the root /deploy/docker-compose with an uber compose file that had everything from all the apps in it.
It was done that way to try and mimic the kubernetes extension. If we did away with that we'd have to hand craft 2 sets of compose files - 1 individually for each app and 1 uber compose file, both for jvm (and perhaps multiple jvm versions) and native.

Got it, thanks. I've moved the discussion to https://github.com/quarkusio/quarkus-super-heroes/issues/299.

Ok, I think I've got all the comments. Thanks for spotting the issues, @edeandrea!

Assuming that means you think it's ready for another pass through? :)
Of so, I'll try to get to it later today

Assuming that means you think it's ready for another pass through? :)
Of so, I'll try to get to it later today

Yes please, thank you!

@someth2say FYI once this is merged it's going to have an effect on #291. Should actually make the work you are doing there easier I would think, although you may get some merge conflicts. Please be aware.

I don't think there's any point in getting too focussed on specific versions, is there

Just that the simple-build-test workflow runs against this PR. Not that I expect any failures, but the version update could potentially incorporate a problem which then would cause the main CI to break when this gets merged to main.
But you're right, probably not a big deal in this case.

I don't think there's any point in getting too focussed on specific versions, is there

Just that the simple-build-test workflow runs against this PR. Not that I expect any failures, but the version update could potentially incorporate a problem which then would cause the main CI to break when this gets merged to main.
But you're right, probably not a big deal in this case.

I think if the version of Quarkus in one microservice being a week out of date caused that kind of problem, we would need to go back to the Quarkus team and have a chat about their release testing. :)
Although, actually, I don't think I entirely see the source of risk. If we think the simple-build-test workflow that we run against PRs isn't comprehensive enough to catch some problems, and we think the move from Quarkus 3.0.3 to 3.1.1 is a risk, wouldn't that risk still be there if I updated before merging? Because I'd be merging with Quarkus 3.1.1, but we wouldn't be confident of catching problems with that version? Or would we be assuming I'd be running more comprehensive tests locally with 3.1.1 than the PR workflow runs?
I think I'm missing something about the process and the concern.

I think I'm missing something about the process and the concern.

This particular app has very little (meaning close to 0) tests, whereas all the other apps have quite a big test suite, meaning the simple build test workflow is definitely trustworthy for all the other apps. In the year and a half I've been maintaining this, I've never had an issue where something was green in the PR and then things were broken once merged (in the other apps - I've had it happen with the UI app, which is why I've tried to not touch it with a 10-foot pole :) ). Hopefully #290 will help there.

I think I'm missing something about the process and the concern.

This particular app has very little (meaning close to 0) tests, whereas all the other apps have quite a big test suite, meaning the simple build test workflow is definitely trustworthy for all the other apps. In the year and a half I've been maintaining this, I've never had an issue where something was green in the PR and then things were broken once merged (in the other apps - I've had it happen with the UI app, which is why I've tried to not touch it with a 10-foot pole :) ). Hopefully #290 will help there.

That makes sense. I'm just not convinced that there's much correlation between someone being a human-dependabot and updating a pom.xml before merging and them doing manual testing. :)
As you say, I think the solution is to improve the testing, not to try and do all version updates manually. Even if I updated to Quarkus 3.1.1 before merging, you know 3.1.2 would be along shortly, and then we have the exact same issue - "can we trust a version update if there's not someone to do manual testing of it before merging?"

Ok, I’ve done the next round of changes, except for the following (as discussed above):

Analyse all the readmes and scripts to identify files which are generated, and avoid changing them (#299 should help with that in future)
Monitor dependabot changes in the rest of the codebase and manually mirror them to this PR while the change is in review
Restructure readme to include more instructions about how the quarkus kubernetes extension works

You’re quite right, @edeandrea, there should have been tests for the Java part. As there weren’t any for the old express server, I had kept parity, but we should aim higher.
I’ve also added the Quinoa incantation to run the Javascript tests, should we ever add any (#290). The javascript tests were so missing that npm run test wasn’t even a no op, it actually failed. So I’ve fixed that, although it ended up involving adding a skeleton test and loads of fixes to make the test framework work at all. The application didn’t even have any of the skeletons for testing, and finding an example of an angular test setup that could worked with Angular 12 was a bit arduous. (And, ultimately pointless, since we know we need to move away from Angular 12.) Retrofitting modern examples, of course, does not work. In the end, I got most of the way there but Jasmine insisted there were no test files. I spent about three hours debugging that but it really doesn’t seem like a good use of time, so in the end I just bypassed the actual Javascript test execution, but left the scaffolding I’d got and the Quinoa executor in.
I also spotted an incorrect package in the Java code, so I’ve fixed that.

Thank you very much @holly-cummins! I'll merge once CI has run.

Thanks, @edeandrea!

There were a few things I missed too in my reviews that I realized when I checked out the branch. I just committed them myself to this PR.


Strange behavior with equal

If I use
body.should.be.equal({response: 'ok'});

to test if a response returns the right content, the test fails because it says the result is not identical, but they are. Here is the error:
AssertionError: expected { response: 'ok' } to be { response: 'ok' }
And here the expected
{
  "response": "ok"
}

and the given return value
{
  "response": "ok"
}

Which are obviously the same.

.equal inside it is ===, which of cause will not work for deep comparison. You need to use .eql there which do deep comparison.

@btd Didn't notice that. Many thanks for your help.


Dataset issues

Bug reported here -> https://github.com/CartoDB/cartodb/issues/11855.
Pagination position in Safari browser.
Renaming a table breaks edition until reloaded (https://github.com/CartoDB/cartodb/issues/11969).

We should test that all those things are tested, just follow the issues.

Moving it to acceptance, ok @matallo ?

acceptance straight-away

@xavijam what does "Pagination position in Safari browser." mean?
All the other points in the description were successfully fixed and are accepted.

There was a problem reported in twitter by a user where the pagination was placed over the create map button in the dataset view.

I see, thanks. That seems to work alright too.

\o/

Frontend tests passed with Travis, merging after solved a conflict with master \o/.


chore: refactor alias import and fix go doc

Codecov Report
Attention: 5 lines in your changes are missing coverage. Please review.

Comparison is base (01585ba) 0.00% compared to head (bb44030) 51.79%.

Files
Patch %
Lines

state/helpers.go
0.00%
4 Missing :warning:

state/core_access.go
0.00%
1 Missing :warning:

Additional details and impacted files
@@            Coverage Diff            @@
##           main    #3159       +/-   ##
=========================================
+ Coverage      0   51.79%   +51.79%
=========================================
  Files         0      178      +178
  Lines         0    11286    +11286
=========================================
+ Hits          0     5846     +5846
- Misses        0     4940     +4940
- Partials      0      500      +500

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


Optimize task scheduler

avoid thread busy loop while the number of executing threads reaches the maximum value of the task.
I have read and agree to the terms under CLA.md

Hi @ted-wq-x,
Thanks for your contribution.
Could you please take a look at our CLA and add “I have read and agree to the terms under CLA.md” to your PR description if you agree with the CLA?

done


Place another order

When the order is successful, we should show a link that can clear the form to place another order to the restaurant:
Received order (Confirmation: {{saveStatus.value._id}})

This same thing should happen on the donejs version.

Waiting on #20 before submitting a PR for this.


alertmanager send duplicate alerts

What did you do?
I use a webhook like examples/webhook/echo.go to receive alarm messages from Alertmanager,
I found that whenever a new alarm rule is triggered in Prometheus, prometheus sends a new alert message to the Alertmanager, the Alertmanager will send this alert message to the webhook with all previous unresolved alerts and resolved but not too late to delete alerts.
for example:
First, webhook receive a alert A from Alertmanager. A few minutes later, Alertmanager receive a alert B from Prometheus, but the alert A is unsolved at this time and not until the repeat_interval. At this time in webhook, i will receive two alerts(A and B)
Is this normal or just designed like this? Or my method of use is wrong ？
What did you expect to see?
I just want to get the second (alert B without A)

System information:
Darwin 16.7.0 x86_64

Alertmanager version:
0.15.2

Prometheus version:
2.4.0

Alertmanager configuration file:

global:
  resolve_timeout: 15s
route:
  receiver: 'default'
  group_by: ['alertname']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 3h

receivers:
- name: 'default'
  webhook_configs:
  - send_resolved: true
    url: http://<IP_ADDRESS>:5002/

Prometheus configuration file:

global:
  scrape_interval:     15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
  evaluation_interval: 10s # Evaluate rules every 15 seconds. The default is every 1 minute.
  # scrape_timeout is set to the global default (10s).

alerting:
  alertmanagers:
    - scheme: http
      static_configs:
      - targets: ['localhost:9093']
# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
  - "first_rules.yml"
#  - "second_rules.yml"

# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
  # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
  - job_name: 'prometheus'

    # metrics_path defaults to '/metrics'
    # scheme defaults to 'http'.

    static_configs:
    - targets: ['localhost:9090','<IP_ADDRESS>:9100']
      labels:
        my:  label

I know what‘s your meaning,  but first,  the alert rule A triggered 2 alert,
like this

the webhook will receive
2018/11/29 20:19:36 {
 >  "receiver": "default",
 >  "status": "firing",
 >  "alerts": [
 >    {
 >      "status": "firing",
 >      "labels": {
 >        "alertname": "A",
 >        "instance": "<IP_ADDRESS>:9100",
 >        "job": "prometheus",
 >        "my": "label",
 >        "severity": "1"
 >      },
 >      "annotations": {
 >        "description": "A"
 >      },
 >      "startsAt": "2018-11-29T20:19:05.984936892+08:00",
 >      "endsAt": "2018-11-29T20:22:05.984936892+08:00",
 >      "generatorURL": ""
 >    },
 >    {
 >      "status": "firing",
 >      "labels": {
 >        "alertname": "A",
 >        "instance": "localhost:9090",
 >        "job": "prometheus",
 >        "my": "label",
 >        "severity": "1"
 >      },
 >      "annotations": {
 >        "description": "A"
 >      },
 >      "startsAt": "2018-11-29T20:19:05.984936892+08:00",
 >      "endsAt": "2018-11-29T20:22:05.984936892+08:00",
 >      "generatorURL": ""
 >    }
 >  ],
 >  "groupLabels": {
 >    "alertname": "A"
 >  },
 >  "commonLabels": {
 >    "alertname": "A",
 >    "job": "prometheus",
 >    "my": "label",
 >    "severity": "1"
 >  },
 >  "commonAnnotations": {
 >    "description": "A"
 >  },
 >  "externalURL": "",
 >  "version": "4",
 >  "groupKey": "{}:{alertname=\"A\"}"
 >}

a few minute later, the alert rule A triggered 3 alert, like this

the webhook will receive
2018/11/29 20:24:36 {
 >  "receiver": "default",
 >  "status": "firing",
 >  "alerts": [
 >    {
 >      "status": "firing",
 >      "labels": {
 >        "alertname": "A",
 >        "instance": "<IP_ADDRESS>:9093",
 >        "job": "prometheus",
 >        "my": "label",
 >        "severity": "1"
 >      },
 >      "annotations": {
 >        "description": "A"
 >      },
 >      "startsAt": "2018-11-29T20:23:55.984936892+08:00",
 >      "endsAt": "2018-11-29T20:26:55.984936892+08:00",
 >      "generatorURL": ""
 >    },
 >    {
 >      "status": "firing",
 >      "labels": {
 >        "alertname": "A",
 >        "instance": "<IP_ADDRESS>:9100",
 >        "job": "prometheus",
 >        "my": "label",
 >        "severity": "1"
 >      },
 >      "annotations": {
 >        "description": "A"
 >      },
 >      "startsAt": "2018-11-29T20:19:05.984936892+08:00",
 >      "endsAt": "2018-11-29T20:26:45.984936892+08:00",
 >      "generatorURL": ""
 >    },
 >    {
 >      "status": "firing",
 >      "labels": {
 >        "alertname": "A",
 >        "instance": "localhost:9090",
 >        "job": "prometheus",
 >        "my": "label",
 >        "severity": "1"
 >      },
 >      "annotations": {
 >        "description": "A"
 >      },
 >      "startsAt": "2018-11-29T20:19:05.984936892+08:00",
 >      "endsAt": "2018-11-29T20:26:45.984936892+08:00",
 >      "generatorURL": ""
 >    }
 >  ],
 >  "groupLabels": {
 >    "alertname": "A"
 >  },
 >  "commonLabels": {
 >    "alertname": "A",
 >    "job": "prometheus",
 >    "my": "label",
 >    "severity": "1"
 >  },
 >  "commonAnnotations": {
 >    "description": "A"
 >  },
 >  "externalURL": "",
 >  "version": "4",
 >  "groupKey": "{}:{alertname=\"A\"}"
 >}

For the second time, i just want to get one that the third alert (its instance is <IP_ADDRESS>:9093)  instead of all the firing status  alerts of this group

The design of alertmanager is to send all alerts in a group. If you want to just receive the third alert, you need to update your group_by labels to an additional label. For example, if you did [ alertname, instance ], then the notifications would in this example would have been sent individually.

Oh thanks, i see. Can you tell me what the purpose of this design is for?

The correct place for this discussion isn't in a github issue. I recommend asking in the irc channel, the users mailing list.


Fix/avoid measurement errors due to coordinated omission [JIRA: TOOLS-114]

See also: https://github.com/brianfrankcooper/YCSB/pull/214 (though that branch appears to be merged into the https://github.com/YCSB/YCSB repo now, despite the status of that ticket)?
It would be awfully nice if we could have basho_bench avoid measurements due to coordinated omission.  Gil Tene and others have been very helpful in pointing out this problem in many tools. YCSB has recently fixed it; b_b should do so also.

This issue is still on the todo list. No estimate for implementation time, however.  PRs are welcome.  ^_^


Merge mbed-crypto stragglers 2020-03-25

Merge content that was merged to mbed-crypto after it got merged back into mbedtls.

https://github.com/ARMmbed/mbed-crypto/pull/377
https://github.com/ARMmbed/mbed-crypto/pull/392 (discarded during the merge as irrelevant)
https://github.com/ARMmbed/mbed-crypto/pull/300 — introduces assemble_changelog.py and ChangeLog.md, but these files are not yet in service.

Note to reviewers: this is a merge of a merge. You can assume that everything that has already been merged to https://github.com/ARMmbed/mbed-crypto/tree/development is good (for Mbed Crypto).
None of these require an update to ChangeLog.

CI is passing everything except the mbed-os tests which are a known issue independent from this PR.


Upgrade to importlib and pyproject.toml

Hi @goto40. There have been recent reports about setuptools pkg_resources API deprecation and complete removal from Python 3.12. This PR started as a work on migrating to importlib.metadata but I took an opportunity to do some other cleanups I've planed to do for the next release which will be mostly maintenance.
Arpeggio is upgraded accordingly to CI to pass but the release of Arpeggio will have to wait as there are some important rework to be done for the next release. Nevertheless, we could release textX as these changes work with the current release of Arpeggio.
Here is an excerpt from the CHANGELOG of what is done in this PR:

(BIC) Removed Python support for 3.6 and 3.7. The minimal supported version is 3.8.
Migrated to pyproject.toml for project configuration.
Migrated to importlib for language/generator registration/discovery as
setuptools pkg_resources is deprecated and unsupported from Python 3.12. See
#411.
Use ruff instead of flake8 for linting. ruff can also be used for code
formating.
Relaxed dependency for click to accept 8.x. See #414.
Use flit for package building and publishing.

found __future__ in

examples/Entity/entity_test.py
tests/perf/test_speed.py

--> remove?

I found that in august we had 338 tests (https://github.com/textX/textX/actions/runs/5923292736/job/16058653693), now we have 339 tests (https://github.com/textX/textX/actions/runs/6812715815/job/18525682009?pr=416) for python 3.10.
So you added one test?

@igordejanovic : I am not yet finished.... Give me this evening,,,

My overall impression is ok! Good work, @igordejanovic.
I appreciate the automated formatting support we get with the new tool!
I thing we have a good unittest coverage and, thus, I do not see any problems with such large scale refactorings/reformatting.
Good work!

Excellent. We are good to go then. I did some tidying of the changelog and will be releasing the new major version during the day. This will be a maintenance release so there is really no changes for folks who are using Python 3.8+.


sideEffects: false leads to different modules order between dev & prod

Moved from https://github.com/webpack-contrib/mini-css-extract-plugin/issues/501

Operating System: Mac OS Catalina
Node Version: 12.15.0
NPM Version: 6.13.4
webpack Version: 4.41.4
mini-css-extract-plugin Version: 0.9.0

Expected Behavior
Rules order is consistent between development and production
Actual Behavior
Rule order is defined by imports order in development, and by usage order in production
Code / How Do We Reproduce?
https://github.com/Hypnosphi/style-loader-duplicates/tree/mcep
Note that I import a before b, but use b before a. This leads to text being red in dev and blue in prod
import {a} from './a.css'
import {b} from './b.css'

document.body.innerHTML = `<div class="${b} ${a}">Text</div>`

It also reproduces if I use style-loader instead of mini-css-extract-plugin

Probably a duplicate of https://github.com/webpack/webpack/issues/7094


Why is there gmsh AND python-gmsh?

Hello,
Thanks for providing the Python API for Gmsh on conda-forge!
It was quite confusing to me however, that the conda package gmsh doesn't install the Python module gmsh.py directly. I was therefore using pip install gmsh inside my conda env for quite a long time, before finally finding out about this feedstock (also because I didn't know about feedstocks ect...).
What is the reason for providing Gmsh on conda-forge in two separate packages?
Joost

Because there are people who don't need the python API and the dependencies it pulls in.

Thanks for the reply!
Christophe Geuzaine from Gmsh was quite surprised to learn that Gmsh is on conda-forge:
https://gitlab.onelab.info/gmsh/gmsh/-/issues/870
Would it be an idea to provide a link on the gmsh anaconda cloud page to this feedstock, or make it more obvious in another way that conda install gmsh does not provide the gmsh Python API?

Maybe you can add a sentence to the summary at https://github.com/conda-forge/gmsh-feedstock/blob/master/recipe/meta.yaml#L91
Can you make that change and send a PR?

Sure!


Links is not working

THe link to referens dokument is not working. Also it would be good if you could document how long it will take for this policy to be applied to a targeted user. 1h-72h (what MS always refer to as "normal") is not really enough to be doing a fault analysis with end user.
/Markus

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

ID: 3d630c7f-0b0b-1699-c5cb-b1787dda521e
Version Independent ID: 06f74bc0-0863-b2f9-3cc8-48e8df6822b8
Content: Grant-CsTeamsMediaLoggingPolicy (MicrosoftTeamsPowerShell)
Content Source: teams/teams-ps/teams/Grant-CsTeamsMediaLoggingPolicy.md
Service: teams-powershell
GitHub Login: @LeoKuhorev
Microsoft Alias: leokukharau

Link was fixed in https://github.com/MicrosoftDocs/office-docs-powershell/pull/9744
I'll pass the feedback about replication times.


ExchangeWithDialer does not exist anymore

ExchangeWithDialer is in the godoc, but its not valid.  This changes it to the appropriate client dialer setting and c.Exchange call.

Codecov Report

Merging #666 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master   #666   +/-   ##
=====================================
  Coverage      58%    58%
=====================================
  Files          37     37
  Lines        9996   9996
=====================================
  Hits         5798   5798
  Misses       3148   3148
  Partials     1050   1050

Continue to review full report at Codecov.

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

thanks!


Very slow startup on Arch Linux

Actual behavior (Required!)
vim-javacomplete2 takes forever (as in >1min) to load.
The steps to reproduce actual behavior (Required!)
~/.../vim-javacomplete2/libs$ time java -cp javavi/target/classes:javavi_log4j-api.jar:javavi_log4j-core.jar:javaparser.jar kg.ash.javavi -version
<IP_ADDRESS>
real    1m0.999s
user    0m0.833s
sys     0m0.183s

I also tried to profile:
FUNCTIONS SORTED ON TOTAL TIME
count  total (s)   self (s)  function
    1  60.854183   0.000117  javacomplete#Start()
    1  60.853499   0.014835  javacomplete#server#Start()
    1  60.745097   0.000098  <SNR>69_GetServerAppVersion()
    1   0.347102   0.339290  javacomplete#server#Terminate()
    1   0.092862   0.001741  javacomplete#server#GetClassPath()
    1   0.089188   0.000119  <SNR>69_System()
    8   0.004287   0.004231  javacomplete#util#GlobPathList()
    2   0.003857   0.000057  <SNR>69_GetJavaviClassPath()
    1   0.003097   0.000309  <SNR>13_SynSet()
[..]

fyi I had to compile javavi manually with mvn -f ~/.vim/plugged/vim-javacomplete2/libs/javavi compile.
This may be similar to #309
Environment (Required!)

OS: Arch Linux (current)
Vim version: 8.0.586
jdk8-openjdk 8.u121-1

Q&A

Yes, I tried minimal .vimrc configuraion.
Yes, I have enabled logs with JCdebugEnableLogs and can put here content of JCdebugGetLogContent command, if you need.
Even, if you wish, I can set g:JavaComplete_JavaviDebug to 1, than set g:JavaComplete_JavaviLogfileDirectory, and put here server logs, too.

@laktak another Arch Linux user here. Have you tried using Oracle's JDK? I don't believe I'm experiencing any slowness here while using it but when I get the opportunity I'll do some profiling to make sure

@DonnieWest how did you install the Oracle JDK? I uninstalled the openjdk and ran sudo apacman -S jdk
$ java -version
java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)

But the issue still persists.

 I don't have regular VIM installed, so, it's possible that there's some sort of regression in the latest version of VIM? Would you mind trying the latest version of Neovim to see if that's the case?

Thanks, I can try neovim when I get back.
But wouldn't javavi taking a minute to display it's version information indicate some problem with the java part/outside of vim?

Still cannot reproduce such a big startup time. I'm on OpenSuse, tried with openjdk and oracle jdk. Everytime I have 1 and half of second.

I think I get same issue, I will try to find a easy way to reproduce it.

If it helps, I've captured an strace with strace -o xtrace -ff -tt -T java -cp javavi/target/classes:javavi_log4j-api.jar:javavi_log4j-core.jar:javaparser.j ar kg.ash.javavi.Javavi -version
trace.tar.gz

@laktak , by your traces, there some DBUS stuff are eating most of the start up time. Any thoughts?

After clearing ~/.m2/repository (and ~/.gradle/caches) the delay is gone:
$ time java -cp javavi/target/classes:javavi_log4j-api.jar:javavi_log4j-core.jar:javaparser.jar kg.ash.javavi.Javavi
 -version
<IP_ADDRESS>
real    0m0.533s
user    0m0.847s
sys     0m0.160s

No idea what was happening there of if it's worth investigating further.
@wsdjeg could you check if this works for you as well (and keep a backup)?

@artur-shaik see my previous comment. On my system it now works without problems from Vim. Thanks!

But why this directories block pure java call? I just can't see.

Sorry no idea. But removing them was the only thing I did to get it working. If it comes up again and I can reproduce it I'll let you know.

Ok, let's close it for now. Reopen for demand.


Hides ShellOut implementation in iOS target

As mentioned in #45, if a target in your workspace directly or indirectly depends on ShellOut and you try to build the SwiftUI preview target, the compilation fails as Process is not available on iOS. Swift Package Manager does currently not supported limiting on which platforms a package can be built. This PR hides the ShellOut implementation using # if os(macOS) || os(Linux) in the iOS target so that its build succeeds.

Ping @JohnSundell. As the issue is blocking us from using the SwiftUI canvas, it would be nice to get this change public asap. :)

@ohitsdaniel: if one of your third party dependencies can end up blocking you from doing your work, then I would strongly suggest that you re-evaluate the way you do dependency management. That doesn't sound sustainable. To unblock yourself, you could, for instance, fork ShellOut and apply this fix on your fork, and then point your project to that fork instead (until a proper fix has been developed and merge into this repo).
As for this PR, I'm not going to accept a change that wraps the entire library in an #if directive. I think we'll be able to use SwiftPM's new platform attribute to solve this, but I haven't had time to work on this yet. I'll get to it as quickly as I can, and no amount of "pinging" is going to change that.

Hey John,
thanks for responding to this PR. First of all, I wanted to apologise if "pinging" you made you feel pressured to act or insulted you in any way. That was definitely not my intention.
Regarding your feedback concerning our dependency management, I guess my wording was a bit off and I would like to clarify some things: ShellOut is a transitive dependency of one of our testing tools (SwiftyMocky). This issue is not blocking us as we're using forks (just as you suggested), however it creates the overhead of maintaining two additional repositories. Resolving this situation would be nice, but I absolutely understand that this is none of your concern and absolutely not your responsibility. Thanks for the constructive feedback and suggesting a solution! 🙂
Regarding the actual content of this PR. When I ran into this issue, I had the same assumption that the newly introduced platforms attribute in the package definition could solve this issue as I assumed that we can list all supported platforms and exclude unsupported ones. This unfortunately is not the case and the platforms array is currently only used to set custom minimum deployment targets for specific platforms. SPM packages assume to support all platforms using a predefined minimum deployment target. Leaving out a certain platform in the platforms array is basically the same as specifying the default minimum deployment target. This is also stated in the evolution proposal and listed as one of the points that the SPM team is aiming to improve in the future. (See Proposed Solution and Future directions (Especially Platform-specific targets or products and Restricting supported platforms): https://github.com/apple/swift-evolution/blob/master/proposals/0236-package-manager-platform-deployment-settings.md#proposed-solution)
I wholeheartedly agree with you that enclosing the entire library in an #if directive is less than ideal and should be avoided if possible. If you think we should wait for SPM to implement restricting supported platforms, I'm absolutely fine with it and we will continue to use our forks in the meanwhile. If you need any support implementing platform restrictions for this package in the future, feel free to reach out to me as I'm happy to help. 🙂

If you didn't intend to pressure me to act, then why did you ping me like that? 😅
No worries though, I understand that this issue is important to you, it's just that I have to balance this against the continued maintenance of ShellOut itself, as well as all of my other work priorities.
I believe that Swift 5.3 includes new SwiftPM capabilities that would solve this issue (specifically, it'll let packages specify dependencies on a per-platform basis), but again, this is something that I'll need a bit more time to research.

Once again, sorry for the ping. I expected /some/ sign of life either in the issue or in the corresponding PR. Doesn't mean I have to ping you though. I'm aware that you have to balance your priorities. Thanks for looking into this. 👏
Whenever I find the time, I'll look into this and see if we can find a different solution. I did some more research into the new Swift 5.3 SPM features. (Based on the https://www.hackingwithswift.com/articles/218/whats-new-in-swift-5-3 and the SPM project changelog).
There are 4 new SPM features in Swift 5.3:
Package Manager Resources (unrelated), Package Manager Binary Dependencies (unrelated), Package Manager Localized Resources (unrelated), and Conditional target dependencies (somehow related):
https://github.com/apple/swift-evolution/blob/master/proposals/0273-swiftpm-conditional-target-dependencies.md
I checked the proposal for conditional target dependencies and it includes this example Package.swift
import PackageDescription
let package = Package(
    name: "BestPackage",
    dependencies: [
        .package(url: "https://github.com/pureswift/bluetooth", .branch("master")),
        .package(url: "https://github.com/pureswift/bluetoothlinux", .branch("master")),
    ],
    targets: [
        .target(
            name: "BestExecutable",
            dependencies: [
                .product(name: "Bluetooth", condition: .when(platforms: [.macOS])),
                .product(name: "BluetoothLinux", condition: .when(platforms: [.linux])),
                .target(name: "DebugHelpers", condition: .when(configuration: .debug)),
            ]
        ),
        .target(name: "DebugHelpers")
     ]
)

The implemented change only affects which targets are built and linked against each other during compilation. In our source code we will still have to add checks for  #if os(macOS)  / #if canImport(Bluetooth) around any platform-specific code. Currently, there is no way to define that a product (i.e. the produced library) can only be consumed on a set of platforms. People could still define .product(name: "BluetoothLinux", condition: .when(platforms: [.macOS])) as a dependency even though it's not meant to be consumed in a macOS target.
Consumers could use  .product(name: "ShellOut", condition: .when(platforms: [.macOS, .linux])), to not build and link ShellOut when building the target for iOS. However, this would mean that consumers would have to enclose the ShellOut imports and usages in their code in #if canImport(ShellOut) or #if os(macOS) || os(Linux). Ideally, they would already do this, but putting the responsibility on the consumers of the library also doesn't feel right to me (just a feeling, very opinionated here).
I won't say that we should encourage misuse of libraries, but as SPM does not enable us to shield us from it, I guess package authors can do two things: make all their packages work on all platforms or make sure that their packages build on all platforms without offering the complete feature set / API.

FYI: Xcode 12 fixes the behaviour that led to the underlying problem in previews. Therefore, this PR is no longer necessary. Seems like you knew something I didn't. :)


Allow filtering of ActiveStateKey and InactiveStateKey by module_instance_id

Today, ActiveStateKey and InactiveStateKey do not contain the module_instance_id
#[derive(Debug)]
pub struct ActiveStateKey {
    // TODO: remove redundant operation id from state trait
    pub operation_id: OperationId,
    pub state: DynState,
}

For client state machine migrations, this makes it difficult to determine which state corresponds to which module. To get around this, we need to delete all states for every module when doing a client state machine migration, which is dangerous and not ideal. This should contain the module_instance_id so that we're able to query and delete states for a specific module.

To get around this, we need to delete all states

DynState has a .module_instance_id so you should only need to query all, but not delete all. @m1sterc001guy
Though yeah, ideally we would like just to query ones we need. Though we might need to have another index for it, if querying by operation_id is important?
We might need to calculate a hash of encoding of DynState to be a DynStateId, then have:
DynStateId -> DynState, DynStateMeta
module_instance_id, DynStateId -> ()
operation_id, DynStateId -> ()

In practice the DynStateId might be often longer than DynState itself, but it's hard to tell. :D
Ping @elsirion for feedback.

DynState has a .module_instance_id so you should only need to query all, but not delete all.

Ah right, I will fix this in https://github.com/fedimint/fedimint/pull/4282 since I'm currently deleting all states.

Long term I'd like to identify state machine states by a StateId consisting of: <OperationID> <StateMachineID> <StateIndex> where

OperationID keeps its current meaning
StateMachineID is an integer that is incremented for each state machine spawned as part of the operation
StateIndex is an integer incremented on each state transition of a given state machine.

The active-ness of a state would be tracked in a separate index that keeps all active states. The schema would look like:
StateId -> State, State Meta
active StateId -> ()           # Only contains active states, so we don't need to include that boolean
<Module Instance> <OperationID> <StateMachineID> -> ()  # Can be used to prefix-search all StateId prefixes belonging to one module instance

Dev call: consider streaming and pruning inactive states.


[ADS] Create NewHandler function, tests, and README (DMX-615)

Added NewHandler basic functionality.  Created readme file.

LGTM


Update version: syvaidya.openstego version 0.8.6

Pull request has been created with WinGet Automation :rocket:
Microsoft Reviewers: codeflow:open?pullrequest=https://github.com/microsoft/winget-pkgs/pull/116672&drop=dogfoodAlpha

This package is a Windows Batch File (.bat) wrapper for a Java (.jar) executable. It appears that a JRE needs to be a dependency:

I tried using Oracle.JavaRuntimeEnvironment, but it conflicts with the machine scope.


Translation of the Error.

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
The error is not translatet. See Picture:

Describe the solution you'd like
A clear and concise description of what you want to happen.
Add the errors in the translation file.

Thank you. I don't know all error descriptions, so i'll add them during developing with your help 😉

Ok cool thanks.
You can tell me where i can update the translation. So i can translate for you.

Added in 0.2.3

Thanks


Feature Request: post a IG story or IGTV

Hi!
It would be great if there was a way to share to a IG story or IGTV instead of the IG feed.
Keep up the good work!

Happy to take a PR. I don't use IG myself so I don't even know what IGTV is.


fix(battery_plus): Fix type conversion

Description
When wasm is used, there is a complete distinction between double and int. For this reason, casting a double type to an int type with as will cause a crash in the wasm environment. Fix this problem by changing from as int to toInt().

https://github.com/flutter/flutter/pull/146231
Starting with flutter 3.24, the flutter run --wasm command makes it easy to try out the wasm version of the app at local.
Related Issues

Related https://github.com/fluttercommunity/plus_plugins/pull/3103#issuecomment-2273891732

Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I titled the PR using Conventional Commits.
[x] I did not modify the CHANGELOG.md nor the plugin version in pubspec.yaml files.
[x] All existing and new tests are passing.
[x] The analyzer (flutter analyze) does not report any problems on my PR.

Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?

[ ] Yes, this is a breaking change (please indicate that with a ! in the title as explained in Conventional Commits).
[x] No, this is not a breaking change.

Makes sense!
can you rebase this PR to https://github.com/fluttercommunity/plus_plugins/pull/3103 ?
I'd also prefer if the PR only contained the toInt change and not the other files.
Thanks!

@miquelbeltran
I've finished rebasing and organizing the commits!

Thank you! I will merge this one once #3103 lands

ugh why is closed...

For some reason GH closed this automatically instead of changing the target to main, reopening here https://github.com/fluttercommunity/plus_plugins/pull/3157

No problem! Thanks Marge!


Removed ManagedService from Admin UI backend

The ManagedService interface would cause service restarts on configuration updates. This PR removes said interface and replaces it with osgi annotations.
Resolves #1217.
Your pull request should…

[x] have a concise title
[x] close an accompanying issue if one exists
[x]  be against the correct branch
[x] pass automated tests
[x] have a clean commit history
[ ] have proper commit messages (title and body) for all commits

@Arnei I'm currently looking into how @Modified works for another PR and I think this one might be introducing a bug - if my understanding is correct, @Modified is only called when the configuration changes, but not on startup. If we want to read the config on startup as well, we either need to add @Activate, or call modified() from an existing activate() method.

@Arnei I'm currently looking into how @Modified works for another PR and I think this one might be introducing a bug - if my understanding is correct, @Modified is only called when the configuration changes, but not on startup. If we want to read the config on startup as well, we either need to add @activate, or call modified() from an existing activate() method.

That sounds correct. What places in the code did you find where this causes an issue?

@Arnei I think this might be an issue for AdminUIConfiguration, SeriesEndpoint & OsgiEventEndpoint.

Just tested this for the SeriesEndpoint and it seems you are quite correct, the .cfg is not read on startup as one would expect.

Sorry, it seems I've missed that in my review.
You can add both annotations to one method though:
@Activate
@Modified
public void modified(ComponentContext cc) {


Getting error trying to unbox null

Here is the JSON:
{
    "login": "idaclaire",
     "fullname": null
}

self.fullname = unboxer.unbox("fullname")

Anyone know what to do here?

@vladimircezar What the error you're getting?

Closed due to inactivity, and no actionable information.


Added table sizes. Such as on buttons

https://deploy-preview-31992--twbs-bootstrap.netlify.app/docs/5.0/content/tables/#sizes

Maybe it may be better to set the variables $table-cell-padding-y-lg and $table-cell-padding-x-lg as .75rem

To be honest, I never really needed larger tables anywhere. This is different for the larger buttons, they come in handy in CTA block where you want to emphasize the button.
Thoughts @twbs/team?

Agreed. Smaller makes sense for super dense tables, but I don't see the use case for larger ones just yet. Could be convinced if there's some good examples out there?

Closing per above comment.
Tangent thought we might want to explore later: adding some CSS custom properties to component likes .table for their padding. That way someone could override at the <table> level with ease.
<table class="table" style="--padding: .25rem;"
  ...
</table>

.table {
  --padding: .5rem;
  // ...

  td,
  th {
    padding: var(--padding);
  }
}


Update Border Color of Fancy-Select Trigger

The trigger has to have the same border-color as the fancy-select itself. In order to prevent different colors when changing @btn-default-border-color.

Thanks @screeny05
We're planning to remove this whole fancy select thing with Shopware 5.3. We already merge the changes into 5.3.


UI Spacing Issue in Settings Screen

Issue Number:
Fixes #197
Snapshots:

Thanks for the PR. LGTM 🚀


fix link mfront 4.2 with mgis 2.2 for both win AND linux.

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

@conda-forge-admin, please rerender


integration with pianoteq-pi

Thanks so much Robert for this great script, on a local install on a headless setup on a raspberry pi it works perfectly, however only when I launch the script from a VNC environment.
I am having difficulty though getting it the script to run from startup on a headless boot.
I got Pianoteq 8 working on a raspberry pi 4B with the help of pianoteq-pi. Your script is the perfect complement, as while pianoteq-pi got pianoteq working, I could not change settings on pianoteq without going in through a VNC to open the gui and change instrument.
Your script works perfectly if launched from a VNC environment (with the webapp to port 3000 as intended) however on a headless boot the webapp ports to something completely different and I can't figure out why it won't port to 3000.
This is more of a feature request than an issue, and beyond my limited abilities. It would be amazing if pianoteq-pi and ptq-client-webapp worked together perfectly!
I've also posted this suggestion/feature request on https://github.com/youfou/pianoteq-pi/issues/9
Thanks for your consideration!

Hi,
Thanks for the kind words.
I have not tested the headless setup of the PI in my env.  I'll look into it.  In the mean time can post the output of the command serve -s build while in headless mode.
I am assuming that you tried launching it while connected in SSH right, or you have a script that automate the launch in the background?
As for the integration with the other repo, it would actually be a good idea for those interested.  This is more an enhancement on the other repo pianoteq-pi.  But I wouldn't mind helping in some way.  I'll look at that repo and see if I can post a pull request to have it include this project as well.
Thx
Robert

Yes, pianoteq-pi gave me a script to launch Pianoteq on a headless startup, I then followed your instructions for Option 2 and added info to the startup script to launch the ptq-webapp:
As I mentioned, I can run the script and it launches the webapp on port 3000 from VNC - which means I can use the webapp from my phone, but on headless startup I get the following error message log, pianoteq runs but the webapp goes to port 42253:
 HTTP  02/09/2024 22:44:14 *IP ADDRESS* GET /  HTTP  02/09/2024 22:44:14 *IP ADDRESS* Returned 200 in 229 ms  HTTP  02/09/2024 22:44:14 *IP ADDRESS* GET /static/css/main.5ecd60fb.chunk.css  HTTP  02/09/2024 22:44:14 *IP ADDRESS* GET /static/js/2.81c38672.chunk.js  HTTP  02/09/2024 22:44:14 *IP ADDRESS* GET /static/js/main.0c2630ce.chunk.js  HTTP  02/09/2024 22:44:14 *IP ADDRESS* Returned 200 in 28 ms  HTTP  02/09/2024 22:44:14 *IP ADDRESS* Returned 304 in 30 ms  HTTP  02/09/2024 22:44:14 *IP ADDRESS* Returned 304 in 27 ms  HTTP  02/09/2024 22:44:14 *IP ADDRESS* GET /assets/midi.png  HTTP  02/09/2024 22:44:14 *IP ADDRESS* GET /assets/metronome-tick.png  HTTP  02/09/2024 22:44:14 *IP ADDRESS* Returned 200 in 14 ms  HTTP  02/09/2024 22:44:14 *IP ADDRESS* Returned 200 in 11 ms  HTTP  02/09/2024 22:44:14 *IP ADDRESS* GET /manifest.json  HTTP  02/09/2024 22:44:14 *IP ADDRESS* Returned 304 in 8 ms 2024-09-02 22:44:26 - Attempting to launch ptq webapp 2024-09-02 22:44:26 - Successfully changed to ptq-client-webapp directory  INFO  Accepting connections at http://localhost:42253

Here's the adapted start.sh script that runs on headless startup...
#!/usr/bin/env bash

set -e  # Exit immediately if a command exits with a non-zero status.

exec_path="/home/pianoteq/Pianoteq 8 STAGE/arm-64bit/Pianoteq 8 STAGE"
base_args="--serve <IP_ADDRESS>:8081 --multicore max --midimapping"

base_cmd=("${exec_path}" ${base_args})

sudo cpufreq-set -r -g performance || echo "Failed to set CPU frequency to performance mode"

if [ "$#" -eq 0 ] ; then
    # open directly
    sudo systemctl stop pianoteq || echo "Failed to stop pianoteq service"
    "${base_cmd[@]}"
    sudo systemctl start pianoteq || echo "Failed to start pianoteq service"
else
    # run from systemctl
    "${base_cmd[@]}" "$@"
fi

# Set up logging
LOG_FILE="/home/pianoteq/ptq_webapp_startup.log"

log_message() {
    echo "$(date '+%Y-%m-%d %H:%M:%S') - $1" >> "$LOG_FILE"
}

# Source user profile to ensure environment is set correctly
source /home/pianoteq/.bash_profile
source /home/pianoteq/.bashrc

# Launch ptq webapp
log_message "Attempting to launch ptq webapp"

# Change to parent directory
if ! cd ..; then
    log_message "Error: Failed to change to parent directory"
    exit 1
fi

# Change to ptq-client-webapp directory
if ! cd ptq-client-webapp; then
    log_message "Error: Failed to change to /home/pianoteq/ptq-client-webapp directory"
    exit 1
fi

log_message "Successfully changed to ptq-client-webapp directory"

# Check if the port is already in use before starting the server

if sudo lsof -Pi :3000 -sTCP:LISTEN -t >/dev/null ; then
    log_message "Error: Port 3000 is already in use"
    exit 1
fi

sleep 8

# Run npx serve
if ! sudo -u pianoteq npx serve -s build -l > >(tee -a "$LOG_FILE") 2> >(tee -a "$LOG_FILE" >&2); then
    log_message "Error: Failed to run 'sudo npx serve -s build'"
    exit 1
fi

log_message "ptq webapp launched successfully"

Actually I think I messed this up somehow and can't replicate... pianoteq launches with this, but in trying to get it to launch ptq-webapp on startup it no longer launches from the VNC either at present.. obviously I don´t really know what I am doing... I'll wait for wiser minds (yours) to find a solution.... much appreciated!

OK,
An easy test would be to set the port yourself instead of using the default one by npx serve.  So instead of the above command pls change it to the following:
sudo -u pianoteq npx serve -s build -l  -p 8080 > >(tee -a "$LOG_FILE") 2> >(tee -a "$LOG_FILE" >&2)
Change the port number to what ever is available on a headless setup.  Then access the website using the port number you used in the command above.
Let me know how it went.
Robert

Hi Robert,
The script now works on a headless Pi setup after having run the build command... here's the script. It launches Pianoteq 8 on startup and the webapp on port 3000 - so I can now use your webapp from my phone. Thanks so much!
`#!/usr/bin/env bash
Set up logging
LOG_FILE="/home/$USERNAME/ptq_webapp_startup.log"
log_message() {
echo "$(date '+%Y-%m-%d %H:%M:%S') - $1" >> "$LOG_FILE"
}
log_message "Script started with PID: $$"
Trap to handle script termination and clean up background processes
trap 'kill $(jobs -p)' EXIT
Source user profile to ensure environment is set correctly
log_message "Sourcing user profiles"
source /home/$USERNAME/.bash_profile
source /home/$USERNAME/.bashrc
Pianoteq handling
log_message "Setting up Pianoteq"
exec_path="/home/$USERNAME/Pianoteq 8 STAGE/arm-64bit/Pianoteq 8 STAGE"
base_args="--serve <IP_ADDRESS>:8081 --multicore max --midimapping"
base_cmd=("${exec_path}" ${base_args})
log_message "Attempting to set CPU frequency"
if ! sudo cpufreq-set -r -g performance; then
log_message "Failed to set CPU frequency to performance mode"
else
log_message "CPU frequency set to performance mode"
fi
log_message "Checking script arguments"
if [ "$#" -eq 0 ] ; then
log_message "No arguments provided, opening directly"
if ! sudo systemctl stop pianoteq; then
log_message "Failed to stop pianoteq service"
else
log_message "Pianoteq service stopped"
fi
log_message "Launching Pianoteq"
"${base_cmd[@]}" &
log_message "Pianoteq launched in background"
if ! sudo systemctl start pianoteq; then
log_message "Failed to start pianoteq service"
else
log_message "Pianoteq service started"
fi
else
log_message "Arguments provided, running from systemctl"
"${base_cmd[@]}" "$@" &
log_message "Pianoteq launched in background with arguments"
fi
Small delay to allow Pianoteq to initialize
sleep 5
Web app launching
log_message "Attempting to launch ptq webapp"
log_message "Changing to ptq-client-webapp directory"
if ! cd /home/$USERNAME/ptq-client-webapp; then
log_message "Error: Failed to change to /home/$USERNAME/ptq-client-webapp directory"
exit 1
fi
log_message "Successfully changed to ptq-client-webapp directory"
log_message "Checking if port 3000 is in use"
if sudo lsof -Pi :3000 -sTCP:LISTEN -t >/dev/null ; then
log_message "Error: Port 3000 is already in use"
exit 1
fi
log_message "Running npx serve"
if ! sudo -u $USERNAME npx serve -s build -p 3000 &>> "$LOG_FILE"; then
log_message "Error: Failed to run 'sudo -u $USERNAME npx serve -s build -p 3000'"
exit 1
fi
log_message "ptq webapp launched successfully"
`
I also changed the permissions on the script to make it executable..

Something else that would improve the webapp would be the ability to run the reset command, (the command Alt+P   from the GUI)...  as sometimes it freezes, and it doesn't seem possible to be able to reset from the webapp at present...

Hi,
Glad to see that you were successful.  OK, I'll add that feature in the list of todos.
Thx

Hi,
Would you mind pointing to the documentation that mention the "Alt-P" command.  I cannot seem to find it on the Mozart's website.
Thx

Hi Robert,
Here's a little screenshot of the Pianoteq GUI with the note on hover over the reset button.
When I'm running Pianoteq on the Pi headless (on a Raspberry Pi 4B, sometimes it is running stably for a long time, sometimes it crashes. At present the only options I have are to restart, or to enter via VNC open the GUI and press that button. Thanks so much for your work on this!


[#1472] fix(server): Inaccurate flow control leads to Shuffle server OOM when enabling Netty

What changes were proposed in this pull request?
When the shuffle server enables Netty, during the pre-allocation of memory and flushing buffer, we should use the actual used direct memory(which is pinnedDirectMemory in PooledByteBufAllocator) and maxDirectMemory for the if statement, instead of the previous usedMemory and capacity due to #1472.
Changes:

When pre-allocating memory and flushing buffer, use the actual direct memory as the basis for judgment, instead of relying on the previous usedMemory metric.
No need to allocate a new direct ByteBuf in Decoders.decodeShuffleBlockInfo(), we can reuse it using readSlice.
Add two metrics allocated_direct_memory_size and pinned_direct_memory_size. Refer to https://github.com/netty/netty/pull/11667.
Improve the robustness of methods ShuffleDataResult.release() and ShuffleIndexResult.release() to fix occasional IllegalReferenceCountException issues in extremely rare scenarios.
Upgrade Netty to latest stable version: 4.1.106.final (including a lot of bug fixes and an important feature pinnedDirectMemory which is needed in this PR).
Upgrade GRPC to latest stable version: 1.61.1 (including a lot of bug fixes).
Fix #1008. It does not actually test GRPC_NETTY mode, because it uses ShuffleServerGrpcClient everywhere instead of ShuffleServerGrpcNettyClient. (I found this problem when fixing the previous UTs. Setting the shuffle server's tags to GRPC_NETTY,GRPC is useless, because we are not using ShuffleServerGrpcNettyClient at all.)

Why are the changes needed?
For #1472
Detailed explanations：
The actual direct memory usage of a ByteBuf that is going to be sent to a Netty server cannot be obtained in advance due to the dynamic nature of Netty's allocation and deallocation.
We use a pooled ByteBufAllocator by default for performance reasons. When a ByteBuf is allocated, it is drawn from a pool of available memory, and when it is deallocated, it is returned to the pool. The size of the ByteBuf can change dynamically as data is written to or read from it.
Furthermore, the actual memory usage includes not only the capacity of the ByteBuf, but also additional overhead for the ByteBuf object itself and possibly other associated objects. This overhead is not constant and can vary depending on factors such as the JVM implementation, the specific Netty version, the runtime environment, and even the network.
Therefore, it is generally not possible to accurately predict the actual direct memory usage of a ByteBuf in advance.
While we were using it, we discovered that due to Netty's dynamic allocation of direct memory based on page and chunk sizes, the actual direct memory occupied by the shuffle server gradually deviates from usedMemory over time. Consequently, it fails to meet the flush conditions for an extended period, as flushing relies on usedMemory. This results in direct used memory exceeding its limit, which explains why an out-of-direct-memory error is prone to occur under high-pressure and high-concurrency situations. If the pressure is insufficient, the job might be completed before this issue arises.
Does this PR introduce any user-facing change?

In GRPC_NETTY mode, usedMemory will use pinnedDirectMemory.
Default values of rss.server.netty.directMemoryTracker.memoryUsage.updateMetricsIntervalMs and rss.server.netty.directMemoryTracker.memoryUsage.initialFetchDelayMs configurations are decreased to 1s.

How was this patch tested?
Fix #1008 to make it test GRPC_NETTY mode using ShuffleServerGrpcNettyClient.
We conducted stress tests in our production environment and the spark job ran successfully.
Before this PR, the spark job cannot run successfully.

@jerqi @zuston PTAL.

Codecov Report
Attention: 33 lines in your changes are missing coverage. Please review.

Comparison is base (576a925) 54.27% compared to head (dc50ca4) 53.82%.
Report is 8 commits behind head on master.

Files
Patch %
Lines

...he/uniffle/server/buffer/ShuffleBufferManager.java
58.82%
11 Missing and 10 partials :warning:

...a/org/apache/uniffle/common/ShuffleServerInfo.java
0.00%
6 Missing :warning:

...pache/uniffle/server/NettyDirectMemoryTracker.java
50.00%
4 Missing :warning:

...che/uniffle/client/impl/ShuffleReadClientImpl.java
0.00%
0 Missing and 1 partial :warning:

...ava/org/apache/uniffle/common/util/NettyUtils.java
50.00%
1 Missing :warning:

Additional details and impacted files
@@             Coverage Diff              @@
##             master    #1519      +/-   ##
============================================
- Coverage     54.27%   53.82%   -0.45%
+ Complexity     2807     2253     -554
============================================
  Files           427      353      -74
  Lines         24349    15885    -8464
  Branches       2077     1469     -608
============================================
- Hits          13215     8550    -4665
+ Misses        10305     6837    -3468
+ Partials        829      498     -331

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

Maybe we can spit this pull requests to some smaller pull requests. It will be easier to review. Surely, it's good to summit a drat pull request at request to give  reviewers an  overall view.

Maybe we can spit this pull requests to some smaller pull requests. It will be easier to review. Surely, it's good to summit a drat pull request at request to give reviewers an overall view.

Smaller pull requests will be:

Upgrade Netty to latest stable version: 4.1.106.final.
Upgrade GRPC to latest stable version: 1.61.1 (including a lot of bug fixes).
No need to allocate a new direct ByteBuf in Decoders.decodeShuffleBlockInfo(), we can reuse it using readSlice.
Improve the robustness of methods ShuffleDataResult.release() and ShuffleIndexResult.release() to fix occasional IllegalReferenceCountException issues in extremely rare scenarios.
Add two metrics allocated_direct_memory_size and pinned_direct_memory_size.
6.1 and 6.2 should be in one pull request, or else the UTs will fail.
6.1 When pre-allocating memory and flushing buffer, use the actual direct memory as the basis for judgment, instead of relying on the previous usedMemory metric.
6.2 Fix #1008. It does not actually test GRPC_NETTY mode, because it uses ShuffleServerGrpcClient everywhere instead of ShuffleServerGrpcNettyClient.

WDYT? @jerqi

Maybe we can spit this pull requests to some smaller pull requests. It will be easier to review. Surely, it's good to summit a drat pull request at request to give reviewers an overall view.

Smaller pull requests will be:

Upgrade Netty to latest stable version: 4.1.106.final.
Upgrade GRPC to latest stable version: 1.61.1 (including a lot of bug fixes).
No need to allocate a new direct ByteBuf in Decoders.decodeShuffleBlockInfo(), we can reuse it using readSlice.
Improve the robustness of methods ShuffleDataResult.release() and ShuffleIndexResult.release() to fix occasional IllegalReferenceCountException issues in extremely rare scenarios.
Add two metrics allocated_direct_memory_size and pinned_direct_memory_size.
6.1 and 6.2 should be in one pull request, or else the UTs will fail.
6.1 When pre-allocating memory and flushing buffer, use the actual direct memory as the basis for judgment, instead of relying on the previous usedMemory metric.
6.2 Fix #1008. It does not actually test GRPC_NETTY mode, because it uses ShuffleServerGrpcClient everywhere instead of ShuffleServerGrpcNettyClient.

Maybe 1 and 5 can be in one pull request too?
WDYT? @jerqi

1 and 2 can be one pull request, too. 5 five pull requests seems easier to review.

I'll initially submit these three pull requests, and the remaining ones can be submitted once these are merged.
@jerqi

I still don't understand the reason of OOM for this. Could you help explain why the usedMemory can't reflect the real memory used compared with grpc based server? @rickyma

I still don't understand the reason of OOM for this. Could you help explain why the usedMemory can't reflect the real memory used compared with grpc based server? @rickyma

As described in this PR previously, Netty allocates direct memory by pages and chunks.

Furthermore, the actual memory usage includes not only the capacity of the ByteBuf, but also additional overhead for the ByteBuf object itself and possibly other associated objects. This overhead is not constant and can vary depending on factors such as the JVM implementation, the specific Netty version, the runtime environment, and even the network.
Therefore, it is generally not possible to accurately predict the actual direct memory usage of a ByteBuf in advance.

When the concurrent pressure of the shuffle server is not high, the ByteBuf allocated by Netty will be flushed and released in time, and there will be no problem. However, when the concurrent pressure is high, if it has not been flushed in time, the direct memory occupied by all ByteBuf allocated by Netty will be much larger than usedMemory. This is because, for example, the size of NORMAL-sized ByteBuf in PooledByteBufAllocator will be rounded up according to chunks and pages (
In reality, it would be more complicated, but for now, it can be simply understood this way), and each ByteBuf also has additional overhead in the Netty framework internally, causing the actual occupied direct memory size to gradually deviate from usedMemory over time, becoming larger and larger. When an OOM occurs, the value of usedMemory is still very small. When judging pre-allocation, it will still meet the conditions, allowing new sendShuffleDataRequest requests to allocate new memory, but at this time, it still does not meet the flush conditions because whether to flush or not is also determined based on usedMemory.
I don't know if it is clear to you now.
@zuston

the ByteBuf allocated by Netty will be flushed and released in time

Who will release and flush ByteBuf ?

the ByteBuf allocated by Netty will be flushed and released in time

I mean flushSingleBufferIfNecessary and flushIfNecessary in ShuffleBufferManager.

the ByteBuf allocated by Netty will be flushed and released in time

I mean flushSingleBufferIfNecessary and flushIfNecessary in ShuffleBufferManager.

Got you point, so you suspect the bytebuf occupied memory size is not equals to the real used size, right? How about initializing the bytebuf with capacity like: ByteBuf buffer = Unpooled.buffer(1024);

the ByteBuf allocated by Netty will be flushed and released in time

I mean flushSingleBufferIfNecessary and flushIfNecessary in ShuffleBufferManager.

Got you point, so you suspect the bytebuf occupied memory size is not equals to the real used size, right? How about initializing the bytebuf with capacity like: ByteBuf buffer = Unpooled.buffer(1024);

You can't precisely control the size of the ByteBuf received by Netty's channelRead, it may be arbitrarily truncated, and may even be affected by network fluctuations. To give a simple example, you send a 15MB ByteBuf, but due to network issues, the server might first receive a 10MB ByteBuf, and then a 5MB ByteBuf. Assuming the chunkSize is 16MB, it will most likely occupy two 16MB chunks of memory on the server, which is 32MB, and the Netty framework will also use some internal memory overhead, so the final memory usage will be more than 32MB.

the ByteBuf allocated by Netty will be flushed and released in time

I mean flushSingleBufferIfNecessary and flushIfNecessary in ShuffleBufferManager.

Got you point, so you suspect the bytebuf occupied memory size is not equals to the real used size, right? How about initializing the bytebuf with capacity like: ByteBuf buffer = Unpooled.buffer(1024);

You can't precisely control the size of the ByteBuf received by Netty's channelRead, it may be arbitrarily truncated, and may even be affected by network fluctuations. To give a simple example, you send a 15MB ByteBuf, but due to network issues, the server might first receive a 10MB ByteBuf, and then a 5MB ByteBuf. Assuming the chunkSize is 16MB, it will most likely occupy two 16MB chunks of memory on the server, which is 32MB, and the Netty framework will also use some internal memory overhead, so the final memory usage will most likely be more than 32MB.

If so, why not creating a new fixed size bytebuf to fill above composite bytebuf? And the overhead memory occupied exceeded can be reflected to the client side using backpressure?

If so, why not creating a new fixed size bytebuf to fill above composite bytebuf? And the overhead memory occupied exceeded can be reflected to the client side using backpressure?

As I mentioned above, you cannot control the size of the ByteBuf that method channelRead.
When the channelRead method is executed, the ByteBuf has already occupied the direct memory of the shuffle server. At this point, no matter what method you use, this part of the memory will always be occupied. If you want to receive and concatenate them through a CompositeByteBuf, this will lead to problems similar to #1521. You need to create a new direct ByteBuf, and then release the ByteBuf passed in by channelRead.

This means, for a very short time, the direct memory usage is doubled, which is extremely uncontrollable.
And will cause the issue that I mentioned in #1521-comment.

And the overhead memory occupied exceeded can be reflected to the client side using backpressure?

I think backpressure can be implemented in another PR, which would be a further improvement to this issue. The current PR is meant to address the problem of inaccurate usedMemory causing OOM.

Replaced by other pull requests. Close this.


pyodata.exceptions.PyODataParserError: Unsupported Schema namespace - http://schemas.microsoft.com/ado/2007/05/edm

I have error, when i try create client: pyodata.exceptions.PyODataParserError: Unsupported Schema namespace - http://schemas.microsoft.com/ado/2007/05/edm

Hi, thank you for reporting this issue. Have you tried this: https://pyodata.readthedocs.io/en/latest/usage/initialization.html#dealing-with-errors-during-parsing-metadata?

@Mracobes9 please let me know the result.

@mamiksik it helped me. Thanks


Status of full 2.2.0 release

What the current status of the 2.2.0 release track is. v2.2.0rc3 was issued ~25 days ago. Are there issues outstanding that are holding up the final release?
Motivating this question is the release of https://github.com/pydata/xarray/issues/1821 that depends on changes in zarr 2.2.0.
Cheers!
cc @alimanfoo @shoyer @rabernat

There are no outstanding issues, I was just giving it a bit of time. If you
haven't found any issues then I'd be happy to make a full 2.2.0 release.
On Mon, 26 Feb 2018 at 02:25, Joe Hamman<EMAIL_ADDRESS>wrote:

What the current status of the 2.2.0 release track is. v2.2.0rc3 was
issued ~25 days ago. Are there issues outstanding that are holding up the
final release?
Motivating this question is the release of pydata/xarray#1821
https://github.com/pydata/xarray/issues/1821 that depends on changes in
zarr 2.2.0.
Cheers!
cc @alimanfoo https://github.com/alimanfoo @shoyer
https://github.com/shoyer @rabernat https://github.com/rabernat
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/zarr-developers/zarr/issues/242, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAq8QrTqZl2bfhOGeRsBTWbnPH_-31edks5tYhYNgaJpZM4SSly_
.

--
If I do not respond to an email within a few days, please feel free to
resend your email and/or contact me by other means.
Alistair Miles
Head of Epidemiological Informatics
Centre for Genomics and Global Health http://cggh.org
Big Data Institute Building
Old Road Campus
Roosevelt Drive
Oxford
OX3 7LF
United Kingdom
Phone: +44 (0)1865 743596 or +44 (0)7866 541624
Skype: londonbonsaipurple
Email<EMAIL_ADDRESS>Web: http://a http://purl.org/net/alimanlimanfoo.github.io/
Twitter: https://twitter.com/alimanfoo

Thanks @alimanfoo - no issues to report on our end.

Great. @jakirkham are you happy to go for full 2.2.0 release?

I'll make the 2.2.0 release on Monday if no objections.

Sorry for the long turnaround.
Have been using the rc happily for a bit. No issues to report.
We also already added provisios for anything that is still being worked out or is experimental at this stage. So I think we are ok there.
Can't think of anything else that would block the release. Would welcome it personally. :)

Great, thanks @jakirkham.

Closing as this is complete.


feat: add torrent-rename-path support

LGTM 👍 thanks for contributing

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


How to get order ID of order being placed?

How do I get the return data from placing orders?

ThisOrderQuery = auth_client.buy(.....)
print(ThisOrderQuery)

Does it send the order on declaration or print?

print is just showing you what information was received and saved in the variable. If you want to get specific information you can do something like print(ThisOrderQuery['id'])

Ok thanks! This will help me out so much..

Great, I've been using this API for more than a year, so if you have other questions I can try to help.

Thanks, yeah ive been using it since gdax days, but recently totally overhauled my autotrader and have been encountering weird errors. I think I have everything good now though.... hopefully, cause riches await!

You just asked me what a print statement is doing, and that kind of
question only comes from someone who is not a programmer. I can't imagine
expecting to make money without understanding the API or basic print
statements.
On Sun, Aug 25, 2019 at 5:19 PM powertradercrypto<EMAIL_ADDRESS>wrote:

Thanks, yeah ive been using it since gdax days, but recently totally
overhauled my autotrader and have been encountering weird errors. I think I
have everything good now though.... hopefully, cause riches await!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/danpaquin/coinbasepro-python/issues/376?email_source=notifications&email_token=AJ6RVIKUKLZSEWEXJEKOPSLQGLZPXA5CNFSM4IPGOBN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5C36NA#issuecomment-524664628,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJ6RVIJUJFX7EMDN6ZBXDPLQGLZPXANCNFSM4IPGOBNQ
.

I asked you if the order command went through to coinbase on the variable declaration or on the print statement.
You misunderstood my question, so I won't hold your a-holeness against you man. I really appreciate the help you have given me. Thanks. Have a good day.


fails with 'not supported by windows'

Fails to run on Windows:
>pixiecore.exe api -d <IP_ADDRESS>:1111
not supported by windows

Why it is not supported? I couldn't find the source of that error.

That error comes from the stdlib's syscall package. I haven't dug deeper yet, but go.universe.tf/netboot/dhcp4 is the package that does the most complex/unusual low-level socket operations (using golang.org/x/net/ipv4), so I suspect it's a codepath in x/net/ipv4 that's doing something not implemented on windows.
If that's the case, unfortunately there's not much I can do about it, the default codepath in dhcp4 is already as portable as I was able to make it, so it's x/net/ipv4 that would need extra windows support.
I'll dig more later today to see if I can identify a specific codepath.

@danderson how do you debug it? I tried delve, but it doesn't work on 32-bit Windows (https://github.com/derekparker/delve/issues/656).

I don't use windows at all, so I don't know what debugger options exist. My strategy would be to add fmt.Println statements in https://github.com/google/netboot/blob/master/pixiecore/pixiecore.go#L185 to trace the initialization. I suspect it's newDHCP that is returning the error, but I could be wrong.
Once you find the function call that's returning the error, you can continue drilling down from there into that function and see which call is failing.
My guess, just looking at the code, is that the error comes from this SetControlMessage call in the dhcp4 package: https://github.com/google/netboot/blob/master/dhcp4/conn.go#L169 . This uses x/net/ipv4 to get information about the network interface that received a packet (required for DHCP, because we have to broadcast responses on the correct interface). My guess is that x/net/ipv4 has a TODO for supporting interface info.

bingo: https://github.com/golang/net/blob/master/ipv4/control_windows.go#L10
Looks like socket control messages are not at all implemented in x/net/ipv4, so the dhcp4 package cannot initialize on windows. If you know how to support this functionality for windows, pull requests for x/net are very welcome.

Hmm.. I am trying to understand this. pixiecore listens on all interfaces, and when a packer is received, it is impossible to tell which interface it was? How come?
I found https://stackoverflow.com/questions/3062205/setting-the-source-ip-for-a-udp-socket?noredirect=1&lq=1 - is it talking about the same issue?

The problem pixiecore has is not the same as the stackoverflow question, it's related to how DHCP works.
With a normal client<->server communication, when you receive a packet, you have both the source (client) IP and the destination (server) IP, so you can easily tell where the client is located and how to respond.
But with DHCP, when the client sends the DHCPDISCOVER packet, it does not have an IP address yet. So, the packet has a source IP of <IP_ADDRESS> (none), and a destination of <IP_ADDRESS> (broadcast). And we have to broadcast the response to <IP_ADDRESS> as well.
With the basic socket APIs, when you receive such a packet, you have no information at all about where the client is (which network interface), you just know that it sent a broadcast packet and your machine was able to see it. So, you don't know where you should send the response.
The function call at https://github.com/google/netboot/blob/master/dhcp4/conn.go#L169 uses an extension of the socket API to ask for interface information. So, when we receive a packet using this API, we get the packet, but also the OS tells us exactly the interface the packet arrived on. Then, when we send the response, we use this extension again, and tell the OS "please send this packet on interface X".
This extension to the basic socket API is required to implement DHCP correctly, because it's a slightly weird protocol that has to talk to clients with no IP addresses. I'm sure Windows offers a similar API to get this information, but x/net/ipv4 has no windows experts, so the support is missing (https://github.com/golang/go/issues/7175).

How the interface on which a message received is identified? Is it an IP address or MAC?

Need time to wrap my head around system specific socket interface flags. I wish there was some table with socket optons and features. I guess on Linux conn.go wraps IP_PKTINFO flag described at https://linux.die.net/man/7/ip which seems implemented on Windows - https://msdn.microsoft.com/en-us/library/windows/desktop/hh285668(v=vs.85).aspx
Maybe a more simple workaround is to just listen on all interfaces separately?


ddev install doen't work anymore for me

I always get the following error:
Failed to start project for custom command: container failed to become healthy: err=health check timed out: labels map[com.ddev.site-name:t3docs-screenshots] timed out without becoming healthy, status=
I tried everything, even deleting the whole project and redoing it. no success always the same error. Doing ddev restart or such works fine...

Works still fine on my side. Please tell if
ddev poweroff
ddev install

does not work either and if so, what happens if you remove the project and do a simple start of it:
ddev delete -yO
ddev start

Does it show the same error? Which versions of DDEV and docker do you use?

ddev delete -yO
ddev start
worked for me


Dragonrage: Watch usastream.xyz

Dragonrage requests the watch of the watch_keyword usastream\.xyz. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

usastream\.xyz has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Mast in Charcoal HQ


Create dependency-review.yml

This change addresses the issue reported in Issue #33.
Changes Made

Added a new GitHub Actions workflow file (dependency-review.yml) to the .github/workflows directory.
Configured the workflow to run the Dependency Review Action on every pull request.
Configured permissions required by the action.
Specified job to run on the ubuntu-latest environment.
Configured the Dependency Review Action to:

Post a summary comment in the pull request.
Fail the CI if vulnerabilities with a severity of "high" are found.
Specify allowed licenses.
Specify which dependency scopes should cause the CI to fail if vulnerabilities are found.
Allow specific licenses for certain dependencies.

Would you be willing to take the issue this is referring to? I think if you commment on it I can assign it to you.

Yeah, can you walk me through what else I've got to do?

@joeyyy09 Please click #33 and write comment for starters.
This PR is now approved but can't be merged becuse the CodeQL check hasn't completed yet.  @JamieSlome any clue?

Yeah, the CodeQL check is still waiting for status, anything to be done from my end?

I'd wait for @JamieSlome to let us known if he has a clue.
I did a bit of research on Google, and found:
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/troubleshooting-required-status-checks
https://stackoverflow.com/questions/52200096/github-pull-request-waiting-for-status-to-be-reported

Some of the worflows require a maintainer to run., which is surprising to me and might be a valuable clue.
I allowed some of the m to run, however it didn't clear up the CodeQl check which is still "Expected".

https://github.com/Citi/gradle-helm-plugin/actions/runs/8629901325

Hey, I've been trying to find out why the CodeQl check is still in the waiting stage, I think this is might help. Idts it has anything to do with the code but something to do with the github actions itself.
https://github.com/orgs/community/discussions/26698

I believe the CodeQL check runs periodically instead of on the pull request event.
I will open a PR to implement the CodeQL workflow 💪


Update nf-winuser-loadimagea.md

Fix whitespacing mistake in Remarks Section.
The paragraph was split up at points that appear to be mistakes when transferring it from a previous build.
There's also another strange ^M edit that wasn't intentional, that other users seemed to of got.

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


Never Gain And Loss Health Script Request

What is your question?
can someone make a script that doesn't gain and loss health when we do or don't hit a note?

This is not the place to request for scripts.


Add i18n tags to About Us team positions

Our names can be English but the positions and team titles should be translated at least. Right now all display in English-only.

@linderr can we normalize the titles across countries so they can all use the same i18n strings? i.e. "Lead" vs. "Organizational Lead", "Tech" vs. "Tech Lead", etc.

Definitely. Sounds good @ngottlieb !


Events

Extremely simple event-based approach to triggering side-effects, e.g. removing orphaned facets after deleting an entry.
There is no global event handler (yet) and some queries are not optimized. But this is nice. All tests pass but we need more testing before trusting this.

Codecov Report

Merging #115 into master will increase coverage by 33.22%.
The diff coverage is 68.26%.

@@              Coverage Diff              @@
##             master     #115       +/-   ##
=============================================
+ Coverage     13.92%   47.14%   +33.22%
- Complexity       42      111       +69
=============================================
  Files            16       21        +5
  Lines          1336     1385       +49
  Branches        123      130        +7
=============================================
+ Hits            186      653      +467
+ Misses         1141      669      -472
- Partials          9       63       +54

Impacted Files
Coverage Δ
Complexity Δ

src/main/java/se/lth/cs/connect/TrustLevel.java
11.76% <ø> (+11.76%)
3 <0> (+3)
:arrow_up:

...main/java/se/lth/cs/connect/DatabaseException.java
0% <ø> (-62.5%)
0 <0> (-2)

.../main/java/se/lth/cs/connect/RequestException.java
100% <ø> (+42.85%)
3 <0> (+1)
:arrow_up:

src/main/java/se/lth/cs/connect/Connect.java
57.69% <ø> (+3.84%)
8 <0> (ø)
:arrow_down:

src/main/java/utils/URLParser.java
55.55% <ø> (+55.55%)
2 <0> (+2)
:arrow_up:

...c/main/java/se/lth/cs/connect/modules/Mailman.java
88.46% <ø> (+34.61%)
4 <0> (+1)
:arrow_up:

src/main/java/se/lth/cs/connect/Graph.java
0% <ø> (ø)
0 <0> (ø)
:arrow_down:

.../main/java/se/lth/cs/connect/modules/Database.java
28.2% <ø> (-48.72%)
3 <0> (ø)

src/main/java/se/lth/cs/connect/routes/Entry.java
39.36% <ø> (+34.84%)
8 <0> (+5)
:arrow_up:

src/main/java/utils/CleanupUsers.java
0% <0%> (ø)
0 <0> (ø)
:arrow_down:

... and 26 more

Continue to review full report at Codecov.

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


libQt5Core.so.5.15.8: undefined reference to<EMAIL_ADDRESS>

Solution to issue cannot be found in the documentation.

[X] I checked the documentation.

Issue
Trying to link to Qt in my new conda-forge recipe:
https://github.com/conda-forge/staged-recipes/pull/23023
Installed packages
See PR CI logs:
https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=719180&view=logs&j=6f142865-96c3-535c-b7ea-873d86b887bd&t=22b0682d-ab9e-55d7-9c79-49f3c3ba4823

Environment info
See PR CI logs:
https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=719180&view=logs&j=6f142865-96c3-535c-b7ea-873d86b887bd&t=22b0682d-ab9e-55d7-9c79-49f3c3ba4823

Well, seems like every recipe using qt needs to be built on cos7. Would be great if this could be documented somewhere. Maybe even as a check at build time so you get an actual error.


let users decide which CDK they want to use for quickstart

currently the top level quickstart lets user deploy a dapp using the motoko cdk. ideally we let people choose which language they want to use and provide links to the respective cdks.

The latest Hello World quickstart example includes code for Motoko/Rust/Azle/Kybra: https://internetcomputer.org/docs/current/developer-docs/getting-started/hello-world


Open for Consulting?

Hi, I do not know, how to get in contact other than via an issue. I would like to give your toolbox a try. I would appreciate, if I could hire you e.g. 2-3 hours to help me with get started with the meshing process and provide me with an overview of your work. I cannot pay a typical corporate fee, but I am sure we can agree on a fair amount. Is this an option for you?

Hi,
thanks for reaching out!
We might want to schedule a meeting about this.
Could you please send an email at malik . hassanaly [at] nrel. gov?
What would be useful is if you briefly explain in your email what you are trying to do, and what you have done so far with this toolbox? Then we can go from there!
I'm leaving this issue open in case you have issues reaching out via email.


FIRECERT 2155 - Add action from FCS to app/device for same state transitions

Ticket link - https://ccp.sys.comcast.net/browse/FIRECERT-2155

PR cancelled


I18n server

Issue #45 labels main and infrastructure

Thanks @gtico80 for the precious work! We will review it during the week and give you some feedback. :+1:  @sebbalex

Actually we have four views in flow:
* main-content

* email-sent

* register-confirm

* confirmed

We must provide localisation for all views and even for email.mst which represent the template for email sent

Quoting @sebbalex 's comment, I also believe that in order to merge this PR and close the relative issue an extra effort should be done to consolidate all the views. Are you able to proceed in this direction @gtico80 or you need some assistance? Thanks a lot for your precious work! :rocket:

Hi @gtico80, I believe that in order to be able to correctly review this PR it is necessary to rebase your branch against our master and consequently run the linter. When trying to run it (with node 12.4.0), I found several problems and the application could not even start. If you need assistance during the rebasing process please let us know! Thanks a lot / cc @sebbalex

Hi @gtico80, if you want we can rebase your branch against your master and push on your fork so that we can test this PR further and merge it. What do you think? Thanks a lot!

We can try but probably it is better to fix  issue #65 otherwise it is difficult to test it

@gtico80 you are right, we will try to work on that issue next week and we'll let you know. Thanks!


Add argument parsing

Contains small refactors and the ability to change parameters via CLI
poetry run python main.py -h
usage: main.py [-h] [--template_path TEMPLATE_PATH] [--font_path FONT_PATH] [--certificate_path CERTIFICATE_PATH] [--data_path DATA_PATH]

options:
  -h, --help            show this help message and exit
  --template_path TEMPLATE_PATH
  --font_path FONT_PATH
  --certificate_path CERTIFICATE_PATH
  --data_path DATA_PATH

Default paths are kept and everything is optional.

Let me know ,when it gets completed.

From my point of view it is done, do you have any request I should do ?

ok then, thanks for contributing 💯
merging


Add sample for AWS Integrated Application Test Kit

Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Thanks for the review! Updated to address comments.


[Snyk] Upgrade com.squareup.retrofit2:retrofit from 2.9.0 to 2.11.0

This PR was automatically created by Snyk using the credentials of a real user.![snyk-top-banner](https://github.com/andygongea/OWASP-Benchmark/assets/818805/c518c423-16fe-447e-b67f-ad5a49b5d123)
Snyk has created this PR to upgrade com.squareup.retrofit2:retrofit from 2.9.0 to 2.11.0.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 2 versions ahead of your current version.

The recommended version was released on 2 months ago.

[!IMPORTANT]

Check the changes in this PR to ensure they won't cause issues with your project.
This PR was automatically created by Snyk using the credentials of a real user.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:

🧐 View latest project report
📜 Customise PR templates
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

Upgraded and using version 2.11.0