[FIX]: Inconsistent behavior when saving existing name without edit and unnecessary API calls

Details

Fixed Issues

$ https://github.com/Expensify/App/issues/38668
PROPOSAL: https://github.com/Expensify/App/issues/38668#issuecomment-2009497401
Tests

Same as QA

[x] Verify that no errors appear in the JS console

Offline tests

Same as QA
QA Steps

Precondition:

User is admin of Collect workspace.
The Collect workspace has categories and tags.

Go to staging.new.expensify.com.
Go to Profile > Workspaces > Collect workspace.
Go to Categories.
Click on any category.
Click Category name.
Save the name without editing.
Go to Tags.
Click on any tag.
Click Tag name.
Save the name without editing.

Observe that when the name is being edit but no change has been done, it do nothing and the modal just closes and the API call is skipped

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

MacOS: Chrome / Safari
https://github.com/Expensify/App/assets/110545952/59777fe1-ce20-48c3-a475-35f1e1234ded

MacOS: Desktop
https://github.com/Expensify/App/assets/110545952/65957a0f-8adf-4ee5-8a80-811b39bd6554

iOS: mWeb Safari
https://github.com/Expensify/App/assets/110545952/ecd5457c-2809-4794-bbec-2ad6a85e9455

iOS: Native
https://github.com/Expensify/App/assets/110545952/eb8082b8-ce65-4c0f-af51-4c0f513df79f

Android: Native
https://github.com/Expensify/App/assets/110545952/ee8f303d-3ce3-42ac-9633-c8ea34c06ae1

Android: mWeb Chrome
https://github.com/Expensify/App/assets/110545952/0e45df1a-bfe4-425c-9257-5710e9d1dae1

Test were passing

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.


Upgrade to Pydantic v2

This is somewhat of a breaking change, so probably need to do a major version bump

When do you estimate this PR can be merged? It seems we'll need it in order to update Aviso version in Tienda & Camino @ljodal

When do you estimate this PR can be merged? It seems we'll need it in order to update Aviso version in Tienda & Camino @ljodal

We can probably get this merged fairly soon, but this alone isn't enough to upgrade pydantic in Tienda. We have other blockers there as well. Feel free to reach out on Slack if you want to discuss the upgrade closer, as I'd rather not take that in a public repo :)


Convert CFE_OMIT_DEPRECATED_6_6 to deprecate by default

Switch ifndef CFE_OMIT_DEPRECATED_6_6 to ifdef CFE_DEPRECATED_6_6, user action is to define if needed but leave out by default.

Imported from trac issue 312.  Created by jhageman on 2019-07-12T13:07:43, last modified: 2019-07-24T17:20:55

Trac comment by jhageman on 2019-07-24 17:20:55:
Decided against deprecate by default.  Keeping same process for this release (define to OMIT) so as not to break all the code out there.  Bundle will recommend removing deprecated code and/or we can notify the standard set of apps if they use deprecated code.


Widget doen't works on firefox

Hi,
Just setup the widget with npm, it is working on Chrome but not firefox.
Here is the error in console :

Hi there
Could you please share which version of Firefox you’re using, along with your operating system (e.g., Windows 10, macOS Monterey)? This will help us better assist you!

Hi,
Version 131.0.3 (64-bit)
Mozilla Firefox Snap for Ubuntu
canonical-002 - 1.0

It is also not working on
Version 132.0
Android 13

Hi
We've managed to replicate a similar error after testing with some Firefox extensions. Could I ask you to double-check if you have any extensions enabled in Firefox? This could help us confirm if they're contributing to the issue.
Thanks very much for you cooperation!

Hi,
Yes my bad it is related to uBlock Origin for my Ubuntu version and No script for the Android (Harder to remember since there is no console there)


having trouble with convergence

Hi, first off thank you for the wonderful code. I am trying to replicate the toy blob example in pytorch. I am finding that it unreliably converges to the same accuracies that you report. Sometimes it will not converge at all, and other times it will get to the 97% source/97% target accuracy. Also, the source-only training yields a 50% accuracy on target domain. I was wondering if there were any snags you encountered that hindered convergence?
Thanks
Austin

for me, the biggest discrepancy with the blobs example was that source-only training resulted in trivial (50%) accuracy. did you get this as well? as for hyperparameters, adding more dimensions to the feature extractor (i.e. going from 8 to 50) was what allowed it to converge at all for me.

I take it that that 50% was the source accuracy, not the target accuracy? In that case, there is certainly something wrong, but 50% accuracy on the target class is not unusual if you only train on the source.
One thing that might help is annealing the gradient reversal parameter. I do this in the MNIST example, following the schedule presented in the paper, but for the blobs example I keep it fixed at -1 throughout training. That is almost certainly not the optimal thing to do.


Do not use ES6 modules

This PR fixes an issue where the code was being transpiled with ES6 modules which are not supported by NodeJS runtimes and therefore causing issues using Brigade in Jest tests.

Pull Request Test Coverage Report for Build 167

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

Totals

Change from base Build 164:
0.0%

Covered Lines:
187

Relevant Lines:
187

💛  - Coveralls


Feature proposal - json file output

Is your feature request related to a problem? Please describe.
I would like to process results gathered by bundlemon, I need an interface that would allow saving bundlemon results as a file or ability to attach custom output/reporter to process and save results. Application I am working with is build on a CI server and can't be build by Github Actions. This forces me to measure bundle sizes on the CI server and then process results further for example by sending them to some dashboard or github issue API.
Describe the solution you'd like
Ability to store result as json file. Optionally passing file name as parameter.
Describe alternatives you've considered
At the moment I could possibly scrap results from the console output but that's very hacky solution.
Additional context
I created a draft of a simple output that could possibly satisfy requirements of how bundlemon works, but I didn't test this solution yet. It's a raw draft for feature proposal.
import fs from 'fs';
import { Report } from 'bundlemon-utils';
import logger from '../../../common/logger';
import type { Output, OutputCreateParams, OutputInstance } from '../types';

const saveAsJson = (filename: string, payload: Report) => {
  fs.writeFile(`${filename}`, JSON.stringify(payload), (error: any) => {
    if (error) {
      logger.log('There was an error when saving a file');
      throw error;
    }
    logger.log(`${filename} saved.`);
  });
};

const output: Output = {
  name: 'json',
  create: (params: OutputCreateParams): OutputInstance | Promise<OutputInstance | undefined> | undefined => {
    const { filename } = params.options;
    const name = filename ? filename : 'bundlemon-results.json';
    return {
      generate: (report: Report): void => saveAsJson(name, report),
    };
  },
};

export default output;

Released in v1.2.0
Thank you for your contribution 👍


Authorization implemented in UsersController#info.

Hi,
I implemented authorization in UserController#info.
Patching this commit, the user info can be returned against a request from administrators or one's own self.
Please take a look.
Thanks.

Looks good to me fwiw

pulled.  thanks


Custom -pp just for ocamldep that makes recompilation more-incremental.

On the topic of ocamldep. Cheng found a bug in our use of ocamldep, that I imagine comes up quite frequently (It's not important, but basically we need to know that when someone refers to Pack.Mod, we're actually depending on Mod, because Pack might be the module alias namespace that we ourselves belong to, and that was opened via -open).
With our opinionated jengaboot rules for namespaceing (via module alias), we  are well positioned to avoid this particular pitfall and I think that we can include the solution in Reason out of the box. The solution I have in mind improves incremental recompilation as well.

When we are in package Pack, we know what our dependencies' namespaces are (according to our opinionated jenga system, we read them from a package.json/opam file). We also know the name of the namespace that we are being compiled into (it's the name of the package!)
Given that we're using opinionated JaneStreet style build rules, we know that Dep1.X is actually going to be compiled into a module artifact named Dep1__X.
We can include a custom preprocessor named -pp refmt-for-ocamldep, which is the same as -pp refmt, but replaces Dep1.X with Dep1__X when we know that Dep1 is one of our dependency package names, and replaces Pack.X to Pack__X when we know that Pack is the name of our own package.
Not only does this solve that bug that we found in our use of ocamldep, but it will also allow fine grained dependencies to be detected between packages. This is really great because it means if I change a single file in a dependency package that I'm developing, recompilation will be super incremental. Currently, we just say "they changed something in a dependency Dep1, better recompile everything that depends on Dep1".

I know there's some discussion of improvements to module aliases coming, but this should work today in most cases (it's not perfect but neither is ocamldep right now).

Just to confirm, you're already using '-no-alias-deps', right?

Yes.

Or do you mean as in argument to ocamldep

Ok.  I didn't mean to ocamldep.
I'm not sure I understand.  Suppose there are two modules Dep.X and Dep.Y within "package" Dep.  Is it expected that the code of X can refer to Dep.Y?  I would have expected not, and that Y without Dep. would need to be used.  Why?  I'm not sure, but that's what my immediate expectation is.  Perhaps referring to Dep from a module that forms part of Dep is too close to a recursive reference to be comfortable.
To me this seems independent of being able to track dependencies to modules of packages, instead of to entire packages.

@jordwalke we should update this with the as-map findings

Yes, as-map in 4.03 might do exactly what we want.

Closing because as-map likely does what we want and we may make Reason 4.03+ only.


Support a broader set of visit types

Following on from #218, which lands with VisitType.unknown, we should record more visit types.
The existing visit types used by Sync are (cribbed from firefox-ios):
    /**
     * This transition type means the user followed a link and got a new toplevel
     * window.
     */
    case Link = 1

    /**
     * This transition type means that the user typed the page's URL in the
     * URL bar or selected it from URL bar autocomplete results, clicked on
     * it from a history query (from the History sidebar, History menu,
     * or history query in the personal toolbar or Places organizer).
     */
    case Typed = 2

    case Bookmark = 3
    case Embed = 4
    case PermanentRedirect = 5
    case TemporaryRedirect = 6
    case Download = 7
    case FramedLink = 8

We might have more values than this.

This is relevant to #678 and the ongoing UA service using DataScript work.  I vaguely recall that WebKit exposes fewer visit types via Electron but don't have a reference to hand.


Members subscription settings migrations

refs #10318
This adds two migrations for pulling the members subscriptions settings and the stripe connect integration into their own settings

@rishabhgrg This should all be in sync now!

This have been updated to assume that the setting will already exist @ErisDS @kevinansfield @rishabhgrg

Test's are erroring because of default-settings.json - but it's necessary to include it to test the migrations locally.
Once migrations are tested and approved they'll go into the main PR over here: https://github.com/TryGhost/Ghost/pull/11957 and everything will be merged in together


Improve colors selecion

I think the design is fine.


"Team page": Add acknowledgement for the dev team on the 'About' page.

Please include:
TL,TE,SP,OT and me!
similar to this:

Added in d4f56d2396978689a6d6f99b98bbc03ef725cd01


turfpy.measurement.points_within_polygon and turfpy.measurement.boolean_point_in_polygon are very slow

Hey there,
I noticed that points_within_polygon (and the foreach-point-callback boolean_point_in_polygon) was fairly slow compared to the Shapely package's shapely.geometry.Polygon.contains method.
As a test, I used a featureCollection called points consisting of roughly 5,000 points (in the Columbus, Ohio metro area fyi) and a geojson.Polygon called polygon (compatible with turfpy methods).
Method 1: turfpy.measurement.points_within_polygon
Calling turfpy.measurement.points_within_polygon(points,polygon) takes roughly 26 seconds.
Method 2: shapely.geometry.Polygon.contains
I wrote a method that:

instantiates a shapely.geometry.Polygon called polygon from a geojson.Polygon and also creates a Python list of points of type shapely.geometry.Point,
overwrites the list of points to only contain those where polygon.contains(point) is True,
converts the list of points back to a geojson.featureCollection, which it returns.

This takes roughly 5 seconds.
Conclusion
The two methods return the same number of points; furthermore, I plotted the points on a map in my browser (using Folium), and neither one is doing anything wrong.
Even with all the object creation (literally copying the list of points, taking up additional memory, too), Method 2 (Shapely) took <1/4 the time.
So - in case anyone intends to use this method, perhaps it can be reworked. For now, I'll post my "faster" method here.
from geojson import Polygon, Point, Feature, FeatureCollection
import shapely.geometry
import shapely

def create_point(lon,lat):
	return Feature(geometry=Point((lon,lat)))

def point_to_shapely(point):
	lon,lat = get_lon_lat(point)
	return shapely.geometry.Point(lon,lat)

def get_list_of_shapely_points(featureCollection):
	return [point_to_shapely(point) for point in featureCollection['features']]

def polygon_to_shapely(polygon):
	return shapely.geometry.Polygon(polygon['coordinates'][0])

def shapely_points_to_featureCollection(points):
	geojson_pts = [create_point(point.x,point.y) for point in points]
	return FeatureCollection(geojson_pts)

def get_contained_points_shapelystyle(points,polygon):
	shply_polygon = polygon_to_shapely(polygon)
	shapely_points = [shply_point for shply_point in get_list_of_shapely_points(points) if shply_polygon.contains(shply_point)]
	return shapely_points_to_featureCollection(shapely_points)

To be fair, my points have no geojson properties, but I still think this is odd and maybe bad.

Thanks, @zsiegel92 for reporting this. We will surely look into this. Meanwhile, if you want to raise PR then feel free to raise it.
:)

@zsiegel92 - Apart from finding  Point in single Polygon currently we also support multiple Polygons and MultiPolygons, but yes we will need to improve the performance of it.

@sackh Thanks for this response! I'm glad you're looking into it. When I encounter a MultiPolygon called feature, I just iterate through the coordinate lists in feature.geometry.coordinates, create a Polygon for each list of coordinate, and then use the method above. Aside from the object-copying I mentioned, it's basically an O(1) transformation, so the difference should remain, though I haven't done a timed test. I can't imagine turfpy does anything much different... I can't imagine there's any theoretical MultiPolygon.contains algorithm that is so much more clever that it is worth a 4x slowdown for a Polygon...

@zsiegel92  can you share the geojson for the points and polygon you test with I have made some progress so to test it I can use that geojson data.

@zsiegel92  I have merged the changes and test with some huge data it looks good, made a new release v0.0.5 you might wanna give it a try 😉

Hi @omanges I look forward to trying out the new implementation! I already have a parallel set of functions that uses this method rather than my workaround, so I should be able to test it out soon.
This will simplify my codebase, as I will not have any reason to import shapely if this method is comparably performant!

@omanges I just ran a small and a large trial of my current use case and got the following output:
Using turfpy.measurement.points_within_polygon:
595 points:
Ran 15 trials with average time of 2.7013930002848308 seconds!

14772 points
Ran 5 trials with average time of 57.62896718978882 seconds!

Using Shapely workaround:
595 points:
Ran 15 trials with average time of 1.3027364571889242 seconds!

14772 points
Ran 5 trials with average time of 31.952202796936035 seconds!

So: it looks like your update improved the performance of this method by a lot! It's still a bit slower than using the shapely method, for some reason.
I noticed when I updated turfpy, pip mentioned downloading shapely as a dependency...was this always a dependency, or did your update utilize Shapely?

Actually, we had added shapely few version earlier, but it is used for some other functions, I have one question did you increased the chunk size parameter, I bet it will give you more after results than shapely :) Give it a try.

By default the chunk_size is 1, but can you try by setting it to 9?
Following is the new signature of the function.
def points_within_polygon(
    points: Union[Feature, FeatureCollection],
    polygons: Union[Feature, FeatureCollection],
    chunk_size: int = 1,
) -> FeatureCollection:

Currently running some tests and it's not looking good!
Iteration 1/5 with params {'shapelyStyle': True, 'chunk_size': 1}
Iteration 2/5 with params {'shapelyStyle': True, 'chunk_size': 1}
Iteration 3/5 with params {'shapelyStyle': True, 'chunk_size': 1}
Iteration 4/5 with params {'shapelyStyle': True, 'chunk_size': 1}
Iteration 5/5 with params {'shapelyStyle': True, 'chunk_size': 1}
Average for {'shapelyStyle': True, 'chunk_size': 1}: 3.2872236728668214
Iteration 1/5 with params {'shapelyStyle': False, 'chunk_size': 1}
Iteration 2/5 with params {'shapelyStyle': False, 'chunk_size': 1}
Iteration 3/5 with params {'shapelyStyle': False, 'chunk_size': 1}
Iteration 4/5 with params {'shapelyStyle': False, 'chunk_size': 1}
Iteration 5/5 with params {'shapelyStyle': False, 'chunk_size': 1}
Average for {'shapelyStyle': False, 'chunk_size': 1}: 14.118095636367798
Iteration 1/5 with params {'shapelyStyle': False, 'chunk_size': 2}
Iteration 2/5 with params {'shapelyStyle': False, 'chunk_size': 2}
Iteration 3/5 with params {'shapelyStyle': False, 'chunk_size': 2}
Iteration 4/5 with params {'shapelyStyle': False, 'chunk_size': 2}
Iteration 5/5 with params {'shapelyStyle': False, 'chunk_size': 2}
Average for {'shapelyStyle': False, 'chunk_size': 2}: 22.541523122787474
Iteration 1/5 with params {'shapelyStyle': False, 'chunk_size': 3}
Iteration 2/5 with params {'shapelyStyle': False, 'chunk_size': 3}
Iteration 3/5 with params {'shapelyStyle': False, 'chunk_size': 3}
Iteration 4/5 with params {'shapelyStyle': False, 'chunk_size': 3}
Iteration 5/5 with params {'shapelyStyle': False, 'chunk_size': 3}
Average for {'shapelyStyle': False, 'chunk_size': 3}: 30.215075874328612
Iteration 1/5 with params {'shapelyStyle': False, 'chunk_size': 4}
Iteration 2/5 with params {'shapelyStyle': False, 'chunk_size': 4}
Iteration 3/5 with params {'shapelyStyle': False, 'chunk_size': 4}
Iteration 4/5 with params {'shapelyStyle': False, 'chunk_size': 4}
Iteration 5/5 with params {'shapelyStyle': False, 'chunk_size': 4}
Average for {'shapelyStyle': False, 'chunk_size': 4}: 37.53313364982605
Iteration 1/5 with params {'shapelyStyle': False, 'chunk_size': 5}
Iteration 2/5 with params {'shapelyStyle': False, 'chunk_size': 5}
Iteration 3/5 with params {'shapelyStyle': False, 'chunk_size': 5}
Iteration 4/5 with params {'shapelyStyle': False, 'chunk_size': 5}
Iteration 5/5 with params {'shapelyStyle': False, 'chunk_size': 5}
Average for {'shapelyStyle': False, 'chunk_size': 5}: 44.78047194480896
Iteration 1/5 with params {'shapelyStyle': False, 'chunk_size': 6}
Iteration 2/5 with params {'shapelyStyle': False, 'chunk_size': 6}
Iteration 3/5 with params {'shapelyStyle': False, 'chunk_size': 6}
Iteration 4/5 with params {'shapelyStyle': False, 'chunk_size': 6}
Iteration 5/5 with params {'shapelyStyle': False, 'chunk_size': 6}
Average for {'shapelyStyle': False, 'chunk_size': 6}: 52.65997791290283

Definitely an improvement as I increase chunk size! I increased it between 1 and 9, and results improved. What is the maximum chunk size at which you expect to see an improvement?
param={'shapelyStyle': True, 'chunk_size': 1}
Iteration 1/5 Iteration 2/5 Iteration 3/5 Iteration 4/5 Iteration 5/5 Average for {'shapelyStyle': True, 'chunk_size': 1}: 7.476626777648926
param={'shapelyStyle': False, 'chunk_size': 1}
Iteration 1/5 Iteration 2/5 Iteration 3/5 Iteration 4/5 Iteration 5/5 Average for {'shapelyStyle': False, 'chunk_size': 1}: 23.191674423217773
param={'shapelyStyle': False, 'chunk_size': 2}
Iteration 1/5 Iteration 2/5 Iteration 3/5 Iteration 4/5 Iteration 5/5 Average for {'shapelyStyle': False, 'chunk_size': 2}: 19.63445348739624
param={'shapelyStyle': False, 'chunk_size': 3}
Iteration 1/5 Iteration 2/5 Iteration 3/5 Iteration 4/5 Iteration 5/5 Average for {'shapelyStyle': False, 'chunk_size': 3}: 15.31570062637329
param={'shapelyStyle': False, 'chunk_size': 4}
Iteration 1/5 Iteration 2/5 Iteration 3/5 Iteration 4/5 Iteration 5/5 Average for {'shapelyStyle': False, 'chunk_size': 4}: 14.534931993484497
param={'shapelyStyle': False, 'chunk_size': 5}
Iteration 1/5 Iteration 2/5 Iteration 3/5 Iteration 4/5 Iteration 5/5 Average for {'shapelyStyle': False, 'chunk_size': 5}: 13.989737749099731
param={'shapelyStyle': False, 'chunk_size': 6}
Iteration 1/5 Iteration 2/5 Iteration 3/5 Iteration 4/5 Iteration 5/5 Average for {'shapelyStyle': False, 'chunk_size': 6}: 13.749914312362671
param={'shapelyStyle': False, 'chunk_size': 7}
Iteration 1/5 Iteration 2/5 Iteration 3/5 Iteration 4/5 Iteration 5/5 Average for {'shapelyStyle': False, 'chunk_size': 7}: 13.314592599868774
param={'shapelyStyle': False, 'chunk_size': 8}
Iteration 1/5 Iteration 2/5 Iteration 3/5 Iteration 4/5 Iteration 5/5 Average for {'shapelyStyle': False, 'chunk_size': 8}: 13.24393539428711
param={'shapelyStyle': False, 'chunk_size': 9}
Iteration 1/5 Iteration 2/5 Iteration 3/5 Iteration 4/5 Iteration 5/5 Average for {'shapelyStyle': False, 'chunk_size': 9}: 13.031423473358155

Sorry that's tough to understand - the first test was using the Shapely variant I wrote, with average time 7.48s (chunk_size is written as 1 but is not meaningful for this trial). The subsequent trials used the Turfpy function; with chunk_size 1, the time was 23.19s, and it decreased all the way down to 13.03s with chunk_size 9.

@omanges I ran a few trials overnight and noticed a roughly constant performance for chunk_sizes between 30 and 150. It leveled out at taking around 1.5x the time that Shapely took. Without knowing what this means, it's hard to know what the ideal value should be.

@zsiegel92 the chunk_size parameter means same as the chunk_size present in multiprocessor.map please refer to this document https://docs.python.org/release/2.6.6/library/multiprocessing.html#multiprocessing.pool.multiprocessing.Pool.map

@omanges Thanks! Now I've tested for chunk_sizes of 100, 500, 1000, 10000, and 15000, all with similar performance (12-16s per trial, with <7s for the Shapely version).

I think further improvement can be done by improving the turfpy.measurement.boolean_point_in_polygon, and then it works faster than shapely as well.

And really Thank You !!! for doing such a great investigation :)


Added static directory to build step #54

add directory src/static
provide README in src/static
update copy run script to recursively copy the directory to
dist/static
refactor favicon to be copied via the static dir
reference favicon from new location in index.html

Issue: #54
@weblogixx if you don't have any objections we could merge this PR into 2.x. Rethinking the size limit on the url-loader could IMO be a separate issue in its own right.

@sthzg, seems good to me 👍


Could you please upgrade your tutorial to use latest Spring Boot version 2.1.3.RELEASE?

I am no longer working with Spring and I am afraid to break any changes. If you can do it, I would really appreciate it. Otherwise, I can't promise to upgrade.
Thanks.


Add Royal.cash to the list of merchants

What's the name of your business?
Royal.cash
What's the URL of the website?
https://royal.cash/en/
Write a brief description of your business/service (max 50 characters)
fast exchange
Enter the URL where a Monero mention can be found
https://royal.cash/en/monero-na-bitcoin.html
How do you accept Monero? (choose only one option)

[ ] Monero integrations (github.com/monero-integrations)
[ ] Globee
[ ] Native wallet
[x] Other payment gateaway (Coinpayments, Morphtoken, etc. Please specify)

How would you categorize your business? (choose only one option)

[x] Exchange
[ ] Block Explorer
[ ] Payment Gateway
[ ] Web Hosting
[ ] Tool
[ ] Service
[ ] Goods
[ ] Entertainment

Comment

Rejected.


Landing Page

Add a small landing page for this little application.
Going with the theme please make a small landing page.
Existing first/index page could have this overlay screen that comes when the user opens the site. Then either on button click or after some time, remove that welcome page/screen and show main content.

Hi, I'd like to work on this!

Sure ^.^

@DesmondANIMUS Thanks! I'll get back to you tomorrow with the code!


[PEC-03M] Potentially Incompatible Approval Methodologies

PEC-03M: Potentially Incompatible Approval Methodologies

Type
Severity
Location

Standard Conformity

ProtectedERC20Gateway.sol:L43, L47

Description:
The referenced statements are meant to reset the approval of the contract to the target to the maximum value possible, however, this reset can occur when a non-zero approval already occurs.
Impact:
Some tokens will be incompatible with the approval reset mechanism of the ProtectedERC20Gateway::depositProtectedToken function.
Example:
function depositProtectedToken(
  IPERC20 pToken,
  address onBehalfOf,
  uint256 amount,
  uint16 referralCode
) external {
  IERC20 token = IERC20(pToken.underlying());
  token.transferFrom(msg.sender, address(this), amount);
  if (token.allowance(address(this), address(pToken)) < amount) {
      token.approve(address(pToken), type(uint256).max);
  }
  pToken.depositFor(address(this), amount);
  if (pToken.allowance(address(this), address(POOL)) < amount) {
      pToken.approve(address(POOL), type(uint256).max);
  }
  // if pToken does not exist as an reserve, this would revert
  POOL.deposit(address(pToken), amount, onBehalfOf, referralCode);
}

Recommendation:
As some tokens will not allow a non-zero approval to occur when a non-zero approval already exists, we advise the code to reset the previous approval and then assign it to the value of type(uint256).max, guaranteeing that the approval will succeed. For more information, consult the relevant OpenZeppelin SafeERC20::forceApprove implementation.

fix in https://github.com/Kinza-Finance/KZA-lending/pull/34/files


[BUG] std::bit_width is not yet part of libc++, we shouldn't use it

https://godbolt.org/z/sdn7nK

We need a replacement. As we only need it in constexpr context, we can replicate a simple implementation

Apparently this mess:
auto IMAX_BITS(auto m)  { return ((m/(m%255+1) / 255)%255*8 + 7-86/(m%255+12)); }
computs exactly bit_width(m) + 1.
I propose we call that log_cardinal and put it in eve/detail as an helper.

Or did we check if clang 12 doesn't just have it ?

https://godbolt.org/z/oKqx1Y3ra
So closign this now we test with clang-12 ?

And stdlibc++ on CI?


Volar does not respect "Editor: Auto Closing Quotes" setting when writing attributes in templates

When you start typing something like class= the Volar extension tries to be helpful and adds a pair of quotes automatically.

I'm sure this is an intended feature. However, this disregards the setting in VS Code that allows the developer to disable "Editor: Auto Closing Quotes".

Personally, I find auto quotes or brackets distracting, as I don't expect characters to appear without my input, so I have that setting set to "never". I'm sure that I'm in the minority on that preference, given the fact that the setting is enabled by default, but I do think I'm justified in expecting an extension to respect this preference, or to add a setting of its own to disable auto quotes.

This is by new html config html.autoCreateQuotes and it is not release yet, you need to add "html.autoCreateQuotes": false to settings manually for now, see https://github.com/microsoft/vscode/blob/f0054e049cd286ff317c738efe0fd8810b48ae98/extensions/html-language-features/package.json#L200-L205.

Ah, thanks, and sorry to bother you.

Never mind, thanks for your report. :)

Just out of curiosity, why does it only seem to affect my Vue templates and not pure HTML files or PHP or things like that?

This feature does not rely on vscode client upgrades, so Volar can release this feature earlier than vscode.

Ah, so it's an upcoming part of the spec, but the implementation is left up to extension maintainers rather than being built into VS Code itself?

HTML extension is built-in support by vscode, I just refer to the code of vscode to add it for vue.

If the implementation is custom, do you have control over which quote gets overtyped? If I type = and then ", I would expect the opening quote to get overtyped, but instead the opening quote stays in place, and the closing quote gets overtyped. Is it known yet how VS Code's core implementation will handle this?

I just follow the logic of vscode. You can open an issue in vscode. If vscode decides to change this logic, volar will change it together.
FYR https://github.com/microsoft/vscode/blob/main/extensions/html-language-features/client/src/autoInsertion.ts

Gotcha, thanks!

@johnsoncodehk There seems to be a regression on Volar where it doesn't respect the "html.autoClosingTags": false setting:


[release-2.5] Validate query inputs

Signed-off-by: Jorge Padilla<EMAIL_ADDRESS>Related Issue: https://github.com/stolostron/backlog/issues/23796
Description of changes

Merge #203 to release-2.5 branch
Adds input validation.

PR for release-2.6 #204 should be merged first.

/lgtm
/hold

/unhold


fix: use the bash executable specified by PATH

📚 Description
Update the release script so the final bashunit script will use PATH to find bash. The version of bash in /bin on macOS is very old, and forcing tests to use it is quite limiting.
🔖 Changes

Change build.sh so it prepends #!/usr/bin/env bash to the final bashunit script.

✅ To-do list

[ ] I updated the CHANGELOG.md to reflect the new feature or fix
[ ] I updated the documentation to reflect the changes

This seems like a workable approach, but I'm not sure it's best (especially because there don't appear to be any tests that use the final packaged bashunit script).
Happy to get any feedback on this change in general as well.

Everything seems to be working fine. Thanks for the PR, @apotterri !


Update nl.json

ugh hard to track the changes, you could have submitted a review in this PR.
@LucaNL do you mind checking #721 ?

Since there was no response, I'll go with #721.
Thanks for the PR though!


Accommodate validator-changing upgrades in sync leap validation

This PR fixes an issue in validation of sync-leap responses where the validators after a validator-changing upgrade were not being used to verify the immediate switch block.
Closes #3659.

bors r+


Mob Harvester: Blaze

The Mob Harvester doesn't produce anything when set to Blaze
MC 1.16.3
Forge 34.1.19
spatialharvesters_1_16_3-0.7.12
Added for power:
Mekanism-1.16.3-10.0.11

I get the feeling the way I was determining the drops was a little broken. I think I know of an alternative that should work a little better, I'll update with that in place. Thanks!

I'm about to publish 0.7.13 which should hopefully resolve this. I'll close this now, thanks!


T03.01-Exercise-RecyclerViewLayout

how to use getViewHolderBackgroundColorFromInstance in ColorUtils class to change he background color of the items in the RecyclerView.

I know this doesn't quite answer your question, but I think in the first exercise the color isn't required to change. The solution also only has a white background color.

Closing this issue as it is not related to the repo's code.


Feat/#64 cleanup

Prettier and linting hooks are working. I deployed contracts and ran, everything looks good.


Improve cancelling POP transitions

Follow-up of #28.
Fixes:

key from initial location wasn't put into allKeys
allKeys wasn't modified correctly for push and replace, not taking the current position into account (e.g. push should remove all keys that come after the current one)

Thanks, @taurose!

This still doesn't seem to work properly:
https://github.com/reactjs/react-router/issues/3738


iOS build failure: No such module 'MLKit'

Hey @salkuadrat, thanks for the great work on this plugin - it's really helpful. I set up learning_translate and learning_language and they work perfectly on android. However, the iOS build is still failing. Not sure if the problem is related to this plugin or if it's my setup.
This is the error message when running flutter build ios. Same error happens using Xcode (and yes, I made sure to open xcworkspace and not xcodeproj as suggested here):
Swift Compiler Error (Xcode): No such module 'MLKit'
/Users/x/.pub-cache/hosted/pub.dartlang.org/learning_translate-0.0.4/ios/Classes/SwiftLearningTranslatePlugin.swift:3:7

In Xcode, it looks like this module doesn't exist either, however, there's one called "GoogleMLKit" (in case this has something to do with it (?)):

I'd greatly appreciate any help on this.

I noticed that most of the APIs in this plugin are only implemented for Android, and not for iOS, this other plugin works for me: google_ml_kit and has the same functionalities.


[MM-41115] Add option to colorize usernames in compact mode

Summary

This pull-request adds a new option which is available in compact-display mode. Usernames are colorized according to a consistent hash. This means that all users will see the same color for a given user.
The option defaults to 'true', but is persistent if changed. If a user disables colorization, modifies their overall message display preference, and then returns to the compact view, their usernames will remain uncolorized.
Ticket Link

https://mattermost.atlassian.net/browse/MM-41115
fixes mattermost/mattermost-server#19368
Related Pull Requests

Has server changes: https://github.com/mattermost/mattermost-server/pull/19382

Screenshots

before
after

Release Note

* Added option to colorize usernames in compact display mode.

Hello @3ach,
Thanks for your pull request! A Core Committer will review your pull request soon. For code contributions, you can learn more about the review process here.

Whoops, this is missing a change from my computer. One moment...

Thanks @3ach! Few comments:

What's the logic that determines what color each user will be and the minimum amount of differentiation between the colors? For example will two users names user1 and user2 have very similar colors?
It looks like the coloring is affecting standard view as well (it should only add color in compact mode as discussed)
Can we try to match the styling of the account settings with the pipe separator as per the mock design (similar to Desktop Notification settings)

I use the color-hash library. There are no current guarantees about the differentiation between colors.
Yes, this is the change coming shortly that I forgot to amend in when I put this up for review.
Yes, will fix styling now.

OK. Updated the view (and my screenshots) to match the other UI.

fixes https://github.com/mattermost/mattermost-server/issues/19368

Looks good from my perspective. @matthewbirtch any comments or concerns before we proceed with this feature enhancement?

I do have concerns about the contrast and legibility with the colors here. Does the library account for proper contrast ratios? Also, how does this apply across the different themes? I imagine it would need to be a different set of colors for dark themes for example.
The other concern I have from a design perspective is the visual noise created by the rainbow of colors that could get introduced by this change with channels that have a lot of active users. I guess it's ok if it is a configurable setting. @esethna was this proposal vetted by the design team before the ticket was created?

The library currently takes no other input than the username, so it doesn’t offer guarantees about contrast. We can constrain its color range using information about the background to make the colors more readable.

This type of feature really shines when you do use it in a large, high traffic channel. If usernames tend to be around the same length, another quick visual difference helps scan through quickly.

I'm okay with the idea of this, but we need to try and make sure the contrast reaches a ratio of 4.5 (or more) comparing the text color to the background. Is that possible?

@matthewbirtch apologies this didn't reach the design team before implementation. @3ach was keen and the idea was solid, so we pushed forward.
+1 and good call to constraining the colors to ensure the contrast with the channel BG is sufficient

This PR has been automatically labelled "stale" because it hasn't had recent activity.
A core team member will check in on the status of the PR to help with questions.
Thank you for your contribution!
/cc @aspleenic

@3ach @matthewbirtch Is there anything further that needs to be worked out here?

Is there anything further that needs to be worked out here?

@devinbinnie, a solution is needed to ensure colors meet the contrast ratio. I think that's it.

Sorry, I will work on this, I have just gotten very busy on other things and haven't had time to patch this up. I hope to have the time in the second half of this week or early next.

Great, thanks @3ach!

Removing myself for now; feel free to add me again once it's ready 🙂.

Sorry, I will work on this, I have just gotten very busy on other things and haven't had time to patch this up. I hope to have the time in the second half of this week or early next.

Hi @3ach how are things coming along with the contrast ratio? Is there anything we can do to help?

Thanks for your patience.
I tried several approaches here, and I'm honestly not an enormous fan of the one I landed on. Basically, check the hashed contrast from the theme background, and if it's not high enough, salt the username, rehash, and check again. Repeat until satisfied. Obviously this is not the most efficient way to do this, but I there were two constraints which I think make something like this the only option:

usernames are consistent, if given the same background, someone will have the same color across machines/users/whatever.
viewing users can have different backgrounds, so storing a single color per-user doesn't work.

Intuitively, I think that there should be some way to instead constrain a color space based on the background, and then generate a single hash within those constraints. But after reading quite a lot of online information about colors... I couldn't figure out how to do that.

Thanks @3ach, I'm going to re-request dev review give this approach to see if there's any concerns cc// @devinbinnie

Hey @3ach, how's this going? Are you blocked on anything?

This PR has been automatically labelled "stale" because it hasn't had recent activity.
A core team member will check in on the status of the PR to help with questions.
Thank you for your contribution!

I tried gathering profiles in Firefox and Google Chrome and was unable to get a good handle on the perf of this generateColor function. Here is a bounded + cached version for review.

@3ach is there a missing attachment in your post above?

No, I meant that I'd updated my PR to contain bounding (only 10 attempts to hash) and caching (per-username) for review.

Ah thanks. @devinbinnie @hmhealey ^

Not sure what's up with the CI tests, it seems like they're missing dependencies like eslint and tsc?

/update-branch

Thanks @3ach
Looks great! Waiting for E2E report to complete.
Manually tested and seeing few small issues.

Usernames on RHS are not colorized

With Collapsed Reply Threads enabled, usernames are not colorized on global Threads inbox

E2E report had some skipped tests. Updating and re-running.

/update-branch

Thank you  @3ach
E2E report looks good, no PR related failures.
There are few conflicts that need to be resolved. Can you please take a look and fix - thanks 🙂

This PR has been automatically labelled "stale" because it hasn't had recent activity.
A core team member will check in on the status of the PR to help with questions.
Thank you for your contribution!

@3ach are able to help with the conflicts?

Rebased

cc// @jgilliam17 for QA

@AshishDhama is actually the other dev we're waiting for reviews on. I just show up in the Reviewers list since I commented on the PR to answer a question

Thanks @jgilliam17 please review and merge if this all looks good. Thanks!

/update-branch

Error trying to update the PR.
Please do it manually.

@3ach I am not seeing colorization of names on the replies and threads in compact mode. See my previous comment
There are also few conflicts that need to be resolved. Thanks 🙂

This PR has been automatically labelled "stale" because it hasn't had recent activity.
A core team member will check in on the status of the PR to help with questions.
Thank you for your contribution!

@3ach, let us know if you're still working on this? Thanks!

All right, I've fixed up most the issues. There remains one spot uncolorized, which I would like some input on before moving forward.
The global threads view (defined in components/threading/global_threads/thread_item/thread_item.tsx) doesn't use UserProfile like everywhere else does to display a username. It simply yanks the author from the post and uses that. I don't know why it's designed like that, otherwise I would replace the span here with an instance of UserProfile, which would resolve the issue and make things more standard. It could also be fine to leave this instance uncolorized, since I don't think this view changes at all between compact and normal. Up to you folks.

@koox00 can you help with the question?

All right, I've fixed up most the issues. There remains one spot uncolorized, which I would like some input on before moving forward.
The global threads view (defined in components/threading/global_threads/thread_item/thread_item.tsx) doesn't use UserProfile like everywhere else does to display a username. It simply yanks the author from the post and uses that. I don't know why it's designed like that, otherwise I would replace the span here with an instance of UserProfile, which would resolve the issue and make things more standard. It could also be fine to leave this instance uncolorized, since I don't think this view changes at all between compact and normal. Up to you folks.

Let's leave the colonization out of this context @3ach and just keep it to the messages themselves.

Ok, great. Then I think this PR is complete.
On Mon, Jun 20, 2022 at 17:15 Matthew Birtch @.***>
wrote:

All right, I've fixed up most the issues. There remains one spot
uncolorized, which I would like some input on before moving forward.
The global threads view (defined in
components/threading/global_threads/thread_item/thread_item.tsx) doesn't
use UserProfile like everywhere else does to display a username. It
simply yanks the author from the post and uses that. I don't know why it's
designed like that, otherwise I would replace the span here
https://github.com/mattermost/mattermost-webapp/blob/9f519001f689e59a99d6c1f8f9413a1560d66904/components/threading/global_threads/thread_item/thread_item.tsx#L166
with an instance of UserProfile, which would resolve the issue and make
things more standard. It could also be fine to leave this instance
uncolorized, since I don't think this view changes at all between compact
and normal. Up to you folks.
[image: Screenshot 2022-06-17 at 11-26-31 Threads - Zach's Team Mattermost]
https://user-images.githubusercontent.com/3093325/174281035-7a514866-77fc-459f-8d49-b991ea28762b.png
Let's leave the colorization out of this context @3ach
https://github.com/3ach and just keep it to the messages themselves.
—
Reply to this email directly, view it on GitHub
https://github.com/mattermost/mattermost-webapp/pull/9684#issuecomment-1160632948,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAXTGTKYORHFYQG4CCVY37TVQCKIXANCNFSM5MOQEBEQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

Successfully triggered e2e testing!
https://git.internal.mattermost.com/qa/cypress-ui-automation/-/pipelines/209925

Successfully triggered e2e testing!
https://git.internal.mattermost.com/qa/cypress-ui-automation/-/pipelines/210388

@jgilliam17 I'm not really sure if I've done it right, but I copied how the other strings were done in this file.

Thanks @3ach
I believe another help text string also needs to be added to translation file  "Use colors to distinguish users in compact mode"
@devinbinnie do you mind giving i18n changes a quick look? Thanks

OK. Translation done.

@hmhealey We are waiting for the related server PR checks to be fixed so we can merge at the same time


Consolidate C++ proto files under src/proto

make the directory structure match the package structure
sanitize the package structure (test --> testing)
add auto-detection of proto file dependencies

LGTM.

Lots of problems with greenness here on interop tests - holding off on merging until we have some news there.

Interop issues fixed... Hoping this is gtg

ping


Update to .NET 5.0

Pull Request Test Coverage Report for Build f5215f0c68607e9dd1df94f04834b90eca8e9d48-PR-1

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+1.8%) to 30.684%

Totals

Change from base Build 7516909bcbe4d053e4f58e5003d02885dc6eb448:
1.8%

Covered Lines:
287

Relevant Lines:
980

💛  - Coveralls


Added very basic redis pipelining functionality

As per issue #13's request, this is just some very simple redis pipelining.

Thanks for this!


[Feature] Group multiples #{input:} into a single window and variable features

An interesting feature would be the possibility to group multiple #{input:} from the same snippet into a single dialog window instead of multiple dialogs, in order to improve the data input.
Another variable feature that would be greatly appreciated is the possibility to determinate a default value for the #{input:}. For instance #{input: Name; unknown} would return "unknown" if no user input. This default variables could also be showed into the the dialog window as an option box or a combo box.
Thank you very much for your great work and I am looking forward for the next updates.

Hi @HenryLino
The multiple input fields in a single dialog is a request I understand, but it is unlikely to be implemented soon.
I really like the idea of having a default value for the input dialog.


why says docker doesn't support OCI runtimes

Hi,
Why we say that docker doesn't support OCI runtimes on the website of CoreOS

This is probably an out of date comparison. @robszumski can we just scrap this?

@jonboulle this illustration is great, just want it be more precise

@robszumski updated this.

Thanks for checking this!


[float8] improve eager numerics for dynamic scales and gets on par with torch.compile

Turning on/off float8 all-gather shows different numerics: https://github.com/pytorch/ao/pull/873
Root cause: hp_tensor_to_float8_dynamic have different numerics in eager vs compile

compile does float32 upcasting at the begining of scale calculation, see tmp0 = tl.load(in_ptr0 + (x0), None).to(tl.float32) in triton kernels below
eager does float32 upcasting at the end

This PR moves float32 upcasting to the begining of scale calculation
unit test: TORCH_LOGS="output_code" pytest -s test/float8/test_base.py -k test_dynamic_scale_parity
tmp0 = tl.load(in_ptr0 + (x0), None).to(tl.float32)
tmp1 = tl.load(in_ptr1 + (0))
tmp2 = tl.broadcast_to(tmp1, [XBLOCK])
tmp3 = tmp2.to(tl.float32)
tmp4 = tmp0 * tmp3
tmp5 = tmp4.to(tl.float32)
tmp6 = -448.0
tmp7 = triton_helpers.maximum(tmp5, tmp6)
tmp8 = 448.0
tmp9 = triton_helpers.minimum(tmp7, tmp8)
tmp10 = tmp9.to(tl.float32)
tmp11 = tmp10.to(tl.float8e4nv)
tl.store(out_ptr0 + (x0), tmp11, None)

I am a bit surprised that we have to use fp64 in eager. Without the upcast to fp64, what is the dtype being used?

I am a bit surprised that we have to use fp64 in eager. Without the upcast to fp64, what is the dtype being used?

eager respect param dtype - if param is bf16, amax is bf16, scale compute is bf16. scale gets upcasted to fp32 at the very end

converting to draft as upcasting to torch.float32 in eager should be enough. digging into inductor as there might be nuances around how bfloat16 is handled

thanks for finding this, it would be great to have numerics match! At a high level, looks good.  Could we add two more things,

verify that there is no performance regression with torch.compile
ensure tests pass in CI

thanks for finding this, it would be great to have numerics match! At a high level, looks good. Could we add two more things,

verify that there is no performance regression with torch.compile
ensure tests pass in CI

thanks for the feedback. will address them and publish for review

verified perf is neutral and make sure all CI passes
for perf, I ran benchmark_compiled_module(times=100, repeat=100) from the output code of pytest -s test/float8/test_compile.py -k test_dynamic_scale_numeric_parity. I tested on shape = (1024, 1024),

without the change:  0.000035 secs P1612792187
with the change: 0.000035 secs P1612791058

looking into the output code, the difrerence is mainly tmp3.to(tl.float64) or tmp3.to(tl.float32)

addressed feedback and is ready for review


Try fix build

Let s see if it builds, it should as the dependency is even not used anymore.

Looks like it might be alive.... ALIVE :-) !!!!

@deltakosh this is ready to go :-) This will unlock latest npm versions to install locally

Too soon my dear :)

@deltakosh this is ready to go :-) This will unlock latest npm versions to install locally
IT IS ALL GREEN


Multi type: number/null type validation fails

Hi, I've encountered issue with validating numbers: example
Schema
{
    "$schema": "http://json-schema.org/draft-07/schema#",
    "type": "object",
    "properties": {
        "content_length": {
            "type": ["number", "null"]
        }
    }
}

Object for test
{
    "content_length": 42
}

when having those files under benches/number_* and running cli, I get
cargo run -- benches/number_schema.json -i benches/number_valid.json
    Finished dev [unoptimized + debuginfo] target(s) in 0.05s
     Running `target/debug/jsonschema benches/number_schema.json -i benches/number_valid.json`
benches/number_valid.json - INVALID. Errors:
1. '42' is not of types 'null', 'number'

But as far as I checked, this should be valid, at least by looking at https://github.com/Stranger6667/jsonschema-rs/blob/master/src/keywords/type_.rs#L54-L57 with my beginners rust knowledge.
Also when running against "type":["number"] everything looks as it's supposed to.

Hi! Thanks for reporting, I'll take a look :)

Yes, it is a bug; the upstream test suite (at least the version used by this lib) does not include such cases. I'll work on a fix

@Stranger6667 this was fast!  I will release the fix tomorrow :)

FYI @driv3r . There are still some issues regarding the comparison of two JSON values (#149) - but I plan to release a fix for this one and then make some refactorings & solve #148 in subsequent patches


docs: update macos requirements

fixes several issues
$ brew cask install adoptopenjdk
Error: brew cask is no longer a brew command. Use brew <command> --cask instead.
$ brew install adoptopenjdk
==> Caveats
Temurin is the official successor to this software:
brew install --cask temurin
adoptopenjdk has been officially discontinued upstream. It may stop working correctly (or at all) in recent versions of macOS.
Pull request checklist
Use the following template to make sure your PR fits the Teku documentation standard.
Before creating the PR
Make sure that:

[ ] You've read the contribution guidelines.
[ ] You've previewed your changes locally.

Describe the change

Issue fixed

Impacted parts

For content changes:

[ ] Documentation content
[ ] Documentation page organization

For tool changes:

[ ] CircleCI workflow
[ ] Build and QA tools (for example lint or vale)
[ ] Node dependencies and JavaScript
[ ] Read the Docs configuration
[ ] GitHub integration

After creating your PR and tests have finished
Make sure that:

[ ] You've fixed any issues raised by the tests.
[ ] You've previewed your changes with Vercel below.

Preview

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


Enhance Introduction Section Aesthetics and Layout for Improved User Experience of "intr-to-ml.html" Page

The current Introduction section on the blog page looks plain and lacks visual appeal. The layout is cramped, and the button interaction is not smooth. The updated version improves the design by adding a light background, a shadow effect for depth, and better spacing between elements. The text size is increased for better readability, and the button now has a hover effect for a smoother user experience. Additionally, the image is made responsive, ensuring it looks good on all screen sizes. These changes will create a cleaner and more user-friendly layout compared to the original design.
Additionally, the code is already prepared and ready for implementation, I kindly request to assign me to this issue
Before
Link:- https://ml-fusion-lab.netlify.app/intr-to-ml

After

@vivekvardhan2810, could you kindly explain why this issue was closed?

@coderiksenthil we will look for this afterwards, as we don't need it now, till then you can contribute.

@vivekvardhan2810 understood


updating for this month.  TEST ONLY

Docs Build status updates of commit b97fb90:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details

:x:Error

Details

[Error: GitBranchDeletedOrForcePushed]

Cannot sync git repo to specified commit because ref +refs/pull/99015/merge has been deleted or has been force pushed.
 If this is pull request, please ensure it is mergeable (no merge conflict) and open (not closed).

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings or suggestions unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


test abapGit with TFS git

https://www.visualstudio.com/team-services/git/

got rid of a 404 error, now down to some core git protocol error:


Resource for the newsletter

I'm not sure you can work with this, there does not seem to be any newsletter in the repo yet. I'm not sure how many local communities have one; there's obviously the OSM weekly that could be included in the global section.

Good suggestion 👍
We don't support a newsletter type yet, but I can add a type and icon for it.


openlayer 6.x version is causing error

hello
I got an error when I upgraded my code from v5.3.0 to 6.x
When adding a custom map using TileImage, everything works fine with v5.3.0 version of openlayer, but when I update to the latest version 6.x and above everything is different. When zooming the map, the layer keeps shifting in the vertical direction. I found that the value of the first parameter tileCoord of the tileUrlFunction function is not the same as that of v5.3.0, but when I change this value it is the same as that of v5.3.0. The map is not striving to be correct.
Do you have any good suggestions?
Here is a screenshot of v5.3.0

Below is the code
百度地图2.zip

Please see the v6.0.0 release notes. The section "New internal tile coordinates" explains the changes you need to make in your code.


Plugin install renders read-only file system error

Describe the bug
When trying to install a plugin via
apiVersion: grafana.integreatly.org/v1beta1
kind: GrafanaDatasource
metadata:
  name: prometheus
  namespace: grafana
spec:
  instanceSelector:
    matchLabels:
      dashboards: "grafana"
  plugins:
    - name: googlecloud-logging-datasource
      version: 1.2.0

  datasource:
    name: prometheus
    type: prometheus
    access: proxy
    url: http://prometheus-k8s.monitoring.svc:9090
    isDefault: true
    jsonData:
      'tlsSkipVerify': true
      'timeInterval': "10s"
    editable: true

The Pod keeps crashing with the error message
Error: ✗ failed to create temporary file: open /tmp/2140794887.zip: read-only file system

Version
v5.0.0-rc2
To Reproduce
Using the deployment manifest from about will fail the plugin install. However, if you set TMPDIR explicitly as an env var in the Grafana deployment spec, you can work around the error message and the plugin gets installed:
apiVersion: grafana.integreatly.org/v1beta1
kind: Grafana
metadata:
  name: grafana
  namespace: grafana
  labels:
    dashboards: "grafana"
spec:
  deployment:
    spec:
      template:
        spec:
          containers:
            - name: grafana
              env:
                - name: TMPDIR
                  value: /var/lib/grafana

Expected behavior
The plugin gets installed correclty without the need to set the TMPDIR env var.
Runtime (please complete the following information):

Grafana Operator Version [e.g. v5.0.0]
Environment: GKE v1.25.7-gke.1000

Additional context
Add any other context about the problem here.

Funny that we haven't gotten this error when trying out some of our other plugins.
Maybe it's something around how the GKE plugin works.
The easiest way forward is probably to just set this value as default for all deployments.
I don't want to remove the read-only filesystem.

This affects other plugins too, just tested with a panel plugin. Setting the TMPDIR sounds like an acceptable solution, it means the plugin gets downloaded and extracted in the same directory, but that should be ok.


Add stale action to mark issues and PRs as stale and close them

Motivation:
To keep good repo hygiene, it would be good to have old issues/PRs automatically commented on after a period of inactivity, and if still inactive after this, subsequently closed.
For this we can use the stale GH action. We can try out a first integration here before potentially moving it to other repos too.
Modifications:

The action will run daily at 7am (UTC).
Issues will be marked as stale after 30 days of inactivity, and subsequently closed after 7 more days of inactivity.
PRs will be marked as stale after 45 days of inactivity, and subsequently closed after 10 more days of inactivity.
A label stale will be added to issues and PRs marked as stale, and a comment will be left.

All of these things can be changed if we think the durations, the message, or the label name (if any) should be different.
Result:
Hopefully better responsiveness in issues/PRs and cleaner repos.

Just as an FYI before I'm back from break, but I'm pretty strongly opposed to doing this. We can discuss later.


cant put fire extinguisher back in place

https://github.com/user-attachments/assets/62d3ae18-cbfe-4ca0-a1d6-4583db78b985

fire axe cabinet still works so this is very sus

https://github.com/space-wizards/space-station-14/blob/af47cbd7b0389098d263248ca380b1940e400821/Resources/Prototypes/Entities/Structures/Wallmounts/extinguisher_cabinet.yml#L33
Component got removed and changed into something generic.
Needs a tag and set here. probably shouldn't accept the pocket extinguisher.
https://github.com/space-wizards/space-station-14/blob/af47cbd7b0389098d263248ca380b1940e400821/Resources/Prototypes/Entities/Objects/Misc/fire_extinguisher.yml#L73

i love whitelist not existing silently beinhg ignored by tests :trollface:


Include "To-Do"s on the track endpoint.

@kytrinyx approved. :)

This makes it easier to reference what exercises need to be implemented for a given track.

Yay! Thank you :)


Global variable leak

Hi,
strNew in lib/transliteration.js is leaking to the global scope (a var is missing at line 32).
Cheers

Thanks for the issue, I've already fixed it!


lib/string: added parseDomain and parseEmail

Motivation for this change
This adds two functions to lib.strings: parseDomain and parseEmail, which parse domains and emails under RFC 1035 and RFC 5322 respectively (the email parser accepts a superset of what is allowed under RFC 5322, but the domain parser should be tight).
I found myself in need of functions to parse domains and emails, so I thought I would upstream what I wrote.
Things done

Tested on platform(s)

[x] NixOS
[ ] macOS
[ ] Linux

[x] Definition has associated documentation.
[x] Implemented unit tests in lib/tests/misc.nix.
[x] Successfully ran nix-build lib/tests/release.nix.
[x] Fits CONTRIBUTING.md.

- could be on the first and the end position. It is non-RFC, but widely used (notable example: subdomains of livejournal.com and tumblr.com, e.g. http://-devol-.livejournal.com/)
Same for _, there are domains with _. You cannot buy such a domain, but you can make a working subdomain (same examples: livejournal, tumblr, ...)
Domains (and emails) could contain Unicode characters, (e.g. http://гувм.мвд.рф == http://гувм.мвд.рф/). I am not sure that [[:alnum:]] covers the set of IDN Unicode characters.

Ping on status?

Sorry I haven't been working on this; I'm pretty busy with my senior thesis until May 10th.
If you need this between now and then for some reason and are willing to finish up this PR, just send me a patch and I'll git commit --amend it on (or I can give you the commit bit on my nixpkgs fork).

@taktoa any motivation to continue with this PR?


'_reactNativeBackgroundActions.default.isRunning' is undefined

In the sample code, in package.json, the dependencies look like this:
  "dependencies": {
    ......
    "react-native-background-actions": "https://github.com/Rapsssito/react-native-background-actions#feat-isRunning"
  },

When running npm install this error is generated:
npm ERR! code 1
npm ERR! Command failed: git checkout feat-isRunning
npm ERR! error: pathspec 'feat-isRunning' did not match any file(s) known to git.

So I changed the version to the last one (2.1.0):
  "dependencies": {
   ......
    "react-native-background-actions": "2.1.0",
  },

So npm install worked normally, but when running react-native run-android, this error is generated:

@gabriel1lima, I am not able to reproduce the issue. Did you reset the transform cache after installing the last version?

react-native start --reset-cache worked
Sorry for the bad English. I'm Brazilian and I'm using Google Translate.
Thanks!

Glad it worked!


tools: move from hack in a proper directory

promote the internal helper tools in their own directory, and, most notably, bootstrap their testsuite.
Once the testsuite is fleshed enough, we will add a lane to exercise it.

error creating EC2 NAT Gateway

/retest

/retest

/hold cancel
/cherry-pick release-4.11

/retest

/retest
this is a flake, but it's more and more suspicious

thanks for making the changes.
/lgtm

/override ci/prow/ci-install-e2e


diable -> disable typo

If you think this is a sign I'm fighting with merging lwa352 into the new build system....you would be correct.

Thanks for the fix! The CI showed 3 spurious failures but of course it's not this commit causing them. :)
I'm working on 2 of those 3 issues right now, related to <pyconfig.h> on self-hosted and installing 3.6 on ubuntu-latest. So I can hopefully cherry-pick solutions onto this branch shortly.
The 3rd seems to be a legit test failure in test_read_drx on self-hosted 3.6. Unclear (to me) what went wrong there.


CDN service annotation support

Newer versions of the AWS load balancer controller change the default behaviour of LoadBalancer objects to be internal (private IP address) rather than internet-facing. The interface for making a LoadBalancer internet-facing is now an annotation on the k8s service object.
So this PR adds support for annotations on the CDN service, which is the only one intended to be used as a LoadBalancer.

I stumbled into issues testing locally, as the kubectl container couldn't build (the alpine pkgs wouldn't install kubectl and jq) - but I replaced it with uselagoon/tests:latest - which has them preinstalled, and it worked fine.
------------------------------------------------------------------------------------------------------------------------
==> Logs of container lagoon-logging-7l8a9hjbxf-logs-dispatcher-test-cdn-service-annotations
------------------------------------------------------------------------------------------------------------------------
fetch https://dl-cdn.alpinelinux.org/alpine/v3.19/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.19/community/x86_64/APKINDEX.tar.gz
WARNING: fetching https://dl-cdn.alpinelinux.org/alpine/v3.19/main: could not connect to server (check repositories file)
WARNING: fetching https://dl-cdn.alpinelinux.org/alpine/v3.19/community: could not connect to server (check repositories file)
ERROR: unable to select packages:
  jq (no such package):
    required by: world[jq]
  kubectl (no such package):
    required by: world[kubectl]
    ```


Fixes #20

Fixes issue where node modules isn't installed before build is started, which causes issues when using client side node dependencies

I don't think node.js 5.x is supported yet. Follow https://github.com/meteor/meteor/issues/5124
Plus now there is a meteor way of handling npm dependencies with meteor npm install, which should also be handled by cf-meteor-buildpack and is not: http://guide.meteor.com/1.3-migration.html#modules


fix some typos in README.md

Ⅰ. Describe what this PR did
Make the document more readable
Ⅱ. Does this pull request fix one issue?
None

Codecov Report

Merging #828 into master will increase coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #828      +/-   ##
==========================================
+ Coverage   40.02%   40.03%   +0.01%
==========================================
  Files         108      108
  Lines        6359     6359
==========================================
+ Hits         2545     2546       +1
  Misses       3606     3606
+ Partials      208      207       -1

Impacted Files
Coverage Δ

supernode/daemon/mgr/scheduler/manager.go
24.81% <0%> (+0.75%)
:arrow_up:

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 c476d46...59bc4b1. Read the comment docs.

LGTM.


Cannot set hotkeys on Mac?

I am trying to set custom hotkeys on Mac. All of the hotkeys say "Not Set", but when I click on it to set it, I press some keys and nothing registers. I've rebooted, tried multiple times, multiple hotkeys, and nothing seems to work. Is there a known issue with setting hotkeys on the Mac version of the app? Thanks!

Keys must contain a modifier key such as ctrl. This is an undocumented feature to keep people from binding 'space' and not being able to press space for any application except for GPMDP, as these hot keys take over the key binding exclusively.

Yes, I get that. Nothing works including using a modifier (e.g. CMD+L or CMD-[)

Hmm, GPMDP version?

CMD+L or CMD-[

You have to use Cntrl, macOS key listeners do not work super well with the Command key, so even on macOS shortcuts have to currently be bound using control

Hmm ok. I’ll give it another shot! Thanks!

Is a workaround for this possible? I know that some electron apps (e.g. atom) have cmd as a modifier. In addition, is it possible to use a function key? I originally wanted to use the music buttons on the top of my keyboard, but @jostrander 's explanation makes me think that it might not be possible, especially without a modifier key. Even so, ctrl/cmd + play/prev/next would be nice...


Use Swift stub file for targets with zero files and swift dependencies

Adds new asset (Stub.swift)
Should apply only to targets with swift dependencies
Fixes swift sample project (Tailor)

What targets would have zero files

@kastiglione the common example is, "bundle" like Apple app targets.
These rules may have sources in *_library's deps. At build time, bazel creates targets to links them all together ( i.e. how ios_application works )
ios_application(deps=[":a"])

objc_library(name="a", srcs=["main.c"])

So, under XCHammer, we end up with empty ios_application's. Since Xcode predicates creating a .swiftmodule on the presence of a .swift file, the build won't work without it.

So it's only the case for certain rules, like ios_application?

@kastiglione - Yup. Since top-level targets contain their sources in library / framework dependencies they have zero source and need a dummy file.


generate.sh writes out the javascript for you?

generate.sh writes out the javascript for you?  Thats' neat.... I guess I/we could do the same thing for python???
PS Fifth star :-D

(oh, ffi-generate is nodejs specific.  Hmmm.  But ... should be possible to write ffi-generate for python.  But.. .I'm trying to avoid engineery stuff at the moment, write an actual research paper.  But, hey, I always say that :-D )


[Question] PreLongClick / PreClick listeners

I just realized MultiselectSampleActivity uses two mysterious undocumented features : mFastAdapter.onPreClickListener and mFastAdapter.onPreLongClickListener that look quite powerful (and much simpler than what I'm using myself to recreate the same behaviour)
I have a vague idea about how they should be used, but I'd rather ask you directly.
Would it be possible to document that API, as well as its interaction with the actual click / longClick events ?
Thanks a lot in advance~

The idea behind those listeners was to provide a way to act on a click event before it is passed along to inner functions of the library. E.g. prevent behaviour of the select or expandable extensions.
Similar to the other listeners you have the possibility to do something with the event at the time, and based on your logic then to either consume the event (by returning true), or to allow passing it further by returning false (e.g. not consuming it)
Beyond that there's actually no further funcionality to those.

The idea behind those listeners was to provide a way to act on a click event before it is passed along to inner functions of the library. E.g. prevent behaviour of the select or expandable extensions.
Similar to the other listeners you have the possibility to do something with the event at the time, and based on your logic then to either consume the event (by returning true), or to allow passing it further by returning false (e.g. not consuming it)
Beyond that there's actually no further funcionality to those.

That's exactly what I needed and it was there all this time... Thanks for the info !

That's exactly what I needed and it was there all this time... Thanks for the info !


Support ACH in Gift Entry Batch

Critical Changes
Changes
We enabled ACH in Gift Entry Batch mode.
Issues Closed
Community Ideas Delivered
Features Intended for Future Release
Features for Elevate Customers
New Metadata
Deleted Metadata

Tracking W-11831824

@lparrott @voduyemi @daniel-fuller Tagged all three of you as reviewers for this item. It includes some commits from #7105 and #7104. Added everything here to enable end to end testing.


FCS_VAL_EXT change

In #26 you moved the entire requirement to selection based, but I think what really needs to happen (thinking about it now), is that FCS_VAL_EXT.1.3 should become a new, separate requirement.
FCS_VAL_EXT.1.1/2 are both about the validation of keys before being used, how it is protected and that it must be done before being used. Since this covers most of the KEKs and the FEKs, it would seem that these should be mandatory. I don't know if all FEKs could be derived from something passed from the platform, it would seem that the platform would hand off a "master key" to protect FEKs or some sort of intermediate KEKs, and at that point, any KEKs or FEKs should be protected and validated according to 1/2 here.
But if the platform is performing the authorization, then FCS_VAL_EXT.1.3 potentially becomes a problem because this is basically what to do when there is a failed login. Looking at the MDFPP, the outcome for failed authentication is handled by FIA_AFL_EXT.1, which is very long and has requirements not relevant here, but my point being that failed authorization is handled in a separate requirement.
I would do the following:

FCS_VAL_EXT.1 Validation -> FCS_VAL_EXT.1 Key Validation
FCS_VAL_EXT.1.3 -> FCS_VAL_EXT.2 Validation Failure
FCS_VAL_EXT.2.1 = FCS_VAL_EXT.1.3 (so the requirement itself doesn't change)

The EA for the new FCS_VAL_EXT.1 would be a description in the TSS about how the keys are validated (which is the current TSS description part of the EA). There would be no tests associated here and likely no guidance requirement.
The existing guidance and testing portions of the EA would become the EA for FCS_VAL_EXT.2 with a new section on the TSS to review the description about how the TOE determines and maintains a count for unsuccessful validations and the actions that are taken.

The new FCS_VAL_EXT.1 could be either selection or mandatory, but I think it should be mandatory with a note that if the platform is doing verification of the user credentials that a key protected by the platform may not be included in the TOE-protected keys (and that this should be clearly described).

I am thinking that is adding a fair bit of compexity for the value is provides.  I agree that we could seperate remediation out, but I think if the platform is handling the auth you are also going to having it handle the validation and remediation.
For the detail on protected keys, I agree platform performing these functions means the potential for platform key storage.  I think the most appropriate place to note that is in the KYC and KYP requirements.

So the question is about the validation. If you are supposed to validate all the keys (which is what I would assume), then the platform is likely to only verify one of them, not all of them. Here is an example of what I am thinking of:
Password -> KDF -> protect a root FE key (i.e. a root KEK) -> folder KEK -> FEK
Here the password is run through a KDF and the result is used to encrypt the root KEK. The root KEK is then used to encrypt the folder KEKs (say one for each separate folder) which is then used to encrypt the FEKs. Obviously I'm simplifying here a little, there would be other data involved (tweaks, IVs, maybe even hardware keys, but this should suffice).
If the software implements its own authentication service, then all this is handled by the software, and it is fine. The password will be validated by the software as should all the rest of the keys in the hierarchy.
In the case I'm talking about though, the authentication service is provided by the platform (say a Windows Hello login or the Android lock screen). Here the OS validates the password (or smart card, whatever is being used). The OS then passes a secret on to the application. This can be the password, it would be some other key, something that is associated with the user (for example the software could have established something where-in when the user authenticates it unlocks some string/key that is provided as input to the app) what it is doesn't really matter). The key point here though is that the OS has performed the validation of the user, and only then does it pass the secret on. So the application never needs to validate the user authentication input because it only gets input on success.
Further down though, the KEKs and the FEKS, I read the requirement as intended for the application to perform validation of the keys in some way to ensure they are correct. For example a key wrap or AES-GCM (something in FCS_COP.1(5)), and that this must be done when those keys are unwrapped to ensure they haven't been tampered with (or just corrupted). At this point the OS is no longer directly involved, the key storage at this level is up to the application, so the KEKs and FEKs need to be validated by the application.
So I don't see how the KEKs and FEKs can rely on the OS like you can for the authentication data, and it would seem to me that they are mandatory for the application. So an application that relies on the OS to provide authentication basically doesn't have to validate the keys that are stored, which is how I see this being selected (or not) in practice.

Reading this over and thinking about it some more, the real goal is not validation of all keys.  The goal is that validation is expected to happen somewhere and when it does we need to make sure it is done in an acceptable way.  I would expect most products to just rely on platform to do this check, but in cases where they may also implement something to ensure what they receive from that platform is valid the requirement should reflect that.
So upon further reflection I concur with your recommendation.

Updated requirements, if any other concerns with the requirement please indicate them now.

This looks good to me. Not exactly how I thought you would do it, but it looks good, so I don't see any issues with this update.


⚠ Fetchers has degraded performance

In 4ea39a0, Fetchers ($STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 262 ms

Resolved: Fetchers performance has improved in fcefe3b.


Is it possible to use different tokens to pay gas fee for the different runtimes?

I now have a runtime related to a web app, I want to pay the gas fee for my users. I am thinking to drop some gas fee to users, but I don't want the user to use that token to pay for other extrinsics. Is it possible to use the different tokens to pay the gas fee for the different runtimes or even for the different methods?
I don't mean in the recent versions, just want to see in the future, technically, whether that is possible.

Hey! Yeah, technically I think that's possible, although there are some caveats.
Gas is actually the same as weight, therefore the issue boils down to a custom way of buying weight. Then, we used to have a mechanism called ext_dispatch_call that allowed a contract to use its gas as weight to call into the host runtime - it would have given a headache, but now we don't have it in favor of a more opt-in approach #6466 - chain extensions. So calling back into the runtime shouldn't be a problem as well.


Add button to stop/restart watch

The lib node-tail tail enables to start/stop watch:
tail.watch();

tail.unwatch();

It's very good for many logs in little time when necessary analyse the log, so watch stop and after, start watch again.
It would be interesting to add this feature in this project as well.
I have an application that generates many logs.

Hey @webjoel
are you referring to https://www.npmjs.com/package/node-tail?

@mthenw Yeap!
Suggestion:
1 - Use this lib I quoted;
2 - Create the similar feature in this project;

I've been thinking about switching to this library (which also means supporting Windows OS) but there is no way to set an initial number of lines. Not sure how it will perform. I need to test it.

I understand, meanwhile, in the current implementation, is it possible to add this stop and continue feature?

Technically it's possible, but I'm probably not able to spend time on that. Are you interested in contributing?

Okay, I'll try to develop.


Feat/favourites

A bit laggy currently. The favourite state could be saved in some way else, because if you favourite something in modal window, it doesn't show instantly in event list

I think this is fine at this point, we can refine that state later :)

Though two things:
I didn't notice any alt text or anything for accessibility. Should be something like "Lisää [TAPAHTUMA] suosikiksi" / "Poista [TAPAHTUMA] suosikeista" or something, but also on Storyblok for the English translation!

@noorapunamaki Added aria-labels and also fixed the case where the favourites did not work in English ":D"


Add About Page E2E tests

Description
Main change is addition of aboutpage.cy.ts to add some basic About page tests. There are basic tests for each of the 3 major sections/components (About Header, About Banner, and About Details). The page doesn't really have functionality so this is more of a "render" test suite.
I also modified a couple of components to include data-cy attributes to more reliably identify key elements.
Related Issue
#129, #130, #158 - This PR provides E2E tests, rather than component tests, for these issues.
Motivation and Context
Provides feature coverage for About page and its sub-components. The E2E tests in this PR may suffice in place of component tests though perhaps if components get configurable options, then component tests would also be warranted. Open to feedback on which approach (E2E or component or both) would be preferred.
How Has This Been Tested?
Run in Cypress app using Chrome browser

Thanks @dgodongm, I'll check this out in the next few days!

@marktnoonan @chadstewart Gentle ping to see if you might have a chance to take a look this week.

thanks @dgodongm and apologies for my slow response!

@dgodongm thanks for adding these tests! I'm going to roll through the tickets and check if all expected tests exist:
https://github.com/TechIsHiring/techishiring-website/issues/129

[x] Tests if the About page banner renders properly
[x] Tests if the 'Ask questions section' renders properly and the button opens your email (outdated requirement, current behavior navigate to Contact page)
[ ] Tests if the 'Find us on Social Media' component renders properly and links to the proper social media -- this is not tested yet, the viewport of the test needs to be increased to show this section of the component

https://github.com/TechIsHiring/techishiring-website/issues/130

[x] Test if the About Page content renders properly - since all this does is render 3 other components, it's covered since the tests cover the 3 other components

https://github.com/TechIsHiring/techishiring-website/issues/158

[x] an article element is used for the content
[-] Twitter, LinkedIn, and YouTube links exist (see cy.validateLink())
[ ] Anything else you can think of that is important, but we don't need to verify all of the text content since it's fine for text content to change without failing a test.

I'll make some comments inline the PR with suggestions of how we might make the tests a bit more specific.
I think there are good reasons to move some of this coverage to component tests, since I see e2e tests as higher level "journey" type tests, and component tests as more specific detail-oriented tests of the behavior, but in this situation there's no need to block on that or ask you to redo work - let's get this coverage merged in e2e and then we can move it around as needed.

@marktnoonan I made a pass at addressing your feedback. Let me know what you think. cc @chadstewart

@marktnoonan checking back on if the feedback revisions look ok

@marktnoonan Friendly nudge on this


langchain:Update the internal chat messages history

Description: prune() just remove the messages in memory, but not the messages stored in the internal chat messages history object. This lead to the problem that load_memory_variables() return a dictionary with all the messages in the history item.
Issue: add code to remove the old messages exceed token limit.
Dependencies: none.
Twitter handle: @meebox

The ConversationTokenBufferMemory class has the same problem.

There's no any method for the BaseChatMessageHistory instance to update the messages except for clear and add_messages. Maybe adding a delete method could do the work.


Add WolvicBrowserContext java class

This patch adds WolvicBrowserContext java class that is an wrapper that allows passing WolvicBrowserContext reference around in the Java layer. It has an interface to get BrowserContextHandle interface that provides a pointer to a native BrowserContext, and can be used to by components to take a BrowserContext reference within Java code.

Could you comment on which uses cases would this patch help to implement? It's unclear to me

It's needed to set the first parameter, BrowserContextHandle in InstalledAppProviderImpl to implement InstalledAppProvider.
https://github.com/Igalia/wolvic-chromium/blob/wolvic/components/installedapp/android/java/src/org/chromium/components/installedapp/InstalledAppProviderImpl.java#L94
Also, some components requires BrowserContextHandle wrapped the native BrowserContext.


stata 贝叶斯

贝叶斯 = bayesian, right? We need more info to keep this issue open.

Well, I don't understand it, so it probably is bayesian.

Closed as it is not clear what the issue is. :)


Double orders when switching to v4.1.3 or v4.2.0

Expected behavior
No double orders when activating Mollie v4.1.3 or v4.2.0
Actual behavior
Double orders when either v4.1.3 or v4.2.0 is activated
Steps to reproduce the behavior
Disabled Mollie v4.x and reinstalled v3.5.5
Details
Our customer store was running on Presta <IP_ADDRESS> and Mollie v3.5.5
We upgrade store (on dev location too) from <IP_ADDRESS> to <IP_ADDRESS>
After updating Mollie module from v3.5.5 to v4.1.3 we noticed a lot of double orders being displayed
We deleted Mollie completely (including checking left overs in DB tables ps_module and ps_hook_module)
Reinstalled Mollie module but this time v4.2.0, reconfigured whole module because settings were gone
Again we see double orders
Deleted Mollie completely again, and reinstalled Mollie v3.5.5, double orders are gone.
Check my screenshots.

Hello, and thank you for your message!
I will check with the development team regarding this report, and will get back to you as soon as possible!
Thank you for your patience.
--
Best regards,
Invertus Support team

Hello, and thank you for your message!
I will check with the development team regarding this report, and will get back to you as soon as possible!
Thank you for your patience.
--
Best regards,
Invertus Support team

Hi @Saimis777,
Thanks for your quick reply.
A duplicated ID is something that physically should not be possible (database should not allow a duplicate ID), maybe just some display error...

Hi @Saimis777,
Thanks for your quick reply.
A duplicated ID is something that physically should not be possible (database should not allow a duplicate ID), maybe just some display error...

@RVanDamage hey again,
Would you be able to send us front/back office/FTP details to<EMAIL_ADDRESS>for further investigation? Or more information about the issue? As without further details we can't really determine what the issue is, as we didn't have this issue before.
Looking forward to your reply!
--
Best regards,
Invertus Support team

@RVanDamage hey again,
Would you be able to send us front/back office/FTP details to<EMAIL_ADDRESS>for further investigation? Or more information about the issue? As without further details we can't really determine what the issue is, as we didn't have this issue before.
Looking forward to your reply!
--
Best regards,
Invertus Support team

Hi @Saimis777,
Thanks, I just send them the credentials  (front/back office/FTP) for one of our dev environments.
Already enabled the Mollie module, so they should see those order duplicates.
As soon Mollie module is disabled (try it) the order duplicates are gone.

Hi @Saimis777,
Thanks, I just send them the credentials  (front/back office/FTP) for one of our dev environments.
Already enabled the Mollie module, so they should see those order duplicates.
As soon Mollie module is disabled (try it) the order duplicates are gone.

Thank you, I've received your email.
Will update you regarding the process!
--
Best regards,
Invertus Support team

Thank you, I've received your email.
Will update you regarding the process!
--
Best regards,
Invertus Support team

@RVanDamage
One of the main reasons we refactored how order is create because of the reason that a lot of merchants just like in this case likes to change order_reference logic, and because a lot of orders were canceled and they ask mollie for order reference before they can create payment they got duplicated, as you can see in the image after using 3.3.5 module it finds more then 1 order_reference that has the same reference, this shouldn’t happen with new orders when using new 4.2.1 version, but the old ones will show it because they were created using 3.3.5 module, you could delete them from mollie_payment table where order_id is empty if you don't want to see them.

The fix for this issue will be released in 4.3.0 version, but if you want, you can currently change - mollie.php line : 1009
Change this code:
if (isset($params['join'])) {
$params['join'] .= ' LEFT JOIN ' . _DB_PREFIX_ . 'mollie_payments mol ON mol.order_reference = a.reference
AND mol.cart_id = a.id_cart';
}
To this:
if (isset($params['join'])) {
$params['join'] .= ' LEFT JOIN ' . _DB_PREFIX_ . 'mollie_payments mol ON mol.order_reference = a.reference
AND mol.cart_id = a.id_cart AND mol.order_id > 0';
}
Let me know if you need any other assistance!
--
Best regards,
Invertus Support team

@RVanDamage
One of the main reasons we refactored how order is create because of the reason that a lot of merchants just like in this case likes to change order_reference logic, and because a lot of orders were canceled and they ask mollie for order reference before they can create payment they got duplicated, as you can see in the image after using 3.3.5 module it finds more then 1 order_reference that has the same reference, this shouldn’t happen with new orders when using new 4.2.1 version, but the old ones will show it because they were created using 3.3.5 module, you could delete them from mollie_payment table where order_id is empty if you don't want to see them.

The fix for this issue will be released in 4.3.0 version, but if you want, you can currently change - mollie.php line : 1009
Change this code:
if (isset($params['join'])) {
$params['join'] .= ' LEFT JOIN ' . _DB_PREFIX_ . 'mollie_payments mol ON mol.order_reference = a.reference
AND mol.cart_id = a.id_cart';
}
To this:
if (isset($params['join'])) {
$params['join'] .= ' LEFT JOIN ' . _DB_PREFIX_ . 'mollie_payments mol ON mol.order_reference = a.reference
AND mol.cart_id = a.id_cart AND mol.order_id > 0';
}
Let me know if you need any other assistance!
--
Best regards,
Invertus Support team

Hello,
As this issue was provided with a solution, and the fix will be released in 4.3.0 version, I will close this issue.
Please let me know if you will encounter any further issues or bugs, we are here to help!
--
Best regards,
Invertus Support team

Hello,
As this issue was provided with a solution, and the fix will be released in 4.3.0 version, I will close this issue.
Please let me know if you will encounter any further issues or bugs, we are here to help!
--
Best regards,
Invertus Support team