[Discussion] 174 packages broken on Flutter master

The latest flutter update-packages (flutter/flutter#39932) changed the pinned version of the intl package from 0.15.x to 0.16.0.
The intl package has 174 dependent packages. Following the update in the Flutter tree (pinning intl to 0.16.0) these packages cannot be used with Flutter master by apps that use flutter_localizations (assuming they follow the common practice of using ^ as the constraint for its dependencies).
The "default fix" a package maintainer would follow up with is to bump their intl constraint to ^0.16.0, but this makes the latest version of the package unsupported with Flutter master (which we try hard to avoid).
As we were considering how to deal with this issue for the local_auth plugin (PR comment thread), it turned out that the major version bump to the intl package was a mistake (https://github.com/dart-lang/intl/issues/233). So we can mitigate this specific issue by extending the intl version constraint to >=0.15.1 <0.17.0. Though I'm not sure it will be obvious to the maintainers of the other 173 packages.
I'd like to raise a few points for discussion:
Dealing with similar future scenarios
How do we allow packages to support both Flutter master and Flutter stable following a major version bump to a transitive dependency that is pinned by Flutter?
While Flutter's rule is to always pin a dependency maybe we should consider allowing Flutter to depend both on version N.0.0 and N-1.0.0 following a major version bump, and only pin the dependency to N.0.0 after a stable Flutter release (to minimize the versions Flutter should worry about maybe we could use a "version a.b.c or version x.y.z" constraint instead of a version range, AFAIK pub does not support such "or" constraints?)
@Hixie any thoughts?
Mitigating unnecessary major version bumps
Maybe a simple check like requiring a "BREAKING CHANGE" section in the changelog when a major version bump is published can help prevent accidental major version bumps?
@mit-mit @csells @jonasfj any thoughts? (I realize it's not trivial as CHANGELOG is unstructured, but we can probably think of some way to make sure an author is aware they are publishing a breaking change)
Mitigating unnecessary major version bumps after the fact
For cases like the 0.16.0 which turned out to not be a breaking change - if we believe this is leading to a wide breakage in the ecosystem can anyone think of a reasonable mechanism to allow mitigation after the fact?
@mit-mit @jonasfj
Monitoring such breakages
I believe that we are currently pretty much blind to such issues in the ecosystem, unless we hear of them through GitHub issues.
@zanderso we've previously discussed collecting dependency resolution failure rates for flutter pub get, this may be a good tool to monitor for such failures.
cc @alan-knight

If we have a package where we say we support two versions, we would have to run our entire test battery against each version. If we have two packages where we support two versions, we'd have to run our entire test battery against every combination of those two packages, so four times. This will rapidly get out of control. This will be especially unlikely to be practical since this will only be relevant when the change is across a package's "breaking change" boundary, so in theory we shouldn't be able to use either version interchangeably anyway.
So I don't think we can support multiple versions.
We don't want to wait until just before we bump our own version to bump our dependencies, for a few reasons. First, we don't know when we're going to bump our version, so we can't make that prediction easily. Second, we bump the version at the very start of the cycle, not the end, so it would actually just maximize the problem. We could instead bump our dependencies at the end of the cycle,  before we cut our release branch, but that runs into a similar problem: we don't know when we're going to cut our branch. Thirdly, and most importantly, we really don't want to wait until the last minute to bump our dependencies because we need time to catch errors that they introduce.
So I don't think we want to change the timing of our dependency bumps.
Making it easy to make a package that works with both the current master Flutter and the current stable Flutter seems ideal, but I really don't know how to do that in a statically-analyzable way...
cc @mit-mit @vsmenon @leafpetersen

@Hixie what would be your suggestion for package maintainers in such cases (major update to a package pinned by Flutter)? support Flutter master? (in which case Flutter stable users are likely not going to get bugfixes until Flutter is released) or support Flutter stable? (in which case the moment Flutter is release a bunch of packages cannot be resolved with the new Flutter version)

One option for package maintainers would be to maintain two versions of their package, one for master at x.y.z, and one for stable at x-1.y.z, assuming pub supports that.

Another interesting alternative - maybe we can try and get the maintainers of packages pinned by Flutter to land breaking changes in a phased way (similar to how we land breaking changes in Flutter to mitigate the same problem).
Probably a first step would be to reach out to all of them and get them aware of the implications, and a second step would be to have some mechanism to detect/enforce this early.

One option for package maintainers would be to maintain two versions of their package, one for master at x.y.z, and one for stable at x-1.y.z, assuming pub supports that.

As a package maintainer I'd hate to have to keep 2 branches and release bug fixes to both.

I certainly didn't realize that bumping the minor version was going to be a
problem for people. I only bumped it because we were significantly
increasing the minimum SDK, which while significant, isn't really breaking.
One obvious thing is that we really ought to bring it up to a 1.0.0 release
so that anyone pinning with ^ won't be broken by second-level increments.
On Wed, Sep 25, 2019 at 9:42 AM Amir Hardon<EMAIL_ADDRESS>wrote:

The latest flutter update-packages (#39932
https://github.com/flutter/flutter/pull/39932) changed the pinned
version of the intl package from 0.15.x to 0.16.0.
The intl package has 174 dependent packages
https://pub.dev/packages?q=dependency%3Aintl&page=1. Following the
update in the Flutter tree (pinning intl to 0.16.0) these packages cannot
be used with Flutter master by apps that use flutter_localizations
(assuming they follow the common practice of using ^ as the constraint
for its dependencies).
The "default fix" a package maintainer would follow up with is to bump
their intl constraint to ^0.16.0, but this makes the latest version of
the package unsupported with Flutter master (which we try hard to avoid).
As we were considering how to deal with this issue for the local_auth
plugin (PR comment thread https://github.com/flutter/plugins/pull/2084),
it turned out that the major version bump to the intl package was a
mistake (dart-lang/intl#233 https://github.com/dart-lang/intl/issues/233).
So we can mitigate this specific issue by extending the intl version
constraint to >=0.15.1 <0.17.0. Though I'm not sure it will be obvious to
the maintainers of the other 173 packages.
I'd like to raise a few points for discussion:
Dealing with similar future scenarios
How do we allow packages to support both Flutter master and Flutter stable
following a major version bump to a transitive dependency that is pinned by
Flutter?
While Flutter's rule is to always pin a dependency maybe we should
consider allowing Flutter to depend both on version N.0.0 and N-1.0.0
following a major version bump, and only pin the dependency to N.0.0 after
a stable Flutter release (to minimize the versions Flutter should worry
about maybe we could use a "version a.b.c or version x.y.z" constraint
instead of a version range, AFAIK pub does not support such "or"
constraints?)
@Hixie https://github.com/Hixie any thoughts?
Mitigating unnecessary major version bumps
Maybe a simple check like requiring a "BREAKING CHANGE" section in the
changelog when a major version bump is published can help prevent
accidental major version bumps?
@mit-mit https://github.com/mit-mit @csells https://github.com/csells
@jonasfj https://github.com/jonasfj any thoughts? (I realize it's not
trivial as CHANGELOG is unstructured, but we can probably think of some way
to make sure an author is aware they are publishing a breaking change)
Mitigating unnecessary major version bumps after the fact
For cases like the 0.16.0 which turned out to not be a breaking change -
if we believe this is leading to a wide breakage in the ecosystem can
anyone think of a reasonable mechanism to allow mitigation after the fact?
@mit-mit https://github.com/mit-mit @jonasfj
https://github.com/jonasfj
Monitoring such breakages
I believe that we are currently pretty much blind to such issues in the
ecosystem, unless we hear of them through GitHub issues.
@zanderso https://github.com/zanderso we've previously discussed
collecting dependency resolution failure rates for flutter pub get, this
may be a good tool to monitor for such failures.
cc @alan-knight https://github.com/alan-knight
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/issues/41308?email_source=notifications&email_token=AA2QU6G5UI2IVWKPZWGVV73QLOIFZA5CNFSM4I2PKHB2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HNU7OIQ,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA2QU6ESMM2P7SLWLKRK73LQLOIFZANCNFSM4I2PKHBQ
.

As a package maintainer I'd hate to have to keep 2 branches and release bug fixes to both.

Certainly. It shouldn't be a problem that often, though.

One obvious thing is that we really ought to bring it up to a 1.0.0 release so that anyone pinning with ^ won't be broken by second-level increments.

We should bring intl to 1.0 in general, if we expect people to use it. :-)

Seems like part of the confusion is around the pub versioning conventions for packages with versions smaller than 1.0.0 (the versioning scheme for these is 0.MAJOR.MINOR+PATCH). This isn't the first time we see wrong version updates as package developers aren't aware of this convention.
I guess this can be partly mitigated by forcing a breaking change description when publishing major version updates.
Another (maybe crazy?) idea is managing versions for plugin authors, e.g when you pub publish we ask you: "Does this update include a breaking change?" "Does this update include a new feature?", and then the tool proposes what the version number should be.

I agree that part of the problem is that we have breaking-change updates that aren't (though I suspect we have non-breaking-change-version-updates that should be much more often, technically), but I think that's mostly a distraction from the core problem here, which would still occur regardless.

@Hixie wrote:

One option for package maintainers would be to maintain two versions of their package, one for master at x.y.z, and one for stable at x-1.y.z, assuming pub supports that.

Yes, you can publish a package on what corresponds to both a stable channel and a dev channel: https://dart.dev/tools/pub/publishing#publishing-pre-releases. Consumers always get stable channel packages by default; you need to specifically specify the pre-release version to get that.
But this, as @amirh pointed out, means maintaining two versions of the package, which is painful.

Is it time to consider running tests on all our channels?

Also:

Loosen your dependency constraints (I understand why you pin, but this is the downside),
Vendor packages you depend on into the Flutter SDK and hide their interface,
Avoid major version breaks by creating a new package name (e.g. intl2).
Avoid major version break by creating a new library in the package package:intl/intl2.dart.

Hi @amirh
Is this still a valid issue? It has been one year since this issue was filled and this may not be valid anymore.
Thank you

Without additional information, we are unfortunately not sure how to resolve this issue.
We are therefore reluctantly going to close this bug for now.
Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution.
Could everyone who still has this problem please file a new issue with the exact description of what happens, logs, and the output of flutter doctor -v.
All system setups can be slightly different, so it's always better to open new issues and reference related issues.


API returns invalid JSON

{'status' : 'success', 'message' : ''}

JSON does not support single quotes. All fieldnames / string values need to be encapsulated in double quotess.

Sorted, thanks. Included in 1.1.0.


[Helm Chart v1.6.1] Cert expiration date is not equal to Duration

Describe the bug:

I created a certificate using below yaml file. However, the certificate expires after 90 days, which is not equal to the duration - 48h. Anyone has experienced the same issue?
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: test-group-com
  namespace: default
spec:
  secretName: test-group-com-tls
  secretTemplate:
    annotations:
      my-secret-annotation-1: "foo"
      my-secret-annotation-2: "bar"
    labels:
      my-secret-label: foo
  duration: 48h # 90d
  renewBefore: 12h # 15d
  subject:
    organizations:
      - jetstack
  commonName: test.group.com
  isCA: false
  privateKey:
    algorithm: RSA
    encoding: PKCS1
    size: 2048
  usages:
    - server auth
    - client auth
  dnsNames:
    - test.groups.com
  issuerRef:
    name: letsencrypt-staging
    kind: ClusterIssuer
    group: cert-manager.io

When I do kubectl describe cert test-group-com, I got Not After: 2022-04-26T08:35:33Z in the description.
Spec:
  Common Name:  test.group.com
  Dns Names:
    test.groupsea.com
  Duration:  48h0m0s
  Issuer Ref:
    Group:  cert-manager.io
    Kind:   ClusterIssuer
    Name:   letsencrypt-staging
  Private Key:
    Algorithm:   RSA
    Encoding:    PKCS1
    Size:        2048
  Renew Before:  12h0m0s
  Secret Name:   test-group-com-tls
  Secret Template:
    Annotations:
      my-secret-annotation-1:  foo
      my-secret-annotation-2:  bar
    Labels:
      My - Secret - Label:  foo
  Subject:
    Organizations:
      jetstack
  Usages:
    server auth
    client auth
Status:
  Conditions:
    Last Transition Time:  2022-01-26T09:35:35Z
    Message:               Certificate is up to date and has not expired
    Observed Generation:   1
    Reason:                Ready
    Status:                True
    Type:                  Ready
  Not After:               2022-04-26T08:35:33Z
  Not Before:              2022-01-26T08:35:34Z
  Renewal Time:            2022-04-25T20:35:33Z

Environment details::

Kubernetes version: v1.23.1
cert-manager version: v1.6.1
Install method: helm

/kind bug

Seems like Let's Encrypt by default support 90 days lifetime. I think that is the same with ZeroSSL.

Let's Encrypt support a lifetime of 90 days only. It's the same with ZeroSSL.

Thank you for the reply! Got it~

This is expected. The duration will be ignored by some issuer types, LetsEncrypt is one of them. See the description of the `Certificate`'s duration` field.

Thank you!


Flexbox post

New post, this one about common annoyances we can fix with Flexbox!

Ah good catch, made the correction


Failed to connect to orchestrator at wss://beta.orchestrator.nexus.xyz:443/prove: TLS error: native-tls error: The certificate was not trusted.

Getting this error on my mac
Failed to connect to orchestrator at wss://beta.orchestrator.nexus.xyz:443/prove: TLS error: native-tls error: The certificate was not trusted.

The same error on the Ubuntu server: Error connecting to nexus orchestrator at: wss://beta.orchestrator.nexus.xyz:443/prove. Nexus team has been alerted and is looking into it. Please try again later.

Working fine now...Just try it again


feat: configure edge function at route level

Unlike the Vercel adapter, the Netlify Adapter currently doesn't support route level config or specifying an edge function at the route level. (e.g) all routes are normal lambda functions but a specific route is rendered on the edge using export config .
I've used this internally for a while but thought it may be helpful to the wider community.

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

[x] It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
[x] This message body should clearly illustrate what problems it solves.
[ ] Ideally, include a test that fails without this PR but passes with it.

Tests

[x] Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

[x] If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

Edits

[x] Please ensure that 'Allow edits from maintainers' is checked. PRs without this option may be closed.

@kylesloper since you've been using this, has this allowed you to split your routes in serverless and edge? Currently, the adapter has the limitation of only accepting the split config or edge config, but this would remove it.


Feature/zk/fine tune partitioning

Updated to create number of partitions based on spark.riak.input.split.count property.

@zkhadikova please apply this PR to the develop branch instead of the timeseries branch.

Closing PR to timeseries branch. Changes should go into develop.


I18n guide

This supersedes #2309

@googlebot I confirm (is this enough?)

@ocombe no, it will stay red forever when the PR author is not the same as the commit author

Heya @vicb, I'm picking up this chapter for now to get it ready for our testing setup and some more edits. I'm not too familiar with the i18n functionality aside from the chapter itself, so that's my starting point.

No pb, added a bunch of comments ping me if you need more info.
We should make it clear that i18n is supported equally well for JiT and AoT.

The guide is heavily revised, I know that @wardbell wants to review but I would also appreciate @vicb, @ocombe and @Foxandxss to have a look.
We plan to further enhance it post AC, but for now the main priority is to get something simple and practical that users can follow.
Notably, I removed the pipe sections as per @vicb comment:

Usage of pipes should be discouraged. They should only be used by the compiler to transform codes.
If you use the pipes you basically can not i18n your app because different langs use different plural category

I also removed sections that talked about dynamic language switching. Angular itself doesn't support it and we don't have a server setup example to show. Also, as per @vicb:

Usage of pipes should be discouraged. They should only be used by the compiler to transform codes.

However, as @ocombe noted, this is a very common request and we should incorporate it in the guide in some form when revising.
@vicb I did not make the ICU messages note you mentioned simply because I don't know what it is nor what to say about it.

Now superseded by #2491


New/Missing Feature Request - Pulling the match round

I'm hoping you can modify/Update the code to allow for pulling the match round as well on top of the current info dump. It makes it easier to clump the matches according to the weeks.
Also for matches that are yet to play under the fixtures tab

These features weren’t on my radar, but I’ll explore adding them.
Keep in mind that the data collected might be used to derive additional information through post-processing, which could potentially provide the details you’re looking for.
The repository is open for contributions, so feel free to add any features if you’re interested!


knightos-kcc: 4.0.0 -> 4.0.4

Motivation for this change
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

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

1 package failed to build:

knightos-z80e

2 packages built:

knightos-kcc
knightos-scas

Dropped knightos-kcc update because it failed to build.


Allow passing GtkBuilderLeaf to macro generated functions

Addresses issue #15

Coverage increased (+1.3%) to 99.301% when pulling 169feff7469a05777f7d99792b2e796aa2a8e22b on external_builder into c2c8203a2f4981d0d9e523498bc8adb6cf9a8b33 on master.


MIAD-252 Create individual users with ro/rw access

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

Project coverage is 92.56%. Comparing base (3c2fcc7) to head (ca08b94).
Report is 1 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff            @@
##               main     #240   +/-   ##
=========================================
  Coverage     92.56%   92.56%
  Complexity      487      487
=========================================
  Files            83       83
  Lines          1654     1654
  Branches        103      103
=========================================
  Hits           1531     1531
  Misses           79       79
  Partials         44       44

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


Double generation of jsDoc comments

The jsDoc comments are being duplicated on properties.
Expected
Bridge.define("Demo.Person", {
    config: {
        properties: {
            /**
                * The age of the Person in years
                *
                * @instance
                * @public
                * @this Demo.Person
                * @memberof Demo.Person
                * @function setAge
                * @param   {number}    value <-- maybe not required?
                * @return  {void}
                */
            Age: 0
        }
    }
});

Actual
Bridge.define("Demo.Person", {
    config: {
        properties: {
            /**
                * The age of the Person in years
                *
                * @instance
                * @public
                * @this Demo.Person
                * @memberof Demo.Person
                * @function getAge
                * @return  {number}
                */
            /**
                * The age of the Person in years
                *
                * @instance
                * @public
                * @this Demo.Person
                * @memberof Demo.Person
                * @function setAge
                * @param   {number}    value <--- also, why? but not included in first block
                * @return  {void}
                */
            Age: 0
        }
    }
});

Steps To Reproduce
Add the generateDocumentation config to bridge.json.
{
  "output": "Bridge/output",
  "generateDocumentation": "Basic"
}

namespace Demo
{
    internal class Person
    {
        /// <summary>
        /// The age of the Person in years
        /// </summary>
        public int Age { get; set; }
    }
}

Also not sure why * @param   {number}    value is included in the second comment block, and not included in the first.

It is not bug. It is expected behaviour. Two comments are generated for getter and setter accessors because only accessors can be used to access a property in javascript. First - @function getAge, second - @function setAge
About value, that argument is available for setter only (getter has no any arguments) therefore first comment block which describes getter has no value

Makes sense now. Not sure how I missed the different getAge and setAge function names.


Prometheus metric drbdreactor_up does not contain node name or address

In kubernetes environment prometheus metric drbdreactor_up does not contain node name (hostname) or ip address. Just instance name (pod name):
drbdreactor_up{app_kubernetes_io_instance="linstor-piraeus-ns", app_kubernetes_io_managed_by="piraeus-operator", app_kubernetes_io_name="piraeus-node", controller_revision_hash="74d8dc587c", env="preprod", instance="linstor-piraeus-ns-node-5g66p", job="pod", kubernetes_namespace="linstor", location="SITE1", name="linstor-piraeus-ns", pod_template_generation="6"}

This isn't really job of the reactor. Instead this should be handled by the ServiceMonitor or PodMonitor created by the Piraeus Operator. Please open an issue with this request there.


autojump: include a way to find the share dir

Things done

[x] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[ ] NixOS
[x] OS X
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

autojump-share is a new script that gives you the path to autojump's
shared directory. It can then be used in the various shell's rc files to
find and source the autojump integration. Eg:
source "$(autojump-share)/autojump.bash"

Fixes #3239

this is cool!

well now we just need to document it :)

damn :) where should the documentation for packages go ?

LGTM

:+1:

Does it make sense to add the doc as a package note like that ? ^


Add a Javy example

As requested by https://github.com/tetratelabs/wazero/issues/591#issuecomment-1136536077

I switched the title as this isn't about allocation the same way as others are thinking. If there is demand, we could add a Javy example anyway, for example, showing how to communicate with stdin/stdout as opposed to via memory regions. cc @saulecabrera @F21
https://github.com/Shopify/javy/issues/111

note: WASI also allows one-way input via args (or env), which some of our examples already do. stdin/stdout would be another way (conversation)

I've been testing sending input to the javy-compiled wasm via stdin and receiving output on stdout.
Currently I am doing something like this (abridged):
config := wazero.NewModuleConfig().WithStdout(os.Stdout)
data := bytes.NewBufferString(`.......some data`)

_, err = r.InstantiateModule(ctx, code, config.WithName("main").WithStdin(data))

Is InstantiateModule the only way to pass input to the module using stdin? Does it have any performance disadvantages compared to using myFunction.Call()?
I am more than happy to contribute an example for this, but would like to know if this is the best way.

The main question I have is if making repeated function calls in Javy is even supported (per the other thread). If not, and the only way is using WASI (_start function automatically called on InstantiateModule), then it is likely a moot point, isn't it?
Maybe you can share a sample project that is calling a function multiple times in the same memory space?

Here's a quick example I created: https://github.com/F21/javy-wazero
Calling InstantiateModule multiple times panics as expected. Not sure how we can call the module multiple times without recompiling at the moment.

thanks. I'll follow up on that repo and keep this issue open meanwhile.

Quick update: I was able to remove the need for an entirely new runtime on each instantiation by instantiating each module with a  unique name and closing the module after it's been called.

for now I will help/watch https://github.com/F21/javy-wazero similar to how I do with https://github.com/birros/wazero-demo  I kindof prefer when community members take stake with others learning things.
we can re-open this issue if something changes.

For those interested in using Wazero with Javy, I've published an example implemented using Shopify's Javy and Suborbital's Javy fork here: https://github.com/F21/javy-wazero


Revert "Replace WALA Pair with clean new Pair."

Reverts apache/incubator-openwhisk#3624
This broke some downstream repositories. Will fix those first before merging this (soon!)

@csantanapr Carlos, what do we need to do in IBM PG to fix this in order to merge in open?

Codecov Report

Merging #3628 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #3628   +/-   ##
=======================================
  Coverage   74.41%   74.41%
=======================================
  Files         126      126
  Lines        5952     5952
  Branches      391      391
=======================================
  Hits         4429     4429
  Misses       1523     1523

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7d9372f...4a658ea. Read the comment docs.

downstreams already fixed

@mrutkows in this case was not about PG.
it was that a common Class “common.Pair” was being removed from the common tests utilities.
And there other repos like the package-cloudant repo that depended on it.
In addition in the IBM downstream was also using this Class.
What needed to happen with that PR was to communicate more broadly about the braking change and fix first the downstreams like the cloudant package first before removing from main repo.


objc: fix envoy_observer native_init

This was being instantiated in the wrong order, and warning at compile time that the wrong closure types were being assigned to envoy_observer:
library/objective-c/EnvoyEngine.m:228:33: warning: incompatible pointer types initializing 'envoy_on_error_f' (aka 'void (*)(envoy_error, void *)') with an expression of type 'void (void *)' [-Wincompatible-pointer-types]
                                ios_on_complete, ios_on_error, context};
                                ^~~~~~~~~~~~~~~
library/objective-c/EnvoyEngine.m:228:50: warning: incompatible pointer types initializing 'envoy_on_complete_f' (aka 'void (*)(void *)') with an expression of type 'void (envoy_error, void *)' [-Wincompatible-pointer-types]
                                ios_on_complete, ios_on_error, context};
                                                 ^~~~~~~~~~~~

Signed-off-by: Michael Rebello<EMAIL_ADDRESS>

@keith that's a great callout. Tried running locally with warnings as errors, but as you mentioned it fails with core Envoy. What would be the best way to run this only on specific Envoy Mobile cc_library targets?

Filed https://github.com/lyft/envoy-mobile/issues/339


Global sources & sinks

How do you pass sinks back up a nested tree without piping it through each branch?
eg: 3 pages, on one of the pages there is intent to +1 / -1 to a number. I want all other pages to be able to listen to that change and update their own number. if I start with 0 click + 1 and move around the app all pages have a number 1.
correct me if I'm wrong but it feels like that sort of state is only kept within each component? so your sources at the Cycle.run level don't have a clue about whats going on elsewhere unless you passed it along each level until it reaches the top. Not so bad one level deep but what about 3-4 levels deep!
redux is a little noisy but it is passing everything back to the top level and feeding it down when a change happens, then the whole tree has the ability to listen to that change (in React via it's props)
Here is a link get a visual representation of what I'm trying to achieve.

What’s wrong with returning state$ from components? To me, it makes completely sense that a parent component carries the responsibility of returning its state$, possibly composed of state$ returned from its children, to its own parent.
There’s another pattern you can use, and that is to inject components into other components. This way, you can instantiate a component on an upper level, where you then have access to its state$, and then pass the component to other components that may be responsible of only the rendering.

where would you're single point of truth live in this pattern? just sounds like state$ is being passed all around and you have to work on pipping through out the app.
Having that single point which you can refer to anywhere in the app is a really useful tool, when you start dealing with larger apps.

Aren’t component state determined by the properties they receive? How then can you have a single point of truth unless you gather it from multiple sources?

This is what I'm proposing a way to channel state into a global state object.
const sources = {
  State: {store} // store would be where all global state lives
  DOM: makeDOMDriver('#application'),
  History: makeHistoryDriver({
    // if you want hash: false you will need to set up a server
    hash: false,
    queries: true,
  }),
};
run(mainApp,sources);

The only problem that I can't work out is in children component you would need the ability to update store Driver, so the rest of the app who is also using that store would get updated on change.
This does sound like a driver of sorts, a global state driver.
or do you think that it would have no value and you'd be quite happy without it?

I know this isn't going to be liked but the way React has props which automatically bubbles down a tree is really useful. In Cycle you would have to manually pass down that information from parent to child.
Redux took advantage of that channel and used it to pipe props.store which can be called from any child element. The only bit that is scruffy in Redux is the way they push the changes back up. I think this could possibly be done with a single driver in Cycle and the state pushing could be handled by the driver.

You are proposing a storage driver of some sort. I have no problem with that. Actually, we already have a LocalStorage driver.

cool, just to expand a little on the idea of bubbling $state down.

The black lines are how state would travel around the app via a state driver. the blue ones would be how to do it currently.
This next image is if 2 wanted to send a message back to 1

Now the bit that I can't work out is you would still have to manually pass $state down from each parent => child. If you are doing that then you might as well be making the connection back up?
Do people think there would be a way for this information to be automatically passed down via it's responses? maybe a custom wrapper for all components that has this built in?!? Or is that just adding/imposing too much.
Cycle is really clean at the core but feel like a sore point to be having to manually make sure the $state pipping is correct. You still then have to have a mental map to make sure you are passing things up/down each branch.

Personally, I don’t like the magic that you are proposing. I think it defeats the purpose of reasoning about data flow. How components are composed should be entirely up to the developer. What state of a child is relevant for a parent should also be entirely up to the developer. How the data flows should be entirely up to the developer. But feel free to bypass all that and implement your app as you like. However, I wouldn’t recommend such an app as a good starting point for new Cycle.js developers.

Your data flow is going to be one massive mess though, if you're implying that everything should be manually piped. That idea is fine when you're dealing with something a couple of levels deep but going by my pictures say I now want page F to have this $state I'm going to have to do a load more pipping make sure each child => parent relationship is correct and you without a global state what would you be changing on F another piece of state?
This is why I feel a single point of truth really comes in handy when dealing with a lot of shared state through multiple levels of parent => child relationships.
because if you're wanted this reaction to happen on 5 pages in the app but not the others, that is going to take some pipping without some form of automatic bubbling.
Yeah you have a good reasoning about your app's data flow but lets now add another 3 intents, ok lets start piping them up and down. I don't think you're data flow is going to be as much fun anymore or have as much clarity.

@Cmdv this is just the difference between top-down approach and bottom-up approach.
If you want global shared state like in Flux and Redux, then you really actually just want one dataflow component, because the Cycle.js equivalent of props-only View in Flux is just functions view : state -> vtree.
Single global state object is the top-down approach where you start with the assumption that all state is in that global object, and all the views are just derivations of that.
Stateful components is the bottom-up approach where you start with existing components and you put them together by composing their behaviors. In this approach, manual "piping" as you call is unavoidable. To some extent in my opinion, I like manual piping because I don't believe it is as tedious as you describe, but it does give you an explicit picture of what happens, without magic underneath.
That said, there are tradeoffs. Neither top-down nor bottom-up is a clear winner and it's not fair to try naming a winner.

Top-down
Bottom-up

Single source of truth
Yes
No

Explicit piping
No
Yes

Easy reusability of components
No
Yes

So, yes, with Nested Dataflow Components you need to manually pass sources and sinks from parent to child and vice-versa. But its a cost we pay in order to get better reusability and explicit contracts on the component boundaries.
If you really really want Redux or a single state atom approach, go ahead for it, but I don't think we can do a compromise between Nested Dataflow Components and single state atom because the two are opposed architectures.

@Cmdv Your data flow is going to be one massive mess though

I don’t agree.

I'm going to have to do a load more pipping make sure each child => parent relationship is correct.

Not really. It’s just passing properties.

"If you really really want Redux or a single state atom approach, go ahead for it, but I don't think we can do a compromise between Nested Dataflow Components and single state atom because the two are opposed architectures."
This needs to be explained a hell of a lot more. There was the Flux Challenge as well, what was learnt from that exercise? I agree that for complex apps a one atom state is useful. The whole problem here is that people are shooting off their ideals while only working on super small concept apps.
I propose that if your going to be so dogmatic at least provide a A vs. B app example, where one is done top-down and the other bottom-up. I'm sure @Cmdv and others can come up with the challenge, it would be interesting to then see the expert response from both sides of the fence.

@staltz I didn't realise what I was trying to achieve is a top down approach.
Could this specific data handling be a function/driver? much like the  LocalStorage driver but it would store state in an immutable object. Then this Object could be manipulated/listened to specified components that wish to listen/interact with it.
This would still result in piping but at least you wouldn't have to handle the parent => child part if you were a few levels deep.
The only reason I wanted to feed it to the Main and have that dispatch it through out the app was to simplify the complexity of pipping.
But if I keep that functionality inside a function/driver. I think that I then wouldn't be moving away from the FP paradigm and it could just be seen as a glue function do you think this is a better approach?

because the two are opposed architectures."
This needs to be explained a hell of a lot more.

One is top-down, the other is bottom-up. What would be a compromise between those? Middle-center? That's why I don't think it's necessary to explain, it's pretty obvious top-down and bottom-up are opposites.

I propose that if your going to be so dogmatic at least provide a A vs. B app example, where one is done top-down and the other bottom-up.

I wrote a blog post about the ideas, and you can check Flux Challenge if you want.

Could this specific data handling be a function/driver?

You can put "stuff" in drivers, but that's not the point of drivers. As Nick Johnstone put it, "Drivers encapsulate imperative side effects". That's all there is to it. State is not an imperative side effect in my opinion.
Also, because the single state atom approach has state as the main piece of the application, you're not supposed to put main business logic in drivers. Drivers should be "plugins" to use imperative side effects, nothing else.
I know where you are trying to get, which is minimizing code for manual "piping". Drivers are not the way to achieve that, neither Nested components are. The way of achieving that is building an architecture that has only one MVI. It has the top-level M, the top-level V, and the top-level I. Then, "dumb components" are just simple pure functions from state to vtree. Model is the place where to keep state, even the global shared state in the case of the top-down approach.
If you find manual "piping" bad, please show us those parts of your code which you don't like, maybe we can find a way to refactor them. But I'm quite sure the explictness of the piping will remain because it's inherent to bottom-up approach. And there isn't a middle ground between bottom-up and top-down. Not as far as I know...

"I know where you are trying to get, which is minimizing code for manual "piping". Drivers are not the way to achieve that, neither Nested components are."
Hopefully there would be a better reason than that to require a one atom state! Architecture is also driven by plain old user/app functionality, the toolkits must bend to the rules of the user/app and so what the user wants in the end determines what the software is expected to do. If a given framework or API is to crippled to handle the demands then so be it, just never lose sight of what the user expects and needs because they are always right and the ones who will pay you for their good pleasure.
Is having a bottom-up preference not also at least a significant reason why there is a sudden interest in Most.js over RxJS? It seems to have been discovered/acknowledged that RxJS is to slow for all the piping required to enforce bottom-up dataflow ideals.

the toolkits must bend to the rules of the user/app and so what the user wants in the end determines what the software is expected to do.

A toolkit is composed of several tools, hopefully. The composition of the kit is entirely up the user. However, if the user want a hammer to drill, the user should get a drill in the kit. Demanding that the hammer ought to do that job is just ridiculous.

It seems to have been discovered/acknowledged that RxJS is to slow for all the piping required to enforce bottom-up dataflow ideals.

Absolutely not. While *Most.js * is extremely fast, RxJS is by no means "too slow".

@Frikki I think you misunderstood my intention. I was just saying that frameworks and APIs are really only useful if they serve a purpose. In my creative world that purpose comes from imaginative and aspiring users. There is hence sometimes a gap between their vision and what present age software can actually do, any compromise would just not work or sell out the purpose.
Agreed, a craftsman needs more than one tool in their toolkit, also good engineering skills can't hurt in the tight spots.
In the end a muscle builder (framework) can take all the steroids (Most.js, etc) they like and look like the hulk. Yet, if they can not jump into action and save the lady or the day what is the point? There are apps to build and experiences to improve upon, hopefully we'll start to see heroic actions (apps) that were made with Cycle soon enough. That is if we can keep from tripping over our own top-down and bottom-up wiring.

@HighOnDrive We have already seen an app, power-ui, built with Cycle.js, and it uses the bottom-up approach. Whether it saved the lady of the day, we’ll have to ask @staltz and Futurice. Again, which approach is chosen, top-down or bottom-up, is up to the developers; both are entirely possible. Staltz has already outlined how to achieve top-down wiring above.

@Frikki Absolutely, we have a few scattered examples to dig through. When the new Cycle update happens what seems reasonable is to have some app templates produced. Just wireframe style templates that have no real contents but they wire up generic and chained drivers, routing and top-down or bottom-up scenarios. These do not have to be app starters, they would just clearly demonstrate the options.

@staltz Thanks for the in depth explanations. The only reason this came up is because I'm trying to imagine cycle replacing apps I work on a daily basis.
For example we have a Diagnostic flow with multiple routes through the application with multiple endings. (a total of about 30 pages) As you move through the app you pic up various pieces of information/data required.

has visitor come via home page | if not redirect back to home
is user logged in | determines options shown through out the flow
did user select specific option | determines options shown through out the flow
results of external api call | one of the steps checks your local weather and this information is later used
information about which route they took | for analytical reasons
Has the user already hit this end point

There are more but as a quick example, some pages need to use some data whilst others don't. All pages need to be aware of 1. You need to be able to keep the a list of the pages visited etc.... (sorry you get the point though)
So before this dataflow was a hard one to reason about when say a new implementation needed to be put in. As a new dev to the team it took me a while to start to understand how everything was talking to each other. (still don't fully understand).
Then we decided to use the idea of what Redux implements and having this global Object where we knew was the singular place to check for the current state of things and change those as and when need be. If you build a new page or implementation you know that what ever you are going to interact with is going to be orientated around this Global Object.
I know this is not what everyone would want from an app, but I hope it can it can be seen that dealing with data in this way still allows you start to build and expand as you wish.
But saying that I understand that this is seen as a top-down approach now and I'm going to go away and research some more experimenting because I don't think this is a straight forward black and white thing.
There are many languages that be seen as better than JS but the reason JS still does so well is because of the simplicity of using the language as a new comer. I know thats fully off topic but simplicity and easy to reason about are always good design choices I'd like to think :)

Ok I've been doing more digging and I can totally see what @staltz + @Frikki were trying to show me.
I came across this great article from Erik Meijer:

Imperative programs describe computations by repeatedly performing implicit effects on a shared global state. In a parallel/concurrent/distributed world, however, a single global state is an unacceptable bottleneck, so the foundational assumption of imperative programming that underpins most contemporary programming languages is starting to crumble. Contrary to popular belief, making state variables immutable comes nowhere close to eliminating unacceptable implicit imperative effects. Operations as ordinary as exceptions, threading, and I/O all cause as much hardship as simple mutable state.

I'll close the issue down now, thanks for the great insight :smiley_cat:

To be fair, if you have cases where many components need access to a common state, you can build those many as a single MVI, but still be able to use this MVI component in an even larger application. You know what I mean? No matter what internal structure your Cycle.js app uses, you can always embed it inside a larger Cycle.js app.

Thanks @Cmdv for that great link! As I'm learning to do more with monad pipelines the need for a central global data store is shrinking. I'm happy with a single top-down MVI DFC approach yet would like to decorate my app tree with many Christmas lights/widgets.
Seeing each observable like redux store with a reduce pipeline that can be as fancy as required, goes a long way. Being able to subscribe to any observable junction in a pipeline extends the options yet further.
I just think it's very important to produce real apps. The statement made in the comments of the linked article (quoted below) are a reminder that technical or academic excellence alone is not enough. If it was not for the real app I'm building I would surely lose my way, glad then that it serves as my north pole.
"Haskell was first made available in 1992, over 23 years ago, and according to Wikipeda, over 5,400 libraries and tools are available for Haskell programming. What language would be called a success that has more than 5,000 libraries of functions and not a single major program that was completely created in it? The only answer I know of is Haskell that was made and promoted by a group of publicly paid professors with next to no "real world experience" between them."
Can you tell that I am not one bit nostalgic or in need of baggage, my own app already tells me what is right and how I must proceed.

@staltz In the list of comparisons made between TopDown vs BottomUp, I think that one can have peer communication in a much easier way (or may be the only way) in TopDown approach.
For instance, if I have a component MAIN and it has 5 child components A, B, C, D where A,B,C,D need to communicate amongst each other. I have not found a clean approach that doesn't depend on intermediary Subject etc. Could you shed some light upon that?

I have not found a clean approach that doesn't depend on intermediary Subject etc.

@tusharmath You mean the proxy Subject technique?

@staltz Yes, referring to this discussion — https://github.com/cyclejs/core/issues/170
Using a proxy subject, seems like an implementation of a TOP => DOWN technique and looking at that discussion thread, it seems like its kind of impossible to do without it. This would mean that there are things that we can absolutely not do in a Bottom => UP approach, doesn't it?

@staltz We could infact have an immutable datastore driver, which would maintain all shared states at one place?

Bottom-up approach simply means you have built the child component first, and it manages its own state because you build it as if it would be the entire application. And only after that have you decided to compose it in the context of a parent. So Bottom-up doesn't mean that you can't compose children components. If the parent needs to maintain some common state for all its children, it's still a Bottom-up approach as long as you didn't start building the parent. If the children cannot live (be reused) in other applications, then it's not bottom-up.


chore: bdd-sbhg-import-1588130483 to 0.0.1

chore: Promote bdd-sbhg-import-1588130483 to version 0.0.1

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
If they are not already assigned, you can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Backslashes are not typed by TypeStr()

Robotgo version (or commit ref): v0.94.1
Go version: 1.16.6
Gcc version: 11.1.0
Operating system and bit: Linux 64-bit
Resolution: N/A
Can you reproduce the bug at Examples:

[X] Yes (provide example code)
[ ] No
[ ] Not relevant

Provide example code:

package main

import (
	"fmt"
	"github.com/go-vgo/robotgo"
)

func main() {
	str := "ab\\cd"
	fmt.Printf("robotgo %s\n", robotgo.GetVersion())
	fmt.Printf("type string: %#v\n", str) // string literal
	fmt.Printf("keystrokes : %s\n", str) // what *should* be typed
	robotgo.TypeStr(str, 50)
	fmt.Println()
}

Log gist:

10454» go run ./newbug.go                                                              ~/tmp/testtyping
robotgo v<IP_ADDRESS>9, MT. Rainier!
type string: "ab\\cd"
keystrokes : ab\cd
abcd

Description
I think this may be related to #221. It looks like backslashes \ are being eaten.

I did a bit of digging, and noticed that toUC() seems to be duplicating all backslashes:
https://play.golang.org/p/rzjDSa1qXmG
This means that the test at robotgo.go#771 fails and inputUTF() is called on the string \\\\.  C.CString() does a correct conversion of backslashes, which implies input_utf() is getting a string of two \\ for each backslash; I'm guessing that this is confusing XStringToKeySym() and causing the character to get eaten.


Elements are animated in but are invisible.

On my Shopify collection page, as the user scrolls down products get loaded into the DOM. These products however, stay hidden when I try to animate them with Sal.js. I previously used AOS where this problem did not occur (looking to change to Sal since I am experiencing some weird bugs under iOS14 with AOS).
I uploaded a Gif of the problem here

The gif is a bit small 🔍 , but I managed to notice the problem. I think it happens, because the list with items is dynamically expanded. When you make a sal's instance it reads elements that are currently on the page.
https://github.com/mciastek/sal/blob/98d0ad3415dc235281a8a320b306af930f6b03a7/src/sal.js#L173-L178
With current API it's not possible to update a list of animated elements, so sal won't know that it needs to animate new elements. I'll provide a method that help with this issue.

The gif is a bit small 🔍 , but I managed to notice the problem. I think it happens, because the list with items is dynamically expanded. When you make a sal's instance it reads elements that are currently on the page.
https://github.com/mciastek/sal/blob/98d0ad3415dc235281a8a320b306af930f6b03a7/src/sal.js#L173-L178
With current API it's not possible to update a list of animated elements, so sal won't know that it needs to animate new elements. I'll provide a method that help with this issue.

Cool! Good to hear you know where the problem comes from. Any update on the method to help fix the issue?

Cool! Good to hear you know where the problem comes from. Any update on the method to help fix the issue?

I noticed that the products getting loaded into the DOM are not getting the 'sal-animate' class (image here) If I manually add the class, they do animate in perfectly. Any idea on how to mitigate this?

I noticed that the products getting loaded into the DOM are not getting the 'sal-animate' class (image here) If I manually add the class, they do animate in perfectly. Any idea on how to mitigate this?

I created a PR with new method - #73. Let me run some tests and it will be good to go. Stay tuned.

I created a PR with new method - #73. Let me run some tests and it will be good to go. Stay tuned.

Cool! Let me know when it's ready for me to use 😄

Cool! Let me know when it's ready for me to use 😄

@mciastek , I am willing to test this on one of my current projects where I also need this feature. If you can publish a test/rc version I can test this pretty soon.

@mciastek , I am willing to test this on one of my current projects where I also need this feature. If you can publish a test/rc version I can test this pretty soon.

@Jordakoes I pushed new version 0.8.3 that adds update() method. Please check if it's useful for your case.

@mciastek Thankyou. I have updated to sal 0.8.3 and have change my init code to:
<script>     const scrollAnimations = sal({       threshold: .5,     });     scrollAnimations.update({       selector: 'grid__item',     });   </script>
However, on the Collection page the 'new' elements don't animate in. When I run sal().update in the browsers console, it causes the items to animate in beautifully. Feel like I am using the Method wrong. Any pointers?

Had some issues getting it to work since I didn't know where to call the update() method. Did some digging where the new elements got loaded into the DOM, added the method and it works butterly smooth now. Amazing work @mciastek, thanks a bunch!

I got success as well! Tnx @mciastek


can i customize reward and face of the snake?

basically the rendering tells me agent don't know the head of the snake is it so?
also, I would like to customize the reward system is there any place where rewards in the current env are defined?
I understand i might have to go into the C++ implementation and modify i guess.
Also, can you let tell me why the obs shape is : (N, 39, 39, 6) why 6?
anyway, thanks for a good starting point to play with.

The rendering code is gym_battlesnake/include/gamerenderer.h, and the relevant code would be this:
                    sf::Color color;
                    unsigned tile_id = gi_->tileid(i,j);
                    if(tile_id == 0) {
                        color = sf::Color(159,159,159);
                    } else if(tile_id == FOOD_ID) {
                        color = sf::Color::Green;
                    } else {
                        uint32_t cid = static_cast<uint32_t>(tile_id);
                        cid = cid ^ 0xA2343434;
                        color = sf::Color(std::hash<uint32_t>{}(cid));
                    }

For each tile (i,j) it gets its tile_id which is either 0 for nothing, FOOD_ID, or some random number which is a snake's unique id. It doesn't distinguish between a snake's head or body. You could write a function like ishead(int i, int j) in gameinstance.h and check if any Player in players_ has the first Tile of its body_ at location (i, j). Then color that square differently, or maybe render a triangle.
Rewards are defined in gymbattlesnake.py:
    def step_wait(self):

        info = [{} for _ in range(self.n_envs)]
        dones = np.asarray([ False for _ in range(self.n_envs) ])
        rews = np.zeros((self.n_envs))

        infoptr = env_infoptr(self.ptr)
        for i in range(self.n_envs):
            if infoptr[i].ate:
                rews[i] += 0.1
            if infoptr[i].over:
                dones[i] = True
                info[i]['episode'] = {}
                if infoptr[i].alive:
                    rews[i] += 1.0 if infoptr[i].turn > 100 else 0.0
                    info[i]['episode']['r'] = 1.0 if infoptr[i].turn > 100 else 0.0
                else:
                    rews[i] -= 1.0
                    info[i]['episode']['r'] = -1.0
                info[i]['episode']['l'] = infoptr[i].turn

        return self.getobs(0), rews, dones, info

Currently it gives a small reward of 0.1 whenever it eats, a penalty of -1 if it loses (game is over and not alive), and a reward of 1 if it wins and the game lasted at least 100 turns (I believe this was to encourage the snake's to live longer and explore the later states of the game when the snake fill up more of the board).
Each of the 6 input layers codes different aspects of the game (as opposed to just feeding in a raw rendered frame of the game). The layers are built gamewrapper.cpp, and if you made a change in the python side you'd have to change the C++ side as well (and recompile), and vice versa. Here is a description of the layers seen in gamewrapper.cpp:
        /*
            layer0: snake health on heads {0,...,100}
            layer1: snake bodies {0,1}
            layer2: segment numbers {0,...,255}
            layer3: snake length >= player {0,1}
            layer4: food {0,1}
            layer5: gameboard {0,1}
        */

The layer's width and height are 39x39, however the player's head will always be at square (19,19) (this substantially sped up training). Also the game board size is variable, the width and height are random between 7 and 19 (this was to make the trained snake flexible). As well, each time it generates an input observation it will randomly flip x and y (this was to make sure the snakes didn't learn an arbitrary preference for a given corner).

thanks for the full details. I appreciated.
one last question if you don't mind. how one snake's observation carrying location of other snake and their sizes?
layer 2 is my snake body i assume starting from head 1,2,3 if the size is 3? layer 3 is confusing.
anyway, thanks a lot, was not really expecting a response as repo seems inactive :)

The player's head should be centered in the layers (note that the render is positioned differently from the layers). This is part of the code that is used to assign a value to tile for layer a given layer l:
        auto assign = [this, model_i, env_i, head, ori](const Tile& xy, unsigned l, uint8_t val) {
            int x = (int(xy.first) - int(head.first)) * ((ori&1)?-1:1);
            int y = (int(xy.second) - int(head.second)) * ((ori&2)?-1:1);
            x += (LAYER_WIDTH/2);
            y += (LAYER_HEIGHT/2);
            if( x > 0 && x < LAYER_WIDTH && y > 0 && y < LAYER_HEIGHT)
                obss_[ model_i*(n_envs_*OBS_SIZE) + env_i*OBS_SIZE + x*(LAYER_HEIGHT*NUM_LAYERS) + y*NUM_LAYERS + l] = val;
        };

The two lines assigning x and y center the tile around the player's head.
I would suggest using something like matplotlib in Python to plot the individual layers to see what is going on.
Ya layer 1 is just bodies {0,1}, layer 2 (if i recall correctly) is segments numbered starting from the tail (so that the head tile will also have the length of the snake). Yes, layer 3 was to hope it would avoid going into longer snakes' heads and lose.

hi,  thanks again. I just noticed you are from uvic too let me know if we can have a chat at<EMAIL_ADDRESS>I figured most of it, just didn't see that the player's head is the center. hmm, that makes sense.


Add inner indexes size

Add a command to have the index stats.
self stats ../meilisearch/data.ms/indexes/952a596c-ed74-45d8-b4c9-080cc222bbb5

Does it interest you @irevoire?
I've used .unwrap() intensivelly 😂

Overall I'm not against it, it's interesting. But I'm not a fan of the implementation, why don't we directly import milli in mieli instead of redeveloping/copy-pasting a bunch of files? (milli = { git = “...”, tag = “v1.2” })
Also, what should we do if the databases are not compatible (since meilisearch can be DB breaking between minor versions) 🤔
Maybe we could import all the milli version possible and try to open the database as mimir is doing

😮 I don't know what would be the best way to do it. At first, I just wanted to do it to be able to run a one-time command to see the size of some DB (you know what I'm thinking about 😉)


feat: abci versioning

Issue being fixed or feature implemented
This is a complete architectural rewrite of drive abci. This is done to allow for easy versioning in the future.
Out of scope is integration with protocol version (next PR on versioning) and versioning of data triggers (another PR).
The approach used in this versioning model was done in an effort to reduce code duplication.
What was done?
Drive ABCI now supports versioning.
How Has This Been Tested?
Tests continue to pass.
Breaking Changes

Checklist:

[X] I have performed a self-review of my own code
[X] I have commented my code, particularly in hard-to-understand areas
[X] I have added or updated relevant unit/integration/functional/e2e tests
[X] I have made corresponding changes to the documentation

For repository code-owners and collaborators only

[X] I have assigned this pull request to a milestone

We had discussion on this PR and decided to merge it in.


Fix World:Collide to use new luax_checkshape

This appears to have been missed in commit 22fe333, and makes it impossible to use a custom collision resolver (the code for a default collision resolver in the docs results in a "bad argument #1 to 'collide' (Shape expected, got userdata)")

Thanks!

Found a similar issue with Collider:addShape and Collider:removeShape, pushed a fix.  Thanks again.


[frontend] Numerical input

We need a Numerical input displaying the value with a bit of formatting like 42,000.00

Can pick this up! Will do it asap


Release notes

Everytime i open VScode the "release notes" opens. There is no option to turn it off.

VSCode Version: Code 1.17.2 (b813d12980308015bcd2b3a2f6efa5c810c33ba5, 2017-10-16T13:59:48.528Z)
OS Version: Windows_NT ia32 10.0.17134
Extensions:

Extension
Author (truncated)
Version

html-snippets
abu
0.2.1

xml
Dot
1.9.2

vsc-material-theme
Equ
1.3.0

beautify
Hoo
1.3.0

minify
Hoo
0.3.0

vscode-browser-sync
jas
1.3.1

font-awesome-codes-css
med
0.1.1

font-awesome-codes-html
med
0.0.7

Angular-BeastCode
Mik
6.1.5

vetur
oct
0.12.4

material-icon-theme
PKi
3.2.2

iis-express
war
1.1.0

bootstrap-3-snippets
wcw
0.1.0

livereload
zee
0.1.1

(2 theme extensions excluded)

Steps to Reproduce:

Open visual studio code

Closing as we have not heard back if this is still occurring in newer VS Code versions

It happens to me with 1.28.2

Sorry for the late reply. I have upgraded to 1.28.2. As Don Glover says, it still happens. Now it only occure sometimes, not everytime as before.


Fix the new lint errors.

Codecov Report

Merging #55 (0852426) into main (c45ad17) will not change coverage.
The diff coverage is n/a.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
@@            Coverage Diff            @@
##              main       #55   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           35        35
  Lines         3223      3223
=========================================
  Hits          3223      3223

Flag
Coverage Δ

unittests
100.00% <ø> (ø)

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


Update to use the v2 API as v1 has been fully discontinued

As of today (2022-07-13), the v1 version of the RCSB search API has been fully discontinued. This PR swaps the library to use the v2 version of the API, following the migration guide detailed here.
The PR also addresses a small number of typos and bugs which are not detailed in the migration guide, but which may be related to the API change.

@ncoish Thanks for this PR! I'm just coming back from vacation but I'll try to review and merge this soon.

Any update on this? Would be nice to have it merged.

@ncoish Thanks for this PR! I'm just coming back from vacation but I'll try to review and merge this soon.

Hey @sbliven, have you had a chance to take a look at this yet?

Heyy will this be merged soon..? The client is super useful, and would be great to have ti working (again)

Yes, please update this. All downstream code CI stopped working because of it.

FYI: https://github.com/sbliven/rcsbsearch/issues/4#issuecomment-1721469353


Short solution needed: "How to groupby data frame using count" (python-pandas)

Please help us write most modern and shortest code solution for this issue:
How to groupby data frame using count (technology: python-pandas)
Fast way
Just write the code solution in the comments.
Prefered way

Create pull request with a new code file inside inbox folder.
Don't forget to use comments to make solution explained.
Link to this issue in comments of pull request.

How to aggregate (groupby) dataframe using count


Update project list on site

Remove unmaintained projects and add a new one.

http4s-tomcat had someone speak up for it.  It's not dead, it just smells funny.

Oh sorry, I was just going by the README.
https://github.com/http4s/http4s-tomcat#unmaintained

Fair. :laughing:


gossip: add missing dependencies

Description of changes

Supersedes #339552, fixes building Gossip after https://github.com/NixOS/nixpkgs/pull/214906
Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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

Still fails on aarch64-darwin:
build_log_pr_341182.log
Currently in a workshop. Can build and test, but can't really focus too much on it 😅

Still fails on aarch64-darwin:
build_log_pr_341182.log
This time in the fixup phase and not in the build phase. Missing command patchelf

postFixup should be conditioned on !stdenv.isDarwin. patchelf doesn’t work with Mach-O, and that particular fixup probably isn’t needed on Darwin anyway.


Fix Vue 2.7 compatibility

Removes the scope from the reactive object, fixing the RangeError: Maximum call stack size exceeded exception.
Note: I'm running the latest version of npm resulting in the package-lock being rebuilt, apologies for the diff size.
Fixes #82

Thanks! This looks promising. Good catch 👏
No need to fix tests here btw. Once we know it's working in 2.7, we can remove support for Vue < 2.7 remove the separate builds for Vue 2 and Vue 3 and even the separate test runs.

No worries. Travis appears unhappy with the new package-lock format & Vuepress with the composition-api removal so you may want to cherry pick this into whichever branch you want to test this in :)

@MartinMalinda I've pushed up a new version that tests against the v4 branch, is passing for myself locally. Just used vue-demi so I didn't need to change the test infrastructure.

@Hawxy that's probably the optimal path forward here, thanks a lot. I've tried vue-demi once before and I couldn't make somthing work with it, maybe the test suite, I'm not sure anymore.
I'll check more in detail soon, but it seems with this it will be possible to finally fully release v4.

Hey @MartinMalinda,
is there any chance to have at least another prerelease with this anytime soon?

This is also a blocker for my team so getting this in as soon as possible would be ideal :)

I'll be checking it this week, maybe tomorrow. Will let you know here once i have a prerelease, if it works for you, I'll do a new classic release finally.Sent from my iPhoneOn 7. 11. 2022, at 10:32, JT @.***> wrote:
This is also a blocker for my team so getting this in as soon as possible would be ideal :)
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

I've played around with the PR and it works fine for me with Vue 2.7. Thanks a lot, @Hawxy!
Just a little heads up for anyone coming accross this: Although vue-demi (in general) can work with Vue < 2.7, this PR does not - so you need to switch to Vue 2.7 and the new vue-concurrency version at the same time.

it works fine for me with Vue 2.7.

Awesome 👍

Although vue-demi (in general) can work with Vue < 2.7, this PR does not

Because I didn't change any library internals to use vue-demi, I just used it so I could reuse the test infrastructure created for Vue 3.

Yep, I understand - just wanted to point it out for anyone trying this or the new release :)

I've also tested this in a Vue 2.7 app and it works well. It's released in 4.0.0. Thanks @Hawxy and all others testing it!


[UPDATE GUIDE] Update RTL v0.15.0

What
Updating RTL to v0.15.0 supports clnrest interface for CLN (#1392)
How
Following instructions on https://github.com/Ride-The-Lightning/RTL/releases/tag/v0.15.0
Scope

[ ] significant change to core configuration
[ ] independent bonus guide
[x] simple app update

I think this doesn't address this new requirement:

NodeJS version 0.18 or higher

I think this doesn't address this new requirement:

NodeJS version 0.18 or higher

$ NODE_MAJOR=20

The guide is already set to use latest Node version v20.

I think this doesn't address this new requirement:

NodeJS version 0.18 or higher

$ NODE_MAJOR=20

The guide is already set to use latest Node version v20.

Ahh, ok.


Accidental .RHistory file?

Don't think this belongs in this project: https://github.com/timlrx/tailwind-nextjs-starter-blog/blob/master/.Rhistory.

Was migrating my previous r blog over... good find

Fixed in master.


Anonymous/old authoring information on OldCantus

further insight on what the sidebar calls "author":
The admin view of all sources has "User name" and "User(old)".

The first links to a user profile, the second, when present, is just a name. Typically these are the same in some obvious way, but in a few the user is anonymous and only "user(old)" tells us who did the work. (In some cases they are both uninformative, but I'm not too concerned with losing information that isn't there in the first place.)

By the look of it this affected sources that were in progress at the last Cantus update; those that got their source pages changed in the meantime have gotten a user id associated, but about 15 are lingering with their ancient usernames associated and needing to be tied to current users. One or two may need dummy usernames created for them.
This is something to consult about with Debra (if these are still-unpublished sources by people who don't have a Cantus username anyway, can we just make them created by "admin"?)
Originally posted by @annamorphism in https://github.com/DDMAL/CantusDB/issues/737#issuecomment-1613563399

Can we recover this information? Let's check on this...


Declaration engine

rendered

Sooo excited for work on this to begin 🚀

The described approach reminds me a little of the Hindley-Milner type system and its approach to inference,

I actually based our current type engine on Hindley-Milner when I wrote it, hence the function names like unify etc. We are already using the HM algorithms to perform unification and inference.

There hasn't been much activity on this RFC page, largely because I have been working on this prototype: https://github.com/emilyaherbert/declaration-engine-and-collection-context-demo/tree/master/de. The prototype should 1) help explain the idea and 2) acts as a guiding light for our implementation. Trait constraints for generic functions are working in the prototype.
Also, I've basically reworked the entire RFC, so I'd love a second round of feedback. In the meantime, I will hack on a experimental branch in the Sway repo so that we can get things moving. Don't let this scare you away from iterating on the design though!

ping @FuelLabs/sway-compiler would we be able to merge this?


Sample/transit roadbook

Closes https://github.com/Woosmap/woosmap/issues/1351
Describe your changes

Added new code sample for Transit Service with roadbook

How to test

Checklist:

[x] My code follows the style guidelines for this repo
[x] I have performed a self-review of my code
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings/errors
[ ] I have added tests that prove my fix is effective or that my feature works
[x] I don't require ops changes for this PR to go to prod
[x] This change does not include a migration

Comments

Nice one.
Only one little things. when no route are returned, remove the Transit Route Roadbook and maybe add a message using the displayOrHideError method.
Thanks

Nice one. Only one little things. when no route are returned, remove the Transit Route Roadbook and maybe add a message using the displayOrHideError method. Thanks

Done ✔

Ok,
Just a little reminder, as this repo implements SemanticVersioning (fix: commit message, feat: commit message...) if it's not used, no release will be triggered and therefore no deploy to devdoc.
I just add a quick commit to trigger this.

Ok, Just a little reminder, as this repo implements SemanticVersioning (fix: commit message, feat: commit message...) if it's not used, no release will be triggered and therefore no deploy to devdoc. I just add a quick commit to trigger this.

Oh ok. Thanks for letting me know. I will keep that in mind.

:tada: This PR is included in version 1.36.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


test

Describe the bug
aaa
Link to the blitz that caused the error
https://stackblitz.com/run?file=src/app/app.component.ts
Steps to reproduce
aaaa
Expected behavior
aaaa
Parity with Local

[X] I have run the project in my local machine and I could not reproduce the issue.

Screenshots
aaa
Platform
Browser name  = Chrome
Full version  = 100.0.4896.127
Major version = 100
navigator.appName = Netscape
navigator.userAgent = Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.127 Safari/537.36
performance.memory = {
  "totalJSHeapSize": 41167609,
  "usedJSHeapSize": 37995877,
  "jsHeapSizeLimit":<PHONE_NUMBER>
}
Hash = be57dda01bcfe1c4973d7980b1ec44aabd3a6863

Additional context
aa

Closing this issue as it's unclear what goes wrong and none of the required details are filled in. Feel free to open a new issue and fill in all the necessary details so we have enough information to have a look ourselves. The more information we have, the better we can help you 🙏 .


Add GitHub workflow to automatically assign PRs

Our repositories require that every pull request have two approvals
before they can be merged. Often, what will happen is a team will be
added as a requested reviewer but then the first person who reviews
performs their review "on behalf of" the team. That's pretty cool but it
also means that there are no longer any assigned reviewers! This further
means that for anyone using the Review requests tab on GitHub, they
don't see that PR still needs to be reviewed.
This new workflow takes care of that by just re-requesting review from
the team until the review threshold has been met. For simplicity in the
implementation, it pauses asking for reviews once someone has requested
changes (but that matches our branch protection rules anyway).
Because assigning team reviewers requires permissions not available on
the GITHUB_TOKEN, creating a workflow like this previously would have
been a bit of a complication but we're now able to leverage the same
GitHub App that we're using for our other workflow automation (without
having to request a PAT).
Now, one might ask “could this be solved by just using a CODEOWNERS
file or passing team-reviewers to the create-pull-request Action?”
And both of those would solve the first issue: the initial
assignment; however, they don’t handle the continuing review requests
to meet the project’s threshold. The same applies to the various other
Actions that exist to auto-assign reviews to pull requests (and many
can’t support the team_reviewers parameter at all).

Oh wow!! I didn't realize that it would start operating now! That's interesting!

@kylelaker, just thought of this but could we instead make this a reusable workflow/github action? We'll need this ability to re-assign PRs across EasyGRC repositories and it wouldn't make sense to copy this workflow across each repo.

I talked with @mikeisen1 about this briefly the other day. Obviously, we'll want to eventually find a way to get this to work on all our repositories. Unfortunately, GitHub doesn't really have a builtin a way to do that today; so we'll have to just copy-and-paste it to other repositories for now.
One potentially-interesting option would be to use some sort of webhook-driven model (rather than GitHub Actions) but that would require a server implementation.


Memory leak with handtracking iOS

I found a memory leak on example project for iOS.

Model: iPhone 11 Pro
iOS: 13.3
Xcode: 11.3
mediapipe: v0.6.8
bazel: 1.1.0
tulsi: 0.20190814.88
Scheme: HandTrackingGPUApp
3D / 2D both

Message from debugger: Terminated due to memory issue

Is this relevant?
https://github.com/google/mediapipe/issues/93

I can reproduce the issue. We experience leaks with our graphs on iOS as well.
It seems no CPU-only apps are leaking nor is the edge detection example app.
mediapipe v<IP_ADDRESS>
Xcode 11.3.1
iOS 13.3.1 (17D50)
Model: iPhone 6s

ObjectDetectionCpuApp: no leaks
ObjectDetectionGpuApp: crashes with

validateComputeFunctionArguments:771: failed assertion `Compute Function(ComputeFunction): argument size[0] from buffer(7) with offset(0) and length(12) has space for 12 bytes, but argument has a length(16).'

EdgeDetectionGpuApp: no leaks
MultiHandTrackingGpuApp: leaks by allocating about 30MB/s
HandTrackingGpuApp: leaks
HandDetectionGpuApp: leaks
FaceDetectionGpuApp: leaks
FaceDetectionCpuApp: no leaks

We are affected as well. ObjectDetectionGpuApp is crashing.
Could we get some more attention to the issue, @mgyong?
@fenollp, do you have an idea when the problem was introduced?

We're seeing the same thing on MultiHandTrackingGpuApp, Xcode 11.3.1, iOS 13.3.1, iPhone 11 Pro. The leak happens in both Debug and Release, but NOT when open in Instruments (regardless of which Instruments are active), which makes this well nigh impossible to actually debug.

The leak is fixed in upcoming release

Great to hear! Is the fix on the staging branch, or another fork, or is it not available yet? Any chance of posting the fix if it's not available on GitHub yet? It's be really great to get this ASAP.

While release is coming please use the quick fix: replace a single line https://github.com/google/mediapipe/blob/3b6d3c40589968c8333b4a936fbad7a8bea6d7f6/mediapipe/framework/scheduler_queue.cc#L28
with this code:
#ifdef APPLE
#define AUTORELEASEPOOL @autoreleasepool
#else
#define AUTORELEASEPOOL
#endif  // APPLE

Thank you!
For anyone confused by the automatic markdown parsing, that's supposed to be:
#ifdef __APPLE__
#define AUTORELEASEPOOL @autoreleasepool
#else
#define AUTORELEASEPOOL
#endif // __APPLE__

This fix is in https://github.com/google/mediapipe/commit/1722d4b8a25ad7c919576f9b1bab4ffa7a9299bc.


Low test coverage.

I'm gonna improve test coverage!
Please assign this issue to me!

Hi, thank you for your interest and work.
It doesn't matter that the coverage ratio is high, It is much more important to make sure that the test of each case is written, please put this more first.

In the first place, it's my priority, but it would be great to have %99-100 of code coverage.

In the first place, it's my priority, but it would be great to have %99-100 of code coverage.

I agree with you

https://github.com/hakancelik96/unimport/blob/098eb5f3da3ca3213c546e9806806d33b384fbf1/unimport/refactor.py#L135
I'm wondering why this line exists!
I can't figure out in which case this line may be executed!

Fixed: #93

https://github.com/hakancelik96/unimport/blob/098eb5f3da3ca3213c546e9806806d33b384fbf1/unimport/refactor.py#L135
I'm wondering why this line exists!
I can't figure out in which case this line may be executed!

I guess I wrote that if the get_star_imp function returns None, leave_ImportFrom function returns original_node, but now I have examined it, there is no such possibility, so it was an unnecessary line. Because we take all-star imports as unused imports and then offer a suggestion object instead of a star.

So, I'm gonna remove this line, then I think it's a good time to review the PR (#93 )


fix System.NullReferenceException when disconnecting Handler

Besides, disconnecting the Handler is a workaround for memory leaks:
https://github.com/dotnet/maui/issues/20283#issuecomment-2218729505

Thanks @sferhah , I'll work on merging this.
I plan to eventually re-work all the code in this repo to be based on what's shipping in .NET MAUI, and the logic for cleanup/preventing memory leaks is a lot better in that code base. But for now I think this is good!


Dead function elimination

This is the first pass at the code that will remove function that are not needed.  Please let me know if there is anything I am missing.

Did a cursory review of the main code. Looks good.
Good catch on exported functions. I have added an issue to apply size optimizations to exported functions as well.

Rebased and pushed into master as e43c91046b47b


Gzip Compression

Topic Suggestion
Getting Started With Gzip compression
Proposed title of article
Getting Started With Gzip compression
Proposed article introduction
Since website sizes are getting bigger, improving website speed has always been a concern. The size of a website was 2 MB in 2014, and is now 4 MB. It is good to know that we have fast internet, but slow internet users will end up waiting. It remains to be seen, however, whether we can keep websites fast despite larger web sizes? That’s where gzip comes in.
Basically, this article will cover the basics for a beginner.
Key takeaways
Compress files to deliver fast experience.
Encoding and decoding in a matter of seconds.
Optimize website for page speed.
Article quality
This article is going to be unique since Gzip compression is a  technology that can improve web based application speed. The article will also cover Gzip [p basics that are very essential for beginners.
References
Gzip Compression
NOTE: All 1st-time contributors should know Topic approval and PR submission does NOT guarantee your Topic/Article will be published. Our team of Peer Reviewers and Content Moderators will review all PRs that come in to make sure they adhere to the standard of quality we expect from the EngEd community.
We expect all community memebers to go through provided examples, resources, and previously published material before submitting content. As a rule of thumb, please only submit articles (pull requests) that are complete, formatted correctly, and include a fully polished article (ready to be published and error free).
All revisions and edits should be completed on your own forked repo (as to not take up room in the queue). Any PR that is submitted incomplete (meaning not ready to be published as is) will be closed. A PR being closed does NOT mean the article can not be published (or fixed) it simply means that the edits, revisions, and fixes will happen outside of the queue.
NOTE: Any topic suggestion copied/taken/modified from YouTube may Lead to a permanent ban from the community.
Topic Suggestion
Enter topic suggestion here...
Pre-submission advice
By following all our pre-submission advice and reviewing our Resources folder, you will maximise your chances of your topic being approved.
We ask that you please be patient as our team works through approving and publishing all articles/tutorials in a timely manner.
Allow 1-3 days for a topic to be reviewed and/or approved - allow 3-7 days for an articles to be reviewed and/or published (subject to vary depending on volume and/or backlog of articles).
Be sure to visit our Resources Page for tools, resources, and example articles that will help you propose and write a successful article.
Please ensure that you have only one open issue + linked pull request at a time. This will ensure that we complete the article in a timely manner from inception to publishing.)
We tend to stray away or tend not to publish reviews/comparisons of commercial product offerings.
Writing sample(s):
Include any links or writing samples - to help our team better gauge your writing quality.
Proposal Submission
Proposed title of article
Your title should be descriptive of the article/tutorial. Be Specific.
Use keyword research to improve your article's SEO.
Proposed article introduction
We're looking for the first 2-3 paragraphs of your article that appropriately summarize what your article will be about.
We will use this writing snippet to help us assess the overall quality before approval so ensure it has been proofread, spellchecked and grammarchecked.
For example, if the article is based on machine learning, use the following: [Machine learning] Introduction to Machine Learning.
If the article is based on developing an Android application, use the following: [Android] Developing Apps using Android.
ONLY viable topics to pick from:

API
Artificial Intelligence
Blockchain
Containers
Edge Computing
Languages
Machine Learning
Networking
Node.js
Security

Key takeaways
What are the 3-5 most important things the reader should understand or be able to do after reading this article?
Use this area to get your ideas down on the bulk of your article or tutorial.
Article quality
How is your article unique? Tell us what makes your approach different from similar articles that have published on the same topic?
Is yours more in-depth? Does it cover additional topics? Do you provide handy tips or anecdotal advice?
References
Please list links to any published content/research that you intend to use to support/guide this article.
Conclusion
Finally, remove the Pre-Submission advice section and all our blockquoted notes as you fill in the form before you submit.
We look forwarding to reviewing your topic suggestion.
Templates to use as guides

How To Guide Template
Software Review Template
Tutorial Template

Good afternoon and thank you for submitting your topic to the EngEd program.
After some careful consideration it struck us that this topic may be a bit over saturated throughout other blog sites and official documentations. We're more interested in original, practitioner-focused content that takes a deeper dive into programming-centric concepts. Please feel free to suggest an alternate topic to explore. 🚀


Cannot Run deploy to ACI. provided all the required libraries but init() fails in score.py

error: undefined,
stdout: '',
stderr: 'ERROR: {'Azure-cli-ml Version': '1.0.79', 'Error': WebserviceException:\n\tMessage: Service deployment polling reached non-successful terminal state, current service state: Failed\nMore information can be found using '.get_logs()'\nError:\n{\n  "code": "AciDeploymentFailed",\n  "message": "Aci Deployment failed with exception: Your container application crashed. This may be caused by errors in your scoring file's init() function.\nPlease check the logs for your container instance: diabetes-aci-1. From the AML SDK, you can run print(service.get_logs()) if you have service object to fetch the logs. \nYou can also try to run image scrmlops1amlcr.azurecr.io/azureml/azureml_7658761db4e29457d2df7ab09e40fa3e locally. Please refer to http://aka.ms/debugimage#service-launch-fails for more information.",\n  "details": [\n    {\n      "code": "CrashLoopBackOff",\n      "message": "Your container application crashed. This may be caused by errors in your scoring file's init() function.\nPlease check the logs for your container instance: diabetes-aci-1. From the AML SDK, you can run print(service.get_logs()) if you have service object to fetch the logs. \nYou can also try to run image scrmlops1amlcr.azurecr.io/azureml/azureml_7658761db4e29457d2df7ab09e40fa3e locally. Please refer to http://aka.ms/debugimage#service-launch-fails for more information."\n    }\n  ]\n}\n\tInnerException None\n\tErrorResponse \n{\n    "error": {\n        "message": "Service deployment polling reached non-successful terminal state, current service state: Failed\nMore information can be found using '.get_logs()'\nError:\n{\n  \"code\": \"AciDeploymentFailed\",\n  \"message\": \"Aci Deployment failed with exception: Your container application crashed. This may be caused by errors in your scoring file's init() function.\\nPlease check the logs for your container instance: diabetes-aci-1. From the AML SDK, you can run print(service.get_logs()) if you have service object to fetch the logs. \\nYou can also try to run image scrmlops1amlcr.azurecr.io/azureml/azureml_7658761db4e29457d2df7ab09e40fa3e locally. Please refer to http://aka.ms/debugimage#service-launch-fails for more information.\",\n  \"details\": [\n    {\n      \"code\": \"CrashLoopBackOff\",\n      \"message\": \"Your container application crashed. This may be caused by errors in your scoring file's init() function.\\nPlease check the logs for your container instance: diabetes-aci-1. From the AML SDK, you can run print(service.get_logs()) if you have service object to fetch the logs. \\nYou can also try to run image scrmlops1amlcr.azurecr.io/azureml/azureml_7658761db4e29457d2df7ab09e40fa3e locally. Please refer to http://aka.ms/debugimage#service-launch-fails for more information.\"\n    }\n  ]\n}"\n    }\n}}\n' }
File "/azureml-envs/azureml_3921e717c180127e72729a5bd9ba1fe6/lib/python3.7/pickle.py", line 1426, in find_class
import(module, level=0)
ModuleNotFoundError: No module named 'sklearn.linear_model._ridge'

I downgraded python version to 3.6.2 and it seems to be working fine now.


Loop for M3U8 File

Hello,
On certain publisher websites, video resolution and detection work successfully, and the download proceeds as expected. However, the M3U8 file does not loop, leading to a recording of only 10-20 seconds of the video stream.
Is it possible to record until the M3U8 file is completely empty? I wanted to develop this feature myself, but the required coding knowledge for this plugin is quite advanced.
For testing purposes, I wanted to try it on a site called "chatur...com". Although the video stream is found and recording starts, only a few seconds of the video are recorded. How can the loop be maintained indefinitely (until the file is empty)?
Thank you for your work.

Intersting, can you share the M3U8 file?

Hello @puemos
Of course, this link

Thanks. Can you share the mater m3u8 files with the links to the playlists?

I think you are talking about this file; https://bit.ly/3UVoUBT

Fantastic extension, thank you ! I'll try to debug when I find time

@onedayblack is this for recording Live broadcast? I was analyzing the source code and I missed this feature.

@onedayblack is this for recording Live broadcast? I was analyzing the source code and I missed this feature.

It does not work

@onedayblack  So I saw the source code of another extension that detects when m3u8 is a live stream and loops the m3u8 fetch to get the fragments and updates a queue that will be consumed by another loop that downloads the '.ts' files. Maybe we can implement this feature in this extension to be able to record live streaming.

I am also interested in how to do this. Does someone have insight into where the extension detects the video? This might help me figure out a solution for streams.

@MrKeon It is written in type script, using react ? and js libraries hence it needs to be 'compiled'. Too modern for my ancient rusty plain js knowledge. The detection happens in the src/extension/extension-background/. Look at setTabListener.ts - when tab is opened, a statement 'browser.tabs.onActivated.addListener' handler adds a listener. The listener should catch the Urls of the loaded web resources I guess. It has m3u parsing libraries, etc.


Minute function only returns a single digit + Additional Helpful Variables

If the time is 12:00 for example, the minute only returns a single digit.
In order to get around it, I did the following:
String(format: "%02d", startDate!.minute)
Also, idk if you'd like me to submit a pull request, but here are a few useful variables I added for 12hour support:
public var twelveHour: Int {
        if hour > 12 && hour != 24 {
            return hour - 12
        } else {
            return hour
        }
    }

public var twelveHourPeriod: String {
        var period = String()
        if hour >= 12 && hour != 24 {
            period = "PM"
        } else if hour < 12 || hour == 24{
            period = "AM"
        }
        return period
    }

I'm always open to pull requests. Feel free to send me one with your modifications, and make sure you add the required tests for it (I do not accept PRs without tests or with failing tests).


Create Source Buffer and Lexer

Description
This issue is focused on laying the foundation for the compiler by implementing a source buffer and a lexer. The source buffer will handle the input source code, and the lexer will tokenize the input into meaningful symbols for further processing by the parser.
Tasks

Source Buffer:

[x] Design the interface for the SourceBuffer class.
[x] Implement methods to load source code from a file or string.
[ ] Implement methods to manage and access the current position within the buffer.
[ ] Ensure efficient handling of character streams and lookahead.

Lexer:

[ ] Design the interface for the Lexer class.
[ ] Define token types and structure (tokens.hpp or equivalent).
[ ] Implement the tokenization logic:

[ ] Handle different types of tokens (keywords, identifiers, literals, operators, etc.).
[ ] Manage whitespace, comments, and special symbols.

[ ] Implement error handling and reporting for invalid tokens.
[ ] Create unit tests for the lexer to ensure accurate tokenization.

Documentation:

[ ] Write comprehensive comments for all public methods and classes.
[ ] Create a README or documentation file that explains the usage of the SourceBuffer and Lexer.

Code Quality:

[ ] Ensure that the code follows clean code principles (e.g., clear naming conventions, modularity).
[ ] Implement linting and code formatting tools in the CI/CD pipeline.
[ ] Perform code reviews before merging into the main branch.

Acceptance Criteria

The SourceBuffer class is fully implemented and tested, capable of handling different input sources.
The Lexer class can accurately tokenize input source code into defined tokens.
All code is documented, follows clean code standards, and passes the CI/CD checks.
Unit tests for the lexer are written and all tests pass successfully.

Related Issues

This issue is a part of the compiler project roadmap.
Future issues will build on the source buffer and lexer, such as the parser and AST generation.

Additional Notes

Consider future scalability when designing the SourceBuffer and Lexer, as they will be foundational components for the entire compiler.

For the first task Source Buffer, I used section 3.2 of the Dragon book, check it for more info, we could add a pair buffer, and make dynamic sentinels.