Visualization of merge sort and internationalization

Hello,
First of all, thank you very much for this tool! It's very nice to use... And you published it at a perfect timing, as I needed something like that for my job. So, thanks a lot!
I implemented a way to visualize the merge sort algorithm. Instead of trying to compute all the moves at once, I chose to progress step by step. That is, at the start, the implementation memorizes that the full array must be split. The first time next_step() is called, that split is performed and we memorized that, in the future, we will have to, in this order: split the first half of the array further down, split the second half, and, finally, merge both sub-arrays together. By repeating this recursively, we cover the whole array.
I wrote documentation in the code that explains the main steps (and the not-obvious operations to apply).
Due to my specific needs, I also added functions that dictate whether a sorting algorithm (or a visualizer) is "enabled". If this function returns false, it does not appear in the popup. I think it's more convenient than having to move files.
Finally, I added a simple way of supporting internationalization. Instead of writing the texts in the code, they are written in a CSV file. Thanks to Godot's nice features, it is very easy to use. If you want to add a brand new text, you simply have to add a new row in the CSV file with a specific key, say KEY. In the code, use tr(KEY) to ask Godot to fetch the appropriate text, according to the user's locale.
I only added French but other people can quickly add their languages, if they need so.
If you see anything that should be changed, let me know!
Thank you again for your work!

Hello,
Thank you for your answer! I totally agree with the issues you mentioned.
If you do not mind waiting, I can work on the issues you mentioned on April 1 (this is not a joke) as I will be quite busy until then. Sorry for making you wait!

that's fine I understand, take as much time as needed and thank you for your help!

hey @DocSkellington it's all good there is no time pressure for this,
I can't thank you enough for all your work! the new font is that one thing I didn't know I needed, it's much better and more compatible than the old, the whole language system is really well done, as someone who's never done any localization before I had to go back and read the docs to understand how it all works, and now I realize how well it is all put together, I couldn't have designed it any better myself, great work!
one thing I want to mention which is the is_enabled() function in sorter.gd and visualized.gd, I am a bit confused about how it's supposed to work, we currently check for it in files_tracker.gd when adding sorters/visualizers but the function always returns true in all classes, and I can't think of a case where we would want to return false other than in the base classes sorter.gd and visualizer.gd that's why I was confused about the if curr_dir != "sorter.gd" part before. of course this is no big deal and things work just fine as they are, yet correct me if I'm wrong but it feels like is_enabled() is not really contributing anything to the rest of the app, that's why I suggest we use it to exclude the base classes unless you have another purpose in mind, but again, it's just a small thing that's I'm curious about.
other than that, I'm happily ready to merge this PR, and thanks again for your help!

Hi!
The point of the is_enabled() was to allow a user to quickly disable a sorter or a visualizer without needing to rename the files. In retrospect, I agree that the way I wrote it for this pull request is not really useful. So, here are the updated commits to disable the base classes and "simplify" files_tracker.gd.
Again, thank you for your work!

@DocSkellington I think I've prolonged this enough,
everything looks good now and I'm very happy with all the improvements you've made,
however there is one issue that, I'm just kidding :smile: it's all good now, I'm merging this bad boy
thank you for your contribution, you're awesome!


Logic-Boolean tests don't pass

In some cases this is because of Squeak vs. Pharo idioms, e.g.

x and: [] and: [] -> (x and: []) and: []
self needsWork ->  self flag: #todo
only -> anyOne (and a size check)

However, there seem to be some actual bugs as well.

Both comments & tests for Logic-Boolean were insufficient.  After stumbling around for a while trying to fix everything simultaneously, I created the groundhog repo parallel to trike.  My plan is to gradually copy Logic-Boolean functionality to that repo, making sure there is a working Spec UI and complete tests for both the model and the UI.  Some interfaces are changing due to my slightly better understanding of Boolean logic.
When all of Logic-Boolean works in groundhog, I'll merge it into the main Trike repo, including the cleaned change history and replacing the current Logic-Boolean implementation.


Create a NFT smart contract

Hey @emilyJLin95 should we merge this PR?

@httpJunkie
I merged it and then reverted
I forgot we're not actually merging things -> it's supposed to be like scaffold-eth where you choose your flavor of dapp


web_modules path

Using parcel-bundler, is there a way to define where web_modules is stored on the server, so that a line like
import { onMount } from "/web_modules/svelte/internal.js";

is replaced with:
import { onMount } from "/web_root/web_modules/svelte/internal.js";

PS: I can't load https://www.pika.dev/npm/snowpack/discuss/new as I get the following error:
browser.js:4371 ReferenceError: require is not defined
    at PackageCreateDiscussionPage.js:15

Sorry about that, the bug to post has been fixed! will respond in your discussion thread


If using lazy cachers in a --dry run and the cached output doesn't already exist, run errors out

Unclear on the best way to deal with this, --dry implies we aren't allowed to write to the cache, but a lazy cacher requires the ability to move something into cache if not already there.
Presumably, if this situation arises, the lazy instance should refuse to unload the data and keep it in memory.

Plan for now can be to leave in memory and throw a warning

This actually isn't reasonably feasible - since we allow for "unresolved" lazy instances, you can't just replace the output with the thing itself because there may be later stages that are explicitly expecting to have access to the cacher. A true fix for this likely won't be possible until the #58 API changes are made, since an Artifact would then be specified as needed on the input side rather than assuming a nonresolve lazy on the output side.


Don't implement GeometryArrayTrait for Coord arrays?

This is fixed now, I think from the split from GeometryArrayTrait to NativeArray and SerializedArray: https://github.com/geoarrow/geoarrow-rs/pull/781


Use new Document intent to import Pubkeys

Coverage decreased (-0.1%) to 34.158% when pulling 252cca1cd003feedefd7090471d9c1117a2d00dc on kruton:open-doc-import into 20f0daa6a68c2f7cc2f09e1abb6e3d9414e0a4be on connectbot:master.


Updated dependencies and removed ts-ignores

Pull Request Test Coverage Report for Build 54

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 52:
0.0%

Covered Lines:
19

Relevant Lines:
19

💛  - Coveralls


ActiveMQ User Resource is missing

What problem are you facing?
We want to use ActiveMQ in the official provider (mq.aws.upbound.io/v1beta1). We noticed that the official provider does not have a User API.  The inline user configuration will not help because of the following comment MQ does not return broker users preventing this resource from making user updates and drift detection. https://marketplace.upbound.io/providers/upbound/provider-aws-mq/v1.3.1/resources/mq.aws.upbound.io/Broker/v1beta1#doc:spec-forProvider-user
And the Broker is missing a status that returns the log group names.
Both of these features are integrated in the community providers and it would help us a lot if we could have similar features with the official provider.
Is it possible to integrate these features into the official providers?

How could Official AWS Provider help solve your problem?

Some pointers for reference:

Terraform registry: aws_mq_broker
terraform-provider-aws: mq/broker.go
AWS SDK for Go V2: MQ

We took an initial look at this:

As @haarchri states in the description, the UpdateBroker operation in the Amazon MQ REST API does not allow updating the broker users (please search for the definition of UpdateBrokerInput object in the given link). So while one can provision broker users (with some constraints on RabbitMQ) using the CreateBroker operation, it's not possible to update them via the UpdateBroker operation.
So, it's not possible to manage (drift detection/updates) the existing users of a broker via the Broker.mq MR.
Regarding the general log group, it's already available in the DescribeBroker output (please see the LogsSummary schema). However, the Terraform AWS provider does not extract that information from the SDK response and the Terraform resource schema does not have a corresponding attribute.

@ulucinar in the community provider-aws we have a ActiveMQ User Resource - so we could implement the resource her too without tf ?

Hi @haarchri,
We are on it. @mergenci has started investigating how to implement the broker user resource.

@haarchri, I was able to create, update, and delete ActiveMQ (not RabbitMQ) users, in the current provider version, using MQ Broker resource's embedded user field. RabbitMQ users cannot be managed neither using Terraform nor using AWS APIs.
I'm sharing the detailed steps below, to avoid any confusion. Does this address your needs?
Note that the reconciler enters an update loop upon applying any user updates, because updates won't take effect until next scheduled maintenance period or manual reboot of the broker.

Apply the following manifest (requires EC2 provider as well):

apiVersion: mq.aws.upbound.io/v1beta1
kind: Broker
metadata:
  annotations:
    meta.upbound.io/example-id: mq/v1beta1/broker
  labels:
    testing.upbound.io/example-name: test-issue-1264-activemq-broker
  name: test-issue-1264-activemq-broker
spec:
  forProvider:
    # Due to an existing Terrajet limitation, we cannot use "metadata.name" for "brokerName"
    # Details can be found in https://github.com/crossplane/terrajet/issues/280
    brokerName: test-issue-1264-activemq-broker
    region: us-west-1
    securityGroupRefs:
    - name: test-issue-1264-mq-securitygroup
    engineType: ActiveMQ
    engineVersion: 5.17.6
    hostInstanceType: mq.t3.micro
    user:
    - passwordSecretRef:
        key: password
        name: test-issue-1264-mq-secret
        namespace: upbound-system
      username: admin

---
apiVersion: v1
kind: Secret
metadata:
  annotations:
    meta.upbound.io/example-id: mq/v1beta1/broker
    uptest.upbound.io/pre-delete-hook: testhooks/delete-broker.sh
  labels:
    testing.upbound.io/example-name: test-issue-1264-mq-secret
  name: test-issue-1264-mq-secret
  namespace: upbound-system
type: Opaque
stringData:
  password: "Upboundtest!"

---
apiVersion: ec2.aws.upbound.io/v1beta1
kind: SecurityGroup
metadata:
  annotations:
    meta.upbound.io/example-id: ec2/v1beta1/securitygroup
  labels:
    testing.upbound.io/example-name: test-issue-1264-mq-securitygroup
  name: test-issue-1264-mq-securitygroup
spec:
  forProvider:
    region: us-west-1
    description: Allow TLS inbound traffic
    name: allow_tls
    tags:
      Name: allow_tls

To test creation of a user, edit the broker resource and add the following block to spec.forProvider.user:

- consoleAccess: true
  passwordSecretRef:
    key: password
    name: test-issue-1264-mq-secret
    namespace: upbound-system
  username: testuser

Observe the user created in MQ Console.
Reboot the broker from MQ Console, for new user creation to take effect.
To test update of a user, edit the broker resource and set consoleAccess: false for the previously created user.
Reboot the broker from MQ Console, for user update to take effect.
Observe that “Console Access” has been disabled in MQ Console.
To test deletion of the user, edit the broker resource and simply remove the whole block that we introduced above.
Again, reboot the broker.

Released with https://github.com/crossplane-contrib/provider-upjet-aws/releases/tag/v1.5.0


Issue 176 beyond editorial object

Here is the pull request related to #176 I am working on.

@JuergenGrupp do you think this pull request is covering your ideas?
For the trailer and "the production of ..." concepts, I just added two new concepts. "Promotes", and I extended the topic property to have a program as a filler for the triple.
I am not sure if we need more specific properties, the generic properties are covering most of the relations on the right side of the diagram.

Added missing classes and added the relations not covered.

Looks very good, thank you!
little typo: an "i" is missing in "CampagnPackage", should read "CampaignPackage"

Oops, was I thinking of the drink?


Navigation and footer update

@Mikivitkovski don't forget to resolve the issues in the PR when you fix them.


Problem with loading images.

Hello.
Localhost (xampp) works perfectly without flaws but when published it on an online server (apache 2.4, php 5.4) this does not work, only load one or two images, and do not charge more.
Because is this?, the code is the same that I use on localhost, all within the same domain and sub directory.
I hope someone can help me.
P/d: My English is not very good.
Link: https://www.voorpret.cl/public/api/lafayette/0/
Many thanks in advance, regards atte: Max Bizera.

I've changed the images to an external server and in this way it works.
The question is: How do I make it work with the images on the same server?


CI: test load dump in binary format

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


fade drawer based on percentage open, baseline of 50%

On updates to the drawer appearance set the alpha between .5 and 1 based on the percentage the drawer is open

oops! wrong branch.


Oracle 9i - ORA-00923 Error

Hello.
Some times there are tables and views with bad column naming. For example this one table schema:
CREATE TABLE DB2REST.TEST_BAD_COLUMNS
(
  ID                         INTEGER,
  NAME                       VARCHAR2(50 BYTE),
  "Bad Varchar Column Name"  VARCHAR2(50 BYTE),
  "Bad Int Column Name"      INTEGER
)
TABLESPACE USERS
PCTUSED    0
PCTFREE    10
INITRANS   1
MAXTRANS   255
STORAGE    (
            INITIAL          64K
            MINEXTENTS       1
            MAXEXTENTS       UNLIMITED
            PCTINCREASE      0
            BUFFER_POOL      DEFAULT
           )
LOGGING
NOCACHE
NOPARALLEL
NOMONITORING;

When you have such tables or views and you try to get them via the API, it throws an error:
{
	"type": "https://github.com/kdhrubo/db2rest/generic-error",
	"title": "Generic Data Access Error",
	"status": 400,
	"detail": "ORA-00923: FROM keyword not found where expected\n",
	"instance": "/TEST_BAD_COLUMNS",
	"errorCategory": "Data-access-error",
	"timestamp": "2024-04-16T14:05:12.952434229Z"
}

This is because the query db2rest tries to run in the database is like that:
SELECT * FROM (
    SELECT
        TEST_74.ID
        ,TEST_74.NAME
        ,TEST_74.Bad Varchar Column Name
        ,TEST_74.Bad Int Column Name
    FROM
        DB2REST.TEST_BAD_COLUMNS TEST_74

)
WHERE ROWNUM <= 100

For these cases the bad column names must be quoted like this to run successfully the query:
SELECT * FROM (
    SELECT
        TEST_74.ID
        ,TEST_74.NAME
        ,TEST_74."Bad Varchar Column Name"
        ,TEST_74."Bad Int Column Name"
    FROM
        DB2REST.TEST_BAD_COLUMNS TEST_74

)
WHERE ROWNUM <= 100

@kdhrubo I would hope we are always creating SQL SELECT statements that are always double quoting column names?  And simply inform (document) that we pass along quoted column names, and so column names will always be recognized as case sensitive.  What do you think?  Although creation of objects because more strict as well if double quotes are used for their creation.

Actually there is no use of double quotes in column names ?
Is it suitable for all databases ?

So for all db column names and table names should be in quotes ?

delimited identifiers - delimited meaning they have a token at their start and end.  Typically a " double quote.

yes, the only special case that comes up is with Unicode.
PostgreSQL has the U& prefix before the delimited identifier.  So,
SELECT U&"\0441\043B\043E\043D" FROM my_table

Double quotes wont work for mysql its back tick.

Can confirm. Latest version 0.3.0 is working fine.
Have in mind for Microsoft SQL server, when you support it, i think the default way to escape column names are by using the square brackets like this [column name]


Support for multiple plex servers

Option to support now playing/screening and on-demand on multiple plex servers.

I think the way to solve this is to just run a second instance of Posterr for the other plex server.


Is lack of "dump()" support intentional?

We're using this library with flask-smorest (and marshmallow of course!), and quite impressed with the out-of-the-box support for GeoJSON.
We did run into a big surprise though, as it appears that these schemas only implement the load/loads interfaces (with the fancy sub-schema selector logic), and do not implement the corresponding dump functionality. When we call .dump() with a GeoJSONSchema object, it just returns an empty dictionary (via the base Marshmallow schema method).
So I'm wondering if I'm missing something (being new to the marshmallow ecosystem), or perhaps dump wasn't the needed for the original use-case?
As an aside, I cobbled this together to simulate a proper dump method, while still leveraging this library's dynamic schema handling:
class GeoJsonSchema(marshmallow_geojson.GeoJSONSchema):

    def dump(self, obj: typing.Any, *, many: bool | None = None):
        # Do a JSON dance to convert Python-ized JSON to proper JSON
        return json.loads(
            json.dumps(
                # This is the interface supported by library. It returns a Python-ized JSON dictionary
                self.load(obj, many=many)
            )
        )

So wondering if anyone else has run into this before, or has advice?
It does seem like it may be straightforward to build out the dump methods following the load patterns.

Hi. Good point. In my practice, I usually needed to load GeoJSONS data, do validation and put it in the database. The suggestion to implement dump looks interesting. I will not be happy if you offer a pull requests.

@folt wow, you beat me to it!  Thank you very much :)


Don't share the session id between tabs

Just thought about it but we should clear the sessions when the file watcher picks up a change in the user developer's code. Currently we just reload the config and the browser, but now the session will be resumed. As a developer I would expect to start from a fresh start every time I change something in my code.


Assorted spelling fixes

exression -> expression
egal or upper -> greater than or equal
upper than -> Greater than or equal

Thx for your contribution.
I'll fix it manualy because too many change in 0.9.1


Add static build for macos

This PR adds support for building static wasmvm (universal) for darwin.
Here at Nibiru we would like to provide binaries for both linux and darwin, without requesting users to manually install libraries. We are aware that going fully static on macOS is hard (if not impossible), and we still need to link dynamically to system libraries, but at least libwasmvm can be statically linked to our executable.
With this changes, we can use a simple goreleaser config and goreleaser-cross to build binaries to all platforms.
NOTE:
I have included the built library under internal/api/static to make builds easier. But it is huge. If you prefer I can remove it and remove the cgo LDFLAGS and we add the flags to our build config instead.

@webmaster128 after this is merged, would it be possible to backport this to v1.2.0? Even it is just built and published in release assets would be nice.

This was merged right before the 1.2.1 release. So it should be usable now. Could you try it out? See https://github.com/CosmWasm/wasmvm/issues/407 for follow up discussions on that topic.


Add some type annotations

Description
Add some type annotations
Checklist

[x] I have read the contributing guide and understand what's expected of me
[x] I have signed the CLA
[x] I have run this code in development and it appears to resolve the stated issue
[x] I have opened an issue to add/update docs, or docs changes are not required/relevant for this PR
[x] I have run changie new to create a changelog entry

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 64.29%. Comparing base (00fbf91) to head (05acc41).

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #156      +/-   ##
==========================================
+ Coverage   64.27%   64.29%   +0.02%
==========================================
  Files          51       51
  Lines        3191     3193       +2
==========================================
+ Hits         2051     2053       +2
  Misses       1140     1140

Flag
Coverage Δ

unit
64.29% <100.00%> (+0.02%)
:arrow_up:

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

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Added trenz docs logo and removed nav tree pin button

Embrace the swarm!

Technically, that's two unrelated changes. :-p


Add input history window

This feature allows users to view their history input, pin useful expressions, and combine several expressions to one string expression(useful if you want to watch multiple expressions in one monitor window)


[Perf] Reduce SelectListItem and other allocations when generating HTML for select lists

Fixes #3953
The changes include

Cleaning up Linq and Linq to SQL like  usage in MultiSelectList.cs
Caching the List in MultiSelectList that will be used when getting the Enumerator
Removing the Groupby operation in DefaultHtmlGenerator.GenerateGroupsAndOptions
Remove the defensive deep copies of SelectListItem done in DefaultHtmlGenerator.GenerateSelect

Scenario: https://github.com/aspnet/Performance/tree/dev/testapp/BigViews
Before Optimization

After Optimization

Gain: ~30% reduction in total allocated bytes and total allocated objects.

Why did the CI builds fail?

:watch:

On the day I created the PR, the dev branch was having two failures in the functional tests which are what shown by the CI.

:up::date:

:shipit:


Add better descriptions to the free gait action feedback

Solved in #21. The output should be ignored (not shown in the GUI) if it is empty.


[SSR ]update warning message about runtime/standalone builds

Currently, SSR will warn like this when a standalone build is used in the SSR bundle:

[vue-server-renderer] You are using the standalone build (vue/dist/vue.js) for server-side rendering. It is recommended to use the CommonJS build (vue/dist/vue.common.js) instead so that the code can run in production mode by setting NODE_ENV=production. The server renderer supports the template option regardless of what build you are using.

After the new build introduced with Vue 2.1, this should probably read:

[vue-server-renderer] You are using the standalone build (vue/dist/vue.common,js) for server-side rendering. It is recommended to use the runtime-only CommonJS build (vue/dist/vue.runtime.common.js) instead so that the code can run in production mode by setting NODE_ENV=production. The server renderer supports the template option regardless of what build you are using.

Actually with the new dist file setup, users will most likely be using CommonJS builds by default, so this check is no longer necessary.


gobrew self-update always updates

Previously when running gobrew self-update the tool would check for updates and if found would update the tool, otherwise it would report no update available and that you are already up to date.
Currently when running the above command the tool always seems to download and report 'Upgrade successful' even though no new version has been posted.
Can you please investigate?
Expected behaviour is to run this command and if an update is available then download and upgrade, otherwise do not download approx 6Mb unnecessarily.
Kind regards

lol, yea you are right.

probably next weekend :)

Fixed
╭─pulkit.kathuria@JP-GCJKVGQK0G ~/git/re ‹master›
╰─$ gobrew self-update
Downloading 100% |███████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| (6.0/6.0 MB, 2.8 MB/s)
Upgrade successful
╰─$ gobrew version
[INFO] gobrew version is 1.8.5

╭─pulkit.kathuria@JP-GCJKVGQK0G ~/git/re ‹master›
╰─$ gobrew self-update
[INFO] your version is already newest


Add --store-ledger option to db-analyser

Consider a chain downloaded by cardano-node. While getting the chain, the default disk policy created two snapshots on disk
$> ls -h db_mainnet/ledger
13916582  14776127

Now we can ask db-analyser to also create a snapshot of ledger at slot 13916582 - while processing the chain - and store it. The name of the file will be 13916582_db-analyser.
(please note that by providing a suffix _db-analyser we ensure that the snapshot will not be deleted by node in the future)
cabal run ouroboros-consensus-cardano:db-analyser --  \
  --db db_mainnet cardano \
  --configByron dbacfg/mainnet-byron-genesis.json \
  --configShelley dbacfg/mainnet-shelley-genesis.json \
  --nonce 1a3be38bcbb7911969283716ad7aa550250226b76a61fc51cc9a9a35d9276d81 \
  --configAlonzo dbacfg/mainnet-alonzo-genesis.json \
  --store-ledger 13916582

Once the node is done with its work we can see that the snapshot is created.
ls -h db_mainnet/ledger
13916582  13916582_db-analyser  14776127

We can now compare if snapshot created by node is identical to the one created by db-analyser
&> cmp db_mainnet/ledger/13916582 db_mainnet/ledger/13916582_db-analyser \
&& echo 'success' || echo 'failure'

success

I've just finished running the tool against longer chain that also holds alonzo blocks, and everything works as expected
λ cmp db_mainnet_with_alonzo_40217333/ledger/40174168 db_mainnet_with_alonzo_40217333/ledger/40174168_db-analyser && echo 'success' || echo 'failure'

success

bors merge


GridSearch::CheckConstraints use grid_xy to do collision check with cartisian  line_segment obstacle

bool GridSearch::CheckConstraints
do collision check use gridindex in node2d and line segment obstacle in cartesian.

bool GridSearch::CheckConstraints
do collision check use gridindex in node2d and line segment obstacle in cartesian.

Hi Hoppss,
Thanks for your comment.
GridSearch just conducts standard A* search to get cost of each Node2d. I couldn't tell any unreasonable reasons to check collision in Cartesian.

bool GridSearch::CheckConstraints
do collision check use gridindex in node2d and line segment obstacle in cartesian.

Hi Hoppss,
Thanks for your comment.
GridSearch just conducts standard A* search to get cost of each Node2d. I couldn't tell any unreasonable reasons to check collision in Cartesian.

Hi,
Thanks for your response.
Node2d xy is grid index, but it is used to do collision check obstacle linesegment while obstacle is at cartisian coordinate ?


The include pre-release checkbox on NuGet.org should default to off state

We should not promote pre-release pacakges on NuGet.org. When users search for packages, we should promote stable versions only - unless they know what they are opting into (in which case they can check the box to be on).

Will wait for more community feedback on this.

Ideally,

By default the pre-release checkbox should not be selected
We should remember the checkbox selection for a user (using cookie) otherwise its a pain for user to select/unselect.
Clicking on a package in the search results should take me to:

Take the user to the latest stable version, if the pre-release box is not selected
Take the user to the latest pre-release version, if the pre-release box is selected

We probably need to figure out how many packages have pre-release only versions (i.e. no stable version present) and their popularity, to estimate the amount of people that will not find their packages if uncheck that checkbox by default.

@agr Agree, we should look at the % and that's applicable for 1.
2 and 3 can be done in either cases.


RPCCore$RPCException: UTFDataFormatException: encoded string too long

I'm trying to run my Scala.js tests and something is failing but the jsenv is only providing me with this:
[error] stack trace is suppressed; run last Test / executeTests for the full output
[error] (Test / executeTests) org.scalajs.testing.common.RPCCore$RPCException: java.io.UTFDataFormatException: encoded string too long: 65816 bytes

This error message doesn't help me at all. I really need to see what the test failure was. I'm in a position now where I have no idea which test is failing, let alone why.
I believe this is due to some limit in the WebSocket spec when you close a connection with a message right? Could you please, please, please either

send a message with the full error msg in it before closing, or
send a truncated message back so I can at least see the bulk of the error.

Thanks!!

Dupe of #3667?

Ah my bad. I'll close this one.


GridMap: Fix physics_material property

Use computed bounce and friction, just like StaticBody3D already does.
Also don't rebuild all internals just to set two floats on each body.

Fixes https://github.com/godotengine/godot/issues/90490

Reminds me that having a single physics material for the entire GridMap was a not very sound decision. Should have been really a property of the item.

@smix8 At least the property is called physics_material and not physics_material_override like on StaticBody3D.
It would be possible to add a per-item override. (I would wait for someone to propose it.)
Another idea I heard was making physics materials per-shape, but that's more involved.
(The per-GridMap-item override could be implemented either way.)

Thanks!

Thanks for the quick work on this, it will make a big impact on my current project.


PAPP-30822: Updated requests modules

According to this thread we can ignore the prodsec failure

Cloud - https://cd.splunkdev.com/phantom-apps/app-tests/-/pipelines/13663130
Current - https://cd.splunkdev.com/phantom-apps/app-tests/-/pipelines/13750823
Next -  https://cd.splunkdev.com/phantom-apps/app-tests/-/pipelines/13685166
Previous - https://cd.splunkdev.com/phantom-apps/app-tests/-/pipelines/13750908

Due to an authorization issue ran all pipelines manually
also, there is a data-related issue that needs pytest fix so, will create a ticket for same
hence, merging it


Unable to claim drops, crashes

The app properly watches the streamers and gets the channel points but seems unable to then claim the drops, it errors terminating the application and requests me to close the window.

Please see the pinned issue: #40


Bump version to v1.17.26

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 81.6%. Comparing base (9b22f28) to head (8ef8b88).

Additional details and impacted files
@@           Coverage Diff           @@
##            v1.17     #168   +/-   ##
=======================================
  Coverage    81.6%    81.6%
=======================================
  Files         806      806
  Lines      219096   219096
=======================================
+ Hits       178853   178864   +11
+ Misses      40243    40232   -11


Update CustomTMS examples use of default tiles.

Removes the use of Map.default_tiles which was removed in Release 0.7.0.

LGTM!

Thanks


No permission dialog

I using very simple script to request permission, but I always getting permissionDenied callback. Also IsPermissionGranted always return false, even when I set permission in application settings.
App built  with 26 API, and I have installed firebase messaging plugin, that uses custom activity. Tested with meizu U10, maybe problem with flyme.
What I doing wrong?
private static string[] PERMISSIONS =
    {
        "INTERNET",
        "ACCESS_NETWORK_STATE",
        "READ_PHONE_STATE",
        "ACCESS_WIFI_STATE",
        "ACCESS_FINE_LOCATION",
        "ACCESS_COARSE_LOCATION",
    };

    private IEnumerator Start()
    {
#if UNITY_ANDROID //&& !UNITY_EDITOR
        foreach (string p in PERMISSIONS)
        {
            if (!AndroidPermissionsManager.IsPermissionGranted(p))
            {
                Debug.Log("No permission: '" + p + "'\nRequest for permission. " + Time.frameCount);
                bool granted = false;
                bool gotCallback = false;
                AndroidPermissionsManager.RequestPermission(new string[] { p }, new AndroidPermissionCallback(
                    grantedPermission =>
                    {
                        gotCallback = true;
                        granted = true;
                    },
                    deniedPermission =>
                    {
                        gotCallback = true;
                        granted = false;
                    }
                    ));

                while (gotCallback == false)
                    yield return null;
                if (granted)
                {
                    Debug.Log("Permission '" + p + "' is granted. " + Time.frameCount);
                }
                else
                {
                    Debug.Log("Permission '" + p + "' is denied! " + Time.frameCount);
                }
            }
        }
#endif

    }

I can think of 2 possible problems:

You have to add the permission to the Manifest as well, dont forget that
You have at some point denied the permission and checked "[X] Dont ask again", so to revert that you have to open Settings -> Apps -> your app -> then change the permission there

INTERNET is not a dangerous permission, no dialog is needed, it's granted automatically.
https://developer.android.com/guide/topics/permissions/overview#permission-groups


Remove brackets - feature request

I would like a script to remove the bracketed information in a filename.
I tried to modify one of the existing scripts with
rename 's/\s*([^)]+)//g' "$filename"
but keep getting an error log.
The ultimate goal is to turn (for example )...
DD WRT Router Configuration Part 1 (720p_30fps_H264-128kbit_AAC).mp4
into
DD WRT Router Configuration Part 1.mp4
All help appreciated.

Hello @frayja2002 ! Thank you for using the scripts and for your detailed explanation of what you needed. I’ve implemented a script that removes the bracketed information in filenames, as you described. Could you test it in the new version and let me know if it works as expected? Your feedback would be greatly appreciated! 😊
Check the script:
https://github.com/cfgnunes/nautilus-scripts/blob/main/Rename files/Remove brackets

I have tested this on various files on my HDD & seems to work exactly as expected.
Your quick response & assistance with this is much appreciated.
Thaks
Alex


updating 1.2.2 to version 2.1.1 is giving a could not find declaration file for module /@angularclass/hmr'

Updating my dependencies I came across this error when updating from 1.2.2 to v 2.1.1 produces this error
[at-loader] ./src/app/app.module.ts:7:69
TS7016: Could not find a declaration file for module '@angularclass/hmr'. <EMAIL_ADDRESS>implicitly has an 'any' type.

The typings setting in package.json is missing. The typings are distributed correctly as it looks.

I have the same issue, the PR works for me.

Is anybody going to merge this and make this a new version?

merged as<EMAIL_ADDRESS>


[BUG] transport interface for wolfSSL

Describe the bug
transport_wolfSSL.c include application include file...
it include "user_settings.h" and "demo_config.h"
in wolfSSL, the user_settings.h file is included only when WOLFSSL_USER_SETTINGS is defined
regarding demo_config.h... it has nothing to do in this file... (same for the related code) this could keep the interface as a lib without user modification in it.
am i right in my expectation ?

this could keep the interface as a lib without user modification in it.

This is not a library but an implementation of transport interface which should be used as a reference. Feel free to update this file as per your application needs.

I am closing this issue. Feel free to reopen if you need anything from us.


retrieve data by byte offset and line position

Hi,
I guess you are aware of the https://github.com/circulosmeos/gztool project, which allows to index gz files including line information for random access data retrieval. Since I am using rapidgzip for full decompression and gztool for parallel random access decompression on a regular basis when working with fastq files, I would be very happy to have this combined in one tool. Can you imagine to implement it?

How exactly are you calling gztool? and, wouldn't ratarmount solve your feature request? It has rapidgzip as a backend and exposes a view to the decompressed file via FUSE. You can then use the usual POSIX APIs or dd to "extract"/copy from an offset. It would also have the advantage that the index stays cached in memory.

To e.g. get one line starting at the second one, I do something like echo -e "foo\nbar\nzar" | gzip -c | tee foo.gz | gztool -v 0 -f -i -x -C -I foo.gzi && gztool -v 0 -L 2 -R 1 foo.gz wrapped into GNU parallel. Ratarmount is my choice, when a tool requires uncompressed data, but in general I don't like to mount and unmount temporary directories all the time. I am also aware of dd capability of skipping bytes, but it is unsuitable if lines are composed of different numbers of bytes (wasn't this also the issue with general appliance of pugz?)

Ah ok, I was only thinking about byte offset. Lines are another matter altogether. And currently, the index does not store any line indexing information. However, I am working on a compressed and sparse index format and this feature request is in time to add line information as a consideration to the file. Alternatively, supporting gztool indexes would also be an option I would consider. I like when stuff like that (index compatibility) just works for the user. bgzip and indexed_gzip index files can already be loaded by rapidgzip.
I can imagine adding options like -L and -R. I already have "weird" options such as --count-lines and --count, which aren't solely for decompressing and indexing.

but in general I don't like to mount and unmount temporary directories all the time

Understandable. It also takes some runtime to set up a FUSE mount point and there are other difficulties. You could also do:
python3 -c '
import sys
import ratarmountcore as rmc
a = rmc.open(sys.argv[1])
name = next(iter(a.listDir("/").keys()))
f = a.open(a.getFileInfo("/" + name))
f.seek(10)
sys.stdout.buffer.write(f.read(5))
' test.py.gz

The rapidgzip Python-bindings can also be used directly, but then index saving and loading would have to be managed manually.
I am aware that this is too cumbersome for a solution. It would be nicer to have an option directly in the rapidgzip CLI.

wasn't this also the issue with general applicability of pugz?

No. That was only about the deflate block searching heuristic that wasn't stable and fast enough to work with anything other than "printable" characters and even then might fail because of false positives.

However, I am working on a compressed and sparse index format and this feature request is in time to add line information as a consideration to the file.

Sounds great.
In the meantime I made some interesting observation, I wonder weather you could comment on them (or even include them into your benchmark). Even tough, I did not turned off NUMA, cache effects and kept cpu frequencies constant, I can say, that the throughput/bandwidth when piping decompressed fastq data back into compression tools heavily depends on the used tool. Whereas I was not able to achieve more then 110MB/s for pigz (76 threads), the maximum throughput of 400MB/s was gained by using rapidgzip on 8 threads streamed into bgzip with 32 threads.

In the meantime I made some interesting observation, I wonder weather you could comment on them (or even include them into your benchmark). Even though, I did not turned off NUMA, cache effects and kept cpu frequencies constant, I can say, that the throughput/bandwidth when piping decompressed fastq data back into compression tools heavily depends on the used tool. Whereas I was not able to achieve more then 110MB/s for pigz (76 threads), the maximum throughput of 400MB/s was gained by using rapidgzip on 8 threads streamed into bgzip with 32 threads.

I don't think that I entirely understand your benchmark. Are you doing rapidgzip -d -c -P 8 | pigz and rapidgzip -d -c -P 8 | bgzip? How fast are pigz and bgzip without any decompression going on, i.e., a simple cat | pigz? Is there still a difference between bgzip and pigz? Is there a difference topigz <file>? How is CPU utilization? I tried with a small 888 MB perf.data file cat prf.data | pigz is 5x faster than bgzip, so it seems that I cannot reproduce your results. In general, I think that in the range of < 1 GB/s, caching and NUMA shouldn't come into effect yet, but it might depend on the system. Rather it seems as if pigz doesn't parallelize at all. 110 MB/s seems very slow. My 888 MB compressed-decompressed-and-compressed-again time pigz -c perf.data | rapidgzip -d -c | pigz > /dev/null takes ~5 s on my notebook with 8 cores (x2 for hyperthreading).

Are you doing rapidgzip -d -c -P 8 | pigz and rapidgzip -d -c -P 8 | bgzip?

exactly. I am on an AMD EPYC 7513 with an NVMe that should be capable of 7BG/s reading. cat  /dev/null makes 2GB/s, pigz -p 2 -kcd and bgzip -@ 2 -kcd around 400MB/s. rapidgzip > /dev/null makes 1.8GB/s. cat | pigz -c > /dev/null maxed out at 48 compression threads resulting in 800MB/s. bgzip -@ 42 -c > /dev/null achieved 900MB/s. pigz | pigz and pigz | bgzip reached 90MB/s. rapidgzip | pigz for 1 to 32 decompresison threads and 1 to 128 compression threads berformed best at rapidgzip -P 4 | pigz -p 76 resulting in 110MB/s. rapidgzip -P 8 | bgzip -@ 32 resulted in 200MB/s and rapidgzip -P 8 --import-index | bgzip -@ 32 in 400MB/s.

This took a bit longer and more code lines than I thought, especially the newline logic. And it still could benefit from many more unit tests, but at least there are some.
Issue #10 is still not implemented, therefore working with large gztool indexes to extract only very small amounts of data is not recommended because the index is always read fully into memory. However, the option to specify multiple ranges should help to alleviate this. Else, the other way around: creating indexes with rapidgzip and accessing lines or byte offsets via gztool could be a viable option.
I have not yet merged it. It would be helpful if you could give it a try. There might still be bugs with the newline features. You can install it with:
python3 -m pip install --force-reinstall 'git+https://github.com/mxmlnkn/indexed_bzip2.git@develop#egginfo=rapidgzip&subdirectory=python/rapidgzip'

Wow, you made it - this is super cool.. fast decompression with an offset! As far as I can tell you, I didn't observe any issues so far.
But I'd like to add minor recommendations.

When a user wants to decompress from, lets say line 4000 to the very end of file, currently one has to do something like
--ranges 999T@4000L or --ranges 99999999L@4000L. Maybe something like inf@4000L or simply @4000L could be useful?
--count and --count-lines options could profit from a gztool index as well, since gztool -l </path/to/indexed/gz> has this information included
Do you think the gztool index and rapidgzip index could be used or even fused together some when in the future, for an even more efficient decompression?

followup: index creation from stdin does not work anymore. rapidgzip now complains All window sizes must be at least 32 KiB or empty!

1. When a user wants to decompress from, lets say line 4000 to the very end of a file, currently one has to do something like
   `--ranges 999T@4000L` or `--ranges 99999999L@4000L`. Maybe something like `inf@4000L` or simply `@4000L` could be useful?

[ ] Ah yes. I remember thinking about it at some point but then forgot.

2. `--count` and `--count-lines` options could profit from a gztool index as well, since `gztool -l </path/to/indexed/gz>` has this information included

[ ] I thought I had something like that implemented for --count already, but that doesn't seem to be the case (anymore). But yes --count-lines can also have a fast path for gztool indexes.

3. Do you think the gztool index and rapidgzip index could be used or even fused together some when in the future, for an even more efficient decompression?

[ ] Yes, I think I already mentioned it further above. I am working on yet another index format because I also found some small nitpicks with gztool indexes. I have started it here https://github.com/mxmlnkn/indexed_bzip2/blob/fbec01816f386810f392b7ebef9506acc5a0e8e1/src/rapidgzip/IndexFileFormat.hpp#L223 but I want to wait for the LZ4 implementation to see whether the format is sufficiently generic. I am not sure what you mean with "even more efficient decompression". The index format probably cannot optimize much more for that. The ideal case is bgzip because it produces very small indexes without windows, which reduces I/O read times, processing times, and memory usage. But this is something the compressor has to do.  I have already been optimizing a bit to automatically detect windows that are not required at all plus the sparse window detection to reduce index sizes by ~3.

followup: index creation from stdin does not work anymore. rapidgzip now complains All window sizes must be at least 32 KiB or empty!

Damn, so many tests and weird CI issues I had to fix (literal stack overflows on MacOS because std::array<char, 128*1024> ballooned the stack when used for multiple local variables) and there are still major bugs. I have most command line invocations tested in testCLI but anything relating to stdin, is a hassle to test from inside C++.
However, I am getting:
Caught exception: Failed to detect a valid file format.

when trying:
m rapidgzip && cat base64-8MiB.gz | src/tools/rapidgzip --export-index index

I'm not sure why you are seeing another error message.
The introducing commit for this bug is: https://github.com/mxmlnkn/indexed_bzip2/commit/582d6f7d002f2f7970b7d83d5fc502131655875d.

I have pushed a fix for the stdin problem and will release 0.14.1 after the CI has finished. Thank you for noticing the bug! I have also added a test, so it shouldn't happen again so easily. The other two things, as they are small features and performance optimizations, not bugfixes, will probably have to wait until the next minor release.
Ah, did I mention that the sparseness is also used for the gztool indexes? This is why the new sparseness feature meshes surprisingly well with the gztool support feature, both newly added in rapidgzip 0.14.0. E.g., try this:
base64 /dev/urandom |head -c $(( 4 * 1024 * 1024 * 1024 )) | gzip > 4GiB-base64.gz

rapidgzip --no-sparse-windows --index-format gztool --export-index 4GiB-base64.gz{.index,} && stat -c %s 4GiB-base64.gz.index
# -> 39 MB (38811851 B)
# 3 MiB spacing instead of the default 10 MiB for roughly comparable comparison with rapidgzip
gztool -s 3 -I 4GiB-base64.gz{.gzi,} && stat -c %s 4GiB-base64.gz.gzi
# 34 MB -> (33983860 B)

rapidgzip --index-format gztool --export-index 4GiB-base64.gz{.index,} && stat -c %s 4GiB-base64.gz.index
# -> 702 kB (701964)
# The index is compatible with gztool of course, even though it is ~50x smaller!
gztool -b 0 -I 4GiB-base64.gz{.index,}
# ACTION: Extract from byte = 0
#
# Index file '4GiB-base64.gz.index' already exists and will be used.
# Processing '4GiB-base64.gz' ...
# Processing index to '4GiB-base64.gz.index'...
# 4.00 GiB<PHONE_NUMBER> Bytes) of data extracted.
#
# 1 files processed
#
# 229af148b81ef63faf7e723d50173d1f  -
gzip -d -c 4GiB-base64.gz | md5sum
# 229af148b81ef63faf7e723d50173d1f  -

Of course, random base64 data is almost the best case for sparseness ;). For wikidata.json, I observed the mentioned 3x size reduction of the gztool index from ~10 GB indexed_gzip index (windows not compressed) down to ~1.5 GB gztool index (windows compressed) down to ~500 MB for compressed sparse windows for the 102 GiB wikidata.json.gz, which decompresses to ~1 TB.

Ah, did I mention that the sparseness is also used for the gztool indexes?

No, you didn't :) but I already wondered how you achieved gztool index size reduction..

I am not sure what you mean with "even more efficient decompression". The index format probably cannot optimize much more for that.

I meant: When using the default rapidgzip index and the same number of threads as without using the index, the decompression throughput is much higher due to ISA-L. When using the gztool index, I guess the algorithm falls back to your "own custom-written gzip decompression engine". To overcome this, I asked if it would be possible to make use of both indices i.e. using gztool index to infer the line/byte offset and the rapidgzip index for the actual decompression.

I am sorry to bother you again with stdin related issues. with v0.14.1 index export works with "indexed_gzip" and "gztool" keywords, but fails on "gztool-with-lines" giving me the error
terminate called after throwing an instance of 'std::invalid_argument'
  what():  Cannot seek backwards with non-seekable input!
Aborted (core dumped)

I meant: When using the default rapidgzip index and the same number of threads as without using the index, the decompression throughput is much higher due to ISA-L. When using the gztool index, I guess the algorithm falls back to your "own custom-written gzip decompression engine". To overcome this, I asked if it would be possible to make use of both indices i.e. using gztool index to infer the line/byte offset and the rapidgzip index for the actual decompression.

You are right about ISA-L and the slower custom decoder. But, ISA-L is also used when importing a gztool index. I.e., gztool already should give all the benefits, no reason to combine it with the old index format. There is one edge case that gztool indexes do not work with:
> rapidgzip --index-format gztool --export-index SRR22401085_2.fastq.gz{.index,}
> cat SRR22401085_2.fastq.gz | /home/maximiliank/.local/bin/rapidgzip --count --import-index SRR22401085_2.fastq.gz.index
Traceback (most recent call last):
  File "/home/maximiliank/.local/bin/rapidgzip", line 8, in <module>
    sys.exit(cli())
             ^^^^^
  File "rapidgzip.pyx", line 685, in rapidgzip.cli
ValueError: Cannot import gztool index without knowing the archive size!

This is a known limitation of the gztool index because it does not store the total archive size but rapidgzip kinda needs it and therefore tries to query it from the file and this will not work for stdin input.

I am sorry to bother you again with stdin related issues. Using v0.14.1 index export works with "indexed_gzip" and "gztool" keywords, but fails on "gztool-with-lines" giving me the error

No bother. As the message says, are you using non-seekable input like stdin? In that case it is a known limitation because the line information are currently gathere in post, i.e., rapidgzip needs to seek back in the file, which is not possible for stdin.

[ ] I am also getting a ValueError: Window too small! error with rapidgzip --export-index issue-37.tar.gz{.index,}. Decompression works fine, so it seems to come from the index exporting. I'll have to take a look at this later.

gztool already should give all the benefits

I see. So except for index file size and the use case with --count option, there are no other drawbacks switching to gztool indices?

No bother. As the message says, are you using non-seekable input like stdin? In that case it is a known limitation because the line information are currently gathere in post, i.e., rapidgzip needs to seek back in the file, which is not possible for stdin.

Yes, that's correct, because I would like to create the index asynchronously while compressing the data and not afterwards by doing gzip -kc <file> | tee >(rapidgzip --index-format gztool-with-lines --export-index [..]) > <file.gz>. This currently works for me using gztool this way gzip -kc <file> | tee >(gztool -v 0 -f -i -x -C -I <file.gz>) > <file.gz>. If this would be able to achieve with your implementation one could avoid using gztool completely and an top profit from your sparseness feature.

gztool already should give all the benefits

I see. So except for index file size and the use case with --count option, there are no other drawbacks when switching to gztool indices?

Yes.

No bother. As the message says, are you using non-seekable input like stdin? In that case it is a known limitation because the line information are currently gathere in post, i.e., rapidgzip needs to seek back in the file, which is not possible for stdin.

Yes, that's correct, because I would like to create the index asynchronously while compressing the data and not afterwards by doing gzip -kc <file> | tee >(rapidgzip --index-format gztool-with-lines --export-index <file.gzi>) > <file.gz>. This currently works for me using gztool this way gzip -kc <file> | tee >(gztool -v 0 -f -i -x -C -I <file.gzi>) > <file.gz>. If this would be able to achieve with your implementation one could avoid using gztool completely and an top profit from your sparseness feature.

I see, thanks for the feedback. I'll see what I can do for the next minor release. It might be more difficult than it sounds because of the abstraction layers, but maybe I'll "just" have to move the line counting one level deeper (into ParallelGzipReader or even into the ChunkData, instead of doing it outside in the CLI logic).

I have fixed some of the performance ideas for --count-lines.

Yes, that's correct, because I would like to create the index asynchronously while compressing the data and not afterwards by doing gzip -kc <file> | tee >(rapidgzip --index-format gztool-with-lines --export-index <file.gzi>) > <file.gz>. This currently works for me using gztool this way gzip -kc <file> | tee >(gztool -v 0 -f -i -x -C -I <file.gzi>) > <file.gz>. If this would be able to achieve with your implementation one could avoid using gztool completely and an top profit from your sparseness feature.

If you are compressing files, I would really recommend bgzip, which also should be a drop-in replacement for gzip and is available via the Debian/Ubuntu package manager. It can also create an index while compressing files, although those indexes do not contain line information. Rapidgzip should also be a lot faster when the input is a bgzip file because it can delegate to ISA-L.

I have pushed a commit that should make your use case of using stdin input to create an index work to develop. You can try it out with:
python3 -m pip install --force-reinstall 'git+https://github.com/mxmlnkn/indexed_bzip2.git@master#egginfo=rapidgzip&subdirectory=python/rapidgzip'

It needs a bit more testing before it will be merged.

If you are compressing files, I would really recommend bgzip, which also should be a drop-in replacement for gzip and is available via the Debian/Ubuntu package manager. It can also create an index while compressing files, although those indexes do not contain line information. Rapidgzip should also be a lot faster when the input is a bgzip file because it can delegate to ISA-L.

I know :) To add up on this, bgzip is also much faster than pigz. But be aware of the version you are using, because from v1.16 on, the developers switched to hfile with a default block size of 4kb when data comes from stdin, which heavily reduces throughput. See my issue opened here bgzip performance drop from v1.16. Unfortunately, the pull request which partially should fix this issue by increasing the block size, is not merged yet.

I have pushed a commit that should make your use case of using stdin input to create an index work to develop. You can try it out with:
python3 -m pip install --force-reinstall 'git+https://github.com/mxmlnkn/indexed_bzip2.git@develop#egginfo=rapidgzip&subdirectory=python/rapidgzip'

It needs a bit more testing before it will be merged.

Works like charm. You also implemented the infinity option for --ranges<EMAIL_ADDRESS>Thank you so much!


feat: start adding some Rustier interfaces for reactive types

This library has traditionally had a style that's more idiomatic/familiar to JS devs coming from React or Solid than to typical Rust:
let (count, set_count) = create_signal(cx, 0);
let double_count = create_memo(cx, move |_| count() * 2);

as opposed to
let count = RwSignal::new(0);
let double_count = Memo::new(move |_| count() * 2);

Historically this has been for three reasons

create_signal's tuple return doesn't lend itself well to a ::new() style; it's not returning a struct, after all.
The addition of a cx variable has made ::new() seem odd.
I largely ported it from SolidJS and its idioms, which are all that classless JS createSignal() and useSomething() style.

But there are some real advantages to using structs with associated functions and methods:

Idiomatic Rust.
Better discoverability in docs (easier to find Memo::new() than create_memo if you're on the page for the Memo struct)
Reduced duplication of the generic types on functions
Easier to create variants like Resource::once() rather than increasingly-long function names like create_resource_once

I do not plan to remove the current style or make any breaking changes. I do plan to start adding more Rust-y idioms for all the same APIs.
Still to do:

[ ] Signal::new (MaybeSignal::new, MaybeProp::new)
[x] StoredValue::new
[x] Effect::run() (name?)
[x] Selector?
[ ] others that can get the same treatment?

And there's a lot of beauty in actual idiomatic Rust, no?

A Rustier example
pub fn counter(initial_value: i32, step: u32) -> impl IntoView {
    let count = RwSignal::new(Count::new(initial_value, step));
    let double_count = Memo::new(move |_| count.get() * 2);

    div()
        .child((
            button()
                .on(ev::click, move |_| count.update(Count::clear))
                .child("Clear"),
            button()
                .on(ev::click, move |_| count.update(Count::decrease))
                .child("-1"),
            p().child(("Value: ", move || count.get().value(), "!")),
            p().child(("Double Value: ", double_count, "!"))
        ))
        .child(
            button()
                .on(ev::click, move |_| count.update(Count::increase))
                .child("+1"),
        )
}

#[derive(Debug, Clone)]
pub struct Count {
    value: i32,
    step: i32,
}

impl Count {
    pub fn new(value: i32, step: u32) -> Self {
        Count {
            value,
            step: step as i32,
        }
    }

    pub fn value(&self) -> i32 {
        self.value
    }

    pub fn increase(&mut self) {
        self.value += self.step;
    }

    pub fn decrease(&mut self) {
        self.value += -self.step;
    }

    pub fn clear(&mut self) {
        self.value = 0;
    }
}

Seems like a relatively simple change. Is there any way I can help?

@rakshith-ravi Thanks for the offer — I think it's all set for now, but if there are other APIs you spot that could benefit from a Rust-ier interface feel free to open a PR!


Upgrade gems for 2018-03-04

Gems in our Gemfile (or pretty direct dependencies):

[x] Rails, 5.1.4 → 5.1.5

now invokes callbacks on update_attribute
"Fix to working before/after validation callbacks on multiple contexts." (which might fix our issue with deprecation warnings?)

[x] api-pagination, 4.6.3 → 4.7.0
[x] audited, 4.5.0 → 4.6.0
[x] aws-partitions, 1.52.0 → 1.68.0
[x] aws-sdk-core, 3.13.0 → 3.17.0
[x] aws-sdk-kms, 1.3.0 → 1.5.0
[x] aws-sdk-s3, 1.8.0 → 1.8.2
[x] browser, 2.5.2 → 2.5.3
[x] byebug, 9.1.0 → 10.0.0
[x] capybara, 2.16.1 → 2.17.0 → 2.18.0
[x] httparty, 0.15.6 → 0.15.7 → 0.16.0
[x] memory_profiler, 0.9.8 → 0.9.9 → 0.9.10
[x] newrelic_rpm, <IP_ADDRESS>0 → <IP_ADDRESS>1
[x] nokogiri, 1.8.1 → 1.8.2
[x] puma, 3.11.0 → 3.11.1 → 3.11.2
[ ] rack, 2.0.3 → 2.0.4
[ ] rack-protection, 2.0.0 → 2.0.1
[ ] rack-test, 0.8.2 → 0.8.3
[x] rspec-core, 3.7.0 → 3.7.1
[x] rspec-support, 3.7.0 → 3.7.1
[x] sanitize, 4.5.0 → 4.6.0
[x] sass, 3.5.4 → 3.5.5
[ ] tunemygc, 1.0.69 → 1.0.71
[x] uglifier, 4.0.2 → 4.1.0 → 4.1.1 → 4.1.2 → 4.1.3 → 4.1.4 → 4.1.5 → 4.1.6
[x] webmock, 3.1.1 → 3.2.0 → 3.2.1 → 3.3.0

Other items:

ast, 2.3.0 → 2.4.0
et-orbi, 1.0.8 → 1.0.9
ffi, 1.9.18 → 1.9.23
font-awesome-sass, 4.7.0 → <IP_ADDRESS>
i18n, 0.9.1 → 0.9.5
loofah, 2.1.1 → 2.2.0
minitest, 5.10.3 → 5.11.3
multi_json, 1.12.2 → 1.13.1
mustermann, 1.0.1 → 1.0.2
nio4r, 2.1.0 → 2.2.0
nokogumbo, 1.4.13 → 1.5.0
parser, <IP_ADDRESS> → <IP_ADDRESS>
public_suffix, 3.0.1 → 3.0.2
rb-fsevent, 0.10.2 → 0.10.3
request_store, 1.3.2 → 1.4.0
ruby_parser, 3.10.1 → 3.11.0
sexp_processor, 4.10.0 → 4.10.1
sinatra, 2.0.0 → 2.0.1
tzinfo, 1.2.4 → 1.2.5
xpath, 2.1.0 → 3.0.0

I'm gonna guess rack doesn't break anything, though I can't find a proper history file for it, and tunemygc isn't (afaik) enabled.
We might want to remove that sometime, but for now I think I'm happy to merge this.


'ProvisioningFailed' failed to provision volume with StorageClass "cephfs": fork/exec /usr/local/bin/cephfs_provisioner: invalid argument

use cephfs_provisioner  to create pvc, pvc can not be provisioned ,make errors:
[root@control-1 rbac]# kubectl describe pvc claim -n paas-dev
Name:          claim1
Namespace:     paas-dev
StorageClass:  cephfs
Status:        Pending
Volume:
Labels:
Annotations:   kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"v1","kind":"PersistentVolumeClaim","metadata":{"annotations":{},"name":"claim1","namespace":"paas-dev"},"spec":{"accessMode...
volume.beta.kubernetes.io/storage-provisioner: ceph.com/cephfs
Finalizers:    [kubernetes.io/pvc-protection]
Capacity:
Access Modes:
VolumeMode:    Filesystem
Mounted By:
Events:
Type     Reason                Age                    From                                                                                Message

Normal   Provisioning          3m26s (x5 over 7m11s)  ceph.com/cephfs_cephfs-provisioner-574c84468d-l2qx9_f34f1650-368a-11ea-ab92-3a265dee8862  External provisioner is provisioning volume for claim "paas-dev/claim1"
Warning  ProvisioningFailed    3m26s (x5 over 7m11s)  ceph.com/cephfs_cephfs-provisioner-574c84468d-l2qx9_f34f1650-368a-11ea-ab92-3a265dee8862  failed to provision volume with StorageClass "cephfs": fork/exec /usr/local/bin/cephfs_provisioner: invalid argument
Normal   ExternalProvisioning  71s (x26 over 7m11s)   persistentvolume-controller                                                               waiting for a volume to be created, either by external provisioner "ceph.com/cephfs" or manually created by system administrator
and the cephfs_provisioner logs :
r: invalid argument, output:
W0114 07:15:19.510976       1 controller.go:746] Retrying syncing claim "paas-dev/claim1" because failures 3 < threshold 15
E0114 07:15:19.510995       1 controller.go:761] error syncing claim "paas-dev/claim1": failed to provision volume with StorageClass "cephfs": fork/exec /usr/local/bin/cephfs_provisioner: invalid argument
I0114 07:15:19.511016       1 event.go:221] Event(v1.ObjectReference{Kind:"PersistentVolumeClaim", Namespace:"paas-dev", Name:"claim1", UID:"8b8874e9-df41-4d6c-94b1-84d8e0a64061", APIVersion:"v1", ResourceVersion:"23305650", FieldPath:""}): type: 'Warning' reason: 'ProvisioningFailed' failed to provision volume with StorageClass "cephfs": fork/exec /usr/local/bin/cephfs_provisioner: invalid argument
I0114 07:17:19.511193       1 controller.go:987] provision "paas-dev/claim1" class "cephfs": started
I0114 07:17:19.513861       1 event.go:221] Event(v1.ObjectReference{Kind:"PersistentVolumeClaim", Namespace:"paas-dev", Name:"claim1", UID:"8b8874e9-df41-4d6c-94b1-84d8e0a64061", APIVersion:"v1", ResourceVersion:"23305650", FieldPath:""}): type: 'Normal' reason: 'Provisioning' External provisioner is provisioning volume for claim "paas-dev/claim1"
E0114 07:17:19.515725       1 cephfs-provisioner.go:158] failed to provision share "kubernetes-dynamic-pvc-e69ed80e-369d-11ea-ab92-3a265dee8862" for "kubernetes-dynamic-user-e69ed844-369d-11ea-ab92-3a265dee8862", err: fork/exec /usr/local/bin/cephfs_provisioner: invalid argument, output:
W0114 07:17:19.515768       1 controller.go:746] Retrying syncing claim "paas-dev/claim1" because failures 4 < threshold 15
E0114 07:17:19.515791       1 controller.go:761] error syncing claim "paas-dev/claim1": failed to provision volume with StorageClass "cephfs": fork/exec /usr/local/bin/cephfs_provisioner: invalid argument
I0114 07:17:19.515811       1 event.go:221] Event(v1.ObjectReference{Kind:"PersistentVolumeClaim", Namespace:"paas-dev", Name:"claim1", UID:"8b8874e9-df41-4d6c-94b1-84d8e0a64061", APIVersion:"v1", ResourceVersion:"23305650", FieldPath:""}): type: 'Warning' reason: 'ProvisioningFailed' failed to provision volume with StorageClass "cephfs": fork/exec /usr/local/bin/cephfs_provisioner: invalid argument

me too -_-||

Check your secret. The secret needs to be base64 encoded.

Thanks for reporting the issue!
This repo is no longer being maintained and we are in the process of archiving this repo. Please see https://github.com/kubernetes/org/issues/1563 for more details.
If your issue relates to nfs provisioners, please create a new issue in https://github.com/kubernetes-sigs/nfs-ganesha-server-and-external-provisioner or https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner.
Going to close this issue in order to archive this repo. Apologies for the churn and thanks for your patience! :pray:


Bug: Model validation rules is_unique fails on placeholder

PHP Version
8.1
CodeIgniter4 Version
4.3.6
CodeIgniter4 Installation Method
Composer (using codeigniter4/appstarter)
Which operating systems have you tested for this bug?
Windows
Which server did you use?
cli-server (PHP built-in webserver)
Database
MySQL 5.7.24
What happened?
Using the Myth Auth package to manage users, uppon saving their profile the validation inside the UserModel will check if the email is unique.
protected $validationRules = [
        'email'         => 'required|valid_email|is_unique[users.email,id,{id}]',
        'username'      => 'required|alpha_numeric_punct|min_length[3]|max_length[30]|is_unique[users.username,id,{id}]',
        'password_hash' => 'required',
];

Saving this has issues on the is_unique validation, error message given is:
No validation rules for the placeholder: id
Steps to Reproduce
Basic composer installation with latest CodeIgniter4, and the use of MythAuth version 1.2.1.

Modify a user basic steps like changing the username/emaiil for example.
The UserModel will use $validationRules to process the request.

On step 2 it fails already.
Expected Output
Saving the user without any issues.
Anything else?
Before upgrading CodeIgniter4 we didn't have any issues, seems to me like a recent change in the way this works?

To use Validation Placeholders securely, please remember to create a validation rule for the field you will use as a placeholder.
https://codeigniter4.github.io/CodeIgniter4/installation/upgrade_435.html#validation-placeholders

Why do you close this so fast??
The current version of MythAuth uses the exact same way so I have no clue what you are talking about?
Maybe for you this is understandable but i've got zero clues how and why this has changed from previous versions.

@erikkraijenoord If the error message is difficult to understand, please suggest a better message.


Distribution::Hash should be tested

It's already used, and seems to be a part of the language according to the synopsis, so it might be a good idea to include some tests here.

@JJ let me give you a suggestion that I personally would find useful...
Take the test mentioned ( curli-install.t ) and modify it so it first runs against a Distribution::Hash ( what already exists ) and then do it again with Distribution::Path. The installation process that gets run on each will test them quite well. So maybe put a large chunk of the existing code into a subroutine that you pass a distribution to, and then add new code to create the Distribution::Path to be passed to it ( as a bonus additional Distribution::* interfaces will easily be addable to test ).
https://github.com/ugexe/zef2/blob/master/t/distribution.t#L7 This test has some tooling for generating META6.json file from a hash of meta data -- you'll probably want something like this to generate the META6.json file from the hash used to create the Distribution::Hash. Additionally it may give you some insight into Distribution::* as a whole, although be warned that those interfaces have additional non-spec methods.

I just remembered I've already done a lot of work in this area as well. Probably some stuff here worth considering: https://github.com/perl6/roast/compare/cur-candidates

Not sure. Could possibly just mark the tests that don't yet work as todo instead of the entire file.
rm_rf would probably be a handy Test::Util tool. I think there might even be an issue about that.
It is only essentially for Distribution::Path


Still having issues with Disabling Security hub Controls in LZA (1.7.0)

When adding controls to disabled they never disable the onyl time i have sucess is either manual disable or create a control policy in security hub which than breaks Security hub deployment in LZA with a managed policy error
Currently the code is
  - name: NIST Special Publication 800-53 Revision 5
    # [https://docs.aws.amazon.com/securityhub/latest/userguide/nist-standard.html](https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.aws.amazon.com%2Fsecurityhub%2Flatest%2Fuserguide%2Fnist-standard.html&data=05%7C02%7CFScalzo%40optimumhit.com%7C1c50553fc46744a7345f08dc8643ae7a%7C7853fe62ef514774ab1b876fd9cf540b%7C0%7C0%7C638532872467492325%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=BHd%2BKj55cgzeYdTeKOpR4cQ%2BK3%2F6ZRfJuuQ9ERwBDAs%3D&reserved=0)
    deploymentTargets:
     organizationalUnits:
       -  Root
    enable: true
    controlsToDisable:
      - IAM.6
      - CloudFormation.1
      - Config.1
      - EC2.4
      - EC2.17
      - EC2.8
      -

And it does not seem to work that being said I wonder if NIST needs to be added to it like PCI has it
  - name: PCI DSS v3.2.1
    # [https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-pci-controls.html](https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.aws.amazon.com%2Fsecurityhub%2Flatest%2Fuserguide%2Fsecurityhub-pci-controls.html&data=05%7C02%7CFScalzo%40optimumhit.com%7C1c50553fc46744a7345f08dc8643ae7a%7C7853fe62ef514774ab1b876fd9cf540b%7C0%7C0%7C638532872467502240%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=83QcoRLDg%2FRjUJqX6R9LwUNBtYheUzobTFNhfOfayUo%3D&reserved=0)
    enable: false
    controlsToDisable:
      - PCI.IAM.6
      - PCI.IAM.4
      - PCI.CloudFormation.

I do have an active ticket with AWS so i will report back if they solve

You need to specify the controls to disable as they appear in the standard.
For NIST Special Publication 800-53 Revision 5,
Config.1 should be CM-3 CM-6 CM-8
For CIS Foundations Benchmark v1.4.0,
Config.1 is "3.5" (and the quotation marks are required)
You can find those IDs next to the standard in the according user guides:
e.g. https://docs.aws.amazon.com/securityhub/latest/userguide/config-controls.html

@akobara seems overly complex i am better off using the policy and not using LZA at this point because if im reading  you right
to remove cloudtrail.5 i would have to add all these in

AC-2(4)
AC-4(26)
AC-6(9)
AU-10
AU-12
AU-2
AU-3
AU-6(1)
AU-6(3)
AU-6(4)
AU-6(5)
AU-7(1)
CA-7
SC-7(9)
SI-20
SI-3(8)
SI-4(20)
SI-4(5)
SI-7(8)


Scss-lint column numbers

I want to be able to highlight warnings inline with Scss-lint like I do with Eslint and Rubocop.  See the difference below:
Eslint: error shows in gutter and on line/column

Scss-lint: warning shows in gutter only; no column given
but I don't like the gutter :(

Here's the debug output:
"test.scss" 4L, 36C
syntastic: 0.094294: &shell = '/bin/bash', &shellcmdflag = '-c', &shellpipe = '2>&1| tee
', &shellquote = '', &shellredir = '>%s 2>&1', &shellslash = 0, &shelltemp = 1, &shellxq
uote = '', &shellxescape = ''
syntastic: 0.094689: UpdateErrors (auto): default checkers
syntastic: 0.094967: CacheErrors: default checkers
syntastic: 0.095541: g:syntastic_aggregate_errors = 0
syntastic: 0.095701: getcwd() = '/Users/jeffreyauriemma/personal/game-of-life-n'
syntastic: 0.617293: CacheErrors: Invoking checker: scss/scss_lint
syntastic: 0.617819: SyntasticMake: called with options: {'errorformat': '%f:%l [%t] %m'
, 'makeprg': 'scss-lint test.scss', 'returns': [0, 1, 2, 65, 66]}
syntastic: 0.975939: checker output: ['test.scss:2 [W] PropertySpelling: Unknown propert
y silly-error', '']
syntastic: 0.976459: raw loclist: [{'lnum': 2, 'bufnr': 1, 'col': 0, 'valid': 1, 'vcol':
 0, 'nr': -1, 'type': 'W', 'pattern': '', 'text': 'PropertySpelling: Unknown property si
lly-error'}, {'lnum': 0, 'bufnr': 0, 'col': 0, 'valid': 0, 'vcol': 0, 'nr': -1, 'type':
'', 'pattern': '', 'text': ''}]
syntastic: 0.976817: getLocList: checker scss/scss_lint returned 1
syntastic: 0.976966: scss/scss_lint raw: [{'lnum': 2, 'bufnr': 1, 'col': 0, 'valid': 1,
'vcol': 0, 'nr': -1, 'type': 'W', 'pattern': '', 'subtype': 'Style', 'text': 'PropertySp
elling: Unknown property silly-error'}, {'lnum': 0, 'bufnr': 0, 'col': 0, 'valid': 0, 'v
col': 0, 'nr': -1, 'type': '', 'pattern': '', 'subtype': 'Style', 'text': ''}]
syntastic: 0.977243: quiet_messages filter: {}
syntastic: 0.977782: aggregated: {'_sorted': 0, '_name': 'scss_lint (scss)', '_owner': 1
, '_columns': 1, '_rawLoclist': [{'lnum': 2, 'bufnr': 1, 'col': 0, 'valid': 1, 'vcol': 0
, 'nr': -1, 'type': 'W', 'pattern': '', 'subtype': 'Style', 'text': 'PropertySpelling: U
nknown property silly-error'}]}

Since column data is being collected, I wonder if this could be solved by simply formatting the output differently.
Any thoughts on this?

Since column data is being collected

Not sure how did you reach this conclusion; it currently isn't.
It could be, since scss-lint has added a JSON reporter in version 0.29.0, and that reporter does output column numbers.  But changing syntastic to take advantage of that involves writing a special parser.  That isn't a huge problem, but I don't really have time for that right now.  Perhaps in a few days.

@lcd047 https://github.com/brigade/scss-lint/pull/671 looks like there's work happening on their side to update the default reporter.

It doesn't matter, the JSON output is available since version 0.29.0, and it offers more features.  Please see commit 2db6f53.


Kill the Arc inside Context::Inner

Turns out we don't need it

Note the error on the coverage build:
  = note: /usr/bin/ld: final link failed: No space left on device

Any indication that this saves cycles?

I'd love to test that, but #921 is a blocker for it. @richajaindce have you had a chance to take a look and see what is broken inside the compact gate script generator?

Any indication that this saves cycles?

I'd love to test that, but #921 is a blocker for it. @richajaindce have you had a chance to take a look and see what is broken inside the compact gate script generator?

I checked the history of steps.txt and it supported upto depth 31 meaning 2^31! This was then overwritten by OPRF changes. Not sure how we generated so many steps but working to find a way to get them in again


WIP: TEST: Show that cibuildwheel action can be used

The cibuildwheel docs
recommend using some thirdparty GitHub Actions to drive it.
This may not work in Apache CI due to restrictions on workflows.
If this PR fails then we will need a different approach.
DO NOT MERGE - I only want to see if the CI passes.

Apologies for the auto 'review request' spam - i wasn't aware of the 'Draft' flag in GitHub.


how to enable nbextensions in conda env

It seems that a local notebook.json file is ignored, so we need another solution for this.

one can specify the config, when starting the notebook server: https://jupyter-contrib-nbextensions.readthedocs.io/en/latest/config.html#jupyter-configuration-filenames

What about this?
%%javascript
Jupyter.utils.load_extensions('exercise2/main')

According to https://mindtrove.info/4-ways-to-extend-jupyter-notebook/#nb-extensions, this snippet will load an installed exercise2 extension; and we have it installed via environment.yml.


User gets a 403 error when trying to load an LMS Google picker assignment

Describe the bug
Intermittently, users will get the following when trying to open an assignment made with a PDF in Drive:

Unexpected server response (403) while retrieving PDF "https://via3.hypothesis.is/proxy/static/...

The network response was:
<meta http-equiv=“content-type” content=“text/html; charset=utf-8"/><title>Sorry...</title>

Google
Sorry...

We’re sorry...

... but your computer or network may be sending automated queries. To protect our users, we can’t process your request right now.

See Google Help for more information.

<div style=“text-align: center; border-top: 1px solid
To Reproduce
This bug seems to be intermittent, and is not reliable to reproduce.

Log in to Canvas as an instructor and create an Assignment using a PDF in GDrive.
Open the assignment periodically until you get the above error.

Expected behavior
The PDF should open like other Drive-integrated assignments, with the PDF visible in pdf.js, and the Hypothesis Sidebar present.
Screenshots
Error:

Netword response:

Console error 1:

Console error 2:

Additional context
Slack convo:
https://hypothes-is.slack.com/archives/CBN3DGW02/p1585598606033800

A fix for this has been deployed as far as QA and testing / thinking and getting more familiar with Google API console has revealed some details.

Google has quotas, this means this is likely to fix our issues as long as we stay within them
This change allows us to make much more effective use of Cloudflare caching (meaning fewer requests and much faster loading for most users)
The API route does not return detailed filename information, so the filename is blank, causing the page title to become just "uc"

Why our caching should be better
Previously when asking for us to proxy Google docs the following would happen:

You go to: ..via3/proxy/static/<google doc url>
NGINX goes to <google doc url>
<google doc url> returns a redirect, which we cannot cache to <final doc url>
NGINX redirects the user to ..via3/proxy/static/<final doc url>
User starts over going to ..via3/proxy/static/<final doc url>
NGINX goes to <final doc url>
NGINX returns the document

You can't cache the redirect at all, because the second final location could be user/region specific. We should cache the second, but it's less likely. A casual test suggests we're not / not consistently.
In the new world:

You go to: ..via3/proxy/static/<google doc url>
NGINX goes to <google API url>
NGINX returns the document

This can be cached right away

An informal test suggests the redirects above are different for different users.

It looks like the fix has resolved the issue, and we aren't using much of our alloted quota (<1%), so I think we're good here. @mkdir-washington-edu do you think we're good to close this?

Just confirmed in chat this is good to close


support feedback update

Docs Build status updates of commit 130320a:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

Advertising/bingads-13/bulk-service/app-install-ad.md
:white_check_mark:Succeeded

Advertising/bingads-13/bulk-service/campaign.md
:white_check_mark:Succeeded

Advertising/bingads-13/bulk-service/dynamic-search-ad.md
:white_check_mark:Succeeded

Advertising/bingads-13/bulk-service/expanded-text-ad.md
:white_check_mark:Succeeded

Advertising/bingads-13/bulk-service/experiment.md
:white_check_mark:Succeeded

Advertising/bingads-13/bulk-service/keyword.md
:white_check_mark:Succeeded

Advertising/bingads-13/bulk-service/product-ad.md
:white_check_mark:Succeeded

Advertising/bingads-13/bulk-service/responsive-ad.md
:white_check_mark:Succeeded

Advertising/bingads-13/bulk-service/responsive-search-ad.md
:white_check_mark:Succeeded

Advertising/bingads-13/bulk-service/text-ad.md
:white_check_mark:Succeeded

Advertising/bingads-13/campaign-management-service/campaign.md
:white_check_mark:Succeeded

Advertising/bingads-13/campaign-management-service/experiment.md
:white_check_mark:Succeeded

Advertising/bingads-13/guides/authentication-oauth-identity-platform.md
:white_check_mark:Succeeded

Advertising/bingads-13/guides/handle-service-errors-exceptions.md
:white_check_mark:Succeeded

Advertising/bingads-13/guides/operation-error-codes.md
:white_check_mark:Succeeded

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


test: update test framework to use latest best practices and reduce boilerplate

what

Update this module's test framework. Reduce boilerplate and make reusable functions.
Changelog:

Upgrade go to 1.21.
Update test/Makefile and test/src/Makefile from https://github.com/cloudposse/terraform-aws-eks-node-group/tree/e9f908c026d8ca5dc30190a050de68a510ff3983/test
Create framework_test.go and default_test.go, following how it's done in https://github.com/cloudposse/terraform-aws-eks-node-group/blob/e9f908c026d8ca5dc30190a050de68a510ff3983/test/src/framework_test.go
Remove enabled=true from fixtures and add new test TestExamplesCompleteDisabled for when enabled=false
Add Test_ExistingDeployment for faster test cycle, and modify Makefile accordingly
Update dependencies
Migrate test DB Engine from 3.6.0 to 5.0.0

why

Enable testing with OpenTofu
Support automated maintenance

references

Closes #88
Closes #98
https://github.com/cloudposse/terraform-aws-documentdb-cluster/pull/94
https://github.com/cloudposse/terraform-aws-eks-node-group/tree/e9f908c026d8ca5dc30190a050de68a510ff3983/test/src
https://github.com/cloudposse/terraform-aws-dynamic-subnets/tree/8528dadc5cbdcf657faa1d917c9f069c254f41a3/test/src

/terratest

/terratest

/terratest

/terratest


CLI: rewrite in rust

To date, the Go CLI has lived in its own repo and has received infrequent updates, failing to track our APIs as they change.
In an effort to improve on this, this diff adds new Rust version of the CLI here in the webhooks repo. The idea is to release the CLI along with the libs as a part of the same process (https://github.com/svix/monorepo-private/issues/9620).
Modules in the source tree under cli_types/ and cmds/api/ (excluding the mod.rs) are largely produced via our new codegen tooling (h/t @svix-jplatte).
Other modules under cmds/ are written by hand, the most involved being listen which depends on greenfield code under relay/.
The relay code was largely inspired by the code seen in the Go CLI, but the overall shape of it has changed to account for GC vs borrow checker. Future work sound be planned to do a design pass now that the pieces are working together since breaking things apart to satisfy rustc left things in an odd shape.
Differences
Comparing the Go and Rust CLIs, there are some differences. The list of features added in the Rust version that are lacking in Go's is long thanks to the new codegen.
It'll be more useful to focus on what isn't here.
--data-* flags
In the Go CLI we exposed flags named --data-foo where foo would be a field in the expected JSON body sent with the request. These flags have not been carried forward. Instead users will be required to write out the full JSON body as a command-line argument.
Serde will give some feedback if the body fails to parse given the expected schema even before the request is made to the server.
Future work is planned to include an example body for each place we accept JSON in the long help.
Import/Export
svix import and svix export have been left behind. For import, users are encouraged to leverage svix event-type import-openapi which should fill the same need.
For export, I think the best alternative is using svix event-type list and handling the responses as needed.
Server URL no longer mandatory
The GO CLI required users to set the URL for the API server they wanted to interact with.
In the new Rust CLI, we will default to the issuer of the auth token. Typically this is going to be the safest default since manually specifying a Server URL should only be necessary when doing local development or talking to a non-production-SaaS server. The impacted group for this change would be enterprise customers and Svix employees and the fix is to do what they'd have needed to do all along: set the URL explicitly.
Verification
Reviewers will note that there's a dramatic lack of unit tests 😇
To this, I assure you there's technically more coverage on this CLI than there is on the Go one 🤣.
The majority of the verification for this has been manual testing. If you have specific concerns, pitch a test and I can run through the scenario for you (or you can try it yourself!)
OSS Reviews
There are several new-to-us crates included in this diff. I'll call each out in the comments below, looking for 👍🏻 from the security team.

@svix-jplatte you mentioned in a separate conversation about wanting to tidy up imports (perhaps WRT codegen).
I wonder if you'd like to swoop in with a follow-up PR to get the rustfmt config setup how you like it. This still needs lints/CI etc. I can take a stab at it before merging this if not.

OSS Review
tokio-tungstenite
https://crates.io/crates/tokio-tungstenite/0.26.1
This is the websocket client used for the listen command.
Seems well maintained.
They have remarks in their readme about performance, specifically that some other libs might be better for cases where perf is mission critical. For this use case I think we're okay. Nobody should be running production systems tunneled through our relay server.
dialoguer
https://crates.io/crates/dialoguer/0.11.0
This is used for the login command which prompts for user input to store in the user's config file.
Hasn't been updated in a while but there is a long list of contributors/maintainers on the github page. One piece of a larger "console" project.
colored_json
https://crates.io/crates/colored_json/5.0.0
Used to optionally/conditionally color the JSON output from various API commands.
This one comes with a drawback. The license is EPL-2.0 which was flagged by our security lints, requiring an exception. This is a slightly more restrictive license than we've seen in the past. Seems like it should be fine for the CLI since we're entirely in the open for it, but would need to make sure we don't introduce it as a dep to areas where we have proprietary builds happening.
I looked at 2 alternatives:

https://github.com/saghm/json-color
https://github.com/andrewhickman/termcolor-json

While both of these seemed able to give similar output, configurable colors, etc, each of these had issues with color mode detection and overriding.
We should revisit this at a later date. For now I added an exception to the deny.toml for this lib.
open
https://crates.io/crates/open/5.3.1
Cross-platform "open this url in your default browser."
At first I thought to write this myself but since the Go CLI used a lib for this task, I elected to delegate.
The Windows one looked a bit fiddly when I peeked at the source, so I'm glad I did.
Project looks healthy. Regular updates and several maintainers.
home
https://crates.io/crates/home/0.5.11
home_dir() in the stdlib currently has a deprecation warning since it can give the wrong answer for Windows systems.
An alternative version of the stdlib's home_dir() as used by cargo to better support Windows.  This is maintained by the cargo team.
In Rust 1.86 this will no longer be needed.

Looks good to me. Thanks!


Remove unused imports

Should have been done in #364.

Current coverage is 81.25% (diff: 100%)

Merging #371 into master will increase coverage by 0.10%

@@             master       #371   diff @@
==========================================
  Files            63         63
  Lines          1963       1963
  Methods        1877       1802    -75
  Messages          0          0
  Branches         86        161    +75
==========================================
+ Hits           1593       1595     +2
+ Misses          370        368     -2
  Partials          0          0

Powered by Codecov. Last update 26c2754...972abde


CookBook/16 build error

Problem Description
NAME="Ubuntu"
VERSION="22.04.4 LTS (Jammy Jellyfish)"
ROCk module version 6.2.4
Name:                    gfx1100

following: sample build

build error on 02_CookBook/16_xxx

ld.lld: error: undefined symbol: __hip_fatbin
>>> referenced by square.cpp
>>>               /workspace/samples/build/2_Cookbook/16_assembly_to_executable/square_host.o:(__hip_fatbin_wrapper)
>>> did you mean: __hip_fatbin_
>>> defined in: /workspace/samples/build/2_Cookbook/16_assembly_to_executable/square_device.o
clang: error: linker command failed with exit code 1 (use -v to see invocation)

looks the default cmake can't find a link lib ?  or how should I setup ?
Thanks
Operating System
Ubuntu 22.04
CPU
Ryzen
GPU
AMD Radeon RX 7900 XTX
ROCm Version
ROCm 6.1.0
ROCm Component
No response
Steps to Reproduce
No response
(Optional for Linux users) Output of /opt/rocm/bin/rocminfo --support
No response
Additional Information
No response

Hi @ZJLi2013, internal ticket has been created to investigate your issue. Thanks!

Hi @ZJLi2013,
A recent compiler patch introduced a change where clang is emitting the symbol __hip_fatbin_ (with an underscore) instead of __hip_fatbin (without an underscore): https://github.com/llvm/llvm-project/pull/81700. The hip-tests were updated accordingly here: https://github.com/ROCm/hip-tests/commit/fba826fc3c6afc0deae298ecf0e9f7ee9901d990. I believe that you are running an older version of the compiler where __hip_fatbin is still being emitted. This mismatch is causing the reported error.
The solution is either to upgrade your ROCm version to the latest (6.2.0) or to try running the tests with the changes here reverted: https://github.com/ROCm/hip-tests/commit/fba826fc3c6afc0deae298ecf0e9f7ee9901d990. Please give that a try and let me know if you run into any further issues!


WSL Tutorial  busID problem

What to do when
usbip: error: WSK Kernel is not USBIP capable; update with 'wsl --update'.

usbipd: error: The selected WSL distribution is not running; keep a command prompt to the distribution open to leave it running

Add to the documentation for your class.

After whatever solution you proposed where the students had to close the Ubuntu terminal and reopen it again, some people ran into problems with minicom.
When running minicom with sudo minicom -s and pressing ESC, some people see a message that reads something along the lines
no such directory found
They have to check with
usbipd wsl list

whether the device is still attatched,  and use
usbipd wsl attach --busid <busid>

again


PROD data issue causing portal index error

On PROD, the dataset 06d03f751006a149b75009d07501fba1 has two data types: "data_types": [ "snATACseq", "scRNA-Seq-10x" ]  and this has been causing the portal index transformation error:
AssertionError: Maximum 2 types, and one should be image pyramid: ['snATACseq', 'scRNA-Seq-10x']

This dataset is no longer available on PROD.


support partial column list when using .write()

when writing data frame to SingleStore using insert batch it expecting all columns of the tables to be included in the data frame, otherwise, it fails.
why not use the data frame columns from the schema to support partial column insert?
if you agree with the direction, do you accept pull requests?

Hi, @ronassa
This request sounds reasonable.
I agree with a direction and accept pull requests.

@AdalbertMemSQL, since I posted this comment, it's already been solved.