Stateless Row Conversion

Is your feature request related to a problem or challenge? Please describe what you are trying to do.

Currently row conversion is stateful, relying on a separate RowConverter to maintain this global state.
This has a number of drawbacks:

Prevents parallelizing row conversion across multiple threads
Complicates APIs which have to manage mutable access to a RowConverter - https://github.com/apache/arrow-datafusion/blob/cf229b82cb53f1d9f430a2fa4ff5191ba52e5cef/datafusion/core/src/physical_plan/sorts/stream.rs#L38
State accumulation can be problematic, necessitating workarounds like https://github.com/apache/arrow-datafusion/pull/7401
The dictionary interning logic is very expensive - https://github.com/apache/arrow-rs/pull/3831

Describe the solution you'd like

I would like to propose removing the dictionary preservation logic, instead always hydrating the dictionaries values when encoding. This in turn would allow simplifying the API to no longer have a notion of a stateful RowConverter.
This may represent a performance regression for dictionaries with small number of values. We should definitely quantify this, but it is my expectation that this will only occur for dictionaries with a very low number of values. It is currently the case that even arrays with low numbers of distinct values may contain non-trivial number of values as a result of the way dictionaries are handled by the various kernels and readers, and so I'm inclined to not weigh this very highly.
Describe alternatives you've considered

Additional context

I personally think this proposal is very compelling because using high cardinality dictionaries has caused us significant pain in IOx due to the memory accumulated in the row converters. We have several non trivial PRs to properly account for and try to avoid using dictionary encoding for these cases -- see https://github.com/apache/arrow-datafusion/pull/7130 and  https://github.com/apache/arrow-datafusion/pull/7401 for example
Also, a stateful row converter has caused other operations like https://github.com/apache/arrow-datafusion/pull/7379 from @wiedld become significantly more complicatated as it can't be shared between threads
Thus, in my mind the ideal outcome would be that we can remove the stateful row conversion and minimize the performance penalty for relatively low cardinality dictionaries.  I am hopeful that @tustvold 's ideas to make string encoding more efficient (e.g. https://github.com/apache/arrow-rs/issues/4812) could be part of this answer

The one case I can think of where a stafeful row converter is likely to have massive benefit is with low cardinality dictionaries that have very large individual values (e.g. 2MB strings for each entry). I have no idea how common that type of data is in practice.

label_issue.py automatically added labels {'arrow'} from #4819

label_issue.py automatically added labels {'arrow-flight'} from #4819


TelemetryConfigration.Active deprecated

TelemetryConfigration.Active is deprecated with ApplicationInsights SDK 2.11-beta1 as described here, so the first example under using config file
should maybe reflect that?
Could be done similar to how TelemetryProcessorChainBuilder is described here

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

ID: b189efce-ce4e-f8f8-ecf8-8803a18f9b65
Version Independent ID: aec54012-dae3-ce18-0f8c-30749c46a79c
Content: Azure Application Insights for Console Applications
Content Source: articles/azure-monitor/app/console.md
Service: application-insights
GitHub Login: @mrbullwinkle
Microsoft Alias: mbullwin

@eivinskr Thank you for your feedback. I will investigate and get back to your shortly.

@eivenskr TelemetryConfigration.Active is being deprecated for .NET Core only. As is noted in the doc,  using config files is not supported in .NET Core.
In the doc for .NET Core there is also a note that TelemetryConfiguration.Active is not supported for Core.
I will now proceed to close this thread. Please tag me if you need to discuss this further.

Ahh, I have two things I still find weird if you don't mind discussing it @SamaraSoucy-MSFT.

It was posted in the .NET Github repo for Application Insights, not the .NET Core Github repo.
After describing how to configure AppInsights for ASP.NET Core and Azure functions it says:

If you have other kind of application where you configure TelemetryConfiguration yourself - do not use TelemetryConfiguration.Active singleton

But as you mention, I don't get why that should be a problem if TelemetryConfiguration.Active is only being deprecated in .Net Core.

The Application Insights package is used in both Framework and Core. The .NET Core SDK has it as a dependency.
TelemetryConfiguration.Active is a backup for when you don't have dependency injection available. Think of it as a default implementation that can be used in simple scenarios. In the doc example, Active avoids the complexity of setting up DI in .NET Framework. DI is built into .NET Core so there is no need to deal with the issues that can come with the Active singleton.
If you are setting up the configuration somewhere else, like through DI, using Active creates a second instance of the configuration and can cause conflicts. This is exactly the problem that is happening in Core apps.

Thank you for clearing up the confusion!


Consumer API: Revoke a Relationship reactivation request

Readiness checklist

[X] I added/updated unit tests.
[ ] I added/updated integration tests.
[X] I ensured that the PR title is good enough for the changelog.
[X] I labeled the PR.

Description
Relationship reactivation can now be revoked via PUT /Relationships/{id}/Reactivate/Revoke endpoint, after which the status of the relationship remains Terminated and an appropriate RelationshipAuditLogEntry is created with reason RevocationOfReactivation. The RelationshipStatusChangedIntegrationEvent integration event is not triggered since the status of the Relationship doesn't change.

Summary by CodeRabbit

New Features

Introduced a new feature to revoke the reactivation of relationships, enhancing control over relationship statuses.
Added a new HTTP endpoint to manage the revocation of relationship reactivations.

Enhancements

Expanded support for 'Terminated' relationship status in data transfer objects.

Documentation

Updated audit log entries to include new reasons related to relationship status changes.

Bug Fixes

Implemented error handling for specific cases in relationship requests.

Tests

Added comprehensive tests for new functionalities related to revoking relationship reactivations.

@coderabbitai review

Reminder: we shouldn't merge this before the reactivation PR is merged.

@NikolaVetnic There are conflicts in this branch.


Upgrade codebase to Swift 1.2

Thanks for this!  Unfortunately I will not merge this until Travis gets their act together and updates to 1.2.

Okay, understandable! :smiley:

No, no, don't close this!  I will merge it, just not now.

I'll take you at your word that this builds.
:boat:

:smiley:


gitlab: 17.2.0 -> 17.2.1

Description of changes

https://gitlab.com/gitlab-org/gitlab/-/blob/v17.2.1-ee/CHANGELOG.md
https://about.gitlab.com/releases/2024/07/24/patch-release-gitlab-17-2-1-released/
Fixes CVE-2024-0231
Fixes CVE-2024-5067
Fixes CVE-2024-7057

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

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

@ofborg build nixosTests.gitlab

Result of nixpkgs-review pr 329872 run on x86_64-linux 1

5 packages built:

gitaly
gitlab
gitlab-ee
gitlab-pages
gitlab-workhorse

Reopening #323011

@ofborg build nixosTests.gitlab

Result of nixpkgs-review pr 329872 run on x86_64-linux 1

6 packages built:

gitaly
gitlab
gitlab-container-registry
gitlab-ee
gitlab-pages
gitlab-workhorse

nixpkgs-review happy, nixos x86_64. passthru.tests pass.

Cherry-picked and deployed on x86_64-linux, release-24.05 for local testing. Seems to work fine.


Add a context menu item to view the table designer mode from explore

Describe your feature request
Add "View structure/table/info" here (in explorer)

which would load the side bar from "Designer"

This has been implemented in #394


[Extensibiliy Bug] codeunit 481 "Check Dimensions" OnCheckDimValuePostingOnAfterCreateDimTableIDs - codeunit 408 DimensionManagement CheckDimValuePosting

The event OnCheckDimValuePostingOnAfterCreateDimTableIDs
[IntegrationEvent(false, false)]
    local procedure OnCheckDimValuePostingOnAfterCreateDimTableIDs(RecordVariant: Variant; var TableIDArr: array[10] of Integer; var NumberArr: array[10] of Code[20])
    begin
    end;

and procedure CheckDimValuePosting in codeunit 408 DimensionManagement  should be refactored to some var DefaultDimensionToCheck: Dictionary of [Integer, Code[20] to support a flexible length of Default Dimensions for checking.
Similiar to the other refacotring that was already done for dimensions.

@MarkoTrn in my opinion this is totally an extensibility bug.
This event was forgotten when the refactoring of the default dimension arrays to lists did happen.

This issue seems to still be there in the current 23.2.14098.14562 version of the BaseApp. Is there any update on when this bug is going to be resolved?

I asked @JesperSchulz for help.
He said, that this request was closed internally.
He reponed it and pinged the team.
I won't open an idea for this extensibility issue, since this is a bug and was simple forgotten while refactoring the dimensions.

Looping in @AlexanderYakunin for details on this case. The work item is now active again.

Refactoring of parameters in global procedure cannot be an event request. We classify it as extensibility enhancement. When we did change for Location Dimension and related changes in some document and journal tables, we decided not to refactor everything related with list of dimensions due to way too large scope of this work. Still have no plans to make this change in current release but open to discuss it internally and agree if we can fit this work into our plans.

I only want to add that I created this issue as an extensibility bug already in May 2023.
This was shortly after the release of BC22.
Since the first part of the refactoring was done by microsoft and the Old Events and procedures were removed with BC23 (CLEAN20) I was hoping that this can be addressed in the near future.
Maybe the work can be separated into several steps

Providing new methods and events in codeunit 408 DimensionManagement + new Events in codeunit 481 "Check Dimensions" that accept the new Dictionary/List
Public Methods:

CheckDimValuePosting
CheckDimBufferValuePosting
CheckDefaultDimensionHasCodeMandatory
...

Some Public Events:

OnAfterCheckDimValuePosting -> Obsolete  + add new event with correct name
OnBeforeCheckDimValuePosting -> Obsolete  + add new event
OnCheckDimValuePostingOnBeforeExit -> Obsolete  + add new event
OnBeforeCheckValuePosting-> Obsolete  + add new event
OnCheckValuePostingOnBeforeExit-> Obsolete  + add new event

Update the places where the old methods are used

Use new methods
Obsolete Old Events by replacing with new ones:

Obsolete related array functions in  codeunit 408 DimensionManagement
e.g. AddFirstToTableIdArray, AddLastToTableIdArray


Start thinking about how to represent the form's data in a reusable way--not just as a PDF

We eventually want to be able to store the information captured in the interview in a structured way, that captures all of the same information that goes onto the PDF. We may want to do this two different ways: a version with all of the data, and an anonymized version with just a summary for running reports.
Some ideas: extend the ALDocument class so that it also assembles a "shadow" JSON file. We could both send this to the court and store in database in searchable JSONB format. This would let us capture the information at the same time we generate the final document for the user/court.
We may also want to format and structure this data to match the fields in ECFv4 or v5; align with the profileMe hackathon experiment; look to NCSC and Schema.org.
At this point: we just need to start thinking about the problem and try to design our classes to allow room for this expansion.

@BryceStevenWilley one of our ideas was that we should try sending this data to the court even before the court has a place for it to go. Is there an existing metadata field where arbitrary JSON or XML data could be attached?

I think one of the strengths of ALDocument is that it has one job and does it well - assembling the documents. It might be better to keep this data building functionality separate from ALDocument, even if ALDocument ends up utilizing the data that's created.

I think one of the strengths of ALDocument is that it has one job and does it well - assembling the documents. It might be better to keep this data building functionality separate from ALDocument, even if ALDocument ends up utilizing the data that's created.

Valid point. Worth keeping simplicity and clarity of purpose in mind as a design goal. I might need to clarify though--what we are thinking about here is the same data that goes into the PDF, but in a structured format rather than a picture that a person has to read. It should not contain different data. I think this could be part of ALDocument in the same way that the addendum code is part of ALDocument. These representations tend to be machine-readable documents, although keeping them indexable and searchable in a database row would be nice. XML is the old wave; JSON is the newer approach but not dominant. For some examples of people who have created structured representations of legal data:

http://www.akomantoso.org/
https://www.ncsc.org/services-and-experts/areas-of-expertise/court-statistics/national-open-court-data-standards-nods
https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=legaldocml
https://schema.org/
https://github.com/jhpyle/docassemble-profileme

Creating these files might simply be a template that we add an attribute for in the ALDocument class. To the extent it ends up adding a lot of new code and not something like a template, we could add a new class that the ALDocument incorporates as an attribute of that class.

One thing that I think we really need to think through is the interface to abstract and capture the relevant fields, which will not have a 1-1 mapping to the information needed to fill in the PDF. Some information that goes into the document will be needed just for rendering/display purposes but has no meaning outside of the specific PDF. Most fields will have real semantic meaning. Some will be captured in the document, but not in the fields. For example, there could be hardcoded headings in the PDF that do not map to a field. When you read the PDF you understand what the data means, but just looking at the variables wouldn't tell you what option the user chose.
It is possible that combining a case type (could be implicit information that we want to make explicit--maybe user indicated it by starting a particular interview, but no variable in the interview state explains it) with all of the fields in the interview state would be enough information. If that feels promising, we could just come up with a deny list style approach, where we explicitly remove some irrelevant information from the answer store but default to sending over everything.
We may also need to add new data structures to capture information though. Things like relationship information that is just implicit in the variable names but the XML/JSON standard expects to be spelled out, reformatting the users and other_parties variables back to Plaintiff/Defendant if it's not relevant to the canonical representation, etc.
All that said: just sending over almost ALL of the field data feels like the place to start.


Python: casting device int to str

fixes an issue when gpu is enabled to run HF models.
Motivation and Context

Why is this change required?
running hf models on GPU causes an issue with device string
What problem does it solve?
fixed string concatenation issue
What scenario does it contribute to?
Helps when running HF models on GPU

Description
Contribution Checklist

[x] The code builds clean without any errors or warnings
[x] The PR follows the SK Contribution Guidelines and the pre-submission formatting script raises no violations
[x] All unit tests pass, and I have added new tests where possible
[x] I didn't break anyone :smile:

@mkarle this is a super simple fix (thanks @jetjodh!) but it's failing linting validation. Can you please take a look, and help merge this, if it's the right fix?


Add translation status indicator badge to README

Adds badge showing current translation status.
Change is only in README so no testing should be necessary (unless with testing you mean looking at rich diff and verifying that it renders, lol)
Rendered:

Closes R2Northstar/Northstar#343 (I think)
That is unless one'd want to add full chart like FlightCore has too:

That is unless one'd want to add full chart like FlightCore has too:

Good point, updated with d6803cb6029173e50189de7290453953d13d2083

mfw I forget about a PR that was ready to merge :clueless:


Version 0.4.15

@JuliaRegistrator register()
Release notes:
Version 0.4.15 (2024-04-16)
New Features

Implemented a function to detect isolated buses and incorporate them into the network calculation (Issue #38)

Registration pull request created: JuliaRegistries/General/104851
Tagging
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.4.15 -m "<description of version>" daf354e0d41cf58a3d2a33efeb8ae237dfab3d42
git push origin v0.4.15


01.08.02 - Ability to reorder habits (and reorder in database?)

Focus
User should be able to reorder their habits.
Partial US
As a doer, I want to manually reorder habits on my list of habits.
Reason
Users may be get a feeling of something off from the order of their habit list. In which case, they should be able to reorder their habits! JK. They should be able to reorder their habits as to give some sort of priority to habits that appear at the top with those at the bottom having the lowest priority.
Story Points
8
Risk Level
Low

Finished as of #124, could be more efficient though.


Pypi update

Hi!
Could it be possible to update the Pypi package with the last PRs? We rely on it to do the deploy.
That would save us some workarrounds or packaging it on a private pypi.
I'm sorry to be so much trouble lately :)
Thanks!

There's only a handful of commits since the last release - if you really need those just specify the GitHub repo in your requirements file.


Add procurementMethodDetails functionality

accelerator is specified in contract

Pull Request Test Coverage Report for Build 139

18 of 28 (64.29%)  changed or added relevant lines in 3 files are covered.
27 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-8.4%) to 90.868%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

openprocurement/contracting/esco/utils.py
13
23
56.52%

Files with Coverage Reduction
New Missed Lines
%

openprocurement/contracting/esco/utils.py
27
74.51%

Totals

Change from base Build 136:
-8.4%

Covered Lines:
398

Relevant Lines:
438

💛  - Coveralls


Unable to create appimage files within ubuntu-18.04 since ~2023-09-12

VSCODIUM uses ubuntu-18.04 for its build. Since a couple of weeks, building the appimage fails.
I guess this is due to a new version of pkg2appimage. I can reproduce the failure. Using ubuntu-18.04 fails building appimage files.
Using ubuntu-20.04, appimage files can be created.
Since VSCODE uses ubuntu-18.04 for its build at the moment, I guess VSCODIUM should use the same version.
I created a custom version of pkg2appimage. Using this version, the build succeeds under ubuntu-18.04. I'll create a pull request
for the version. Maybe you can accept the PR?
I case of questions, please drop me a note. I can provide lots of more details and informations
https://github.com/VSCodium/vscodium/issues/1654

So this is the change?
https://github.com/AppImageCommunity/pkg2appimage/compare/master...uli-heller:pkg2appimage:master

Yes, see the linked PR.

Ubuntu 18.04 ran out of standard support in April 2023. Currently we are targeting Ubuntu 20.04.
https://ubuntu.com/about/release-cycle


A way to install godep securely, hashable/pinning

I like godep because it allows me to install dependencies securely, specifying the hash of each dependency. But I need a way to bootstrap that. go-lang is installed in my system using a package manager like apt, but to install godep from an official source I have to use "go get github.com/tools/godep", which is not very secure. Couldn't you do releases and package them, so that we can download and unpack them and install them in GOPATH for bootstraping?
I'd like to be able something like:
$ mkdir gopath; cd gopath; wget http://path/to/godep-rev.tar.gz
$ [ "$(sha512sum godep-rev.tar.gz)" == "whateverhash" ] && tar zxf godep-rev.tar.gz || echo "Invalid tarball"
$ export GOPATH="$(pwd)"
$ then use godep

Where would you get "whateverhash" from, and why should it be any more trustworthy than the code you can get directly from https://github.com/tools/godep/archive/master.tar.gz? (Or from 'go get', which also uses https on github.)


No option for "offline" wallet as Java packages complain and stop if no internet access

Cold-storage implementation, no go?
Linux build -- Java packages error out if no internet access.

Can you explain what you mean here? Sparrow certainly supports offline usage. Building Sparrow does naturally require the source code and dependencies to be retrieved though.

Hi Craig,
Thanks for your response and sorry for my lack of specificity.
After the initial build on Debian, I can use it (although I can't click on any of the menu items, so I have to use the Alt key to get there, but that's a separate issue).
However if I take the system offline, then on subsequent launches, sometimes the Java packages it's built on try to connect online but complain that they can't, then stop, so the app never launches.
I'll try to capture the exact messages when they happen again so that I can give you more details.
Thank you.

@craigraw here are the screenshots. Again, these are errors NOT from the initial build (which has already been done) but subsequent launches of the app. Errors due to being offline :

Looking at the screenshot, I'm not sure where the path src/sparrow/sparrow comes from.
As noted in https://github.com/sparrowwallet/sparrow/blob/master/docs/reproducible.md, a build will appear in build/jpackage/Sparrow - you would run it with build/jpackage/Sparrow/bin/Sparrow.
Re the menu items, what window manager are you using?

@craigraw thank you, that seems to have solved the issue.
Mouse clicks still don't work for top-level-menu items -- they only flicker on/off once per click. But that's another issue and I think I will try something else to solve that.
Thanks for your help!

Re menus, see #170.
Closing this off.


TreeExplainer.shap_values() incorrect results for model with output vector

I am using a scikit-learn RandomForestClassifier as follows:
model = RandomForestClassifier(**parameters)
model.fit(X, y)
explainer = shap.TreeExplainer(model)
shap_values = explainer.shap_values(X)
y is Nx2, with each element of the output 2-vector having two possible classes (0 or 1).
My plots look like the following:
shap.summary_plot(shap_values, X, plot_type='bar')

Note that the bars are all divided exactly equally into the two classes. It looks like shap_values[0] and shap_values[1] represent the 0 or 1 classes for only the first component of the output vector rather than the importance for the two components of the vector.
shap.summary_plot(shap_values[0], X, plot_type='layered_violin')

Compare with the next figure...
shap.summary_plot(shap_values[1], X, plot_type='layered_violin')

This is the exact mirror image of the preceding figure. Again, it looks like shap_values[0] and shap_values[1] represent only one component of the output vector. How do I get the other one?

Note: I'm using shap-0.28.5

This might be related to #518

RandomForestClassifier in sklearn directly outputs probabilities from the trees. Since you have two classes, the probability of the first class is just one minus the probability of the second class. So you will get no new information by looking at the explanations of the second class vs. the first. Both contain the same information with different signs.

But I have 4 classes. There are two axes, each with 2 classes.

On Apr 18, 2019, at 3:50 PM, Scott Lundberg<EMAIL_ADDRESS>wrote:
RandomForestClassifier in sklearn directly outputs probabilities from the trees. Since you have two classes, the probability of the first class is just one minus the probability of the second class. So you will get no new information by looking at the explanations of the second class vs. the first. Both contain the same information with different signs.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/slundberg/shap/issues/529#issuecomment-484663513, or mute the thread https://github.com/notifications/unsubscribe-auth/ACMQXIJJ64KBUEJO24OOZSLPRDGIHANCNFSM4HDLMGOQ.

Ah! Sorry I missed that. The current setup for TreeExplainer is not designed to handle multiple-output multi-class functions right now. It is something I would like to support, but will require some work to do it. (I work around is to train two different classification models...but that is obviously a different model)
I'll add this as a todo.


Issue 19589 separate command and text field for slack outgoing web-hooks

Fixes: https://github.com/zulip/zulip/issues/19589

Added logic that checks whether text contains a command and splits it into command and text
Adds command and text in their own fields
Updated tests to use "/" operator for commands instead of "@**" as per issue description

Screenshots and screen captures:

Self-review checklist

[ ] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[ ] Explains differences from previous plans (e.g., issue description).
[ ] Highlights technical choices and bugs encountered.
[ ] Calls out remaining decisions and concerns.
[ ] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[ ] Each commit is a coherent idea.
[ ] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[ ] Visual appearance of the changes.
[ ] Responsiveness and internationalization.
[ ] Strings and tooltips.
[ ] End-to-end functionality of buttons, interactions and flows.
[ ] Corner cases, error conditions, and easily imagined bugs.

Thanks @ikrambil ! Please clean up your commit history and post again to request a review. See here for guidelines.

Closing as this is abandoned and doesn't have clear evidence of careful end-to-end testing.


Add getting started doc page

[ ] Closes #xxxx
[ ] Tests added / passed
[ ] Passes pre-commit run --all-files

Are you familiar with https://docs.dask.org/en/stable/10-minutes-to-dask.html ?

Are you familiar with https://docs.dask.org/en/stable/10-minutes-to-dask.html ?

Yes, but that's was too much (and unnecessary) information for someone who wants to start playing around with.
It's not really a quick start, more a resource for things after this section

Yes, but that's was too much (and unnecessary) information for someone who wants to start playing around with.
It's not really a quick start, more a resource for things after this section

I don't disagree with your critique, however I think that both pages are trying to serve the same role, and I'd rather that we have exactly one of them.  I suggest that we find some way to improve the old page, or bring this one up to a state where it could comfortably replace it.
One thing I like about the 10-minutes page is that it's not dask-dataframe specific.  This new attempt talks a lot about pandas and not at all about other APIs, which I would prefer to avoid.

This isn't ready yet and definitely needs more content, but serving 5 different use-cases at the same time is one of the issues with the other page. Someone who hasn't heard about Dask yet is best served with a clear cut intro that holds their hand for the first few steps.
We probably want something similar on another page where we can send user to that don't care about DataFrames.
I wouldn't want to remove the other page completely, but just offer information for the second 10 minutes basically, but again, the PR isn't ready yet

but serving 5 different use-cases at the same time is one of the issues with the other page

I agree that this is a challenge.

intro that holds their hand for the first few steps.

Not if those first few steps don't lead in the direction that they care about.  I think that this is harmful in those cases.  If I'm coming to Dask for general purpose parallel computing, and I see that the quickstart is all about pandas, then there's a non-trivial possibility that I move on.
I acknowledge that solving both of these problems simultaneously is hard

We probably want something similar on another page where we can send user to that don't care about DataFrames

I'm not sure I understand what this would be.    Maybe I'm just communicating early that I'll be -1 on a quickstart that strongly emphasizes dataframes at the expense of other APIs.

Just thinking out loud here, but another solution would be to have a dataframes-specific quickstart in the dataframes section.  Then different external resources could link to that page, rather than to a single overall dask quickstart.

another solution would be to have a dataframes-specific quickstart in the dataframes section

FWIW I was thinking something similar. Could imagine a Dask Array quickstart as well.


Update v4 spec about sharing props type

This PR updates the JSX v4 spec about sharing props type regarding the PR #699

@mattdamon108 made some changes: can you take a look?
What's not clear to me is why one does this:
  let make = ({x, y, _}: props<'a, 'b>) => React.string(x ++ y ++ z)

and not this:
  let make = ({x, y, _}: props<_>) => React.string(x ++ y ++ z)

Also what's unclear to me is why the feature combines a partial type definition (passing certain arguments), which can e.g. use a wrong number of arguments or something. And what's the type error going to look like if used wrong.
Another possibility is having the simples mechanism possible, and just pass the name of the type, and provide zero additional type definitions in the PPX. And let the user fully define that type. Probably requiring that it has at least one type argument (in the instructions for use), so there's no special case to worry about.

@mattdamon108 made some changes: can you take a look?
What's not clear to me is why one does this:
  let make = ({x, y, _}: props<'a, 'b>) => React.string(x ++ y ++ z)

and not this:
  let make = ({x, y, _}: props<_>) => React.string(x ++ y ++ z)

Actually, the feature generates the latter. https://github.com/rescript-lang/syntax/blob/master/tests/ppx/react/expected/sharedProps.res.txt

Also what's unclear to me is why the feature combines a partial type definition (passing certain arguments), which can e.g. be used with a wrong number of arguments or something. And what's the type error going to look like if used wrong.

Here is the example to show how it works and my logic:
Case 1. simple case
type sp = ...

@react.component(:sp)
// transformed to
type props = sp

Case 2.
type sp1<'a> = ...

@react.component(:sp1<'a>) // Ptyp_var
// transformed to
type props<'a> = sp<'a> // props<'a>

Case 3.
type sp1<'a> = ...

@react.component(:sp<string>) // Ptyp_constr
// transformed to
type props = sp<string> // just props

I just show the case of having 1 type argument example, but it would be the same for the 2, 3, ... cases. Both cases 2 and 3 are possible as use cases. So, if the core_type in payload of @react.component has type arguments, then I distinguish the arguments between Ptyp_var or else. This is why it makes the partial type definition.

Another possibility is having the simples mechanism possible, and just pass the name of the type, and provide zero additional type definitions in the PPX. And let the user fully define that type. Probably requiring that it has at least one type argument (in the instructions for use), so there's no special case to worry about.

Yes, I agree with your point. That would make more clean implementation as well as a clear user guide.
IMHO, I guess the current logic would not make many problems in the userland. If the user encounters the type error caused by a mismatched number of type arguments, then would the user rather define the type fully?

I think the tradeoffs in terms of implementations and uses are clear. Up to you to choose which one looks best.

I've made a PR to fix and update the spec accordingly.

Ready to merge?

Yes!


MAAS playbooks use different type of hostnames

What version (commit) do you encounter this issue on?
r11.0.0
What type of issue is this (bug, feature, documentation, regression)?
Bug
What is the expected behavior?
All maas related playbooks should use one type of hostname, either inventory_hostname or ansible_hostname to prevent situations that the host has a FQDN but is only known with a short name in the inventory. That leads to issues that the the verify-maas.yml playbook looks up checks with a different hostname than the checks got created with
For example :
root@bjoern-aio3:/opt/rpc-openstack/rpcd/playbooks# grep hostname roles/rpc_maas/templates/nova_api_local_check.yaml.j2
label: "nova_api_local_check--{{ ansible_hostname }}"
        label                   : nova_api_local_status--{{ ansible_hostname }}

root@bjoern-aio3:/opt/rpc-openstack/rpcd/playbooks# grep hostname verify-maas.yml -B1
        {{ maas_rpc_scripts_dir }}/rpc-maas-tool.py verify-created
        --entity {{ inventory_hostname }}
--
        {{ maas_rpc_scripts_dir }}/rpc-maas-tool.py verify-status
        --entity {{ inventory_hostname }}

What is actually happening?
See above
How can we reproduce this issue?
Use short hostnames in the inventory and long hostnames on host level
and run through the MAAS life cycle
How can we verify your issue is addressed?
All playbooks run successfully when installing them and running the verify-maas.yml playbook
If this is a large issue, what can be done immediately to alleviate the issue while working on a longer-term solution?
Normal prio
What is your evaluation on the importance of this issue, and why?
None
What branches / milestones do you believe this issue should target?
The list below is what is currently supported for backports, remove branches you do not wish to target.

[ ] Master
[ ] liberty-12.0
[ ] kilo

We should be consistent and use short hostnames everywhere.

This is the last play that is failing on the customer deploy I am working on, saying it can't find the entities. When I check the monitoring portal, the entities are all there and checking in 'green'. Here is a sample error from the deployment host:
TASK: [Verify Checks & Alarms are registered] *********************************
failed: [768028-cinder01] => {"attempts": 10, "changed": false, "failed": true, "failed_when_result": true, "rc": 1, "stdout_lines": ["Traceback (most recent call last):", "  File "/root/.ansible/tmp/ansible-tmp-1461191442.52-228658027580531/rpc-maas-tool.py", line 618, in ", "    cli = RpcMassCli()", "  File "/root/.ansible/tmp/ansible-tmp-1461191442.52-228658027580531/rpc-maas-tool.py", line 214, in init", "    self.args.raxrcpath)", "  File "/root/.ansible/tmp/ansible-tmp-1461191442.52-228658027580531/rpc-maas-tool.py", line 55, in init", "    self._filter_entities()", "  File "/root/.ansible/tmp/ansible-tmp-1461191442.52-228658027580531/rpc-maas-tool.py", line 70, in _filter_entities", "    raise Exception("No Entities found matching --entity or "", "Exception: No Entities found matching --entity or --entitymatch"]}
stderr: OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: auto-mux: Trying existing master
debug1: mux_client_request_session: master session id: 2
Shared connection to <IP_ADDRESS> closed.
stdout: Traceback (most recent call last):
File "/root/.ansible/tmp/ansible-tmp-1461191442.52-228658027580531/rpc-maas-tool.py", line 618, in
cli = RpcMassCli()
File "/root/.ansible/tmp/ansible-tmp-1461191442.52-228658027580531/rpc-maas-tool.py", line 214, in init
self.args.raxrcpath)
File "/root/.ansible/tmp/ansible-tmp-1461191442.52-228658027580531/rpc-maas-tool.py", line 55, in init
self._filter_entities()
File "/root/.ansible/tmp/ansible-tmp-1461191442.52-228658027580531/rpc-maas-tool.py", line 70, in _filter_entities
raise Exception("No Entities found matching --entity or "
Exception: No Entities found matching --entity or --entitymatch
And here is the actual entity as it exists in the MaaS portal:
entity_label
768028-cinder01.spindance.com
As I do not see the MaaS portal using anything but FQDN's for the near future, we should consider some other way to deal with that. For now, I'll be commenting out this play from deploy.sh until I hear otherwise.
Thanks

FYI this is still an issue with all releases since Kilo

@claco @mancdaz Same questions, is this a feature and what is the size? That will drive when we do this.

@b3rnard0 if this can be reproduced, it's a bug rather than a feature

This is a bug and should be easily be reproducible.

@nategraf is spinning up an environment to do some testing, and is currently in the discovery phase on this. @Frank-ZhangXin and @cloader89 has also offered help.

I was able to reproduce the output in the original issue report. Going to see if I can reproduce the error in the comments.

I propose that we use either inventory_hostname or ansible_hostname throughout, not using one somewhere, and the other somewhere else. What do you guys think?

I would like more information @BjoernT, which SHA are you using?

This problem is existing in all versions of Kilo and Liberty. The particular SHA does not matter if you just look at the playbooks referencing different names. I suggest do change verify-maas to use the same variable as the Maas playbooks installing the checks. Other way around will cause havoc during upgrades

Can you be specific as to which same variable?  @BjoernT

@BjoernT Please provide feedback on the pull request at your earliest convenience. Thanks!

Update: we have just built liberty and kilo backport for this patch, and wait the result.

@nategraf remember that the checklist in the description needs to be completed. Currently the branches liberty-12.2 and kilo have been ticked but master hasn't, this doesn't match up with the pull requests. This idea is that the branches listed should be the ones requiring the fix and they should be ticked when the fix merges.


Question: Default options in page permissions

Hi
In the page permissions form, is it possible to set the "Login required" option checked and the menu visibility option set as "for logged in users only", both as default for new cms pages?
thanks

Hello @jerickbixly  , please make sure to submit questions within the appropriate channels on either the User Mailing List, IRC (freenode#django-cms) or Stackoverflow.
You can find additional information on our support page.
In this case, I believe your question is best in the Users Mailing List.


Very indented shadows

Godot version:
3.2 dev
OS/device including version:
Windows 10 x64 / NVIDIA GeForce GTX 1060 6GB / Intel Core i7 4790K
Issue description:
A simple directional light over a simple cube produces this triangled shadows:

Steps to reproduce:
Open the project and press F6.
Minimal reproduction project:
shadows.zip

Is this a regression? To me it just looks like the normal behavior of low-resolution shadowmap, with all the effort made to smooth its huge pixels.

Found the solution as indicated by @mysticfall:
Increasing the "Directional Shadow" -> Size it gets much better.


form validation not have remote validation

some time,we need remote validation some data,but i'm not found in semantic
can you add it in the future?

some time,a field has two or more rule,the first rule return invalid,i want to interrupt the validator
but i'm not found in semantic
such as:
username: {
identifier : 'username',
rules: [
{
type   : 'empty',
prompt : 'Please enter a username'
},
{
type:'length[4]',
prompt:'Please enter 4 words'
}
]
}
when is empty,i just want check first rules and ignore other

What you want can easily be done by using a callback, such as onInvalid. Just have one rule:
rules: [
  {
    type: 'empty',
    onInvalid: function(field) {
      if (field.length > 0) {
        // It is less than 4 characters long
      } else {
        // It is empty
      }
    }
  }
]

thanks
some time,we need remote validation some data,but i'm not found in semantic
can you add it in the future?
i'm a semantic fans

You can do this with $.ajax({ sync: false }); although it's not pretty. Would require async which form does not support currently.

thanks for your help
I know too
so i suggest developers add this in the future


Improved Websocket support for latency concerns

Issue

Performing Latency calculations are a challenge.
Websocket reconnect so users don't need to redefine their events handlers in their code
Websocket native keep alive when it's been 10s or more since data/message

Acceptence Criteria

Send-queue for all messages on websocket, so connection drops don't kill transcription - include resend opening packet/headers

@dvonthenen


MH-13003, Stop changing technical start date after event started

This should fix the problem described in MH-13003, however, I have to say that I am not that sure about the changes. I don't know whether the lines I removed weren't there for a reason; comment above them subtly suggests to me that they were. But I wouldn't know why you would want to override the technical start date with the bibliographical one when the event has started (or is finished) recording.
The problem
What follows is a lengthy description of my findings regarding MH-13003, so that other people can reproduce the error and track it through the code.
The first part of the problem is that the IndexServiceImpl#updateEventMetadata method which the /event/:id/metadata endpoint delegates more or less immediately to treats the event differently based on what it calls the "event source", which---for all of our intents and purposes---just means whether the events technical start date lies in the past. (Workflows also play into this, but let's ignore this here; for details: I'm referring to the switch-statement in the aforementioned method and the getEventSource method in the same class.)
If it does, the event is handled by the "ARCHIVE" branch and a snapshot is taken via the asset manager, and everything is find from our point of view. If the technical start date does not lie in the past, though, the event is treated as "SCHEDULED" and handed to the scheduler service.
The scheduler service in turn calls SchedulerServiceImpl#verifyActive, which throws the exception we see in the log when the current time is after the end date of the event.
Now you might ask: "How can that be? The index service things the event starts in the future, gives it to the scheduler and that complains that the event is in the past?!" Well, behold the power of caches/indexes/other redundant storage systems! :smile:
The crux is that the scheduler asks the asset manager for the start date, which still has the original scheduled date (or the one that you set manually in the Scheduling tab after the fact, as described in MH-13003). The index service on the other hand has this information stored itself, too, and of course uses that. This is a problem once these two pieces of information get out of sync.
One place where that might happen is the one I changed. EventIndexUtils#updateTechnicalDate is called from updateEvent in the same class as a response to both, the asset manager and scheduler service messages generated by IndexServiceImpl#updateEventMetadata, and what it does is override the technical start date in the admin UI index with the bibliographical one if the former has already passed as reported, again, by the index service itself.
So step 2 in the description of MH-13003 generates a takeSnapshot message, in which the technical start date of the event in the index service is set to the future, which makes further metadata updates as in step 3 be handled by the scheduler, which still thinks that the event is in the past and thus refuses to update the metadata, which makes sense in my opinion. (Well, you might of course want to change meta data of a passed event, but keep in mind that the treatment of the event in question as an event that is scheduled as opposed to archived is already a faulty consequence of the above behavior. At least I think it is. :wink:)

Interesting. The tests passed on the branch I originally made these changes on. But that was admittedly not quite r/5.x. I'm looking into it.

@JulianKniephoff I could dig into the code to verify, but do you know if a technical start date is Ok to be null, or nullified, for an event after it starts recording, after ingest, or during an upload?

@karendolan no, sorry, I would have to do the same digging I'm afraid. Why do you ask?

@JulianKniephoff I ask because a person monitoring the processing of the recording in the Admin UI needs to know the scheduled technical start time up until the point of the end of the schedule event. But after the ingest, upload, or republish (in our case), the manager is concerned about the bibliographical start date that will be used for searching and displaying the event to consumers. The technical start date is useful for debugging after the fact, but no longer the primary date of concern when processing the metadata and materials for publication.
If the techncial start date should not be synchronized with the bibliographical start date after ingest, how does the admin-ui distinguish between the display of those dates in the UI?

Hmm I'm not sure I understand you correctly. Is the bibliographical start date in the search indices only stored as this copy of the technical start date? But then setting the latter to nothing wouldn't help either, right? The bibliographical start date would be lost either way. Also if that were really the case---if there is really no explicit storage space for the real bibliographical start date in the indices---that would indicate a pretty big design oversight to me, given your use case, which should be fixed a little closer to its root, imo.
But then again: This is exactly what I was hoping for, because I have probably too little knowledge still about many of the Opencast internals involved in this bug. Can you maybe provide a specific scenario that I can reconstruct locally, which breaks with this change?

Looking at org.opencastproject.index.service.impl.index.event.Event, there are two relevant fields: technicalStartDate and recordingStartDate. So there is definitely room to store both. Now of course if all the queries relevant to the display, filtering, sorting, ... in the UI use the former, I would see a need for these to be synced, but I think that would be a design smell in my opinion. Why not introduce a new field that reflects the use case you just gave: It would contain the technical start date before the recording started and the bibliographical one afterwards. This way the original fields would stay intact and can properly be used to make decisions about the actual state of the event.
Or the index service has to ask the scheduler service to make these decisions, which still contains the correct start date as I said before. But I guess that would be too slow? Which is why this information is stored in an index in the first place? :thinking:
So yeah, I'm a bit out of my depth here; any further feedback is greatly appreciated. :sweat_smile:

@JulianKniephoff  From the discussion, to keep the technicalStartDate isolated and not synched to secondary date sources, the updateTechnicalDate() method should be removed altogether. Uploaded events with SPACIAL and TEMPORAL location and start and stop times must have a NULL technicalStartDate to prevent design smell and represent that this value is not set and should not be  included in technical metadata searches. The Index endpoint should provide technical search services if that is what is needed by clients such as the scheduler service.
To go halfway for this pull, if it is not technically reasonable to avoid setting a technicalStartDate for uploads at this time, it would be more clear in the admin UI if the technicalStartDate for uploads is something like Jan 1, 1970, to represent an unknown to technical start time, to avoid confusion and design smell by mixing it with the bibliographic TEMPORAL start time of the event.

Okay so after some internal discussion here in Osnabrück, we decided to not touch the date semantics in the index service for this. Let the ElasticSearch update and index service rewrite/refactor deal with this as it turns out rather hairy issue. :wink:
We can fix this a step before already: Why does the index service even treat a completed event as scheduled only based on the date field? It should rather check whether it is done already somehow. This should be possible since this is exactly what the scheduler does as well and which eventually leads to the offending exception.
I will close this PR for now and create a new one once I cooked up a solution that does this. Thanks to @karendolan for the feedback, pushing me to explore the complexities of this topic a bit further. :smile:


Update install.sh

@VishnuByrraju

Please review and sign the Contributor License Agreement.
Where do the DB_SERVER and related environment variables come from?

@VishnuByrraju
I would like to move forward with reviewing your PR. Can you answer the question above, please?


TypeScript definitions are not in NPM release

Hi David, nice idea for a lib & digging your writing style!
Having a go at setting it up with SSR+Typescript and met some resistance:

index.d.ts is missing in the package published to NPM.
store: object causes errors in strict TS
PureComponent is too specific
collect should return ComponentType

How about this:
recollect's index.d.ts:
declare module 'react-recollect' {
  import * as React from 'react';

  interface GlobalState {
  }

  interface WithStoreProp {
    store: GlobalState;
  }

  interface CollectorComponent extends React.Component {
    update(store: object): void,
    _name: string,
  }

  export function collect<P extends object>(Component: React.ComponentType<P>): React.ComponentType<P & WithStoreProp>;

  export const store: GlobalState;

  export function afterChange(callback: (
    newStore: GlobalState,
    propPath: string,
    updated: CollectorComponent[],
    oldStore: GlobalState
  ) => void): void;
}

User would define interface for their global state in their project:

declare module 'react-recollect' {
  interface GlobalState {
    test?: string[];
    userName?: string;
  }
}

Disclaimer: not fully tested

Thanks!
I actually don't know anything about TypeScript, I kinda hobbled that index.d.ts together and it seemed to work (I was just looking for the autocomplete, not to use in a TypeScript project).
If you've got a moment, would you mind testing what you've done? If you could do a PR that'd be great otherwise I'll just copy paste what you've got above :) and add something to the readme.

Cool, I'll test and do a PR a bit later :-)

Thanks, much appreciated.


wasm-ld: error: unknown argument: --exclude-libs

CMake version is: 3.10.2-lubuntu<IP_ADDRESS>
gcc: 7..5.0

Could you try with emsdk 2.0.6?
Alternatively, you can try to comment the line https://github.com/tdlib/td/blob/33c689aacc78ef5a68973552b968a3bb68cdd7c6/CMake/TdSetUpCompiler.cmake#L64.

After using the emsdk 2.0.6 version, an error will still be reported.
Comment out that line of code to package successfully.
Thanks.


Release App

Not show ads error code 605

for a release app I don't try it yet, because you have to send them email to activate live ads on your app. and the code is based on their example, so in release app it should work as well if they already approved your account. you can see the error code here https://developers.ironsrc.com/ironsource-mobile/android/supersonic-sdk-error-codes/ which is not in the list.

It's a late reply but that error code is shown if you haven't created ad unit for the type of ad you want to display. So create some ad units.


Release 0.5.1

Checklist

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

@conda-forge-admin, please rerender

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe/meta.yaml:

noarch: python recipes should almost always follow the syntax in our documentation. For the host section of the recipe, you should almost always use python {{ python_min }} for the python entry. For the run section of the recipe, you should almost always use python >={{ python_min }} for the python entry. For the test.requires section of the recipe, you should almost always use python {{ python_min }} for the python entry. You may need to override the python_min variable in the conda_build_config.yaml/variants.yaml if the package requires a newer Python version than the currently supported minimum version on conda-forge.
PyPI default URL is now pypi.org, and not pypi.io. You may want to update the default source url.

Hi! This is the friendly automated conda-forge-linting service.
I failed to even lint the recipe, probably because of a conda-smithy bug :cry:. This likely indicates a problem in your meta.yaml, though. To get a traceback to help figure out what's going on, install conda-smithy and run conda smithy recipe-lint --conda-forge . from the recipe directory.
This message was generated by GitHub actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/11756766631.

@conda-forge-admin, please rerender

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

@conda-forge-admin, please rerender

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe/meta.yaml:

noarch: python recipes should almost always follow the syntax in our documentation. For the host section of the recipe, you should almost always use python {{ python_min }} for the python entry. For the run section of the recipe, you should almost always use python >={{ python_min }} for the python entry. For the test.requires section of the recipe, you should almost always use python {{ python_min }} for the python entry. You may need to override the python_min variable in the conda_build_config.yaml/variants.yaml if the package requires a newer Python version than the currently supported minimum version on conda-forge.

noarch: python recipes should almost always follow the syntax in our documentation. For the host section of the recipe, you should almost always use python {{ python_min }} for the python entry. For the run section of the recipe, you should almost always use python >={{ python_min }} for the python entry. For the test.requires section of the recipe, you should almost always use python {{ python_min }} for the python entry. You may need to override the python_min variable in the conda_build_config.yaml/variants.yaml if the package requires a newer Python version than the currently supported minimum version on conda-forge.
PyPI default URL is now pypi.org, and not pypi.io. You may want to update the default source url.

@sbillinge Got 2 new suggestions from the linter:
Provided my comments via in-lines. Once approved by you,I will update our staged-recipe-cookiecutter and also make an announcement so this is our new standard.

@conda-forge-admin, please rerender

Hi! This is the friendly automated conda-forge-webservice.
I tried to rerender for you, but it looks like there was nothing to do.
This message was generated by GitHub actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/11756822354.

@bobleesj here you set python_min to 3.11 consdisten with our NEP29 standard, but reading the linter, I had the impression that python_min referred to the minimum version that conda-forge is currently shipping....in other words it is a dynamic variable that is somehow set by conda-forge?    I am basically ok with anything here, but let's figure it out and follow some standard or other.

OK, I read more and I think what we are doing here is ok.   The syntax change is something to do with the fact that CF will test the minimum python version.  This avoids problems people were having when they forgot to change the minimum python version in their yaml and would then ship broken, unsupported, versions of their packages causing issues for users.

@bobleesj here you set python_min to 3.11 consdisten with our NEP29 standard, but reading the linter, I had the impression that python_min referred to the minimum version that conda-forge is currently shipping....in other words it is a dynamic variable that is somehow set by conda-forge? I am basically ok with anything here, but let's figure it out and follow some standard or other.

Appears that the minimum python version is indeed set dynamically and it is 3.9 according to the new file generated when re-rendered. As recommended, I used the jinja variable to override the python version.

OK, I read more and I think what we are doing here is ok. The syntax change is something to do with the fact that CF will test the minimum python version. This avoids problems people were having when they forgot to change the minimum python version in their yaml and would then ship broken, unsupported, versions of their packages causing issues for users.

Noted.


Can not load "webpack"

1.7.0 karma-webpack started breaking karma tests, 1.6.0 works as expected.
running on:
node v0.10.33
npm v2.12.0
karma v0.12.37
webpack v1.10.5
WARN [preprocess]: Can not load "webpack"!
  TypeError: Object [object Object] has no method 'refreshFiles'
    at Plugin.notifyKarmaAboutChanges (node_modules/karma-webpack/index.js:108:15)
    at Plugin.<anonymous> (node_modules/karma-webpack/index.js:72:9)
    at Tapable.applyPlugins (node_modules/webpack/node_modules/tapable/lib/Tapable.js:26:37)
    at Watching._done (node_modules/webpack/lib/Compiler.js:78:17)
    at Watching.<anonymous> (node_modules/webpack/lib/Compiler.js:61:18)
    at Tapable.emitRecords (node_modules/webpack/lib/Compiler.js:281:37)
    at Watching.<anonymous> (node_modules/webpack/lib/Compiler.js:58:19)
    at /home/ubuntu/gropius/resources/front-ends/application/node_modules/webpack/lib/Compiler.js:274:11
    at Tapable.applyPluginsAsync (node_modules/webpack/node_modules/tapable/lib/Tapable.js:60:69)
    at Tapable.afterEmit (node_modules/webpack/lib/Compiler.js:271:8)

You need to upgrade karma to 0.13

Duplicate of #65

Ok, I had karma locked at 0.12.x due to a previous problem with karma-webpack which was solved in this new version.
agree with @gil about broken semantic versioning, one might have other reasons to have karma at a locked at a lower version and any given package.json with karma-webpack at ^1.6.0 (notice the tilde) will give devs a headache with this version.
closing this since my problem was solved by updating karma.


Unable to Start Docker Kong 3.3.0 Alpine on Apple Silcon

Is there an existing issue for this?

[X] I have searched the existing issues

Kong version ($ kong version)
Kong 3.3.0
Current Behavior
Using Kong 3.3.0-alpine, Kong does not start with "lmdb function not implemented" on Apple Silicon
DOCKER_DEFAULT_PLATFORM=linux/amd64 docker run -e='KONG_DATABASE=off' kong:3.3.0-alpine
Error: could not prepare Kong prefix at /usr/local/kong: nginx configuration is invalid (exit code 1):
nginx: [warn] the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /usr/local/kong/nginx.conf:6
nginx: the configuration file /usr/local/kong/nginx.conf syntax is ok
nginx: [crit] unable to open LMDB environment: Function not implemented

  Run with --v (verbose) or --vv (debug) for more details

Kong 3.2.2 was work well.
DOCKER_DEFAULT_PLATFORM=linux/amd64 docker run -e='KONG_DATABASE=off' kong:3.2.2-alpine
2023/07/25 08:43:28 [warn] 1#0: the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /usr/local/kong/nginx.conf:6
nginx: [warn] the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /usr/local/kong/nginx.conf:6
2023/07/25 08:43:34 [notice] 1#0: using the "epoll" event method
2023/07/25 08:43:34 [notice] 1#0: openresty/<IP_ADDRESS>
2023/07/25 08:43:34 [notice] 1#0: built by gcc 11.2.1 20211120 (GCC)
2023/07/25 08:43:34 [notice] 1#0: OS: Linux 5.15.49-linuxkit-pr
2023/07/25 08:43:34 [notice] 1#0: getrlimit(RLIMIT_NOFILE): 1048576:1048576
2023/07/25 08:43:34 [notice] 1#0: start worker processes
2023/07/25 08:43:34 [notice] 1#0: start worker process 3185
2023/07/25 08:43:34 [notice] 1#0: start worker process 3187
2023/07/25 08:43:34 [notice] 1#0: start worker process 3189
2023/07/25 08:43:34 [notice] 1#0: start worker process 3191
2023/07/25 08:43:34 [crit] 3185#0: unable to open LMDB environment: Function not implemented
2023/07/25 08:43:34 [crit] 3187#0: unable to open LMDB environment: MDB_INVALID: File is not an LMDB file
2023/07/25 08:43:34 [notice] 1#0: start worker process 3193
2023/07/25 08:43:34 [crit] 3189#0: unable to open LMDB environment: Function not implemented
2023/07/25 08:43:34 [notice] 1#0: signal 17 (SIGCHLD) received from 3185
2023/07/25 08:43:34 [notice] 1#0: worker process 3185 exited with code 2
2023/07/25 08:43:34 [alert] 1#0: worker process 3185 exited with fatal code 2 and cannot be respawned
2023/07/25 08:43:34 [crit] 3193#0: unable to open LMDB environment: Function not implemented
2023/07/25 08:43:34 [notice] 1#0: worker process 3187 exited with code 2
2023/07/25 08:43:34 [alert] 1#0: worker process 3187 exited with fatal code 2 and cannot be respawned
2023/07/25 08:43:34 [crit] 3191#0: unable to open LMDB environment: MDB_INVALID: File is not an LMDB file
2023/07/25 08:43:34 [notice] 1#0: signal 17 (SIGCHLD) received from 3187
2023/07/25 08:43:34 [notice] 1#0: signal 17 (SIGCHLD) received from 3189
2023/07/25 08:43:34 [notice] 1#0: worker process 3189 exited with code 2
2023/07/25 08:43:34 [alert] 1#0: worker process 3189 exited with fatal code 2 and cannot be respawned
2023/07/25 08:43:34 [notice] 1#0: signal 29 (SIGIO) received
2023/07/25 08:43:34 [notice] 1#0: signal 17 (SIGCHLD) received from 3191
2023/07/25 08:43:34 [notice] 1#0: worker process 3191 exited with code 2
2023/07/25 08:43:34 [alert] 1#0: worker process 3191 exited with fatal code 2 and cannot be respawned
2023/07/25 08:43:34 [notice] 1#0: worker process 3193 exited with code 2
2023/07/25 08:43:34 [alert] 1#0: worker process 3193 exited with fatal code 2 and cannot be respawned
2023/07/25 08:43:34 [notice] 1#0: signal 17 (SIGCHLD) received from 3193

Expected Behavior
No response
Steps To Reproduce
No response
Anything else?
No response

Hi @DingGGu this is due to the qemu emulation missing some syscall support on Apple Silicon.
I did:
$ DOCKER_DEFAULT_PLATFORM=linux/amd64 docker run -e='KONG_DATABASE=off' -it kong:3.3.0-alpine bash
5f7c3617bdfc:/$ kong prepare
# shows the Function not implemented error, ignore it for now
5f7c3617bdfc:/$ cat >> /usr/local/kong/a.conf << EOF
> pid pids/nginx.pid;
error_log logs/error.log notice;

# injected nginx_main_* directives
daemon off;
user kong kong;
worker_processes auto;
worker_rlimit_nofile 16384;

lmdb_environment_path dbless.lmdb;
lmdb_map_size         128m;

events {
    # injected nginx_events_* directives
    multi_accept on;
    worker_connections 16384;
}

http {}
EOF

5f7c3617bdfc:/$ QEMU_STRACE=1 /usr/local/openresty/nginx/sbin/nginx -c /usr/local/kong/a.conf -p /usr/local/kong/ 2>&1|grep -i implem

1154 get_robust_list(0,274905703464,274905703472,1,274905703492,0) = -1 errno=38 (Function not implemented)
nginx: [crit] unable to open LMDB environment: Function not implemented

So get_robust_list syscall is not implemented in the qemu-x86-64 binary. Do note by using DOCKER_DEFAULT_PLATFORM=linux/amd64 you are running emulation mode (not Rosetta 2) of an x86_64 image
on Apple Silicon. We have no control on if that will work in the long term. Please consider using arm64 images on Apple Silicon. They are available for both alpine and ubuntu images.


FEAT: Suggested developer installation README update

Hi Joaquin,
I am automating my environment installation in a few multiple machines and whilst doing it I realized that this line of code on the GDSFactory developer Readme installation might help developers automate the install of all plugins. Just added a: # pip install -e .[full,gmsh,tidy3d,devsim,meow,database] # Install all plugins  on the developer installation README.

Thank you Dario!


[backport] Fix Caffe exporter to export eps of BatchNormalization layer

Backport of #4884

Jenkins CI test failed with status FAILURE.
(For contributors, please wait until the reviewer confirms the details of the error.)

Jenkins, test this please.

Jenkins CI test failed with status FAILURE.
(For contributors, please wait until the reviewer confirms the details of the error.)

Restarted tests.


Make iterator context tests explicit about type

By using a coercive assertion, the tests were not being explicit about
the fact that when specifying a primitive as the context for _.each,
the this value will actually be a wrapped version of the given
primitive.
This change simply makes the assertions more explicit.

Coverage remained the same at 96.863% when pulling 1a2bdf98bef1d4c95bed429b83c43a5b1c65383c on captbaritone:strict-iterator-context into a9432276b90bd23d3022deb89ac1ba6b10ee7495 on jashkenas:master.


Allow to define columns on Snippet chooser

Is your proposal related to a problem?
I would like to see more columns on the SnippetChooserBlock chooser to give editors better orientation. My current asset chooser looks like this:

Describe the solution you'd like
I have defined a SnippetViewSet with list_display fields which shows like this in snippet admin:

I would expect, that the same columns (name, asset_id and version_id) would display on snippet chooser.
The solution could look very similar to page chooser which already has columns (and the two could share the same code):

Describe alternatives you've considered
I might have missed something and maybe this is possible to achieve somehow. But I have searched the docs for quite some time and didn't find anything.
Additional context
There is note about necessity to display fields when using index.AutocompleteField, but there isn't described way how to achieve this for snippet choosers: https://docs.wagtail.org/en/stable/topics/search/indexing.html#index-autocompletefield
There is no mention about snippet chooser in description of creating SnippetViewSets although the icon parameter will affect the snippet chooser, but the list_display will not: https://docs.wagtail.org/en/stable/topics/snippets.html#customising-snippets-admin-views

Take a look at this tutorial https://enzedonline.com/en/tech-blog/wagtail-creating-custom-choosers-with-viewsets/


Fix example OIDC field repository_visibility

repo_visibility should be repository_visibility
Why:
The field documented in example OIDC json is wrong. Spent more than an hour just to later realise it is repository_visibility.
What's being changed (if available, include any code snippets, screenshots, or gifs):
Change in documentation, updated wrong field name in example
Check off the following:

[ ] I have reviewed my changes in staging (look for the "Automatically generated comment" and click the links in the "Preview" column to view your latest changes).
[ ] For content changes, I have completed the self-review checklist.

Writer impact (This section is for GitHub staff members only):

[ ] This pull request impacts the contribution experience

[ ] I have added the 'writer impact' label
[ ] I have added a description and/or a video demo of the changes below (e.g. a "before and after video")

Created issue #20266


crawler data too long for column

both mavat_data field under the plan table and the pdf chart data sometimes have a field value which is too long for our database fields.
should find all occurrences of this and enlarge the field sizes.

running crawler to check the errors now

running crawler to check the errors now


Fixed and added additional config for File Fieldtype

This pull request fixes the File Attribute and its issue of receiving a Livewire\Exceptions\CorruptComponentPayloadException and not uploading the file. Additionally, this fieldtype can handle multiple files and configuration options were added: File Types, Multiple Files, Min Files, and Max Files.
Of importance is the change in the handling of the dehydrated state for the File Attribute in  AttributeData that happens after the file upload.
Before dehydrating, files are uploaded by BaseFileUpload and a string or array is returned, which was not properly handled previouslly.

@alecritson Great, glad I can help!


assert forall by doesn't work for math multi-trigger

The second proof below, which should be trivial, doesn't verify:
pub proof fn lemma_mod_equivalence(x: int, y: int, m: int)
    requires
        0 < m,
    ensures
        x % m == y % m <==> (x - y) % m == 0,
{
    assume(false);
}

pub proof fn lemma_mod_equivalence_auto()
    ensures forall |x: int, y: int, m: int| #![trigger (x % m), (y % m)] 0 < m ==> (x % m == y % m <==> (x - y) % m == 0),
{
    assert forall |x: int, y: int, m: int| #![trigger (x % m), (y % m)]
        0 < m implies
        x % m == y % m <==> (x - y) % m == 0 by
    {
        lemma_mod_equivalence(x, y, m);
    }
}

A couple of observations.  First, this behavior is weirdly brittle.  It persists if you replace your version of lemma_mod_equivalence with:
pub proof fn lemma_mod_equivalence(x: int, y: int, m: int)
    requires
        true,
    ensures
        false,
{
    assume(false);
}

but if you remove the requires true above, then everything verifies nicely.
Similarly, if you replace the call  lemma_mod_equivalence(x, y, m); inside lemma_mod_equivalence_auto with assume(false), everything verifies successfully.
Z3 also quickly reaches unsat if you edit the output smt2 file to remove the definition of EucMod; i.e., delete:
(assert
 (forall ((x Int) (y Int)) (!
   (= (EucMod x y) (mod x y))
   :pattern ((EucMod x y))
   :qid prelude_eucmod
   :skolemid skolem_prelude_eucmod
)))

If you run Verus on the version with lemma_mod_equivalence under the profiler, the quantifier on the assert forall... is instantiated 22M times, with no other user-level quantifier instantiations reported.  If we dig a big deeper, here are the internal quantifier instantiations:
prelude_eucmod created 2681 instantiations and cost 2681
prelude_mod_unsigned_in_bounds created 2681 instantiations and cost 2681
prelude_sub created 82 instantiations and cost 82
internal_ens__assert_forall_lorch!lemma_mod_equivalence._definition created 1 instantiations and cost 1
internal_req__assert_forall_lorch!lemma_mod_equivalence._definition created 1 instantiations and cost 1

They're all very modest compared to the 22M for the user-level version.
My rough conclusion is that this isn't a Verus issue.  Instead, under certain circumstances known only to itself, Z3 gets caught in a trigger loop.  In particular, given two terms x % m and y % m, the assert's quantifier introduces a
term (x - y) % m.  Then we have two more possible pairs of terms (x % m with (x - y) % m, and y % m with (x - y) % m), which each introduce a new term, and so on.
If instead you write the lemma as:
pub proof fn lemma_mod_equivalence_auto()
    ensures forall |x: int, y: int, m: int| #![trigger (x % m), (y % m)] 0 < m ==> (x % m == y % m <==> (x - y) % m == 0),
{
    assert forall |x: int, y: int, m: int| #![trigger ((x - y) % m)]
        0 < m implies
        x % m == y % m <==> (x - y) % m == 0 by
    {
        lemma_mod_equivalence(x, y, m);
    }
}

then everything works nicely.  This suggests considering a similar change to the quantifier in the ensures clause, so clients don't get hit with this behavior.

Thanks, Bryan!


chore: release 3.2.6

:robot: I have created a release *beep* *boop*
3.2.6 (2019-08-03)
Bug Fixes

allow calls with no request, add JSON proto (#282) (c358df9)

This PR was generated with Release Please.

Release is at https://github.com/googleapis/nodejs-language/releases/tag/v3.2.6

The release build has started, the log can be viewed here. :sunflower:

:egg: You hatched a release! The release build finished successfully! :purple_heart:


Add Flutter-specific platform headers to requests sent to Firebase

@kroikie is tracking adding a way for us to separate requests generated from FlutterFire iOS/Android plugins from the ones made from unwrapped ObjC/Swift/Java/Kotlin Firebase SDKs.

May I ask what what this is used for?
Should https://github.com/fluttercommunity/firebase_flutter_sdk do this as well which is Flutter but doesn't use native APIs?

This has been implemented! :)

@eseidelGoogle
This issue has been moved to https://github.com/FirebaseExtended/flutterfire/issues/590. Any further collaboration will be done there.


Kernel compilation fails for compute::count

I use this simple code with OpenCL 1.2 CUDA on a GeForce GTX 750 Ti:
BOOST_COMPUTE_FUNCTION(bool, tuple_is_equal, (boost::tuple<uchar, uchar> x),
{
   return boost_tuple_get(x, 0) == boost_tuple_get(x, 1);
});

// ...

std::vector<compute::vector<uchar>> d_blender_images;
compute::vector<uchar> d_frame(ctx);

// ...

compute::vector<bool> d_frame_2(d_frame.size(), ctx);

// ...

compute::transform(
   compute::make_zip_iterator(boost::make_tuple(d_frame.begin(), d_blender_images.at(j).begin())),
   compute::make_zip_iterator(boost::make_tuple(d_frame.end(), d_blender_images.at(j).end())),
   d_frame_2.begin(),
   tuple_is_equal,
   queue
);
int count = compute::count(d_frame_2.begin(), d_frame_2.end(), true, queue);

Which throws an exception after building the second kernel:
Boost.Compute: kernel compilation failed (-5)
--- source ---
#define boost_pair_type(t1, t2) _pair_ ## t1 ## _ ## t2 ## _t
#define boost_pair_get(x, n) (n == 0 ? x.first ## x.second)
#define boost_make_pair(t1, x, t2, y) (boost_pair_type(t1, t2)) { x, y }
#define boost_tuple_get(x, n) (x.v ## n)

__kernel void reduce(__global ulong* input, const uint offset, const uint count, __global ulong* output, const uint output_offset)
{
const uint block_offset = get_group_id(0) * VPT * TPB;
__global const ulong *block = input + offset + block_offset;
const uint lid = get_local_id(0);
__local ulong scratch[TPB];
ulong sum = 0;
for(uint i = 0; i < VPT; i++){
    if(block_offset + lid + i*TPB < count){
        sum = sum + block[lid+i*TPB];
    }
}
scratch[lid] = sum;
barrier(CLK_LOCAL_MEM_FENCE);
if(TPB >= 1024){
if(lid < 512) { sum += scratch[lid + 512]; scratch[lid] = sum;} barrier(CLK_LOCAL_MEM_FENCE);}
if(TPB >= 512){
if(lid < 256) { sum += scratch[lid + 256]; scratch[lid] = sum;} barrier(CLK_LOCAL_MEM_FENCE);}
if(TPB >= 256){
if(lid < 128) { sum += scratch[lid + 128]; scratch[lid] = sum;} barrier(CLK_LOCAL_MEM_FENCE);}
if(TPB >= 128){
if(lid < 64) { sum += scratch[lid + 64]; scratch[lid] = sum;} barrier(CLK_LOCAL_MEM_FENCE);}
if(lid < 32){
volatile __local ulong *lmem = scratch;
if(TPB >= 64) { lmem[lid] = sum = sum + lmem[lid+32];}
if(TPB >= 32) { lmem[lid] = sum = sum + lmem[lid+16];}
if(TPB >= 16) { lmem[lid] = sum = sum + lmem[lid+ 8];}
if(TPB >=  8) { lmem[lid] = sum = sum + lmem[lid+ 4];}
if(TPB >=  4) { lmem[lid] = sum = sum + lmem[lid+ 2];}
if(TPB >=  2) { lmem[lid] = sum = sum + lmem[lid+ 1];}
}
if(lid == 0){
    output[output_offset + get_group_id(0)] = scratch[0];
}

}

--- build log ---

ptxas info    : 0 bytes gmem
ptxas info    : Compiling entry function 'reduce' for 'sm_50'
ptxas info    : Function properties for reduce
ptxas         .     0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
ptxas info    : Used 32 registers, 1032 bytes smem, 348 bytes cmem[0]

I'm not 100% sure, but I think the code should be correct judging from the documentation.
The compiler call is:
cl_int ret = clBuildProgram(m_program, 0, 0, "-DT=ulong -DVPT=8 -DTPB=128 -cl-nv-verbose", 0, 0);

I added -cl-nv-verbose to enable the ptxas info (build log) output.

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/29805310-kernel-compilation-fails-for-compute-count?utm_campaign=plugin&utm_content=tracker%2F402515&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F402515&utm_medium=issues&utm_source=github).

The error code is -5 which means that the error is CL_OUT_OF_RESOURCES  (there is a failure to allocate resources required by the OpenCL implementation on the device). Maybe there is no enough local memory or registers.
compute::vector<bool> d_frame_2(d_frame.size(), ctx);
Basically in OpenCL you shouldn't have bool buffers, because the size of bool is implementation defined and and in addition can also be different for the OpenCL device and the host. Use boost::compute::uint_ type or boost::compute::uchar. I can see that in this implementation it's ulong type which is not memory-efficient.

I think local memory or registers cannot be the issue, at least not if the build log is correct. 32 registers and 1kB s(hared?)mem...
I changed
compute::vector<bool> d_frame_2(d_frame.size(), ctx);

to
compute::vector<compute::uchar_> d_frame_2(d_frame.size(), ctx);

and updated tuple_is_equal accordingly. Unfortunately the generated kernel code remains the same (with ulong):
#define boost_pair_type(t1, t2) _pair_ ## t1 ## _ ## t2 ## _t
#define boost_pair_get(x, n) (n == 0 ? x.first ## x.second)
#define boost_make_pair(t1, x, t2, y) (boost_pair_type(t1, t2)) { x, y }
#define boost_tuple_get(x, n) (x.v ## n)

__kernel void reduce(__global ulong* input, const uint offset, const uint count, __global ulong* output, const uint output_offset)
{
const uint block_offset = get_group_id(0) * VPT * TPB;
__global const ulong *block = input + offset + block_offset;
const uint lid = get_local_id(0);
__local ulong scratch[TPB];
ulong sum = 0;
for(uint i = 0; i < VPT; i++){
    if(block_offset + lid + i*TPB < count){
        sum = sum + block[lid+i*TPB];
    }
}
scratch[lid] = sum;
barrier(CLK_LOCAL_MEM_FENCE);
if(TPB >= 1024){
if(lid < 512) { sum += scratch[lid + 512]; scratch[lid] = sum;} barrier(CLK_LOCAL_MEM_FENCE);}
if(TPB >= 512){
if(lid < 256) { sum += scratch[lid + 256]; scratch[lid] = sum;} barrier(CLK_LOCAL_MEM_FENCE);}
if(TPB >= 256){
if(lid < 128) { sum += scratch[lid + 128]; scratch[lid] = sum;} barrier(CLK_LOCAL_MEM_FENCE);}
if(TPB >= 128){
if(lid < 64) { sum += scratch[lid + 64]; scratch[lid] = sum;} barrier(CLK_LOCAL_MEM_FENCE);}
if(lid < 32){
volatile __local ulong *lmem = scratch;
if(TPB >= 64) { lmem[lid] = sum = sum + lmem[lid+32];}
if(TPB >= 32) { lmem[lid] = sum = sum + lmem[lid+16];}
if(TPB >= 16) { lmem[lid] = sum = sum + lmem[lid+ 8];}
if(TPB >=  8) { lmem[lid] = sum = sum + lmem[lid+ 4];}
if(TPB >=  4) { lmem[lid] = sum = sum + lmem[lid+ 2];}
if(TPB >=  2) { lmem[lid] = sum = sum + lmem[lid+ 1];}
}
if(lid == 0){
    output[output_offset + get_group_id(0)] = scratch[0];
}

}

Here is the complete source code, in case some important part is missing: http://dpaste.com/0EM61SK

Yes, you're right. In that kernel ulong_ type is used, becouse ulong_ type is used in count_if_with_reduce.hpp. But before reduce kernel there is also initial_reduce kernel (see reduce_on_gpu.hpp. Nonetheless, it's better not to use bool type in device vectors.
I'll try to compile that code later today and see what happens.

Funny, the code works perfectly fine on my Laptop (OpenCL 1.1 CUDA on a GeForce GT 540M). It had a few bugs, here is the new/final version: http://dpaste.com/1V1J7FA
Note that I switched from transform+count to count_if (see commented code), but both variants have the same error on my desktop computer.

// https://github.com/boostorg/compute/issues/550
BOOST_AUTO_TEST_CASE(count_issue_550)
{
    compute::vector<compute::uchar_> vec(1024*1024, compute::uchar_(1), queue);
    compute::vector<compute::uchar_> vec2(1024*1024, compute::uchar_(1), queue);

    BOOST_CHECK_EQUAL(
        compute::count_if(
            compute::make_zip_iterator(boost::make_tuple(vec.begin(), vec2.begin())),
            compute::make_zip_iterator(boost::make_tuple(vec.end(), vec2.end())),
            tuple_is_equal,
            queue
        ),
        size_t(1024*1024)
    );
}

This code runs perfectly fine for me.


Unable to assign database ownership and future schema ownership grants using snowflake_grant_privileges_to_role

Terraform CLI and Provider Versions
PS C:\proj\GitRepo\Snowflake_Terraform> .\terraform.exe version
Terraform v1.7.0
on windows_amd64

provider registry.terraform.io/snowflake-labs/snowflake v0.84.0

Terraform Configuration
resource "snowflake_grant_privileges_to_role" "DB_OWNERSHIP-SYSADMIN" {
  for_each = { for db in var.DB_SCHEMA_MAPPING : db.database => db... }

  privileges = ["OWNERSHIP"]
  role_name  = "SYSADMIN"

  on_account_object {
    object_type = "DATABASE"
    object_name = each.key
  }
}

resource "snowflake_grant_privileges_to_role" "SCHEMA_OWNERSHIP-SYSADMIN" {
  for_each = { for ds in var.DB_SCHEMA_MAPPING : "${ds.database}_${ds.schema}" => ds }

  privileges = ["OWNERSHIP"]
  role_name  = "SYSADMIN"

  on_schema {
    future_schemas_in_database = each.value.database
  }
}

Expected Behavior

plan to evaluate successfully
apply to evaluate successfully
apply to complete and all my databases to be owned by sysadmin and new schemas to also be owned by sysadmin

Actual Behavior

plan evaluates successfully
apply evaluates successfully
when applying the plan it fails and we see the below

Error: error granting privileges to account role: 003504 (01000): A future grant with privilege OWNERSHIP on object type SCHEMA already exists in the schema.

   with snowflake_grant_privileges_to_role.SCHEMA_OWNERSHIP-SYSADMIN["STG_RAW_FIRM_MARKET_DATA"],
   on 1-db_creation.tf line 26, in resource "snowflake_grant_privileges_to_role" "SCHEMA_OWNERSHIP-SYSADMIN":
   26: resource "snowflake_grant_privileges_to_role" "SCHEMA_OWNERSHIP-SYSADMIN" {

Error: error granting privileges to account role: 003504 (01000): A future grant with privilege OWNERSHIP on object type SCHEMA already exists in the schema.

   with snowflake_grant_privileges_to_role.SCHEMA_OWNERSHIP-SYSADMIN["DEV_AY_RAW_SNAPSHOTS"],
   on 1-db_creation.tf line 26, in resource "snowflake_grant_privileges_to_role" "SCHEMA_OWNERSHIP-SYSADMIN":
   26: resource "snowflake_grant_privileges_to_role" "SCHEMA_OWNERSHIP-SYSADMIN" {

Steps to Reproduce

Use snowflake_grant_privileges_to_role to set ownership on a database
Use snowflake_grant_privileges_to_role to set ownership on future schemas in the same database
run terraform plan which shows the config as presumably valid
on application of the plan, it will fail wiht the error shown above

How much impact is this issue causing?
Medium
Logs
No response
Additional Information
No response

Hey @gdelia-pm
I would say that's more Snowflake misuse than the TF Provider bug. That's a Snowflake error that says grant x on future schemas in database y have been called on this object (by Terraform or it was granted previously outside of the Terraform). Also, I would say snowflake_grant_privileges_to_role is not that well suited for granting ownership. You can use it for now, but soon, we should start the work on the grant ownership resource which should handle different cases. But I guess it makes sense in this case because Snowflake doesn't allow to transfer of ownership from role to role that already has it.

Thanks for responding here, I guess I thought (incorrectly) that we should have been using the snowflake_grant_privileges_to_role for ownership as using the snowflake_schema_grant option gives an deprecated resource warning on every run.
I'll use that along with snowflake_database_grant to set these and wait for a newer resource to come along instead to manage this.  Any eta on what that would be availalbe?

You can also use ** snowflake_role_ownership_grant** for managing ownership transfer. It's also deprecated and will be replaced by the newer resource, but it should be better at managing ownership. Cannot give you the exact eta, but it may be somewhere around next quarter. To be honest the error should also be visible when using snowflake_database_grant. The error comes from Snowflake, not the provider. If the error is not returned I would be suspicious of either deprecated resource not doing the call (or alternating it to something else) or the configuration is doing something else and thus not triggering the error.

Ah I see what you mean.  With the snowflake_database_grant  it's assigning a second ownership grant, and leaving the old grant in place despite having enable_multiple_grants set to false.
Next quarter-ish is fine for us, as this is not really a blocker for us, just a non perfect setup.  Thanks for detailed info here Jan, was very helpful for me to trace what is happening here vs. on the snowflake side.


fix: wait for flush to finish

Refs: https://github.com/pinojs/pino/issues/1261

@mcollina PTAL

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

1 of 3 (33.33%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.1%) to 84.199%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

index.js
1
3
33.33%

Totals

Change from base Build<PHONE_NUMBER>:
0.1%

Covered Lines:
285

Relevant Lines:
330

💛  - Coveralls

@mcollina I added a test that fails on main

I would need to look into this with a couple of free hours. This logic is quite tricky. I'll get to it next week.

I have tried running the attached test to this PR and it passes on main.

I was able to repro with:
'use strict'

const t = require('tap')
const { join } = require('path')
const { file } = require('./helper')
const { createReadStream } = require('fs')
const ThreadStream = require('..')
const buffer = require('buffer')

const MAX_STRING = buffer.constants.MAX_STRING_LENGTH

t.plan(1)

const dest = file()
const stream = new ThreadStream({
  filename: join(__dirname, 'to-file.js'),
  workerData: { dest },
  sync: false
})

stream.on('close', async () => {
  t.comment('close emitted')
  let buf
  for await (const chunk of createReadStream(dest)) {
    buf = chunk
  }
  t.equal('asd', buf.toString().slice(-3))
})

stream.on('open', () => {
  t.comment('open emitted')
  stream.write('a'.repeat(MAX_STRING - 2))
  stream.write('asd')
  stream.end()
})

My bad, I made a mistake in the previous example. We emit 'ready' and not 'open'.
I cannot reproduce the problem using the attached test.

You are right I had no updated my local main.


ci: report test coverage to codeclimate

Description
This PR adds codeclimate coverage reporting to the push/pr pipeline. Additionally, the push_pr.yml file has been renamed to follow the same convention as other integrations.

It seems that the CodeClimate does not support Windows yet, which makes hard (if not impossible) to report test coverage as tests cannot run in linux. Leaving this on hold until we find a soluition.


Don't use elixir-europe/json-schema-validator library as a dependency

Steps:

Merge https://github.com/elixir-europe/json-schema-validator code to this repo
Refactor the code based on that library code

Implemented changes: https://github.com/elixir-europe/bio-validator/pull/4


Incorrect country code for New Zealand

Hi. Fix the problem with a New Zealand phone code. In JSON, it is "+24". In real, it is "+64".
Because now I have collisions with other countries which code starts on "+24..."
https://en.wikipedia.org/wiki/Telephone_numbers_in_New_Zealand

Hi I'll take a look and launch a fix


Change Travis to use ci-helpers

This is based on an initial effort by @josePhoenix with some follow-up on my part. It updates the .travis.yml to use the newer ci-helpers infrastructure, which is generally easier to read because it's build around shell/python scripts instead of arcane .travis.yml machinery.
Note that this also removes the setup_requires from setup.py - that's necessary to get egg_info to run without trying to install numpy.  This is definitely important behavior in certain contexts, so I think it's desired, but it's possible that it has some unintended consequences if poppy is doing something unusual.  I suspect, though, that it's a throw-back to before the astropy-helpers, when all of its machinery was packaged as part of astropy itself.

Oh, and in its current form this doesn't do coveralls... let me know if I should turn it on (I wasn't clear on whether poppy is actually using it or not)

POPPY was set up at one point to use Coveralls. It seems to have come back to life with a recent change to the test infrastructure, so we'd like it to work. May be out of scope.
My concern with this .travis.yml is that it works but still does the wrong thing (namely installing enum34 in situations where it will clobber a standard library module). (To be fair, the current build does that too, which is part of why it works.)
I can see how I would hack Travis with some environment variables and conditionals to install more stuff, but I cannot see how to express such a conditional dependency with the Astropy CI helpers.

namely installing enum34 in situations where it will clobber a standard library module

Are you sure it clobbers the stdlib module?  I just tried installing it in py 3.5 and it appears the stdlib module takes precedence...
I could also modify this to only use enum in the 2.7 versions, though, if you like.  The problems we were seeing before I think were due to the setup_requires bits, not an enum dependency problem.

Coverage remained the same at 64.518% when pulling 6194fff7cd39d8b26bf36a246d04240c22d7abb8 on eteq:travis-ci-helpers into b3852afcd4393d8463a3c0d7d23cd16d3c2a460c on mperrin:master.

Aha! the last commit there just turned coveralls back on, so that's working.  I'm speculating you want coveralls on py 3.5, but of course that's a trivial change to switch to 2.7.
Also, check out https://travis-ci.org/eteq/poppy/builds/161755807 for a version that only uses enum34 on 2.7 - I can switch this over to that if you like.

Coveralls on 3.5 is correct, yeah. Going to deprecate 2.7 as soon as astropy does, so everything should be in 3 by default.

ok, @mperrin is back on the list.  @josePhoenix, do you prefer the version that moves enum34 to only py27 (https://github.com/mperrin/poppy/compare/master...eteq:travis-ci-helpers-test) or this one?

I'm a fan of the one showing Python 2.7 customizations. Even if it's not strictly necessary, I suspect we'll grow more backported dependencies the further we get into Python-3-first development.

@eteq meanwhile I've started seeing a strange error in Travis on webbpsf related to astropy-helpers, see for instance https://travis-ci.org/mperrin/webbpsf/jobs/164074052
    /tmp/pip-build-YgWNZk/poppy/astropy_helpers/astropy_helpers/setup_helpers.py:100: AstropyDeprecationWarning: Direct use of the adjust_compiler function in setup.py is deprecated and can be removed from your setup.py.  This functionality is now incorporated directly into the build_ext command.
      'command.', AstropyDeprecationWarning)

Do you have any insights into what's causing that? It only happens on 2.7 but not 3.5, and it seems to have started recently for reasons that are unclear. Would this switch to ci-helpers fix that?

At risk of mixing up issues in different threads, I have a first whack at .travis.yml for WebbPSF with the helpers. Still needs some tweaks, but it's building on 2.7 now. https://travis-ci.org/josePhoenix/webbpsf/jobs/164089397


Rest API. Build Logs

Querying specific build information in response could on-demand include build logs
Probably partial response approach would be the best to reduces the amount of data returned
GET /api/v3/builds/:build?fields=id,logs(tail,100)

Builds logs is something which we want to include. However we first need build steps, since logs are for build steps.
Also we will not inline the logs in the object, but make it a separate endpoint.

Totally right, didn't occur to me


Feature/improve operation import scripts

Added Formating alignment For Policy import to align with StarterKit format
Added Reference to ConverTo-HashTable in assignment creation as was missing

@microsoft-github-policy-service agree

Relates to fix for #144
Relates to fix for #143


How to increase perfomance ? FPS dropped after big count elements (200+)

Hi, how to increase FPS ? Have any features ? I have stacked circles and after ~200 elements FPS start dropping without return.
Demo: https://codesandbox.io/s/matter-js-forked-ev6hzh?file=/src/App.vue
Debug:

Are you using Vue here? I'm told Vue watchers can cause general performance problems, see this comment https://github.com/liabru/matter-js/issues/1001#issuecomment-998888681 and let me know if that is the cause?

Are you using Vue here? I'm told Vue watchers can cause general performance problems, see the comments here #1001 (comment) and let me know if that is the cause?

Problem not with Vue. I make my code in vanilla js and get same result, drops after 130 elements:
(Vanilla JS) https://codesandbox.io/s/autumn-brook-uqc0ll
(Vue JS) https://codesandbox.io/s/matter-js-forked-ev6hzh
My system is Ryzen 2700x & 1660 ti (if it matters)
Results:
https://i.imgur.com/3PKnSB9.png
https://i.imgur.com/LTTu0Dm.png
Thats problem only if im using sprite. Without him i get drops only after 800 elements:

May be have optimization ways ?

In my case working solution it change randerer to pixi.js. Using pixi i get drops only after 1000 elements, and after recalculate mass it was returned to 50 FPS with, then after 300 elements has 40 FPS.

Its good result, but i dont want using others libs :(

Problem if using SVG texture for sprite. If using PNG texture - result is good

Ah thanks for confirming, then it looks like this is browser limitation and you'll need to probably draw the SVG to another canvas texture to cache it if I understand correctly - you can probably make a copy of Matter.Render and customise it for this at the cost of extra memory usage.
Since that is more of an advanced rendering feature it's a little out of scope of this project at the moment unfortunately though, so closing this one but thanks for looking into it as it's one I'll make note of.


feat: Ignore already open applications for Workspaces

Description of the new feature / enhancement
Instead of launching everything configured, it would be better if it only opened only applications that weren't already open.  I don't need a separate instance of things.
Scenario when this would be used?
Maybe something crashed, or this is on startup and some of the applications are open.  Having a single keyboard shortcut to get to my starting point without having to deal with potential duplicates and depending on the application to enforce single instance would be nice.
Supporting information
No response

It also would be nice if already open applications just get in the Focus / foreground

With respect to those who have commented, I like how the feature works as it is. I certainly wouldn't say no to another customize option that lets us pick whether to (1) always launch the app in question, or (2) merely bring it to the foreground if it's running.

There is a similar feature implemented in 0.87: https://github.com/microsoft/PowerToys/issues/34571.
You can configure your workspace to skip launching apps that are already running and move them to a designated location. Does that meet your needs? /needinfo