[WW-4958] Uses less restrictive RegEx to check if it's a multipart request

Fixes WW-4958

Coverage remained the same at 46.997% when pulling f45d2752bb089ade2e41320b81283cbc8aa78259 on lukaszlenart:WW-4958 into<PHONE_NUMBER>2b1e673402e21d52320fe41dbda500 on apache:struts-2-5-x.

@apache/struts-committers can someone hit the button?

After merge I discovered some issues via reading WW-4958 comments references. I tried GitHub's revert on this but wasn't what I expected so I opened the new one #350 to address those.

I wouldn't revert changes using Github functionality, please be aware that this repo is just a mirror, bi-directional but mirror. Also we should keep history consistent, if some changes went in, even wrong one, we shouldn't fix them with another commit and not to revert history of changes.


⚠ Heritage of Faith Christian Church - Gold Coast has degraded performance

In 00990ce, Heritage of Faith Christian Church - Gold Coast (https://heritageoffaith.com.au) experienced degraded performance:

HTTP code: 200
Response time: 11824 ms

Resolved: Heritage of Faith Christian Church - Gold Coast performance has improved in be2706d.


How to get SQL script before calling DbContext.SaveChanges()

I use EF core 2.2
How to get generated SQL scripts to be applied. I need something like that
 private IEnumerable<string> GetSqls<TEntity>(ICollection<TEntity> entities)
        {
            foreach (var entity in entities)
            {
                DbContext.Add(entity);
            }

            // list of the apply sql scripts. something like this DbContext.GetQueries()
            foreach (var query in DbContext.GetQueries())
            {
                yield return query;
            }

          //  DbContext.SaveChanges();
        }

@zsender - Can you describe why you need to get SQL for SaveChanges?

I have methods for synchronizing database dictionaries (these methods are also used in code, in services).
Therefore, I use DbContext.
My database is created by migration. At the end of the script, I added my own method for inserting data for dictionaries. I did this to create either everything or nothing (in one transaction).
The problem is that when I call DbContext.SaveChanges(), I get an error that the object does not exist.
Therefore, I need to get scripts from DbContext and pass them to MigrationBuilder.Sql(...) so that it sequentially performs all the actions.

Is it possible somehow in MigrationBuilder to pass executing DbContext.SaveChanges()

To modify data in a migration, use migrationBuilder.Insert(), Update(), and Delete()--not the DbContext.

How to do it? If when adding an item we have navigation property?

Use foreign key values and insert data in the correct order.

This is understandable, I wanted to solve this problem by DbContext. The first reason is to forget about changes of fields of Entity (deleting, renaming columns, or remove or create navigation properties). The second reason, do not to editing SQL, delegate  this for the DbMigration.

Are you looking for Data Seeding?

Not exactly what I wanted, but this solution is working. Thanks for help.


Harmonize page templates across Sections, Lists and Content pages

What is it and who's it for?
All site users
Due to the long-running iterative development of the site, we've ended up with a lot of variety in our page templates, making it much harder to see a consistent site hierarchy.
As we've iterated on a section-by-section basis, we've created some pages with custom functionality, and those pages sometimes also have hero images. We've already done the work on making the cards and card groupings consistent across all sections (pending content development), but the headings of these page templates needs work:

section-level pages (Visit us, What's on, Stories, Collections, Get involved/What we do)
landing pages
list/index pages
content pages

Project Brief: https://www.notion.so/wellcometrust/Project-Brief-Improving-section-content-browsing-and-navigation-8d11582ef0e14a95a1a617a394f919ea
Problems to solve

Lack of consistency in background graphic
Over-dominant hero image takes up a significant amount of page real estate and is a barrier to any possible custom functionality (a search box; filters; dynamic info).
Setting guidelines for each template's header
Resolving the alignment problem here #6045

Implementation TBC
Acceptance criteria TBC

Relates to KR wellcomecollection/platform#4645

Designs looking to introduce consistency across Section pages: App • Web

Section summaries
Visit Us
Wellcome Collection is a free museum and library connecting science, medicine, life and art. Come and see the exhibitions, events and collections in our beautiful building in central London. You will need a ticket to enter the building.
What’s on
Come to events and exhibitions, online and in our building. All our permanent and temporary exhibitions are free, and so are most of our events. We hold a wide variety of events throughout the year, from tours to multi-part festivals.
Stories
Our stories relate to health and the human experience. We use words and pictures in a variety of ways to make connections, provoke new thinking and share lived experiences. Dive into a story no matter where in the world you are.
Collections
Our collections are at the heart of what we do. Find out what we have by searching online or visiting our library. If you’re interested in exploring and researching our collections, we’re here to support you.
Get involved
Get involved with what’s happening at Wellcome Collection. From activities for specific groups, such as young people, to opportunities for collaboration and working with us, it’s up to you just how involved you’d like to be.

@jennpb do you we need all the section summaries to be in prismic for the editorial team to update? stories is static at the moment, collections and whats-on are not primisic pages ?
Thanks

It would be v v useful for my team if these were Prismic editable.


fix: Typo in README.md

What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind design

/kind documentation

/kind failing-test

/kind feature

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area plugins

/area registry

/area build

/area documentation

What this PR does / why we need it:
Fixed a typo in the README.md
Which issue(s) this PR fixes:

Fixes #253
Special notes for your reviewer:

Thanks for your pull request. Before we can look at it, you'll need to add a 'DCO signoff' to your commits.
:memo: Please follow instructions in the contributing guide to update your commits with the DCO
Full details of the Developer Certificate of Origin can be found at developercertificate.org.
The list of commits missing DCO signoff:

21ba8b9 fix: Typo in README.md

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

Welcome @MukulKolpe! It looks like this is your first PR to falcosecurity/plugins 🎉

Hi @MukulKolpe. Thanks for your PR.
I'm waiting for a falcosecurity member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: MukulKolpe
Once this PR has been reviewed and has the lgtm label, please assign jasondellaluce for approval. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found 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

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: jasondellaluce, MukulKolpe
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 [jasondellaluce]

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

LGTM label has been added.  Git tree hash: 220498d2a4045b84b3f7c73807db27427733a455

@jasondellaluce: Closed this PR.

In response to this:

/close
Closing and reopening to trigger the CI.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

/reopen

@jasondellaluce: Reopened this PR.

In response to this:

/reopen

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.


Update for large disk GA

This checklist is used to make sure that common guidelines for a pull request are followed.

[x] The PR has modified HISTORY.rst describing any customer-facing, functional changes. Note that this does not include changes only to help content. (see Modifying change log).

[x] I adhere to the Command Guidelines.

@adewaleo What is the next step on me?

@yuemlu why are there two separate PRs for this?

@yuemlu You didn't fully address my previous comment.
az vm disk --size-gb should only mention "managed disks".
On the other hand, az vm unmanaged-disk attach --size-gb should mention "unmanaged disks".
Currently you are referring to both managed and unmanaged disks in a command that works only for managed disks.

@yuemlu please get CI passing or this PR will be closed due to inactivity.

Closing due to inactivity. Feel free to address comments and reopen.


Recognize delete expressions

delete expressions need to be recognized in order to avoid an error due to the missing return value.
Test case to show the difference between the old and the new version:
uint8[3] memory array = [1,2,3];
delete array[1];
array

Thanks!


Make FreeRTOS prvCreateDNSSocket check FreeRTOS_socket return code.

Make prvCreateDNSSocket check the return code of FreeRTOS_socket.  The FreeRTOS_socket method is allowed to return FREERTOS_INVALID_SOCKET.  The prvCreateDNSSocket calls FreeRTOS_socket and then possibly calls FreeRTOS_bind and FreeRTOS_close without checking that the socket is valid.  This one-line fix just returns an error code if FreeRTOS_socket returns an error code.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Thanks for finding this one. It has been there since version 1.0, the UPD-only library.
	/* This must be the first time this function has been called.  Create
	the socket. */
	xSocket = FreeRTOS_socket( FREERTOS_AF_INET, FREERTOS_SOCK_DGRAM, FREERTOS_IPPROTO_UDP );

	/* Auto bind the port. */
	xAddress.sin_port = 0;
	xReturn = FreeRTOS_bind( xSocket, &xAddress, sizeof( xAddress ) );

	/* Check the bind was successful, and clean up if not. */
	if( xReturn != 0 )


Color Status Token

Just an additional default token for colorized status codes.  Not sure if it would be wanted or useful.

Thanks! The concept seems fine, just a few issues:

The changes do not even compile. All tests are red due to the inability to now even require() the script. Please take a look into this issue.
There are no tests for the added token, please add complete tests for app possible branches of the token :)
There is no documentation added to the README for the token, so that would be sweet to get added as well :)

In addition to this, this PR should also DRY up the dev format as well. Probably the code for this new token should be the exact same color code from the dev format instead of some other code, and the format can just use this token and then get smashed down into just being a string like the other formats are.

Thanks for the feedback.  I will get the details hashed out and resub.

Cool :) Just update this pull request with the new changes and ping me when they are included and I'll take another look :)

@dougwilson Dried up the dev compile to the string format.  Added test for new token, and corrected test for dev to account for the resulting changes to responses, left in the color test in dev even though they were a little redundant.  Added colorstatus token to docs.  Also, changed the color code to be more inline with the original implementation from dev.  Sorry if there was any build spam.

The last comment on this was on May 28. Is this still on track to being implemented @frankydp? Seems like a revert of a removed test is still pending.

@arikalfus Revert was committed, with a clear added to accommodate, back on May 28th.  Pull seems to have conflicts now though.

Hi @frankydp , sorry, until very recently GitHub did not send any notice when PRs where updated, so since your last update you never posted a comment, I didn't realize you pushed anything else, very sorry for the misunderstanding!
Looking over the PR, there are still a few issues to be resolved:

Every line in the :dev format seems to now be starting with a space character where before the first letter of the method was the first character. You should probably remove that space character.
The documentation for :colorstatus is confusing. It sounds like it's just the colorized :status token, but if I override that token to do something different, :colorstatus does not seem to be affected.
It doesn't seem like you reverted those tests that I asked earlier, as they are still showing as altered in the current diff (one line was changed and another line was removed). Can you put them back to how they were, please?

Closing the PR since I never heard back and there are conflicts that prevent merging.


nlf.find() does not return duplicate module entries

This is an enhancement request. It would be nice to provide an option that allows nlf.find() to return all entries for modules duplicated in the dependency hierarchy. For example, the module 'ms' can be found twince in the hierarchy of dependencies for express (under node_modules/debug/node_modules/ms
and node_modules/send/node_modules/ms) but nlf.find() only returns a single entry in its output array for 'ms'. Perhaps add a new boolean key to the options object ('getDuplicate') which would return these modules twice in the returned output array with module.directory set to the appropriate location.

Now made obsolete by npm3


cleaning logging, have single logging.yaml, fix logging for ND

Moloy,
You changed ‘deviceType’ back to ‘family’ in l3Clos.py. But ‘family’ is deprecated. ‘deviceType’ is the correct one. Right?
-yun
From: moloyc<EMAIL_ADDRESS>Sent: Monday, January 12, 2015 10:04 PM
To: Juniper/OpenClos
Subject: [OpenClos] cleaning logging, have single logging.yaml, fix logging for ND (#119)

You can merge this Pull Request by running
git pull https://github.com/moloyc/OpenClos devR2.0
Or view, comment on, or merge it at:
https://github.com/Juniper/OpenClos/pull/119
Commit Summary

cleaning logging, have single logging.yaml, remove console logger for ND, add /var/log for ND
fixing unit test

File Changes

D jnpr/openclos/conf/loggingTest.yamlhttps://github.com/Juniper/OpenClos/pull/119/files#diff-0 (33)
M jnpr/openclos/dao.pyhttps://github.com/Juniper/OpenClos/pull/119/files#diff-1 (3)
M jnpr/openclos/devicePlugin.pyhttps://github.com/Juniper/OpenClos/pull/119/files#diff-2 (6)
M jnpr/openclos/l3Clos.pyhttps://github.com/Juniper/OpenClos/pull/119/files#diff-3 (9)
M jnpr/openclos/report.pyhttps://github.com/Juniper/OpenClos/pull/119/files#diff-4 (6)
M jnpr/openclos/rest.pyhttps://github.com/Juniper/OpenClos/pull/119/files#diff-5 (9)
M jnpr/openclos/tests/performance/stressRest.pyhttps://github.com/Juniper/OpenClos/pull/119/files#diff-6 (9)
M jnpr/openclos/tests/unit/test_devicePlugin.pyhttps://github.com/Juniper/OpenClos/pull/119/files#diff-7 (8)
M jnpr/openclos/tests/unit/test_l3Clos.pyhttps://github.com/Juniper/OpenClos/pull/119/files#diff-8 (2)
M jnpr/openclos/tests/unit/test_rest.pyhttps://github.com/Juniper/OpenClos/pull/119/files#diff-9 (2)
M jnpr/openclos/tests/unit/test_util.pyhttps://github.com/Juniper/OpenClos/pull/119/files#diff-10 (35)
M jnpr/openclos/tests/unit/test_ztp.pyhttps://github.com/Juniper/OpenClos/pull/119/files#diff-11 (2)
M jnpr/openclos/trapd.pyhttps://github.com/Juniper/OpenClos/pull/119/files#diff-12 (6)
M jnpr/openclos/util.pyhttps://github.com/Juniper/OpenClos/pull/119/files#diff-13 (82)
M jnpr/openclos/writer.pyhttps://github.com/Juniper/OpenClos/pull/119/files#diff-14 (3)
M jnpr/openclos/ztp.pyhttps://github.com/Juniper/OpenClos/pull/119/files#diff-15 (8)

Patch Links:

https://github.com/Juniper/OpenClos/pull/119.patch
https://github.com/Juniper/OpenClos/pull/119.diff

—
Reply to this email directly or view it on GitHubhttps://github.com/Juniper/OpenClos/pull/119.


trufflehog: 3.59.0 -> 3.60.0

Diff: https://github.com/trufflesecurity/trufflehog/compare/refs/tags/v3.59.0...v3.60.0
Changelog: https://github.com/trufflesecurity/trufflehog/releases/tag/v3.60.0
Description of changes

Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

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

1 package built:

trufflehog


Support more aggregations

Looks like there's a new typed_keys parameter we could utilise to parse aggregations exactly.
Since it depends on the parameter being present in the request we would probably have to have an alternative Aggregations parser that expects it to be present.
API Gist
See here

I think we should add this to #319 (v0.21.0). I am running into the issue of not being able to easily access anonymous aggregations in a project.
I am happy to open a PR to replace the current implementation with your gist.


3.2.1 Release request

Hi,
It would be great to have the release that contains the permgen leak fix, so that spring can repackage it.
Thanks in advance.

The release must be made by someone with the credentials. The current state would be a clear improvement. @samberl, could you trigger a release?

Sure I'll take a look.
On Wed, Feb 10, 2016, 2:50 AM Rafael Winterhalter<EMAIL_ADDRESS>wrote:

The release must be made by someone with the credentials. The current
state would be a clear improvement. @samberl, could you trigger a release?
—
Reply to this email directly or view it on GitHub
https://github.com/cglib/cglib/issues/61#issuecomment-182240743.

Guys, thanks for your efforts. FYI, we'll be releasing Spring Framework 4.2.5 next Monday (Feb 22). If CGLIB 3.2.1 is available in Maven Central by that time, we'll be happy to include it right away.

I just looked over the recent commits and have some concerns about API compatibility, so don't think it's best to push a release right now.
@raphw & @vlsi -- can you chime on on the API compatibility concerns I mentioned @ https://github.com/cglib/cglib/commit/196da25819cd2080f87306c391611f1113e3391a#diff-eec25ed9d2099dbe5d7d1004957aec64L43 ?

Having had a look at those commits, they do indeed look like significant API changes. Maybe the next release should rather be called CGLIB 3.3 if some of those changes turn out to be necessary?
In any case, no hurries from our side. We'll pick it up for Spring Framework 4.3 then (GA in May).

Having had a look at those commits, they do indeed look like significant API changes. Maybe the next release should rather be called CGLIB 3.3 if some of those changes turn out to be necessary?
In any case, no hurries from our side. We'll pick it up for Spring Framework 4.3 then (GA in May).

@jhoeller , @sameb ,
Please, point where do you see API changes.
I think I did not modify old tests. This means the API was not changed from test perspective.
I did my best to keep backward compatibility.

Just created a PR to adress the backward compatibility issue (https://github.com/cglib/cglib/pull/63). Let me know of thatś good for you.

I'll try to do a release tomorrow. Thanks for the PR @elrodro83!

@sameb, @elrodro83, Spring Framework 4.2.5 is a few days behind schedule in the meantime and was meant to go out today now... Given that you intend to release CGLIB 3.2.1 today, we'll be postponing until tomorrow on our end in order to pick it up.

3.2.1 is released to maven.  It may take a few hours to appear on maven central.

Looks like it's up @ http://central.maven.org/maven2/cglib/cglib/3.2.1/

@sameb, thanks for your efforts there! I'm in the process of picking it up for Spring Framework 4.2.5.
Unfortunately we have a regression with respect to proxy class reuse: For the same proxy specifications, we end up with individually generated classes now where previously we got the same class. Any hints appreciated in terms of what could be causing this; I suspect it is directly related to the permgen fix but I got trouble figuring out the actual root of the problem...

@jhoeller , do you have a quick example to reproduce the case?

@vlsi, at this point, I'm debugging failing tests in the Spring Framework test suite, e.g.: org.springframework.aop.framework.CglibProxyTests.testMultipleProxies() in the spring-context module. I'll isolate a minimal example ASAP, not least of it all to find out about the differences.
One thing I've noticed already is that a ClassLoader has to be specified now, whereas previously that wasn't strictly necessary, due to synchronization performed on the Enhancer's ClassLoader reference now. This should be easy enough to address on our end but is technically also a subtle regression.

Thanks for helping to isolate the minimal repro!  Please do point out any more regressions.
@vlsi, can we do anything about the class loader issue @jhoeller referred to?

The reuse issue seems to be something rather involved with the enhancer cache key when backed by a Spring AOP ProxyCallbackFilter. A quick plain Enhancer based test against the same target class passes for me, reusing the proxy class as expected.
As for the class loader issue, it's a new synchronized block in AbstractClassGenerator.generate which expects ClassLoaderData.getClassLoader() to be non-null... and if no ClassLoader has been specified on the Enhancer, that one seems to return null. FWIW, I'm also running into that issue just in specific cases... I guess depending on whether there is a cache hit or cache miss, can't tell yet. For Spring's purposes, it is easy enough to sort out though, simply explicitly specifying proxySuperClass.getClassLoader() on the Enhancer if no ClassLoader has been given otherwise (i.e. not implicitly relying on Enhancer.getDefaultClassLoader()).

synchronized block in AbstractClassGenerator.generate which expects ClassLoaderData.getClassLoader() to be non-null.

It might take me a while to setup IDE to run spring-framework tests, however the "classloader issues" might be due to wrong classloader being used in new ClassLoaderData(classLoader): https://github.com/cglib/cglib/blob/ef8fdd49bc71932486d4bd2d489414f8452f579a/cglib/src/main/java/net/sf/cglib/core/AbstractClassGenerator.java#L260-L268
It looks like as if local ClassLoader loader should be better there.

A quick update: It's indeed about CallbackFilter equality - a plain Enhancer test specifying the simplest possible CallbackFilter fails to reuse the proxy class, even if the CallbackFilter implements equals and hashCode accordingly. The test just passes if the CallbackFilter is the very same instance...

And one more: Hacking Spring's CglibAopProxy implementation to reuse the ProxyCallbackFilter instance makes the problem go away. So it indeed seems that, as of 3.2.1, Enhancer requires a CallbackFilter to be instance-identical for a proxy class to get reused... whereas previously it accepted CallbackFilters that were equal according to their equals/hashCode implementation.

a plain Enhancer test specifying the simplest possible CallbackFilter fails to reuse the proxy class, even if the CallbackFilter implements equals and hashCode accordingly

@jhoeller , can you just reuse CallbackFilter instances?
I might need to rethink WeakIdentityKey: https://github.com/cglib/cglib/commit/c1d6d31b06a423a173d11a9111bee43999793e37#diff-173a9c4b512f39086ed564b6320318e2R378
Having strong reference to the original CallbackFilter will hold a strong reference to its ClassLoader, thus introduce a memory leak.
Personally, I do not like how CallbackFilter serves two purposes: it acts as a filter and as a cache key. It would be nice if we could isolate "cache key" part from "filtering" part.

On the other hand, I see nothing that prevents using "source object" for hashCode/equals if WeakReference is not yet expired.
I do not remember why I used identity-based key.

I just tested equals/hashCode delegation in WeakIdentityKey, and cglib tests still pass, thus it seems to be a missing optimization.

Technically, we could quite easily manage a canonical ProxyCallbackFilter instance for each advised Spring bean. We'd have to extract our own cache key, based on ProxyCallbackFilter's current equals implementation, and store the filter instance accordingly. Of course, we'd have to carefully avoid a permgen leak of our own there but I suppose that'd be manageable.
However, this is nevertheless a regression. Spring's repackaged version of CGLIB is used in other places in the Spring portfolio as well, and we can't update all of those places to manage a canonical CallbackFilter instance right away. We could only really do that as of Spring Framework 4.3, where we have a release candidate phase to go through in a couple of months.
So the key question is: Will CGLIB 3.2.2 restore equality support for CallbackFilters? Sounds like that's feasible? Or will we have to adapt to filter instance identity in the long run?

Will CGLIB 3.2.2
Sounds like that's feasible?

Technically speaking, that depends on @sameb 's bandwidth.
@sameb , what is the probability to release 3.2.2 in the observable future?

However, this is nevertheless a regression

I would agree.

For the time being, we can simply stick with CGLIB 3.2.0 in Spring Framework 4.2.5 and possibly in the entire 4.2.x line, living with the permgen behavior that's been around so many years already. It would be good to have a CGLIB 3.2.2 for Spring Framework 4.3 though but that's still a few months to go.

I don't have the time to do dev work, but I can release a 3.2.2 when the
code is ready. I agree that this is a regression we don't want. We need to
reinstate support for equals/hashCode equality, IMHO even if the original
filter has been GC'd (because we don't know the usage patterns here).
Re: the cglib tests -- don't rely on them for much. They are far from
exhaustive. When changing code, you'll typically want to write regression
tests for the old behavior to make sure it didn't change.
@vlsi, do you think it's possible to still kill the classloader leak even
if we need to keep the old equals/hashCode semantics?  If not, I think we
just need to ditch that new code and revert to how it was before. If so,
great.
How long do you think it would take to make things stable again?  I'd like
to make sure the most recent release doesn't have regressions. Is there a
way to redact or mark bad a Maven release?
On Wed, Feb 24, 2016, 9:41 AM Juergen Hoeller<EMAIL_ADDRESS>wrote:

For the time being, we can simply stick with CGLIB 3.2.0 in Spring
Framework 4.2.5 and possibly in the entire 4.2.x line, living with the
permgen behavior that's been around so many years already. It would be good
to have a CGLIB 3.2.2 for Spring Framework 4.3 though but that's still a
few months to go.
—
Reply to this email directly or view it on GitHub
https://github.com/cglib/cglib/issues/61#issuecomment-188282564.

do you think it's possible to still kill the classloader leak even
if we need to keep the old equals/hashCode semantics?

I think so.
Classloader leak is covered by the cglib tests (it was added as a part of the feature development). As I said earlier, proper equals/hashCode delegation does not break cglib tests => it should be easily doable.

When changing code, you'll typically want to write regression
tests for the old behavior to make sure it didn't change.

The problem with "regression" tests is you never have 100% coverage.
I think I deliberately went with "identity" based keys, then never reconsidered to resort to equals delegation.
It would be good if we could add spring-framework tests to cglib's Travis job. That would probably increase regression coverage.

How long do you think it would take to make things stable again?

I think I can make that in a day or two.

Is there a way to redact or mark bad a Maven release?

I think the best way is to resease a subsequent one.
Some comments at "github/release" would help as well.

The most important assumption that Spring makes, as far as my analysis goes, is indeed CallbackFilter equality leading to the reuse of proxy classes. Some tests for that will cover quite a bit of ground already. Beyond that, the Spring Framework test suite has plenty of integration tests, of course...

I added a warning to the release notes. Let me know if I summarized it
incorrectly. Thanks for all the help, everyone!
On Wed, Feb 24, 2016, 10:08 AM Juergen Hoeller<EMAIL_ADDRESS>wrote:

The most important assumption that Spring makes, as far as my analysis
goes, is indeed CallbackFilter equality leading to the reuse of proxy
classes. Some tests for that will cover quite a bit of ground already.
Beyond that, the Spring Framework test suite has plenty of integration
tests, of course...
—
Reply to this email directly or view it on GitHub
https://github.com/cglib/cglib/issues/61#issuecomment-188297336.

I think #65 and #66 should sort the issues out. However I did not configure spring project yet, so there might be other failures.

I ran the spring build with this fixes and it ran correctly. I created https://github.com/cglib/cglib/issues/69 for a release including those changes.


Correct the y-axes for the Metron Egress in the CF: Metron Agent dashboard from bytes to short

Just a small quality of life thing.
The graph for Metron Egress is displaying in bytes, when it looks like it should be just a number of messages.
Swapped the format from bytes to short so it is displayed as a number of messages.
Old:

New:

Thanks @srothwell01!


How do I send a message?

Describe the bug
How can I send message when I'm focused on the prompt?
Reproduction steps
ctrl+3 / ctrl+down
(default is alt and I changed it to ctrl)
Expected behavior
Send message
Logs and screenshots
No response
Method of Installation
Cargo
tgt version
1.0.0
Operating System (including version and architecture)
Windows 10
Terminal and Command Line Interface (CLI) (including versions)
wezterm nightly
rustc and rustup target (including versions)
No response

Oh, how can I change it to ctrl+enter? alt enter is used by glazewm for opening the terminal and the whole alt key is used to switch my workspaces thats why I use ctrl

Right now the only hardcodrd keymaps are the prompt one, we should work on this feature.
I suggest you change the terminal one for the moment, could you work on it?

I see, It's fine I can use it when it updates and since I have school I can't work on that unfortunately. maybe in future tho!


Xcode String Catalog is populated with all types of languages

The bug
We have started to upload Xcode String Catalogs using this crowdin/github-action:
 files: [{
  "source" : "/path/to/Localizable.xcstrings",
  "dest" : "/some/other/path/Localizable.xcstrings",
  "translation" : "%original_path%/%original_file_name%",
  "multilingual": true,
 }]

In the workflow we put:
upload_sources: true
download_translations: true
upload_translations: false
create_pull_request: true

The downloaded string catalog then contains far too many localisation keys:
["ar", "be", "bg", "bn", "ca", "cs", "da", "de", "el", "en", "es", "et", "eu", "fa", "fi", "fr", "he", "hr", "hu", "id", "is", "it", "ja", "ka", "ko", "lt", "lv", "ms", "my", "nl", "no", "pl", "pt-BR", "pt-PT", "ro", "ru", "si", "sk", "sl", "sr-CS", "sr-SP", "sv", "th", "tr", "uk", "ur-PK", "vi", "zh-Hans", "zh-Hant"]

The localisation key "sr-SP" even triggers a warning from AppStore connect:
ITMS-90176: Unrecognized Locale

Expected behavior
The downloaded string catalog should have the same languages as the .strings and .stringsdict files.

@caldrian: This is related to the process of exporting the xcstrings file format, not the action itself.
Please contact our Customer Success team for further investigation. Sorry for the inconvenience!


ENH: write denoising stats to artifact

fixes #79
This was more work than I expected.
Some things that might improve this in the future:

Metadata seems like an obvious "super format". Is there a good way to indicate what columns are meant to be present and auto-generate a format from that?
Framework could have transformers built in for Metadata and sub-formats
reading/writing TSV files is still a frustrating experience, and there's probably still a million holes. Can we use the above ideas to create a generic and robust parser?

TODO:

[x] all the tests are borked.

I can take a stab at testing and getting the PR finalized. Probably later today (?) 🙏 .

If my tests and other changes look okay to you @ebolyen, feel free to hit that "Squash and merge" button! ⏭

Thanks @thermokarst!


https://rakudo.org/news not showing latest release

Need an entry for 2020.05.01

Star? As latest is 2020.06.

is missing from https://rakudo.org/downloads/star, then, also.

Star has a different life cycle with rarer releases, no?

Yes, the star release cycle is different. but you just said there was a 2020.06 star release.

Oh, sorry, too concise to be readable...
I meant "Did you mean Star in OP? Because its latest release is "2020.05.01" you wrote, but if this ticket says about just a rakudo release, then latest is 2020.06".
And soon will be 2020.07. Absence of automagic updates for this is not cool, anyway.

Looks like this is now updated


Remove needless 'old_orphan_check' feature flag

With build on rustc 0.13.0-nightly (ad9e75938 2015-01-05 00:26:28 +0000), we needless this feature flag.

Sorry. This was hasty conclusion....


Does it support SRID?

Hi,
I tried to use it to export geometry point as binary and use COPY command to copy it to PostGIS, but reports "ERROR: Geometry SRID (0) does not match column SRID (4326)". So my question is where can I set SRID to geometry types and then write them to binary? Thanks.
State your question
A clear and concise question.
Additional context
Add any other context or screenshots related to your question.

The SRID is not part of the WKB specification.
From the PostGIS ST_GeomFromWKB documentation:

The ST_GeomFromWKB function, takes a well-known binary representation of a geometry and a Spatial Reference System ID (SRID) and creates an instance of the appropriate geometry type
If SRID is not specified, it defaults to 0 (Unknown).

If you know the SRID of the WKB, such as 4326, you should try creating it with the optional SRID value.


React native MMKV storage support

Is your feature request related to a problem?
Would be nice if we could use MMKV instead of async storage
Describe the solution you'd like
Describe alternatives you've considered
Related sub-libraries

[ ] All of them
[ ] posthog-web
[ ] posthog-node
[x] posthog-react-native

Additional context
Thank you for your feature request – we love each and every one!

Some people may have mmkv instead of async storage, posthog could detect if async storage not present fallback to mmkv + option to prefer mmkv

We didn't want to end up with 100s of if statements trying to cover every possible dependency 😅
But you can just configure your own interface like so:
const options: PostHogOptions = {
  customAsyncStorage: {
    getItem: (key: string) => Promise<string | null>,
    setItem: (key: string, value: string) => Promise<void>
  }
}

mmkv is sync, any chance to get a sync storage provider? to be able to have feature flags on first render/paint @benjackwhite

I'm not 100% certain but I would expect if you simply resolve immediately in those custom functions then it basically will be sync, especially from a first-render point of view?

The bridge is async by design, so even if you resolve/await a function, it does not guarantee the order of execution, it might be that something is executed before your awaited function (it's an event loop/single thread), that has also been awaited for.
A solution for all the async problems is to migrate to the RN new architecture and define when a method is async/sync or even have both.
Since all the storage plugins are Native libs (android/ios), this would be the best/most reliable option.
For most cases, just awaiting the methods is enough, showing loading progress. At the same time, the calls get resolved, and after you decide what to do depending on the resolved feature flags, it's not necessary to be before the first render/paint, you can work around that by just using this suggestion for now.

@marandaneto I don't see any native code, so what needs to be migrated or am i missing something?

I'm not 100% certain but I would expect if you simply resolve immediately in those custom functions then it basically will be sync, especially from a first-render point of view?

@benjackwhite doesnt matter how fast it is, if you need to await it wont be available on first paint/render

@marandaneto I don't see any native code, so what needs to be migrated or am i missing something?

Right now we try to use expo-file-system or AsyncStorage, both are async by design.
We'd need to either change SemiAsyncStorage or create an SyncStorage type where all methods are sync. including the preloadAsync.
Also create a customSyncStorage instead of customAsyncStorage, etc.
Also, use another file system plugin that supports the new architecture/JSI with only sync. methods, for example, react-native-mmkv.
So it's a bit of refactoring on the TS code actually, not native code, plus supporting react-native-mmkv.

Well, I am now about to use the feature flags feature, and I guess, this is not such an annoying issue?
The SemiAsync implementation is actually sync, besides the preload async. So if I write my own sync storage, I can follow the same API, and that function can be empty 🪄 💫
the only downside is that I stil have an unnecessaryly async "initAsync"

If any change gets planned, I'd make the posthog-rn.ts only have a storage implementation/declared, removing checks for "memory or semiAsyncStorage".  making it configurable by passing 'async' | 'memory' or 'custom' or some object, or whatever web might also do for custom providers.
Move "workarounds" to the storage.ts implementation i.e., the "removeItem" check for nulls here
Currently makes no sense that I need to call initAsync if I'm using a memory provider, would also not make sense for a sync provider, so allow for either initAsync or initSync to exist or make any "sync" setup part of the constructor when using sync providers, like memory, or JSI implementations like rn-mmkv
Also simply making the implementation of the setupAsync optional in the SemiAsyncStora type/class makes it perfectly suitable for both sync and async providers :)
Maybe getting out of topic, but I don't understand the existence/use of the methods getAllKeys and clear on the SemiAsyncStorage. There might be others, similarly the web cookieStore also implements it but there is no usage. Tech debt/legacy?

This can be done with couple small changes:

Make setupAsync optional on the "semiAsyncProvider" or support both Async and SemiAsync provider types.
Move "sync" logic in initAsync, (for memory and other sync providers to the constructor), guess the api-key and new Posthog initialization , an call it in the initAsync for async providers
Move "workarounds" ie this to the storage.ts implementation

@filipef101 would you like to submit a draft PR with your suggestion and we take it from there?
I am all in to guide/review your suggestions to make it better.
I'd just try to keep compatibility with previous versions if possible.

Yes, already started!

@marandaneto are you able to take it from #170 ? Cheers

@filipef101 can you check if https://github.com/PostHog/posthog-js-lite/pull/189/ helps with your use case?
It's not released yet though.

@marandaneto Step in the right direction, not there yet? Still will need to create a semiAsyncStorage with empty/immediate resolve preloadAsync to use mmkv as storage.
I feel that it is wrongly exposing a sync functionality, but in practice there will be a small delay before it is actually initialized, so for example using feature flags for conditional UI may "flicker" as first render a feature flag that we could expect to be cached is still undefined.
What happens if I try to log an event, or even access a feature flag, on first render?
Will the event sending be "delayed" until the _isInitialized is true? or will it fail if anything happens before _isInitialized becomes true?

I'd be okay with closing. The point still stands as a very likely use case of using PH feature flags for conditional rendering on first paint, currently there is atleast 1 first render where it will always be undefined.
My current solution is to just use pg as is, and wrap the useFeatureFlag, in it's own hook that caches the flag with mmkv, ie when undefined return from cache if exists. Ideally I would want to not use async storage as I
(I also use it to nicely get the payload if exists instead of only the boolean value as afaik theres no useFFPayload hook)

If you init PostHog with a custom customAsyncStorage (mmkv for example), _semiAsyncStorage is created but resolved async, indeed.
A call to isFeatureEnabled or similar will return undefined if not loaded yet, correct.
All calls to capture will be executed after the _initPromise is resolved if not yet, otherwise it's all sync calls (so just a bit of delay - probably a few ms if any).
You can call and await posthog.ready() on a loading state or something if you wanna be sure everything is loaded.
I get your point, ideally if a sync storage is provided flags should not have returned undefined nor you need to call ready() on the first render.

@filipef101 would be keen to hear your input as someone with knowledge of rn-mmkv - Does it make sense to try and offer it as a built in option via peer-dependencies like we do with AsyncStorage?
I ask as from the docs it seems that there is a bit more potential config desired with mmkv in terms of scoping and namespacing it so it might not make sense to offer as a default but rather support via the new config option. Thoughts?

Closing this issue as resolved since it's possible to pass custom storage, we can raise a new issue based on the answer here.
Thank you all.

@marandaneto Thanks for considering the request and adding support for my use case. And all the time taken considering my suggestions and feedback. Very much appreciated. Rockstar work 🤘💫

@filipef101 would be keen to hear your input as someone with knowledge of rn-mmkv - Does it make sense to try and offer it as a built in option via peer-dependencies like we do with AsyncStorage?
I ask as from the docs it seems that there is a bit more potential config desired with mmkv in terms of scoping and namespacing it so it might not make sense to offer as a default but rather support via the new config option. Thoughts?

Yeah think it would make sense, nowadays RN has no async storage by default so it may become more common that people want to use it
I would not default to it if async storage is not found. Unless it was clear for users that they needed to migrate from async to mmkv. (That is also why i didnt ask for mmkv support on ph side as that introduces a whole new problem :) )

@marandaneto / @benjackwhite  FYI a bunch of docs might need to be updated to use the new sync api ie:https://posthog.com/docs/feature-flags/installation?tab=React+Native

https://github.com/PostHog/posthog/pull/20854
https://github.com/PostHog/posthog.com/pull/8021
https://github.com/PostHog/posthog.com/pull/7902
We'll merge once its GA, let's give a few more days after the last beta with a few fixes.

Is this working?  If so, is there any documentation on how to configure postHog for MMKV?

Is this working? If so, is there any documentation on how to configure postHog for MMKV?

Good point, https://github.com/PostHog/posthog.com/pull/8232
Just install the MMKV lib and create your own customStorage.
Be aware that if you were using a previous storage form, the data won't be migrated so cached events, cached user id, etc won't be available.
I recommend calling identify right away after the new storage.


FMUv4pro : updates

This PR :

adds overcurrent sensing capability for both high-power and periphal rails
updates mapping to V1.3 RC02 (correct pull-up/down/float configuration)
enables the use of safety switch on V1.2 (workaround)

@davids5 Anything more to add?

@klopezal Have you seen the feedback from David?

@LorenzMeier Yes, we will discuss it today on Skype and conclude.

@davids5  PB6 on PIO has these options :

If possible, it would be great to have this workaround to solve the safety switch issue on V1.2 with very little overhead.

Understood!
If we do this we have to dedicate the pin forever.
Given V1.2 requires the the BYPASS_REG rework.
What is the the level of effort of adding the 1/8 watt pull down on the large pads at the connector?
Please keep in mind, that the BYPASS_REG rework alone opens the board to vibration related failures.  Therefore it can not be reliably flown, unless track level repair is done but a certified rework house. The same would hold true for the adding the resistor. The units would be fine for bench testing.
@LorenzMeier  - please advise.

@klopezal - this is a better link for track level repair

There is no ground on the pads on that side of the board, so as you say adding the resistor would be uneffective unless the repair is reliable in terms of vibration level. I suggest we drop the workaround then.

@klopezal
I am assuming by "workaround" you are refering the the SW one?
If that is the case please revert 9528ae2 - FMUv4pro : workaround for safety switch and we will merge this.

@davids5 Done!

@klopezal Thank you!


Non developer readme contribution

I have written a clear, easy-to-comprehend introduction for Underscore.js. I believe this introduction, free of complex technical terms, will swiftly and thoroughly inform anyone about the use-cases, merit, and advantages, including the celebrated features, of Underscore.js. Seasoned developers, new programmers, and even nontechnical visitors will benefit from the clear language, exposing Underscore.js to a broader range of users.

I don't see this as a big improvement over the existing wording, but thanks.


Payload not arriving in chrome

Hi
It seems the payload arrives as null in event.data on the client side after a push message has been recieved.
Testing with the following code:
require __DIR__ . '/vendor/autoload.php';

use Minishlink\WebPush\WebPush;
use Minishlink\WebPush\Subscription;

$auth = [
    'VAPID' => [
        'subject' => 'htts://testpush.test/',
        'publicKey' => 'BBFwt4l1ZvIoCkH2Cp9DSQKGN6MUQ5mFXrT3OLKNsoqSTweloz87hZtIA64Zgx2zROgxPWN1l61q8ezM0QkD2Dg',
        'privateKey' => 'XXXX',
    ],
];

$notifications = [
    [
        'subscription' => Subscription::create([
            'endpoint' => 'https://fcm.googleapis.com/fcm/send/f1azG0YpefY:APA91bEgPUCksrDdHc3vpd8JZUsiLnf6sphqgw8TdyPVyTMaviZGvBY76RPJ2zFmMFpvhxoL3hvbvMSJ_O8Ct5nqKmDYozsZh-IU-gm2DWqeTVRRgW9k6Hq58vxnYi75RehmdXbEr_yb', // Chrome
            'contentEncoding' => 'aes128gcm',
            'publicKey' => 'BBFwt4l1ZvIoCkH2Cp9DSQKGN6MUQ5mFXrT3OLKNsoqSTweloz87hZtIA64Zgx2zROgxPWN1l61q8ezM0QkD2Dg',
            'privateKey' => 'XXXX',
            'authToken' => '',
            'payload' => '{"msg":"Hello World!"}' // optional (defaults null),
        ]),
    ],
];

$webPush = new WebPush($auth);

// send multiple notifications with payload
foreach ($notifications as $notification) {
    $webPush->queueNotification(
        $notification['subscription'],
        $notification['payload'] // optional (defaults null)
    );
}

/**
 * Check sent results
 * @var MessageSentReport $report
 */
foreach ($webPush->flush() as $report) {
    $endpoint = $report->getRequest()->getUri()->__toString();

    if ($report->isSuccess()) {
        echo "[v] Message sent successfully for subscription {$endpoint}.";
    } else {
        echo "[x] Message failed to sent for subscription {$endpoint}: {$report->getReason()}";
    }
}

The message is successfully sent, and notification appears on the client, however the event.data is always empty.  Couldf you please help with the above?
Musaffar

Same issue here.

Hey, above you have a bug,
your payload should be inside your notification array, not your subscription object

$notifications = [
    [
        'subscription' => Subscription::create([
            'endpoint' => 'https://fcm.googleapis.com/fcm/send/f1azG0YpefY:APA91bEgPUCksrDdHc3vpd8JZUsiLnf6sphqgw8TdyPVyTMaviZGvBY76RPJ2zFmMFpvhxoL3hvbvMSJ_O8Ct5nqKmDYozsZh-IU-gm2DWqeTVRRgW9k6Hq58vxnYi75RehmdXbEr_yb', // Chrome
            'contentEncoding' => 'aes128gcm',
            'publicKey' => 'BBFwt4l1ZvIoCkH2Cp9DSQKGN6MUQ5mFXrT3OLKNsoqSTweloz87hZtIA64Zgx2zROgxPWN1l61q8ezM0QkD2Dg',
            'privateKey' => 'XXXX',
            'authToken' => '',
        ]),
        'payload' => '{"msg":"Hello World!"}' // optional (defaults null),
    ],
];

Any solution to this problem? I spent a while trying to make it work. It's not working, "data" field is null

Any solution to this problem? I spent a while trying to make it work. It's not working, "data" field is null

@sadektouati Did you find a solution or did you give up?

@sadektouati Did you find a solution or did you give up?

I sort of gave up.  How about you

@sadektouati Did you find a solution or did you give up?

I sort of gave up. How about you

I am not much further, but I will update / notify you if it works for me.

@richard-llmnn Thank you very much

@sadektouati It works on my localhost :+1: after a bit of try and error.
Please make sure that you have the publicKey (p265dh), the endpoint and the authToken (auth).
My backend send notification code looks like this:
            $subscription = [
                'endpoint' => $credential->getEndpoint(),
                'publicKey' => $credential->getPublicKey(),
                'authToken' => $credential->getAuthtoken(),
            ];

            $payload = [
                "title" => "Hallo Push-Welt!",
                "body" => "Hi! Dies ist eine Testnachricht!",
                "badge" => "/assets/img/test1.svg",
                "icon" => "/assets/img/test2.svg",
                "image" => "https://unterricht.cloud/wp-content/themes/bueffel/assets/img/unterricht-logo.png",
                "tag" => "test",
                "data" => [
                    "show1" => "/test1",
                    "show2" => "/test2",
                    "default" => "/test3"
                ],
            ];

            $message = [
                'subscription' => Subscription::create($subscription),
                'payload' => json_encode($payload),
            ];
            // $this->webpushConnection is the WebPush object (Minishlink\WebPush\WebPush)
            $this->webpushConnection->queueNotification(
                $message['subscription'],
                $message['payload']
            );

        foreach ($this->webpushConnection->flush() as $report) {

        }

@richard-llmnn I'm happy to hear that.
Can you please help tell me what goes where ?
Here's the object I get from the subscription:
{ "keys":      {"auth": "string", "p256dh": "string"}, "endpoint": "string", "expirationTime": null }
`$subscription = [
            'endpoint' => $credential->getEndpoint(),

            'publicKey' => $credential->getPublicKey(),

            'authToken' => $credential->getAuthtoken(),

        ];

`

@sadektouati
On the client you get the subscription object. In my project I send the endpoint, keys.auth and keys.p265d to my backend api.
The backend saves the data to a mysql database. The structrue looks like:
Webpush_ID | endpoint | publicKey | authToken
1 | https://fcm.googleapis.com/fcm/sen.... | BMrfFtMtL9IWl9vchDbbbYzJlbQwpl... | pbs9Y6r5TscHC64Ce9... // example data
So, my backend saves the data in the database as follows:

endpoint (from client) -> DB endpoint
keys.p265d (from client) -> DB publicKey
keys.auth (from client) -> DB authToken

Now if you want to send a message to the users that has subscripted to your webpush you have to do the following:

Fetch the data from the database (I use for this symfony/doctrine orm, so all rows are saved in a own object. My name for the row object is $credential and with the getter methods I get the data for the row.)
use the code from my comment: https://github.com/web-push-libs/web-push-php/issues/334#issuecomment-996893924

Some good tutorials are:

https://www.bjoern.info/2020/05/web-push-notifications-mit-php-und-js/ (German)
https://www.attheminute.com/article/sending-a-web-push-notification-tutorial (English)
https://felixgerschau.com/web-push-notifications-tutorial/ (English)

@richard-llmnn Thank you very much, now it's working.
My problem was that intead of this:
Subscription::create([             'endpoint' => $endpoint, 'publicKey' => $p256dh, 'authToken' => $keys_auth, 'contentEncoding' => 'aesgcm',         ]),
I was doing this:
Subscription::create([             'endpoint' => $endpoint, $p256dh, $keys_auth, 'contentEncoding' => 'aesgcm',         ]),
I'll open a new issue for this.
Make sure you update the subscription on your server each time it's changed on the client.
I did something similar to this:
https://medium.com/@madridserginho/how-to-handle-webpush-api-pushsubscriptionchange-event-in-modern-browsers-6e47840d756f

me too, I cannot send push.. I use Lumen
            'title' => 'test',
            'body' => 'Messaggio di test',
            'vibrate' => [100, 50, 100],
            'silent' => false,
        ];

        $notifications = Subscription::all()->map(function($item) use ($payload) {
            $subsData = json_decode($item->subscription, true);

            return [
                'subscription' => Subs::create($subsData),
                'payload' => json_encode($payload)
            ];
        })->toArray();

        $auth = Config::get('vapid');
        $webPush = new WebPush($auth);

        // send multiple notifications with payload
        foreach ($notifications as $n) {
            $webPush->queueNotification(
                $n['subscription'],
                $n['payload'] // optional (defaults null)
            );
        }

        $results = [];

        foreach ($webPush->flush() as $report) {
//            $endpoint = $report->getRequest()->getUri()->__toString();

            if (!$report->isSuccess()) {
                $results[] = $report;
            }
        }

where $auth = Config::get('vapid'); returns something like this
[
    'VAPID' => [
        'subject' => 'myemail'
        'publicKey' => '<publicKey>'
        'privateKey' => '<secretKey>'
    ],
]

@falco442  in my case it was a matter of making a subscription exactly as
Subscription::create([ 'endpoint' => <endpoint>, 'publicKey' => <p256d>, 'authToken' => <keys_auth>, 'contentEncoding' => 'aesgcm', ]),
the endpoint, publicKey, authToken are the keys you received in the subscription object on the client.

me too, I cannot send push.. Even if all reports are successful, I cannot see a push notification, neither in the browser on my laptop, nor in the mobile phone (Android). I use Lumen
        $payload = [
            'title' => 'test',
            'body' => 'Messaggio di test',
            'vibrate' => [100, 50, 100],
            'silent' => false,
        ];

        $notifications = Subscription::all()->map(function($item) use ($payload) {
            $subsData = json_decode($item->subscription, true);
            return [
                'subscription' => Subs::create($subsData),
                'payload' => json_encode($payload)
            ];
        })->toArray();

        $auth = Config::get('vapid');
        $webPush = new WebPush($auth);

        // send multiple notifications with payload
        foreach ($notifications as $n) {
            $webPush->queueNotification(
                $n['subscription'],
                $n['payload'] // optional (defaults null)
            );
        }

        $results = [];

        foreach ($webPush->flush() as $report) {
//            $endpoint = $report->getRequest()->getUri()->__toString();

            if (!$report->isSuccess()) {
                $results[] = $report;
            }
        }

where $auth = Config::get('vapid'); returns something like this
[
    'VAPID' => [
        'subject' => 'myemail'
        'publicKey' => '<publicKey>'
        'privateKey' => '<secretKey>'
    ],
]

and $item->subscription is already a json of the form
{
   "endpoint":"endpointUrl",
   "expirationTime":null,
   "keys":{
      "p256dh":"pdkey",
      "auth":"authkey"
   }
}

Do you get it working?

@richard-llmnn I think the problem is in your
$subsData = json_decode($item->subscription, true);
it should be :
$subsData = [ 'endpoint' => $endpoint, 'publicKey' => $p256dh, 'authToken' => $keys_auth, 'contentEncoding' => 'aesgcm', ];
json_decode($item->subscription, true) would give you [ 'endpoint' => $endpoint, 'keys' => ['p256dh' => $p256dh, 'auth' => $keys_auth]];
I hope this helps you

You may have to modify the service worker JS which is listening for push event.
self.addEventListener('push', function (event) {
    if (!(self.Notification && self.Notification.permission === 'granted')) {
        return;
    }

    const sendNotification = body => {
        // you could refresh a notification badge here with postMessage API
        const title = "Web Push example";

        return self.registration.showNotification(title, {
            body,
        });
    };

   // Notice this part carefully. event.waitUntil is only getting called when event.data is non-empty.
    if (event.data) {
        console.log( event );
        const message = event.data.text();
        event.waitUntil(sendNotification(message));
    }
});

Using this script started showing the push notifications.

Hello,
For me it was one of this key ('endpoint', 'keys', 'p256dh', 'auth', 'contentEncoding', 'publicKey', 'authToken')_ which was badly written by me, the optional keys in the table are not verified if they are well formatted, to get payload you need to have endpoint, publicKey and authToken OR endpoint, keys with ph256dh and auth. hope it save someone times XD


(chore) Update the default ENV variables

Include a default SECRET_KEY_BASE that works out of the box for development purposes
Update the Docker ENV with those found in .env, presumably the 2 files have fallen out of date so there are variables like NEW_INGEST and SUBMIT_INVOICES that aren't present.
Add a comment around the Google variables to make it clear that they are not required, and that their presence or omission changes the applications behaviour for signing in. Suggest that it is safe to use the default, and might actually remove some setup headaches from getting the right Google account prepared for use.

Did we decide that AWS keys should no longer be necessary?

@jcoglan I've since learnt from Leeky that AWS S3 is still very much used, Azure is used for files sent to the "data warehouse", S3 is still used for submissions.

It looks to still be configured as a local storage device https://github.com/dxw/DataSubmissionServiceAPI/blob/develop/config/storage.yml#L7. Presumably we have to keep S3 around to have similar functionality in development.
I can also see we have something that looks to be ingesting files from S3 in all environments? https://github.com/dxw/DataSubmissionServiceAPI/blob/6353ec62c037f60ed0ff1e1ffc9d3862afc390ed/lib/vcap_parser.rb#L14


Check to see if package installed should take into account user

I ran into a funny problem where npm always tried to install the package. After a bit of troubleshooting, I found out it was because the npm list command didn't run as the same user as the npm install command. This breaks when you have a prefix set.
For example, if I run "npm install -global " as the vagrant user, and my npmrc contains a prefix of ~/npm, it'll put the package there.
However on the next converge, it'll run "npm list -global -json" as the root user, so it won't find the package.
The resource.user param should be passed into the shell that executes npm list...

Needs a review to determine if this report is still an issue. Also review the suggest fix.  A fix may already have been merged.

Adding user to the command without setting the path gets an error complaining about root owned files in the cache.  I'm not able to reproduce an issue in a meaningful way. Closing due to age and lack of a way to reproduce.
@jfbibeau thank you for the report.


autosave closes autocomplete menu and overwrites the status message

Is there a way to prevent autosave to close the autocomplete menu and overwriting the status bar message?

Does it not do this when you are using other autocomplete packages? I can't see anything that would cause this in the plugin's code, but I don't have enough experience with sublime text scripting to really know why it could happen.

Yes other autocomplete packages close it too :) really enoying

Okay. I agree that's awful, but it seems to be an ST bug, not something I can help.


Automatically rerun tests after updating snapshots.

Environment

node -v: [v9.0.0]

npm -v: [5.5.1], yarn v1.3.2

npm ls react-scripts (if you haven’t ejected): [fill]

Operating system<EMAIL_ADDRESS>

Steps to Reproduce
[Pre-cond]: all tests passing.

Change the code so that there is an expected snapshot failing.
Output shows correct information that there is a snapshot failing and the editor offers replacing the snapshots with the new ones.
Confirm by clicking on Replace them in the Info box.
The info box shows Updated Snapshots. It will show in your next test run..
Close the Info box by clicking on Close button.
The OUTPUT still shows the test failure.
Perform Save on the file that caused the snapshot failure.

Expected Behavior

The relevant tests will re-run and the relevant errors will be cleared in Problems tab.

Actual Behavior

Instead, the OUTPUT sometimes shows: No tests found related to files changed since last commit. Press a to run all tests, or run Jest with --watchAll. In such a case the PROBLEMS tab still shows failing Snapshot test.

It would be nice to get an Option (e.g. via CMD-SHIFT-P) to force re-run all the tests. Otherwise it is hard to clean up the PROBLEMS tab and it is annoying. I see there is an enhancement proposed for just doing this, but this is still not optimal solution for a nice snapshot-testing flow.
A natural behaviour with snapshot testing is to re-run the relevant tests immediately after replacing snapshots. The Updated Snapshots. It will show in your next test run. confirmation is redundant and off-the flow. Also doing 'dummy' save on the file that caused the snapshot failure, hopping to trigger a test rerun is not natural (and it does not always work).
Reseting Jest Runner (Stop/Start) will clear the errors in the PROBLEMS tab, but it is also not how one would like to go through the process.

I am working on pull-request for that. Unfortunately, the way the jest process management is done is a bit hard to follow for me. As soon when start playing with starting/restarting/stopping jest process and you want to fill in control some things needs to be simplified/corrected. Especially, making startProcess killing the currently running process when restarting is just causing confusion and the way this.forcedClose is currently used is asking for trouble. For instance, when the handler for debuggerProcessExit is invoked for the previously killed process but this.forceClose is already cleared for the more recent process that was just started. As a result we get redundant closeJest followed by startWatchMode. Using startWatchMode inside of the close handler is also making reasoning harder. There should be only one method used to start the process and this should be startProcess. There is more to it, but instead of enumerating problems I will create first a pull-request for simplifying the process management and then I will follow with two pull-requests for restarting jest after updating snapshot and I will also add pull-request for #176 as this is then no-brainer. I still need to update the tests a bit to reflect the changes.
In the meantime, you may like to check:
https://github.com/marcinczenko/vscode-jest/tree/clean-up-jest-process-management
and
https://github.com/marcinczenko/vscode-jest/tree/restart-jest-on-snapshot-update
and let me know if this ok.

Is it possible to update the snapshots and run all tests like you're hoping to using the interactive watch mode @marcinczenko? I've been experimenting with sending commands to Jest over stdin. It'd add a tiny bit of overhead, but it'd simplify the process management quite a bit.

Related: There's also discussion in Jest around having a JS API for running a test, which could mean that some of this process faffing could be simplified: https://github.com/facebook/jest/issues/5048#issuecomment-350677931

@marcinczenko I think you are right that the process management can definitely be simplified and streamlined:

closeJest
this method mainly calls jestProcess.closeProcess() in jest-editor-support to work around the fact that it doesn't clean up its internal state (debugprocess) when the process exited thus prevented the start() to be called again. If you fix the jest-editor-support then we don't need to call the closeJest() at all because the process is obviously closing if debuggerProcessExit event is invoked...

forceClose
this is pretty hacky I agree, so let's not piling more stuff on it... I think a better approach will be to eliminate forceClose, maxRestart altogether and consolidate the jest process management logic into a separate class that does something more intuitive like this (pseudo code):

class TaskManager {

    shouldTakeRequest: boolean /* default false */
    maxTaskCount: number /* control max retry */
    taskCount: number
    jestProcess: Runner

    constructor(maxTaskCount = 3...){...}

    // should be called in startProcess()
    start() { this.shouldTakeRequest = true; this.taskCount = 0; this.jestProcess = Runner(...); }

    // should be called in stopProcess()
    stop() { this.shouldTakeRequest =false; this.jestProcess.closeProcess() }

   // replace all other jest run with this
    runJest(watchMode:boolean){
        if(!this.shouldTakeRequest || this.taskCount > this.maxTaskCount) return;
        this.taskCount += 1;
        this._execute(watchMode);
   }
  // could introduce delay if needed
   _execute(watchMode) { Promise.resolve(() => this.jestProcess.start(watchMode)); }
}

invoke startWatchMode in debuggerProcessExit:
This is so we can 1) start watch-mode after the full test-run 2) auto-restart should the process exit unexpected. Nothing wrong with that, in short, the idea is there should always be a jest process running unless explicitly stopped. Once we have done the refactoring mentioned above, it should be a lot easier to understand/reason:

this.jestProcess.on('debuggerProcessExit', () => {
    this.channel.appendLine('Closed Jest')

    // we should always have a jest running, if possible
     this.taskManager.runJest(true /* watchMode */)
}

Thanks for the input - I will look into it a bit later - I can only be active late in the late evening on it :(.
Just a quick reply to @connectdotz. Introducing a proper separate abstraction is definitely what should be done here. So thanks for triggering that! I just took a small step so that I understand myself how it works right now.
We have to remember that Jest is not always playing very nice - e.g. it forwards both onExit and onClose events to debuggerProcessExit. So when the full test run finishes by itself, we get two debuggerProcessExit events, and we have to ignore one of them. Unfortunately, this is not happening always - in my current implementation, when I stop Jest explicitly by calling stopProcess only one event occurs. I think forcedClose was also in some way helping out to handle that. To handle that with a proper abstraction, I would propose to have two abstractions: one say JestTask to take care for initialisation and proper cleanup of the Jest process and the second TaskManager that will provide the interface for starting, stopping, restarting of JestTasks.
We also may want to think about naming - isn't process closer to reality? At least we should agree to use one term to describe this Jest process thing? Also In your proposal I see maxTaskCount and taskCount. It may give an impression that we run multiple tasks (or processes) which is not the case. We only want one to be active at the given moment (maybe with exception of updating snapshots - but I will comment on that later), so I would keep maxRetries in the naming somehow to make that clear to the reader.
I would suggest to separate the two issues: cleaning up the process management, and then doing other stuff like rerunning all tests after updating snapshots.
If you agree, I can separate the two issues. As I think I have pretty good understanding of how process work I can work on introducing the two abstractions for process management. Just let me know :).

It may give an impression that we run multiple tasks (or processes) which is not the case.

We're only running one for now. As we look at getting test results in the editor quicker we'll probably want another Jest process. That'd help test:

the last saved file without changing the Jest test scheduler (#119)
unsaved document content (in a language service)

I would suggest to separate the two issues: cleaning up the process management, and then doing other stuff like rerunning all tests after updating snapshots.

I'm all for an issue per symptom. :+1:

I just took a small step so that I understand myself how it works right now.

👍

We have to remember that Jest is not always playing very nice - e.g. it forwards both onExit and onClose events to debuggerProcessExit.

This seems like a bug on the jest-editor-support, onClose means stdin closed, it should not be confused with onExit... you can fix it either with a backward compatible solution: passing a new flag indicating which signal triggered the debuggerProcessExit, or a cleaner one: make 2 distingue methods.

I would propose to have two abstractions: one say JestTask to take care for initialisation and proper cleanup of the Jest process and the second TaskManager that will provide the interface for starting, stopping, restarting of JestTasks.

hmmm... I am not quite sure what you have in mind for JestTask... I thought we already have one, it's called Runner in jest-editor-support. I don't think vscode-jest should worry about the actual node process state, it should be managed from where it was spawned, i.e. the Runner. I suggest starting from there and see what is missing... (for example, it should reset the debugProcess in onExit()...)
regarding the naming:
@marcinczenko your naming suggestion makes sense to me for a single jest process environment. But as @seanpoulter suggested, if we ever going to move toward multiple jest runs, then maybe a more generic naming scheme will be easier to transition to. Either way, once the TaskManager refactoring is done, it should be much easier to introduce Runner pool/queue for multi-jest runs.

@connectdotz Perhaps I am missing something, but this looks to me to be a conscious choice:
https://github.com/facebook/jest/blob/3ea2e106635e908579630b17f84a33602a891b69/packages/jest-editor-support/src/Runner.js#L87:
this.debugprocess.on('exit', () => {
  this.emit('debuggerProcessExit');
});

https://github.com/facebook/jest/blob/3ea2e106635e908579630b17f84a33602a891b69/packages/jest-editor-support/src/Runner.js#L95:
this.debugprocess.on('close', () => {
  this.emit('debuggerProcessExit');
});

I thought we already have one, it's called Runner in jest-editor-support.

Yes, that's exactly the reason - it is external dependency that demands its own abstraction on the plugin side.

@marcinczenko your naming suggestion makes sense to me for a single jest process environment.

Hmm...was your proposal already taking into account multiple tasks? Then sorry. You were still referring to maxRuns and this is clearly not for managing multiple tasks but to shot the whole thing down when it keeps crashing. This is why I though you are thinking about running just one process for the moment.
Anyway - I have created a separate issue for this (#189), leaving this thread to the comments only about retuning tests after updating snapshots.
I do care to have a more stable plugin, so if you guys need some help please let me know. If you prefer to work on the TaskManager abstractions yourself, it is completely fine with me. I have plenty of work and I would prefer to avoid working on something that you do not value at the moment.

@seanpoulter, @orta So coming back to rerunning tests after updating snapshots. Does it make sense to create the pull request for the temporary solution I have now. I am using it now, so I kind of achieved what I wanted. It adds a new config option to rerun the tests after snapshot update which is false by default (which means it does not touch the current behaviour in any way). I also refactored the process management a bit so this would have to include that as well.
We can work on a better approach in the mean time, but maybe this is already useful to some other people. What's your idea?

was your proposal already taking into account multiple tasks?

no, the current implementation is definitely for the single process, that's why I am agreeing with your naming suggestion under this assumption.

@seanpoulter, @orta So coming back to rerunning tests after updating snapshots. Does it make sense to create the pull request for the temporary solution I have now?

Sure 👍

@marcinczenko now I have a bit more time to reply: I sensed you are a bit frustrated... please don't, we are all trying to do the right thing to help our favor tool ;-). Not sure if this is the best place to comment these kind of things, but I figure it's better to address them than not...

I would prefer to avoid working on something that you do not value at the moment.

ouch, if I made you feel that way, it is my bad. It's great that you feel the code should be improved for simplicity and that's why we love fresh perspectives! I am sure there are many ways to refactor the process and it's hard to fully understand each other's idea via these comments... I just want to share the lesson we learned and balance short-term hack vs long-term fix...

Perhaps I am missing something, but this looks to me to be a conscious choice

Just because the code is out there, doesn't mean its right or unchangeable ;-) when uncertain, I will usually do the backward compatible change, so whoever needs it can get the benefit without breaking others.

Yes, that's exactly the reason - it is external dependency that demands its own abstraction on the plugin side.

I guess it all depends on what this local abstraction do... If it makes more sense to happen in the external package, then we should fix it there (better encapsulation too) instead of hacking on our side, which is exactly what led us to the process management issue now... just trying to learn from our mistake.
regarding restarting the process after snapshot update: I see you are trying to call stopProcess() followed immediately by startProcess(). Given stopProcess() will not "complete" right away (like an async operation), the startProcess() should fail to keep the "single-process" mode true. Will it be better to wait after the process is truly stopped before invoking startProcess()? What do you think if we use a promise (or something like that), resolved by debuggerProcessExit, to trigger the startProcess()...? I could be wrong but I think you might not even need to touch the forcedClose or any other part of the system if we can truly serialize the stop/start sequence...

@connectdotz I moved discussion on this to #189. I will replay to your comments there.


When will the  be open source?

When will the  be open source?

please refer to https://github.com/OpenGVLab/InternVideo#model-zoo for downloading.


Reduce metric name text size

Reduce metric name text size to differentiate them from meter name.

Internal previews

📄 File
🔗 Preview link

docs/core/diagnostics/built-in-metrics-aspnetcore.md
ASP.NET Core metrics

@noahfalk What do you think?
@gewarren Is this an ok thing to do?

We have MD001 rule disabled, so markdownlint is happy with this. But another idea is to create a separate file for each namespace (?) and have those as subnodes in the TOC.

We have MD001 rule disabled, so markdownlint is happy with this. But another idea is to create a separate file for each namespace (?) and have those as subnodes in the TOC.

We might split up by meter in the future. For now, each general area is in its own file.


Design doc fixups

This continues the work in MCUB-67. The substantial change is deleting the 'pending' / 'confirmed' state space in favor of one defined in terms of 'swap types'.

I fixed some issues with the commit log in the last patch in v2. No changes to the patches themselves.

v3 posted accounting for review comments from @d3zd3z. Diff from v2:
diff --git a/doc/design.txt b/doc/design.txt
index 8894304..27facc4 100644
--- a/doc/design.txt
+++ b/doc/design.txt
@@ -218,8 +218,9 @@ image trailer. An image trailer has the following structure:
     |                       MAGIC (16 octets)                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

-The offset immediately following such a record represents the start of the next
-flash area.
+Each image trailer is placed at the very end of its flash area. For example, if
+the following flash area begins at offset 'n', the MAGIC field of the image
+trailer starts at offset 'n-16', the 'Image OK' byte is at offset 'n-24', etc.

 Note: "min-write-size" is a property of the flash hardware.  If the hardware
 allows individual bytes to be written at arbitrary addresses, then
@@ -261,9 +262,10 @@ confirmed as good by the user (0x01=confirmed; 0xff=not confirmed).

 *** IMAGE TRAILERS

-At startup, the boot loader determines the boot swap type by inspecting the
-image trailers.  When using the term "image trailers" what is meant is the
-aggregate information provided by both image slot's trailers.
+At startup, mcuboot determines the boot swap type by inspecting the image
+trailers. If a previous boot was interrupted, some of the contents of the image
+trailers may be in the swap flash area as well, as described in more detail
+below in IMAGE SWAPPING and RESET RECOVERY.

 The image trailers records are structured around the limitations imposed by flash
 hardware.  As a consequence, they do not have a very intuitive design, and it

@utzig are you saying I should squash all of the design doc changes into one commit? I made the commits separate logical changes on purpose so they'd be easier to review.


Ensure exceptions raised from unsuccessful runs show up properly when using email alerts

A user has email alerts set up, and the exception that gets raised when tests fail is not very helpful as it all appears in one line. We should ensure email alerts show up properly.

This issue is still relevant.
Test env:
DBT: 1.5.1
Cosmos: 1.2.0
Airflow: 2.5.1

This issue is still relevant.
Test env:
DBT: 1.5.1
Cosmos: 1.2.0
Airflow: 2.5.1

This is a relevant feature, @saikotcharlakota would you like to contribute to improving this?

I can give it a try.


STORM-3100 : Introducing CustomIndexArray to speedup HashMap lookups

Added Unit Tests
Ran below perf numbers on my mid 2015 macbook pro for single worker.

Ran these perf topos to check perf impact:
1) ConstSpoutIdBoltNullBoltTopo With 1 Acker
Before:  Throughput= 1,067,128 /sec .  Latency = 1.038 ms
After:  Throughput= 1,294,511 /sec .  Latency = 1.037 ms

Throughput improved ~21%.  No signifiant change in latency.

2) ConstSpoutIdBoltNullBoltTopo With 0 Acker
Before:  Throughput= 4,389,133
After:  Throughput= 4,748,744 /sec

Throughput improved ~8%.

3) TVL : --rate 350000 --spouts 1 --splitters 2 --counters 2 -c topology.max.spout.pending=500 -c topology.acker.executors=2  -c topology.disable.loadaware.messaging=true
No significant change observed in Throughput or Latency.

Looks like tester_bolt_metrics.py under storm-core is failing. I see that it can be run via mvn clojure:test under storm-core. But unable to figure out what really going wrong. Any help would be appreciated. thanks.

It looks like Zk issue but not 100% sure. If it is happening intermittently we might be fine. Could you setup Travis to your fork and run build couple of times?

Sorry for not being able to address the comments sooner. Have been traveling and should be able to get back to this soon after jul 12 th.

@roshannaik
https://travis-ci.org/apache/storm/jobs/403972342
https://travis-ci.org/apache/storm/jobs/403972347
https://travis-ci.org/apache/storm/jobs/403972348
https://travis-ci.org/apache/storm/jobs/403972349
Travis CI build is failing and failures look like related to the changeset. Could you check above build result and track?

Looks like the build still fails and relevant to this patch.

Spent sometime trying to triage this failure but unable to figure out the cause. i know the issue has to do with this patch as it passes w/o this patch.  I think it will take me some more time to get to the bottom of this.  I did notice another (kind of significant) performance issue is simple to address. Given that this is a relatively minor optimization, I am planning to provide a fix for that one first, and then revert back to this.


Test suite failed to run

Hi there!
I have this problem after using react-app-rewired near CRA.
FAIL  src/App.test.js
● Test suite failed to run
SyntaxError: Invalid regular expression: /[\\]node_modules[\\].+.(js|jsx|mjs)$/: Unterminated character class
at new RegExp ()
  at shouldTransform (node_modules/jest-runner/node_modules/jest-runtime/build/script_transformer.js:603:9)

Test Suites: 1 failed, 1 total
Tests:       0 total
Snapshots:   0 total
Time:        1.347s
Ran all test suites related to changed files.

thank you in advance

I finally found my answer.
You could use the below code in your config-overrides.js file. Please notice that you do not need to install jest-cli.
module.exports = {
  webpack : function override(config, env) {
    ...

    return config;
  },
  jest: (config) => {
    config.transformIgnorePatterns = ["node_modules"];
    return config;
  }
};


ci(vitest): use name field of package.json for name field of vitest config consistently

In vite.config.ts, we use package name like (we use test name as react-query in @tanstack/react-query)
And I checked resolvePackageJson: true in global tsconfig, so I update viteConfig.test.name as packageJson.name. so we can manage test name like packageJson.name as one consistently

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

Comparison is base (62704ce) 41.78% compared to head (cd36017) 41.78%.
Report is 3 commits behind head on main.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main    #6787   +/-   ##
=======================================
  Coverage   41.78%   41.78%
=======================================
  Files         178      178
  Lines        7017     7017
  Branches     1421     1421
=======================================
  Hits         2932     2932
  Misses       3722     3722
  Partials      363      363

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


Table constraints

Hi,
is it possible to use table constraints on table creation?
Or do i have to use a raw sql query?

For now you have to use raw sql


feat: Update PAS Egress Vector Explainer for nullability

Includes updates to language and examples

@salmanmlk ready for re-review

@salmanmlk ready for re-review

Thanks! LGTM


Deprecated: filterList must now be provided under each column option.

I am attempting to use the filterList option but I am getting an error:
Deprecated: filterList must now be provided under each column option. see https://github.com/gregnb/mui-datatables/tree/master/examples/serverside-options example
However I am following the above example exactly. The issue is also effecting the example linked. codesandbox below.
Expected Behavior

list should be filtered by my filterList on default
Current Behavior

List is not being filtered
Steps to Reproduce (for bugs)

https://codesandbox.io/s/32znywpzk5

Sorry please look at this example: https://github.com/gregnb/mui-datatables/blob/master/examples/column-filters/index.js
I will clean that warning up

Thank you @gregnb! That worked perfectly.


Using Examples folder is not easy to follow

https://github.com/Urban-Analytics-Technology-Platform/od2net/blob/main/docs/tutorial_examples.md tutorial is bit confusing and python scripts are actually expecting a lot of harness to actually work.

I think it might be useful to create another image using builder stage of Dockerfile which would serve as examples "compiler"
README.md in examples folder would be easier to follow than a link to url to docs hidden in echo.sh
Simple Makefile with targets like build_docker / build_examples  / test would be very helpful for newcomers to fast start
using symlink utils.py is not great, this folder should have a python pkg structure so proper importing would work.
autoformat and lint code with ruff.

Thanks for the detailed feedback and list of suggestions! All of these sound great to me.

I think it might be useful to create another image using builder stage of Dockerfile which would serve as examples "compiler"

Maybe this could then replace or simplify #76? Including all the external tools that're useful for generating inputs in one place sounds helpful for sure.

using symlink utils.py is not great, this folder should have a python pkg structure so proper importing would work.

I tried setting this up before, but I got stuck because the order of directories is inverted. Rather than the python main files living in dir1 and the common library also living in dir1 (or nested beneath), we've got examples in a bunch of subdirectories. I didn't spend that much time searching around to find the right structure, though. Do you know what's appropriate here?

+1 to simplifying things. Also an ask for making it easy for people to contribute from other languages, e.g. R or Julia, with a nod to upcoming SDSL conference next week: https://spatial-data-science.github.io/2024/


add some badges to the README file

Description
add some badges to the top of readme.md file, since the badges will be colorful and more attractive at the top of README.md file than the text the users will like it and after linking the badges it will also help them to navigate to different sections/ webpages like PRs, issues, contributors, etc.
Describe the solution you'd like

I will add some badges at the top and also will add links related to them so that the README.md file will look more interactive and awesome.
Work under/as

[x] LGMSOC
[ ] Contributor

@Creatoon Should I work on this??

would love to contribute to this under LGMSOC

Irrelevant, as GitHub takes care of these features already.


Quarkus Operator SDK version is outdated

Feature Request
The Quarkus Operator SDK template generating the project stub seems to be outdated:
<quarkus-sdk.version>3.0.7</quarkus-sdk.version>
<quarkus.version>2.7.5.Final</quarkus.version>

while latest is:
<quarkus-sdk.version>4.0.1</quarkus-sdk.version>
<quarkus.version>2.12.2.Final</quarkus.version>

cc. @metacosm

Let me take a look into it

Raised PR on java-operator-pkugins https://github.com/operator-framework/java-operator-plugins/pull/102

Thanks @laxmikantbpandhare for redirecting this to the correct project!

This issue raised here is correct. operator-sdk release needs to happen for getting those changes available.

Modified milestone to v1.24.0

Pointed to most latest now:
    <quarkus-sdk.version>4.0.3</quarkus-sdk.version>
    <quarkus.version>2.13.1.Final</quarkus.version>

1.25 SDK release will take care of this.

PR for the same: https://github.com/operator-framework/operator-sdk/pull/6044

Note that 4.0.3 is functionally equivalent to 4.0.2, this was just needed to publish more artifacts to better integrate with the Quarkus ecosystem.

https://github.com/operator-framework/java-operator-plugins/blob/main/pkg/quarkus/v1alpha/scaffolds/internal/templates/pomxml.go#L54-L61


Add "expand all" button to model viewers

We have a collapse all button, but no expand all button.

I'm not sure if this is a good idea, at least for right now.  There's not much of a precedence in Eclipse (like in Package Explorer) to open a tree entirely with a single click of the button.  If the tree is large, this is rarely a good idea for the user.  But the bigger issue is memory.  In my experience, there have been several models that will simply throw you into an Out Of Memory error when this is attempted.  At a minimum, I think we should wait until we have some type of weak reference support for our models.

On Feb 16, 2015, at 7:31 AM, Keith Babo<EMAIL_ADDRESS>wrote:
We have a collapse all button, but on expand all button.
—
Reply to this email directly or view it on GitHub https://github.com/fabric8io/data-mapper/issues/142.

That's a fair point.  I imagine we could use the tree size to get a sense on whether it's manageable to do so and implement an arbitrary limit to prevent any display/memory issues.  I would think display area would be an issue before memory since anything over 1000 nodes is gonna be a mess in that view if it's all expanded.   :-)

John is definitely right in this case. I would worry about the potential size and memory footprint as well. There are probably ways around it, but it can be a hairy, ugly mess at times.
That said, we could probably start stashing some file/project-specific settings behind the scenes in the project metadata in Eclipse to keep track of the last node selected and whether it was expanded or not, filter button state, etc. - that might help persist a bit of state between openings of the editor.

On Feb 16, 2015, at 8:33 AM, Keith Babo<EMAIL_ADDRESS>wrote:
That's a fair point. I imagine we could use the tree size to get a sense on whether it's manageable to do so and implement an arbitrary limit to prevent any display/memory issues.

Unfortunately, you can't determine the Eclipse tree size without expanding everything under the covers first.  The total size has to come from the back end, for which in my experience, memory can be just as much a concern.  And if you're using weak references on the backend model, you won't necessarily know the size up front (but that depends entirely on how changes to the model are handled, of course).  Plus, it would be a new/unusual precedent to change the GUI behavior (i.e., whether an expand all button is visible/enabled) based upon the size of the tree's contents.

I would think display area would be an issue before memory since anything over 1000 nodes is gonna be a mess in that view if it's all expanded.  :-)

Both of these are concerns, but it depends with the latter.  Eclipse does have some mechanisms to use "virtual" trees that help with the memory impact, but I'm not sure about the details yet.  But I'd certainly be concerned about the former.  This would be pretty non-standard in Eclipse also, but what do you think about auto-expanding the tree if it's size is less than some amount?  Again, we might have to back that out eventually if we get to using weak references in the backend and sizes aren't always available up front...

—
Reply to this email directly or view it on GitHub https://github.com/fabric8io/data-mapper/issues/142#issuecomment-74516444.

The model tree in core is super light, so it should not be a problem to implement size efficiently.  Should be simple enough to test it at a tree size of 10000 just to be sure.  If a user has a model with > 10000 nodes, then mapping overall is going to be pretty horrific.
On Feb 16, 2015, at 9:48 AM, John Verhaeg<EMAIL_ADDRESS>wrote:

On Feb 16, 2015, at 8:33 AM, Keith Babo<EMAIL_ADDRESS>wrote:
That's a fair point. I imagine we could use the tree size to get a sense on whether it's manageable to do so and implement an arbitrary limit to prevent any display/memory issues.

Unfortunately, you can't determine the Eclipse tree size without expanding everything under the covers first. The total size has to come from the back end, for which in my experience, memory can be just as much a concern. And if you're using weak references on the backend model, you won't necessarily know the size up front (but that depends entirely on how changes to the model are handled, of course). Plus, it would be a new/unusual precedent to change the GUI behavior (i.e., whether an expand all button is visible/enabled) based upon the size of the tree's contents.

I would think display area would be an issue before memory since anything over 1000 nodes is gonna be a mess in that view if it's all expanded.  :-)

Both of these are concerns, but it depends with the latter. Eclipse does have some mechanisms to use "virtual" trees that help with the memory impact, but I'm not sure about the details yet. But I'd certainly be concerned about the former. This would be pretty non-standard in Eclipse also, but what do you think about auto-expanding the tree if it's size is less than some amount? Again, we might have to back that out eventually if we get to using weak references in the backend and sizes aren't always available up front...

—
Reply to this email directly or view it on GitHub https://github.com/fabric8io/data-mapper/issues/142#issuecomment-74516444.

—
Reply to this email directly or view it on GitHub.


Configuration option to skip reading configuration files.

There are two ways to configure config file reading:
1. In-code - By default config file is skipped until
SetViperLocalConfig() is called.
2. In command line - Use --skip-config-file command line options.

Codecov Report

Merging #9 (f33547f) into main (dfa9d48) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##              main        #9   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            8         8
  Lines          546       574   +28
=========================================
+ Hits           546       574   +28

Impacted Files
Coverage Δ

cli/cli.go
100.00% <100.00%> (ø)

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 dfa9d48...f33547f. Read the comment docs.


devel: Privileged and cap_add are mutually exclusive

Ah I just wanted to close this >< There's also some issue with selinux labels/relabeling of volumes, I think the ovlume mounts need :z depending on policy.
I'm ashamed to admit i dont actually have selinux running, but i'll revisit this in a fedora vm or something later, as people have still been running into issues.


Can I use DAIN-APP on Google Colab?

Yes, there is already a few implementations like:
https://github.com/HeylonNHP/Dain-App#google-colab-demo


Deprecate simulator

Remove simulator from the codebase to speed up phase 1 and 2 development. A network simulator will be re-introduced in phase 3, either in this repo or another simulation-focused one.

Included here https://github.com/farcasterxyz/hub/pull/38


Add Microsoft Azure to Snowpark supported cloud providers

Add Microsoft Azure as a supported cloud platform for Snowpark (Oct 2021 release)

Thank you for your contribution!


Check against against ACVP testvectors

We should check against the official testvectors availlable at https://github.com/usnistgov/ACVP-Server/tree/master/gen-val/json-files in CI.
OQS has also recently integrated that check, so we can hopefully borrow some code from there: https://github.com/open-quantum-safe/liboqs/pull/1899

Done in #256


Pass selected kind and story as args

When creating plugins for stories, it'll be useful to have
the kind name and the story name accessible to plugins.
The react-storybook-story plugin can be improved with this PR.

This is great. Try to document it too. Just an example would be enough.


5tps build (NO MERGE)

Adds a build configured for 5tps for testing

@nholland94 and @deepthiskumar did napkin math yesterday or Monday and found that at only 1tps when the scan-state is full, we're using 4GB of RAM on that. At 5tps I'd expect that we get an OOM error. Worth trying!
Should we be building artifacts for these networks every PR though? Maybe we shouldn't add these to the coda-parallel workflows but only trigger manually -- up to you

I can retire it quickly if it OOMs immediately.
My goal was to push out some edges that fit within our goals, make some measurements and encourage some profiling so we can focus attention.

Bitrot!