Energy Dashboard: First value of the day wrong (too high)

Describe the bug
Energy Dashboard (new statistic api):
Over the day the solaryield recording value of the first hour of the day with yield>0 rises (every hour?) and is way too high at the end of the day.
Screenshots show the same day at 3 different times.
Value (12:00-13:00) is correct at 15:39 and gets bigger (see 18:47 and 19:2).
To Reproduce
Use new statistic api for record values (solar, ch, dhw) .
Screenshots

Version

HA version 2023.8.1
HA Bosch component version 0.23.2

** Debug SCAN **
https://drive.google.com/file/d/145_q7vAubtqRHgQmXWFladxCCWg8tk1Y/view?usp=drivesdk

Not a special issue regarding the solaryield.
ActualCHpower is also getting bigger over the day

fyi:
My workaround is to delete the recording-statistics of the current day at 23:50.
With the next "run" the data for the whole day is added again and stays correct.

Please check out https://github.com/bosch-thermostat/home-assistant-bosch-custom-component/releases/tag/v0.23.3
I will reopen if problem'd still occur.

Looks good for todays data.
Thanks a lot!

Please check out https://github.com/bosch-thermostat/home-assistant-bosch-custom-component/releases/tag/v0.23.3 I will reopen if problem'd still occur.

Unfortunately the problem does still occur with the dhw recording (maybe also ch, it's still too warm to see).
Solaryield looks fine.

Please enable debug logs, find relevant ones and attach here.

Please enable debug logs, find relevant ones and attach here.

The dhwpower-value today 13-14 was 2.7.
Looks like the 2.7 are added to the "sum" every following hour.
Find the log attached. I hope this helps and thanks a lot for your effort!!
bosch_home-assistant_short.log
bosch_home-assistant.log

I'll take another look at this. What timezone are you in? Is HA timezone same as your device?

I'm in GMT+1 (Berlin).
HA and device have the same time.

It looks like the "sum" field is not calculated correctly. I set it up initially and somehow it starts with the value 277 instead of 0:
sqlite> select * from statistics where metadata_id=68; 229672|||||||8.0|277.0|68|1697436392.31216|1697432400.0| 229732|||||||2.0|279.0|68|1697439960.86276|1697436000.0| 229792|||||||3.0|282.0|68|1697443560.80928|1697439600.0| 229853|||||||1.0|283.0|68|1697447160.79825|1697443200.0| 229914|||||||1.0|284.0|68|1697450760.81171|1697446800.0| 229974|||||||2.0|286.0|68|1697454360.78511|1697450400.0| 230038|||||||1.0|287.0|68|1697457962.15749|1697454000.0| 230096|||||||1.0|288.0|68|1697461560.79043|1697457600.0| 230157|||||||1.0|289.0|68|1697465160.83549|1697461200.0| 230278|||||||1.0|290.0|68|1697472360.81009|1697468400.0| 230339|||||||1.0|291.0|68|1697475960.84639|1697472000.0| 230400|||||||1.0|292.0|68|1697479560.84954|1697475600.0| 230460|||||||1.0|293.0|68|1697483160.82669|1697479200.0| 230522|||||||1.0|294.0|68|1697486760.86455|1697482800.0| 230583|||||||1.0|295.0|68|1697490360.87519|1697486400.0|
I tried fixing it manually while HA was shut down:
sqlite> select * from statistics where metadata_id=68; 229672|||||||8.0|8.0|68|1697436392.31216|1697432400.0| 229732|||||||2.0|10.0|68|1697439960.86276|1697436000.0| 229792|||||||3.0|13.0|68|1697443560.80928|1697439600.0| 229853|||||||1.0|14.0|68|1697447160.79825|1697443200.0| 229914|||||||1.0|15.0|68|1697450760.81171|1697446800.0| 229974|||||||2.0|17.0|68|1697454360.78511|1697450400.0| 230038|||||||1.0|18.0|68|1697457962.15749|1697454000.0| 230096|||||||1.0|19.0|68|1697461560.79043|1697457600.0| 230157|||||||1.0|20.0|68|1697465160.83549|1697461200.0| 230278|||||||1.0|21.0|68|1697472360.81009|1697468400.0| 230339|||||||1.0|22.0|68|1697475960.84639|1697472000.0| 230400|||||||1.0|23.0|68|1697479560.84954|1697475600.0| 230460|||||||1.0|24.0|68|1697483160.82669|1697479200.0| 230522|||||||1.0|25.0|68|1697486760.86455|1697482800.0| 230583|||||||1.0|26.0|68|1697490360.87519|1697486400.0|
But then after starting HA again, it looked like this:
sqlite> select * from statistics where metadata_id=68; 229672|||||||8.0|34.0|68|1697436392.31216|1697432400.0| 229732|||||||2.0|36.0|68|1697439960.86276|1697436000.0| 229792|||||||3.0|39.0|68|1697443560.80928|1697439600.0| 229853|||||||1.0|40.0|68|1697447160.79825|1697443200.0| 229914|||||||1.0|41.0|68|1697450760.81171|1697446800.0| 229974|||||||2.0|43.0|68|1697454360.78511|1697450400.0| 230038|||||||1.0|44.0|68|1697457962.15749|1697454000.0| 230096|||||||1.0|45.0|68|1697461560.79043|1697457600.0| 230157|||||||1.0|46.0|68|1697465160.83549|1697461200.0| 230278|||||||1.0|47.0|68|1697472360.81009|1697468400.0| 230339|||||||1.0|48.0|68|1697475960.84639|1697472000.0| 230400|||||||1.0|49.0|68|1697479560.84954|1697475600.0| 230460|||||||1.0|50.0|68|1697483160.82669|1697479200.0| 230522|||||||1.0|51.0|68|1697486760.86455|1697482800.0| 230583|||||||1.0|52.0|68|1697490360.87519|1697486400.0|
26 + 8 is 34.
This is for recording:ractualchpowerexternal.

OK, not sure if I'm actually seeing the same issue here. I fixed all the sums again manually on the second day, and now everything looks fine. So for me there was only a problem when there was less than one day of data available.

With the colder temperatures I did check the recs more the last few days and it seems like the values are correct and stay correct.
Fine for me.


ensure sentencepiece.pb.h gets installed

Fix fallout from #59

Hi! This is the friendly conda-forge automerge bot!
I considered the following status checks when analyzing this PR:

linter: passed
azure: passed

Thus the PR was passing and merged! Have a great day!


Error while adding urls.py

While adding the code : url(r'^review/$', include('review.urls'))  into urls.py, its throwing import error
I am using Django-Edge. (django-edge.readthedocs.io/)
Logs:
http://pastebin.com/PV3xKtpH

This is an issue of your local setup. Did you use another app called 'review' before? Please try to debug it by yourself or try to use a clean virtual environment.

Oh  yes. My bad. Already app named 'review' existed. Removed it and django-review working fine.
Thanks


Division by zero in dist/umd/js-search.min.js

Great libraries Mr Vaughn. Very happy to be using your react virtualized in many things.
Our code scan popped up a division by zero in js-search:
l===1/0&&(l=0);

Hey @vladimirramik 😄  Thanks!
This is actually intentional. The code in question uses Infinity but that gets converted to 1 / 0 during bundling.
Since Infinity is a specific case I check for, I don't think there's any cause for concern here.


The Contributing link in the README on the master and v3 branches does not show up

Describe the bug
The Contributing link in the README on the master and v3 branches does not show up.
To Reproduce
Press the Contributing link in the README on the master and v3 branches.
Expected behavior
A description of Contributing will be displayed.
Screenshots

https://github.com/spatie/laravel-activitylog/blob/master/.github/CONTRIBUTING.md


Hi. In this chalenge you need "Your target6 element should have green text." but it is not correct because all child elements become green.

Challenge http://www.freecodecamp.com/challenges/waypoint-target-the-children-of-an-element-using-jquery has an issue. Please describe how to reproduce it, and include links to screenshots if possible.

Hey can you post a screenshot to show exactly what you have typed in?
Is it possible that you set the css for background-color to green instead of color?

here is.

You got it right!
That should be showing up there. It's part of all the javascript based challenges that you are able to see the tests that are running against your code.  See #2231 for a similar issue/explanation.

I think what he is trying to say is that all the text are green and not the"#target6" as in the challenge. It is a bit confusing

I see, thanks for clarifying @rowansen!
I believe #target6 is just meant to be one example to prove that the children are being selected.  How would you change this to be clearer?  Would you want the test to check 4, 5, and 6?

Perhaps if the phrase 'Your target 6 element should...' was changed to 'Your right-well elements should...' it would be a bit more in line with the instructions in the upper paragraph.

Still seeing the same issue per below screenshot.

Thanks @jwjb, this issue has not yet been closed so it is still on the backlog of items to be fixed.

Closing this issue because it is fixed in staging.

@benschenker and @bugron Awesome and thanks for posting fixed as it not only helps in understanding the fixing of this issue, but gives a glimpse under-the-hood of the actual code and some great test examples using assert to help with our coding skills.


Improve error display in spaceship

When we get an unexpected response from Apple servers, we'll now examine their contents more closely to see if they contain user-presentable error messages. If they do, we'll present those more clearly so that users have a better chance at identifying what went wrong.
This also removes the stdout redirection from the spec_helper. Before knowing it was there, it was extremely confusing to not understand where all my puts and pry output was going. Even with it removed, the default testing output is not overwhelming.

:ship:


Fixing PE-D bugs

Edit success message for Sort Command. Closes #191
Provide valid sort command in the User Guide. Closes #187

LGTM

LGTM


Add the possibility to overwrite redis-server configuration parameters

Currently, only a few redis-server parameters can be set thru the redis-node parameters and pod-template present in the Redis-Cluster Custom-Resource.
The Idea is to add new Key-Value map field in the Redis-Cluster.Spec (like the Metadata.Labels) That will be used by the redis-node process to configure the Redis-Server process.

Also it may be worth considering putting these into a ConfigMap that gets mounted into the container as a file, rather than having the go code modify the config file inside in the container. This would help take some of the responsibilities out of the container and into existing constructs within kubernetes.

https://github.com/AmadeusITGroup/Redis-Operator/pull/23
i'm not sure that i'm getting this right. But you can do that without any interventions into the code

@killmeplz sure, but since the redis-node process is already playing with the configuration file, I didn't want to add another process (/bin/cp) in an init-container to do it.
in #22 PR I also to the time to re-organize the redis-node process parameter. and to support "read-only root file system" in containers.


MAINT: revert addition of multivariate_beta

Reference issue
Reverts gh-16042
What does this implement/fix?
There are multiple issues with multivariate distributions which need to be addressed before adding new distributions. So, this PR reverts addition of multivariate_beta (which fixed only one of the dirichlet issues). It would be good to fix all the issues together before adding distributions we'd need to fix again.
Additional information
@mdhaber

@tirthasheshpatel I made additional changes to more completely revert. I think multivariate_beta is totally removed, and dirichlet should be almost exactly as it was before. Please pick a commit from before the merge of gh-16042 and compare these files with their old versions. If you agree that looks good, I'll merge.

The changes look good! Thanks @mdhaber!

Ok, the CI failure is just a connection issue for downloading openblas I think.
I'll put this in--if I need to revert something in the release notes maybe let me know in gh-16248


Renovate should detect google/yamlfmt

It would be nice for Renovate to automatically PR a new yamlfmt release.
It currently only lives in the action file when it downloads the repo, there might be a way to have renovate detect this file but it needs to be investigated how to do do.

 Renovate should detect google/yamlfmt


Executing commands via RCON throws an exception

CommandAPI version
9.2.0
Minecraft version
1.20.2
Are you shading the CommandAPI?
Yes
What I did
Executed a command that has been registered with CommandAPI over the rcon protocol.
What actually happened
An exception has been thrown that says that the RemoteConsoleCommandSender cannot be wrapped
Unexpected exception while parsing console command "execute in minecraft:overworld run wps temporaryWaypoint Sytm 0 100 0"
org.bukkit.command.CommandException: Unhandled exception executing 'execute in minecraft:overworld run wps temporaryWaypoint Sytm 0 100 0' in org.bukkit.craftbukkit.v1_20_R2.command.VanillaCommandWrapper(execute)
        at org.bukkit.command.SimpleCommandMap.dispatch(SimpleCommandMap.java:165) ~[paper-api-1.20.2-R0.1-SNAPSHOT.jar:?]
        at org.bukkit.craftbukkit.v1_20_R2.CraftServer.dispatchCommand(CraftServer.java:989) ~[paper-1.20.2.jar:git-Paper-222]
        at org.bukkit.craftbukkit.v1_20_R2.CraftServer.dispatchServerCommand(CraftServer.java:974) ~[paper-1.20.2.jar:git-Paper-222]
        at net.minecraft.server.dedicated.DedicatedServer.lambda$runCommand$4(DedicatedServer.java:788) ~[paper-1.20.2.jar:git-Paper-222]
        at net.minecraft.util.thread.BlockableEventLoop.lambda$submitAsync$0(BlockableEventLoop.java:59) ~[?:?]
        at java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1768) ~[?:?]
        at net.minecraft.server.TickTask.run(TickTask.java:18) ~[paper-1.20.2.jar:git-Paper-222]
        at net.minecraft.util.thread.BlockableEventLoop.doRunTask(BlockableEventLoop.java:153) ~[?:?]
        at net.minecraft.util.thread.ReentrantBlockableEventLoop.doRunTask(ReentrantBlockableEventLoop.java:24) ~[?:?]
        at net.minecraft.server.MinecraftServer.doRunTask(MinecraftServer.java:1324) ~[paper-1.20.2.jar:git-Paper-222]
        at net.minecraft.server.MinecraftServer.d(MinecraftServer.java:193) ~[paper-1.20.2.jar:git-Paper-222]
        at net.minecraft.util.thread.BlockableEventLoop.pollTask(BlockableEventLoop.java:126) ~[?:?]
        at net.minecraft.server.MinecraftServer.pollTaskInternal(MinecraftServer.java:1301) ~[paper-1.20.2.jar:git-Paper-222]
        at net.minecraft.server.MinecraftServer.pollTask(MinecraftServer.java:1294) ~[paper-1.20.2.jar:git-Paper-222]
        at net.minecraft.util.thread.BlockableEventLoop.managedBlock(BlockableEventLoop.java:136) ~[?:?]
        at net.minecraft.server.MinecraftServer.waitUntilNextTick(MinecraftServer.java:1272) ~[paper-1.20.2.jar:git-Paper-222]
        at net.minecraft.server.MinecraftServer.runServer(MinecraftServer.java:1160) ~[paper-1.20.2.jar:git-Paper-222]
        at net.minecraft.server.MinecraftServer.lambda$spin$0(MinecraftServer.java:315) ~[paper-1.20.2.jar:git-Paper-222]
        at java.lang.Thread.run(Thread.java:833) ~[?:?]
Caused by: java.lang.RuntimeException: Failed to wrap CommandSender org.bukkit.craftbukkit.v1_20_R2.command.CraftRemoteConsoleCommandSender@4d4f2a11 to a CommandAPI-compatible BukkitCommandSender
        at dev.jorel.commandapi.CommandAPIBukkit.wrapCommandSender(CommandAPIBukkit.java:433) ~[?:?]
        at dev.jorel.commandapi.nms.NMS_Common.getCommandSenderFromCommandSource(NMS_Common.java:396) ~[?:?]
        at dev.jorel.commandapi.nms.NMS_Common.getCommandSenderFromCommandSource(NMS_Common.java:97) ~[?:?]
        at dev.jorel.commandapi.CommandAPIHandler.lambda$generatePermissions$1(CommandAPIHandler.java:362) ~[?:?]
        at com.mojang.brigadier.tree.CommandNode.canUse(CommandNode.java:79) ~[paper-1.20.2.jar:git-Paper-222]
        at com.mojang.brigadier.CommandDispatcher.parseNodes(CommandDispatcher.java:360) ~[paper-1.20.2.jar:?]
        at com.mojang.brigadier.CommandDispatcher.parseNodes(CommandDispatcher.java:390) ~[paper-1.20.2.jar:?]
        at com.mojang.brigadier.CommandDispatcher.parseNodes(CommandDispatcher.java:390) ~[paper-1.20.2.jar:?]
        at com.mojang.brigadier.CommandDispatcher.parseNodes(CommandDispatcher.java:394) ~[paper-1.20.2.jar:?]
        at com.mojang.brigadier.CommandDispatcher.parseNodes(CommandDispatcher.java:394) ~[paper-1.20.2.jar:?]
        at com.mojang.brigadier.CommandDispatcher.parse(CommandDispatcher.java:350) ~[paper-1.20.2.jar:?]
        at com.mojang.brigadier.CommandDispatcher.parse(CommandDispatcher.java:318) ~[paper-1.20.2.jar:?]
        at net.minecraft.commands.Commands.performPrefixedCommand(Commands.java:309) ~[?:?]
        at org.bukkit.craftbukkit.v1_20_R2.command.VanillaCommandWrapper.execute(VanillaCommandWrapper.java:45) ~[paper-1.20.2.jar:git-Paper-222]
        at org.bukkit.command.SimpleCommandMap.dispatch(SimpleCommandMap.java:155) ~[paper-api-1.20.2-R0.1-SNAPSHOT.jar:?]
        ... 18 more

What should have happened
The command should be executed with similar behaviour to the normal console
Server logs and CommandAPI config
No response
Other
The issue I described here happended when I tried to reproduce the issue a user of my plugin encountered below

Although I think this issue occurred on 9.0.3 when using RCON

I made a commit (https://github.com/JorelAli/CommandAPI/commit/07defff891ba4b717105ac6f32a506fa7f555977) that should add support for such command senders.
I am being honest, I have no idea how to set this up which is why I want to ask you if you could test that commit yourself?
It is on the dev/remote-console-command-sender branch :D

@DerEchtePilz Testing rcon is fairly simple:

Download an rcon client. I used rcon-cli

In your server's server.properties, enable rcon and set a password (for illustrative purposes, I used password):
rcon.port=25575
enable-rcon=true
rcon.password=password

Run your server with the CommandAPI and a CommandAPI registered command

In a terminal, run the command with rcon:
$ rcon -a localhost:25575 -p password "mycommand hello"

I've tested this feature myself and I can confirm it works! 🎉

Implemented in CommandAPI 9.3.0.


Install wheel for hermes and search2

Install wheel via pip for hermes and search2 virtual environments to fix (non fatal) build errors:
Building wheels for collected packages: PyYAML
  Running setup.py bdist_wheel for PyYAML: started
  Running setup.py bdist_wheel for PyYAML: finished with status 'error'
  Complete output from command /opt/appscale_venvs/search2/bin/python3 -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-1ss2a3ji/PyYAML/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" bdist_wheel -d /tmp/tmprthwswm_pip-wheel- --python-tag cp36:
  usage: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
     or: -c --help [cmd1 cmd2 ...]
     or: -c --help-commands
     or: -c cmd --help

  error: invalid command 'bdist_wheel'

  ----------------------------------------
  Running setup.py clean for PyYAML
  Failed building wheel for PyYAML
Failed to build PyYAML

as present in image build output.
This results in the installed:
/opt/appscale_venvs/hermes/lib/python3.6/site-packages/PyYAML-5.1.2.egg-info
rather than the expected (as per task queue):
/opt/appscale_venvs/appscale_taskqueue/lib/python3.6/site-packages/PyYAML-5.1.2.dist-info

Daily build no. 6977
Demo is that the errors are no longer shown in the image build output and the expected yYAML-5.1.2.dist-info directories are present instead of the PyYAML-5.1.2.egg-info directories.


Fixed assembly loading issue for netcoreapp.

Fixes https://github.com/dotnet/sdk/pull/14276.

Please share why is this needed, because I don't get it from the linked issue without investigating it. And what impact it has on package sizes.

TestHost depends on PlatformAbstractions, it's is provided by ObjectModel which is built against netstandard2.0. TestHost fails to load, so I added one built against the same library.


Small fixes

[x] Explicit only show the master branch badge & link to Actions pipeline

Codecov Report

Merging #41 (6c9d65c) into master (2e82e20) will increase coverage by 0.11%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master      #41      +/-   ##
==========================================
+ Coverage   56.13%   56.25%   +0.11%
==========================================
  Files           2        2
  Lines         367      368       +1
  Branches      178      178
==========================================
+ Hits          206      207       +1
  Misses          3        3
  Partials      158      158

Impacted Files
Coverage Δ

src/client.cc
57.48% <0.00%> (+0.16%)
: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 2e82e20...6c9d65c. Read the comment docs.


Support corp http proxies

Some users are in a corp network where all http traffic has to go through a proxy. bazelisk relies on http to talk to google storage API, github search API, and to download binaries.
It seems like at least support for the HTTP[S]_PROXY environment variables would be straightforward to add: https://golang.org/pkg/net/http/#ProxyFromEnvironment
If/when we have an npm package for bazelisk (#114) we should also read values from .npmrc to find the proxy config (https://docs.npmjs.com/using-npm/config#https-proxy) and pass that to the Go program. We can't tear down the @bazel/bazel npm package until this feature lands, because some users rely on the npm proxy setting to get Bazel onto their dev machines today.

It seems Go's http package handle HTTP_PROXY/HTTPS_PROXY by default.
I tested on my Mac that bazelisk will use my HTTP_PROXY/HTTPS_PROXY values.

Oh that's great, I didn't test it myself so there is probably no issue here.


NTR: IkappaB kinase complex binding

Hi,
From annotation review ticket (co-localizes_with complex terms): geneontology/go-annotation#1940
I need a term to indicate 'IkappaB kinase complex binding' based on
PMID:12492477
(Mixed lineage kinase LZK and antioxidant protein-1 activate NF-kappaB synergistically.)
Thanks,
Penelope

GO:0038059 IKKalpha-IKKalpha complex ?

Hi @pgaudet ,
it seems that GO:0038059 IKKalpha-IKKalpha complex that you suggested is a different complex. This is a homodimer of IKKalpha (IkappaB kinase alpha).
The IkappaB kinase complex (IκB kinase complex) is composed of three subunits each encoded by a separate gene:
IKK-α (also known as IKK1) (CHUK)
IKK-β (also known as IKK2) (IKBKB)
IKK-γ (also known as NEMO) (IKBKG)
Thanks,
Penelope

GO:0106137


Creating dictionary with big file hangs

When attempting to turn binary (500mb) into bytes and load it into a dictionary via RobotFramework, it seems to fill up the memory (8gb) and completely stress the CPU cores (i7-8550U).
Loading the 500mb binary data into a variable (file_data) causes no issues, but when creating a dictionary with file=${file_data}, it breaks and the robot process is eventually killed from timeout as it just uses up the resources and hangs.
${file_data} =     Get Binary File     ${FILE_UPLOAD_PATH}
&{files} =           Create Dictionary    file=${file_data}

That's a big file but you also have lot of free memory so this kind of behavior is pretty strange. Does the same test work with smaller files?
It would be great to get this work, but even bigger files would anyway create problems. Could uploading be change so that you don't need to read the file in Robot side? In the best case the keyword sending the data could read the data from file and preferably stream it to the connection without reading it fully into memory at all.

That's a big file but you also have lot of free memory so this kind of behavior is pretty strange. Does the same test work with smaller files?
It would be great to get this work, but even bigger files would anyway create problems. Could uploading be change so that you don't need to read the file in Robot side? In the best case the keyword sending the data could read the data from file and preferably stream it to the connection without reading it fully into memory at all.

my two cents worth:
I had some similar symptoms when processing large dict/list inside one of my python libraries:
pseudo-code:
my_large_dict = LargeDictFromFile(my_file)
# make dict available as robot variable so that I can use it in my test cases
BuiltIn().set_test_variable("${MY_DICT_AS_ROBOT_VARIABLE}", my_large_dict)

This was really slow and memory-intensive, like in your case.
But after refactoring my library to use that large dict only internally, i.e. there was no robot variable pointing to anymore - things became really fast. Obviously I was happy that things were much faster ... but I also got curious and was looking at the code a bit:
It seemed to me that the variable assignment was the problem and that the code was spending the time "stringifying" that large dict for logging.
In the end I did not have time to figure out, if I was right or not, but maybe this helps @pekkaklarck where to look ...

my two cents worth:
I had some similar symptoms when processing large dict/list inside one of my python libraries:
pseudo-code:
my_large_dict = LargeDictFromFile(my_file)
# make dict available as robot variable so that I can use it in my test cases
BuiltIn().set_test_variable("${MY_DICT_AS_ROBOT_VARIABLE}", my_large_dict)

This was really slow and memory-intensive, like in your case.
But after refactoring my library to use that large dict only internally, i.e. there was no robot variable pointing to anymore - things became really fast. Obviously I was happy that things were much faster ... but I also got curious and was looking at the code a bit:
It seemed to me that the variable assignment was the problem and that the code was spending the time "stringifying" that large dict for logging.
In the end I did not have time to figure out, if I was right or not, but maybe this helps @pekkaklarck where to look ...

@pekkaklarck It appears to work just fine with a small binary, so it definitely seems to be the size that is the problem.
I also ended up writing all the dictionary handling in a python library instead without any Robot variables being used. It solved the problem like yours @yahman72.
But it would of course be preferable that the BuiltIn dictionary handling and assignment works with larger files, so there's no need for extra custom python library implementations to do the same thing.

@pekkaklarck It appears to work just fine with a small binary, so it definitely seems to be the size that is the problem.
I also ended up writing all the dictionary handling in a python library instead without any Robot variables being used. It solved the problem like yours @yahman72.
But it would of course be preferable that the BuiltIn dictionary handling and assignment works with larger files, so there's no need for extra custom python library implementations to do the same thing.

Did you test how big the file needs to be to start causing problems?
What log level did you use? If TRACE, then all arguments are logged to output.xm and that certainly won't work well if an argument is 500MB.

No updates in over a year. Closing.


Fixed controlled Date and TimePicker value update

Possible fix for issue #180

@ferencrocks Hey can you squash those commits please?

@rojobuffalo Thanks for picking up the open issues and PRs! That reminded me to ask - would you like me to transfer the repo to you, or create its own org? Seems a little unfair that it still appears to be mine when you're doing all the work these days.
On this one, there's now the option to squash and merge (drop-down icon on merge button), so you don't have to wait for  @ferencrocks to do it.

Cool, thanks for pointing out that feature. I'm ok with you transferring the repo but I don't mind either way.

I'm happy for you to take it. I tried transferring it, but I think you'll need to delete your fork first, so let me know when that's done, and I'll give it another go.

Ok. I just renamed my fork.

Now I get a different error 🤦♂
"rojobuffalo already has a repository in the mbrookes/formsy-material-ui network"
Looks like you'll have to delete your fork, sorry.

Ok, I deleted it.

"You have the bridge."

Thanks @mbrookes


Stop overriding the git version in built binaries.

This was resulting in unexpected binary versions; in particular, the kubectl client version did not match the gitVersion in pkg/version/base.go` due to new tags not being created on the master branch/ tags being unreachable. In the future we need to be more diligent about creating versions on the master branch and cherrypicking to release branch (Note that 0.13.1 and 0.13.2 were not created on the master branch).
Edit: closes #5868
cc @smarterclayton, @brendandburns, @zmerlynn

cc @fabioy

NAK   people use this when building from src instead of from a git tree

@eparis, won't the built binary be unchanged if building from src with no git tree?

I guess what I need is the 'dirty,' more than the version.  What's in the bin is fine for that....

isn't the real problem that the tag isn't on a branch?  nothing wrong with this code, its git that's broken?

I'm going to continue this discussion in #5868.

I'll let @brendandburns and @zmerlynn chime in, but I think it is confusing if the binary version doesn't match the version in pkg/version/base.go. That is the way releases are defined, so the we shouldn't base the binary version on the presence of an annotated tag in the branch. It's useful to get the git commit and tree state, and that info is kept. Example output with this change (rebased to head)
# running a binary build with uncommitted local changes
current-context: "jeffmltest_e2e-test-jeffml"
Running: cluster/../cluster/gce/../../cluster/../_output/local/bin/linux/amd64/kubectl version
Client Version: version.Info{Major:"0", Minor:"13.0+", GitVersion:"v0.13.0-dev", GitCommit:"ceffa489d018b89d5b913cb2a4b723dbcdb246fd", GitTreeState:"dirty"}
Server Version: version.Info{Major:"0", Minor:"12+", GitVersion:"v0.12.0-979-g6918a4d32ed200", GitCommit:"6918a4d32ed200e6e5e4715fcf049c32d86c5488", GitTreeState:"clean"}

# running a binary build with no local changes
current-context: "jeffmltest_e2e-test-jeffml"
Running: cluster/../cluster/gce/../../cluster/../_output/local/bin/linux/amd64/kubectl version
Client Version: version.Info{Major:"0", Minor:"13.0+", GitVersion:"v0.13.0-dev", GitCommit:"ceffa489d018b89d5b913cb2a4b723dbcdb246fd", GitTreeState:"clean"}
Server Version: version.Info{Major:"0", Minor:"12+", GitVersion:"v0.12.0-979-g6918a4d32ed200", GitCommit:"6918a4d32ed200e6e5e4715fcf049c32d86c5488", GitTreeState:"clean"}

Ping @brendandburns, @zmerlynn, @eparis. #5868 was closed, but it's not clear to me whether we want to merge or abandon this PR.

Trying to decide how I feel.  Going from
Client Version: version.Info{Major:"0", Minor:"12+", GitVersion:"v0.12.0-1041-gef758881d108bb", GitCommit:"ef758881d108bb53a128126c503689104d17f477", GitTreeState:"clean"}

To:
Client Version: version.Info{Major:"0", Minor:"12+", GitVersion:"v0.12.0-dev", GitCommit:"ef758881d108bb53a128126c503689104d17f477", GitTreeState:"clean"}

It's a change, but I guess not an important one.  I'm not sure what the point of "gitVersion" is at all, since it has nothing at all to do with git...

I guess I'm ok either way, but if we are going to back stuff out, why not just drop "gitVersion" from all of the code entirely?

We definitely want the patch version in there if we're going to drop the
gitVersion, and adding "Patch" would be pretty big change. Maybe we should
just throw it into the breaking change day. :)
On Fri, Mar 27, 2015 at 8:47 AM, Eric Paris<EMAIL_ADDRESS>wrote:

I guess I'm ok either way, but if we are going to back stuff out, why not
just drop "gitVersion" from all of the code entirely?
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/pull/5817#issuecomment-86981271
.

What do you mean by "patch version"  you still have gitCommit...

Right now the only fields are "Major" (0), Minor ("12+"). That's not enough
to express the semantic version "0.13.2". The GitVersion is the only place
the entire semantic version exists today.
On Fri, Mar 27, 2015 at 8:56 AM, Eric Paris<EMAIL_ADDRESS>wrote:

What do you mean by "patch version" you still have gitCommit...
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/pull/5817#issuecomment-86985052
.

$ git checkout origin/master:
major (0) minor (13.0+) gitVersion(v0.13.0-dev)
$ git checkout v0.13.2:
major(0)  minor(13.2)   gitVersion(v0.13.2)
I'm not exactly sure what you are saying it missing in the 0.13.2 semantic....
The tagging of things is still totally screwed up, but that's unrelated....
$ git describe --tags --abbrev=14 origin/master
v0.13.1-dev-652-ge4fc45c26fdecd

You seem to be arguing from a position of including gitVersion after having said:

I guess I'm ok either way, but if we are going to back stuff out, why not just drop "gitVersion" from all of the code entirely?

... which is arguing the opposite.

I'm saying that everything in gitVersion is in gitMajor, gitMinor, and gitCommit.  And thus gitVersion is unnecessary.
(unrelated I'm saying that tags/git describe are still messed up)

No, gitVersion is Major, Minor, Patch, as in semantic versioning. It also happens to include enough hash for a git describe. I really need that Patch level as well, so gitVersion is not unnecessary, unless you include Patch elsewhere. Where are you putting the "2" of 0.13.2? You still haven't answered that part.

https://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/version/base.go#L39

Also, what's your objecting to the current tag?

or if you meant specifically the "2"
https://github.com/GoogleCloudPlatform/kubernetes/blob/release-0.13/pkg/version/base.go#L39

Bleh.

I am saying that I believe gitVersion is entirely unnecessary as it is currently contained in the major/minor/gitCommit fields.  Releases also seem to screw up tagging often enough that git describe isn't accurate and thus isn't great for generating gitVersion anyway.
(The problem with git describe right now is that it says master is 0.13.1 + 652 commits.  It should either say it is 0.13.0 + some number of commits, or it should say it is 0.13.2 + some number of commits.  Since all commits from 0.13.2 are in master.  I don't care which we call 'correct' but what it gives right now is wrong)

Sorry, I actually totally forgot that the .0 version looked different than the .2 version. I've been staring at the .0 versions too long.

Actually, the git describe is as correct as I could make it, believe it or not. 0.13.1-dev is the branch point for v0.13.1, so that git describe of "0.13.1 + 652" pretty much nails it. I couldn't even fix the tag v0.13.0 because it was so badly broken.

(There's no relevant tag for v0.13.2 on master because it doesn't make sense.)

Oops. Accidentally garbage collected the pr branch. Reopened as #6065

What is 'correct'.  In 2 months should we call master:
0.14.0 + 1000 commits
or
0.14.3 + 997 commits

Okay, I'm fine with this change. Should we just stop tagging in git as
well? The use of last-good-e2e-run means the tags are always time traveling
(which is why there's -dev tag, even though the actual bump to 0.13.1 is a
bit later in the log.)
On Mar 27, 2015 9:44 AM, "Jeff Lowdermilk"<EMAIL_ADDRESS>wrote:

Oops. Accidentally garbage collected the pr branch. Reopened as #6065
https://github.com/GoogleCloudPlatform/kubernetes/pull/6065
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/pull/5817#issuecomment-87003033
.

We should call master a git hash and be done :p
On Mar 27, 2015 9:51 AM, "Zachary Loafman"<EMAIL_ADDRESS>wrote:

Okay, I'm fine with this change. Should we just stop tagging in git as
well? The use of last-good-e2e-run means the tags are always time traveling
(which is why there's -dev tag, even though the actual bump to 0.13.1 is a
bit later in the log.)
On Mar 27, 2015 9:44 AM, "Jeff Lowdermilk"<EMAIL_ADDRESS>wrote:

Oops. Accidentally garbage collected the pr branch. Reopened as #6065
https://github.com/GoogleCloudPlatform/kubernetes/pull/6065
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/pull/5817#issuecomment-87003033
.

last-good-e2e-run must be some google internal thing, I don't see that name in the repo.....  Is that what's breaking things constantly?  This all seems like your internal release process is broken...
It seems we should be doing:
git checkout -b possible-v-14 origin/master
edit base.go to set to 0.14;
git commit;
edit base.go to set to 0.14+;
git commit;
run e2e on that middle commit;
if it works
tag the middle commit as v0.14.0
if it fails
delete your possible-v-14 branch and goto start;
merge possible-v-14 into master on github
git checkout -b v0.14 v0.14.0
edit base.go to set to 0.14.0+
push new "v0.14" branch to github.
What do we do differently?

"last-good-e2e-run" was my shorthand for "picking a validated git hash from our Jenkins server". In other words, instead of the very expensive process of the middle step, we essentially elevate a known good build. For v0.x.0 with known-good-hash from Jenkins, we did:
git checkout -b release-0.x known-good-hash
./build/mark-new-version.sh v0.x.0
git checkout v0.x.0
make clean; make release # To build the binaries that actually have the new version number
git push https://github.com/GoogleCloudPlatform/kubernetes tags/v0.x
git push https://github.com/GoogleCloudPlatform/kubernetes release-0.x
# merge the resulting PR, the version numbers appear a little later in the stream
# push binaries up
# change github page

Unfortunately, that doesn't quite work because the v0.x tag create by mark-new-version.sh is effectively created on a release branch and not reachable from HEAD. And so it requires the introduction of a branch point tag so that git describe doesn't freak out entirely.
FWIW, before you consider this broken, please consider that we all have quite busy jobs outside of the release process and being able to escalate a known good build is quite advantageous versus squatting on somewhat flakey e2e runs.


Unmet peer dependencies with Astro 2 beta

Astro build leads to object-hash error with Astro 2.0.0-beta.1
Cannot find package 'object-hash' imported from /Volumes/Evo/Sites/astro-content/dist/entry.mjs
  Did you mean to import<EMAIL_ADDRESS>
Therefore, I tried installing object-hash as a separate package, but then I ended up with a different error in regards to unmet peer dependencies which made more sense since Astro 2 beta is quite new.
Regardless, if I downgrade to Astro 1.9.x, my project does compile.

i mean :: seens it is still happening, but after manually installing missing deps it all seems fine.

This is still happening with Astro 2.0.4

@djmtype @guttenbergovitz @beeb could you please share more info about your system and versions of astro-imagetools and astro? I just tested both on Windows and Ubuntu with<EMAIL_ADDRESS>and<EMAIL_ADDRESS>but I am not getting any build related issue.

could you please share more info about your system and versions

Latest versions of both as of two days ago, please note I'm using pnpm@latest if that makes a difference.

@RafidMuhymin  Still getting object hash error too.
Astro 2.0.5
astro-imagetools 0.7.6
pnpm 7.25.1
node v16.19.0
MacOS 13.1

@RafidMuhymin I decided to start a blank Astro project, making sure there wasn't a conflict with this library.
Although, I don't get the object-hash error, whenever I build I get something like:
 error   ENOENT: no such file or directory, open<EMAIL_ADDRESS>
Here's my Picture component which resides in /public/images/:
<Picture
src="/images/placeholder-about.jpg"
alt="poster"
width="1200"
height="600"
	/>

I tried also on an astro project (not blank) where I didn't already depend on astro-imagetools, updated to astro 2.0.5, then added astro-imagetools and I get a different error:
> astro build

04:53:14 PM [build] output target: static
04:53:14 PM [build] Collecting build info...
04:53:14 PM [build] Completed in 26ms.
04:53:14 PM [build] Building static entrypoints...
Could not resolve "../../astroViteConfigs.js" from "node_modules/.pnpm/astro-imagetools<EMAIL_ADDRESS>file: /home/vbersier/work/smsl_dev/launchpad/launchpad-astro/node_modules/.pnpm/astro-imagetools<EMAIL_ADDRESS> error   Could not resolve "../../astroViteConfigs.js" from "node_modules/.pnpm/astro-imagetools<EMAIL_ADDRESS>  File:
    /home/vbersier/work/smsl_dev/launchpad/launchpad-astro/node_modules/.pnpm/astro-imagetools<EMAIL_ADDRESS>  Stacktrace:
RollupError: Could not resolve "../../astroViteConfigs.js" from "node_modules/.pnpm/astro-imagetools<EMAIL_ADDRESS>    at error (file:///home/vbersier/work/smsl_dev/launchpad/launchpad-astro/node_modules/.pnpm/rollup@3.12.1/node_modules/rollup/dist/es/shared/rollup.js:2091:30)
    at ModuleLoader.handleInvalidResolvedId (file:///home/vbersier/work/smsl_dev/launchpad/launchpad-astro/node_modules/.pnpm/rollup@3.12.1/node_modules/rollup/dist/es/shared/rollup.js:23219:24)
    at ModuleLoader.resolveDynamicImport (file:///home/vbersier/work/smsl_dev/launchpad/launchpad-astro/node_modules/.pnpm/rollup@3.12.1/node_modules/rollup/dist/es/shared/rollup.js:23277:58)
    at async file:///home/vbersier/work/smsl_dev/launchpad/launchpad-astro/node_modules/.pnpm/rollup@3.12.1/node_modules/rollup/dist/es/shared/rollup.js:23166:32

On the initial project where I had the error, I think I solved it by doing public-hoist-pattern[]=*astro-imagetools* inside .npmrc, but not sure if that's the fix.
Anyway, I still have the  Cannot find package 'object-hash' error even with astro 2.0.5.

@RafidMuhymin Here's my blank Astro project with astro-imagetools: https://github.com/djmtype/astro-imagetools-test

Just wanted to add here that @djmtype 's project is exhibiting the exact issues I had. I cloned it and downloaded all the modules it was complaining it was missing with pnpm add -D ...:

"@astropub/codecs"
"file-type"
"find-cache-dir"
"object-hash"
"potrace"

Until it stopped complaining about not finding things... I ran pnpm build and then ran into (shell output):
 building client
Completed in 29ms.

 generating static routes
▶ src/pages/index.astro
Responsive Image sets generated for Picture at /src/images/placeholder-about.jpg in 4585.597000002861ms
  └─ /index.html (+4.59s)
Completed in 6.28s.

 error   ENOENT: no such file or directory, open<EMAIL_ADDRESS>Error: ENOENT: no such file or directory, open<EMAIL_ADDRESS> ELIFECYCLE  Command failed with exit code 1.

And there is not even a /Users/xavierruiz/Projects/astro-imagetools-test/dist/_astro directory. I was thinking maybe it had to do with the image being from the /src directory but, no, moving the image to /public and updating the <Picture/> element accordingly gives the same error. Hopefully someone might see what is happening here with this error? I have a hunch it has something to do with a folder pointed wrong somehow and it is not finding stuff properly.
Using a Mac, pnpm version 7.27.0. Astro 2.0.5

In trying to diagnose this, I discovered there is a plugin/hooks/config.js file that has all but one of the modules I had to install ("sharp") listed in external SSR dependencies list, so maybe the issue has something to do with that file?
But I was able to come up with a workaround!!!! (I did have to install all those packages mentioned earlier (https://github.com/RafidMuhymin/astro-imagetools/issues/149#issuecomment-1426609221) in addition to this workaround).
By default Vite puts all assets in an "assets" folder (https://vitejs.dev/config/build-options.html#build-assetsdir) but for Astro it puts them in "_astro"... (https://docs.astro.build/en/reference/configuration-reference/#buildassets).
To be honest, I am not sure about how it all works, I just know that they are connected.
So I added some logging and here was the original problem output of pnpm build using @djmtype 's repo:
saving asset...
/Users/xavierruiz/Projects/astro-imagetools-test/dist/assets does not exist, creating now...
^^^ previous two lines x15
/Users/xavierruiz/Projects/astro-imagetools-test/dist/assets created successfully!
^^^ previous line x15 total
 error   ENOENT: no such file or directory, open<EMAIL_ADDRESS>Error: ENOENT: no such file or directory, open<EMAIL_ADDRESS> ELIFECYCLE  Command failed with exit code 1.

Please note the dissonance between this library creating a dist/assets folder but then turning around and trying to save the many photos generated in the dist/_astro folder.
So, we can workaround this by simply changing our configuration and explicitly telling Vite and Astro to match up their assets folder, please! Below is my astro.config.mjs:
import { defineConfig } from 'astro/config';
import { astroImageTools } from "astro-imagetools";
// https://astro.build/config
export default defineConfig({
	integrations: [astroImageTools],
	build: {
		assets: "assets"
	},
	vite: {
		build: {
		 // assetsDir: "poop" // if you uncomment this line, you have to make astro assets also "poop"
		}
	}
});

What this does, is tell Astro to use /assets instead of /_astro for assets, matching Vite's expectation.
Here is the shell output now:
saving asset...
/Users/xavierruiz/Projects/astro-imagetools-test/dist/assets does not exist, creating now...
^^^ previous two lines x15
/Users/xavierruiz/Projects/astro-imagetools-test/dist/assets created successfully!
^^^ previous line x15 total
saved asset! =><EMAIL_ADDRESS>saved asset! =><EMAIL_ADDRESS>saved asset! =><EMAIL_ADDRESS>saved asset! =><EMAIL_ADDRESS>saved asset! =><EMAIL_ADDRESS>saved asset! =><EMAIL_ADDRESS>saved asset! =><EMAIL_ADDRESS>saved asset! =><EMAIL_ADDRESS>saved asset! =><EMAIL_ADDRESS>saved asset! =><EMAIL_ADDRESS>saved asset! =><EMAIL_ADDRESS>saved asset! =><EMAIL_ADDRESS>saved asset! =><EMAIL_ADDRESS>saved asset! =><EMAIL_ADDRESS>saved asset! =><EMAIL_ADDRESS>11:03:18 PM [build] 1 page(s) built in 7.17s
11:03:18 PM [build] Complete!

Note how we are still creating an dist/assets folder, but thanks to that change we are actually saving them in the assets folder and not _astro folder. As mentioned in the comment of the config, you can also change the assets folder for Vite, but Astro will still try to save the images in the _astro folder, so you may as well just change one of them to be correct.
This astro.config.mjs also works:
import { defineConfig } from 'astro/config';
import { astroImageTools } from "astro-imagetools";
// https://astro.build/config
export default defineConfig({
	integrations: [astroImageTools],
	build: {
		// assets: "poop" // same stuff as before but flipped
	},
	vite: {
		build: {
			 assetsDir: "_astro"
		}
	}
});

but now you get this output:
saving asset...
/Users/xavierruiz/Projects/astro-imagetools-test/dist/_astro does not exist, creating now...
^^^ previous two lines x15 total
/Users/xavierruiz/Projects/astro-imagetools-test/dist/_astro created successfully!
^^^ previous line x15 total
saved asset! =><EMAIL_ADDRESS>saved asset! =><EMAIL_ADDRESS>saved asset! =><EMAIL_ADDRESS>saved asset! =><EMAIL_ADDRESS>saved asset! =><EMAIL_ADDRESS>saved asset! =><EMAIL_ADDRESS>saved asset! =><EMAIL_ADDRESS>saved asset! =><EMAIL_ADDRESS>saved asset! =><EMAIL_ADDRESS>saved asset! =><EMAIL_ADDRESS>saved asset! =><EMAIL_ADDRESS>saved asset! =><EMAIL_ADDRESS>saved asset! =><EMAIL_ADDRESS>saved asset! =><EMAIL_ADDRESS>saved asset! =><EMAIL_ADDRESS>11:25:01 PM [build] 1 page(s) built in 6.82s
11:25:01 PM [build] Complete!

In this config, we know that Astro is going to try and save the images in _astro for some reason and Vite is going to try to make an assets folder, so we tell Vite to instead make a dist/_astro folder instead. Maybe this might be important for some people to keep the _astro folder? idk...
Whew... I am happy I forced it to work. This was my first time messing with code in node_modules. Hopefully, someone more knowledgeable than me about how asset directories between Vite and Astro works can figure out why this dissonance is happening.

@xav-ie Much appreciated. It all builds now.
It's just an unfortunate side effect every time Astro updates it has always ended up breaking this awesome library. Thanks for going down this rabbit hole. Hopefully Astro Imagetools will be fixed one day so we don't have to install all of its same required packages into our own project.
At least with Astro 2.0.17, it seemed to even build and preview without adding the following rules to the Astro config:
vite: {
  build: {
  assetsDir: "_astro"
 }

@xav-ie There seems to be 2 issues at play. One regarding pnpm and the other with the build directory. Only with pnpm do I need to add all of astro-imagetools dependencies to my own project. The other issue is the assetsDir which you solved.

@xav-ie I really don't know much about pnpm, but adding a .npmrc file with shamefully-hoist=true to the root of the project seems to magically clear up any remaining issues.
I've updated my march-update branch to use pnpm instead.

Hello, what is the best practice for using astro-imagetools witn pnpm? I tried with shamefully-hoist=true but it didn't help.

pnpm install --shamefully-hoist seen to do the trick... but I felt so shameful doing this.


[ADD]: DYNAMIC LEADERBOARD JS PROJECT💡

Describe the project you want to add with tech stack

This project is about visualizing the player's score as a leaderboard.
The user can increment or decrement score of the players, the leaderboard will updated during this process to get live scores.
There's also a trash button is provided to remove any player from the leaderboard.
This project is build with HTML5, CSS3 & ES6 Principles.
As always i used mobile first workflow to design this application so this could perform well adaptive for every types of devices.

Screenshots (optional)

Please assign this issue to me @MohitGupta121, @pranjay-poddar, @Saurabh-kumar09 & @TusharKesarwani.


Enabling MetaAudio.dll breaks CaptionMod

Whenever I enable metaaudio.dll, CaptionMod breaks so that no subtitles are displayed at all. Without a fix or setting it seems like there's not a way to play with the Full Audio Remaster and subtitles.
https://github.com/LAGonauta/MetaAudio/issues/50

DO NOT replace metahook.exe if you have installed MetaHookSv launcher before.
or MAKE SURE MetaHookSv is installed after MetaAudio if MetaAudio was installed from .bat.
and MAKE SURE [mod_directory]/metahook/configs/plugins.lst loads all the plugins you want.

Oh yeah I figured that. I made sure to just take out the dlls, put them where they should be; OpenAL, libsndfile-1, and alure2 are in the base game folder while MetaAudio.dll is in valve/metahook/plugins and gearbox/metahook/plugins, and added metaaudio.dll to plugins.lst and plugins_goldsrc.lst and tried removing it from plugins_goldsrc.lst. The Remastered audio is playing when I add it in, but the subtitles don't show up unless i delete metaaudio.dll from plugins.lst

try adjust the load order :

Unfortunately it's still broken when I put it first in the load order in plugins.lst or both plugins.lst and plugins_goldsrc.lst. The subtitles do play when I only put it first in plugins_goldsrc.lst, but that's because MetaAudio isn't working.

This should fix the issue : v20230118b

WOO! Looks like it did! Thank you very much.


hello how about we make web-site?

i think it's good idea making web-site collecting games that you made.
it can be by using git-hub.

Most of the game materals(including music, fonts and pictures) in this repository collected from the web, copyright belongs to the original author. This repository is created just for python learners.


add aws load metric test

Following issue #445
Added a test to recognize import errors of all metrics

Could you run make style to fix the code_quality fail ?
You'll need black and isort that you can install by doing pip install -e .[quality]

Thanks @lhoestq
I fixed the styling

Thank you :)


[TIR] More flexible buffer compaction

Hi there, the change want to enforce the power and flexiblity of CompactBufferAllocation pass in two aspects:

Free of pass order

It could work on both s-tir (with opaque blocks) and lowered tir. For example, now one could be able to invoke LoopPartition and then make partitioned tile aware buffer compactions.
We test existing cases to ensure that
(LowerOpaqueBlock . CompactBufferAllocation) (mod) == (CompactBufferAllocation . LowerOpaqueBlock) (mod)

Allow "non-strict" compaction

Add an option is_strict defaults to True, to denote that during compaction we should respect the original buffer shape bound. Thus the compacted buffer region never exceed the original.
If set to False, the "compacted" shape is totally determined to cover buffer region accesses. Thus it may become larger than the original shape. This change the original semantic for out-of-bound accesses but may be helpful in certain usages.
If loop domain changed (eg, align the loop dim or remove the extra predicate), the accessed buffer region may grow, the pass could provide a fallback implementation to adapt the buffer regions.

About implementation issues:

To achieve [1]

Buffer decl point:

(s-tir) T.alloc_buffer in block form is handled without any change.
(lowered) T.decl_buffer is newly handled. We assume it is at the proper position to dominate all accesses.

Predicates

Predicates in T.where and IfThenElse, T.if_then_else are handled uniformlly now. We would try simply resolve the predicate to update loop domain as before. But on failures, now we keep them into pending stack.
The visit logic is very alike IRVisitorWithAnalyzer's, but since  arith::Analyzer and arith::IntSet are independent components now, the change do not introduce IRVisitorWithAnalyzer'.

Buffer accesses

There is no difference between s-tir and lowered form. If there are pending predicates on access point, always try affine iter analysis to get more tight relaxed region.

Thread binding

To work on lowered form, attr::thread_extent and attr::virtual_thread are handled to record neccesary info for thread relaxion.

Buffer aliasing

No change to T.match_buffer handling, and we explicitly disable compaction to alised buffers in lowered form.

Dim alignment

We utilize annotation field in T.allocate and preserve attr::buffer_dim_align in LowerOpaqueBlock pass when it convert T.alloc_buffer to T.allocate. Thus the compaction could collect the dim alignment information in lowered form.

To achieve [2]

It is much direct. SimplifyAndNarrowBufferRegionFromNDIntSet would not intersect accessed region with original shape if the is_strict option is overrided to false.

cc @Hzfengsy @spectrometerHBH @vinx13 @Lunderberg

I have no objections. But it would be great if we can have double-checked with other TIR maintainers, as this PR changes the fundamental flow.

@wrongtest-intellif @Hzfengsy @Lunderberg any updates?

@wrongtest-intellif @Hzfengsy @Lunderberg any updates?

sorry for too late.. I am make modifications for review suggestions.

Since this pass can now be applied to the lowered TIR, would this allow for de-duplication between the S-TIR lowering path and TE lowering path?

I remove the legacy check, let's see if there are issues in testing. Generally, since the pass is after storage flatten for te codepath, I expect there would be no special IR form to cause problems.

Are the DeclBuffer nodes sufficient to find all buffer declaration locations?  @vinx13 can correct me, but last I heard they weren't fully used across the lowering flow.

The change is refactored to not depend on DeclBuffer nodes.

Sea of failures when use it with "legacy" schedule (T.T)..  We are trying to fix all of them to best improve the generality, but at the last I think we'd better to skip it by default. @Lunderberg

Here lists lessons from te workloads:

There may exist opaque usage to the var before we meet any buffers, so a pre-collection var2buffer_ is added to ensure we can treat the opaque access as full region access to the corresponding buffer. If the aliased buffer count > 1, we would skip the region collection and the buffers would not get mutated.

The itervar of thread binding from te-workloads would have empty dom field.

There would be conditions with non-bool type. Thus we add some normalization from if(x: int32) to if (x != 0) for non-bool conditions.

There would be mismatch from allocation dtype and buffer dtype, even if the buffer is the only one who refer to the allocated var.

The inferred region extent could be data dependent (for example, dependent by the buffer value Y = T.allocate([X[i], ...), in such cases, we should not compact the buffer to the dynamic extent, just like in the loop-dependent allocation cases.

Now it seems ok to the CI cases. Now we could disable the process for workloads from TE again and just leave some more covering cases for them.

Hi~ Could you help to take another round of look? cc @Hzfengsy @Lunderberg

CC @Hzfengsy @Lunderberg for a second look


[8.x] Adds new RefreshDatabaseLazily testing trait

Hi guys,
Hope you're well! Lemme break down this PR.
Background
When testing, we often add RefreshDatabase to our tests to migrate the database between tests. This is super useful but comes with a speed penalty. Because it is frustrating to have to add the RefreshDatabase trait to every TestCase that uses it, developers often just drop it on the base TestCase in PhpUnit or use something like uses(RefreshDatabase::class)->in('Feature'); in Pest PHP. This means that tests that have no need to interact with the database will still run migrations.
To quote Caleb Porzio: 'No Bueno.'
Solution
This PR adds a new drop-in replacement for RefreshDatabase: RefreshDatabaseLazily. By utilising a new QueryExecuting event bundled in with this PR, the test is able to wait until the database is actually required before running the migrations. This means that if a test has no need for the database, migrations will never be run.
The impact of this PR is that you can drop this trait on your base TestCase with 0 consequences. The new QueryExecuting event also allows for users with more complex database requirements to implement similar functionality in their test setup manually.
Why not just alter RefreshDatabase directly?
It is entirely possible that developers make use of Laravel's migrations, but then interact with the database through raw PDO statements. This would lead to the QueryExecuting event never being fired, and the migrations never being run.
As such, allowing developers to opt in to this feature if their application solely makes use of Laravel's DB tools allows for a non-breaking change. I feel the majority of devs will be able to start using this trait immediately, but better safe than sorry.
As always, I want to say a huge thank you for all of the hard work you continue to put into maintaining and building upon the Laravel framework. I am eternally grateful.
Kind Regards,
Luke
Edit: in order to alleviate concerns about performance caused by the QueryExecuting event, I have removed it in favour of a more simplistic and streamlined callback array. This allows for the same functionality without the overhead.

Thanks. What are the before / after benchmarks on some real world scenarios?

Obviously greatly depends on the application; how many non-database tests vs database tests.
In an application with ~400 tests, where around 90% of those tests use the database, I went from 24s to 21s.

Isn't the concern around the emitting of the event on every query called during the application's lifecycle and not directly with the test performance? If an application performed 100 database queries on a request (arguably poor design but you never know!), would the QueryExecuting overhead be noticed in the response time? Even if negligible, those on AWS Lambda (or other serverless environments) would be impacted by a cost increase?
Would it be safer to only emit the event when in the testing environment to being with?

What happens if a test only runs SELECT queries (no INSERT/UPDATE/DELETE queries in this test) ? Will the database still be refreshed ?

@taylorotwell here you can see another application, this one using MySQL rather than SQLite in memory and the saving is pretty drastic...

@windu2b SELECT statements still run through the run method, so the migrations will be run 👍

@timrspratt thanks for the feedback. I've done some testing on this, and with no changes, the event call takes between 0 and 0.1 milliseconds. In honesty, I don't know enough about lambda costs to know how much that would impact costs. I would certainly assume that there would be much larger impacts on costs, such as multiple or inefficient database queries as you pointed out.
Would be good to get some opinions on this for sure.

The impact of this PR is that you can drop this trait on your base TestCase with 0 consequences

Creating a QueryExecuting object every single time a query is executed just to satisfy this performance increase in tests will have an impact slowing down your main app and increase memory usage.
Rather than creating a new event for QueryExecuting for every single query being executed could there be a ConnectionStarted event instead? That would fire only once when connection is started and should only fire when an anticipated query is excepted to be run?

@garygreen ideally we'd link into the connection booting, but that happens regardless of whether a query will be run:
https://github.com/laravel/framework/blob/3806a98df2a8ed2dff17a2f7b5a85524f78c4e6d/src/Illuminate/Database/DatabaseServiceProvider.php#L71
Any ideas? 🤔

ideally we'd link into the connection booting, but that happens regardless of whether a query will be run

Hmm you sure about that? I haven't checked, but that sounds a bit strange if it pre-emptively connects. Briefly looking at the code it creates the PDO object on demand when needed...

@garygreen found the cause.

Create the most basic test possible that doesn't hit the database.
Add a dd call at the top of the make method in ConnectionFactory.
Run the test. You'll hit the dd.

The cause is the ParallelTestingServiceProvider, which boots and registers regardless of whether or not you're running parallel or series. This provider makes a call to DB::connection, which invokes the make method on the ConnectionFactory.
So whilst Laravel wouldn't attempt a DB connection early, tests always will. The ConnectionFactory and DatabaseManager are both singletons.
I've switched out event calling for another solution, which I think provides the best of both worlds.

@windu2b SELECT statements still run through the run method, so the migrations will be run +1

But I think it's useless to refresh the database, if there are only SELECT queries, isn't it ?

@windu2b in an ideal world, yes. However, if a developer has used a select statement and no database exists, it will throw an exception, which would break a previously passing test.

Isn't the root problem that you are adding that trait to tests that don't use the db? Can't you just not do that?

@GrahamCampbell up to this point, that's exactly what I have done in my applications. However, it's annoying to have to keep track of this and muddies up the test cases.
In my opinion (and I dare say in the opinion of a large percentage of the community), this removes complexity and makes it easier to maintain a fast test suite.
If we start saying "can you just not do that" about things, much of Laravel wouldn't exist.
I really appreciate your insights and contributions by the way; just stating my case.

@GrahamCampbell I think this will help reduce the cognitive load for newcomers to testing.
I don't know if you recall when you wrote your first tests, but there is already A LOT of things to take into account.
In my opinion, this is the kind of change that will reduce friction and help more and more people have a good experience with testing 👍

I am just trying to decide if encouraging people to jam all the traits into their tests should be considered a bad practice. We don't encourage people to install every package on packagist in case they need to use them. What's so wrong with having to say "run this test with db migrations". It'll make people think, "do I really need to hit the db for this test?". Lots of people have really slow test suites because they are writing "unit" tests that unnecessarily boot the framework and do all kinds of stuff.

I've personally only added the RefreshDatabase trait it in feature tests/places where I know there will be db tests being done. I didn't realise it was common practise for developers to be adding it in the base TestCase class.
So benefit of this PR will come at a per-test level where it only refreshes when it knows a database query is being run. Still seems like a win if it can be done in a way that doesn't impact main app.
The new callbacks are ok, but I would prefer to see a general one time ConnectionStarted event rather than being able to register callbacks when booting a query (as I'm not sure what other use cases there are for that?). I'm concerned that might encourage naughty packages to add callbacks and slow down queries (and you wouldn't really know why...)
It would be ideal to listen for when database was connected and then assume it's needed. If something in Laravel is connecting too pre-emptively then that should be addressed?

@garygreen how would you handle parallel testing? Laravel has to make an early connection in order to build the required databases in preparation for running across processes.

Laravel has to make an early connection in order to build the required databases in preparation for running across processes

That's the main purpose of this PR, to hook into some mechanism that defers refreshing the DB? Curious to know why does Laravel have to make an "early connection" ? That may well be the case at the moment so wonder if that process can be deferred - run makes a call to reconnectIfMissingConnection which makes it sound like the connection happens only when something is going to happen on the DB, i.e. it's intended to be deferred?

The DatabaseServiceProvider isn't deferred at all, so if what your saying is right then Laravel sets up a database connection every single time the app starts up.. which sounds weird. Especially if you didn't make any db calls i.e. static pages. Could this be something that only happens during tests though?

@lukeraymonddowning
Maybe split the PR into the callback on run and the trait testing stuff
because we could easily implement the trait in userland, but not the hook

@lukeraymonddowning were the benchmarks you shared on this feature on a real-world application or specifically crafted for this PR?
In my own applications I don't think I would see any benefit from this trait because every feature I test that hits controllers in my application is going to authenticate a user which is going to run a database query. It's actually probably pretty rare for me to write a feature test that does not interact with the database at all.

@lukeraymonddowning were the benchmarks you shared on this feature on a real-world application or specifically crafted for this PR?
In my own applications I don't think I would see any benefit from this trait because every feature I test that hits controllers in my application is going to authenticate a user which is going to run a database query. It's actually probably pretty rare for me to write a feature test that does not interact with the database at all.

That's true for my apps too. Even a unit test that involves a model uses the DB in most cases.
Anyways it would be cool to have the event in the framework but the trait in a sperate package aka user-land.

@taylorotwell this was a real world application that we are currently in the process of building. No tweaks were made to the code other than switching out RefreshDatabase for RefreshDatabaseLazily.
A more detailed breakdown of the tests:

438 tests
362 with DB
76 without DB

@lukeraymonddowning and this application is the one where you saw improvement from 24 seconds to 21 seconds?

That's the one 👍 the second example is quite light on the database as it stores the majority of its state in an external API.

Renamed to LazilyRefreshDatabase. Thanks.

excited to release this

A benchmark FYI: 51,76s vs 56,48s


Update rotating drum example

Description of the problem

The large scale rotating drum example contained poorly set parameters and did not run anymore.

Description of the solution

Fixed the paremeters and split the example into two parts to load the particles correctly
Update documentation

Are the modified .prm missing? You say you changed the parameters, but here we only see some clean up in the doc + new video.

The PRM are there, but I added them by mistake when I refactored the dimensionality. The new PRM are actually already there in the master version of Lethe.

All comments have been addressed @voferreira

All comments have been addressed @voferreira

Nice!! On my side, it is ready to go.

Will merge after CI then
:)


Dynamic pages using templates

Hey, very new to Gridsome and I think its wonderful.
I am using wordpress as my headless cms and I want to create a template similar to the wordPressPost.vue but for all pages that dont have a defined page in pages, something like wordPressPage.vue
I understand that templates are used to create single pages for each node (a post for example) in a collection of posts.
My question is can pages also work as posts where they exist in a collection of pages and as such I can have a dynamic template for them instead of having defined pages?
I hope this makes sense :)

You can implement a dynamic route: https://gridsome.org/docs/dynamic-routing/#programmatic-dynamic-routes.
Then you can fetch your data via client side scripting.
In general dynamic pages are not really the purpose of a static website builder.
And if you want to often change / maintain pages you either need to rebuild your gridsome delivery or switch to using a CMS.


darwin.system_cmds: 735.50.6 -> 970.0.4

Description of changes
Update system_cmds to 970.0.4. I replaced the Xcode build system with Meson for easier maintenance.
Tested building both aarch64-darwin and x86_64-darwin early in the bootstrap. Tested full bootstrap with aarch64-darwin.
Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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

I updated the PR to build as many things as possible. The following binaries are gone:

makekey - removed upstream
login - requires entitlements and non-public headers
sadc - removed upstream
sar - removed upstream
zprint - requires IOKitUser framework that isn’t packaged

Building of the following binaries is disabled:

fs_usage - requires non-public header
gcore - requires non-public XPC APIs
reboot - requires IOKitUser framework that isn’t packaged
shutdown -  IOKitUser framework that isn’t packaged

Everything else is built, though a handful have SDK version dependencies:

arch - requires the 11.0 SDK
latency - requires the 12.0 SDK
lskq - requires the 12.0 SDK
lsmp - requirers the 12.0 SDK
mslutil - requires the 10.13 SDK
taskpolicy - requires the 11.0 SDK
vm_purgeable_stat - requires the 11.0 SDK
zlog - requiers the 11.0 SDK

I added a comment explaining the choice to use a vendored meson.build. As other _cmds get bumped, I’ll probably just copy and adapt it to them. Honestly, I just really hate dealing with xcbuild and Xcode projects.

LGTM

I think it needs a new approval with the force push. I added the comment to stay in the spirit of https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#new-packages for non-upstreamed patches (since that’s effectively what the custom build system is).

Once all the checks complete, I’ll go ahead and merge.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/nix-macos-monthly/12330/50

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/darwin-updates-news/42249/2


For #406: changing rultor image

For #406: changing rultor image
Added rultor image to rultor.yml

@rultor merge

@rultor hello

@rultor merge

@paulodamaso OK, I'll try to merge now. You can check the progress of the merge here

@rultor hello

@paulodamaso Hi there! I understand a few simple commands: "merge", "deploy", etc. This page explains them briefly. Any questions or bug reports are welcome. Have fun :)

@rultor merge

@paulodamaso Done! FYI, the full log is here (took me 15min)

@paulodamaso/z this pull request is too small, just 1 lines changed (less than 10), there will be no formal code review, see §53 and §28; in the future, try to make sure your pull requests are not too small; @paulodamaso/z please review this and merge or reject

Job gh:yegor256/jpeek#419 is not assigned, can't get performer


Update Travis config to run builds on all Pull Requests

Description
LEARNER-4338
Reverts: LEARNER-2367 (PR https://github.com/edx/edx-app-android/pull/997)
Due to this change, Travis will checkout current master and put all of the changes done in a PR on top of it through a commit and run tests on it. This will be valid for all PRs i.e. internal and externals (OSPRs).
Note: Following change in Travis's setting has also been done:

Before
After

What files are we pushing to transifex from master?

strings.xml, labels.xml, errors.xml, profiles.json, languages.json and countries.json.

Transifex should already be configured to pull string resources from the repo on a daily basis.

What do you mean by that?


add scale moments to predictions

It is potentially helpful to include estimates of the first and second moments of the scale distribution predicted for each reflection observation. This PR will add that info to the *_predictions_#.mtz files.

Codecov Report

Merging #112 (5596371) into main (d932119) will decrease coverage by 0.41%.
The diff coverage is 16.66%.

@@            Coverage Diff             @@
##             main     #112      +/-   ##
==========================================
- Coverage   82.86%   82.45%   -0.41%
==========================================
  Files          46       46
  Lines        1972     1984      +12
==========================================
+ Hits         1634     1636       +2
- Misses        338      348      +10

Flag
Coverage Δ

unittests
82.45% <16.66%> (-0.41%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

careless/models/merging/variational.py
76.57% <9.09%> (-7.43%)
:arrow_down:

careless/io/manager.py
89.26% <100.00%> (+0.05%)
:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Let cache/temp directory be configurable

:tada: This issue has been resolved in version 3.2.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release
v3.2.0

Your semantic-release bot :package::rocket:


chore: bump nushell version to 0.95.0

As described in the title the only change is updating github action's nushell version to 0.95.0
and the plugin_details.md file is updated (to test the action)

Thanks. Next time I can just run the ci that creates the plugin_details.md.

Well, I just wanted to make sure the script is working on the latest Nushell version, so we do not update the version to something like 1.5 and then see that it's not working. I'll randomly update the script if needed.

yup, seems logical. thanks.


fixes #735 Prevent spaces in path

I replaced spaces by underscores '_' where applicationId is used in :

Connector path
REST connector "test" path

Did not replace other special chars.
Did not replace spaces, where namespace is used for path (but namespace cannot include space right?).

New commit : as discussed, I have added a 'label' property to applications.
When creating an application, its name is the label without special chars by default. Name is still editable.
For previously-created applications (in base or dumps without label), label is copied from the name by default.

Merged. Great ! :)


Low difficulty share

Getting this error from pools :(
Is it because all of them switched to rx/0? Do you have any plans about updating the repo to actual version?
Thank you!

CN/r (rx/0) is very different algo. And it requires realtime code modification (JIT) which is unavailable on iOS.

Thanks for the explanation!


[Bug] Fixed Text Getting Cut Off in Accessibility Mode

Purpose
There's an inconsistency between normal text size and accessibility text size. For example, in accessibility mode, text might appear being cut off while it's not getting cut off in normal text size.
This PR is meant to address this inconsistency.
Does this introduce a breaking change?

[ ] Yes
[x] No

Pull Request Type
What kind of change does this Pull Request introduce?

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Documentation content changes
[ ] Other... Please describe:

How to Test

go to settings, accessibility, enable large font
open the app
start/join a call

What to Check

make sure participant info header has content shown up correctly and texts are not getting cut off
make sure participant's name below its avatar is not getting cut off

Other Information
1. This PR is meant to fix inconsistency between normal font size and accessibility large font sizes. If content was getting cutoff in normal mode (e.g. very long participant's name), it would still be cutoff in accessibility mode (just like how Teams behaves currently).
2. UI team has requested that content be shown in one line and do not wrap the text.
3. testing was done on iPod touch with large font enabled (smallest screen with biggest font sizes):
Testing
Before

After
shown longest text we had for info banner on smallest screen we currently support:

PR looks good, just wondering has the ux been reviewed by Alex?

PR looks good, just wondering has the ux been reviewed by Alex?

Hi Kevin, yes, I have made two prototypes for solutions I had. Alex has chosen the second design which is what this PR is about. You can find our discussions in the teams channel.


[SignalR] (Hub)Exception in OnConnectedAsync sporadically not propagated to .NetClient

Describe the bug
I want to conditionally block some .NET-Client from connecting with my Hub in the OnConnectedAsync overide method by throwing an (hub)exception so that in the client-code the exceptional state gets raised too.
Sporadically the (hub)exception does not get propagated to the client.
To Reproduce
Steps to reproduce the behavior:

Using this version of ASP.NET Core '2.2.0', Microsoft.AspNetCore.SignalR.Client '1.1.0'
Using this code:

Server/Hub
namespace Server
{
    public class ChatHub : Hub
    {
        public Task SendMessage(string user, string message)
        {
            return Clients.All.SendAsync("ReceiveMessage", user, message);
        }

        public override async Task OnConnectedAsync()
        {
            await base.OnConnectedAsync();
            throw new HubException("Denied");
        }
    }
}

Client
namespace Client
{
    class Program
    {
        static async Task Main(string[] args)
        {
            try
            {
                HubConnection connection = new HubConnectionBuilder()
                .WithUrl("http://localhost:5000/ChatHub")
                .Build();

                await connection.StartAsync();
                await connection.InvokeAsync("SendMessage", "Me", "Hello");
            }
            catch (HubException hubEx)
            {
                Console.WriteLine(hubEx.Message);
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex.Message);
            }
        }
    }
}

Run the server and then the client (in my case an console app) multiple times (one at a time).
See that the exception is not raised on the second try
After server-restart the (hub)exception is working again (one more time)

Expected behavior
(Hub)Exception gets propagated to client properly every time.
Screenshot

Additional context
.NET Core SDK
Version:   2.2.106
Commit:    aa79b139a8
Windows 7 - x64
Host (useful for support):
Version: 2.2.4
Commit:  f95848e524

StartAsync doesn't observe the hub method OnConnectedAsync before completing. If you change the try catch to be around InvokeAsync you'll see that the exception is actually coming from that call.
There is an implicit race between the connection closing from the server and the InvokeAsync call starting.
If you want to always observe the HubException then you need to wire up the connection.Closed handler
connection.Closed += (ex) =>
{
    if (ex is HubException hubEx)
    {
        Console.WriteLine(hubEx.Message);
    }
    else
    {
        Console.WriteLine(ex);
    }
    return Task.CompletedTask;
};

Thanks for your suggestion. I tried it but the race condition still remains.
InvokeAsync is called before the connection.Closed handler fires.
My demo client now looks like this:
static async Task Main(string[] args)
{
    try
    {
        HubConnection connection = new HubConnectionBuilder()
        .WithUrl("http://localhost:5000/ChatHub")
        .Build();

        connection.Closed += (ex) =>
        {
            if (ex is HubException hubEx)
            {
                Console.WriteLine(hubEx.Message);
            }
            else
            {
                Console.WriteLine(ex);
            }
            return Task.CompletedTask;
        };

        await connection.StartAsync();
        await connection.InvokeAsync("SendMessage", "Me", "Hello");
    }
    catch (HubException hubEx)
    {
        Console.WriteLine(hubEx.Message);
    }
    catch (Exception ex)
    {
        Console.WriteLine(ex.Message);
    }
    Console.ReadKey();
}

I tried it but the race condition still remains.

Correct, that will always be the case.
What are you trying to do exactly? Is observing the HubException twice an issue?

Correct, that will always be the case.

Ok then my initial idea:

I want to conditionally block some .NET-Client from connecting with my Hub in the OnConnectedAsync overide method by throwing an (hub)exception so that in the client-code the exceptional state gets raised too.

will not work.

I´m still confused why this is by design:

StartAsync doesn't observe the hub method OnConnectedAsync before completing.

Because OnConnectedAsync is the suggested/only hook to Handle events for a connection. For me it sounds like if it is completed before the clients could invoke any further methods on the server.
Imagine the following usecase:

Client calls StartAsync();
Server does some connection mapping in OnConnectedAsync()
StartAsync() completes before mapping is completed
Client invokes Server method which relies on mapping-completition
Crash?

This usecase is pretty similiar to that what im going to do.

Crash?

The server will wait for StartAsync to finish before starting to process invokes from the client.
If you really want to wait for some mapping to finish before doing an invoke on the client you could set up a client handler that StartAsync calls.
var tcs = new TaskCompletionSource<object>(TaskCreationOptions.RunContinuationsAsynchronously);
connection.On("Finished", () =>
{
    tcs.TrySetResult(null);
});
connection.Closed += (ex) =>
{
    tcs.TrySetCanceled();
};
await connection.StartAsync();
await tcs.Task;
await connection.InvokeAsync(...);

public class ChatHub : Hub
{
    public override async Task OnConnectedAsync()
    {
        // mapping etc.
        await Clients.Client(Context.ConnectionId).SendAsync("Finished");
    }
}

Thanks for the suggestion. I´ ll give it a try.


504 Gateway Time-out

When logging in to the dashboard, i receive a 504 gateway timeout. When returning to the main page the user is logged in. After the first 504 the problem is fixed for a couple of hours. When i try to open the dashboard at the end of the day, i receive a new 504 error.
15:12:26 [error] 78#78: *9 upstream timed out (110: Operation timed out) while reading response header from upstream, client: <IP>, server: localhost, request: "GET /dashboard HTTP/1.1", upstream: "fastcgi://<IP_ADDRESS>:9000", host: ", referrer: "

First thought was a php-fpm issue so i changed the www.conf to the following settings
[www]
listen = <IP_ADDRESS>:9000

request_terminate_timeout = 120s

pm = dynamic
pm.max_children = 5
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 500

chdir = /

env[DB_DRIVER] = $DB_DRIVER
env[DB_HOST] = $DB_HOST
env[DB_DATABASE] = $DB_DATABASE
env[DB_USERNAME] = $DB_USERNAME
env[DB_PASSWORD] = $DB_PASSWORD
env[CACHE_DRIVER] = $CACHE_DRIVER

catch_workers_output = yes
access.log = /dev/stdout

[global]
daemonize = no
error_log = /dev/stderr
pid = /tmp/php-fpm.pid

The change didn't help.

+1 on that, we're having the same issue for our status page. A temporary solution is probably to create a health check for it.

I have exactly the same problem ... works perfect on my local machine (macbook) but when I try to run the container on CentOS it stops with this problem .... fastcgi/fpm seems to be running, no other log messages etc.
2021/08/06 09:38:07 [error] 78#78: *1 upstream timed out (110: Operation timed out) while reading response header from upstream, client: <IP_ADDRESS>, server: localhost, request: "GET /dashboard HTTP/1.1", upstream: "fastcgi://<IP_ADDRESS>:9000"


pcolormesh /   _draw_2d_from_bounds doesn't handle time coordinates

This was raised via Met Office Yammer.  Given a 2d cube with a time dimension, pcolormesh does not recognise the time coordinate as such.  Example:
import iris
import iris.plot as iplt
import numpy as np
import matplotlib.pyplot as plt
import matplotlib.dates as mdates

time_coord = iris.coords.DimCoord(range(12), standard_name='time',
                                  units='days since 2019-06-01')

height_coord = iris.coords.DimCoord(range(5), standard_name='height', units='m')

cube = iris.cube.Cube(np.arange(12) + np.arange(5)[:, np.newaxis])
for dim, coord in enumerate([height_coord, time_coord]):
    cube.add_dim_coord(coord, dim)

iplt.contourf(cube)
plt.gca().xaxis.set_major_formatter(mdates.DateFormatter('%d %b'))
plt.show()

iplt.pcolormesh(cube)
plt.gca().xaxis.set_major_formatter(mdates.DateFormatter('%d %b'))
plt.show()

contourf produces this:

For the pcolormesh plot, matplotlib thows an error about non datetime values.  Without the set_major_formatter call, we get this:

contourf uses _draw_2d_from_points which has specific handling for time coordinates.  pcolormesh uses _draw_2d_from_bounds, which doesn't have this handling (as far as I can see).  So possibly we just need to add that if loop to make it consistent (I haven't tried).
There seems to be a fair bit of overlap between the code of _draw_2d_from_points and _draw_2d_from_bounds, so I wonder if it's worth doing some rationalisation while addressing this.

Fixed by #3762 :sunglasses: .


Flushing only new transactions don't do anything

Hello,
Using branch doctrine 2.0.x, I am trying to update the set of translations attached to an existing entity.
When I flush the Entity Manager, there isn't any change to the Database.
Code example:
$entity = $em->find('\\MyNS\\MyEntity');
$translator->translate($entity, 'translatable_field', 'en', 'My new entity translation');
$translator->translate($entity, 'translatable_field', 'fr', 'La nouvelle traduction de mon entité');
$em->flush();

PS: workaround, If I force persist the entity, calling $em->persist($entity), it works.
I am using the Defered Implicit (default) Change Tracking Policy for my entity ( http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/change-tracking-policies.html#deferred-implicit )


block spacing is not being handled correctly

Description
Hi! I think there is a bug in how to the spacing option is being handled in block:
#block(spacing: 0pt)[
  paragraph 1

  paragraph 2

  paragraph 3
]

#set block(spacing: 0pt)

#block[
  paragraph 1

  paragraph 2

  paragraph 3
]

AFAIK both forms should produce the same thing: paragraphs without space between them. However, it happens only in the second case . Additionally,, the SVG output diverges from the PDF output:

Which makes me think it is indeed a bug.
Reproduction URL
No response
Operating system
Linux
Typst version

[X] I am using the latest version of Typst

see #4224