Massive resource use

Checklist

[x] I updated the card to the latest version available
[x] I cleared the cache of my browser
[x] I verified that I'm really running the lastest version in my browser console
[x] I checked if there is another issue opened with the same problem

Describe the bug
I've been quite impressed with the look and function of apexcharts and was going to replace all my mini graph cards but I have found that apexcharts is far too resource intensive to meet my needs.
For example, the bar charts in the screenshot below are daily maximums or last values for the past week. There could be thousands of measurements a day from the inverter that need to be processed.
When loading, the charts grind not only the frontend to a halt but the backend too. I get loads of errors that unrelated integrations are taking too long to respond.
This is with Home Assistant on an i7 mini PC.
I tried setting the graph update to 5 minutes rather than on sensor change. This helped a bit. Except when trying to edit the cards. If the card is still loading data when I try to save it seems to start loading and processing the data again, without cancelling the previous load/process operation. Leading to massive resource use. Closing the page does not help. All the processes continue to run to completion. This pretty much prevents Home Assistant from doing anything else.
I've tried removing the "experimental" colour thresholds. The massive resource use continues to occur.
The mini-graph card (for all it's other failings) does not do this. I have no idea how or why. Caching perhaps?
Version of the card
Version: v1.9.0
To Reproduce
This is the configuration I used:
type: custom:apexcharts-card
apex_config:
  dataLabels:
    background:
      enabled: false
    style:
      colors:
        - var(--primary-text-color)
graph_span: 7d
header:
  show: true
  title: Daily Energy
series:
  - entity: sensor.energy_inverter_daily
    type: column
    show:
      datalabels: true
    group_by:
      func: max
      duration: 1d

Screenshots
If applicable, add screenshots to help explain your problem.

Expected behavior
A bit of optimisation, particularly when editing the card so that it does not bog down the entire system.
Desktop (please complete the following information):

Browser Firefox
Version 91.0.2

Smartphone (please complete the following information):

Device: [e.g. iPhoneX]
OS: 14.8
Browser saffari
Version ??

Additional context
Add any other context about the problem here.

Caching is disabled while editing the card from the frontend, that's on purpose. Maybe there are some bugs there and I could make it better but I don't use the frontend editor so I never really checked.
With regards to the backend being slow, unfortunately that has nothing to do with the card but to requesting history data (almost exact same code as mini-graph-card). I have an i7 NUC to run home-assistant and I don't experience what you are seeing (and I also load a lot of history data). Once the card is configured, you shouldn't have any issue anymore as caching is enabled again automatically.
With regards to the frontend being slow, all the math is done in frontend but I do not experience that either (neither does a lot of other people using the card). If you hace a slow device for your frontend through, that is quite expected (eg: slow Android tablet, old iPad or equivalent)

(almost exact same code as mini-graph-card).

That's weird because I don't see the same behaviour with the min-graph card. I can interrupt it loading to my hearts content when editing via the UI.

Once the card is configured, you shouldn't have any issue anymore as caching is enabled again automatically.

As I said, it's better, but if you interrupt the loading/processing it begins again without (apparently) stopping the previous processes. And that's what gets heavy. It starts trying to load all this data 2 or 3 time in parallel.

If you hace a slow device for your frontend through,

No, it's an older but still quite powerful PC.

I have found that the graphs were logging lots of errors in the browser console.
Seems like this was causing slow loading of the graphs for me.
Disabling adblock for the site removed the errors and improved the performance noticeably.

Sorry, it tunrs out that the errors in the console are just transient. Disabling adblock didn't affect them. The errors just disappeared, and then magically reappeared again. Seems like I'm actually facing bug #17.

@vadipp, you can ignore the errors in the console as those are related to some bugs in apexcharts.js but are not affecting functionalities.

That's weird because I don't see the same behaviour with the mini-graph card. I can interrupt it loading to my hearts content when editing via the UI.

I don't understand what you mean?
If there is a bug with editing the card in the UI (like having ghost instances of the card still running), it should go away once you close the editor and reload the page.

Still an issue on 2021.11.1

i have noticed a memory leak when the experimental brush features is enabled that was causing my system to crash when editing any card (frontend client running on a desktop pc intel core i7@4ghz and 8gb of ram, chrome was using all 8gig before crashing the tab, it appears to me that when using template sensors when HA redefined them sometimes the card try to re-render without valid values causing a lots lots of attempt to draw svg path like "M3 %NaN %NaN", i tried debugging but the code it pretty complexe and the culprit seems to be HA sending way too much update statement i had a card that was re-rendering almost every seconds despite the interval set to 10sec, when debugging i could see the interval got reset every time the "hass()" fonction was called ... hope this helps, for the moment i just disabled the brush feature and memory usage is almost back to normal usage (still a bit high but at least stable)

Still an issue on 2021.12.7

Still an issue on 2022.2.0

I have an interface with two graphs - its super slow. I wish it would generate the graph serverside as an image so it would be super fast for the client!

I thinks there's some memory leaks with the card, even with only 2 sensors as inputs, massive CPU/RAM usage, as soon as the card is removed memory goes back to normal usage, and it's even worse when editing (most likely due to cache being disable as you mentionned)

There might be some issues with edit, yes and I need to have a look at it. however outside of editing the card, the card is resource heavy especially if you have to display A LOT of datapoints (like using a sensor updated every minute or less with raw data over a long period of time).

There might be some issues with edit, yes and I need to have a look at it. however outside of editing the card, the card is resource heavy especially if you have to display A LOT of datapoints (like using a sensor updated every minute or less with raw data over a long period of time).

I have a sensor with lots of datapoints - what can you recommend me do instead.
Also I have the same data in a SQL database.

I thought I was losing my mind... I've chased this for almost a month and finally realized that Apex charts IS THE CULPRIT. it started a few core updates ago,  basically the charts are so slow as to render them totally unusable. The Ui freezes completely for anywhere from 10-30 seconds, only on Lovelace tabs that have the charts.
Bummer.  It was a nice card.  Anyone found a substitute card?
Jeff

The mini graph card seems to handle large data sets better. The graphs aren't as customisable or nice though.

I thought I was losing my mind... I've chased this for almost a month and finally realized that Apex charts IS THE CULPRIT. it started a few core updates ago, basically the charts are so slow as to render them totally unusable. The Ui freezes completely for anywhere from 10-30 seconds, only on Lovelace tabs that have the charts.
Bummer. It was a nice card. Anyone found a substitute card? Fwiw, I'm on core-2022.3.7 now, but it's been going on for weeks. Jeff

@jazzmonger, I'm experiencing the same (UI freezes for many seconds and I can't even switch tab in the dashboard until the graph is loaded) and I'm moving toward Ploty. It seems a younger project but it's very powerful, lighting fast, and you can also interact with the graph.
It is not a direct drop-in replacement, but I'm moving to it. The worst issue for me is dbuezas/lovelace-plotly-graph-card#34. But considering the drawbacks of apex, it's nothing.

Apex charts IS THE CULPRIT

I have a dashboard with 100 charts displayed at once and it's working fine. Just saying there's an issue without providing any data/performance graph isn't going to help with fixing a potential issue.

Yeah but how many data points do each of your graphs use and what features of Apexcharts are you using?
There is definitely an issue using multiple graphs when using sensors that can update every second or so (like from my solar inverter).

Yeah but how many data points do each of your graphs use and what features of Apexcharts are you using?
There is definitely an issue using multiple graphs when using sensors that can update every second or so (like from my solar inverter).

Yeah, me too. I'm visualizing 10h of data with 8/9 traces that update every minute.

Use update_interval then, updating every second is way too high.

I wasn't aware of the update interval. I'll give it a go. Yeah I didn't write the SMA Integration that does that.

With mini-graph you can select points_per_hour, this helps alot with the speed of the graph.
I have several sensors updating every second, this really slows everything down when trying to use apex. Every page load takes a lot of resources from both backend and browser, even with group_by and func: avg.
I think a solution would be if you specify group_by and func: first, that should only fetch the first value from the database, not all of them and then filter out what to show in the browser. Another solution would be to be able to specify a value on how many data points you want to fetch, similar to points_per_hour.
Also: update_interval isn't working. https://github.com/RomRider/apexcharts-card/issues/293

For anyone having this issue, I just updated to v1.11.0-dev.1, my resource usage is way down at the moment. I will keep monitoring. But try out v1.11.0-dev.1 if you're having these issues.

For those who don't have update_interval working, could you please share your config in https://github.com/RomRider/apexcharts-card/issues/293 as I can't reproduce the issue.

update_interval fixed in 2.0.0

The issue go much worse for me in 2.0.0.
It was very slow, taking up to 30 seconds to load on previous versions, but now it's unusable.
My update_interval is 2 hours and I can't even get the first card to load before it crushes.
I managed to get it loaded after 10 attempts and clicking wait to load.
This is how the graphs should look like

Is there anything I can optimize in my config to improve the situation:

The issue was very bad for me with 2.0.1 as well. But it magically became better. Try clearing chrome cache etc.

Thanks for the offer, but it didn't make difference for me.

I was just wondering if there is any action planned for this issue.
While I love the card, since I can't use it, I'll probably have to redo it on another card type to make it work.
Thank you in advance!

Use update_interval and maybe an aggregate (eg: avg) function over that then to reduce the sample rate to 1min, updating every second is way too high. Every seconds over 10h is 36000 data points, not surprising it is quite slow...

Unfortunately I have to agree with the people complaining about poor performance. The issue appeared with v1.9 , that is why I downgraded to version 1.8.3 to be able to use the brush feature with long (48 h) selectable timeline.
So it is not just a thing of the many data points. Because the number of data points have been the same with the old version.
Can you remember what ressource hungry feature you added with v1.9?
Is there a possibility to reduce the datapoints that are loaded for the brush timeline? E.g. loading only every 20th point from Database?
In my opinion avg does not help because ALL values have to be loaded to avg the an then plot as many points as before. Why should it be faster?
generally it would make sense to have the option to display only every xth datapoint. Or even more luxury: To say 3 points per minute. That should be configurable separately for main plot and brush plot.

Brutal.... I've had to remove these charts completely.  My inverter current sensors update every 10 seconds. Increasing this value isn't practical as finding max values requires at least 10 sec intervals.  Too bad. This used to be a nice card.

Hi,
I've been struggling for a week or so on the same issue.  I'm creating a couple of new dashboards using the mushroom templates and finding similar issues to the above comments.  Some of my lovelace editing is done on the UI, however I've noticed that even navigating to a page that contains the charts can start to cause the system to freeze.  I've also noticed it on the back end, most recently while navigating to the backups screen.
It seems that closing down the browser and reopening it fixes the issue until I navigate to a screen that contains a graph.

In fact, the number of errors goes nuts on each load of the graphs as shown below, over 12000 errors listed.

Below was a single page load with 3 charts

Just removed all the charts, and the system is back to its usual responsive self.
I'm running system on a Pi4 with SSD, system performance params are shown below, and this doesn't really change much.

I suspect the charts are perhaps affecting the performance of the browser more than anything.
Cheers,
Paul

@RomRider : Do you see a chance to solve the performance issue within the next 2 month? Otherwise I will definitely have a look on alternatives, because the graphs I setup with lot of time effort cannot be used, when the whole page freezes.

I would suggest looking for alternatives, there isn't a lot of action happening in this space at the moment.  Remember too that these addins are free, and people do have priorities that change from time to time.

Brutal.... I've had to remove these charts completely. My inverter current sensors update every 10 seconds. Increasing this value isn't practical as finding max values requires at least 10 sec intervals. Too bad. This used to be a nice card.
Plotly works flawlessly.

Hi I also have big performance problems with apexcharts-card. The same with plotly. The longer the graph is the slower everything gets.
mini-graph-card however is fine.
I too hope this is improved soon as apexcharts are much prettier and more useful features 😊

Hi I also have big performance problems with apexcharts-card. The same with plotly. The longer the graph is the slower everything gets.

Please read this comment: https://github.com/RomRider/apexcharts-card/issues/210#issuecomment-1118884848

As I struggled last evening with bad performance of this otherwise great graph card, I did run into this thread and hopefully help others with my solution.
Using the option forceNiceScale in the code below resulted in (and got sorted by removing this option again) multiple pop-up messages from Firefox (103.0 64bit) about the hass tab resulting in bad performance of my browser as a whole. Closing these prompts and a good portion of patience, unfreezes my browser. Having a look at the browser debug mode terminal it reported: Uncaught (in promise) out of memory.
For reference: Data plotted in this chart is 2 days of 5 series with an updating each 30min, resulting in roughly 6000 datapoints.
Configuration leading to the issue:
type: 'custom:apexcharts-card'
header:
  show: true
  title: Humidity
  show_states: true
  colorize_states: true
apex_config:
  legend:
    show: false
  grid:
    strokeDashArray: 0
    yaxis:
      lines:
        show: false
  yaxis:
    max: 100
    forceNiceScale: true
  stroke:
    width: 2
    curve: smooth
  chart:
    zoom:
      enabled: true
    toolbar:
      show: true
      tools:
        download: false
        zoom: true
        zoomin: true
        zoomout: true
        pan: true
        reset: true
graph_span: 2d
series:
  - entity: sensor.living_room_humidity
  - entity: sensor.babyroom_humidity
  - entity: sensor.bedroom_humidity
  - entity: sensor.outdoor_humidity
  - entity: sensor.metno_liefdesnest_humidity
    show:
      in_header: false

Hi I also have big performance problems with apexcharts-card. The same with plotly. The longer the graph is the slower everything gets.

Please read this comment: #210 (comment)

Hi thanks for the heads up I used  group_by:    func: avg  duration: 20m and it is very fast now, almost as fast as a similar mini graph card.
here is my yaml in case somone else wants it:
`type: custom:apexcharts-card
header:
show: false
show_states: true
colorize_states: true
graph_span: 7d
update_interval: 1min
series:

entity: sensor.power_dr_dedichens_vei_48
stroke_width: 1
group_by:
func: avg
duration: 20m
yaxis:
show: false
min: 0
max: 10000
apex_config:
tickAmount: 3`

`type: custom:mini-graph-card
font_size: 75
line_width: 1
entities:

sensor.power_dr_dedichens_vei_48
name: Electricity use
hours_to_show: 168
points_per_hour: 3
show:
labels: true`

Just wanted to confirm that this is still an issue, and I get a lot of console errors on some of my dashboards with Apex charts.

However, I can also confirm that using group_by: func: avg makes a huge difference and I don't see any of those console errors when I'm using group_by. I'm guessing there's some spurious or weird data in the series that's getting 'fixed' by the average function? Though I was seeing this on all my dashboards, using Apex charts for a variety of sensors.

The issue has not been resolved!
There are no resolution steps.

@RomRider would you mind having another look at it?
Anything that I've tried so far (including all the ideas offered above) do very little.
The graphs are loading dashboard so much that they simply crash or not load at all.
I have to wait anywhere between 10-60 seconds for the different dashboards to load on a PC and nearly for even on a phone.
Below a few of my configs—if you see anything I am doing wrong, I'd greatly appreciate some advice.
    cards:
      - type: custom:apexcharts-card
        update_interval: 30min
        experimental:
          brush: true
        graph_span: 7d
        brush:
          selection_span: 72h
        header:
          show: true
          title: Solar power managment - daily
          show_states: true
          colorize_states: true
        yaxis:
          - max: '|+20|'
        series:
          - entity: sensor.daily_solar_energy_production
            name: Daily Solar production
            type: column
            group_by:
              func: median
              duration: 60min
            show:
              in_brush: true
          - entity: sensor.daily_energy_consumed
            name: Daily Incoming energy
            group_by:
              func: median
              duration: 60min
          - entity: sensor.daily_energy_returned
            name: Daily Returned energy
            group_by:
              func: median
              duration: 60min
          - entity: sensor.absolute_energy_consumption
            name: Daily Absolute energy consumption
            group_by:
              func: median
              duration: 60min

and

      - type: custom:apexcharts-card
      update_interval: 10min
      experimental:
        brush: true
      graph_span: 7d
      brush:
        selection_span: 48h
      header:
        show: true
        title: Power flow
        show_states: true
        colorize_states: true
      series:
        - entity: sensor.net_power_meter
          type: column
          group_by:
            func: avg
            duration: 30min
          show:
            in_brush: true
        - entity: sensor.solar_ac_power
          type: line
          stroke_width: 1
          name: Current solar output
          group_by:
            func: avg
            duration: 30min
          show:
            in_brush: true
        - entity: sensor.returned_power_meter
          type: column
          group_by:
            func: avg
            duration: 30min
          show:
            in_brush: true
        - entity: sensor.incoming_power_meter
          type: column
          group_by:
            func: avg
            duration: 30min
          show:
            in_brush: true

    - type: custom:apexcharts-card
      update_interval: 10min
      experimental:
        brush: true
      graph_span: 7d
      brush:
        selection_span: 72h
      header:
        show: true
        title: Solar power managment - momentary
        show_states: true
        colorize_states: true
      series:
        - entity: sensor.yearly_solar_energy_production
          name: Momentary Solar production
          type: column
          group_by:
            func: diff
            duration: 30min
          show:
            in_brush: true
        - entity: sensor.yearly_energy_consumed
          name: Momentary Incoming energy
          group_by:
            func: diff
            duration: 30min
        - entity: sensor.yearly_energy_returned
          name: Momentary Returned energy
          group_by:
            func: diff
            duration: 30min

Example of a failure to load, but there are many other ways it fails:

I have the sam Issue. I Cant use the card with my Android-Wallpannel anymore, due to freezing the UI completely for about 5 Seconds while the Card is reloading. On an i7 its take about 2 Seconds.
There are only 2 Sensors without many Data-Points.
  - type: custom:apexcharts-card
    graph_span: 24h
    experimental:
      disable_config_validation: true
    all_series_config:
      stroke_width: 2
      fill_raw: last
    header:
      show: false
      show_states: false
      colorize_states: true
    series:
      - entity: sensor.0x158d00044d1e69_humidity
        name: Haus
        type: area
        show:
          in_header: false
          legend_value: true
      - entity: sensor.delta_forecast_erdgeschoss
        name: Forecast
        show:
          in_header: false
          legend_value: true
        unit: '%'
        type: line

I second this bug causing both backend and frontend to freeze.

I can confirm having same issue.

Thanks for the prompt comment. I agree with mostly all of what you said.

Plotly vs. APEX - agreed, APEX is way more polished
I am mostly using group_by - please see https://github.com/RomRider/apexcharts-card/issues/210#issuecomment-1272066956 - and it makes a big difference but after having it added it's still mighty slow.
Since there are that many people reproducing it, if there would be will to tackle it, I am guessing there would be a line of people wanting to provide logs, input, and beta test. I am not sure if I subscribe to the 'difficult to reproduce' being the root cause.

Remember too that if someone else wishes to have a crack at it, fork the project.

@PierreMarieBaty respectfully that is the most TL:DR while mansplaining response I've seen in a while.
No, that is not a fix (not even a workaround) nor is it any different that majority of the people in the thread reported to have been using from the start and still experiencing performance issues.
Not to mention that averaging is only possible with continuous variables while at least some people reported having worked with entities that cannot be averaged at all.
So TL:DR - it's always a good idea to at least read the last 5 comments before making such authoritative statements.

@convicte Apologies for the mansplaining. The TL;DR diagnosis is right though, I totally endorse it. I wrote that from the point of view of the average user looking for a usable multichart card for HomeAssistant who doesn't expect to spend hours on it. Pretty sure I'm not the only one : without that setting even the provided graph samples are unusable. As there was no indication that feeding a large dataset to the graph code would freeze the UI, and considering the average user was not supposed to expect that behavior as competing chart solutions handle them well, I was about to throw it away and pester against yet another open source garbage, but gave it a second thought and attempted to "fix" that myself. Call that as you wish, not a fix not even a workaround, it makes the solution usable. That's all the average user needs to know, and I persist thinking it should be a default setting.

I'm having the same issue. It freezes the complete HASS system on both ends. Console gives the following errors when trying to reload the graph:

The code I use:
type: custom:apexcharts-card
graph_span: 10d
update_interval: 1h
stacked: true
header:
show: true
title: Opbrengst PV
yaxis:

id: first
id: second
opposite: true
series:
entity: sensor.opbrengst_zonnepanelen
name: Omzet PV
type: column
yaxis_id: first
opacity: 0.8
color: '#03b2cb'
group_by:
duration: 1d
func: diff
show:
legend_value: false
entity: sensor.netto_kosten_zonnepanelen
name: ROI PV
yaxis_id: second
type: line
opacity: 0.8
color: '#cb6f02'
group_by:
duration: 1d
func: last
show:
legend_value: false

It doesn't load longer than 10days in my experience. I assume it uses the short term statistics, where it would be better to use long term statistics with this setup. The data is updated every 5 seconds. So it generates a lot of datapoints.
I can read code, but haven't developed for HASS yet. Hence, I am using HASS for a few months now. I want more of these type of graphs, because they are very beautiful in giving insight in daily volumes (ex. power usage an total usage) If I wan't to debug this I need time and soms hints where to start.

I'm having the same issue. It freezes the complete HASS system on both ends. Console gives the following errors when trying to reload the graph:

Is it possible to use
group_by:
  func: avg
  duration: 1h

in your case? As far as I'm aware, that's still the only known workaround for this issue. It's annoying to have to add it in to every chart every time, but it does seem to solve the issue for most of us.

I can do that, but I want the diff between the days. I can confirm it is a bug in backend of HASS. Because other front end implementations suffer the same slow performance. (like https://github.com/dbuezas/lovelace-plotly-graph-card) for instance. It is possible to achieve the same result but does take a long time either to load. Not shure what to doe next. rebuidling my database as we speak but I don't think that is going to be the solution.

For those who are intereseted, I had the same experience with the extreme slow performance after I added a apex chart to my HA. It took me verry long to be even able to remove the chart. Seems that it does not work well for me so I removed apex chart.

For those who are intereseted, I had the same experience with the extreme slow performance after I added a apex chart to my HA. It took me verry long to be even able to remove the chart. Seems that it does not work well for me so I removed apex chart.

I have same expirience, it takes up  to 3 mins for some charts to load yet there is no alternative so far which have time on X scale sadly.


Extend download repository functionality, Fixes #811

Checklist

[x] I tested the changes and all related features on the test server https://artemistest.ase.in.tum.de.
[x] I documented my source code using the JavaDoc / JSDoc style.
[x] I added integration test cases for the server (Spring) related to the features
[x] ~I added integration test cases for the client (Jest) related to the features~
[x] I added screenshots/screencast of my UI changes
[x] I translated all the newly inserted strings

Motivation and Context
This fixes #811: It adds several options when downloading the student repos.
Also, now a different folder for the repos is used in order to prevent inference with the code students use.
Description

The repositories of all students can now be downloaded by activating the checkbox. This disables the text-box with the student ids (and the student ids won't be evaluated on the server, even if something is written in there)
Filtering of late submissions can now be activated/disabled. By default, the exercise due date is used as date, but it can be changed manually. Also, the commithash saved within the submission is now used instead of the commithash of the git repository itself if possible in order to avoid students from creating commits with a wrong date and tricking the system with that. If this is not possible, the old solution is used as fallback.
It can now be toggled if the student names should be added to the project or not.
It can now be toggled if all commits made by the student should be squashed into one commit.
The code style can now be normalized: This changes the encoding of all files to UTF-8 (the apache tika library is used in order to determine the encoding) and changes all line endings to UNIX line endings.

Steps for Testing

Log in to Artemis
Navigate to Course Administration
Click on exercises for one course.
Click on 'Scores' for a programming exercise
Click on 'Download repos'
Test if the available checkboxes work correctly
Test if the newly added folder ('repos-download' by default) is used instead of the folder used by students ('repos' by default)

Screenshots
(somehow the mouse is missing..)

Complicated stuff, good work!
In general it works, I have a couple of comments about the design of methods, etc. though (see below).
Some comments about the functionality:

Minor: The zip folder structure is nested when exporting a single repository. Also the single student repositories within the main zip are all themselves zipped. This might be due to file size, but I thought it was annoying when testing the feature.

Medium: There is no autocomplete for the student names. This would help the instructors/tutors to efficiently export repositories.
Major: When I enter one student login that does not exist, nothing happens after clicking on download repos
Major: No progress is visualized for the user, even though the download could take a while (let's say exporting 2000 repositories). We currently have a 15 min limit a request can take on nginx, this might even take longer.
A simple solution would be to at least show a loading indicator in the UI while the request has not returned a response (we have a new generic button component for this jhi-button that already has a loading state built in).
A more sophisticated solution would involve more work and is out-of-scope for this PR, but running an async task that sends websocket messages to the client, which are then visualized with e.g. a progress bar would be idea.

On a side note: There are no server tests in this PR which I think is critical for methods with heavy logic (e.g. normalizeFileEndings or squashingCommits). We should write unit tests for those.

Thanks, these are all good suggestions for a follow up issue / PR. Right now, we want to give this functionality to the users. We can still improve its usability later on.


Install tensorboard as an extra

Click to expand!
Issue Type
Feature Request
Have you reproduced the bug with TF nightly?
Yes
Source
source
Tensorflow Version
2.11.0
Custom Code
Yes
OS Platform and Distribution
No response
Mobile device
No response
Python version
No response
Bazel version
No response
GCC/Compiler version
No response
CUDA/cuDNN version
No response
GPU model and memory
No response
Current Behaviour?
The `tensorflow` package currently relies on a great deal of sub-dependencies. Among them the biggest one is definitely the tensorboard, as you can see from this tree obtained through `poetry`. I wonder if the `tensorboard` (and possibly other dependencies) are really needed for a minimal installation of tensorflow. E.g. do I really need the tensorboard for running inference on a model? The more dependencies we have
- The more bloated our virtual environments become
- The slower our CI jobs are
- The bigger are our Docker images that run TensorFlow
- The slower is the dependency resolution of Python packages with tools such as poetry, pipenv, pdm, ..

In comparison, `torch` just depends on `typing-extensions`.

It would be great to have a minimal installation of `tensorflow` by default and rely on pip extras to install any satellite functionalities (such as `pip install tensorflow[tensorboard]`).

tensorflow >=2.3.0
    ├── absl-py >=0.4.0
    ├── astunparse >=1.6.0
    │   ├── six >=1.6.1,<2.0
    │   └── wheel >=0.23.0,<1.0
    ├── flatbuffers >=1.12
    ├── gast >=0.2.1
    ├── google-pasta >=0.1.1
    │   └── six * (circular dependency aborted here)
    ├── grpcio >=1.24.3,<2.0
    ├── h5py >=2.9.0
    │   └── numpy >=1.14.5
    ├── keras >=2.8.0rc0,<2.9
    ├── keras-preprocessing >=1.1.1
    │   ├── numpy >=1.9.1 (circular dependency aborted here)
    │   └── six >=1.9.0 (circular dependency aborted here)
    ├── libclang >=9.0.1
    ├── numpy >=1.20 (circular dependency aborted here)
    ├── opt-einsum >=2.3.2
    │   └── numpy >=1.7 (circular dependency aborted here)
    ├── protobuf >=3.9.2
    ├── setuptools *
    ├── six >=1.12.0 (circular dependency aborted here)
    ├── tensorboard >=2.8,<2.9
    │   ├── absl-py >=0.4 (circular dependency aborted here)
    │   ├── google-auth >=1.6.3,<3
    │   │   ├── cachetools >=2.0.0,<6.0
    │   │   ├── pyasn1-modules >=0.2.1
    │   │   │   └── pyasn1 >=0.4.6,<0.5.0
    │   │   ├── rsa >=3.1.4,<5
    │   │   │   └── pyasn1 >=0.1.3 (circular dependency aborted here)
    │   │   └── six >=1.9.0 (circular dependency aborted here)
    │   ├── google-auth-oauthlib >=0.4.1,<0.5
    │   │   ├── google-auth >=1.0.0 (circular dependency aborted here)
    │   │   └── requests-oauthlib >=0.7.0
    │   │       ├── oauthlib >=3.0.0
    │   │       └── requests >=2.0.0
    │   │           ├── certifi >=2017.4.17
    │   │           ├── charset-normalizer >=2,<4
    │   │           ├── idna >=2.5,<4
    │   │           └── urllib3 >=1.21.1,<1.27
    │   ├── grpcio >=1.24.3 (circular dependency aborted here)
    │   ├── markdown >=2.6.8
    │   │   └── importlib-metadata >=4.4
    │   │       └── zipp >=0.5
    │   ├── numpy >=1.12.0 (circular dependency aborted here)
    │   ├── protobuf >=3.6.0 (circular dependency aborted here)
    │   ├── requests >=2.21.0,<3 (circular dependency aborted here)
    │   ├── setuptools >=41.0.0 (circular dependency aborted here)
    │   ├── tensorboard-data-server >=0.6.0,<0.7.0
    │   ├── tensorboard-plugin-wit >=1.6.0
    │   ├── werkzeug >=0.11.15
    │   └── wheel >=0.26 (circular dependency aborted here)
    ├── tensorflow-estimator >=2.8,<2.9
    ├── tensorflow-io-gcs-filesystem >=0.23.1
    ├── termcolor >=1.1.0
    ├── typing-extensions >=3.6.6
    └── wrapt >=1.11.0

### Standalone code to reproduce the issue

```shell
pip install tensorflow

Relevant log output
No response

Thanks for the feature request. AFAIK, we don't have anything planned for the minimal tensorflow version to reduce the dependency packages.
@learning-to-play , Could you please take a look into this request.

Hi,
Thank you for opening this issue. Since this issue has been open for a long time, the code/debug information for this issue may not be relevant with the current state of the code base.
The Tensorflow team is constantly improving the framework by fixing bugs and adding new features. We suggest you try the latest TensorFlow version with the latest compatible hardware configuration which could potentially resolve the issue. If you are still facing the issue, please create a new GitHub issue with your latest findings, with all the debugging information which could help us investigate.
Please follow the release notes to stay up to date with the latest developments which are happening in the Tensorflow space.

I see tensorboard is still part of the requirements: https://github.com/tensorflow/tensorflow/blob/378a3a1d81b2bbc78f81188e4aa2fbe771148b51/tensorflow/tools/pip_package/setup.py#L112C6-L112C16


bug: fix 's height in /dashboard page

Description
The current height settings for <LoadingOverlay> in /dashboard page is not not right, i.e, the height is equals to the height of tab panel's body, while ideally it should be almost equals to calc(100vh - distance between top edge of tab panel body and html root <body>).
Check the following screenshot and you will see why we need this fix.

[Optional] Possible Solutions
NA
Acceptance Criteria

Fix the heigh of <LoadingOverlay> in /dashboard page and make it equals to calc(100vh - distance between top edge of tab panel body and html root <body>)

Todo list
NA

Fixed:

On mobile:
https://github.com/ppresume/community/assets/1164623/f6f5b0df-765f-496c-87cd-46de63f49890


[Python] Failing pandas tests because of downstream datetime64 unit changes

Pandas changed the default unit used in certain cases for the datetime64[unit] dtype. This causes some failures in our test suite when tested with pandas 3.0.0.dev

Issue resolved by pull request 41979
https://github.com/apache/arrow/pull/41979


[Question] How to set timestamps for submodels.

The submodel shouldn't be a new collection in the database...

Right now I do this as an alternative:
 @prop({default: Date.now()})
    createdAt: Date

The submodel shouldn't be a new collection in the database...

for this, you need to give an example, because it shouldnt create a new collection.

class LastStatus
  {
    @prop()
     prop1: string

   @prop()
    prop2:string
  }

class Person extends Typegoose {
 @prop()
  lastStatus: LastStatus

}
const PersonModel = new Person().getModelForClass(Person);

say here I want the lastStatus to have a timestamp

To avoid this right now I have something like this:
class LastStatus
  {
    @prop()
     prop1: string

   @prop()
    prop2:string

 @prop({default: Date.now()})
    createdAt: Date
  }

this should work without creating a new collection, a collection is only created when the document is saved, and not as a subdocument of a another document / model
import * as mongoose from "mongoose";
import { prop, Typegoose } from "./typegoose/src/typegoose";

class LastStatus extends Typegoose {
    @prop()
    public prop1: string;

    @prop({ required: true, default: Date.now() })
    public createdAt: Date;
}

class Person extends Typegoose {
    @prop({ required: true })
    public lastStatus: LastStatus;

    @prop()
    public prop3: string;

    @prop()
    public prop4: number;
}

const LastStatusModel = new LastStatus().getModelForClass(LastStatus);
const PersonModel = new Person().getModelForClass(Person);

(async () => {
    mongoose.set("debug", true);
    await mongoose.connect(`mongodb://mongodb:27017/`, {
        useNewUrlParser: true,
        useFindAndModify: true,
        useCreateIndex: true,
        dbName: "verify346",
        user: "user",
        pass: "passwd",
        authSource: "admin",
        autoIndex: true
    });

    const doc = new PersonModel({lastStatus: new LastStatusModel({})});
    await doc.save();
    console.log(doc.toObject());

    await mongoose.disconnect();
})();

Thanks again
Well if getModelForClass can be used without creation of a collection I think it would be better to have this instead of explicitly putting the createdAt property in the class:
const LastStatusModel = new LastStatus().getModelForClass({ schemaOptions: { timestamps: { createdAt: true } } });

is everything solved now?

@hasezoey  I have the same issue.
mongoose: 5.7.4
@hasezoey/typegoose: 6.0.0-32
Base Model:
const schemaOptions: SchemaOptions = {
  timestamps: true,
  toJSON: {
    virtuals: true,
    getters: true,
  },
};

@pre<any>('findOneAndUpdate', function(next) {
    //this._update.updatedAt = new Date(Date.now());
    next();
}) //@pre<T> -> https://github.com/nartc/nest-mean/issues/8
@modelOptions({ schemaOptions })
@ObjectType()
export abstract class BaseModel<T> {
    @prop({ default: () => Date.now()})
    @Field()
    createdAt: Date;

    @prop({ default: () => Date.now()})
    @Field()
    updatedAt: Date;

    @Field()
    id: string;
}

Location Model:
@ObjectType()
@index({ geoJson: 1, locationType: 1 }, { unique: true })
export class Location extends BaseModel<Location> {

  ...

  @arrayProp({ itemsRef: Picture })
  @Field(type=> [Picture], { nullable: true })
  pictures: Ref<Picture>[]

  static get model(): ModelType<Location> {
    return getModelForClass(Location);
  }

  static get modelName(): string {
    return this.model.modelName;
  }

  static createModel(): DocumentType<any> {
    return new this.model();
  }
}

Picture model:
export class Picture extends BaseModel<Picture> {
  @prop({ required: true })
  @Field({ nullable: true })
  key!: string;

  @prop()
  @Field({ nullable: true })
  url?: string;

  @Field(type => User)
  @prop({ref: {name: 'User'}, required: true})
  user!: Ref<User>;

  static get model(): ModelType<Picture> {
    return getModelForClass(Picture);
  }

  static get modelName(): string {
    return this.model.modelName;
  }

  static createModel(): DocumentType<any> {
    return new this.model();
  }
}

When I add  2 pictures to the location's pictures, the two pictures have the same createdAt and updatedAt timestamp.
Here is how I add a picture to a location:
    const dbLocation = await this.locationsService.findById(locationId);
    if(!dbLocation) {
      throw new UserInputError(`Can not find any location with ID#${locationId}`);
    }

    const newPicture = Picture.createModel();
    newPicture.key = pictureKey;
    newPicture.user = user;

    const dbPicture = await this.picturesService.create(newPicture);
    dbLocation.pictures = [dbPicture, ...dbLocation.pictures];

    await this.locationsService.update(locationId, dbLocation)

    return dbLocation;

The weird  thing about it is that's the only entity I have this issue with.
The work around I found to have it working is using an anonymous function that returns a Date.now() :
@prop({ default: () => Date.now() })
@Field()
createdAt: Date;

@hasezoey/typegoose: 6.0.0-32

update to @typegoose/typegoose@latest / 6.0.4

what does const newPicture = Picture.createModel(); do?

the two pictures have the same createdAt and updatedAt timestamp.

do you mean that when you just update one of them, both change?

otherwise, this dosnt seem to be an typegoose-created issue @cesar3030

Thanks for your quick response.
I updated to @typegoose/typegoose@latest and this is still happening if I don't use @prop({ default: () => Date.now() }).
const newPicture = Picture.createModel(); does: new getModelForClass(Picture)

the two pictures have the same createdAt and updatedAt timestamp.

I mean: I add two different pictures and the second one has the same timestamp as the first one even if the second one has been added 20 seconds after the second one:
First picture document:
{ "_id" : ObjectId("5dbc7c04c660a70020503d8c"), "createdAt" : ISODate("2019-11-01T18:39:03.297Z"), "updatedAt" : ISODate("2019-11-01T18:39:03.297Z"), "key" : "Location/35fde9f5-d1bc_2019-11-01T18:40:03.669Z_location.jpeg", "user" : ObjectId("5d8b7d95f9da06009bdce9bd"), "__v" : 0 }

Second picture document:
{ "_id" : ObjectId("5dbc7c04c660a70020503d8c"), "createdAt" : ISODate("2019-11-01T18:39:03.297Z"), "updatedAt" : ISODate("2019-11-01T18:39:03.297Z"), "key" : "Location/35fde9f5-d1bc_2019-11-01T18:40:03.669Z_location.jpeg", "user" : ObjectId("5d8b7d95f9da06009bdce9bd"), "__v" : 0 }

Each picture document has a key (Bucket key) which is composed of [uuid]_[timestamp]_[picture name].jpeg these keys are generated when the mobile app is requesting an AmazonS3 upload url to upload a picture to S3 from the mobile app. When the upload is done, the mobile app sends a request to my api to create a picture document with the key of the picture that has just been uploaded to S3 and add this new Picture document to the location's pictures array.
You can clearly tell by the timestamp in the key that it is not a concurrency issue since there is 20 seconds between the two urls are generating and I waited the first picture document to exists in the picture collection before uploading the seconde picture.

is your setup like this below, or functions called again for each picture?
// NodeJS: 12.13.0
// MongoDB: 4.2-bionic (Docker)
import { arrayProp, getModelForClass, modelOptions, prop } from "@typegoose/typegoose"; //<EMAIL_ADDRESS>import * as mongoose from "mongoose"; //<EMAIL_ADDRESS>
@modelOptions({ schemaOptions: { timestamps: true } })
class Nested {
    @prop()
    public hello?: string;
}

class Something {
    @arrayProp({ items: Nested })
    public nesty!: Nested[];
}
const SomethingModel = getModelForClass(Something);

(async () => {
    await mongoose.connect(`mongodb://localhost:27017/`, { useNewUrlParser: true, dbName: "verifyMASTER", useCreateIndex: true, useUnifiedTopology: true });

    const some = new SomethingModel();
    some.nesty.push({ hello: "1" });

    setTimeout(async () => {
        some.nesty.push({ hello: "2" });

        await some.save();

        console.log(some);

        await mongoose.disconnect();
    }, 1000);
})();

almost, nesty should be an array of refs.
  @arrayProp({ itemsRef: Nested })
  pictures: Ref<Nested>[]


parallel_tests gem support

parallel_tests gem allows running tests using multiple processes to speed up the process. The problem is that parallel_tests has its own spec discovery mechanism, so Stimpack's RSpec integration doesn't do anything.
One workaround we found is passing the name of the package directory through the fourth argument to parallel:spec works:
RAILS_ENV=test bundle exec rake 'parallel:spec[2,,,packs]'

It would be nice to find a better way to integrate into parallel_tests.

In the Ruby/Rails modularity slack server another user recommends an approach with parallel_tests:
https://rubymod.slack.com/archives/C02TLU33RNW/p1662063968955199?thread_ts=1660063285.310539&cid=C02TLU33RNW
(Here's an invite link to the server for anyone who is not in it.)
Would this work for you?
I think it would be interesting to allow Stimpack to permit plugins so users can add their own pack-based tooling integrations, but we're generally hesitant about adding too many integrations with a lot of tools that may not be applicable to all users.

Copying the solution over from Slack:
RAILS_ENV=test bundle exec parallel_test spec packs/**/spec -n 12 -t rspec

Yes, this also works, and looks more elegant. 👍

but we're generally hesitant about adding too many integrations

This makes sense. With parallel_tests in particular I don't think there's a clean way to hook into it, other than monkey patching. parallel_tests needs to add support for integrations on their end.
Either way, what we could do for now is to document the best known integration methods in README, and close the issue. What do you think?

That sounds great to me. I'm thinking an Ecosystem and Integrations section in the README where we can list recommended approaches for integrating with other tools!

I had a similar issue with Knapsack, another popular library for parallising specs execution.
I'll create a PR to add this new section to the README and include both solutions 👍


Improve type annotations (add more and fix wrong ones)

The origins of these are three-fold:

Merging in stubs from https://github.com/python/typeshed/tree/main/stubs/Markdown using "merge-pyi"

Note: we can consider these annotations to be the important ones because it's what people have been adding according to their own need

Double-checking around places where stubs were already added from the above, particularly conflicts with annotations that got added in this repository already

Taking the opportunity to declare a generic "Registry of T" class

Running "mypy" and eliminating the most glaring errors it reported

So there appears to be a couple code changes included in this (I don't mean adjustments to whitespace/line length). Could you please remove those? They should be submitted separately.

I only recognized one change that's clearly not about type annotations and reverted it.
I'm not sure if you also mean the NamedTuple change (which I think is on topic, as it's just the way to spell the same thing but with type annotations) or if there was something else.

I was thinking of the NameTuples, but you are correct, they do have type annotations. So nevermind on that.

Thanks for this. Some of the wrong annotations I completely missed.
I'll merge this after a changelog entry is added.

That is done

For future reference:

The main reason that nobody complained about the current type annotations is probably that they aren't actually used by type checkers. Unless a file named py.typed exists, the dominant type checker "mypy" ignores the types and asks you to install https://pypi.org/project/types-Markdown/ anyway.

If you are interested in a fully correct type-checked codebase (according to "mypy") as well as official external-facing type annotations support (by adding py.typed), let me know anytime, I can take up that task and help maintain this going forward. Otherwise that's all for now.

Note that you have a conflict with the changelog (presumably with #1392).
Regarding a fully correct type-checked codebase (according to "mypy")  that is probably a reasonable goal. Personally, I haven't really explored what's involved given that this is a rather new thing for Python. So contributions are welcome.

Note that you have a conflict with the changelog

Hm? I had already merged to resolve the conflict. There was just the spelling check failing

Regarding a fully correct type-checked codebase (according to "mypy") that is probably a reasonable goal.

Great, so I'll continue looking into this soon.

This PR almost closes #1389 :slightly_smiling_face:

Oh I didn't see that!
No there are still like 100 mypy errors so maybe not  "almost" 😅


The docs (https://react.semantic-ui.com) cause excessive CPU usage in Chrome

Bug Report
NOTE: Issue #3784 was accidentally closed (the PR to close was a README fix, so no way it solved the issue). This is a direct copy/paste from #3784 as this issue still persists (Sitting on the docs for semantic-ui easily causes 50% cpu usage)
Steps
Use Chrome to open the documentation pages for any component which contains examples
Expected Result
Chrome should not use more CPU than with other similar sites
Actual Result
According to Chrome's dev tools, the Rendering task "Recalculate Styles" runs continuously.
After a few moments my laptops fan kicks in and the laptop turns into a heater
Version
0.88.2
Screenshot

Further investigation:

if you load a page (I was on Checkbox docs) and stay on the top, the CPU holds at 40-45%. for as long as you stay there.
if you scroll to the bottom, the CPU drops back to normal (0.7%). You must scroll all the way until you see "This is the bottom".

This makes me think it has something to do with the Visibility component?
Staying on the top (or even just above the bottom) of a page will keep the CPU at 44% for as long as you remain there. As soon as you scroll to the bottom the CPU will jump for 1 tick, then go back to normal.

I agree that the issue is with react-visibility-sensor: https://github.com/joshwnj/react-visibility-sensor/issues/79
the module uses a function call getBoudingClientRect forcing web engine to recalculate the layout the function is known to be expensive.
VisibilitySensor._this.check @ visibility-sensor.js:250, a timer is also implemented which executes this function to handle edge cases when events may not be triggered by the user creates a performance bottleneck.

A possible fix could be to either remove the module and replace using intersection observer api: https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API or look into improving the performance for that function call, it has been suggested to implement a caching system in some way. I think intersection observer api may be the less expensive way to go performance wise because it uses a registered callback to handle entrance and exit of the view port, instead of firing constantly.

Thanks for catching this ❤  react-visibility-sensor should be replaced with react-intersection-observer. PRs are welcome 👍

I added the react-intersection-observer, to the docs ComponentExample and there is some notable differences in layout recalculations as seen from previous snapshots.
This is the Drop down component examples page. Looks like more scripting and less render calculations not sure if there needs to be more of a balance there or not?

Here is a snapshot of the form examples, I posted this for comparison with a form performance snapshot above in a previous comment. What I see here is the rendering calculations start to plane out which I think is what you are looking for.

(Sitting on the docs for semantic-ui easily causes 50% cpu usage)

I'm seeing this on a regular basis even now.  I can always tell when I have a tab open & active on one of these pages, my notebook fan is humming along at a good clip.

(Sitting on the docs for semantic-ui easily causes 50% cpu usage)

I'm seeing this on a regular basis even now.  I can always tell when I have a tab open & active on one of these pages, my notebook fan is humming along at a good clip.

Yeah, I'm seeing the same thing.

Yeah, I'm seeing the same thing.


Set enable_cleanup_closed=True to drop TLS connections without a shutdown

Description
AsyncOpenSearch seems to leak TLS connections due to a missing parameter in aiohttp.TCPConnector.
Issues Resolved
This fixes https://github.com/opensearch-project/opensearch-py/issues/172 and was also fixed "upstream" in this issue https://github.com/elastic/elasticsearch-py/issues/1910.
Also seems to be related to this https://github.com/aio-libs/aiohttp/issues/6490 (which is probably the root cause of the issue).
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Thanks! Could you please add a line to CHANGELOG and write a unit test (ideally showing that the leak is fixed, but at least that the parameter is passed through).

Sure, I can add a line to the changelog, but I won't have time to write a
unit test for this, sorry about that.
On Thu, Aug 3, 2023, 17:24 Daniel (dB.) Doubrovkine <
@.***> wrote:

Thanks! Could you please add a line to CHANGELOG and write a unit test
(ideally showing that the leak is fixed, but at least that the parameter is
passed through).
—
Reply to this email directly, view it on GitHub
https://github.com/opensearch-project/opensearch-py/pull/468#issuecomment-1664189798,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABP4VHX5QX7ETYREDSWGW7LXTO7DLANCNFSM6AAAAAA3C4WYHU
.
You are receiving this because you authored the thread.Message ID:
@.***>

Sure, I can add a line to the changelog, but I won't have time to write a unit test for this, sorry about that.
…
On Thu, Aug 3, 2023, 17:24 Daniel (dB.) Doubrovkine < @.> wrote: Thanks! Could you please add a line to CHANGELOG and write a unit test (ideally showing that the leak is fixed, but at least that the parameter is passed through). — Reply to this email directly, view it on GitHub <#468 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABP4VHX5QX7ETYREDSWGW7LXTO7DLANCNFSM6AAAAAA3C4WYHU . You are receiving this because you authored the thread.Message ID: @.>

We'll have to wait for one to merge this. Thanks for your help, hopefully someone can finish the PR.

@snemes, Could you please try to write a test when you have a moment? Thank you!

I tried to concoct a test for this but it became rather convoluted, so I gave up. Merging this as is. The documentation in https://docs.aiohttp.org/en/stable/client_reference.html is convincing enough that this is a harmless improvement that times out unclosed SSL connections.


v1.7.1

Reorganize the internals of this crate to be more coherent. (#46)
Bump to event-listener v3.0.0. (#43)

I would like to treat the https://github.com/smol-rs/async-process/pull/42 included in this release as a semver-minor change because it could potentially cause regressions

I would like to treat the #42 included in this release as a semver-minor change because it could potentially cause regressions

Good point, I missed that one. Fixed!


Thanks, small suggestion on function implementation

Thanks for writing this up, and linking it over in the typer repo!  good stuff :)
small suggestion on the function implementation.  the inspect.Signature object has some conveniences that provide all of the parameter binding and validation that you're doing here.  The following implementation

uses Signature.bind and apply_defaults to the same effect.
sets __signature__ so inspection of the returned object returns the proper value.
works when the default parameter isn't a typer.Option that has a default attribute
keeps all typing info of the original function using ParamSpec

from typing_extensions import ParamSpec
from typing import TypeVar, Callable
from functools import wraps
from inspect import signature

P = ParamSpec("P")
R = TypeVar("R")

def function(typer_command: Callable[P, R]) -> Callable[P, R]:

    sig = signature(typer_command)
    fixed_defaults = [
        p.replace(default=getattr(p.default, "default", p.default))
        for p in sig.parameters.values()
    ]
    new_sig = sig.replace(parameters=fixed_defaults)

    @wraps(typer_command)
    def wrapped(*args: P.args, **kwargs: P.kwargs) -> R:
        bound = new_sig.bind(*args, **kwargs)
        bound.apply_defaults()
        return typer_command(*bound.args, **bound.kwargs)

    wrapped.__signature__ = new_sig  # type: ignore
    return wrapped

feel free to use some/any of that if you like.  thanks again

Hello, Tally!
This is fascinating material, and I'm sorta shocked I didn't know about inspect.Signature.
In my defense, the code I actually use in my projects is the one that makes a dataclass out of a typer command, and I just threw in the function one at the end when I looked at the conversation about the issue and realized that this is what people wanted...
I can't do this today, likely tomorrow, else Monday.  I also accept pull requests...
Thanks again!!!

In my defense

No defense necessary!   Sorry for the somewhat obnoxious unsolicited advice 😂

Pff, I'm pathetically grateful for the interest.  :-D
Sure you don't wanna submit a pull request?  Add to your laurels, make this repo seem more important?

No, I’ll do the pull request later today!  Sorry, should have just done it to begin with :)


Use secure URLs for docs

The docs links used http:// in stead of https://
Rebuilt the binary and tested it locally, looks to be working correctly

I rebuilt the binary and it's bit-for-bit the same as what you've got here in 22ecfe4. :+1:
LGTM

LGTM

I rebuilt the binary and it's bit-for-bit the same as what you've got here in 22ecfe4.

Yay! I first tried to build on OS X, which didn't work, so created an ad-hoc build-container, which is the proper Docker way to tackle this :)
Perhaps I'll create a PR for a Dockerfile.build for the build-container :)


fix: ensure codeql still runs on main

Types of changes

[ ] Hot fix (emergency fix and release)
[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Documentation (change which affects the documentation site)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Release (develop -> main)

Quality assurance (all should be covered).

[x] My code follows the code style of this project.
[x] Documentation for my change is up to date?
[x] My PR meets testing requirements.
[x] All new and existing tests passed.
[x] All commits are signed-off.

Summary
Key links:

Sonar coverage

Before you merge

Ensure it is a 'squash commit' if not a release.
Ensure CI is currently passing
Check sonar. If you are working for a fork a maintainer will reach out, if required.

I'm not sure if this will fix the problem raised, however, it will definitely improve the situation


Improve local scheduler

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: skhalash:x: lindnerbyYou have signed the CLA already but the status is still pending? Let us recheck it.


[BUG] Fresh Install Blocker - Error: Cannot find package '@expo/spawn-async' when running pnpm dev

What happened?
Update: Seems to be an issue creating a new plasmo app inside a turbo repo. I've tried with pnpm and npm workspaces and all produce the same error on fresh installs.
Description:
I encountered an error when trying to run pnpm dev for a newly created Plasmo extension. The error indicates that the package @expo/spawn-async cannot be found. This issue seems to be related to the Plasmo dependencies.
Steps to Reproduce:

Run pnpm create plasmo to create a new Plasmo extension project. (I've also tried pnpm dlx ...'
Navigate to the project directory.
Run pnpm dev.

Expected Behavior:
The development server should start without any errors.
Actual Behavior:
The following error is displayed:
Error: Cannot find package 'E:\Web Projects\_CLIENTS\WITHSEISMIC\living-in-prague\prague-living-turbo\node_modules\.pnpm\plasmo@0.88.0_@swc+core@1.5.29_@swc+helpers@0.5.5__@swc+helpers@0.5.5_ejs@3.1.10_lodash<EMAIL_ADDRESS>imported from E:\Web Projects\_CLIENTS\WITHSEISMIC\living-in-prague\prague-living-turbo\node_modules\.pnpm\plasmo@0.88.0_@swc+core@1.5.29_@swc+helpers@0.5.5__@swc+helpers@0.5.5_ejs<EMAIL_ADDRESS>Did you mean to import<EMAIL_ADDRESS>    at legacyMainResolve (node:internal/modules/esm/resolve:210:26)
    at packageResolve (node:internal/modules/esm/resolve:828:14)
    at moduleResolve (node:internal/modules/esm/resolve:914:18)
    at defaultResolve (node:internal/modules/esm/resolve:1119:11)
    at ModuleLoader.defaultResolve (node:internal/modules/esm/loader:542:12)
    at ModuleLoader.resolve (node:internal/modules/esm/loader:511:25)
    at ModuleLoader.getModuleJob (node:internal/modules/esm/loader:241:38)
    at ModuleJob._link (node:internal/modules/esm/module_job:126:49) {
  code: 'ERR_MODULE_NOT_FOUND'
}

Environment:

Plasmo version: 0.88.0
Node.js version: v22.2.0
npm version: 8.1.0
Operating System: Windows 10

Additional Information:
I have tried the following troubleshooting steps without success:

Verified Node.js version compatibility (tried Node.js v18).
Deleted node_modules and pnpm-lock.yaml, then reinstalled dependencies.
Reinstalled Plasmo using pnpm add<EMAIL_ADDRESS>
Please let me know if you need any additional information or if there are any other steps I can take to resolve this issue.
Version
Latest
What OS are you seeing the problem on?
Windows
What browsers are you seeing the problem on?
No response
Relevant log output
Error: Cannot find package 'E:\Web Projects\_CLIENTS\WITHSEISMIC\living-in-prague\prague-living-turbo\node_modules\.pnpm\plasmo@0.88.0_@swc+core@1.5.29_@swc+helpers@0.5.5__@swc+helpers@0.5.5_ejs@3.1.10_lodash<EMAIL_ADDRESS>imported from E:\Web Projects\_CLIENTS\WITHSEISMIC\living-in-prague\prague-living-turbo\node_modules\.pnpm\plasmo@0.88.0_@swc+core@1.5.29_@swc+helpers@0.5.5__@swc+helpers@0.5.5_ejs<EMAIL_ADDRESS>Did you mean to import<EMAIL_ADDRESS>    at legacyMainResolve (node:internal/modules/esm/resolve:210:26)
    at packageResolve (node:internal/modules/esm/resolve:828:14)
    at moduleResolve (node:internal/modules/esm/resolve:914:18)
    at defaultResolve (node:internal/modules/esm/resolve:1119:11)
    at ModuleLoader.defaultResolve (node:internal/modules/esm/loader:542:12)
    at ModuleLoader.resolve (node:internal/modules/esm/loader:511:25)
    at ModuleLoader.getModuleJob (node:internal/modules/esm/loader:241:38)
    at ModuleJob._link (node:internal/modules/esm/module_job:126:49) {
  code: 'ERR_MODULE_NOT_FOUND'
}

(OPTIONAL) Contribution

[ ] I would like to fix this BUG via a PR

Code of Conduct

[X] I agree to follow this project's Code of Conduct
[X] I checked the current issues for duplicate problems.

Okay this is within a turbo repo. I've no idea if you can have turbos within turbos, but there we go.

Update: Seems to be an issue creating a new plasmo app inside a turbo repo. I've tried with pnpm and npm workspaces and all produce the same error on fresh installs.

I think I managed to solve this by updating to the latest pnpm v9.4.0 and running pnpm create plasmo. If anyone else is stuck here, can you give it a go?

I think I managed to solve this by updating to the latest pnpm v9.4.0 and running pnpm create plasmo. If anyone else is stuck here, can you give it a go?

for me what worked was solution here:
https://github.com/vercel/next.js/issues/48593#issuecomment-1681930868
"pnpm": {
"overrides": {
"<EMAIL_ADDRESS>"0.4.36"
}
}

I've encountered the same error on Windows with pnpm v9.6.0 (plasmo v0.88.0).
What worked for me was creating the application in a folder with a shorter file path.
For instance, if I create the project inside C:\folderwithreallyreallyreallylongname\chrome-plasmo-extension-tests I get the error, while C:\folderwithlongname\chrome-plasmo-extension-tests works correctly.

Encontrei o mesmo erro no Windows com o pnpm v9.6.0 (plasmo v0.88.0).
O que funcionou para mim foi criar o aplicativo em uma pasta com um caminho de arquivo mais curto. Por exemplo, se eu criar o projeto dentro, C:\folderwithreallyreallyreallylongname\chrome-plasmo-extension-testsrecebo o erro, enquanto C:\folderwithlongname\chrome-plasmo-extension-testsfunciona corretamente.

Thanks! That worked for me.

I've encountered the same error on Windows with pnpm v9.6.0 (plasmo v0.88.0).
What worked for me was creating the application in a folder with a shorter file path. For instance, if I create the project inside C:\folderwithreallyreallyreallylongname\chrome-plasmo-extension-tests I get the error, while C:\folderwithlongname\chrome-plasmo-extension-tests works correctly.

same here


Cannot register commands using registerCommandsIn

Hello, I have been stuck with registering commands by using registerCommandsIn
This is my code structure:
src
├── app-loader.ts
├── commands
│   ├── bet-create.ts
│   └── dank.ts
├── controllers
├── entities
│   ├── bet.js
│   ├── match.ts
│   └── user.ts
├── migration
├── test-commands
│   ├── reply.ts
│   └── user-info.ts
└── types
    └── dank.js

This is the content of app-loader.ts:
import Commando, { CommandoClient } from 'discord.js-commando'
const path = require('path')

const client = new CommandoClient({
  owner: process.env.OWNER,
  commandPrefix: '!gvn'
})

/**
 * All Discord events are listed here:
 */
client
  .on('ready', () => {
    console.log(`Client ready; logged in as ${client.user.username}#${client.user.discriminator} (${client.user.id})`)
  })
  .on('message', (msg: any) => {
    // console.log(msg)
  })
  .on('commandError', (cmd, err) => {
    if(err instanceof Commando.FriendlyError) return;
		console.error(`Error in command ${cmd.groupID}:${cmd.memberName}`, err);
  })

client.registry
  .registerGroups([
    ['bet', 'Bet commands']
  ])
  .registerDefaults()
  .registerTypesIn(path.join(__dirname, '/types/'))
  .registerCommandsIn(path.join(__dirname, '/test-commands/'));

// Start the client:
client.login(process.env.DISCORD_TOKEN)

Within reply.ts, I tried to create a very simple command:
const { Command } = require('discord.js-commando');

module.exports = class ReplyCommand extends Command {
  constructor(client) {
    super(client, {
      name: 'reply',
      group: 'bet',
      memberName: 'reply',
      description: 'Replies with a Message.',
      examples: ['reply']
    });
  }

  run(msg) {
    return msg.say('Hi, I\'m awake!');
  }
};

But no luck, I always get the error
Unknown command. Use help to view the list of all commands.

I also checked the path created by path.join(__dirname, '/test-commands/') . But it definitely points to correct directory (otherwise it will fires an error when compiling), so I don't think it's path problem.
What am I missing here?
Edit: Link to the repo.

Edit: I found out that there are problems with "require-all" (which is internally used by commando). So I decided to create an umbrella index.ts file then export those commands as array:
// tsconfig.json:
{
   "compilerOptions": {
      "lib": [
         "es2015"
      ],
      "target": "es6",
      "pretty": true,
      "module": "commonjs",
      "declaration": true,
      "moduleResolution": "node",
      "outDir": "./build",
      "allowSyntheticDefaultImports": true,
      "emitDecoratorMetadata": true,
      "experimentalDecorators": true,
      "sourceMap": true
   }
 }

// index.ts
import { BetCreate } from './bet-create'

module.exports = [
  BetCreate
]

The default structure for the commands directory requires nested subdirectories named after the group IDs, and the command files named after their memberName within those.

I know this is a super late response to this issue, but here's the solution for anybody who runs into the same issue when working with Commando in TypeScript:
require-all by default only requires files with the extension(s) .js(on).
Specify a custom filter to include .ts files and voilà.
  .registerCommandsIn({
    filter: /^([^.].*)\.(js|ts)$/,
    dirname: join(__dirname, 'commands'),
  })

Even after adding that filter, Commando is still not registering my commands when running ts-node. I am using v12.5.1 of discord.js and v0.11.1 of discord.js/commando

I know this is a super late response to this issue, but here's the solution for anybody who runs into the same issue when working with Commando in TypeScript:
require-all by default only requires files with the extension(s) .js(on).
Specify a custom filter to include .ts files and voilà.
  .registerCommandsIn({
    filter: /^([^.].*)\.(js|ts)$/,
    dirname: join(__dirname, 'commands'),
  })

Even after adding that filter, Commando is still not registering my commands when running ts-node. I am using v12.5.1 of discord.js and v0.11.1 of discord.js/commando


Example code in the Badges documentation referencess an unused "icon" class

In the badges documentation there's the following example:

account_box

account_box

It applies the icon class, however this class isn't used in the CSS. I'm presuming this is a mistake and should be removed from the example?

ah yes, that is from an older build of the docs I believe. Updating to remove them now.


[TC-ACL-2.2] require more verifiable infomations

Summary Title:
[TC-ACL-2.2] require more verifiable infomations
Description:
Python script does not present verifiable information. Unable to verify.
Steps to reproduce:

Before commission to DUT, make sure DUT in comission mode.
Choose TC-ACL-2.2 and run test-case in TH.

Logs:
[TC-TC-ACL-2.2]_[zNw7rlE3]_TH_log.log

Can you please confirm whether this was fixed for you with the addition of the trace data in the test harness?

This case was passed at the SVE, can be considered to have been fixed.


Update network-watcher-nsg-flow-logging-overview.md

Added a Costs section to mimic the VNet flow logs page. Updated the pricing section for the same reason.
Both log collection types follow the same pricing model so having similar pricing and costs section would be beneficial to users.

@halkazwini

Can you review this PR?
IMPORTANT: When this content is ready to merge, you must add #sign-off in a comment or the approval may get overlooked.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

@kyjones03
Thank you for your contribution!


[Bug Report]: relative import is not working in scss

Steps to reproduce
clone https://github.com/rushi3691/farm-sass-issue

install dependencies - npm i
run - npm start (which works fine)
run - npm run start:farm (doesn't work)

Reproduce link
No response
What is actually happening?
the project contains some .scss files with some image imports, farm is not able to detect those imports and throwing error
[ Farm ] Error: Failed to start the server
Caused by: Error: Can not resolve ../../../images/Truck_wallpaper.jpg from src/assets/scss/theme.scss.
Original error: None.
Potential Causes:
1.The file that ../../../images/Truck_wallpaper.jpg points to does not exist.
2.Install it first if ../../../images/Truck_wallpaper.jpg is an dependency from node_modules, if you are using pnpm refer to [https://pnpm.io/faq#pnpm-does-not-work-with-your-project-here] for solutions.
3. If ../../../images/Truck_wallpaper.jpg is a alias, make sure your alias config is correct.
System Info
System:
    OS: Linux 6.8 Ubuntu 24.04.1 LTS 24.04.1 LTS (Noble Numbat)
    CPU: (16) x64 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz
    Memory: 5.05 GB / 15.32 GB
    Container: Yes
    Shell: 5.9 - /usr/bin/zsh
  Binaries:
    Node: 20.16.0 - ~/.nvm/versions/node/v20.16.0/bin/node
    npm: 10.8.1 - ~/.nvm/versions/node/v20.16.0/bin/npm
    pnpm: 9.7.0 - ~/.bun/bin/pnpm
    bun: 1.1.26 - ~/.bun/bin/bun
  Browsers:
    Chrome: 128.0.6613.137
  npmPackages:
    @farmfe/core: ^1.3.21 => 1.3.21

It is recommended to use aliases to load resources in public scss files


TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.
If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.
If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/99519

Triggering TagBot for merged registry pull request
This extra notification is being sent because I expected a tag to exist by now, but it doesn't.
You may want to check your TagBot configuration to ensure that it's running, and if it is, check the logs to make sure that there are no errors.


[QUESTION] CMake Error: protobuf cannot be found

I am trying to build this on a ppc64le machine, which integrates torch models into the simulation software LAMMPS (c++). I realize this is perhaps not the place to ask about LAMMPS, but since the error message specifies the torch configuration, I hope there's a chance that I could get some help.
Attempting the build with open-ce 1.5.1, 1.6.1, and 1.7.2 all lead to the same error:
CMake Warning at /opt/miniconda3/envs/opence-v1.7.2/lib/python3.9/site-packages/torch/share/cmake/Caffe2/public/protobuf.cmake:88 (message):
  Protobuf cannot be found.  Depending on whether you are building Caffe2 or
  a Caffe2 dependent library, the next warning / error will give you more
  info.
Call Stack (most recent call first):
  /opt/miniconda3/envs/opence-v1.7.2/lib/python3.9/site-packages/torch/share/cmake/Caffe2/Caffe2Config.cmake:56 (include)
  /opt/miniconda3/envs/opence-v1.7.2/lib/python3.9/site-packages/torch/share/cmake/Torch/TorchConfig.cmake:68 (find_package)
  CMakeLists.txt:922 (find_package)

CMake Error at /opt/miniconda3/envs/opence-v1.7.2/lib/python3.9/site-packages/torch/share/cmake/Caffe2/Caffe2Config.cmake:58 (message):
  Your installed Caffe2 version uses protobuf but the protobuf library cannot
  be found.  Did you accidentally remove it, or have you set the right
  CMAKE_PREFIX_PATH? If you do not have protobuf, you will need to install
  protobuf and set the library path accordingly.
Call Stack (most recent call first):
  /opt/miniconda3/envs/opence-v1.7.2/lib/python3.9/site-packages/torch/share/cmake/Torch/TorchConfig.cmake:68 (find_package)
  CMakeLists.txt:922 (find_package)

-- Configuring incomplete, errors occurred!

This is confusing since protobuf actually does exist:
$ conda list | grep protobuf
libprotobuf               3.19.4               h690f14c_0    conda-forge
protobuf                  3.19.4           py39had50986_0    conda-forge

What are the appropriate library paths to set?
[edit] an example from scratch:
git clone -b stable https://github.com/lammps/lammps.git test_lammps
git clone https://github.com/mir-group/pair_nequip.git
cd pair_nequip/
./patch_lammps.sh ../test_lammps/
cd ../test_lammps/
mkdir build
cd build/
cmake ../cmake -DCMAKE_PREFIX_PATH=`python -c 'import torch;print(torch.utils.cmake_prefix_path)'`

Please share the steps that you are using to build the pair_nequip package alongside OpenCE.

I've updated the question with some steps to try and reproduce

Thanks @kkly1995. I will try with these.

Could you please install protobuf from Anaconda's default channel instead of pulling it from conda-forge and retry the build.
Also please share output of conda list from your build environment.

Our packages in Open-CE 1.6.1 are built with protobuf 3.19. So, conflicts when packages are installed along with protobuf 3.9 are expected.

The following works for me:
conda create -y -n dctest_lammps
conda activate dctest_lammps
conda install -c https://ftp.osuosl.org/pub/open-ce/1.6.1/ pytorch=1.10.2=cuda11.2_py38_1 protobuf python=3.8 cmake gxx_linux-ppc64le

git clone -b stable https://github.com/lammps/lammps.git test_lammps
git clone https://github.com/mir-group/pair_nequip.git
cd pair_nequip/
./patch_lammps.sh ../test_lammps/
cd ../test_lammps/
mkdir build
cd build/
cmake ../cmake -DCMAKE_PREFIX_PATH=`python -c 'import torch;print(torch.utils.cmake_prefix_path)'`

-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Caffe2: Found protobuf with new-style protobuf targets.
-- Caffe2: Protobuf version 3.19.1

Are you building the package on baremetal or container?

I am building on bare. It looks like using conda's cmake is what makes the difference. How come this is necessary here, but not so in environment with the CPU version?

Ideally, cmake should be installed in the conda environment for both use cases. Perhaps you also have cmake installed on your system?

@kkly1995 Is there anything left for us to help you with?

Please reopen if something is still not working


Strange escaping of ampersand followed by LT

Maybe I missed something but I was surprised by the following result when cleaning some html.
Considering:
 String html = "
John&LT Dow
";

Jsoup.clean(html, Safelist.basic()) will produce
John< Dow
.
I was expecting
John&LT Dow
.
Is there a reason why &LT is interpreted as an incomplete < as opposed to & followed by the letters LT ?

Yes, that's the expected outcome, as per the HTML5 spec. For named entities not within an attribute, the trailing ; is optional. See https://html.spec.whatwg.org/multipage/parsing.html#named-character-reference-state
You can check in a browser, you'll get the same result.
It does get emitted as an error (see this example), so you could conceivably handle it differently if you wanted to.


chore(deps): update dependency javax.servlet:javax.servlet-api to v4

This PR contains the following updates:

Package
Update
Change
References

javax.servlet:javax.servlet-api
major
3.0.1 -> 4.0.1
homepage, source

Release Notes

javaee/servlet-spec
v4.0.1
Compare Source
v4.0.0
Compare Source
v3.1.0
Compare Source

Renovate configuration
:date: Schedule: At any time (no schedule defined).
:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.
:recycle: Rebasing: Whenever PR is stale, or if you modify the PR title to begin with "rebase!".
:no_bell: Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

Available now for Enterprise: Renovate Pro with real-time webhook handling and priority job queue.

PR has been edited
:construction_worker: This PR has received other commits, so Renovate will stop updating it to avoid conflicts or other problems. If you wish to abandon your changes and have Renovate start over you may click the "rebase" checkbox in the PR body/description.

PR has been edited
:construction_worker: This PR has received other commits, so Renovate will stop updating it to avoid conflicts or other problems. If you wish to abandon your changes and have Renovate start over you may click the "rebase" checkbox in the PR body/description.


Automated cherry pick of #4445: not return on recv packet failed

Cherry pick of #4445 on release/2.10.0.
#4445: not return on recv packet failed

Codecov Report

:exclamation: No coverage uploaded for pull request base (release/2.10.0@84fe82d). Click here to learn what that means.
The diff coverage is n/a.

@@               Coverage Diff                @@
##             release/2.10.0   #4449   +/-   ##
================================================
  Coverage                  ?   7.47%
================================================
  Files                     ?     418
  Lines                     ?   66695
  Branches                  ?       0
================================================
  Hits                      ?    4984
  Misses                    ?   61285
  Partials                  ?     426

Flag
Coverage Δ

#aFlag
7.47% <ø> (?)

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 84fe82d...5a76023. Read the comment docs.

/lgtm
/approve


Enhance prompt output reader to store buffered output and update tests

What this PR does / why we need it:
De-flakes and makes tests involving interactive behaviour more legible
Does this PR introduce a user-facing change?

NONE

Additional Notes for your reviewer:

The "KCTRL_DEBUG_BUFERED_OUTPUT_TESTS" env variable helps debug tests using prompt output if set to "true". This might help out when we add more tests (table tests maybe?)

Review Checklist:

[x] Follows the developer guidelines
[x] Relevant tests are added or updated
[x] Relevant docs in this repo added or updated
[x] Relevant carvel.dev docs added or updated in a separate PR and there's
a link to that PR
[x] Code is at least as readable and maintainable as it was before this
change

Additional documentation e.g., Proposal, usage docs, etc.:

PS: There's some cleanup pending, now redundant parts of prompt output can be removed

All cleaned up!
@rohitagg2020 feel free to merge away once this goes green, I think it is good to go
Further changes to tests would include adding more cases as per #828
We can reliably wait for questions now. We can comfortably add table tests as they would be legible and won't require a \n delimiter to pick up questions.


Error while installing: Failed to load icon: steam_oldglory.ico

Distro: Arch Linux
Failed to load icon: steam_oldglory.ico
Traceback (most recent call last):
  File "/home/posaydone/SteamUI-OldGlory/old_glory.py", line 1469, in add_window_icon
    icon = PhotoImage(file=icon_filename)
NameError: name 'PhotoImage' is not defined

Ah, a little slipup with the icon for Linux. Fixed for the next release (5.5).

Ah, a little slipup with the icon for Linux. Fixed for the next release (5.5).


AbstractWaitStrategy is not exported.

I'm trying to make a custom wait strategy, which ideally would extend the AbstractWaitStrategy, to take out the boilerplate, like the startUpTimeout stuff. However, AbstractWaitStrategy is not exported, line all the other classes which extend it.

Hi @david-induro, indeed the wait strategy implementations are purposefully not exported so that they can be changed without potential breaking changes. The wait strategies provided should already provide all you need, if not I'd love to hear what it is and maybe we could raise a PR here so others would also benefit

The wait strategies provided should already provide all you need, if not I'd love to hear what it is and maybe we could raise a PR here so others would also benefit

For me, there's a use case in which I have to wait for the application within docker to partially initialize, which in this case, would not usually satisfy some of the provided wait strategies. Of course there's always an option to add some log text to indicate this state, but I think the flexibility of extension would be nice as well.

@cwkang1998 If the host-port or log wait strategies are insufficient, you can always provide your own health-check wait strategy like so:
const container = await new GenericContainer("alpine")
  .withHealthCheck({
    test: "curl -f http://localhost || exit 1",
    interval: 1000,
    timeout: 3000,
    retries: 5,
    startPeriod: 1000
  })
  .withWaitStrategy(Wait.forHealthCheck())
  .start();

You could put anything you like in the test. What use case isn't covered by these wait strategies?

@cwkang1998 If the host-port or log wait strategies are insufficient, you can provide a health-check wait strategy:
const container = await new GenericContainer("alpine")
  .withHealthCheck({
    test: "curl -f http://localhost || exit 1",
    interval: 1000,
    timeout: 3000,
    retries: 5,
    startPeriod: 1000
  })
  .withWaitStrategy(Wait.forHealthCheck())
  .start();

You could put anything you like as the health check. What use case isn't covered by this?

One use case that is more specific to me, is the reliance on the use of sdk to infer the readiness of the testcontainers. Yes, I am aware that I can implement something via the current provided wait strategy that is similar to doing so via the sdk itself, but a more consistent and uniform use of the sdk would be preferable.
To put it in code instead of words:
class CustomWaitStrategy implements WaitStrategy {
    constructor(private readonly sdkInstance: SdkInstance) {}
   public async waitUntilReady(container: Dockerode.Container, boundPorts: BoundPorts): Promise<void> {
        await this.sdkInstance.waitForModuleAReady()
   }

  public withStartupTimeout(startupTimeout: number): WaitStrategy {
    this.startupTimeout = startupTimeout;
    return this;
  }
}

Technically its already possible to implement a custom wait strategy via the WaitStrategy interface, but just thought I would like to share my thoughts xD.

I will look into exposing these classes if there is more interest, for now I believe this is such a niche use case that I would rather keep the flexibility to make non-breaking changes.


gyp: name 'openssl_fips' is not defined while evaluating condition 'openssl_fips != ""' in node_modules/node-addon-api/node_api.gyp while loading dependencies of binding.gyp while trying to load binding.gyp

node -v: v18.9.0
node-gyp --version: v9.1.0
prebuilfidy -- ^5.0.1
Hi, I'm trying to use prebuildify in my project: https://github.com/vaguue/net-runner-engine. Now only linux-x64 is supported. When I run prebuildify --target v18.9.0 everything seems to be fine, however, when I run prebuildify --all I get this error:
gyp: name 'openssl_fips' is not defined while evaluating condition 'openssl_fips != ""' in node_modules/node-addon-api/node_api.gyp while loading dependencies of binding.gyp while trying to load binding.gyp
Thanks in advance!

It's not an issue in prebuildify. Can be solved by adding openssl_fips to your binding.gyp.
Example: https://github.com/Level/classic-level/commit/b3f8517611f1e479d92b80ef4714bb8a4f0fa7c6


Not working with recommended bucket policy

Aws::S3::Errors::AccessDenied in Admin::ApurationsController#create

I keep getting S3 permission denied

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": "arn:aws:s3:::tradertax-files",
            "Principal": {
                "AWS": "XXX"
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:PutObjectAcl",
                "s3:GetObject",
                "s3:DeleteObject"
            ],
            "Resource": "arn:aws:s3:::tradertax-files/*",
            "Principal": {
                "AWS": "XXX"
            }
        }
    ]
}

I already restarted, added correct credentials, add my user as root even, and this policy is not working. ideas?

Can you share your carrierwave configuration, and, if you're overriding inside the uploader, that configuration as well?


Fix extension init command for non Windows users

This PR implements the fix suggested in issue 363.
Currently tfx extension init is broken for anyone on a non Windows system.
The code in this PR now checks for both \ and / when checking a file path, instead of just checking what Windows uses, \.

Thanks for the contribution!


Convert 2 log messages WARN->INFO

As far as I can tell AWS_ROLE_ARN and AWS_WEB_IDENTITY_TOKEN_FILE are optional, so I don't think it's appropriate to log those as WARN, as that implies something has gone wrong.
My motivation at creating this PR is that my logs are getting filled with warning messages like:
WARNING: Token file must be specified to use STS AssumeRole web identity creds provider.
Check all that applies:

[x] Did a review by yourself.
[ ] Added proper tests to cover this PR. (If tests are not applicable, explain.)
[ ] Checked if this PR is a breaking (APIs have been changed) change.
[ ] Checked if this PR will not introduce cross-platform inconsistent behavior.
[ ] Checked if this PR would require a ReadMe/Wiki update.

Check which platforms you have built SDK on to verify the correctness of this PR.

[ ] Linux
[ ] Windows
[ ] Android
[ ] MacOS
[ ] IOS
[ ] Other Platforms

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Hello,
Sorry to say this, but these log lines must be present in order to notify about the error use-case because both token file and role ARN must be present for STSAssumeRoleWebIdentityCredentialsProvider to work.
I would suggest checking why you see these warnings in your logs, i.e. why you need to use STSAssumeRoleWebIdentityCredentialsProvider when it fails to properly initialize.
Best regards,
Sergey

Thanks for the feedback @serzhick. I don't intentionally/directly use STSAssumeRoleWebIdentityCredentialsProvider, however I do use DefaultAWSCredentialsProviderChain, which creates a STSAssumeRoleWebIdentityCredentialsProvider. How would you suggest I get around this? Should I be creating my own class derived from AWSCredentialsProviderChain?


The final line does not seem to be complete

The final line in this doc seems to be incomplete. I'm not sure what it was supposed to say, so I can't create a PR to fix it.

The .NET 5 version and .NET 6 version with the WebApplicationFactory by design.

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

ID: 20acee3e-8b6e-b3fb-8271-661e1a287bdd
Version Independent ID: 20acee3e-8b6e-b3fb-8271-661e1a287bdd
Content: Code samples migrated to the new minimal hosting model in 6.0
Content Source: aspnetcore/migration/50-to-60-samples.md
Product: aspnet-core
Technology: aspnetcore-migration
GitHub Login: @Rick-Anderson
Microsoft Alias: riande

@jonas-lomholdt thanks for pointing that out. Fix will be live soon.

@jonas-lomholdt thanks for pointing that out. Fix will be live soon.

Awesome! Thanks.


Changed to safe_load with yaml

Cloes #6

Codecov Report

Merging #7 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master       #7   +/-   ##
=======================================
  Coverage   73.68%   73.68%
=======================================
  Files           5        5
  Lines         361      361
=======================================
  Hits          266      266
  Misses         95       95

Impacted Files
Coverage Δ

yamanifest/manifest.py
82.4% <100%> (ø)
:arrow_up:

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 5906251...39c9cc6. Read the comment docs.


[IntelliJ Plugin] Improve handling ballerina source files inside non-ballerina projects

Purpose
Fixes #20718.
Remarks

Related PR - #21273

Check List

[ ] Read the Contributing Guide
[ ] Updated Change Log
[ ] Checked Tooling Support (#)
[ ] Added necessary tests

[ ] Unit Tests
[ ] Spec Conformance Tests
[ ] Integration Tests
[ ] Ballerina By Example Tests

[ ] Increased Test Coverage
[ ] Added necessary documentation

[ ] API documentation
[ ] Module documentation in Module.md files
[ ] Ballerina By Examples

Codecov Report

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

@@           Coverage Diff           @@
##           master   #21306   +/-   ##
=======================================
  Coverage   14.64%   14.64%
=======================================
  Files          51       51
  Lines        1400     1400
  Branches      214      214
=======================================
  Hits          205      205
  Misses       1179     1179
  Partials       16       16

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 7ca2edd...ba6ba48. Read the comment docs.


markerimageElement isn't working

I'm using the .html loaded versions of this library, and whenever I try to load an image as my marker, I just get the default.
I can easily create an image and just load it in the page by injecting it to the , but haven't been able to get the icon working for me. My goal is to have a distinct icon per point (basically a thumbnail picture of a person), and was planning to drawPoints multiple times to do that, but if I could feed in the marker details where I have title/address/coordinates that would be great too.
                    const peopleMap = await createMap(
                        {
                            container: "peopleMap",
                            center: [-101.8151056, 36.2153979],
                            zoom: 3,
                        }
                    );
                    people = [{coordinates: [lon,lat], title: "hello", address: "there"}],
                    const myImg = new Image();
                    myImg.src = 'https://pathToMyImage.com/foobarbazImage;
                    myImg.alt = "myImage";
                    drawPoints(
                        "people",
                        people,
                        peopleMap,
                        {
                            "unclusteredOptions": {
                                "markerimageElement": myImg
                            }
                        }
                    );

    <script src="https://cdn.amplify.aws/packages/maplibre-gl/1.15.2/maplibre-gl.js" integrity="sha384-rwYfkmAOpciZS2bDuwZ/Xa/Gog6jXem8D/whm3wnsZSVFemDDlprcUXHnDDUcrNU" crossorigin="anonymous" referrerpolicy="no-referrer"></script>
    <script src="https://cdn.amplify.aws/packages/core/4.3.0/aws-amplify-core.min.js" integrity="sha384-7Oh+5w0l7XGyYvSqbKi2Q7SA5K640V5nyW2/LEbevDQEV1HMJqJLA1A00z2hu8fJ" crossorigin="anonymous" referrerpolicy="no-referrer"></script>
    <script src="https://cdn.amplify.aws/packages/auth/4.3.8/aws-amplify-auth.min.js" integrity="sha384-jfkXCEfYyVmDXYKlgWNwv54xRaZgk14m7sjeb2jLVBtUXCD2p+WU8YZ2mPZ9Xbdw" crossorigin="anonymous" referrerpolicy="no-referrer"></script>
    <script src="https://cdn.amplify.aws/packages/geo/1.1.0/aws-amplify-geo.min.js" integrity="sha384-TFMTyWuCbiptXTzvOgzJbV8TPUupG1rA1AVrznAhCSpXTIdGw82bGd8RTk5rr3nP" crossorigin="anonymous" referrerpolicy="no-referrer"></script>
    <script src="https://cdn.amplify.aws/packages/maplibre-gl-js-amplify/1.1.0/maplibre-gl-js-amplify.umd.min.js" integrity="sha384-7/RxWonKW1nM9zCKiwU9x6bkQTjldosg0D1vZYm0Zj+K/vUSnA3sOMhlRRWAtHPi" crossorigin="anonymous" referrerpolicy="no-referrer"></script>
    <script src="https://cdn.amplify.aws/packages/maplibre-gl-geocoder/1.1.0/maplibre-gl-geocoder.min.js" integrity="sha384-kB2/fEHOpfHm1Gzute77/GLQw40BlWkV4XCaqQ/+P8zPIwUm4X5gZxcYx7Nj3tpC" crossorigin="anonymous" referrerpolicy="no-referrer"></script>
    <link href="https://cdn.amplify.aws/packages/maplibre-gl-geocoder/1.1.0/maplibre-gl-geocoder.css" rel="stylesheet" integrity="sha384-9INm4qwCgRPHsynDw8uatP2FHVIMItwPU+PH8RtOzYAGEjU4Hiirfmuc3Rsa/pBq" crossorigin="anonymous" referrerpolicy="no-referrer"></link>
    <link href="https://cdn.amplify.aws/packages/maplibre-gl/1.15.2/maplibre-gl.css" rel="stylesheet" integrity="sha384-DrPVD9GufrxGb7kWwRv0CywpXTmfvbKOZ5i5pN7urmIThew0zXKTME+gutUgtpeD" crossorigin="anonymous" referrerpolicy="no-referrer"></link>

I've got a similar problem. In my case working with React.
I'm trying to use drawPoints() to draw custom icons. I've follow the guide but it's stil showing the default icons.
First I imported the library and the icon.
import { drawPoints } from "maplibre-gl-js-amplify";
import CustomIcon from 'assets/Aubo-logo.png';

Then I declared this, as the documentation mentioned (I try it declaring it at the beginning of the script right after the import of libraries, and also right before the map.on("load",....), but same result.
//custom icon
const icon = new Image(100,100);
icon.src = CustomIcon;

Then I declared a functional component (React), and inside the useEffect() hook after creating the map I load this.

I'm passing it the icon object that I declared at the beginning, but it shows the default icons? Why is this happening? or What am I doing wrong? Thanks.

@AuboIoT this update hasn't been released to NPM yet but it is available on the unstable release - https://github.com/aws-amplify/maplibre-gl-js-amplify/releases/tag/v1.3.0-unstable.1
@shafkevi this may be due to the html loaded version not having the latest release, will look into this, thanks for bringing it up!

Verified that custom icons can now be shown on a map after above merge.

@AuboIoT, @shafkevi
Please verify if it works on your side so we can close the issue.