Suggestion for chaotic system

Wow, awesome job with this! I'm going to add an example of using these datasets with some of the PySINDy repository's new functionality -- will update you on progress.
Also, you may be interested in adding the chaotic "atmospheric oscillator" from Tuwankotta, J. M. (2003). Widely separated frequencies in coupled oscillators with energy-preserving quadratic nonlinearity. Physica D: Nonlinear Phenomena, 182(1-2), 125-149. Our group also uses a simple version of this system in Kaptanoglu, A. A., Callaham, J. L., Aravkin, A., Hansen, C. J., & Brunton, S. L. (2021). Promoting global stability in data-driven models of quadratic nonlinear dynamics. Physical Review Fluids, 6(9), 094401.

Hey @akaptano , my apologies for the delay on this---the issue that I am running into is that to add new systems, I need to make sure that all of the different features are included (Lyapunov exponents, best timescale, precomputed trajectories). I also need to freeze a version for the benchmarks reported in the paper.
I'm currently working on automating most of this

Hey @akaptano this is now included in the GitHub version:
pip install git+git://github.com/williamgilpin/dysts

I included estimates of Lyapunov exponents and other metadata that the other systems have. It should work the same as other systems
from dysts.flows import AtmosphericRegime

eq = AtmosphericRegime()
sol = eq.make_trajectory(1000)
plt.plot(sol[:, 0], sol[:, 1])

Thanks for sharing the info and snippet---very interesting system with the two timescales

Agreed, thanks for implementing.


GHC-7.10.1 compatibility

Hi,
if Travis is not misleading me, then cassava has no version compatible with GHC-7.10.1 (which ships ghc-prim-0.4) due to ghc-prim (>=0.2 && <0.4).
Thanks,
Joachim

:+1: I need this too. I think every benchmark program that uses on Criterion is now broken because of this.

Btw, cassava probably doesn't need ghc-prim anymore for GHC >= 7.6 anyway...

FYI, building it without the ghc-prim dependency and relaxing blaze-builder to < 0.5 (instead of < 0.4) works for me (i.e. passes cabal config / cabal build / cabal test)

Fixed.


PR: Create Completions Plugin Statusbar Widget

Description of Changes
Created a statusbar widget for the completions plugin. This replaces the status bar widget for the MainInterpreter.

MainInterpreter plugin still handles all interpreter related manipulations, but simply does not display on the StatusBar
Completion plugin now has a status bar widget that displays the completion environment.
The interpreter-changed signal no longer routes through the MainWindow. Any services requiring it should access sig_interpreter_changed from the MainInterpreter plugin.

Issue(s) Resolved

Fixes spyder-ide/ux-improvements#38
Affirmation
By submitting this Pull Request or typing my (user)name below,
I affirm the Developer Certificate of Origin
with respect to all commits and content included in this PR,
and understand I am releasing the same under Spyder's MIT (Expat) license.

I certify the above statement is true and correct:
@mrclary

Hello @mrclary! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file spyder/utils/icon_manager.py:

Line 270:80: E501 line too long (97 > 79 characters)

@ccordoba12, I think this reflects what we discussed at our last meeting.
We can, of course, change any of the class/function names and update documentation as needed.

/show binder

/show binder

Sure thing! Since we're using (mostly) Material Design Icons now, I think mdi-close and mdi-check seem like good options for the simple options.

Okay, @isabela-pf, @ccordoba12, and @steff456,
I've fixed up the LSP status widget, also. Let me know what you think.

Thanks for the updated screen shot! That makes it so easy to review. Looks good to me! 🌻

@ccordoba12 @isabela-pf @steff456 any chance of moving forward on this soon?

@isabela-pf, it looks like I'm able to merge this, but I didn't do so before because I didn't know if I needed to wait for any other reviewers. Should I merge this or wait?

I'd personally merge it! @steff456 or @ccordoba12 any last thoughts since you also reviewed?

Okay, I'll go ahead and merge.

Hmm... the maininterpreter status bar widget is still visible. It was not visible last time I checked. I'll have to investigate and make a followup PR.

Okay, it looks like the interpreter status bar is added to the status bar from the maininterpreter plugin (makes sense). This must have been a change since after I started working on this PR and I just missed it. Nevertheless, I know that we had discussed removing the interpreter status bar widget in favor of putting that information in the Console tab (see spyder-ide/ux-improvements#10) so maybe it's good to leave it until that information is put into the Console tab.

Since I was requested to give a review, I'd have preferred if you waited to hear my opinion before merging. I'm sorry for not doing it before, but I'm really busy these days with personal and family issues, so I have very little time for Spyder (i.e. I'm only responding issues and fixing bugs for 5.3.0).
Besides, we try not to merge our own PRs. Yes, I know I do it all the time but that's when I'm basically the only one who understands what the PR is doing or it's very simple. However, I try to ask for a review when I submit big modifications or things I'm unsure about.
My main concern about your work (when I saw the initial implementation some months ago) is that it is mainly about moving the widget from the maininterpreter plugin to completions, which (to me) seems to give us a very little gain.
Furthermore, you say in your description

The interpreter-changed signal no longer routes through the MainWindow. Any services requiring it should access sig_interpreter_changed from the MainInterpreter plugin.

So, it seems you're implementing a design pattern similar to the one in PR #15629. The problem with that is that we discussed about it with @andfoy some months ago and agreed that we should revert it because, now that plugins can be turned off easily, the logic is much simpler and easier to follow if the main window is the one that emits a restart signal and other plugins connect to it. That the Application plugin handles that is an implementation detail that external developers don't need to be aware of (that's what I can recall right now, I could be a bit mistaken though).
Sorry for leaving you hanging for so long here, but the team has been very busy during the last months with updating Qt/PyQt to 5.15 in conda-forge (which is a huge undertaking), making Spyder work with that version (also very hard) and trying to improve engagement with our community (quite time consuming as well). The first two are requirements from our main sponsor (TDK), so we really to address them asap. Besides that, I've been in bug fixing mode, merging PRs that I understand well and don't need too much back and forth (for which I don't have time, as I said in another issue), and writing and reviewing proposals for conferences and grants.
Finally. all this is to say: I don't know if it'd be better to revert this PR and discuss about it a bit more. What do you think?

@ccordoba12, I completely understand that you and many other developers are busy with higher priority items. I apologize for prematurely merging this PR. I think we should revert this PR and discuss it more when you have time.

I'd rather take the blame here since, when asked, I said I'd personally merge it. @mrclary has taken a lot of feedback on this very readily, but he can't take feedback that hasn't been communicated any more than I can know to watch for review I'm unaware of.
I don't think @mrclary stepped out of line at all. He's been tagging us and asking for review respectfully, patiently, and regularly for almost a year (April 2021 to March 2022). I do know it's not common practice in open source to merge one's own PRs, and I generally support that. In this case I wasn't clear on another way to help move this PR forward.
In trying to learn from this, is there any documentation about these kind of expectations? Since there is sometimes self-merging happening on this repo, it makes it look like a viable option when it sounds like that may not be the case.

Thanks @mrclary and @isabela-pf for your answers. I'm a bit tired to give you an answer now (it's midnight in my timezone), but I'll try to do it tomorrow.
I also apologize with you again for taking so long to respond to your pings. I'll let you @mrclary and the other volunteers know the reasons in an email (they are not super personal stuff, just private).

I did review this PR yesterday and I didn't find any issue like the ones @ccordoba12 is commenting on and I have a couple of things that I don't agree.

Besides, we try not to merge our own PRs.

As I already stated, I did review and approve this PR yesterday, so Ryan didn't merge his own work without any opinion or approval.

I try to ask for a review when I submit big modifications or things I'm unsure about.

Ryan asked for review and none of us were able to deliver our opinions in a reasonable timing. So again, this doesn't apply here.

My main concern about your work (when I saw the initial implementation some months ago) is that it is mainly about moving the widget from the maininterpreter plugin to completions, which (to me) seems to give us a very little gain.

Thanks to the new API, we are able to do this modifications. For me, it makes sense to have the completions statusbar widget in the actual completions plugin since the component is dependent on it and it modifies what's displayed, which is not the case of having the widget in the maininterpreter plugin.
Just a heads up of the editor migration, we are going to move several widgets that aren't in the most logical position to one that makes the structure of the code more organized. So I don't agree that this is a little gain PR. And I just wanted to highlight that we shouldn't be using this language becase every PR is a gain.

So, it seems you're implementing a design pattern similar to the one in PR https://github.com/spyder-ide/spyder/pull/15629.

@ccordoba12 this PR is just a refactor of the widget rather than a change in the design pattern and it will not have any effect on the turn off of the plugins.

Finally, all this is to say: I don't know if it'd be better to revert this PR and discuss about it a bit more. What do you think?

Finally, I don't agree with reverting this PR. @mrclary has put a lot of effort into this, we finally merge it and there's nothing else to discuss.

My comments:
To Ryan:

I apologize for prematurely merging this PR.

Thanks for understanding @mrclary!

I think we should revert this PR and discuss it more when you have time.

We'll see, but thanks for being ok with the idea.

To Isabela:

I'd rather take the blame here since, when asked, I said I'd personally merge it.

Don't worry. I think no one is to blame here.

@mrclary has taken a lot of feedback on this very readily, but he can't take feedback that hasn't been communicated any more than I can know to watch for review I'm unaware of.

I totally agree. This was my fault.

I don't think @mrclary stepped out of line at all.

I agree too. That's why I tried to be as polite as possible in my comment above.

He's been tagging us and asking for review respectfully, patiently, and regularly for almost a year (April 2021 to March 2022).

I agree, the problem is that (due to the commitments and work I mentioned above) no one has had time to review it.

I do know it's not common practice in open source to merge one's own PRs, and I generally support that. In this case I wasn't clear on another way to help move this PR forward.

Right, the thing is I had some things to say about the design before merging, that's all.

In trying to learn from this, is there any documentation about these kind of expectations? Since there is sometimes self-merging happening on this repo, it makes it look like a viable option when it sounds like that may not be the case.

No, there isn't. But we could add some instructions to the review PR guidelines.

To Stephannie:

As I already stated, I did review and approve this PR yesterday, so Ryan didn't merge his own work without any opinion or approval.

I know. What I meant is that Ryan didn't wait to hear from me yesterday (when I received another ping to look at this).
To be more specific, I was thinking of QtPy yesterday when I wrote that, where @dalthviz, @CAM-Gerlach and I have been successfully working on reviewing and merging work for the last months. There we try to wait for all developers asked for a review before merging, unless it's something urgent and some of us (usually me) fail to respond; and we don't merge our own PRs, i.e. someone else on the team does it.

Thanks to the new API, we are able to do this modifications. For me, it makes sense to have the completions statusbar widget in the actual completions plugin since the component is dependent on it and it modifies what's displayed, which is not the case of having the widget in the maininterpreter plugin.

That's a difference of opinions and I'm fine with it. But that's why (for me) this required more discussion.

So I don't agree that this is a little gain PR. And I just wanted to highlight that we shouldn't be using this language becase every PR is a gain.

Again, the little gain is my opinion. And I disagree that all PRs are a gain. For instance, you can take a look at this PR of mine in QtPy, which was rejected by @dalthviz and @CAM-Gerlach: https://github.com/spyder-ide/qtpy/pull/295.
They had strong arguments against my proposed changes, so we all agreed that it was best to close it.

this PR is just a refactor of the widget rather than a change in the design pattern and it will not have any effect on the turn off of the plugins.

I disagree too and Ryan made it clear on the description above:

The interpreter-changed signal no longer routes through the MainWindow. Any services requiring it should access sig_interpreter_changed from the MainInterpreter plugin.

So Ryan removed sig_interpreter_changed from the MainWindow and moved it to the MainInterpreter plugin. As I said in my previous comment, this is very similar to the pattern followed in PR #15629. At the moment I agreed with Ryan that that was fine. However, after the new teardown mechanism landed, @andfoy and I said that we'd like to revisit that implementation at some point and revert it to using signals emitted by the MainWindow.

Finally, I don't agree with reverting this PR. @mrclary has put a lot of effort into this, we finally merge it and there's nothing else to discuss.

I'm fine with the refactoring of the status bar widget, if the rest of the team agrees on that too. However, I think we should talk more about the removal of sig_interpreter_changed from MainWindow.

@ccordoba12 @isabela-pf @steff456,
Thank you for your kind comments.
The changes to sig_interpreter_changed, as Carlos pointed out, were made in good faith following a previously agreed upon pattern. However, since that pattern has subsequently been reverted or changed, then we should certainly discuss what should be done to restore sig_interpreter_changed to compliance and make a follow-up PR.
I also agree that we could add some guidance to the PR guidelines and I'll make a few suggestions in a comment at #16789 .

@ccordoba12, please don't be alarmed by the recent removal/request to review this PR. I was just testing GitHub's interface.

Ok, no problem. Thanks for letting me know about it 👍🏽

The changes to sig_interpreter_changed, as Carlos pointed out, were made in good faith following a previously agreed upon pattern. However, since that pattern has subsequently been reverted or changed, then we should certainly discuss what should be done to restore sig_interpreter_changed to compliance and make a follow-up PR.

Ok, so are you ok with reverting that change so we can discuss about it later? Just checking with you before taking a decision here.

I also agree that we could add some guidance to the PR guidelines and I'll make a few suggestions in a comment at https://github.com/spyder-ide/spyder/pull/16789 .

That's fine for me too. I'll leave my comments there.


Uncaught ReferenceError: bezier is not defined

Hi
First, thanks for this nice lib !
I am trying to use it from ES2015 code, but I have the following error :

Uncaught ReferenceError: bezier is not defined

published as 0.1.6. Thank you for PR


Integration is using deprecated DEVICE_CLASS_* constants

Describe the bug
This custom integration uses deprecated DEVICE_CLASS_* constants in its codebase.
The DEVICE_CLASS_* constants have been deprecated and replaced in Home Assistant Core 2021.12 (over a year ago). I would highly suggest updating/migrating this integration to the new enums.
For example, for the device classes supported by the sensor platform, there is now a SensorDeviceClass enum. So if a sensor previously used the DEVICE_CLASS_ENERGY constant, it should now use SensorDeviceClass.ENERGY. Other platforms (like binary_sensor, and number) provide similar enumerations for their supported device classes.
The migration thus only consists of replacing constants with an enumeration member and is, therefore, very low impact and should be fairly straightforward.
If I can help resolve any questions regarding this change or migration, feel free to ask or respond to this issue. I'm happy to help!
Kindest regards,
../Frenck
To Reproduce
n/a
Expected behavior
n/a
Screenshots
n/a
Desktop (please complete the following information):

HomeAssistant Version: 2021.12 and newer
OS [e.g. Ubuntu, Hassio, Docker] Any
Used shutters (iveo/commeo) [e.g. 2 x iveo] Any

Additional context
n/a

Fixed, thank you for stopping by ;)

Thanks for addressing @Kannix2005 👍
../Frenck


Make sure it works on Laravel 5

Cause that's gonna be a thing like tomorrow or something...

Hi Sammy,
can you say how long it will take until its laravel 5 ready? We're on starting a new project and would like to use laravel 5. We have a strong facebook connection to be built up and your package seems to be a very good choice. Of course we would help on making it laravel 5 compatible, if you provide us with information what has to be done. Sadly we have never used laravel before (coming from zend 1/2). Therefore we have no clue what's needed to make it work with laravel 5.
greets, dahaiz

Hey @DaHaiz! I'm working on this this week. I'll let you know when it's ready. :)

aah your're great man! much thanks! :)

+1 waiting for it too :)
Thank you!

It's got some BC's in it and it's in dev mode until the Facebook PHP SDK v4.1 is officially tagged as stable. I'm going to close this issue out. If you run into any trouble with it, please let me know by submitting a new issue.
Good luck! :)

Wow! That was fast.
Can't wait to try it out on L5.
Cheers!


Stuck at "Downloading dependencies: Finishing VS Live Share installation (downloading)..."

Stuck at "Downloading dependencies: Finishing VS Live Share installation (downloading)...
What was your system configuration?
Processor: 2.6 GHz 6 kernels  Intel Core i7
Memory:    16GB
Product and Version [VS/VSCode]:  VSCode1.66.2
OS Version[macOS/Windows]: macOS Big Sur
Live Share Extension Version: 1.0.5527
Target Platform or Language [e.g. Node.js]:  Node.js
Steps to Reproduce / Scenario:

Go to install the live share plugin
See error

We’ve made improvements in this area since this issue was filed (i.e. the vsls-agent process and associated dependencies have been removed). We believe this may have improved your experience and are closing this issue. If this issue still persists for you, please comment on the issue and let us know. Thank you.


Exclude plugin vendor directories from openapi search paths

1. Why is this change necessary?
When installing dependencies in plugins in order to execute unit tests in isolation from the shopware development system, the OpenApiLoader used up all available memory (tested with 16G memory_limit).
I agree this is an edge case, but it cost me 4-5 hours to figure out why the swagger UI wasn't loading. I hope this will save someone else the trouble.
2. What does this change do, exactly?
This commit excludes vendor directories within custom/plugins/* from the OpenApiLoader search path.
3. Describe each step to reproduce the issue or behaviour.

Create a plugin that requires "shopware/platform": "6.1.x@dev" in its `composer.json.
Run composer install in the plugin directory
Try to open the swagger UI at /api/v1/_info/swagger.html

4. Please link to the relevant issues (if any).
No issue.
5. Checklist

[x] I have written tests and verified that they fail without my change
[x] I have squashed any insignificant commits
[x] I have written or adjusted the documentation according to my changes <-- none are required
[ ] This change has comments for package types, values, functions, and non-obvious lines of code
[x] I have read the contribution requirements and fulfil them.

Note: this PR is partially also motivated by me wanting to learn about the shopware contribution process.
Please let me know what I can improve.

As far as I can tell the failing tests are not related to this PR.

Hello,
thank you for creating this pull request.
I have opened an issue on our Issue Tracker for you. See the issue link: https://issues.shopware.com/issues/NEXT-7447
Please use this issue to track the state of your pull request.

Hello @Vinai,
thanks for the PR and particularly for the test :)
Our gitlab pipeline is green except for some styling issues. Please use our pre-commit hook or run cs-fixer like this: https://github.com/shopware/development/blob/79b602871d41cfdfb6cb073e09f2599aaad6d99e/dev-ops/pre-commit#L60

hey @Vinai,
I will also leave a few comments in a while 😉✌

In gitter @shyim just told me about a patch he made for the issue which, in addition to resolving the problem, also reduces the load time a lot by reducing the number of files to scan to only active controllers. His is probably the better solution.

ok, maybe we could use your test with the helper class nevertheless
@shyim @pweyck what do you think?

@mitelg I think the test would pass with the patch, however, it wouldn't test the actually behavior of the patch. For example, the API controller that is copied into the in-memory file system isn't used to add the _search path to the result, but instead that would come from the registered controller... so that part of the fixture could be removed without influencing the test.
The only thing of value this PR might still contain is the flysystem wrapper, but since it's not used, it might as well be kept out of the system.
So all in all I think it's better if I close the PR. Thank you for the reviews, I learned something and it was a good experience.


feat: Keep upstream's state in local cache #585

Core keeps upstream's state in local cache for deployments taken from DIAl config.
We want to maintain a consistent behavior for deployments from blob storage as well.

/deploy-review


Large tensor support for random ops

Description
Support int64 (large tensor) for remaining random ops
Below 8 are supported
random.exponential
random.gamma
random.generalized_negative_binomial
random.multinomial
random.negative_binomial
random.normal
random.poisson
random.randn

Checklist
Essentials
Please feel free to remove inapplicable items for your PR.

[x] Changes are complete (i.e. I finished coding on this PR)
[x] All changes have test coverage:
[x] Code is well-documented:
[x] To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

Changes
Added 1 test case each
Comments
Currently
nosetests tests/nightly/test_large_array.py results in 42 tests pass
(4 fail - unrelated test ops- topk,sort,argsort,reduce)

addressed!


Error opening filter: Access is denied. at v1.0.5

how can I solve it?

Can you tell what is your OS?(7,8,8.1,10 ?)

Windows 10 pro build 17134


pipeline: FileUploaded events don't populate Filename

FileUploaded events don't populate the Filename field, which looks tricky because pending files can be merged into multiple outgoing files.
Code: https://github.com/moov-io/achgateway/blob/v0.16.10/internal/pipeline/aggregate.go#L219-L225

We'll need to call .emitFilesUploaded for each merged file rather than at the end or call newUploadedFiles multiple times.


Laxmi's register page

Naming Rules
Name your PR like this: ISSUENUMBER-TITLE-YOURNAME
Description
Write a summary of your change. Explain why you have made it.
Related to
Make sure you include the issue number with a hash sign # so Github can link this PR to the right issue, like this:
Fixes #1
Checklist:

[ ] My code follows the style guidelines of this project
[ ] I have carefully reviewed my own code
[ ] I have commented my code
[ ] I have updated any documentation

As screenshots in the Slack channel and reviewed your code, I merged your PR.
But not sure whether it will conflict with other PRs .
Let's see what will happen after this  merge.


Update repository to point to the correct project

Your projects are flip-flopped. Art gallery code is for the dark mode activity and vice versa. Also creating a pull request there...

@salman5436 @aram-thrivedx this is an old PR solving the issue, tested, and ready to be merged.


update django.po pt_BR

naturaltime translation spacing correction.

Thanks for the report, however, translations are handled at Transifex.


Featuresupport clickhouse jdbc external table

Proposed changes
Issue Number: close #xxx
Problem summary
Describe your changes.
Checklist(Required)

Does it affect the original behavior:

[ ] Yes
[x] No
[ ] I don't know

Has unit tests been added:

[ ] Yes
[x] No
[ ] No Need

Has document been added or modified:

[ ] Yes
[x] No
[ ] No Need

Does it need to update dependencies:

[ ] Yes
[x] No

Are there any changes that cannot be rolled back:

[ ] Yes (If Yes, please explain WHY)
[x] No

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 34.28 seconds
load time: 432 seconds
storage size:<PHONE_NUMBER>2 Bytes
https://doris-community-test-1308700295.cos.ap-hongkong.myqcloud.com/tmp/20221114070311_clickbench_pr_45468.html


UT must now be PEP8 compliant

Coverage remained the same at 84.334% when pulling d72404072354e0cefe02354cedbc6eed434a848a on feat/flake8-on-ut into f026cfb90e4ccba59260e6b6075b398585a582da on master.


containers: modify bindmount option

This commit changes the bind mount option for the mount point
/var/lib/ceph in the systemd template for mon and mgr containers. This
is needed in case of collocating mon/mgr with osds using dmcrypt
scenario.
Once mon/mgr got converted to containers, the dmcrypt layer sub mount is
still seen in /var/lib/ceph. For some reason it makes the
corresponding devices busy so any other container can't open/close it.
As a result, it prevents osds from starting properly.
Since it only happens on the nodes converted before the OSD play, the idea is
to bind mount /var/lib/ceph on mon and mgr with the rshared option
so once the sub mount is unmounted, it is propagated inside the
container so it doesn't see that mount point.
Closes: https://bugzilla.redhat.com/show_bug.cgi?id=1896392
Signed-off-by: Guillaume Abrioux<EMAIL_ADDRESS>

jenkins test centos-container-lvm_batch

not sure whether there is a benefit to have this in master/stable-5.0/stable-4.0 see #6041

jenkins test centos-container-external_clients

jenkins test centos-container-all_daemons

jenkins test centos-container-all_in_one

jenkins test centos-container-collocation

jenkins test centos-container-external_clients

jenkins test centos-container-lvm_batch

jenkins test centos-non_container-switch_to_containers

jenkins test centos-non_container-all_daemons

jenkins test centos-container-update

jenkins test centos-container-purge

jenkins test centos-container-lvm_osds

jenkins test centos-non_container-all_daemons


AvailableModes for AC_Unit

Hello,
I'm trying to build an app to control an Air Conditioning Unit. I've seen that one of the available trait is the Modes (https://developers.google.com/actions/smarthome/traits/modes) one, but I couldn't find a complete list of these modes.
I would like to know if in this list there are the "Dry" mode and "Fan" mode, or if in the future they will be available.
Thank you

You can take a look at the FanSpeed trait.
There is a mode called "Fan Speed" and "fan_position".
There is a mode setting called "Dry".

Thank you!
Is there the possibility to have a complete list of all the possible modes?

We've published the first set of reference documentation: https://developers.google.com/actions/reference/smarthome/traits/modes

There is a mode called "Fan Speed" as well as "fan_position".

@Fleker what happened to fan_position? I can't find any reference to it 🤔

Oh, those may not currently be marked in the documentation, but they should work.


Disable in floating windows

Hi,
I'm trying to find a way to exclude some buffers by type or name.
Some colorschemes use a different guibg for floating windows (hi NormalFloat) which becomes problematic with the colorcolumn.
Is there an option for this?
An example of the results I have with Mason plugin:

local config = {
disabled_filetypes = { "lazy", "mason" },
}


Adding additional colors to the tailwind.config.js

Which @angular/* package(s) are the source of the bug?
compiler-cli, compiler
Is this a regression?
No
Description
According to the tailwindcss docs it's possible to extend theme with new colors for example 'custom-color':'#43d62c'. But after rebuild Angular project (ng serve), Angular doesn't recognize my new color class (class="bg-custom-color"). For more information about applying custom/new colors to the tailwind.config.js see/watch https://youtu.be/ibVOMdVpYOY (play video from 4.15) and tailwindcss docs: https://tailwindcss.com/docs/customizing-colors#adding-additional-colors.
Please provide a link to a minimal reproduction of the bug
https://github.com/mengio001/tmroot/blob/main/tailwind.config.js
https://github.com/mengio001/tmroot/blob/main/src/app/presentation/page-designs/welcome-page/welcome-page.component.html
https://www.timelessmedia.nl/mytickets/issue-44670/example-issue-custom-color.PNG
Please provide the exception or error you saw
https://www.timelessmedia.nl/mytickets/issue-44670/bg-custom-color.PNG
Please provide the environment you discovered this bug in (run ng version)
Angular CLI: 13.1.2
Node: 14.15.0
Package Manager: npm 6.14.8
OS: win32 x64

Angular: 13.1.1
... animations, cdk, common, compiler, compiler-cli, core, forms
... material, platform-browser, platform-browser-dynamic, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1301.2
@angular-devkit/build-angular   13.1.2
@angular-devkit/core            13.1.2
@angular-devkit/schematics      13.1.2
@angular/cli                    13.1.2
@schematics/angular             13.1.2
rxjs                            7.4.0
typescript                      4.5.4

Anything else?
No response

I'm sorry, but this issue is not caused by Angular CLI. I was able to reproduce the problem using tailwindcss CLI directly.
tailwindcss -i src/styles.scss -o ./dist/output.css --watch

I'm sorry, but this issue is not caused by Angular CLI. I was able to reproduce the problem using tailwindcss CLI directly.
tailwindcss -i src/styles.scss -o ./dist/output.css --watch

Thanks, I'll shoot a ticket to tailwindcss.


Aquarea Heat Model not recognized

** Versions **

Home Assistant version: 2024.12.3
This integration version: 1.3.4

Describe the bug
I have a IG:WH-ADC0509L3E5AN AG:WH-WDG05LE5  and the Model is not shown in HA

Hello,
it should be fixed in https://github.com/kamaradclimber/heishamon-homeassistant/releases/tag/1.13.5


Created and updated docs for 1.26

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

/lgtm

/approve

/unhold


Autoloads and engine singletons sometimes are considered "freed"

Godot version:
3.1 stable
OS/device including version:
Linux and Android (multiple versions)
Issue description:
Sometimes we get errors and crashes where the message is like "Trying to access property 'X' from a stray pointer object". Happens with properties and sometimes functions. We added those checks in release mode so we can gather info from Google Play crash reports, since Godot only has them in debug.
When looking at the base from which the property belongs, we found it was an autoload marked as singleton. It doesn't make sense since we don't free this autoload and it should only be gone when the application exits.
We also had reports of freed instances when calling static functions from some scripts and from the OS singleton (which is on Godot itself and should never be freed).
I tried to use Valgrind but couldn't find anything particular that could be related to those errors.
This is quite similar to #26564, maybe the same thing.
We need help to figure out what could be causing this.
Steps to reproduce:
Not sure since it happens rarely.

Sounds similar to https://github.com/godotengine/godot/issues/30700#issuecomment-513374731

Can confirm. The frequency is quite high considering a game with more than a few users.
In our latest Google Play Pre-launch report, from 8 tested devices, we got 1 with this problem. (In this case, Global, which is an autoloaded variable was a stray pointer object)

I know it is a small sample size but still supposes a 12.5% rate of this crash happening.
It sometimes happen on linux, but is semi-impossible to replicate (a matter of luck). Also: happens more frequently when there is no max fps (when fps reaches the hundreds/thousands).

I'm running with ASAN and found this:

=================================================================
==30888==ERROR: AddressSanitizer: heap-use-after-free on address 0x604000b9b178 at pc 0x000001046f54 bp 0x7fffffffb570 sp 0x7fffffffb560
READ of size 8 at 0x604000b9b178 thread T0
    #0 0x1046f53 in CowData<Vector2>::set(int, Vector2 const&) core/cowdata.h:139
    #1 0x1045199 in Vector<Vector2>::set(int, Vector2 const&) core/vector.h:82
    #2 0x104124d in Vector<Vector2>::push_back(Vector2 const&) core/vector.h:154
    #3 0x3c1a56c in LineBuilder::strip_add_tri(Vector2, LineBuilder::Orientation) scene/2d/line_builder.cpp:495
    #4 0x3c1ac5e in LineBuilder::strip_add_arc(Vector2, float, LineBuilder::Orientation) scene/2d/line_builder.cpp:526
    #5 0x3c181ba in LineBuilder::build() scene/2d/line_builder.cpp:356
    #6 0x3c009ac in Line2D::_draw() scene/2d/line_2d.cpp:266
    #7 0x3bffd5e in Line2D::_notification(int) scene/2d/line_2d.cpp:203
    #8 0x3c09f1f in Line2D::_notificationv(int, bool) scene/2d/line_2d.h:38
    #9 0x5098c91 in Object::notification(int, bool) core/object.cpp:952
    #10 0x3b0a558 in CanvasItem::_update_callback() scene/2d/canvas_item.cpp:455
    #11 0x1337ac1 in MethodBind0::call(Object*, Variant const**, int, Variant::CallError&) core/method_bind.gen.inc:54
    #12 0x50988e7 in Object::call(StringName const&, Variant const**, int, Variant::CallError&) core/object.cpp:942
    #13 0x5081e67 in MessageQueue::_call_function(Object*, StringName const&, Variant const*, int, bool) core/message_queue.cpp:256
    #14 0x508261f in MessageQueue::flush() core/message_queue.cpp:303
    #15 0x31078d8 in SceneTree::idle(float) scene/main/scene_tree.cpp:513
    #16 0xfdf50e in Main::iteration() main/main.cpp:1899
    #17 0xf6fd65 in OS_X11::run() platform/x11/os_x11.cpp:3006
    #18 0xf46e79 in main platform/x11/godot_x11.cpp:55
    #19 0x7ffff690dee2 in __libc_start_main (/usr/lib/libc.so.6+0x26ee2)
    #20 0xf46c1d in _start (/home/george/workspace/javary/games/monster-pop/godot/bin/godot.x11.tools.64s+0xf46c1d)

0x604000b9b178 is located 40 bytes inside of 48-byte region [0x604000b9b150,0x604000b9b180)
freed by thread T0 here:
    #0 0x7ffff766ef40 in __interceptor_realloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:163
    #1 0x537684b in Memory::realloc_static(void*, unsigned long, bool) core/os/memory.cpp:140
    #2 0x10417cd in CowData<Vector2>::resize(int) core/cowdata.h:282
    #3 0x103f85b in Vector<Vector2>::resize(int) core/vector.h:84
    #4 0x10411b0 in Vector<Vector2>::push_back(Vector2 const&) core/vector.h:152
    #5 0x3c1a56c in LineBuilder::strip_add_tri(Vector2, LineBuilder::Orientation) scene/2d/line_builder.cpp:495
    #6 0x3c1ac5e in LineBuilder::strip_add_arc(Vector2, float, LineBuilder::Orientation) scene/2d/line_builder.cpp:526
    #7 0x3c181ba in LineBuilder::build() scene/2d/line_builder.cpp:356
    #8 0x3c009ac in Line2D::_draw() scene/2d/line_2d.cpp:266
    #9 0x3bffd5e in Line2D::_notification(int) scene/2d/line_2d.cpp:203
    #10 0x3c09f1f in Line2D::_notificationv(int, bool) scene/2d/line_2d.h:38
    #11 0x5098c91 in Object::notification(int, bool) core/object.cpp:952
    #12 0x3b0a558 in CanvasItem::_update_callback() scene/2d/canvas_item.cpp:455
    #13 0x1337ac1 in MethodBind0::call(Object*, Variant const**, int, Variant::CallError&) core/method_bind.gen.inc:54
    #14 0x50988e7 in Object::call(StringName const&, Variant const**, int, Variant::CallError&) core/object.cpp:942
    #15 0x5081e67 in MessageQueue::_call_function(Object*, StringName const&, Variant const*, int, bool) core/message_queue.cpp:256
    #16 0x508261f in MessageQueue::flush() core/message_queue.cpp:303
    #17 0x31078d8 in SceneTree::idle(float) scene/main/scene_tree.cpp:513
    #18 0xfdf50e in Main::iteration() main/main.cpp:1899
    #19 0xf6fd65 in OS_X11::run() platform/x11/os_x11.cpp:3006
    #20 0xf46e79 in main platform/x11/godot_x11.cpp:55
    #21 0x7ffff690dee2 in __libc_start_main (/usr/lib/libc.so.6+0x26ee2)

previously allocated by thread T0 here:
    #0 0x7ffff766ef40 in __interceptor_realloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:163
    #1 0x537684b in Memory::realloc_static(void*, unsigned long, bool) core/os/memory.cpp:140
    #2 0x10417cd in CowData<Vector2>::resize(int) core/cowdata.h:282
    #3 0x103f85b in Vector<Vector2>::resize(int) core/vector.h:84
    #4 0x10411b0 in Vector<Vector2>::push_back(Vector2 const&) core/vector.h:152
    #5 0x3c19f4d in LineBuilder::strip_add_quad(Vector2, Vector2, Color, float) scene/2d/line_builder.cpp:467
    #6 0x3c17920 in LineBuilder::build() scene/2d/line_builder.cpp:304
    #7 0x3c009ac in Line2D::_draw() scene/2d/line_2d.cpp:266
    #8 0x3bffd5e in Line2D::_notification(int) scene/2d/line_2d.cpp:203
    #9 0x3c09f1f in Line2D::_notificationv(int, bool) scene/2d/line_2d.h:38
    #10 0x5098c91 in Object::notification(int, bool) core/object.cpp:952
    #11 0x3b0a558 in CanvasItem::_update_callback() scene/2d/canvas_item.cpp:455
    #12 0x1337ac1 in MethodBind0::call(Object*, Variant const**, int, Variant::CallError&) core/method_bind.gen.inc:54
    #13 0x50988e7 in Object::call(StringName const&, Variant const**, int, Variant::CallError&) core/object.cpp:942
    #14 0x5081e67 in MessageQueue::_call_function(Object*, StringName const&, Variant const*, int, bool) core/message_queue.cpp:256
    #15 0x508261f in MessageQueue::flush() core/message_queue.cpp:303
    #16 0x31078d8 in SceneTree::idle(float) scene/main/scene_tree.cpp:513
    #17 0xfdf50e in Main::iteration() main/main.cpp:1899
    #18 0xf6fd65 in OS_X11::run() platform/x11/os_x11.cpp:3006
    #19 0xf46e79 in main platform/x11/godot_x11.cpp:55
    #20 0x7ffff690dee2 in __libc_start_main (/usr/lib/libc.so.6+0x26ee2)

It looks like a bug in Line2D. I wonder if other people that had this issue were using Line2D as well.
This is the same I've found with Valgrind some time ago. I had dismissed as not the cause, but now I think it actually might be the issue. This is reported in a similar point where we got the crash in the Pre-Launch Report from Google Play.

Sample project with just a Line2D. If you run with ASAN enabled you can see the issue. It happens with Godot master (05be97a607105dbd8fb93bc90d5fc3dd3eaf94a2) too.
line2d-bug.zip

LineBuilder was added in #7352 by @Zylann.
It changed quite a bit since that PR, but from a quick glance I don't see anything particularly fishy.

I can't see what's wrong with those lines.
The only eventual issue that occured in the past was the fact there is stuff like this going on:
uvs.push_back(uvs[_last_index[UP]]);

But due to how Vector was implemented, it was resizing, invalidating the reference passed as parameter of push_back. I wonder if that issue still occurs, although your logs doesn't mention lines like this.

I can't see what's wrong with those lines.
The only eventual issue that occured in the past was the fact there is stuff like this going on:
uvs.push_back(uvs[_last_index[UP]]);

This is exactly what I've found, actually. The logs I posted is from an older version of Godot, the actual issue is on this line:
https://github.com/godotengine/godot/blob/05be97a607105dbd8fb93bc90d5fc3dd3eaf94a2/scene/2d/line_builder.cpp#L533
Changing that to use a temporary variable doesn't give the ASAN error anymore.
I'm not entirely sure this is the cause of my initial problem, but it's the only memory issue I could find.

This is the issue where it was found, it was assigned to @hpvb https://github.com/godotengine/godot/issues/16961#issuecomment-435541571


WIP | migrate to plugin SDK

test-backend-plugin-changes

1.  The major issue is that after the following change https://github.com/wbrowne/oci-grafana-metrics/tree/backend-to-sdkOur frontend is receiving an encoded  data  as follows in data frame. Is this expected and mandatory ?
{"results":{"A":{"refId":"A","series":null,"tables":null,"dataframes":["[encoded data, 6096 characters]"]}}}

--
2. Also, Will had told earlier that front-end might need some changes too. I was able to finds some links on migration.But the migration guide doesn’t talk about handling the encoded text though. 3. Is it possible to retain the table instead of the data frame without encoding  as our front end code is using table ?Can you please point me to the right  docs if required?
@wbrowne

@athulmurali yes this is expected. Are these the docs you're referring to?

@athulmurali yes this is expected. Are these the docs you're referring to?

Yep. It is the one.
With the current front end and the response that we receive,
I tried using the function toDataFrame on the response that we are getting, but it doesn't look like it is able decode it though

@wbrowne  can you please point me to a  sample repo where the frontend takes in this kind of response from the backend and works ?

This seems like you're using a Grafana version pre-v8. Here's the code for handling base64 encoded arrow data on Grafana v7.5.x branch: https://github.com/grafana/grafana/blob/c5cf127aa6217ae8babdd6fb9315114e8badd488/packages/grafana-runtime/src/utils/queryResponse.ts#L94-L110

This seems like you're using a Grafana version pre-v8. Here's the code for handling base64 encoded arrow data on Grafana v7.5.x branch: https://github.com/grafana/grafana/blob/c5cf127aa6217ae8babdd6fb9315114e8badd488/packages/grafana-runtime/src/utils/queryResponse.ts#L94-L110

Thanks a ton

This seems like you're using a Grafana version pre-v8. Here's the code for handling base64 encoded arrow data on Grafana v7.5.x branch: https://github.com/grafana/grafana/blob/c5cf127aa6217ae8babdd6fb9315114e8badd488/packages/grafana-runtime/src/utils/queryResponse.ts#L94-L110

Hi @marefr ,
To include the above suggest, I had to import apache-arrow

is there any reason why apache arrow cannot be included in grafana ?

There seems to be an issue with this.

Tried importing base64StringToArrowTable from Grafana reuntime @ ver 7.5  but didn't work
Whenever the apache arrow module  (in an attempt to write function by copy pasting the lines required for this )is added, grafana  throws an error "module loading". Table.from is being imported. from apache arrow

I tried doing it in a standalone script but it works.

There seems to be an issue with this.

Tried importing base64StringToArrowTable from Grafana reuntime @ ver 7.5  but didn't work
Whenever the apache arrow module  (in an attempt to write function by copy pasting the lines required for this )is added, grafana  throws an error "module loading". Table.from is being imported. from apache arrow

I tried doing it in a standalone script but it works.

Hello @athulmurali,
I was hoping that I can help you with the migration of your plugin. What steps are you doing to get this error? I would like to recreate it locally.
Also, what steps are you planning on doing to migrate the frontend code?

@athulmurali would it be possible to get access to a demo/test environment so we can setup this plugin locally? Would help me to help you get the final steps of the migration in place.

Hi Marcus,
I am traveling today and hence I am off work.
But still, I will push my changes on top of  the existing one in the PR.
I will touch base with my manager (Dmitry)and get back to you, if he can
get you some help for the local environment  set up.
Thanks for your response,
Athul
On Tue, Jul 6, 2021, 02:53 Marcus Andersson @.***>
wrote:

@athulmurali https://github.com/athulmurali would it be possible to get
access to a demo/test environment so we can setup this plugin locally?
Would help me to help you get the final steps of the migration in place.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/oracle/oci-grafana-metrics/pull/92#issuecomment-874624084,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AE3CLHBM3RI2CLXQQT4MUGDTWLHDDANCNFSM47OQL4SA
.

Here is a sample wip
https://github.com/oracle/oci-grafana-metrics/pull/93
On Tue, Jul 6, 2021 at 8:09 AM Athul Muralidharan @.***>
wrote:

Hi Marcus,
I am traveling today and hence I am off work.
But still, I will push my changes on top of  the existing one in the PR.
I will touch base with my manager (Dmitry)and get back to you, if he can
get you some help for the local environment  set up.
Thanks for your response,
Athul
On Tue, Jul 6, 2021, 02:53 Marcus Andersson @.***>
wrote:

@athulmurali https://github.com/athulmurali would it be possible to
get access to a demo/test environment so we can setup this plugin locally?
Would help me to help you get the final steps of the migration in place.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/oracle/oci-grafana-metrics/pull/92#issuecomment-874624084,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AE3CLHBM3RI2CLXQQT4MUGDTWLHDDANCNFSM47OQL4SA
.

--
Athul

@mckn
Hi Marcus,

The readme file should be able to help the oci-cli installation.
the PR above contains the latest changes.

Still, we can jump on zoom to get this sorted out asap.

@mckn
Hi Marcus,

The readme file should be able to help the oci-cli installation.
the PR above contains the latest changes.

Still, we can jump on zoom to get this sorted out asap.

Suuuper! Thanks for getting back to me and sorry for the late answer.
I will have a look at it now and see it I can help you push this forward.

@athulmurali so I did see the guide in the readme about how to setup the oci-cli. But I guess I still need an Oracle Cloud environment to connect the plugin against. Can you help out on that area?

Hi @mckn,
Thanks for looking into it.
Sure.
I was told the free tier account should be able to do the same.
Let me try to set up one and give the steps.
Meanwhile, I can walk you through the local instance setup.
Please let me know when you are available and I can do zoom.

Ok ok, I can see if I can sign up for a free tire. Will that contain data and metrics?
That would be awesome! I'm located in CEST what time zone are you located in? I am happy to take a call tomorrow.

Ok ok, I can see if I can sign up for a free tire. Will that contain data and metrics?
That would be awesome! I'm located in CEST what time zone are you located in? I am happy to take a call tomorrow.

Regarding getting metrics,
As long as  a resource is created already, such as instance, yes
I work in PT.
But, I can do  your time ( 5pm CEST Thursday)
Can you please send me an email. Couldn't find an emailID in your profile.

@marefr
Regarding getting metrics,
As long as  a resource is created already, such as instance, yes
I work in PT.
But, I can do  your time ( 5pm CEST Thursday)
Can you please send me an email. Couldn't find an emailID in your profile.

@marefr
Something came up.
I will have to cancel the meet  tomorrow.

@athulmurali I just sent you an email. Feel free to reach out to me on that email.


Filter reports

Describe the issue/bug:
O filtro "Reporter user:" está retornando como "Reported user:"
To Reproduce:

Vá para https://brainly.com.br/question/add?reported-contents

Clique em "options"

Preencha o campo "Reporter user:"

Screenshots [paste below, optional]:

https://brainly.com.br/perfil/badcsound-1110038

Hi @Maxonvs
Your GIF is very small for identifying characters that you use. I'll try to reproduce but in the meantime, do you mind sending a bigger version of that gif, please?

@seahindeniz acho que ficou melhor, mas se precisar posso hospedar em vídeo.

Thanks a lot, @Maxonvs


Ecto.Schema and typespec issues in Elixir 1.10

Environment

Elixir version (elixir -v): 1.10.1
Database and version (PostgreSQL 9.4, MongoDB 3.2, etc.): N/A, but Postgres 12.2
Ecto version (mix deps): 3.3.3
Database adapter and version (mix deps): N/A, but ecto_sql, 3.3.4
Operating system: Mac OS Mojave

Current behavior
I think this is an Ecto issue with the newest minor version of Elixir, but in Elixir 1.10.1, I can't use the schema types in my typespecs. This is not an issue on previous versions of Elixir.
Using this code (note the spec on what would be line 12):
defmodule MyApp.User do
  use Ecto.Schema
  import Ecto.Changeset
  alias __MODULE__

  schema "users" do
    field :email, :string
    field :password, :string
    timestamps()
  end

  @spec changeset(User.t(), map()) :: Ecto.Changeset.t()
  def changeset(%User{} = user \\ %User{}, attrs) do
    user
    |> cast(attrs, [:email, :password])
  end
end

Paste in an iex session with Elixir 1.10.1 (erlang 22.2.6, Ecto 3.3.3), and you'll get this error:
** (CompileError) iex:12: type t/0 undefined (no such type in MyApp.User)
    (elixir 1.10.1) lib/kernel/typespec.ex:898: Kernel.Typespec.compile_error/2
    (stdlib 3.11.2) lists.erl:1354: :lists.mapfoldl/3
    (elixir 1.10.1) lib/kernel/typespec.ex:950: Kernel.Typespec.fn_args/5
    (elixir 1.10.1) lib/kernel/typespec.ex:936: Kernel.Typespec.fn_args/6
    (elixir 1.10.1) lib/kernel/typespec.ex:377: Kernel.Typespec.translate_spec/8
    (stdlib 3.11.2) lists.erl:1354: :lists.mapfoldl/3
    (elixir 1.10.1) lib/kernel/typespec.ex:229: Kernel.Typespec.translate_typespecs_for_module/2
    (elixir 1.10.1) src/elixir_erl_compiler.erl:12: anonymous fn/3 in :elixir_erl_compiler.spawn/2

Paste that same code in an iex session with Elixir 1.9.1 (erlang 22.1.3, Ecto 3.1.7), and it compiles:
{:module, MyApp.User,
 <<70, 79, 82, 49, 0, 0, 15, 84, 66, 69, 65, 77, 65, 116, 85, 56, 0, 0, 1, 248,
   0, 0, 0, 51, 17, 69, 108, 105, 120, 105, 114, 46, 77, 121, 65, 112, 112, 46,
   85, 115, 101, 114, 8, 95, 95, 105, 110, ...>>, {:changeset, 2}}

Expected behavior
I expect to be able to use schemas in Elixir 1.10 like I used them in 1.9. Again, this may be an issue with how Elixir changes something in Kernel, but since I do define types in the schema definition, I do not expect to have to define them again (i.e. @type t :: %__MODULE__{...).

Hi @davelively14!
Ecto does not define typespecs for you (and it never has). So the code above did not ever work, it is just that Elixir v1.10 started to error if you point to a typespec in the same module that does not exist. You have to define @type t :: %User{} yourself, preferably with proper typespecs inside. :)


[Dependency] Update mb.py

MeowerBot.py has been updated to 2.4.4

dependabot moment

Updated in https://github.com/MeowerBots/MeowyMod/commit/eb46d4e32479619b93f6537439ad34dcdc400399, closing.


Added python book in Ukrainian

What does this PR do?
Add resource(s)
For resources
Description
Why is this valuable (or not)?
This is translation of python documentation to Ukrainian language
How do we know it's really free?
Original (http://docs.python.org/tut/tut.html) is free and this translation is available for free as well
For book lists, is it a book? For course lists, is it a course? etc.
This is more like a book - description of Python language and how to use it.
Checklist:

[x] Read our contributing guidelines.
[x] Search for duplicates.
[x] Include author(s) and platform where appropriate.
[x] Put lists in alphabetical order, correct spacing.
[x] Add needed indications (PDF, access notes, under construction).
[x] Used an informative name for this pull request.

Follow-up

Check the status of GitHub Actions and resolve any reported warnings!

@eshellman should anything else be addressed or this can be merged now?

Thanks, and welcome to free-programming-books!


Admin interface to edit chart of accounts

Part of https://github.com/opencollective/opencollective/issues/7028
In the Host Workspace, add a new “Accounting” entry in the "Fiscal Host Settings". The only category for now will be “Chart of accounts”, to let host admins edit their chart of accounts.

Demo:
https://github.com/opencollective/opencollective/assets/1556356/f0bf18e7-e00b-497e-b04a-a5d234bc2810
cc @Memo-Es

@Betree
https://www.loom.com/share/1f412c31f45b4ee6b19ba25bf50f9f2d?sid=a1204d5f-9f99-489e-85cc-85912e23be95
Figma file

@Memo-Es This issue will be resolved with https://github.com/opencollective/opencollective-frontend/pull/9467, we'll track the UI improvements in https://github.com/opencollective/opencollective/issues/7062


What is extensions_enum.inc ?

We are using shaderc as dependency and SPIRV-Tools is shaderc's dependency. I'm trying to "merge" source of SPIRV-Tools into out project however i encountered a problem with aforementioned extensions_enum.inc file. What is it? I can't find it anywhere. I assumed it has to be generated during build, but I can't even find anything about this in SPIRV-Tools' build scripts. Can you help me out somehow, please?

The file is mentioned here, and is used here.  It is generated from the grammar file in spriv-headers, and it contains a list of all of the extensions found in the grammar appropriately named to fit the coding style.  Hope that helps.

Yeah, I found out it's generated by python script in util directory. However I've abandoned the idea and we'll be using SPIRV-Tools as external dependency (and not putting it directly into our build system).
Thanks for help, I'm closing.


Fix #936: set url-current-object for modified url-open-stream function in emacs 27.0.50

This PR fixes the Request failed: ((wrong-type-argument url nil)) error in emacs 27.0.50 by setting the url-current-object.

Thanks, merged.

Thanks!


The Source is not apearing to me

Look!

Did this work for you?

NOW WORKS!!!

Thanks

v0.2.0 doesn't seem to work on Linux (Pop! OS 21.10)


Add .NET Core fsc to  FSharp.Compiler.Tools package

the FSharp.Compiler.Tools should include a framework depended deployment of fsc as netcoreapp1.0
That will help run the fsc xplat having an installed dotnet sdk, just as dotnet /path/to/fsc.dll (it's not .exe, but .dll the netcoreapp)
file size is minimal, because a framework depended deployment doesnt contains the full netcore runtime.
Also like that, can be used by f# integration with .NET Core Sdk (FSharp.NET.Sdk) to acquire and run the compiler

[x] add signed assemblies from Microsoft.FSharp.Compiler.netcore package
[x] setup layout and props files so can fsc path can be discovered at runtime

Done


TagBot trigger issue

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

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

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

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

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

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

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


Support any iterable for incoming slices and vectors

Motivation
Right now, incoming slices and vectors are typed as T[] or UInt8Array and similar for primitives. This is unnecessarily restrictive.
Even today, all function taking slices and vectors already support array-like objects (anything with a length that can be indexed).  So just by changing the type definition, exported Rust functions would be easier to use on the JS side, but we can go even further.
Proposed Solution
Support arbitrary iterables in the JS glue code.
The basic idea is that we can support any iterable by just converting the input argument with Array.from, UInt8Array.from, etc. to the desired array type. Obviously, we don't always have to do this conversion. If the argument is already in the desired shape, we can skip the conversion. If the argument is in a different but similar-ish shape, we can also define a custom code path for it.
However, this also allows us to be more efficient than users could be. The prime example here is Set. Sets are not array-like, but they do have a size property, which fulfills essentially the same function. This means that we can skip the conversion to an array by having custom code path for Set.
To illustrate what I mean, here is how I would imagine the glue code for taking a Vec<Foo> where Foo is user-defined Rust struct with #[wasm_bindgen].
#[wasm_bindgen]
pub fn drop_it(array: Vec<Foo>) {}

function passArrayJsValueToWasm0(array, malloc) {
    // a single check for non-array types to keep the happy path fast
    if (!Array.isArray(array)) {
        if (array instanceof Set) {
            // Set is common enough to warrant special path to avoid the conversion
            const ptr = malloc(array.size * 4, 4) >>> 0;
            const mem = getDataViewMemory0();
            let i = 0;
            for (const item of array) {
                mem.setUint32(ptr + 4 * i++, addHeapObject(item), true);
            }
            WASM_VECTOR_LEN = array.size;
            return ptr;
        }

        // just convert to an array
        array = Array.from(array);
    }

    const ptr = malloc(array.length * 4, 4) >>> 0;
    const mem = getDataViewMemory0();
    for (let i = 0; i < array.length; i++) {
        mem.setUint32(ptr + 4 * i, addHeapObject(array[i]), true);
    }
    WASM_VECTOR_LEN = array.length;
    return ptr;
}

/**
 * @param {ArrayLike<Foo> | Iterable<Foo>} array
 */
export function drop_it(array) {
    const ptr0 = passArrayJsValueToWasm0(array, wasm.__wbindgen_malloc);
    const len0 = WASM_VECTOR_LEN;
    wasm.drop_it(ptr0, len0);
}

Please keep in mind that this is just PoC code that I threw together in 5 minutes.
Alternatives
The main alternative would to be only adjust the generated type definition to reflect what is actually accepted. This is already an improvement, but falls short of being convenient to use on the JS side.
Additional Context
I'm willing to make a PR for this.

This sounds perfectly fine to me and I'm happy to review a PR.
I would appreciate if you could link all the necessary resources as well, e.g. how ArrayLike is defined and such.

This sounds perfectly fine to me and I'm happy to review a PR.

Great, then I'll make one next week.

I would appreciate if you could link all the necessary resources as well, e.g. how ArrayLike is defined and such.

Sorry, I forgot about that.
ArrayLike<T> is essentially any object with a length property that can be indexed with numbers. So it's similar to readonly T[], but doesn't require any array methods (like e.g. map). I proposed ArrayLike<T>, because that's what the set method of typed arrays uses (please ignore the doc comment, the array doesn't just accept arrays and typed arrays; the type is exactly what the ECMAScript spec uses), and because our conversion for Rust structs doesn't need anything more.


outdated/problem with a link

The link
https://id.uvci.eu/DCC.Core.Types.schema.json#/$defs/person_name have either a ssl problem or is outdated.
for the attribute 'v'
"description": "Vaccination Group",
Additionally
https://id.uvci.eu/DCC.Types.schema.json#/$defs/test_entry
is a 404 error directly
for the attribute 't'
"description": "Test Group"
and the same for
https://id.uvci.eu/DCC.Types.schema.json#/$defs/recovery_entry
for the attribute 'r'
"description": "Recovery Group",

Please see https://github.com/ehn-dcc-development/ehn-dcc-schema/wiki/FAQ#schema-location

thank you for the quick answer.
What you link in your reply is right when using URI in a linked data context, but it is not valid when is the link of a definition of a $ref element in a schema.
This schema is simply wrong, it cannot validate any payload. (it is also true that it could be easily get fixed by changing the domain) but now what is in the repo is wrong. If you want me to make the PR I will be happy to do it.

The combined schema is fine and used for validation.
Improvements are welcomed: feel free to make a PR.

Certainly, the combined schema is right), so I would close the issue.
I have a doubt about the country attribute
"valueset-uri": "valuesets/country-2-codes.json"
I got that this is like an enumeration, shouldn't be an actual enumeration instead of an ad-hoc list of objects, that in fact, it does not validate anything?
I am rather sure that if you include the value 'XZ' in the 'co' attribute it will be validated while this is not a valid ISO-3166 code.

OK, I'll close it.
You're right about the value sets being underspecified through their JSON Schema. The value sets are defined in another repository but we haven't finished splitting that off properly yet, so there are some technical loose ends, and some duplication. The value sets are actually properly specified in official EU documents, so in practice it poses no problems.


⚠ Bofrost.de has degraded performance

In 4c5c508, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1128 ms

Resolved: Bofrost.de performance has improved in b79d7d0 after 8 minutes.


jsmn_parse_string() should set the token type to JSMN_STRING, not JSMN_PRIMITIVE

Bitbucket: https://bitbucket.org/zserge/jsmn/issue/1
Originally reported by: Mikael Eiman
Originally created at: 2011-03-14T13:27:30.402

I have a patch for this issue (I think it's the same I ran into). I'm new to bitbucket (and mercurial for that matter). I created a fork and added my patch: https://bitbucket.org/mbrossard/jsmn/changeset/095b38a2561c
I hope this helps,
--Mathias

Original comment by: Mathias Brossard

Sorry for a long delay, now it's fixed using your patch. Thanks!

Original comment by: Serge Zaitsev


remove original bitmap resource recycling

According to glide wiki, original bitmap resource recycling is done automatically.
https://github.com/bumptech/glide/wiki/Transformations#bitmap-re-use
I've been getting the following error when showing multiple images, but this pull request fixed it when I tried in my environment.
java.lang.IllegalArgumentException: Cannot draw recycled bitmaps
        at android.view.GLES20Canvas.drawBitmap(GLES20Canvas.java:772)
        at android.view.GLES20RecordingCanvas.drawBitmap(GLES20RecordingCanvas.java:105)
        at com.bumptech.glide.load.resource.bitmap.GlideBitmapDrawable.draw(GlideBitmapDrawable.java:101)
        at android.widget.ImageView.onDraw(ImageView.java:1028)
        at android.view.View.draw(View.java:14853)

@yqritc
Hey.
Thank you.
Be fixed in 1.0.4


Updated BIG-IP APM delegation account

File 1: f5-big-ip-kerberos-advanced.md
Changes made:

Revised the following sections of the document:

Configure Active Directory Kerberos constrained delegation (Title from another document for the same section: Active Directory KCD configurations)

Create a BIG-IP APM delegation account
Configure BIG-IP and the target application in the same domain
Configure BIG-IP and the target application in different domains
Changed from AskF5 to MyF5

Following Microsoft documentation links are affected by the above-specified changes:

https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/f5-big-ip-kerberoseasy- button#create-a-big-ip-apm-delegation-account
https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/f5-big-ip-kerberosadvanced# configure-active-directory-kerberos-constrained-delegation

File 2: f5-big-ip-kerberos-easy-button.md
Changes made:

Revised the following sections of the document:

Active Directory KCD configurations (Other title: Configure Active Directory Kerberos constrained delegation)
Create a BIG-IP APM delegation account
Configure BIG-IP and the target application in the same domain
Configure BIG-IP and the target application in different domains

Corrected the redirect links at the bottom of the document:

Changed from AskF5 to MyF5
Modified the Devcentral document link to https://community.f5.com/t5/codeshare/apm-variable-assign-examples/ta-p/287962

Following Microsoft documentation links are affected by the above specified changes:

https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/f5-big-ip-kerberos-easy-button#create-a-big-ip-apm-delegation-account
https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/f5-big-ip-kerberos-advanced#configure-active-directory-kerberos-constrained-delegation

@Gargi-Sinha
Can you review the proposed changes? Note that the validation warnings must be resolved before merging.
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

After we fix the validation errors, should we have to raise another pull request?

Hi @YGopichand - You'll want to resolve the warnings in this PR. After this PR passes validation and the author reviews your proposed changes, we can merge. Thanks!

Hi @YGopichand - You'll want to resolve the warnings in this PR. After this PR passes validation and the author reviews and approves your proposed changes, we can merge. Thanks!

"Thanks for the response. I have just fixed all the validation errors and committed the changes on my branch. Now, should I need to Fork and submit another pull request? or, are you able to re-run the checks after I just committed the changes. Please suggest the next steps after committing the changes made"

Hi @Court72 , Thanks for sharing the next steps. That's helpful. Looks like the latest validation checks are successful.
Hi @Gargi-Sinha , Request you to please proceed with the review and merge the proposed changes.
Thanks,
Gopi

#sign-off

#closed


[BEAM-79] Merge branch 'master' into gearpump_runner

Be sure to do all of the following to help us incorporate your contribution
quickly and easily:

[x] Make sure the PR title is formatted like:
[BEAM-<Jira issue #>] Description of pull request
[x] Make sure tests pass via mvn clean verify. (Even better, enable
Travis-CI on your fork and ensure the whole test matrix passes).
[x] Replace <Jira issue #> in the title with the actual Jira issue
number, if there is one.
[x] If this contribution is large, please file an Apache
Individual Contributor License Agreement.

merge master into gearpump-runner branch and also follow up recent changes on integration-tests and package-info

R: @jbonofre

@jbonofre connecting issue on traivs ?

I'm checking, but it seems so. I will trigger a new run for this PR.

@jbonofre have we got another run? I'm worried that the branch is left behind with 0.2.0-incubating released

Hi Manu. It looks an temporary issue with travis as the build works fine. Do you want I rebase on master ?

Is that possible ? I've also added commits for package-info and integration-test.

@jbonofre @kennknowles @dhalperi rebased on recent master. Not sure what is going wrong with the travis test

I'm not certain what is going on with Travis, but you definitely will want to update runners/gearpump/pom.xml to version 0.3.0-incubating. I'll try that out, too, and see if it resolves things.

A new rebase is needed for new version. I plan to do it asap.

I forked it and updated the version. It looks like it is passing: https://travis-ci.org/kennknowles/incubator-beam/builds/151282293.
I've opened manuzhang#1 which bumps the version on this branch, or you could just do it yourself.

@kennknowles updated but hit by downloading timeout again 😞

@kennknowles @jbonofre @dhalperi merged with recent master. Previous DoFn has been replaced with OldDoFn and support for new DoFn will be added later.

Guys, can we advance with this PR ?

I will be back from vacation Wednesday. I will work on it then.

guys, any updates ?

Yes, I rebased and tested. I noted some stuff to fix. I will comment today.

@manuzhang would you be available on Slack or Hangout ? I would like to discuss a couple of topics with you. Thanks !

The tests are green. Are there any outstanding issues, or are you ready to merge it in? Since it is a feature branch, presumably you can just roll forwards addressing any issues.

I plan to discuss with Manu about some topics tomorrow. I will do the merge. Thanks !

I discussed with Manu about couple of topics:

support of some IO features (not yet implements, it's on the TODO)
the README.md could be enhanced
the translation of DoFn is based on Gearpump FlatMapFunction which matches well
examples package and code directly in the runner (I would keep it like this for now and remove later)

I also tested the gearpump runner with the last gearpump incubating release with simple pipelines.
I also checked:

checkstyle is OK
headers are OK

@kennknowles I'm proposing to merge this runner on master. It would give more visibility and would allow people to experiment and provide feedback. If you agree, I will do more than happy to do the merge  ;)

That's a different discussion for the mailing list, where we have discussed criteria a bit. This PR is merging the other way, so that the gearpump-runner branch is caught up to master a bit.

I have shuffled the commits for readability and pushed the changes from this PR into gearpump-runner. I think you'll need to close this PR manually due to the way the asfgit bot operates.
I recommend merging master into gearpump-runner as frequently as possible so that it is almost always a pretty small update.

Fully agree. It's the plan and what I did. I think we have to move forward quickly to merge gearpump runner on master. It would give more visibility.

Thanks for both of you


Port GC changes from coreclr - 4

This port continues https://github.com/dotnet/corert/pull/7342
Porting strategy: extracting patches via format-patch from coreclr, adjusting paths, then am them on corert.
Glossary:

already merged: change already exists in corert
gc only port: change only affected the gc directory and patch applied with no conflicts
manual port: change applied with custom changes
omitted changes: contains changes to files that do not exists in corert and were discarded

Changes since last commit:

https://github.com/dotnet/coreclr/commit/41617fee235d22d9e6dc1fa31548de63637551fa (manual port)
https://github.com/dotnet/coreclr/commit/be8504bd8a63962c84567990f0b84019f299166c (manual port)
https://github.com/dotnet/coreclr/commit/7ba3cc8174dec2626a403f5ccd35c79a3bf6cf77 (manual port)
https://github.com/dotnet/coreclr/commit/e17f40a186c294f977e336cab049d9026cf40c78 (manual port)
https://github.com/dotnet/coreclr/commit/273e63414deccefd1ad048062e4d1ebfe5e5eb50 (manual port)
https://github.com/dotnet/coreclr/commit/f9d0333d8955c11a2e8f495f0a12d6384fb95541 (gc only port)
https://github.com/dotnet/coreclr/commit/7721f89f517f09f90d46a1078f0d26caf3b310c0 (manual port, omitted changes)
https://github.com/dotnet/coreclr/commit/447521434ab80ea97a42108a429e3773e71f7c66 (gc only port, omitted changes)
https://github.com/dotnet/coreclr/commit/ea55c4a25945d8ccb39d686b89f1fa729b4ebe23 (gc only port)
https://github.com/dotnet/coreclr/commit/2dfc74df1f9fe238eb2ec25c4764b8b65432b010 (manual port)
https://github.com/dotnet/coreclr/commit/09b7f0a0f44798108a33d7e698420f147c45461b (manual port)

Points of interest:
Some of the commits moved features to the runtime that were disabled in the GC with #ifndef FEATURE_REDHAWK, i've transplanted the equivalent to gcrhenv.cpp, do tell if you rather wish to remove it.

LGTM otherwise. Thanks!

Do you have a hint for me why it's apparently only failing CI on windows and what this means?
Runtime.ServerGC.lib(gcrhenv.obj) : error LNK2001: unresolved external symbol g_pGCHandleTable [corert\tests\src\Simple\BasicThreading\BasicThreading.csproj]
Runtime.ServerGC.lib(HandleTableHelpers.obj) : error LNK2001: unresolved external symbol g_pGCHandleTable [corert\tests\src\Simple\BasicThreading\BasicThreading.csproj]
    Hint on symbols that are defined and could potentially match:
      "class IGCHandleTable * g_pGCHandleTable" (?g_pGCHandleTable@@3PEAVIGCHandleTable@@EA)

Definition: https://github.com/Suchiman/corert/blob/d425b7a7a796e2df4d0e029e7905156930a66078/src/Native/Runtime/gcheaputilities.cpp#L27
Declaration: https://github.com/dotnet/corert/pull/7358/files#diff-366daac881206f11f6a6b65153920cb2R14


[jsfm] supported return value from native

fixed #1677

callNativeModule(instanceId, module, method, arguments, options)
callNativeComponent(instanceId,  componentRef,  method,  arguments, options)

After discussion, this feature has been implemented in jsfm-feature-0.19, and have few difference with this code.
This PR will be closed.


How can I ignore a package that is not in the Debian apt cache?

I am trying to package python-sonic (which depends on python-osc) for use on pi-topOS.
python-osc isn't available on Debian, and so python-sonic fails to build - it can't find the package dependency.
Given that we intend to provide both of these packages in our apt repository, we would like an easy way to override this behaviour and continue with the build. Have I missed something or is this a feature to be added?
It would be great to have a command-line argument to override this behaviour.

Turns out the wheel for this was needed at build time. This could be better documented, but I accept that the software is technically working in a reasonable way.


When creating Organizations, clean out address objects where all properties, or all properties except "isPrimary", are empty

I think we are doing this for Users already? We should be able to, and should strive for, handling this the same way for Users and Organizations.

The only somewhat required property for addresses -- in that the UI will not let you edit the object without it -- is that at least one address has to be primary.


Don't try to read files that have been moved/renamed.

LGTM.

Unrelated failures (and they are known flakes).


#2116 - Request an Offering Change - E2E test

Created below E2E tests

To test the study overlap, we have to BYPASS_APPLICATION_SUBMIT_VALIDATIONS to false.

Great job with scenarios. Added few minor comments but have one question https://github.com/bcgov/SIMS/pull/2176#discussion_r1291720093


Remove xregexp (polyfill) & replace urlify (Django port) vendor library

With #11161 merged & #11157 coming (modeladmin removal), we can now start to deprecate the global window.URLify and remove the legacy Regex polyfill (62KB of JS no longer needed).
Overview

Replace URLify vendor with npm parameterize a mostly equivalent port of Django's URLify function.
Add legacy support for window.URLify with allowUnicode as a param.
Add release notes details for both window.URLify (deprecated) & window.XRegExp (removed).
Update JSDoc for the urlify wrapper util.
Gets us a step closer to finishing #2936 (Stop importing _editor_js.html everywhere).

Implementation details
Mostly for my own reference but could be useful for those reviewing this PR.
Usage of parameterize
This NPM package is an exact port of the mapping from the Django URLify util, except for the allow_unicode param. I have done a 1:1 comparison of the file in Git to confirm. This NPM package also does not use the Regex polyfill which is no longer required for all browsers we support.

https://github.com/fyalavuz/node-parameterize/blob/master/parameterize.js
https://github.com/django/django/blob/main/django/contrib/admin/static/admin/js/urlify.js
https://github.com/wagtail/wagtail/blob/main/wagtail/admin/static_src/wagtailadmin/js/vendor/urlify.js

About URLify allow_unicode
The Slug widget usage of the urlify does not use the Django port URLify allow_unicode, instead our allowUnicodeValues option is only passed into slugify. The history here seems complex but basically we only use the urlify variant on the initial load for validation of a saved slug to the slug loaded into the UI.
This means that the Wagtail admin SlugInput widget never used this.
However, the allow_unicode value on fields were used for modeladmin prepopulate JS to pass into the global util in this case.
This behaviour is subtly different to how Page/Snippet slug fields works, so I have opted to support this with a legacy window.URLify for the time being. This way, even though modeladmin is removed, we should not have to add any more JS until we fully remove this global.

See https://github.com/wagtail/rfcs/blob/main/text/085-snippets-parity-modeladmin.md#other-attributes ModelAdmin.prepopulated_fields for more details on our RFC plan for prepopulated fields.
https://docs.wagtail.org/en/stable/reference/contrib/modeladmin/create_edit_delete_views.html#id10 - We do not explicitly call out support for allow_unicode on slug field usage but it is something we should keep supporting with a deprecation process.

About 'stopwords'
Our comments for urlify indicated that this function removes stopwords, this is not true and as far as I can tell has not been the case for many years. It only cleans the string and replaces unicode like characters with their mapped equivalent (e.g. 'À' -> 'A').
See https://code.djangoproject.com/ticket/11157 & https://github.com/wagtail/wagtail/pull/6410 & https://github.com/wagtail/wagtail/pull/4884
As such, I have removed this reference in the comments.
Testing

Check that window.URLify is a valid global function & accepts three args.
Check that the page edit (new and existing pages) correctly changes the slug field when it's interacted with or changed when in sync and NOT published.
Do a manual comparison of the parameterize and the current Wagtail admin vendor urlify if needed.
See detailed testing for slugs on https://github.com/wagtail/wagtail/pull/10568 if needed.

Checks

[X] Do the tests still pass?
[X] Does the code comply with the style guide?
[X] For front-end changes: Did you test on all of Wagtail’s supported environments?
[X] For new features: Has the documentation been updated accordingly?

Need to rebase.

Ci failure appears to be unrelated to this change.

Just rebased

Rebased

Note to self. Move release notes to 6.1

@laymonage I did explore keeping the urlify.js but that means we also have to keep the regexp implementation it uses I think, which also relies on jQuery.
I can go through this again but I did try to find a way to use Django's code also but it still has an old custom implementation of regex.
Hence why I found a direct port of it to modern -ish JS on npm.
Would you be ok if I copied their implication into our package code, use it directly that way? I can add a reference to the top of the file but this is basically the same as using it via an NPM package but maybe it's easier to maintain.

Had another look and I really think we should avoid putting all this code in our codebase, the parameterize package is a direct copy of what Django has in it's code.
Happy to do this if you really think we should @laymonage but my understanding is that it's much easier and simpler to maintain if that code is brought in as a package.
There will be over 200 lines of code that will continue to be 'our' responsibility to think about in our code, potentially even convert to TypeScript. We already have unit tests covering the 'result' of this package in our code so I just do not see the point.
Sorry to be a pain, thank you for your review, but just thought I would double check we really really want this in our own vendor code still.

@laymonage ok - you have good points, thanks for helping me understand better some of the nuanced differences and working with me on this.
I have now moved the urlify code to our own area of code instead of the external package.
Have a look and hopefully this is what you were thinking :)
I will update the description once you have had a chance to review, explaining the new changes.
Did some smoke testing also

Thanks, I'll give this another go next week.

@laymonage  let's give this another go.
I have taken a brand new look at this as a whole and made some further refinements.

Pulled out the long sets of character mapping to JSON, this will be easier to maintain and understand.
Split up the commits to be more granular.
Removed our urlify wrapper of the Django URLify port and kept the urlify code to only be the urlify part, the slugify 'fallback' will now happen only in the SlugController code. This keeps the functions simpler, doing ONE thing only.
In our port of the Django urlify I have opted for (as suggested) a much simpler set of code, no classes and avoiding the linting issues. Overall it's much simpler to follow & I hope this is OK.

As noted, there is a bug that has been introduced historically in 4.0, I will not fix this in this PR and instead look at it in isolation.
I hope this makes sense, if you feel this is too much change and we should rethink this completely, I am happy to close this PR and just address this later. Hopefully though this is closer to what we want and worth the benefit of a much more maintainable/testable code with a smaller bundle size.


Root folder should not be empty string

in StorageDriver
   public function getRootLevelFolder()
    {
        return '';
    }

In localdriver however it's return '/';

similar here: https://github.com/andersundsehr/aus_driver_amazon_s3/blob/master/Classes/Driver/AmazonS3Driver.php
Changing this should come with a migration wizard as in sys_file->Identifier column doesn't have a starting '/' at the beginning.


ciao: Install ciao from github sources

Add a new variable ciao_dev to ciao-common
When set to True, it will build ciao from the master branch
When set to False (default) it will install ciao from the OS
packages

Fixes #21
Signed-off-by: Alberto Murillo<EMAIL_ADDRESS>

it LGTM, just a question, where should we document how to use this feature? how to setup the env for this?, this solution would be planned for cluster-based development, so, we need to document it somewhere.

@obedmr I think that the current documentation provides an example on how to setup CIAO in a cluster, for more customization, the user should refer to each role README.md file
The use of ciao_dev is already documented in
https://github.com/clearlinux/clear-config-management/tree/github/roles/ciao-common


gazebo_ros2_control build failures on Rolling

ROS distro: Rolling
OS version: Ubuntu 22.04 (Jammy)
gazebo_ros2_control version: 0.4.0-1
Link to failing build: https://build.ros2.org/view/Rbin_uJ64/job/Rbin_uJ64__gazebo_ros2_control__ubuntu_jammy_amd64__binary/100/
Blocked packages

gazebo_ros2_control_demos

Build log excerpt:
00:07:19.450 /usr/lib/ccache/c++ -DBOOST_ALL_NO_LIB -DBOOST_ATOMIC_DYN_LINK -DBOOST_DATE_TIME_DYN_LINK -DBOOST_FILESYSTEM_DYN_LINK -DBOOST_IOSTREAMS_DYN_LINK -DBOOST_PROGRAM_OPTIONS_DYN_LINK -DBOOST_REGEX_DYN_LINK -DBOOST_SYSTEM_DYN_LINK -DBOOST_TEST_DYN_LINK -DBOOST_THREAD_DYN_LINK -DDEFAULT_RMW_IMPLEMENTATION=rmw_fastrtps_cpp -DLIBBULLET_VERSION=3.05 -DLIBBULLET_VERSION_GT_282 -DRCUTILS_ENABLE_FAULT_INJECTION -Dgazebo_ros2_control_EXPORTS -I/tmp/binarydeb/ros-rolling-gazebo-ros2-control-0.4.0/include -I/opt/ros/rolling/include -I/opt/ros/rolling/include/rclcpp_lifecycle -I/opt/ros/rolling/include/rclcpp_action -I/usr/include/gazebo-11 -I/usr/include/bullet -I/usr/include/sdformat-9.7 -I/usr/include/OGRE -I/usr/include/OGRE/Terrain -I/usr/include/OGRE/Paging -isystem /opt/ros/rolling/include/angles -isystem /opt/ros/rolling/include/pluginlib -isystem /opt/ros/rolling/include/rclcpp -isystem /opt/ros/rolling/include/ament_index_cpp -isystem /opt/ros/rolling/include/control_msgs -isystem /opt/ros/rolling/include/lifecycle_msgs -isystem /opt/ros/rolling/include/rcpputils -isystem /opt/ros/rolling/include/rcutils -isystem /opt/ros/rolling/include/sensor_msgs -isystem /opt/ros/rolling/include/controller_manager_msgs -isystem /opt/ros/rolling/include/diagnostic_msgs -isystem /opt/ros/rolling/include/std_msgs -isystem /usr/include/simbody -isystem /usr/include/ignition/math6 -isystem /usr/include/ignition/transport8 -isystem /usr/include/ignition/msgs5 -isystem /usr/include/ignition/common3 -isystem /usr/include/ignition/fuel_tools4 -isystem /opt/ros/rolling/include/class_loader -isystem /opt/ros/rolling/include/libstatistics_collector -isystem /opt/ros/rolling/include/builtin_interfaces -isystem /opt/ros/rolling/include/rosidl_runtime_c -isystem /opt/ros/rolling/include/rosidl_typesupport_interface -isystem /opt/ros/rolling/include/fastcdr -isystem /opt/ros/rolling/include/rosidl_runtime_cpp -isystem /opt/ros/rolling/include/rosidl_typesupport_fastrtps_cpp -isystem /opt/ros/rolling/include/rmw -isystem /opt/ros/rolling/include/rosidl_typesupport_fastrtps_c -isystem /opt/ros/rolling/include/rosidl_typesupport_introspection_c -isystem /opt/ros/rolling/include/rosidl_typesupport_introspection_cpp -isystem /opt/ros/rolling/include/rcl -isystem /opt/ros/rolling/include/rcl_interfaces -isystem /opt/ros/rolling/include/rcl_logging_interface -isystem /opt/ros/rolling/include/rcl_yaml_param_parser -isystem /opt/ros/rolling/include/libyaml_vendor -isystem /opt/ros/rolling/include/tracetools -isystem /opt/ros/rolling/include/statistics_msgs -isystem /opt/ros/rolling/include/rosgraph_msgs -isystem /opt/ros/rolling/include/rosidl_typesupport_cpp -isystem /opt/ros/rolling/include/rosidl_typesupport_c -isystem /opt/ros/rolling/include/rcl_action -isystem /opt/ros/rolling/include/action_msgs -isystem /opt/ros/rolling/include/unique_identifier_msgs -isystem /usr/include/eigen3 -isystem /usr/include/sdformat-9.7/sdf/.. -isystem /usr/include/ignition/cmake2 -isystem /usr/include/uuid -isystem /opt/ros/rolling/include/geometry_msgs -isystem /opt/ros/rolling/include/trajectory_msgs -isystem /opt/ros/rolling/include/rcl_lifecycle -g -O2 -ffile-prefix-map=/tmp/binarydeb/ros-rolling-gazebo-ros2-control-0.4.0=. -flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2  -fPIC -Wall -Wextra -Wconversion -Wno-sign-conversion -Wpedantic -Wnon-virtual-dtor -Woverloaded-virtual -I/usr/include/uuid -MD -MT CMakeFiles/gazebo_ros2_control.dir/src/gazebo_ros2_control_plugin.cpp.o -MF CMakeFiles/gazebo_ros2_control.dir/src/gazebo_ros2_control_plugin.cpp.o.d -o CMakeFiles/gazebo_ros2_control.dir/src/gazebo_ros2_control_plugin.cpp.o -c /tmp/binarydeb/ros-rolling-gazebo-ros2-control-0.4.0/src/gazebo_ros2_control_plugin.cpp
00:07:44.577 In file included from /opt/ros/rolling/include/controller_manager/controller_manager.hpp:43,
00:07:44.577                  from /tmp/binarydeb/ros-rolling-gazebo-ros2-control-0.4.0/include/gazebo_ros2_control/gazebo_ros2_control_plugin.hpp:42,
00:07:44.577                  from /tmp/binarydeb/ros-rolling-gazebo-ros2-control-0.4.0/src/gazebo_ros2_control_plugin.cpp:42:
00:07:44.577 /opt/ros/rolling/include/diagnostic_updater/diagnostic_updater.hpp: In constructor ‘diagnostic_updater::Updater::Updater(std::shared_ptr<rclcpp::node_interfaces::NodeBaseInterface>, std::shared_ptr<rclcpp::node_interfaces::NodeClockInterface>, std::shared_ptr<rclcpp::node_interfaces::NodeLoggingInterface>, std::shared_ptr<rclcpp::node_interfaces::NodeParametersInterface>, std::shared_ptr<rclcpp::node_interfaces::NodeTimersInterface>, std::shared_ptr<rclcpp::node_interfaces::NodeTopicsInterface>, double)’:
00:07:44.577 /opt/ros/rolling/include/diagnostic_updater/diagnostic_updater.hpp:389:55: warning: conversion from ‘double’ to ‘rcl_duration_value_t’ {aka ‘long int’} may change value [-Wfloat-conversion]
00:07:44.577   389 |     period_(rclcpp::Duration::from_nanoseconds(period * 1e9)),
00:07:44.577       |                                                ~~~~~~~^~~~~
00:07:44.577 /opt/ros/rolling/include/diagnostic_updater/diagnostic_updater.hpp:399:57: warning: conversion from ‘double’ to ‘rcl_duration_value_t’ {aka ‘long int’} may change value [-Wfloat-conversion]
00:07:44.577   399 |     period_ = rclcpp::Duration::from_nanoseconds(period * 1e9);
00:07:44.577       |                                                  ~~~~~~~^~~~~
00:07:44.577 /opt/ros/rolling/include/diagnostic_updater/diagnostic_updater.hpp: In member function ‘void diagnostic_updater::Updater::setPeriod(double)’:
00:07:44.577 /opt/ros/rolling/include/diagnostic_updater/diagnostic_updater.hpp:423:57: warning: conversion from ‘double’ to ‘rcl_duration_value_t’ {aka ‘long int’} may change value [-Wfloat-conversion]
00:07:44.577   423 |     setPeriod(rclcpp::Duration::from_nanoseconds(period * 1e9));
00:07:44.577       |                                                  ~~~~~~~^~~~~
00:07:44.577 /opt/ros/rolling/include/diagnostic_updater/diagnostic_updater.hpp: In member function ‘void diagnostic_updater::Updater::broadcast(int, std::string)’:
00:07:44.577 /opt/ros/rolling/include/diagnostic_updater/diagnostic_updater.hpp:456:22: warning: conversion from ‘int’ to ‘unsigned char’ may change value [-Wconversion]
00:07:44.577   456 |       status.summary(lvl, msg);
00:07:44.577       |                      ^~~
00:07:44.577 /tmp/binarydeb/ros-rolling-gazebo-ros2-control-0.4.0/src/gazebo_ros2_control_plugin.cpp: In member function ‘virtual void gazebo_ros2_control::GazeboRosControlPlugin::Load(gazebo::physics::ModelPtr, sdf::v9::ElementPtr)’:
00:07:44.577 /tmp/binarydeb/ros-rolling-gazebo-ros2-control-0.4.0/src/gazebo_ros2_control_plugin.cpp:288:67: error: ‘__gnu_cxx::__alloc_traits<std::allocator<hardware_interface::HardwareInfo>, hardware_interface::HardwareInfo>::value_type’ {aka ‘struct hardware_interface::HardwareInfo’} has no member named ‘hardware_class_type’
00:07:44.577   288 |     std::string robot_hw_sim_type_str_ = control_hardware_info[i].hardware_class_type;
00:07:44.577       |                                                                   ^~~~~~~~~~~~~~~~~~~

This is fixed in #169. We have to trigger a new release. @bmagyar can you do that?

closing for now.


No targets in Prometheus

What did you do?
Added 21 targets on my prometheus.yml file
What did you expect to see?
All of my pre-configured targets
What did you see instead? Under which circumstances?
I can add 20 targets and everything is ok, but once i add one more and all of them but one dissapear. If i go to Service Discovery i can find all of them, but not in "Targets" and every metric on grafana gets lost untill deleting that last one on prometheus.yml file, i tried to change the scrape time interval thinking it was not enough but remains the same.

Here are the Logs. i don really know if this is enough, but this part of them took my attention
ts=2023-12-18T23:00:03.263Z caller=db.go:1619 level=info component=tsdb msg="Deleting obsolete block" block=01HHYQ1VYP6SGW9RYSCV7ZS609
ts=2023-12-18T23:00:03.266Z caller=db.go:1619 level=info component=tsdb msg="Deleting obsolete block" block=01HHZ4SAF4NFW6GS3R221F24P6
ts=2023-12-18T23:00:03.270Z caller=db.go:1619 level=info component=tsdb msg="Deleting obsolete block" block=01HHYXXK6QS560GHWPSVJTYCJ2
ts=2023-12-18T23:37:52.735Z caller=main.go:859 level=warn msg="Received SIGTERM, exiting gracefully..."
ts=2023-12-18T23:37:52.735Z caller=main.go:883 level=info msg="Stopping scrape discovery manager..."
ts=2023-12-18T23:37:52.735Z caller=main.go:897 level=info msg="Stopping notify discovery manager..."
ts=2023-12-18T23:37:52.735Z caller=manager.go:1026 level=info component="rule manager" msg="Stopping rule manager..."
ts=2023-12-18T23:37:52.735Z caller=manager.go:1036 level=info component="rule manager" msg="Rule manager stopped"
ts=2023-12-18T23:37:52.735Z caller=main.go:934 level=info msg="Stopping scrape manager..."
ts=2023-12-18T23:37:52.735Z caller=main.go:893 level=info msg="Notify discovery manager stopped"
ts=2023-12-18T23:37:52.736Z caller=main.go:879 level=info msg="Scrape discovery manager stopped"
ts=2023-12-18T23:37:52.737Z caller=main.go:926 level=info msg="Scrape manager stopped"
ts=2023-12-18T23:37:52.802Z caller=notifier.go:604 level=info component=notifier msg="Stopping notification manager..."
ts=2023-12-18T23:37:52.802Z caller=main.go:1155 level=info msg="Notifier manager stopped"
ts=2023-12-18T23:37:52.802Z caller=main.go:1167 level=info msg="See you next time!"
ts=2023-12-18T23:37:59.095Z caller=main.go:539 level=info msg="No time or size retention was set so using the default time retention" duration=15d
ts=2023-12-18T23:37:59.095Z caller=main.go:583 level=info msg="Starting Prometheus Server" mode=server version="(version=2.48.0, branch=HEAD, revision=6d80b30990bc297d95b5c844e118c4011fad8054)"
ts=2023-12-18T23:37:59.095Z caller=main.go:588 level=info build_context="(go=go1.21.4, platform=linux/amd64, user=root@26117804242c, date=20231116-04:35:21, tags=netgo,builtinassets,stringlabels)"
ts=2023-12-18T23:37:59.095Z caller=main.go:589 level=info host_details="(Linux 5.14.0-284.11.1.el9_2.x86_64 #1 SMP PREEMPT_DYNAMIC Tue May 9 17:09:15 UTC 2023 x86_64 56be1daa1720 (none))"
ts=2023-12-18T23:37:59.095Z caller=main.go:590 level=info fd_limits="(soft=1073741816, hard=1073741816)"
ts=2023-12-18T23:37:59.095Z caller=main.go:591 level=info vm_limits="(soft=unlimited, hard=unlimited)"
ts=2023-12-18T23:37:59.097Z caller=web.go:566 level=info component=web msg="Start listening for connections" address=<IP_ADDRESS>:9090
ts=2023-12-18T23:37:59.097Z caller=main.go:1024 level=info msg="Starting TSDB ..."
ts=2023-12-18T23:37:59.098Z caller=repair.go:56 level=info component=tsdb msg="Found healthy block" mint=1701814554112 maxt=1701842400000 ulid=01HGZCJ0CMSE9NCSGZ6DWGF8B5
ts=2023-12-18T23:37:59.098Z caller=repair.go:56 level=info component=tsdb msg="Found healthy block" mint=1701842403342 maxt=1701907200000 ulid=01HH1ABHD5EY6N6Y2YDMTQX67Y
ts=2023-12-18T23:37:59.098Z caller=repair.go:56 level=info component=tsdb msg="Found healthy block" mint=1701907203340 maxt=1701972000000 ulid=01HH3852VFQYH9P9NSE8QTFXFZ
ts=2023-12-18T23:37:59.098Z caller=repair.go:56 level=info component=tsdb msg="Found healthy block" mint=1701972003340 maxt=1702036800000 ulid=01HH55YM5W3S9470QYKF1M7GRK
ts=2023-12-18T23:37:59.098Z caller=repair.go:56 level=info component=tsdb msg="Found healthy block" mint=1702036803342 maxt=1702101600000 ulid=01HH73R563FWS1PKH2EHNQXB70
ts=2023-12-18T23:37:59.098Z caller=repair.go:56 level=info component=tsdb msg="Found healthy block" mint=1702101603342 maxt=1702166400000 ulid=01HH91HPEENFRQ60HVQP4FT98N
ts=2023-12-18T23:37:59.099Z caller=repair.go:56 level=info component=tsdb msg="Found healthy block" mint=1702166403342 maxt=1702231200000 ulid=01HHAZB7SZFC41M0FHM4HPWETH
ts=2023-12-18T23:37:59.099Z caller=repair.go:56 level=info component=tsdb msg="Found healthy block" mint=1702231203342 maxt=1702296000000 ulid=01HHCX4KJ0VE734YN639XQTTXX
ts=2023-12-18T23:37:59.099Z caller=tls_config.go:274 level=info component=web msg="Listening on" address=[::]:9090

It seems like there might be an issue with your Prometheus configuration. One thing that stands out is that you have repeated configurations for each job, specifically the static_configs block. Each job definition should have a single static_configs block with a list of targets.
For example, instead of having separate static_configs for each job, you should organize your configuration like this:
`scrape_configs:

job_name: prometheus
static_configs:

targets:

prometheus:9090

job_name: node_exporter
static_configs:

targets:

node_exporter:9100

job_name: SRV-Insurgentes
static_configs:

targets:

<IP_ADDRESS>:9182

... Same for other jobs`
Make sure to correct the structure for all jobs. Having multiple static_configs blocks at the same level.

I don't think there's any problem with the config.
I think it's a UI issue, adding that 21th target strangely triggers some sticky scrapePool filtering on the page like in https://github.com/prometheus/prometheus/issues/13413
I think we can close the issue in favor of the other one that contains more details. And maybe add your config there as a simpler way to reproduce the issue.

I added your config as a way to reproduce the issue https://github.com/prometheus/prometheus/issues/13413#issuecomment-2042091658
I'll close the issue, don't hesitate if there is sth else we should know about.


use orbit-db-store v3.1.0

https://github.com/orbitdb/orbit-db-store/pull/86#issuecomment-596030779
https://github.com/orbitdb/orbit-db/pull/767#issuecomment-596034217

Published to 1.8.0 :+1:


unable to run TPU using current kaggle environment

the code from https://www.kaggle.com/code/sgandhi99/whisper-jax-tpu which using 2023-04-04 environment is work, but not the code below using current environment
!apt update -qq
!apt install -qq ffmpeg -y
!pip install --upgrade pip
#!pip install -U "jax[tpu]" -f https://storage.googleapis.com/jax-releases/libtpu_releases.html
!pip install git+https://github.com/sanchit-gandhi/whisper-jax.git ipywidgets

error here but no error logs
from whisper_jax import FlaxWhisperPipline
import jax.numpy as jnp

# silent fail
pipeline = FlaxWhisperPipline("openai/whisper-large-v2", dtype=jnp.bfloat16, batch_size=16)

from jax.experimental.compilation_cache import compilation_cache as cc
cc.initialize_cache("./jax_cache")

outputs = pipeline('/kaggle/input/voice.wav', return_timestamps=True, language="id", task="transcribe")
#print(outputs["text"])
for sub in outputs["chunks"]:
    print(f'{sub["timestamp"][0]}-{sub["timestamp"][1]} : ')

nevermind, solved.