Memory leaks

Just creating the PhysicsCommon causes a massive amounts of memory leakage
Dumping objects ->
{239} normal block at 0x0000023F105CE070, 5242920 bytes long.

Data: <  'O            > 00 83 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{237} normal block at 0x0000023F0EC71390, 16 bytes long.
Data: <  'O            > D0 82 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{236} normal block at 0x0000023F0EC70C10, 16 bytes long.
Data: <  'O            > A0 82 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{235} normal block at 0x0000023F0EC70CB0, 16 bytes long.
Data: <p 'O            > 70 82 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{234} normal block at 0x0000023F0EC70580, 16 bytes long.
Data: <@ 'O            > 40 82 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{233} normal block at 0x0000023F0EC70C60, 16 bytes long.
Data: <  'O            > 10 82 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{232} normal block at 0x0000023F0EC70760, 16 bytes long.
Data: <  'O            > E0 81 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{231} normal block at 0x0000023F0EC70800, 16 bytes long.
Data: <  'O            > B0 81 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{230} normal block at 0x0000023F0EC70D00, 16 bytes long.
Data: <  'O            > 80 81 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{229} normal block at 0x0000023F0EC706C0, 16 bytes long.
Data: <P 'O            > 50 81 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{228} normal block at 0x0000023F0EC6F5E0, 16 bytes long.
Data: <  'O            > 20 81 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{227} normal block at 0x0000023F0EC6F590, 16 bytes long.
Data: <  'O            > F0 80 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{226} normal block at 0x0000023F0EC6F4F0, 16 bytes long.
Data: <  'O            > C0 80 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{225} normal block at 0x0000023F0EC6F4A0, 16 bytes long.
Data: <  'O            > 90 80 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{224} normal block at 0x0000023F0EC6F540, 16 bytes long.
Data: < 'O            > 60 80 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00  {223} normal block at 0x0000023F0EC6FFE0, 16 bytes long.  Data: <0 'O            > 30 80 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00  {222} normal block at 0x0000023F0EC6FB80, 16 bytes long.  Data: <  'O            > 00 80 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00  {221} normal block at 0x0000023F0EC6FB30, 16 bytes long.  Data: <  'O            > D0 7F 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00  {219} normal block at 0x0000023F0EC6FF40, 16 bytes long.  Data: <  'O            > A0 7F 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00  {218} normal block at 0x0000023F0EC6F9F0, 16 bytes long.  Data: <p 'O            > 70 7F 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00  {217} normal block at 0x0000023F0EC6F450, 16 bytes long.  Data: <@ 'O            > 40 7F 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00  {216} normal block at 0x0000023F0EC6F9A0, 16 bytes long.  Data: <  'O            > 10 7F 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00  {215} normal block at 0x0000023F0EC6F950, 16 bytes long.  Data: < ~'O            > E0 7E 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00  {214} normal block at 0x0000023F0EC6F310, 16 bytes long.  Data: < ~'O            > B0 7E 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00  {213} normal block at 0x0000023F0EC6FEA0, 16 bytes long.  Data: < ~'O            > 80 7E 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00  {212} normal block at 0x0000023F0EC6F720, 16 bytes long.  Data: <P~'O            > 50 7E 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00  {211} normal block at 0x0000023F0EC6F130, 16 bytes long.  Data: < ~'O            > 20 7E 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00  {210} normal block at 0x0000023F0EC6FA90, 16 bytes long.  Data: < }'O            > F0 7D 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00  {209} normal block at 0x0000023F0EC6F8B0, 16 bytes long.  Data: < }'O            > C0 7D 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00  {208} normal block at 0x0000023F0EC6F7C0, 16 bytes long.  Data: < }'O            > 90 7D 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00  {207} normal block at 0x0000023F0EC6F900, 16 bytes long.  Data: <}'O            > 60 7D 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{206} normal block at 0x0000023F0EC70030, 16 bytes long.
Data: <0}'O            > 30 7D 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{205} normal block at 0x0000023F0EC6FE50, 16 bytes long.
Data: < }'O            > 00 7D 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{204} normal block at 0x0000023F0EC6F810, 16 bytes long.
Data: < |'O            > D0 7C 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{203} normal block at 0x0000023F0EC6F2C0, 16 bytes long.
Data: < |'O            > A0 7C 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{202} normal block at 0x0000023F0EC6FAE0, 16 bytes long.
Data: <p|'O            > 70 7C 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{201} normal block at 0x0000023F0EC6F630, 16 bytes long.
Data: <@|'O            > 40 7C 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{200} normal block at 0x0000023F0EC6F400, 16 bytes long.
Data: < |'O            > 10 7C 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{199} normal block at 0x0000023F0EC6F6D0, 16 bytes long.
Data: < {'O            > E0 7B 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{198} normal block at 0x0000023F0EC6FC20, 16 bytes long.
Data: < {'O            > B0 7B 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{197} normal block at 0x0000023F0EC6F220, 16 bytes long.
Data: < {'O            > 80 7B 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{196} normal block at 0x0000023F0EC6FE00, 16 bytes long.
Data: <P{'O            > 50 7B 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{195} normal block at 0x0000023F0EC6F0E0, 16 bytes long.
Data: < {'O            > 20 7B 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{194} normal block at 0x0000023F0EC6FF90, 16 bytes long.
Data: < z'O            > F0 7A 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{193} normal block at 0x0000023F0EC6F270, 16 bytes long.
Data: < z'O            > C0 7A 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{192} normal block at 0x0000023F0EC6FEF0, 16 bytes long.
Data: < z'O            > 90 7A 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{191} normal block at 0x0000023F0EC6FDB0, 16 bytes long.
Data: <`z'O            > 60 7A 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{190} normal block at 0x0000023F0EC6FD60, 16 bytes long.
Data: <0z'O            > 30 7A 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{189} normal block at 0x0000023F0EC6F360, 16 bytes long.
Data: < z'O            > 00 7A 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{188} normal block at 0x0000023F0EC6FA40, 16 bytes long.
Data: < y'O            > D0 79 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{186} normal block at 0x0000023F0EC6FBD0, 16 bytes long.
Data: < y'O            > A0 79 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{185} normal block at 0x0000023F0EC6FCC0, 16 bytes long.
Data: <py'O            > 70 79 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{184} normal block at 0x0000023F0EC6F1D0, 16 bytes long.
Data: <@y'O            > 40 79 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{183} normal block at 0x0000023F0EC6F180, 16 bytes long.
Data: < y'O            > 10 79 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{182} normal block at 0x0000023F0EC6FD10, 16 bytes long.
Data: < x'O            > E0 78 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{181} normal block at 0x0000023F0EC6F680, 16 bytes long.
Data: < x'O            > B0 78 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{180} normal block at 0x0000023F0EC6F770, 16 bytes long.
Data: < x'O            > 80 78 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{179} normal block at 0x0000023F0EC6FC70, 16 bytes long.
Data: <Px'O            > 50 78 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{178} normal block at 0x0000023F0EC6F3B0, 16 bytes long.
Data: < x'O            > 20 78 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{177} normal block at 0x0000023F0EC6F860, 16 bytes long.
Data: < w'O            > F0 77 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{176} normal block at 0x0000023F0EC6C020, 16 bytes long.
Data: < w'O            > C0 77 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{175} normal block at 0x0000023F0EC6CED0, 16 bytes long.
Data: < w'O            > 90 77 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{174} normal block at 0x0000023F0EC6CD90, 16 bytes long.
Data: <0w'O            > 30 77 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{173} normal block at 0x0000023F0EC6CC00, 16 bytes long.
Data: < w'O            > 00 77 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{172} normal block at 0x0000023F0EC6CBB0, 16 bytes long.
Data: < v'O            > D0 76 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{171} normal block at 0x0000023F0EC6CC50, 16 bytes long.
Data: < v'O            > A0 76 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{170} normal block at 0x0000023F0EC6CB10, 16 bytes long.
Data: <pv'O            > 70 76 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{169} normal block at 0x0000023F0EC6C980, 16 bytes long.
Data: <@v'O            > 40 76 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{168} normal block at 0x0000023F0EC6C4D0, 16 bytes long.
Data: < v'O            > 10 76 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{167} normal block at 0x0000023F0EC6C840, 16 bytes long.
Data: < u'O            > E0 75 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{166} normal block at 0x0000023F0EC6C9D0, 16 bytes long.
Data: < u'O            > B0 75 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{165} normal block at 0x0000023F0EC6C7F0, 16 bytes long.
Data: <xu'O            > 78 75 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{164} normal block at 0x0000023F0EC6CE80, 16 bytes long.
Data: <@u'O            > 40 75 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{163} normal block at 0x0000023F0EC6C480, 16 bytes long.
Data: < u'O            > 10 75 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{162} normal block at 0x0000023F0EC6C430, 16 bytes long.
Data: < t'O            > E0 74 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{161} normal block at 0x0000023F0EC6C750, 16 bytes long.
Data: < t'O            > B0 74 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{160} normal block at 0x0000023F0EC6C1B0, 16 bytes long.
Data: <xp'O            > 78 70 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
{159} normal block at 0x0000023F0EC6CAC0, 16 bytes long.
Data: <0'O            > 30 5C 27 4F F6 7F 00 00 00 00 00 00 00 00 00 00
Object dump complete.
What am I doing wrong ?

Can I ask you what are those logs? Where are they coming from?

Do you have an error message somewhere? Can you paste your complete code here? Can you also try to compile the "Hello World" application and see if you have the same issue?

This is the most basic things we wrote
visual studio 2022 , c++17.
also we noticed 12 warnings related to uninitialized variables in various classes
#pragma warning(disable:6386)
#pragma warning(disable:26451)
// debug_new.cpp
// compile by using: cl /EHsc /W4 /D_DEBUG /MDd debug_new.cpp
#define _CRTDBG_MAP_ALLOC
#include
#include <crtdbg.h>
#ifdef _DEBUG
#define DBG_NEW new ( _NORMAL_BLOCK , FILE , LINE )
// Replace _NORMAL_BLOCK with _CLIENT_BLOCK if you want the
// allocations to be of _CLIENT_BLOCK type
#else
#define DBG_NEW new
#endif
/////////////////////////////////////////////////////////////////////////////////////////////
#include <vml2.0\libs\reactphysics3d\reactphysics3d\reactphysics3d.h>
using namespace reactphysics3d;
///////////////////////////////////////////////////////////////////////////////////////////////////
int main()
{
_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF | _CRTDBG_REPORT_FLAG);
_CrtSetReportMode(_CRT_ERROR, _CRTDBG_MODE_DEBUG);
PhysicsCommon physicsCommon;

_CrtDumpMemoryLeaks();

return 0;

}

I am not familiar with _CrtDumpMemoryLeaks() (I only use valgrind on Linux to check this) but in your code when this function is called the memory as not been released yet (the call is before the return statement). In your pointer version of that code, did you call _CrtDumpMemoryLeaks() after the delete statement?
Is this tool able to tell where in the code the leaks are happening (like valgrind)?

yes , the code structure stays the same, , no matter how you instantiate physicscommon, the leak detector always reports those memory leaks

Yes but I mean you are aware that in your code example above you test for leaks BEFORE releasing memory and therefore it's normal to find leaks in this situation. In your code above the destructor of the "physicsCommon" instance has not been called when you call _CrtDumpMemoryLeaks(). The destructor is only call at the end of the main function. Can you confirm  that your code above is wrong or is there something I misunderstand?

Hello. I took some time to investigate this. I am able to reproduce your results. I tried to break at the memory allocations with possible leaks. However, the only ones that I am able to break on, are allocations that are correctly released at the end. I tried to use two other different memory leak debuggers (valgrind and VLD) and they don't find any leak for the same example. I don't know if those results are part of the possible false positives of the CRT leak detection that are described here but I am not able to prove the memory leaks.
I don't have enough experience with the CRT memory leak detector of Visual Studio to go further. I will close this issue for the moment but feel free to let me know if you an any idea how to proceed to prove there are indeed memory leaks.


Excessive null checks degrading performance

Describe your issue
I tried to perf-test javalin and it seems that abnormal amount of CPU time is spent in simple null-checks

6 seconds for 70k requests does seem slow 🤔

Are you using Java or Koltin?

Are you using Java or Koltin?

Java. Kotlin functions are there from the Javalin build itself.

@desert-dev
Are you by any chance using instrumentation when profiling?
Instrumentation can really skew these results, especially when it comes to these tiny oft-called functions (such as null checks).
JProfiler, which is the tool I use, has a feature where you can exclude these short functions from the profile due to this problem.
JProfiler Method Call Recording
I've done a lot of profiling with Javalin services and I have never had this function pop up in my hot-spots view, but I always use sampling instead of instrumentation.


Look at using Rank Evaluation for testing search

In order to ensure quality of search results look at using Rank Evaluation for testing relevancy of search results to known queries.
Rank Evaluation allows you to evaluate the effectiveness of a query against some expected result.
See:

https://www.elastic.co/guide/en/elasticsearch/reference/current/search-rank-eval.html
https://www.elastic.co/blog/test-driven-relevance-tuning-of-elasticsearch-using-the-ranking-evaluation-api

Closing as “yeah, we did this 😎”


add suport for customized Polr instances

Hi,
I've changed a little your extension allowing it to use any Polr instance.
polr.me is an Open Source and very light URL shortener.
In order to run this changes with my instance of Polr I had to change a header of the response from the server, but I am sending patches to its authors also.
Best Regards,
Claudemir

This is the Issue I've opened on Polr project: https://github.com/cydrobolt/polr/issues/205

I would merge this however, I found some bugs and suggestions that need to be fixed.

#option_polr_show and #option_polr_hide do not display properly when both user-inputted variables are empty. They can also be put under one element and using data-attributes and using the css :after tag (Just my personal preference, changing text using jQuery.text is viable too.)
URLs should be validated using the isValidUrl function that is included in the settings.js
The polr apiKey and url variables can be initalized within the apiData object itself.
Add capitlization to the show/hide config

Other than that, this would be a great addition.

Thank you for your reply @Wassup789 , HTML and Javascript is not where I am good, so, you can think of my suggestion as a quick hack. Learning about data attributes right now!
The hiding of hide and show links when url and api are empty was intentional, since it will not work without them, I chose to show them until they are filled and saved.
Will try to do your suggestions and will get back here to post.
Best Regards,
Claudemir

Made some enhancements following your suggestions. Included also the display of https:// before the url field, since I think it is wise to only use polr instances that support encryption.

Sorry for the late reply, there are some issues with how the base URL is displayed I can fix that. I recommend you make a pull request to the Polr repository about the CORS issue.

I will talk with the author again. Now that your extension have support to
it I can point it back!
Thank you!
Em ter, 30 de ago de 2016 às 18:16, Wassup789<EMAIL_ADDRESS>escreveu:

Sorry for the late reply, there are some issues with how the base URL is
displayed I can fix that. I recommend you make a pull request to the Polr
repository about the CORS issue.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Wassup789/URL-Shortener/pull/1#issuecomment-243559652,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFyh0DvR0TMJ-hJpsY566_ujmkWTPJ7vks5qlIsugaJpZM4Jnx5A
.


Exporting big project for Windows not working in Godot 3.4.1 (working in Godot 3.4)

Godot version
3.4.1
System information
Linux, GLES3
Issue description
I exported a big project for Windows with embedded PCK in Godot 3.4.1. When I try to execute the game, I get the following alert:

Exporting for Linux, macOS or Windows without embedded PCK works fine (gives a file of about 5 GiB).
Steps to reproduce
Export a big project with embedded PCK for Windows in Godot 3.4.1.
Minimal reproduction project
No response

@AgentSmith0 Can you reproduce this in any of the 3.4.1 RCs to determine when the regression started?

@Calinou Yes, it works when I disable PCK embedding. I will now try to determine when the regression has started.

Are use exporting 32-bit or 64-bit executable, 32-bit exports can't have more than 4 GB embedded due to EXE format limitations.

@bruvzg I am exporting for Windows 64-bit on a 64-bit machine.

Is any of the rcedit related properties (application/* export settings, like icon) or code signing enabled? Is it working if none of this is enabled?
Seems like the size of the embedded data is a 32-bit value even in the 64-bit executable.
https://github.com/godotengine/godot/blob/8485d0c53a55ee0295187a3144b390f35787b57d/platform/windows/export/export.cpp#L127-L130

Seems like the real limit is even lower, only 2 GB for both 32 and 64 executables:

PE32+ images allow for a 64-bit address space while limiting the image size to 2 gigabytes.

Quote from the PE spec: https://docs.microsoft.com/en-us/windows/win32/debug/pe-format

Since it's format limitations, it can't be fixed, but we should add a check and error message if it's too big and update the documentation.

Thank you for the information. I think this issue can then be closed.


Test GitHub Actions CI

Just added a comment to the yml file to test if the GitHub Actions CI tests actually run now.

It worked! Yay!


Add support for pressing the OK button for Web OS.

I think this may been implemented in the change aa9704b8b2e4acb0660aa22a1022eec187f42e9b

This has been implemented and tested.


Builds take long time to start

I have noticed that builds seem to be taking a very long time to start, during this time there is nothing in the build log in the web interface but there is in the upstart log:
Step 0 : FROM bradrydzewski/go:1.2
 ---> 7bf9ce0ffb72
Step 1 : WORKDIR /var/cache/drone/src/github.com/my/repo
 ---> Running in 9897483f0721
 ---> 0a5f2c00f865
Step 2 : ADD drone /usr/local/bin/
 ---> 35f48080c2f9
Step 3 : USER ubuntu
 ---> Running in 76fdc8f3126c
 ---> 1aa2dad1c69a
Step 4 : ENV HOME /home/ubuntu
 ---> Running in ef66760bb54a
 ---> fd22769bbc58
Step 5 : ENV LANG en_US.UTF-8
 ---> Running in b12224227e2b
 ---> c4e4e0590fc2
Step 6 : ENV LANGUAGE en_US:en
 ---> Running in a529ac18ebbf
 ---> 646269d351a0
Step 7 : ENV LOGNAME ubuntu
 ---> Running in 928f447f5d9f
 ---> 1d0ecf15b5b4
Step 8 : ENV TERM xterm
 ---> Running in 42910d0717ab
 ---> 1778ff5782c7
Step 9 : ENV SHELL /bin/bash
 ---> Running in 26d8f4475770
 ---> eb0a7d686f01
Step 10 : ADD id_rsa /home/ubuntu/.ssh/id_rsa
 ---> 430c700152d1
Step 11 : RUN sudo chown -R ubuntu:ubuntu /home/ubuntu/.ssh
 ---> Running in ca3868293929
 ---> 3620e6d713c3
Step 12 : RUN sudo chown -R ubuntu:ubuntu /var/cache/drone
 ---> Running in dda1675e3511
 ---> 5abf83090166
Step 13 : RUN sudo chown -R ubuntu:ubuntu /usr/local/bin/drone
 ---> Running in 778203694d59
 ---> cf0bb558aa6a
Step 14 : RUN sudo chmod 600 /home/ubuntu/.ssh/id_rsa
 ---> Running in 7554a7fec30b
 ---> 89ae884ace03
Step 15 : ADD proxy.sh /etc/drone.d/
 ---> 91ea59bef1bd
Step 16 : ENTRYPOINT /bin/bash -e /usr/local/bin/drone
 ---> Running in 0bbbfa175e6a
 ---> 0315fb8155a3
Successfully built 0315fb8155a3
Removing intermediate container b12224227e2b
Removing intermediate container 42910d0717ab
Removing intermediate container 26d8f4475770
Removing intermediate container ca3868293929
Removing intermediate container 7554a7fec30b
Removing intermediate container 5d25ad49b24d
Removing intermediate container 0bbbfa175e6a
Removing intermediate container a529ac18ebbf
Removing intermediate container 778203694d59
Removing intermediate container ef66760bb54a
Removing intermediate container 5dcbb9a9f739
Removing intermediate container 9897483f0721
Removing intermediate container 03fdb5634aff
Removing intermediate container 76fdc8f3126c
Removing intermediate container 928f447f5d9f
Removing intermediate container dda1675e3511
copying repository to /var/cache/drone/src/github.com/my/repo
starting build
temp directory is /tmp/drone
removing build container
removing build image
2014/04/15 13:29:59 error updating github status: Not Found

Here is the .drone.yml
image: bradrydzewski/go:1.2
script:
  - make deps-ci
  - make pkg
notify:
  email:
    recipients:
      - mail@example

The make commands perform very simple commands like go get and go build.
I thought maybe the problem was performance of the server but just wanted clarification.
I am using a very recent drone build from a few days ago and the latest docker that their documentation installs (0.10) I believe).

I've tried @yanc0 solution and it worked
sudo apt-get install linux-image-extra-$(uname -r)
sudo reboot

But right now, i'm not able to build any commit (everything was working well before the apt install). The error shown is:
2015/03/12 11:42:00 Error building 4010ea63eae7e66026ef1be68b74c36e584b32ee, Err: Error: Unable to pull image bradrydzewski/postgres:9.1
2015/03/12 11:42:00 subscription's close channel received message
2015/03/12 11:42:01 WS: Error getting build stream from channel

Has anyone any idea on what's going on in here? Thanks in advance.

You need to re-pull any containers you relied on prior to making the change
On Thu, Mar 12, 2015, 6:44 AM mbajur<EMAIL_ADDRESS>wrote:

I've tried @yanc0 https://github.com/yanc0 solution and it worked
sudo apt-get install linux-image-extra-$(uname -r)
sudo reboot
But right now, i'm not able to build any commit (everything was working
well before the apt install). The error shown is:
2015/03/12 11:42:00 Error building 4010ea63eae7e66026ef1be68b74c36e584b32ee, Err: Error: Unable to pull image bradrydzewski/postgres:9.1
2015/03/12 11:42:00 subscription's close channel received message
2015/03/12 11:42:01 WS: Error getting build stream from channel
Has anyone any idea on what's going on in here? Thanks in advance.
—
Reply to this email directly or view it on GitHub
https://github.com/drone/drone/issues/271#issuecomment-78465269.

just ran into this as well on CentOS 7; no idea why devicemapper performance is so terrible, but we were able to work around it by upgrading to elrepo's kernel-ml (3.19.1-1), and adjusting `/etc/sysconfig/docker-storage' with:
DOCKER_STORAGE_OPTIONS=--storage-driver=overlay --storage-opt=dm.fs=xfs --storage-opt=dm.mountopt=nodiscard

the improvement is quite pronounced...
devicemapper:
<EMAIL_ADDRESS>~]$ time docker run --rm -it centos true

real	0m3.371s
user	0m0.013s
sys	0m0.014s

overlayfs
<EMAIL_ADDRESS>~]$ time docker run --rm -it centos true

real	0m0.308s
user	0m0.019s
sys	0m0.010s

I tried overlayfs on CentOS 7, but I faced with this problem > "Overlay FS "invalid argument" issues with Centos 7" https://github.com/docker/docker/issues/12488. I could not switch to overlayfs. Just FYI.

I installed a kenel with aufs support provided by https://github.com/bnied/rhel-aufs-kernel (https://yum.spaceduck.org/) for CentOS 7. By changing to aufs, the time until starting drastically improved. Just FYI.


Why is CLI global usage "not recommended"?

In the Installation section of the Setup page of the website, it mentions that installing through npm using -g is "not recommended." I was wondering why that is. Is it because the recommended usage would be to use cssnext in a build tool or script of some sort, or is there something else to this?
I also noticed that there is no installation bullet point noted as "recommended," so a newcomer might be left confused.
If someone can explain to me the reasons for the notes, I can take a stab at contributing copy to that page to pass the knowledge on.

this type of installation isn't recommended because the versions you want across your projects can be incompatible. to prevent this, install cssnext locally and use npm scripts in your package.json:
{
  "scripts": {
    "css": "cssnext src/styles/index.css dist/index.css"
  }
}

and then run:
$ npm run css

you can also add ./node_modules/.bin to your $PATH to get the right CLI locally.

I will add this to the incoming FAQ


Short link for app stores

Create a short link something like http://app.hexawallet.io which redirects to the respective store based on the OS

We can use:
https://hexawallet.io/downloadhexa.html

Short link for stores: http://hexawallet.io/store

Closing this issue as discussed with dev.


Refactoring Services

The init.py and common.py are not the correct place for logics, in order to improve the project we did create a vaccum specific folder for the services that are group in the mqtt_vacuum_services.py

Summary by CodeRabbit

New Features

Introduced a more centralized service management approach for vacuum operations.
Added new asynchronous service functions for vacuum control, including cleaning segments, zones, and map management.

Bug Fixes

Streamlined error handling for service functions to improve reliability.

Chores

Updated version number from 2024.11.0 to 2024.11.1.
Removed obsolete functions to enhance code clarity and focus.

@coderabbitai review @sca075
Refactoring Services for the Camera and improving init
09400e6
@sca075
Removed unused library from init.py


Fix Login Styles

The css preflight was only being included in @tinacms/toolkit and not tinacms given it was assumed that would always be wrapped in the toolkit's styles, but this isn't the case of at least the login screen. I just copied it over, but it's possible the tinacms package could import the preflight from the toolkit.
Before:

After:

@spbyrne I think you forgot to add a changeset.
They can be added with
yarn changeset in the monorepo.


Release to Raycast Store

TODO

[x] Take screenshots after the next release
[x] Update readme
[x] Rename repo?
[x] Show line number when adding/removing favorites
[x] Improve empty state view
[x] Update search placeholder
[x] Transport mode captitalization
[x] Use the Navigation API
[x] Update Navigation Title. See below.
[x] npm updates
[x] Make PR to https://github.com/raycast/extensions 🚀
[ ] Make releases on GitHub once it's out (v3.0 and v3.1)

✨🚀✨


i/o timeout

I get i/o timeout error after a connection reset.
*net.OpError: read tcp <IP_ADDRESS>:60799->13.x.x.x:5432: i/o timeout
After 10seconds, the connection times out and subsequent requests works fine.

Timeouts happen. It's okay.
Bun itself can't be responsible for timeouts, because conns are created and managed by database/sql drivers. If you using pgdriver and suspect it, you can switch to pgx and see if the problem goes away.


Check length of generations in allocator before killing

Probably fixes https://github.com/slide-rs/specs/issues/440 but would probably be good to double check there isn't anything wrong here.
From issue on my reasoning why I think this should be enough:

Since atomically created entities don't have a generation in the Allocator until merge  is called, so if you atomically create an entity and it is the first of  its generation, then it will be out of range and panic. And since we  remove the entity from raised a line before, then it should never be allocated in the future and should be safe to just ignore that entity on kill.

This change is

bors r+


[ Bug ] API Request to early/to few retries?

Describe the bug
Yesterday while casting i noticed a few failed API request.
While spectating Game One after the Champselect the fetching of live game data failed. This worked fine in the second game.
Meanwhile in the first Game the fetching of match data worked while that failed after the second game.
To Reproduce
I guess its just random API luck.
Expected behavior
The retries wait a bit after a few retries in case of a slow api.
Logs
2023-07-02T17:06:43.780Z [info ] module-league-state: Flow: lobby - active
2023-07-02T17:08:06.478Z [info ] module-league-state: Flow: champselect - active
2023-07-02T17:15:44.530Z [info ] module-league-state: Flow: champselect - game started (spectator delay)
2023-07-02T17:15:44.538Z [info ] plugin-webapi: Fetching livegame data for summoner=Player1
2023-07-02T17:15:44.681Z [warn ] plugin-webapi: Failed to get spectator game information for summoner=Player1, encryptedId=some-string. Maybe this summoner is not ingame currently? Retrying. error=StatusCodeError: 404 - "{\"status\":{\"message\":\"Data not found\",\"status_code\":404}}"
2023-07-02T17:15:46.681Z [error] plugin-webapi: Failed to get spectator game information for summoner=Player1, encryptedId=some-string, after retries.
2023-07-02T17:15:46.685Z [error] module-league-state: Loading livegame failed for summoner=Player1
2023-07-02T17:18:46.097Z [info ] module-league-state: Flow: lobby - inactive
2023-07-02T17:18:46.719Z [info ] module-league-state: Flow: champselect - inactive
...
2023-07-02T17:40:20.711Z [info ] plugin-webapi: Fetching match data for matchid=123412
2023-07-02T17:40:20.992Z [info ] plugin-webapi: Fetched match for matchId=123412, gameId=3123123123

2023-07-02T17:48:45.672Z [info ] module-league-state: Flow: lobby - active
2023-07-02T17:51:39.181Z [info ] module-league-state: Flow: champselect - active
2023-07-02T17:59:18.698Z [info ] module-league-state: Flow: champselect - game started (spectator delay)
2023-07-02T17:59:18.706Z [info ] plugin-webapi: Fetching livegame data for summoner=Player1
2023-07-02T17:59:18.845Z [info ] plugin-webapi: Fetched livegame for summoner=Player1, gameId=2131231
2023-07-02T18:02:19.761Z [info ] module-league-state: Flow: lobby - inactive
2023-07-02T18:02:20.737Z [info ] module-league-state: Flow: champselect - inactive
...
2023-07-02T18:33:39.720Z [info ] plugin-webapi: Fetching match data for matchid=12312312
2023-07-02T18:33:39.845Z [error] plugin-webapi: Failed to get match information for matchId=12312312. Maybe the match is not over yet? error=AxiosError: Request failed with status code 404
2023-07-02T18:33:39.847Z [error] module-league-state: Loading match failed for gameId=123123123123

System:

OS: [e.g. iOS]
Node: [e.g. 16.4]
Prod Tool Version: [e.g. 1.3.0]
Observer Tool Version: [e.g. 1.0.0]
Streaming Software & Version: (If it is a problem while streaming or testing)
Browser: [e.g. chrome, safari]

Additional context
Currently i have to watch the server logs so i can manually fetch the data again if it fails which is a bit annoying.
Maybe there should be a bigger delay for retries.

this issue should be fixed with the newest version of the webapi plugin


Ability to create custom groups in the OS popup for filtering

Describe the solution you'd like
Ability to create groups for sorting in App page.  Currently there is only 3 platforms and custom.  Within Android there are alot of platforms that are really separate.  Also support for PS4 and Roku is key
Describe alternatives you've considered
Another popup called tags, which we could then tag our apps and have the filter work there.
Similar to HA.
Additional context
Add any other context or screenshots about the feature request here.

@gwootton thanks for the feature request! We don't have any immediate plans to support this but we'll monitor this feature request to help our team prioritize in the future.


Python 3.10 blockers

This issue will serve to track what blockers there are to bump to 3.10 if we want to.
Probably worth waiting for 3.10.1
No wheels:

[ ] hiredis-py https://github.com/redis/hiredis-py/pull/120
[X] rapidfuzz https://github.com/maxbachmann/RapidFuzz/issues/141

Currently blocked by numpy wheels https://github.com/numpy/numpy/issues/20039

[X] pycares @Akarys42 DMed the author to make a new release, their ci is all ready, just needs a release made https://github.com/saghul/pycares

Also raised https://github.com/saghul/pycares/pull/164 to update their test CI

[x] psutil https://github.com/giampaolo/psutil/issues/2028

Need to bump version of regex for 3.10 wheels

With the release of https://github.com/SebastiaanZ/async-rediscache/releases/tag/v1.0.0-rc1 there are no longer any blockers to using Python 3.10.
We can go ahead and make a start on 3.10 using this release candidate and bump up to the production version when it is made before merging.


Updating mods will update mods to a version no longer compatible with current Factorio version.

If you are running the stable branch of factorio, and a mod releases a new version that requires an experimental branch of factorio, it will still download and update the mod and therefor disabeling the mod entirely.
Reproduce:
Use the current Factorio Stable Version (1.1.80) with UPDATE_MODS_ON_START flag.
Install Rampant Version 3.3.2
It will then procede to update Rampant to version 3.3.3 which requires Factorio Version >=1.1.81 which is at this point still experimental. And therefor the mod will not load anymore.

Was thinking about something like checking the version of the base dependency of a mod from its info.json before actually updating the mod. And then only proceede with updating it if its still compatible

This sounds like a good suggestion to me. But, correct me if I'm wrong, the whole mod management is done directly from within factorio, isn't it? And therefore https://forums.factorio.com/viewforum.php?f=6 might be a good place to start a discussion?

Theres this logic i'd assume that is actually responsible to updating the mods.
https://github.com/factoriotools/factorio-docker/blob/d7e6952db8fca853e34b85b209f8d967442a4bb4/docker/files/update-mods.sh#L1-L96

Oh, I see now, thanks for pointing this out!
The helper script is called, if the appropriate flag UPDATE_MODS_ON_START is set:
https://github.com/factoriotools/factorio-docker/blob/d7e6952db8fca853e34b85b209f8d967442a4bb4/docker/files/docker-entrypoint.sh#L43
And then the file you mentioned is executed. :thinking:
It appears to me, that currently only the major and minor version of factorio is taken into consideration when updating mods.
Because, in the info_json ( https://mods.factorio.com/api/mods/Rampant ) only the major/minor version is mentioned (i.e. factorio_version).
And this checks, if a mod version matching the major/minor factorio version has been found.
https://github.com/factoriotools/factorio-docker/blob/d7e6952db8fca853e34b85b209f8d967442a4bb4/docker/files/update-mods.sh#L47

To get the base dependency https://mods.factorio.com/api/mods/Rampant/full would need to be called here: https://github.com/factoriotools/factorio-docker/blob/d7e6952db8fca853e34b85b209f8d967442a4bb4/docker/files/update-mods.sh#L33
As only that endpoint provides the dependencies: https://wiki.factorio.com/Mod_portal_API#Releases
And then use something like this:
MOD_INFO=$(echo "$MOD_INFO_JSON" | jq -j --arg version "$FACTORIO_VERSION" ".releases|reverse|map(select(.info_json.factorio_version as \$mod_version | \$version | startswith(\$mod_version)))[0]|.file_name, \";\", .download_url, \";\", .sha1, \";\", .info_json.dependencies[0]")
And that:
MOD_BASE_DEPENDENCY=$(echo "$MOD_INFO" | cut -f4 -d";")
to parse the base dependency, to be checked later. Not sure, how to do that properly in bash, though.

A quickly cobbled together solution (thanks stackoverflow ;) ) for comparing the versions might be something like this (following the parsing of the json from above):
MOD_BASE_DEPENDENCY_VERSION=$(echo $MOD_BASE_DEPENDENCY | awk '{print $3}')

if [ $(echo -e "${MOD_BASE_DEPENDENCY_VERSION}}}\n${VERSION}"| sort -V | head -1) != "${MOD_BASE_DEPENDENCY_VERSION}}}" ]; then echo "Base dependency fullfilled."; else echo "Base dependency is not fulfilled.";fi

Yea, i don't know bash black magic sry can't help with that :D

@Fank Would you be able to help us out here, on how to implement such a check?

Maybe @KagurazakaNyaa can provide some good input quicker than me :D

Oh, I see now, thanks for pointing this out! The helper script is called, if the appropriate flag UPDATE_MODS_ON_START is set:
https://github.com/factoriotools/factorio-docker/blob/d7e6952db8fca853e34b85b209f8d967442a4bb4/docker/files/docker-entrypoint.sh#L43
And then the file you mentioned is executed. 🤔
It appears to me, that currently only the major and minor version of factorio is taken into consideration when updating mods. Because, in the info_json ( https://mods.factorio.com/api/mods/Rampant ) only the major/minor version is mentioned (i.e. factorio_version). And this checks, if a mod version matching the major/minor factorio version has been found.
https://github.com/factoriotools/factorio-docker/blob/d7e6952db8fca853e34b85b209f8d967442a4bb4/docker/files/update-mods.sh#L47
To get the base dependency MOD_INFO_URL="$MOD_BASE_URL/api/mods/$MOD_NAME_ENCODED/full" (e.g. https://mods.factorio.com/api/mods/Rampant/full) would need to be called here:
https://github.com/factoriotools/factorio-docker/blob/d7e6952db8fca853e34b85b209f8d967442a4bb4/docker/files/update-mods.sh#L33
As only that endpoint provides the dependencies: https://wiki.factorio.com/Mod_portal_API#Releases
And then use something like this: MOD_INFO=$(echo "$MOD_INFO_JSON" | jq -j --arg version "$FACTORIO_VERSION" ".releases|reverse|map(select(.info_json.factorio_version as \$mod_version | \$version | startswith(\$mod_version)))[0]|.file_name, \";\", .download_url, \";\", .sha1, \";\", .info_json.dependencies[0]")
(Which, for example, provides this output: Rampant_3.3.3.zip;/download/Rampant/6459c957d2fe774477f3f390;12271dbb9e63ecc1e13987fab7e4ec094b8e884c;base >= 1.1.81)
And that: MOD_BASE_DEPENDENCY=$(echo "$MOD_INFO" | cut -f4 -d";") to parse the base dependency, to be checked later. Not sure, how to do that properly in bash, though. (Which, for example, provides this output: base >= 1.1.81)

There is a problem here, if a mod's dependency is indirectly dependent on an incorrect version of base, then we cannot detect this way, such as mod a==1.1 require b<=1.1 and a==1.2 require b<=1.2, and b==1.1 require base<=1.1.80 (that is, stable), b==1.2 require base<=1.1.85 (that is, latest)
In this case, if we update a to the latest version, it will still break the dependency, and its dependency b will not be updated, because the detected version of base is incorrect

However, if you can ensure that each mod includes its dependencies on base, then this solution is feasible. Maybe we can refer to https://github.com/cloudflare/semver_bash to compare the semver-style version number , only need to convert <= to semverLT, >= to semverGT such a comparison method
We skip updates to this mod when dependencies are not met, but we still can't properly handle dependencies other than the base package unless we reimplement factorio's mod management system in the shell


Typo in "Target object" section

This property specifies which object will get transformed by the bounds control manipulation. If no object is setit defaults to the owner object.
-->
This property specifies which object will get transformed by the bounds control manipulation. If no object is set, it defaults to the owner object.

文件詳細資料
⚠ 請勿編輯此區段。 這是 docs.microsoft.com ➟ GitHub 問題連結的必要項。

ID: 88931aed-f7dd-9d97-36c6-9838acdf96f6
Version Independent ID: 0b0f869c-60aa-e077-1a00-bb04f8253e78
Content: BoundsControl - Mixed Reality Toolkit
Content Source: mrtk-unity/features/ux-building-blocks/bounds-control.md
Product: mixed-reality
GitHub Login: @thalbern
Microsoft Alias: bethalha

Thanks for the catch!


trim metal 5 straps going into user_project_wrapper

implement magic script to erase metal 5 from caravel going into pr boundary of user project area. Add for met5 spacing as well to avoid drc issues.

Fixed with PR #139


⚠ Bofrost.nl has degraded performance

In e238576, Bofrost.nl (https://www.bofrost.nl) experienced degraded performance:

HTTP code: 200
Response time: 864 ms

Resolved: Bofrost.nl performance has improved in c267340 after 6 minutes.


nmstatectl: do not require varlink as a dependecy

Varlink is only used for varlink support so it should not be imported
when doing other operations using nmstatectl.
File "/usr/lib/python3.6/site-packages/nmstatectl/nmstatectl.py", line 40, in <module>
  from nmstatectl.nmstate_varlink import start_varlink_server
File "/usr/lib/python3.6/site-packages/nmstatectl/nmstate_varlink.py", line 31, in <module>
  raise libnmError.NmstateDependencyError("python3 varlink module not found")
libnmstate.error.NmstateDependencyError: python3 varlink module not found

Signed-off-by: Fernando Fernandez Mancera<EMAIL_ADDRESS>

It would be nice to also have CI jobs that check whether the package is installable on all our target distributions. Since the container images include all the anticipated dependencies, it is not tested, there.

It would be nice to also have CI jobs that check whether the package is installable on all our target distributions. Since the container images include all the anticipated dependencies, it is not tested, there.

That sounds like a job of downstream packager's work.


ES5 generated output

Is there a way to generate ES5 output? IE11 reports syntax errors on ES6 code that client bundler generates at the moment (arrow functions etc...).
meteor-client.config.json
  "release": "<IP_ADDRESS>",
  "runtime": {
        "DDP_DEFAULT_CONNECTION_URL": "http://localhost:3000"
  },
  "generateNodeModules": true,
  "import": [
    "meteor-base",
    "mongo",
    "reactive-var",
    "tracker",

    "standard-minifier-css",
    "standard-minifier-js",
    "ecmascript",
    "es5-shim",
    "shell-server",

    "accounts-password",
    "alanning:roles",
    "session",

    "jalik:ufs",
    "jalik:ufs-gridfs",
    "jalik:ufs-local",

    "konecty:mongo-counter",
    "mdg:validated-method",
    "aldeed:simple-schema",
    "themeteorchef:bert",
    "pfafman:filesaver",
    "tap:i18n",
    "jag:pince",

<EMAIL_ADDRESS>    "underscore"
  ],
  "npmPackages": [

  ]
}

I guess we should transpile the generated bundle file with webpack using babel-loader for example. Are there any recomendations for loader options?

You can add arch field to bundler config with config web.browser.legacy.

Thanks @ardatan that's the solution I was looking for.


Fix a few typos in API/Office.IRibbonUI

Fix a few typos in API/Office.IRibbonUI.

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

api/Office.IRibbonUI.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


kctrl: export section in pkg build should have an option to get package bundle content as release.yml also.

Describe the problem/challenge you have
kctrl: export section in pkg build should have the option to get package bundle content as release.yml also. This way, while doing kctrl package release, users can get release.yml as output as well along with package.yml.
Describe the solution you'd like
[A clear and concise description of what you want to happen. If applicable a visual representation of the UX.]
Anything else you would like to add:
[Additional information that will assist in solving the issue.]

Vote on this request
This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.
👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"
We are also happy to receive and review Pull Requests if you want to help working on this issue.

This would not be possible in all cases.
For instance, the case we see in #1028. This won't be possible unless all values have defaults or a set of values is passed to the stage itself.


Failed to source jukit.vim: can't open file /helpers/.encodings for writing: no such file or directory

Hi, this happens on startup:
Failed to source `C:/Users/vaqxai/AppData/Local/nvim-data/lazy/vim-jukit/plugin/jukit.vim`

vim/_editor.lua:341: C:/Users/vaqxai/AppData/Local/nvim/init.lua..nvim_exec2() called at C:/Users/vaqxai/AppData/Local/nvim/init.lua:0..C:/Users/vaqxai
/AppData/Local/nvim-data/lazy/vim-jukit/plugin/jukit.vim, line 173: Vim(call):E482: Can't open file /helpers/.encodings for writing: no such file or directory

# stacktrace:
  - vim/_editor.lua:341 _in_ **cmd**
  - ~\AppData\Local\nvim\init.lua:21

Issue solved, it was the case of forgetting about shellslash, and using powershell instead of fish.


GEODE-7184: Add function executions timer

Add TimingFunction class which decorates a Function and adds execution timers.
Update InternalFunctionExecutionServiceImpl to decorate registered Functions in TimingFunctions. Internal functions (i.e. those that implement InternalEntity) are not decorated.
Co-authored-by: Aaron Lindsey<EMAIL_ADDRESS>Co-authored-by: Kirk Lund<EMAIL_ADDRESS>Co-authored-by: Dale Emery<EMAIL_ADDRESS>Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:

[x] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?

[x] Has your PR been rebased against the latest commit within the target branch (typically develop)?

[x] Is your initial contribution a single, squashed commit?

[x] Does gradlew build run cleanly?

[x] Have you written or updated unit tests to verify your changes?

Note:
Please ensure that once the PR is submitted, check Concourse for build issues and
submit an update to your PR as soon as possible. If you need help, please send an
email to<EMAIL_ADDRESS>

The following concerns/issues still need to be addressed for this PR:

With our changes, FunctionService.getFunction(String) will now return a TimingFunction instead of the function that that was passed to FunctionService.registerFunction(Function). This could be a problem for users if they are doing an explicit cast after getting the function, like (MyFunction) FunctionService.getFunction("MyFunction"). Is this a breaking change? I have a thread going on the dev list about this topic.
The PR is failing AnalyzeSerializablesJUnitTest.testSerializables because we added a new Serializable class, TimingFunction. We need to determine if this class can actually be serialized. If it cannot, we just need to add it to excludedClasses.txt and we're done. If it can be serialized, we need to consider the implications. One possible way to avoid backwards compatibility issues would be to override the serialization behavior to replace the serialized form of TimingFunction with that of its inner function. After considering the implications, adding the class to sanctioned-geode-core-serializables.txt will fix the failing test.
Many D-unit tests are failing due to ClassCastException and AssertionError being thrown because we are now returning TimingFunction instead of the function that was passed to FunctionService.registerFunction(Function). We verified that these exceptions are all thrown from test code and not product code. We need to update the test code to expect an instance of TimingFunction and know how to get the inner function from the TimingFunction.

Closing to re-work the solution to address the issues above.


OneDrive files repeatedly uploading

Certain files are being uploaded every time I run a copy. The logs provided are incomplete but provided to show the repeat upload over two runs.

What is your rclone version (eg output from rclone -V)
rclone v1.36-222-gf3c7e1a9β
Which OS you are using and how many bits (eg Windows 7, 64 bit)
Ubuntu 17.04
Which cloud storage system are you using? (eg Google Drive)
OneDrive
The command you were trying to run (eg rclone copy /tmp remote:tmp)
rclone copy /mnt/data0/photos onedrive:Pictures
A log from the command with the -vv flag (eg output from rclone -vv copy /tmp remote:tmp)

Upload 1
2017/06/30 16:29:06 INFO  : 2015/2015-12/IMG_5837.jpg: Copied (new)

Upload 2
2017/06/30 16:30:29 INFO  : 2015/2015-12/IMG_5837.jpg: Copied (new)

Possibly related to #1506.
Any chance you could put a complete log with -vv somewhere?

With pleasure. I have truncated the upload to one folder.
http://termbin.com/1xww

As a test I have renamed the target folder and I am re-running. Early indications suggest that it is working as when I stop the process and restart, the existing files are correctly skipped.

OK - more clues. I have just ls the directory locally and there are duplicates where some have .jpg and some .JPG
I am also getting these errors.
2017/06/30 18:08:51 ERROR : IMG_5838.jpg: Failed to copy: resourceModified: ETag does not match current item's value
2017/06/30 18:08:51 INFO  : IMG_5838.JPG: Copied (new)
2017/06/30 18:08:51 INFO  : IMG_5839.JPG: Copied (new)
2017/06/30 18:08:51 ERROR : IMG_5839.jpg: Failed to copy: resourceModified: ETag does not match current item's value
2017/06/30 18:08:53 INFO  : IMG_5840.JPG: Copied (new)
2017/06/30 18:08:54 INFO  : IMG_5840.jpg: Copied (new)
2017/06/30 18:08:55 INFO  : IMG_5841.JPG: Copied (new)
2017/06/30 18:08:56 INFO  : IMG_5841.jpg: Copied (new)
2017/06/30 18:08:57 INFO  : IMG_5843.jpg: Copied (new)
2017/06/30 18:08:57 INFO  : IMG_5843.JPG: Copied (new)
2017/06/30 18:08:57 ERROR : IMG_5842.JPG: Failed to copy: nameAlreadyExists: An item with the same name already exists under the parent
2017/06/30 18:08:58 ERROR : IMG_5844.jpg: Failed to copy: nameAlreadyExists: An item with the same name already exists under the parent

My guess is that OneDrive sees them as the same through the API? They both upload but only one version can be seen through the webclient.

Ah that makes sense.
onedrive is case insensitive, which means you can only have one of "file.jpg" and "file.JPG".
So when rclone syncs, it will continually replace the files.  You can see it doing it in your log
$ grep -i IMG_5746.jpg 1xww
2017/06/30 17:36:27 DEBUG : IMG_5746.JPG: Size and modification time the same (differ by -336.28768ms, within tolerance 1s)
2017/06/30 17:36:27 DEBUG : IMG_5746.JPG: Unchanged skipping
2017/06/30 17:36:30 INFO  : IMG_5746.jpg: Copied (new)

Unfortunately there isn't a solution to this other than to rename your files so they are all different even when made lowercase.
rclone should do a better job warning about this


telemetry modal needs design changes

#Rancher versions: master 2.0 8/1
Steps to Reproduce:

Open rancher
In console l('service:modal').toggleModal('modal-welcome'); to get modal to come up

Results:

[x] Image doesn't take up whole modal so it looks like it has a white border.
[x] The text is hard to read in both the grey section and the Learn More.
[x] Cloud image is on the very bottom by the Got It button.  Seems strange the cloud is not up higher?
[x] Allow collection of stats text is bold?

Redesigning welcome modal.  SO closing this.


Add build Parcel command to fix the build issue

Parcel default build command breaks our app due to folder structure of our resources such as JS, CSS an Vue resources. This script will add files in same folder so their are no issues.

Can you be more specific about the problem you are fixing?  Which files were not able to be found by the build process?
Just want to make sure there's not a bigger issue we are covering over.
I haven't had any issues on my side while running the command as specified in the readme:  parcel client/index.html


Envoy integration stopped working at April 12th [BUG]

Describe the bug
Envoy doesn't report solar panel power production since April 12th. The sensors are unavailable: Integration seems to be not working.
Account type

[ ] Installer
[ ] DIY / DHZ
[x] Home Owner (This integration is not (fully) functional with a home owner account!)

Envoy
<I don't know: how to determine this?>

[ ] Metered with CTs installed

[ ] Metered without CTs

[ ] Standard

FW version: 7.6.175

Amount of micro inverters connected: 16

Home Assistant

Core: 2024.4.3
Supervisor: 2024.04.0
Operating System: 12.2
Frontend: 20240404.2

Additional context
Sensors are not available:

Relevant snippet of Home Assistant error log:
2024-04-12 13:51:20.585 ERROR (MainThread) [homeassistant.config_entries] Error setting up entry Envoy<PHONE_NUMBER>05 for enphase_envoy
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 551, in async_setup
result = await component.async_setup_entry(hass, self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/enphase_envoy/init.py", line 78, in async_setup_entry
enlighten_serial_num=config[CONF_SERIAL],
KeyError: 'serial'

...

2024-04-15 08:17:39.501 ERROR (MainThread) [homeassistant.config_entries] Error setting up entry Envoy<PHONE_NUMBER>05 for enphase_envoy
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 551, in async_setup
result = await component.async_setup_entry(hass, self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/enphase_envoy/__init__.py", line 78, in async_setup_entry
enlighten_serial_num=config[CONF_SERIAL],
~~~~~~^^^^^^^^^^^^^
KeyError: 'serial'

That worked, thanks!
Nothing changed on the Envoy.
I usually perform updates when HA provides an update: I don't remember if I updated exactly that day/time.
Around that time I installed Nordpool day-ahead-prices according to smart-home-junkie's video.


What's different between Async and the other?

one thing is not clear for me. Whats different between async-mqtt-client library and pubsubclient.h library in mqtt exactly? also for asyncwebserver and webserver?
what is advantages and disadvantages of asynchronous in compared of synchronous in esp8266?

I am not an expert either, but think threads (it's not, actually, just a picture). A synchronous implementation runs in the main loop. So for example, to connect to a TCP socket, if it takes 3 seconds, the whole code would block for 3 seconds. An asynchronous implementation does not run in the main loop. When you will connect to the TCP socket, it will work in the background and call your code back (callback) when it's done. So it's not blocking, you can do whatever you want in between! Simply put, the advantage here it is faster and more bulletproof. You can easily crash PubSubClient under high load, nobody managed to break AsyncMqttClient yet. :wink:


fix(deps): update all non-major

This PR contains the following updates:

Package
Type
Update
Change

anyhow
dependencies
patch
1.0.74 -> 1.0.75

mongodb (source)
dependencies
patch
2.6.0 -> 2.6.1

serde (source)
dependencies
patch
1.0.183 -> 1.0.185

serde_json
dependencies
patch
1.0.104 -> 1.0.105

thiserror
dependencies
patch
1.0.46 -> 1.0.47

tokio (source)
dependencies
minor
1.31.0 -> 1.32.0

tokio (source)
dev-dependencies
minor
1.31.0 -> 1.32.0

Release Notes

dtolnay/anyhow (anyhow)
v1.0.75
Compare Source

Partially work around rust-analyzer bug (https://github.com/rust-lang/rust-analyzer/issues/9911)

mongodb/mongo-rust-driver (mongodb)
v2.6.1
Compare Source
The MongoDB Rust driver team is pleased to announce the v2.6.1 release of the mongodb crate, now available for download from crates.io. This release removes a potential panic from the SessionCursor::with_type method.
Included Changes
Bugfixes

RUST-1719 Fix panic after SessionCursor::with_type is called (#928) (thank you @mlokr for this fix!)

serde-rs/serde (serde)
v1.0.185
Compare Source

Fix error "cannot move out of *self which is behind a shared reference" deriving Serialize on a non_exhaustive enum (#2591)

v1.0.184
Compare Source

Restore from-source serde_derive build on all platforms — eventually we'd like to use a first-class precompiled macro if such a thing becomes supported by cargo / crates.io

serde-rs/json (serde_json)
v1.0.105
Compare Source

Support bool in map keys (#1054)

dtolnay/thiserror (thiserror)
v1.0.47
Compare Source

Work around rust-analyzer bug (https://github.com/rust-lang/rust-analyzer/issues/9911)

tokio-rs/tokio (tokio)
v1.32.0: Tokio v1.32.0
Compare Source
Fixed

sync: fix potential quadradic behavior in broadcast::Receiver (#5925)

Added

process: stabilize Command::raw_arg (#5930)
io: enable awaiting error readiness (#5781)

Unstable

rt(alt): improve the scalability of alt runtime as the number of cores grows (#5935)

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

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

This PR has been generated by Renovate Bot.

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

GitHub release
v0.6.2

Your semantic-release bot :package::rocket:


Fix WebXR after changing Emscripten configuration noExitRuntime to false

In #68292, the Emscripten configuration noExitRuntime was changed to false - this has broken entering VR/AR with WebXR! As soon as the browser enters WebXR mode, Godot will exit uncleanly.
This PR fixes that :-)

Thanks!


feat(store-api): Add support for VTEX platform

What's the purpose of this pull request?
This PR adds support for the vtex platform on store-api. This is just a POC of how we can do it, and many other PRs are required to actually put it into production, like logs collecting, metrics, caching etc.
This is really just a first simple iteration that we can improve on later on.
How it works?
Store api exports one single getSchema function. This function returns a schema for a given platform, configured according to its options.

Maybe I'm overthinking all this, but should the platforms be inside store-api? I know it's a natural way to think of it, but I don't like the dependency it puts on us to add new providers.
People prototyping with our platform would have to fork store-api, make their own implementation, link packages to the stores they're prototyping using yarn.
For me, that's a bad developer experience when compared to NextJS, where you have to fork everything, yes, but you can do it all in one place, and move things around as you wish, add new platforms to your stores as you wish, without ever depending on them to approve a PR or anything else.
And even if we take the time to review, approve and merge this new platform, we would have to maintain it, probably without much knowledge of how to do so, making things possibly break or leaving them outdated.
What I think I'm proposing (I'm still thinking about it) is that we have an approach similar to the themes on store-ui: you can use our default platform implementations, but you can just create your own repo and npm package to manage your own platform if you want. I think this gives power to the community and mitigates some of the issues I mentioned above.
store-api would just be a shell, a guide on how to implement an API with the correct types. The getSchema function would be something like:
import { getSchema } from '@vtex/store-api'
import { vtex } from '@vtex/store-api-vtex'

const schema = await getSchema(vtex, { account: 'my-account', environment: 'vtexcommercestable' })

We could also have a mono-repo for officially supported providers, that's also a possibility. I just want opinions on this, I'm not sure I'm making sense lol.

Take a look at the README's extension model. On this readme I show how you can not only extend the resolvers in your frontend project, but also redefine the whole resolvers implementation. Also, you can import the typeDefs and define the resolvers locally, supporting different platforms/use cases


Slow hashing of DateTimes, especially ZonedDateTimes

I noticed that one of my data tables was taking forever to hash. I did some profiling and all the time was in stable_hash_helper and hash_foreach (I was using the vscode profiler though, so I don't have the specific methods that were being called).
Here's the code that reproduces the issue:
using CleanSleepUtils
using Dollars
using StableHashTraits

arousals = CleanSleepUtils.load_arousals()
@time stable_hash(arousals[1:100, :])

On my pet this is taking 0.2s for just 100 rows.
I ran it in Cthulhu.jl and it looks like there's a type instability in hash_foreach
You can see the output here:

So when you call f_x = fn(x) the return type is only inferred as Pair{Symbol}, which is abstract. Honestly I'm not sure what Pair{Symbol} means, given that Pair usually has 2 type parameters.
I wonder if the combination of calling a passed-in function on a symbol is too much for the compiler to follow. I think it would have to rely on constant propagation to do the field lookup in a type-stable way (it needs to know the symbol), and maybe it can only do that for simpler constructions like an explicit getfield.

Pair{Symbol} is Pair{Symbol, T} where {T}

Mmm... 🤔 , it's not obvious to me that the type instability here is the problem. Are you sure this is the method of hash_foreach that is the issue when profiling?
From what I can tell, there is a type instability when iterating over columns. This makes sense since the array of columns is inherently type unstable, since they have varying eltypes. I would have assumed that most of the time should be in the hash_foreach method that occurs within the column. It seems more of an issue if the per-column hash_foreach were type unstable, but it occurs after a function barrier so I would have guessed that it is type stable.

Have you profiled it for larger DataFrames? It could be that the real bottleneck wouldn't show up without more rows, because of what I'm describing above.

I split out the hashing for each column:
julia> times = DataFrame(column=names(a), type=[eltype(a[!, n]) for n in names(a)], dur=map((n->@elapsed stable_hash(a[1:500, n])), names(a)))
17×3 DataFrame
 Row │ column                  type                               dur
     │ String                  Type                               Float64
─────┼───────────────────────────────────────────────────────────────────────
   1 │ recording               UUID                               0.021891
   2 │ id                      UUID                               0.0217685
   3 │ span                    TimeSpan                           0.0771413
   4 │ display_icon_shortcode  Union{Missing, String}             0.00757008
   5 │ author_person           Union{Missing, UUID}               0.00758817
   6 │ author_process          Union{Missing, UUID}               0.0217512
   7 │ channels                Union{Missing, SubArray{String, …  0.00758956
   8 │ inserted_at             ZonedDateTime                      0.36969
   9 │ inserted_by             Union{Missing, UUID}               0.0220694
  10 │ last_updated_at         ZonedDateTime                      0.372024
  11 │ last_updated_by         Union{Missing, UUID}               0.0219271
  12 │ display_name            Union{Missing, String}             0.00756155
  13 │ rule                    Union{Missing, String}             0.00398748
  14 │ signal                  Union{Missing, String}             0.0039855
  15 │ cause                   Union{Missing, String}             0.00754496
  16 │ source_name             Union{Missing, String}             0.00397673
  17 │ source_id               UUID                               0.0217547

julia> barplot(times.column, times.dur)
                          ┌                                        ┐
                recording ┤■■ 0.021891
                       id ┤■■ 0.0217685
                     span ┤■■■■■■ 0.0771413
   display_icon_shortcode ┤■ 0.00757008
            author_person ┤■ 0.00758817
           author_process ┤■■ 0.0217512
                 channels ┤■ 0.00758956
              inserted_at ┤■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ 0.36969
              inserted_by ┤■■ 0.0220694
          last_updated_at ┤■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ 0.372024
          last_updated_by ┤■■ 0.0219271
             display_name ┤■ 0.00756155
                     rule ┤ 0.00398748
                   signal ┤ 0.0039855
                    cause ┤■ 0.00754496
              source_name ┤ 0.00397673
                source_id ┤■■ 0.0217547

So ZonedDateTime is definitely a problem!
I think there are two things going on here. One is that ZonedDateTime has a timezone::TimeZone field (which is abstract, but that's not the biggest problem right now). One common subtype is a VariableTimeZone, which is actually a pretty big object that contains a whole list of all the transitions (I'm guessing daylight savings, leap seconds maybe). Usually if there are multiple ZonedDateTimes with the same time zone, it is shared between them so it's not actually taking up all that memory.
You can probably see the problem though, which is that when we compute a hash, we iterate through that transitions table every time we hash a ZonedDateTime. One solution is to define a hash_method for VariableTimeZone that just hashes the name, under the assumption that there won't be multiple different time zones with the same name.
To save space I'm cut out the first runs of each function call that triggers compilation.
julia> zdt = [ZonedDateTime(2000, tz"Europe/Paris") for _ in 1:100];

julia> dts = [DateTime(2000) for _ in 1:100];

julia> @time stable_hash(dts);
  0.007940 seconds (50.91 k allocations: 3.585 MiB)

julia> @time stable_hash(zdts);
  1.914683 seconds (31.52 M allocations: 2.109 GiB, 2.62% gc time)

julia> StableHashTraits.hash_method(tz::VariableTimeZone) = (FnHash(qualified_name), FnHash(tz->tz.name));

julia> @time stable_hash(zdts);
  0.019814 seconds (187.31 k allocations: 12.840 MiB)

So that's a huge speedup, and I was feeling pretty good about myself at this point. Unfortunately, for reasonably-large tables this is still far too slow. To calibrate an upper bound to how fast hashing should be, I looked at a vector of integers
using BenchmarkTools

julia> is = collect(1:100);

julia> is_elapsed = @belapsed stable_hash(is)
4.6833e-5

julia> dts_elapsed = @belapsed stable_hash(dts)
0.003659833

julia> zdts_elapsed = @belapsed stable_hash(zdts)
0.011046416

julia> dts_elapsed/is_elapsed
78.14645655840967

julia> zdts_elapsed/is_elapsed
235.86821258514297

So a regular DateTime is 70x slower than an integer, and a ZonedDateTime is 235x slower. And what is a DateTime under the hood?
julia> dump(DateTime(2000))
DateTime
  instant: Dates.UTInstant{Dates.Millisecond}
    periods: Dates.Millisecond
      value: Int64<PHONE_NUMBER>0000

It's an integer.
I've got to wrap up for right now, but I suspect that either

the getfield struct machinery isn't as type-stable as we thought
When I was looking at some profiling results today I definitely saw a lot of qualified name lookup, so that might be more expensive than we thought.

If #1 is the problem, we may need to look into a @generated function to unroll the field lookup.
If #2 is the problem, we need to figure out a cheaper mechanism to disambiguate wrapper types.
Zooming out a bit, also perhaps we just shouldn't be hashing these tables with complicated Julia types in them, and we can hash the underlying Arrow data structures instead.

You can probably see the problem though, which is that when we compute a hash, we iterate through that transitions table every time we hash a ZonedDateTime. One solution is to define a hash_method for VariableTimeZone that just hashes the name, under the assumption that there won't be multiple different time zones with the same name.

The Base.hash(::VariableTimeZone) does exactly this. I need to consider the use cases for stable_hash to know if we should mirror that exact behaviour.

I think a risk/danger of the more generic approach is that it will sometimes be hard to be faster than a specialized method. It seems pretty trivial to make a faster method for this particular type, so maybe that is the right approach here?
I have been thinking that an IdDict should be used per call to stable_hash to avoid recomputing hashes for the same object (maybe with LRU limits). (Since objects can change and have the same id it wouldn't make sense to save across calls). That might address the time zone issue you're seeing.
It is possible a similar approach would help for the type qualifiers, but that seems worth examining in more detail to know if it's the computing of the qualified name itself or the hashing of the name that is the issue (or neither). If it is a problem it seems like a bigger deal, since that is littered all over the current design.

I've been experimenting with benchmarking / optimizing StableHashTraits. You can find a fast branch of the repo at dfl/optimize-1. The TL;DR is that compared to a raw call to e.g. sha256 speeds were ~100-1000x as slow with stable_hash before this branch and ~1-10x as slow after this branch.
I'm breaking that up into a series of smaller more digestible PRs.
You can find the first, which simply establishes benchmarks for some basic cases in #28

#29 is a follow-up PR, containing some initial optimizations

The final outstanding performance issue should be addressed by #55

Turns out this is no longer an issue in 1.3  / 2.0 of StableHashTraits. The use of StructTypes means that ZonedDateTimes get printed to a canonical string format, avoiding this problem.


x/tools/gopls: TestMissingPatternDiagnostic flake

This failure was observed once in patchset 1 of https://go.dev/cl/470678. I believe it is unrelated to that change; a second run of the CI passed.
See https://storage.googleapis.com/go-build-log/612c00bf/linux-arm64_9feab390.log
serve.go:434: debug server listening at http://localhost:45007
serve.go:434: debug server listening at http://localhost:45505
#### Start Gopls Test Logs for "TestMissingPatternDiagnostic/default"
[Trace - 18:53:26.444 PM] Sending request 'initialize - (1)'.
Params: {"processId":0,"clientInfo":{"name":"fakeclient","version":"v1.0.0"},"rootUri":"","capabilities":{"workspace":{"workspaceEdit":{"resourceOperations":["rename"]},"didChangeConfiguration":{},"didChangeWatchedFiles":{"dynamicRegistration":true},"configuration":true},"textDocument":{"completion":{"completionItem":{"snippetSupport":true,"commitCharactersSupport":false,"documentationFormat":null,"deprecatedSupport":false,"preselectSupport":false,"tagSupport":{"valueSet":[1]},"insertReplaceSupport":false,"resolveSupport":{"properties":null},"insertTextModeSupport":{"valueSet":null},"labelDetailsSupport":false}},"hover":{},"documentSymbol":{},"codeAction":{"codeActionLiteralSupport":{"codeActionKind":{"valueSet":null}}},"rename":{},"foldingRange":{},"publishDiagnostics":{},"semanticTokens":{"requests":{"range":false,"full":true},"tokenTypes":["namespace","type","class","enum","interface","struct","typeParameter","parameter","variable","property","enumMember","event","function","method","macro","keyword","modifier","comment","string","number","regexp","operator"],"tokenModifiers":["declaration","definition","readonly","static","deprecated","abstract","async","modification","documentation","defaultLibrary"],"formats":null}},"window":{"workDoneProgress":true}},"initializationOptions":{"completionBudget":"10s","diagnosticsDelay":"10ms","env":{"GO111MODULE":"","GOMODCACHE":"","GOPACKAGESDRIVER":"off","GOPATH":"/tmp/workdir/tmp/gopls-regtest-3372056961/TestMissingPatternDiagnostic/default/gopath","GOPROXY":"file:///tmp/workdir/tmp/gopls-regtest-3372056961/TestMissingPatternDiagnostic/default/proxy","GOSUMDB":"off"},"verboseWorkDoneProgress":true},"trace":"messages","workspaceFolders":[{"uri":"file:///tmp/workdir/tmp/gopls-regtest-3372056961/TestMissingPatternDiagnostic/default/work","name":"work"}]}

[Trace - 18:53:26.444 PM] Received response 'initialize - (1)' in 0ms.
Result: {"capabilities":{"textDocumentSync":{"openClose":true,"change":2,"save":{}},"completionProvider":{"triggerCharacters":["."]},"hoverProvider":true,"signatureHelpProvider":{"triggerCharacters":["(",","]},"definitionProvider":true,"typeDefinitionProvider":true,"implementationProvider":true,"referencesProvider":true,"documentHighlightProvider":true,"documentSymbolProvider":true,"codeActionProvider":true,"codeLensProvider":{},"documentLinkProvider":{},"workspaceSymbolProvider":true,"documentFormattingProvider":true,"renameProvider":true,"foldingRangeProvider":true,"selectionRangeProvider":{"documentSelector":null},"executeCommandProvider":{"commands":["gopls.add_dependency","gopls.add_import","gopls.apply_fix","gopls.check_upgrades","gopls.edit_go_directive","gopls.fetch_vulncheck_result","gopls.gc_details","gopls.generate","gopls.go_get_package","gopls.list_imports","gopls.list_known_packages","gopls.regenerate_cgo","gopls.remove_dependency","gopls.reset_go_mod_diagnostics","gopls.run_govulncheck","gopls.run_tests","gopls.start_debugging","gopls.test","gopls.tidy","gopls.toggle_gc_details","gopls.update_go_sum","gopls.upgrade_dependency","gopls.vendor"]},"callHierarchyProvider":true,"semanticTokensProvider":{"legend":{"tokenTypes":["namespace","type","class","enum","interface","struct","typeParameter","parameter","variable","property","enumMember","event","function","method","macro","keyword","modifier","comment","string","number","regexp","operator"],"tokenModifiers":["declaration","definition","readonly","static","deprecated","abstract","async","modification","documentation","defaultLibrary"]},"range":true,"full":true},"inlayHintProvider":{},"workspace":{"workspaceFolders":{"supported":true,"changeNotifications":"workspace/didChangeWorkspaceFolders"},"fileOperations":{}}},"serverInfo":{"name":"gopls","version":"{\"GoVersion\":\"devel 612c00bf4d440160e87e983bd8300ad7b08a6ada\",\"Path\":\"\",\"Main\":{\"Path\":\"\",\"Version\":\"\",\"Sum\":\"\",\"Replace\":null},\"Deps\":null,\"Settings\":null,\"Version\":\"master\"}"}}

[Trace - 18:53:26.444 PM] Sending notification 'initialized'.
Params: {}

[Trace - 18:53:26.444 PM] Received request 'window/workDoneProgress/create - (1)'.
Params: {"token":"6332216880235428519"}

[Trace - 18:53:26.445 PM] Sending response 'window/workDoneProgress/create - (1)' in 0ms.
Result:

[Trace - 18:53:26.445 PM] Received notification '$/progress'.
Params: {"token":"6332216880235428519","value":{"kind":"begin","title":"diagnosing initial workspace load","message":"Calculating diagnostics for initial workspace load..."}}

[Trace - 18:53:26.445 PM] Received request 'window/workDoneProgress/create - (2)'.
Params: {"token":"9006790614455439682"}

[Trace - 18:53:26.445 PM] Sending response 'window/workDoneProgress/create - (2)' in 0ms.
Result:

[Trace - 18:53:26.445 PM] Received notification '$/progress'.
Params: {"token":"9006790614455439682","value":{"kind":"begin","title":"Setting up workspace","message":"Loading packages..."}}

[Trace - 18:53:26.445 PM] Received request 'workspace/configuration - (3)'.
Params: {"items":[{"scopeUri":"file:///tmp/workdir/tmp/gopls-regtest-3372056961/TestMissingPatternDiagnostic/default/work","section":"gopls"}]}

[Trace - 18:53:26.445 PM] Sending response 'workspace/configuration - (3)' in 0ms.
Result: [{"completionBudget":"10s","diagnosticsDelay":"10ms","env":{"GO111MODULE":"","GOMODCACHE":"","GOPACKAGESDRIVER":"off","GOPATH":"/tmp/workdir/tmp/gopls-regtest-3372056961/TestMissingPatternDiagnostic/default/gopath","GOPROXY":"file:///tmp/workdir/tmp/gopls-regtest-3372056961/TestMissingPatternDiagnostic/default/proxy","GOSUMDB":"off"},"verboseWorkDoneProgress":true}]

[Trace - 18:53:26.457 PM] Received notification 'window/logMessage'.
Params: {"type":3,"message":"2023/02/23 18:53:26 go info for /tmp/workdir/tmp/gopls-regtest-3372056961/TestMissingPatternDiagnostic/default/work\n(go dir /tmp/workdir/tmp/gopls-regtest-3372056961/TestMissingPatternDiagnostic/default/work)\n(go version go version devel 612c00bf4d440160e87e983bd8300ad7b08a6ada linux/arm64)\n(valid build configuration = true)\n(build flags: [])\n(selected go env: [GO111MODULE=, GOCACHE=/tmp/workdir/gocache, GOFLAGS=, GOMODCACHE=/tmp/workdir/tmp/gopls-regtest-3372056961/TestMissingPatternDiagnostic/default/gopath/pkg/mod, GOPATH=/tmp/workdir/tmp/gopls-regtest-3372056961/TestMissingPatternDiagnostic/default/gopath, GOPRIVATE=, GOROOT=/tmp/workdir/go, GOWORK=])\n\n"}

[Trace - 18:53:26.525 PM] Received notification 'window/logMessage'.
Params: {"type":3,"message":"2023/02/23 18:53:26 go/packages.Load #20\n\tsnapshot=0\n\tdirectory=file:///tmp/workdir/tmp/gopls-regtest-3372056961/TestMissingPatternDiagnostic/default/work\n\tquery=[builtin example.com/...]\n\tpackages=2\n"}

[Trace - 18:53:26.525 PM] Received notification 'window/logMessage'.
Params: {"type":3,"message":"2023/02/23 18:53:26 go/packages.Load #20: updating metadata for 31 packages\n"}

[Trace - 18:53:26.547 PM] Received notification '$/progress'.
Params: {"token":"9006790614455439682","value":{"kind":"end","message":"Finished loading packages."}}

[Trace - 18:53:26.547 PM] Received request 'client/registerCapability - (4)'.
Params: {"registrations":[{"id":"workspace/didChangeWatchedFiles-0","method":"workspace/didChangeWatchedFiles","registerOptions":{"watchers":[{"globPattern":"**/*.{go,mod,sum,work}","kind":7}]}}]}

[Trace - 18:53:26.547 PM] Sending response 'client/registerCapability - (4)' in 0ms.
Result:

[Trace - 18:53:26.596 PM] Received notification '$/progress'.
Params: {"token":"6332216880235428519","value":{"kind":"end","message":"Done."}}

[Trace - 18:53:26.596 PM] Sending notification 'textDocument/didOpen'.
Params: {"textDocument":{"uri":"file:///tmp/workdir/tmp/gopls-regtest-3372056961/TestMissingPatternDiagnostic/default/work/x.go","languageId":"go","version":1,"text":"package x\n\nimport (\n\t_ \"embed\"\n)\n\n// Issue 47436\nfunc F() {}\n\n//go:embed NONEXISTENT\nvar foo string\n"}}

[Trace - 18:53:26.596 PM] Received request 'window/workDoneProgress/create - (5)'.
Params: {"token":"2868681718438842721"}

[Trace - 18:53:26.596 PM] Sending response 'window/workDoneProgress/create - (5)' in 0ms.
Result:

[Trace - 18:53:26.596 PM] Received notification '$/progress'.
Params: {"token":"2868681718438842721","value":{"kind":"begin","title":"diagnosing opened files","message":"Calculating file diagnostics..."}}

[Trace - 18:53:26.609 PM] Received notification 'textDocument/publishDiagnostics'.
Params: {"uri":"file:///tmp/workdir/tmp/gopls-regtest-3372056961/TestMissingPatternDiagnostic/default/work/x.go","version":1,"diagnostics":[]}

[Trace - 18:53:26.663 PM] Received notification '$/progress'.
Params: {"token":"2868681718438842721","value":{"kind":"end","message":"Done."}}

#### End Gopls Test Logs for "TestMissingPatternDiagnostic/default"
--- FAIL: TestMissingPatternDiagnostic (0.22s)
    --- FAIL: TestMissingPatternDiagnostic/default (0.22s)
        env.go:322: waiting on:
            Unmeetable: once "All of:\ncompleted work \"diagnosing opened files\" at least 1 time(s)" is met, must have:
            any diagnostics at the first position matching `NONEXISTENT` in "x.go", with message containing "no matching files found"

            err:condition has final verdict Unmeetable

            state:
            #### log messages (see RPC logs for full text):
            	Info: "2023/02/23 18:53:26 go info for /tmp/workdir/tmp/g...
            	Info: "2023/02/23 18:53:26 go/packages.Load #20\n\tsnapsh...
            	Info: "2023/02/23 18:53:26 go/packages.Load #20: updating...

            #### diagnostics:
            	x.go (version 1):

            #### outstanding work:
            #### completed work:
            	diagnosing opened files: 1
            	diagnosing initial workspace load: 1
            	Setting up workspace: 1

FAIL
FAIL	golang.org/x/tools/gopls/internal/regtest/misc	24.750s

This was cause by the failing patchset not having https://go.dev/cl/470157.
(such version skew problems are frequently a problem in x/tools, but unfortunately it is not easy to solve the problem; we must get used to rebasing frequently)


Add container persistence for DNX packages

Similar to how we persist Python's Pip cache between container runs, the DNX package cache could also be persisted. That path is normally ~/.dnx/packages

Is this still relevant? I don't think we have that anymore


Loading permissions for workflow transition using AbstractLoadAclData fails

Trying to load a permission like workflow:workflow_name::transition_name|step_1|step_2
fails, at line 94 $oid = $aclManager->getOid(str_replace('|', ':', $permission));
The WorkflowTransitionAclExtension throws LogicException as getObjectIdentity method is not supported.
How to load wrokflow transition permissions ? Using the WorkflowTransitionMaskBuilder and setting the permission through AclManager ? In that case what should be oid ?

Hi @dimonixx
Unfortunately, for now, its not clear that exactly you are trying to do.
The described error message is, unfortunately, not enough to understand what is wrong.
Please explain the problem you are trying to solve in more details.
Or provide us a code example.

I'm trying to save a permission for Transition workflow:workflow_name::transition_name|step_1|step_2.
Using this class Oro\Bundle\SecurityBundle\Migrations\Data\ORM\AbstractLoadAclData in the same way as hier Oro\Bundle\UserBundle\Migrations\Data\ORM\AddProfileAndConfigUpdateCabalitiesToRole.
protected function getAclData()
    {
        return [
            self::ALL_ROLES => [
                'permissions' => [
                    'workflow:workflow_name::transition_name|step_1|step_2'  =>['PERFORM_TRANSITION']
                ],
            ],
        ];
    }

Hi @dimonixx
have looked in yours example,
so, you need to override the method 'processPermission' a bit
to get the OID you need the part of permission string before '::', e.g. 'workflow:workflow_name'
and instead of '$aclManager->setPermission' you need to use '$aclManager->setFieldPermission'
so, the quick example will look like this:
<?php

namespace Oro\Bundle\UserBundle\Migrations\Data\ORM;

use Symfony\Component\Security\Acl\Model\SecurityIdentityInterface;

use Oro\Bundle\SecurityBundle\Acl\Persistence\AclManager;
use Oro\Bundle\SecurityBundle\Migrations\Data\ORM\AbstractLoadAclData;

class Test extends AbstractLoadAclData
{
    /**
     * {@inheritdoc}
     */
    public function getDataPath()
    {
        return '';
    }

    /**
     * {@inheritdoc}
     */
    protected function getAclData()
    {
        return [
            self::ALL_ROLES => [
                'permissions' => [
                    'workflow:task_flow::start_progress|open|in_progress' => ['PERFORM_TRANSITION_NONE'],
                ]
            ],
        ];
    }

    protected function processPermission(
        AclManager $aclManager,
        SecurityIdentityInterface $sid,
        $permission,
        array $acls
    ) {
        $permission = explode('::', $permission);
        //$oid = $aclManager->getOid(str_replace('|', ':', $permission));
        $oid = $aclManager->getOid($permission[0]);

        $extension = $aclManager->getExtensionSelector()->select($oid);
        $maskBuilders = $extension->getAllMaskBuilders();

        foreach ($maskBuilders as $maskBuilder) {
            $mask = $maskBuilder->reset()->get();

            if (!empty($acls)) {
                foreach ($acls as $acl) {
                    if ($maskBuilder->hasMask('MASK_' . $acl)) {
                        $mask = $maskBuilder->add($acl)->get();
                    }
                }
            }

            //$aclManager->setPermission($sid, $oid, $mask);
            $aclManager->setFieldPermission($sid, $oid, $permission[1], $mask);
        }
    }
}

Hi Alex,
I‘ve solved it the similar way.
Thank you.


docs(material/input): Fix cdkTextareaAutosize link

The link to the cdkTextareaAutosize directive in the "Auto-resizing  elements" section on the overview page links to that section on the same page, have changed it to correctly point to that section within the cdk/text-field overview page.

Thank you!


Update to C++ 17.

This modifies the code to be compatible with C++ 17.

@pmskintner, @galanCA is helping us update CSE and its dependencies to utilize more recent C++ features. Let us know if you have any questions on this.


Coalesce not working on SQLite

Laravel Version
v11.14.0
PHP Version
8.3.12
Database Driver & Version
SQLite on Herd for macOS 1.11.1
Description
The functions COALESCE and IFNULL do not work properly over SQLite databases.
The raw SQL query provided by $builder->ddRawSQL() is corectly parsed like the example below
select * from "products" where IFNULL(promotional_price, price) >= 100;
and it works just fine when ran directly against the DB.
For some reason it will return no results when the builder excecutes
Steps To Reproduce
Running a query like this one
$query->where(DB::raw('COALESCE(promotional_price, price)'), '>=', $priceFrom)
will return no results when using the sqlite driver but running the resulting raw query against the DB does work correctly
Using $query->whereRaw('COALESCE(promotional_price, price) >= ?',  [$priceFrom]) does not work either.
Also querying it as a column and then running the where clause like $query->selectRaw('COALESCE(promotional_price, price) as current_price') and then $query->where('current_price', '>=', $priceFrom) doesnt seem to work

works just fine when ran directly against the DB.

Which DB? (MySQL, MariaDB, Postgres, SQL Server?)
Also,

Is your SQLite database seeded?
Is there any output if you run the generated query directly to the SQLite database?

(e.g. from sqlite3 CLI, or using a GUI like DBeaver/Data Grip/PHPStorm/etc.?)

I just tried using cast() like cast(COALESCE(promotional_price, price) as float) and worked.
It does seem odd the need to cast since the values are already SQLites's numeric type

Make sure the data types of promotional_price and price columns are compatible. If one is a string and the other is a number, the comparison may fail.
In addition, for PHP 8.4, mariaDB or PSQL, you can deploy and manage them through servbay, which can prevent environment conflict bugs.


Feature/i2c slave

Implemented a blocking i2c_slave, and modified the i2c_master such that incorrect frame errors can be detected.
The master can cope with an ACK on the last received byte, but also with a NACK on the last received byte from the slave
Tests where the communication between master and slave is tested (good and bad cases) can be found here: https://github.com/smeenka/rust-examples

Can you check that comments in traits and methods are actually doc comments with ///, could you check also letter casings in there.

Looks great! 🦀
I will try to use this change on some of my i2c projects first, then I'm happy to merge this!

This is a blocking i2c implementation so I used the Result value. For function slave_wait_addressed
the nb:Result would be more appropriate (because non-blocking). Please discuss if this is wanted, than I will make a next pull request with this change
Also really want to move i2c into a directory, and this implementation is subdir blocking. Then split in several files (master, slave, lib, config etc) like is done for serial. For now this is a too big change. Please discuss if this is wanted
As soon i2c is in a dir I can start creating a non-blocking variant, based on callbacks and/or with all nb:result variant.

@smeenka feel free to move i2c into a directory, this is great idea!
Also it would be cool to have both implementation: blocking and non-blocking.
I tried this branch on some of my projects - works fine. 🦀

Note that the interfaces are found in i2c/mod.rs and the implementation in i2c/blocking.rs. In the application one has to use the i2c/blocking to include the implementation, See https://github.com/smeenka/rust-examples.

@smeenka lets fix code format issue and we good to merge this!

Fixed the formatting issue

Thank you!


Updated build.zig and .gitignore

Updated build.zig to work with Zig 0.13.0, and updated the .gitignore to properly ignore .zig-cache now.

Thank you @ciathefed!