Payloads MUST be hashed using a cryptographic hash function

You should not be able to sign non hashed payloads
payloads MUST be hashed using a cryptographic hash function as part of the ECDSA spec.
Some Crypto library API's, expected hashed strings so that implementors can choose which hash function to use in their cryptosystem
Allowing developers to misuse hash functions in our library is dangerous, and not inline with defensible code practices.
XMTP sdks should only expose functions which expect raw strings
XMTPv2 uses two different hashing functions, so explicit functions should be created to ensure that developers never invoke sign on unhashed data
Even though the underlying library prevents this in android this function  https://github.com/xmtp/xmtp-android/blob/main/library/src/main/java/org/xmtp/android/library/messages/PrivateKey.kt#L80-L95 needs to explicitly disallow being called without a hashed payload.

Hey @nplasterer  , I would like to pick this up. I'm a native android dev, have been away from open source for a year or so but looking to become active again.
I've set up the codebase locally and gone through some of your documentation/youtube videos to understand what the project is about. I'm ready to open my first PR here, but these two statements seem conflicting to me:

" Allowing developers to misuse hash functions in our library is dangerous, and not inline with defensible code practices. XMTP sdks should only expose functions which expect raw strings"

vs.

" https://github.com/xmtp/xmtp-android/blob/main/library/src/main/java/org/xmtp/android/library/messages/PrivateKey.kt#L80-L95 needs to explicitly disallow being called without a hashed payload."

If we expect devs to provide a raw string, it is naturally going to be unhashed. We wouldn't want to disallow that, right?
My understanding is that we should expect the user to provide a raw string, and the method should hash it internally. Reasoning:

Much smaller change surface. We can just flip the needToHash boolean to true. We can guarantee that the string will be hashed with a secure algo, which is SHA3 in this case.
Afaik, we can't practically disntinguish between hashed and unhashed strings in order to disallow the unhashed ones. Even if we did, we can not guarantee that the hashing algo the dev used meets the desired security standards.

WDYT? Please let me know if I am missing out on something.

@codingtosh that sounds great. I think on the surface the change is simple but it will be a bit more complicated. The sign function should really be internal and not used externally. Any place internally we call sign now will have to be modified. This will be a breaking change for any developers who might be calling it directly as well. I think diving in the direction you outlined sounds great. The test coverage should let you know if any issues arise. Ping me on the PR whenever you have it open!

@codingtosh that sounds great. I think on the surface the change is simple but it will be a bit more complicated. The sign function should really be internal and not used externally. Any place internally we call sign now will have to be modified. This will be a breaking change for any developers who might be calling it directly as well. I think diving in the direction you outlined sounds great. The test coverage should let you know if any issues arise. Ping me on the PR whenever you have it open!

My thought is to avoid introducing a breaking change immediately. Instead, I suggest we create a new function that follows the discussed specifications earlier. Alongside this, we can mark the existing function with an @deprecated annotation. This approach should allow for a smoother transition without immediately breaking code for the devs. What do you think? I will give this a try and open up a PR soon.

@cdhiraj40 That sounds great. Agree deprecating it in advance would give the best experience. 👍


Check existence of ANCMV2 Path

By creating a new global module for ANCM (aspnetcorev2.dll), we need the IISExpressDeployer to be able to change the ANCMPath. The issue is, the ANCMPath is hard coded to aspnetcore.dll, meaning we cannot use it for aspnetcorev2.dll. Also, it is hard to modify it outside of the deployer because the temporary file and folder location is done on DotnetPublish(), which is called on DeployAsync().
There are a few other ways I can make this fix (ex: creating a property that is the aspnetcore dll to replace ANCMPath), but this seemed like the simplest for now.

Which one are we going to put into web.configs of test apps?

@pakrym here was my original intention with this change.
For ANCMV1, the web.config file would contain the attribute handler="AspNetCoreModule" and for ANCMV2 it would be handler="AspNetCoreModuleV2". ANCM V1 will only use aspnetcore.dll and ANCM V2 will only use aspnetcorev2.dll.
The drawback with this approach is we need to duplicate sites for V1 and V2. However, I'd rather test V2 with the changed dll names as it will be a likely breaking point.


Server Error when trying to update a deployment in TOST Campaign

Describe the bug
When doing curation for the TOST campaign, I ran into an issue. I had been trying to adjust the spatial bounds of the campaign's first deployment (TOST_dep_2003_spring) and eventually was unable to save again, instead being directed to a server error 500 page. This first happened on Wednesday morning (3/20) and has persisted when I try to click to edit the deployment again. I had saved a few times before in order to adjust the boundary box correctly, so maybe that messed something up. Deleted cookies and restarted browser but did not solve issue for me.
To Reproduce
Steps to reproduce the behavior:

Go to TOST campaign and click "Details" tab
Click "edit" for the TOST_dep_2003_spring campaign
Get Server Error 500 page

Expected behavior
I expected the MI to save my progress without error and update the boundary box for the deployment accordingly.
Screenshots

Desktop (please complete the following information):

OS: Windows
Browser: Chrome
Version: Windows 10 Enterprise; Chrome Version 122.0.6261.129

Additional context
I'm not sure if this is just a problem on my end or if this issue will affect the reviewers of the campaign, too.

@heidimok Hey Heidi, I submitted this but it's nothing urgent. Just leaving a note here to make you aware. Please let me know if this is something I can fix easily on my end and I'm overlooking something. Thank you!

Thanks for submitting it @bcr1578. I'll check it out and see if we can bring it into our next sprint depending on the capacity of developers.

Thank you for digging into the problem @Tammo-Feldmann
Can we do something like this?

Help curators understand what the constraints are

Add helper text to define specifications required for spatial bounds

Guard more closely against spatial bound inputs that can't be parsed

When validating or saving, we show red error message under the component, similar to what is currently in place in other areas like

The conclusion here is:

The spatial bounds is what cause the error
The correct format is min Longitude, min Latitude, max Longitude, max Latitude
Validate before saving

I will close and create a new issue in the backlog specific to adding helper text on spatial bounds and do a validation to check that the first Longitude is smaller than the second, and the same for the Latitude so that it's more clear for the future.


[BEAM-2052] Cherrypick #3023 and #3059 to release-2.0.0

#3023 implements the functionality, #3059 fixes the build breakage :-|
R: @davorbonaci OR @dhalperi

LGTM as an accurate cherry-pick of those two PRs. Merging.

Merged, close at your leisure :)


FIX CMAKE_WINDOWS_GPU workflow

Fixes #4440
one step of enable windows cuda tests.
Add environment variables for installed cuda binaries.
update VS integration directory.
It's extracted from https://github.com/pytorch/vision/pull/4435.
@NicolasHug, could you take a loot at those failed test cases in #4435 . Could I disable them when I submit the next PRs.
@malfet @NicolasHug
What's the PR's impact?
In fact, the current CMAKE_WINDOWS_GPU result is incorrect.
For example.
Though https://github.com/pytorch/vision/pull/4412 passed all tests, From CMAKE_WINDOWS_GPU log.
https://circleci.com/api/v1.1/project/github/pytorch/vision/796642/output/103/0?file=true&allocation-id=6143fcff7205b60efcdd62e4-0-build%2F6F92D232

We could find it is compiled with 10.1 runtime not the specified 10.2 runtime

update VS integration in cuda_install.bat could be splitted. see https://github.com/pytorch/vision/pull/4420

I don't understand why cuda_install.bat needs to be changed now, but will delete it in followup PR

@malfet
I tried remove the VS integration. but there's the error
https://app.circleci.com/pipelines/github/pytorch/vision/10546/workflows/c37675ed-5ca4-450a-8199-0b75d68f44e6/jobs/801044


Is there really a need to make your own postgres image?

Hello @waprin, thanks for making this project. I have encountered some issues making my own test project on minikube for Django and looking for solutions I found yours.
You make your own postgres image:
https://github.com/waprin/kubernetes_django_postgres_redis/blob/master/kubernetes_configs/postgres/postgres_image/Dockerfile
But as described on https://hub.docker.com/_/postgres/, you could set those environment variables with no need of making your own image:
apiVersion: v1
kind: Service
metadata:
  name: postgres-master
  labels:
    app: postgres
    tier: backend
    role: master
spec:
  selector:
    app: postgres
    tier: backend
    role: master
  ports:
    - port: 5432
      targetPort: 5432
  clusterIP: None
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: postgres-data
spec:
  accessModes:
    - ReadWriteOnce
  capacity:
    storage: 1Gi
  hostPath:
    path: /data/postgres-data/
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgresdata-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
---
apiVersion: v1
kind: Secret
metadata:
  name: postgres-secret
type: Opaque
data:
  username: dGVzdGluZwo=
  password: dGVzdGluZwo=
  database: dGVzdGluZwo=
---
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: postgres-master
spec:
  replicas: 1
  progressDeadlineSeconds: 600
  minReadySeconds: 15
  revisionHistoryLimit: 5
  template:
    metadata:
      labels:
        app: postgres
        role: master
        tier: backend
    spec:
      containers:
      - image: postgres:9.6-alpine
        imagePullPolicy: "IfNotPresent"
        name: master
        env:
        - name: PGDATA
          value: /var/lib/postgresql/data/pgdata
        - name: POSTGRES_USER
          valueFrom:
            secretKeyRef:
              name: postgres-secret
              key: username
        - name: POSTGRES_PASSWORD
          valueFrom:
            secretKeyRef:
              name: postgres-secret
              key: password
        - name: POSTGRES_DB
          valueFrom:
            secretKeyRef:
              name: postgres-secret
              key: database
        ports:
        - containerPort: 5432
          name: postgres-master
        volumeMounts:
        - name: postgres-data
          mountPath: "/var/lib/postgresql/data"
      volumes:
        - name: postgres-data
          persistentVolumeClaim:
            claimName: postgresdata-claim

What are your thoughts on this? Thanks again.

Yep it was probably a mistake, need to take another pass at this repo.

To whoever inspired be the snippet above, please note that 'dGVzdGluZwo=' is a base64 version of 'testing\n', not 'testing'. Don't get a bite. :-)


iris.plot docstrings: separate arg types from descriptions

🚀 Pull Request
Description
Resolves #4085.  Docstrings now show arguments' types on the line above their description, so they render sensibly in readthedocs.

Consult Iris pull request check list

Linkcheck failures appear to be genuine 404's 🙁
https://matthew-brett.github.com/pydagogue/gh_delete_master.html
https://readthedocs.org/dashboard/scitools-iris/version/v3.0.0rc0/

Waiting on #4104.

@trexfeathers ready to go 😁


Install Iter8 as part of ODH Installation

Iter8 should be installed as part of ODH
This includes documentation of the dependency on Service Mesh,
In the sort term, documentation on service mesh installation and configuration.

work to be done here: PR https://github.com/opendatahub-io/odh-manifests/pull/909

This repo is only for ODH core projects. Correct location is https://github.com/opendatahub-io-contrib/odh-contrib-manifests. PR is https://github.com/opendatahub-io-contrib/odh-contrib-manifests/pull/5.

This is only for the v1 ODH operator. The operator is being revenvisioned. See blog article and design document. See also this slack conversation.
Component integration guide

done in https://github.com/opendatahub-io-contrib/odh-contrib-manifests/tree/main/iter8


OTP

When copying otp to clipboard it copies the security key. On small size screens otp won't show

It was fixed


GUI Relationship filters

The GUI currently does not support the input of relationship filters {and} and {or}, however or can be made using individual filters.

Now shows relationship filters but they cant be added in the GUI


Sets task.run to None instead of NotImplemented in ExternalTasks

Using NotImplemented prevents externalized tasks from being pickled, preventing
the use of parallel scheduling due to pickle being the serializer used in
multiprocessing. This uses the picklable None instead, resolving #1608

This makes senses to me.

Thank you :)


Cost Estimate per App in the Lightning App Gallery

🚀 Feature
Could we have a cost estimate per app in the Lightning App Gallery? This could be based on the default compute option the app currently uses to a user understands how much of their credit is consumed (Est Credits / Day) once they hit the clone & run button.
Motivation
Currently, before using Clone & run from an app page, users only have a vague idea of consumption from the pricing page, or after they run the app they can monitor consumption from the Compute tab under their app page. We also see users from the community who've frequently used up their free credits as they were unaware of how many credits an app from the gallery needs to run for a couple of hours, a day, or a month. This will help them use their credits more wisely.
Pitch
Near the Clone & Run button for the app, users should be able to see a Cost Estimate to run this app in the account with the default compute option.
Alternatives

As an alternative, users can be directed to where they can change the compute option for the app, to select either a cost-effective option or a high-performance option.

A more comprehensive calculator for the site could allow the user to calculate costs for using multiple apps & components. I've added some sample images as references below.

Additional context

cc @borda

cc @edenafek


Customize login view response

Hello,
how can I customize the response of the login view so that it returns the token and also the id of the logged in user?

did you figure out a solution? im also looking for a way to return more info about the user

Create custom view that inherits LoginView
from rest_auth.registration.views import LoginView

...

class LoginViewCustom(LoginView):
    authentication_classes = (TokenAuthentication,)

    def post(self, request, *args, **kwargs):
        response = super().post(request, *args, **kwargs)

        user_serializer_data = UserSerializer(self.user, context={'request': request})
        aaa = {'user': user_serializer_data.data}
        aaa.update(response.data)

        return Response(aaa)

Ohh, thanks!
That works for me.

It's working fine. Great work.

It's working fine. Great work.


Minimize set of loader options considered for stress test matrix

This PR removes most of the loader configurations from the stress test, many of which were obsolete/deprecated/had no effect.  Also switches over to the recommended non-deprecated ILoaderOptions from container-definitions instead of container-loader.
Since generatePairwiseOptions doesn't generate every combination, eliminating noise from the options matrix seems like generally a good practice.  This makes it more likely we'll get interesting combos with 3+ properties (though in this case we don't really have that many interesting properties left).
A quick survey of their current state in main:
cache: booleanCases, // Loader hasn't supported caching in a while, has no effect
client: [undefined],
provideScopeLoader: booleanCases, // Doesn't actually have any meaningful effect
maxClientLeaveWaitTime: numberCases, // numberCases === [undefined], not sure why we export this really
summarizeProtocolTree: [undefined],
enableOfflineLoad: booleanCases, // Deprecated (in favor of using MC), but can technically still have an effect
enableOfflineSnapshotRefresh: booleanCases, // Has no effect, only controllable via MC
snapshotRefreshTimeoutMs: [undefined, 60 * 5 * 1000 /* 5min */], // Has no effect, only controllable via MC

AB#12911

Reasoning seems fine to me. But I'd definitely wait for @anthony-murphy or @dannimad's input though, since the experimental options were added pretty recently. If it was an oversight adding them to stress tests because they don't actually have any effect, off with them; but if that was a bug and they should be exercised, we might want a different version of this change.

@dannimad Based on my read, these settings would need to be in a new config matrix for generateConfigurations rather than generateLoaderOptions.  Currently there's no default matrix (only overrides), but you could add one if you want.

i don't believe we should not test things that are deprecated. many of our deprecations are false, and are still in active use, so we should continue to test them. When the work is done to actually remove the deprecated thing these will get removed as well.

Of the settings currently under test, enableOfflineLoad is the only deprecated one that still actually does anything - this one I left unchanged for that reason.  Happy to have a conversation about any of the other settings though, which ones are you interested in?

i don't believe we should not test things that are deprecated. many of our deprecations are false, and are still in active use, so we should continue to test them. When the work is done to actually remove the deprecated thing these will get removed as well.

Of the settings currently under test, enableOfflineLoad is the only deprecated one that still actually does anything - this one I left unchanged for that reason. Happy to have a conversation about any of the other settings though, which ones are you interested in?

I'm not particularly interested in any of them, i just don't think deprecation is a signal that its safe to do anything in generally. I'd rather see work don't to clean up the deprecation completely, rather than piecemeal removal, which can introduce bugs if we get something wrong.

Reasoning seems fine to me. But I'd definitely wait for @anthony-murphy or @dannimad's input though, since the experimental options were added pretty recently. If it was an oversight adding them to stress tests because they don't actually have any effect, off with them; but if that was a bug and they should be exercised, we might want a different version of this change.

@dannimad Based on my read, these settings would need to be in a new config matrix for generateConfigurations rather than generateLoaderOptions. Currently there's no default matrix (only overrides), but you could add one if you want.

Verified that these options currently have no effect.  Pushed one last commit to demonstrate the potential fix if you're interested @dannimad, verified it works as expected.  Closing per @anthony-murphy 's request.


Add lookupSRV function.

Adds support for fetching SRV records and using them in a template. Would go great in conjunction with https://github.com/kelseyhightower/confd/pull/333

@jburnham Now that #333 has been merged, this will need a rebase. I think we really need to figure out a better way of adding template functions.

Rebased, It looks like the failing test is because of the lookupIP function. TravisCI seems to not have ipv6 so resolving localhost is only <IP_ADDRESS>.

@jburnham Seems there is still a conflict. I fixed a bunch of test so things should be all green now.

Rebased again.

@jburnham Thanks!


Update node

https://github.com/AcalaNetwork/hardhat-tutorials/pull/44
https://github.com/AcalaNetwork/waffle-tutorials/pull/11

let's merge https://github.com/AcalaNetwork/hardhat-tutorials/pull/44 first, and update the bodhi reference to master, so further update on hardhat-tutorials can be based on master and won't diverge


CupertinoPicker

I use 5 Cupertinopickers on this dialog, when I quickly scroll any one of them for a while, it will get stuck. and I found that when it got stuck, its rendering time became huge.
Although I have commented out any processing and refreshing of the page in onSelectedItemChanged.
How can I solve this problem?

I use 5 Cupertinopickers on this dialog,

@bbaiqiang I am wondering why do you have these many on a single dialog ? I am not sure if this implementation is correct according to design principles.
Coming back to your issue, can you provide flutter doctor -v, along with a complete minimal reproducible code sample that shows the reported behavior ?

@darshankawar thanks for your reply! I want to create some special date picker, so I tried to use multiple Cupertinopickers to achieve.
[✓] Flutter (Channel stable, 3.3.9, on macOS 12.6 21G115 darwin-x64, locale zh-Hans-CN)
    • Flutter version 3.3.9 on channel stable at /Users/bq/Documents/project/test/.flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision b8f7f1f986 (4 weeks ago), 2022-11-23 06:43:51 +0900
    • Engine revision 8f2221fbef
    • Dart version 2.18.5
    • DevTools version 2.15.0
    • Pub download mirror https://pub.flutter-io.cn
    • Flutter download mirror https://storage.flutter-io.cn

Just pop up this sample dialog, and quickly scroll one of the CupertinoPicker for 1-2 minutes, it will get stuck
import 'package:flutter/cupertino.dart';
import 'package:flutter/material.dart';
class TestDialog extends StatefulWidget {
const TestDialog({Key? key}) : super(key: key);
@override
State createState() => _TestDialogState();
}
class _TestDialogState extends State<TestDialog> {
  @override
  Widget build(BuildContext context) => Dialog(
        insetPadding: const EdgeInsets.all(16),
        shape: RoundedRectangleBorder(borderRadius: BorderRadius.circular(24)),
        child: Container(
          padding: const EdgeInsets.all(12),
          height: 160,
          child: Row(
            children: List.generate(
              5,
              (pickerIndex) => Expanded(
                child: CupertinoPicker(
                  itemExtent: 32,
                  magnification: 1.2,
                  onSelectedItemChanged: print,
                  children: List.generate(
                    100,
                    (index) => Container(
                      alignment: Alignment.center,
                      child: Text(
                        '$pickerIndex - $index',
                        style: const TextStyle(
                          fontSize: 14,
                        ),
                      ),
                    ),
                  ),
                ),
              ),
            ),
          ),
        ),
      );
}

I ran the code sample provided on latest master using iOS simulator but was unable to replicate the reported behavior. I scrolled one of the pickers continuously for couple of minutes and it didn't get stuck. Also, other pickers also scrolled smoothly without any issues.

I ran the code sample provided on latest master using iOS simulator but was unable to replicate the reported behavior. I scrolled one of the pickers continuously for couple of minutes and it didn't get stuck. Also, other pickers also scrolled smoothly without any issues.

I ran the flutter upgrade command, it is 3.3.10 now, but the problem persists. It works fine in iOS, this problem happens in macOS desktop app.

I tried the same on latest stable running on macOS desktop, but was unable to replicate the issue.
https://user-images.githubusercontent.com/67046386/208592055-d14df882-6c9e-4007-90c5-2705e7937e7c.mov


Adding Fixes for Date Range on blog

Removed date formatting code from the client. This is now handled in Sheer. The clients responsibility is just validation.
Additions

Added shared object for filterable-list-control.js acceptance test.

Removals

Removed code deal with date formatting code from the client.

Changes

Modified Sheer code to use date parser when date format is mm/dd

Testing

Visit /blog and enter 05/11/2015 in the from date. Click Apply Filters and you should see results.
Enter '05/11' in the from date. Click Apply Filters and you should see results.
Enter '04/fff' in the from date. Click Apply Filters and you should see an error notification.

Review

@anselmbradford
@jimmynotjim
@KimberlyMunoz
@rosskarchner
@kurtw

Screenshots

Notes

There is currently an issue where the Filters aren't remaining expanded when there are active filters on Sheer pages. I will address that issue in a separate PR.

Todos

Add more acceptance tests.

Checklist

[ ] Changes are limited to a single goal (no scope creep)
[ ] Code can be automatically merged (no conflicts)
[ ] Code follows the standards laid out in the front end playbook
[ ] Passes all existing automated tests
[ ] New functions include new tests
[ ] New functions are documented (with a description, list of inputs, and expected output)
[ ] Placeholder code is flagged
[ ] Visually tested in supported browsers and devices
[ ] Project documentation has been updated (including the "Unreleased" section of the CHANGELOG)

Tested and works fine for me :+1:

:+1: Working locally here as well


引数名の変更誤りを訂正

Codecov Report

Merging #22 (b849acd) into master (45b66b4) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master      #22   +/-   ##
=======================================
  Coverage   98.71%   98.71%
=======================================
  Files          12       12
  Lines         311      311
  Branches       40       40
=======================================
  Hits          307      307
  Partials        4        4

Impacted Files
Coverage Δ

src/race_list_factory.ts
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


Columns not starting at y=0

Describe the bug
Hello,
For many reasons, I am considering switching the charting lib I currently use (Kellochart, adapted from Hellochart) to yours. However, I have a requirement to be able to draw charts that contains columns not starting from y=0. For example, I need to draw a column at x=0 between y=2 and y=6. Of what I found, your implementation only allows to make a column from 0 to abs(y)>0... Unless I missed something ? If not "natively" supported, would you suggest a work around? Do you have some similar examples ? Below is a picture of my current view with Kellochart.
Module

[x] compose
[x] views
[ ] compose-m2
[x] compose-m3
[x] core (select if none of the above apply)

To reproduce
N/A
Expected behavior
N/A
Screenshots

Android versions
N/A
Additional context
N/A

Hello! I’m afraid this isn’t supported, but we will be adding such functionality in the future. Unfortunately, I don’t think there’s much in the way of a trick that would enable you to implement something like this, other than creating a custom Chart implementation (possibly an extension of ColumnChart), a custom ChartEntry implementation, and so on.

Hello,
Thanks for the great package. We have the same need for this feature, but with a line chart. Would really appreciate if you could make this enhancement!
Thank you!

Could you elaborate on that, @sprout-apps? While a column in a column chart has two key y values—the top and the bottom—a point in a line chart has only one.

Hey !
I am sorry: I completely forgot to mention that I finally found a way to display columns not starting from 0. The idea is to put 2 different columns one on top of the other.
Let's take a simple example :
• You want a vertical bar / column from y=1 to y=4 at a x= 2
• You create two bars :
• A "back" bar from y=0 to y=4 at a x= 2
• A "top" bar from y=0 to y=1 at a x= 2
• And then add the same background color on the "top" bar
At the end I got what I put in attachment
I hope it'll give ideas to you ;)
—
Lauranne Sins, PhD
LinkedIn.
https://www.linkedin.com/in/laurannesins
E.Mail.
@.***
On Jul 30, 2023, 12:13 PM -0400, Patrick Michalik @.***>, wrote:

Could you elaborate on that, @sprout-apps? While a column in a column chart has two key y values—the top and the bottom—a point in a line chart has only one.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

@patrickmichalik An example in our case would be a baby growth chart. Baby's weight and height don't start with zero, so zero base doesn't work very well for the chart. It ends up with a lot of white space and the actual values don't get spread out as much, so the chart isn't that readable. It's better to start just below the birth value. Let me know if this makes sense. I can attach sample images.

Interesting, @Laul! I’m glad that you’ve found a workaround.


Added a NOIndex property so the plugin is compatible with old SEO Epiphany plugin

I've just added the No Index option so it's compatible with old plugin when we upgrade.
Also usefull to have a no index option

Thank you for this PR. Very very very busy times at the moment so I will have to ask for some more time to review this. Really sorry!

Greet work on this on @mrflo!
I made some small adjustments and also made this configurable on the data type level.
It's now included in the latest release https://github.com/enkelmedia/Umbraco-SeoVisualizer/releases/tag/10.1.0!
Cheers!


Memory is not released, the growth is not stopped.

hello
I am very happy to use it in my application.
But I found it to be a memory leak. I hope you can fix this problem.
I tested chrome and NW (Chromium) on windows7X64.
jquery mousewheel plugin == Version: 3.1.12
Gif:

I've optimized auto-update function in version 3.1.0 so any memory leaks should be gone. If you have time to test it I'll appreciate any feedback :)


Postgres search fixes

This PR contains a couple of fixes for the Postgres search backend. These issues were caused by recent improvements to ranking.

No longer rewrites the whole table when new entries are added
No longer catches indexing errors for the Postgres backend (because when it does, Django crashes anyway)

Merged in b8848ae2f5b2594c2162cee2d76ef92fcc2ed670+parents


[Feature Request] Use certificates to replace Azure AD client secrets

Azure AD recommended approach for private client web apps is to use a certificate instead of a client secret generated by Azure AD.

migrated to 1852463


Functionalize in-place ops

What does this PR do?
Express some in-place binary ops using their out-of-place counterpart with following prims.copy_, e.g. a.add_(b) as prims.copy_(prims.add(a, b), a), then let interpreter functionalize the trace with such ops.
So this does not quite cover #145, nor take aliases into considerations.
As a less than minimal check, I used what follows:
import torch
import thunder

def f(a: torch.Tensor, b: torch.Tensor) -> tuple[torch.Tensor, torch.Tensor]:
    c = torch.exp(a)
    d = torch.tanh(b)
    c += d

    d.div_(a)
    return c, d

def main():
    a, b = [torch.randn((2, 2), device="cuda", requires_grad=True) for _ in range(2)]
    a_, b_ = a.clone().detach(), b.clone().detach()
    jit_f = thunder.jit(f, executors=[thunder.executors.get_torch_executor()])
    c, d = jit_f(a, b)
    c_, d_ = f(a_, b_)
    print(thunder.last_traces(jit_f)[-1])

    torch.testing.assert_close(c, c_)
    torch.testing.assert_close(d, d_)

if __name__ == "__main__":
    main()

and running the snippet gives me
import torch
from thunder.executors.torchex import no_autocast

@torch.no_grad()
@no_autocast
def augmented_forward_fn(a, b):
  # a: "cuda:0 f32[2, 2]"
  # b: "cuda:0 f32[2, 2]"
  t0 = torch.exp(a)  # t0: "cuda:0 f32[2, 2]"
    # t0 = ltorch.exp(a)  # t0: "cuda:0 f32[2, 2]"
      # t0 = prims.exp(a)  # t0: "cuda:0 f32[2, 2]"
  t1 = torch.tanh(b)  # t1: "cuda:0 f32[2, 2]"
    # t1 = ltorch.tanh(b)  # t1: "cuda:0 f32[2, 2]"
      # t1 = prims.tanh(b)  # t1: "cuda:0 f32[2, 2]"
  t2 = torch.add(t0, t1)  # t2: "cuda:0 f32[2, 2]"
    # t2 = ltorch.add(t0, t1, alpha=None)  # t2: "cuda:0 f32[2, 2]"
      # t2 = prims.add(t0, t1)  # t2: "cuda:0 f32[2, 2]"
  t3 = torch.true_divide(t1, a)  # t3: "cuda:0 f32[2, 2]"
    # t3 = ltorch.true_divide(t1, a)  # t3: "cuda:0 f32[2, 2]"
      # t3 = prims.div(t1, a)  # t3: "cuda:0 f32[2, 2]"
  return {'output': (t2, t3), 'flat_args': [a, b], 'flat_output': (t2, t3)}, ((a, t0, t1), ())

Awesome stuff. The fundamental questions I have about this are

Does this give silent errors? What do we do about this
If we do work on #145 (and we want to shortly), how will we manage the transition?

Does this give silent errors? What do we do about this

could you give me some examples of silent errors? I'm not quite following what they would be.

If we do work on Handling inplace through SSA #145 (and we want to shortly), how will we manage the transition?

"the transition" of what? The better coverage by supporting in-place ops?
Anyway I'd like to give it a try as well. I just am not quite clear about what would look better even in the short term

could you give me some examples of silent errors? I'm not quite following what they would be.

Essentially things that rely on aliases (x = thunder.zeros(1, 1); x.diag().fill_(1.0))

"the transition" of what? The better coverage by supporting in-place ops?

So I'm imagining that people will use this as soon as we have it and won't like us to regress on the support for their model.
Relative to #145, I wonder whether this is an alternative long-term solution or whether can we evolve it to a long-term solution or how else this fits into a long-term plan.

I think I'm a little confused. This allows for operations like add_ to appear in traces, and then a pass converts those operations to something like
c = add(a, b)
copy_(a, c)

?
What happens to the copy_ operations?
In general I think we need a design review of how to handle inplace operations before merging PRs related to them.

I think I'm a little confused. This allows for operations like add_ to appear in traces, and then a pass converts those operations to something like
c = add(a, b)
copy_(a, c)

?
What happens to the copy_ operations?
In general I think we need a design review of how to handle inplace operations before merging PRs related to them.

I think @crcrpar is only handling inplace on intermediate that can be functionalized away. Which is already help (i.e. inplace activation in resnet)

The example I was referring to in my comment
import thunder
import torch

val = 5

def foo(flag):
    return flag

mod = torch.nn.modules.BatchNorm2d(4)
#mod.track_running_stats = None
mod.cuda()

jfoo = thunder.jit(mod)

a = torch.randn(2, 4, 5, 5, device="cuda")

print(mod.running_mean)
print(mod.num_batches_tracked)
print(jfoo(a))  # tensor([1.])
print(mod.running_mean)
print(mod.num_batches_tracked)

orig_trace = thunder.last_traces(jfoo)[0]
traces = thunder.last_traces(jfoo)

print(f"===\n{traces=}")

I'm not asking you to necessarily support it in this PR, but we should error out instead of silent wrong result.

If you try to run a batch_norm with your example, you'll notice that num_batches_tracked's update gets functionalized. So that's silent wrong result. We should instead throw a loud error for that case.

To this point, https://github.com/Lightning-AI/lightning-thunder/pull/584/commits/8889120e4542d4ac649b1efb7aa18c71f2a3f34b should be helpful:
import torch
import torch.nn as nn

import thunder

def main():
    num_features = 128
    m = nn.BatchNorm2d(num_features).cuda()
    m_ref = nn.BatchNorm2d(num_features).cuda()
    m_ref.load_state_dict(m.state_dict())
    jm = thunder.jit(m)

    x = torch.randn((4, num_features, 32, 32), device="cuda")
    y: thunder.core.module.ThunderModule = jm(x)
    x_ref = x.clone().detach()
    y_ref = m_ref(x_ref)

    print(thunder.last_traces(jm)[-1])

    torch.testing.assert_close(y, y_ref)

    print(f"{m.num_batches_tracked=}")
    print(f"{jm.get_buffer('num_batches_tracked') = }")

if __name__ == "__main__":
    main()

# Constructed by Delete Last Used (took 0 milliseconds)
import torch
from torch import Tensor
from thunder.executors.torchex import no_autocast

@torch.no_grad()
@no_autocast
def augmented_forward_fn(input, t_bias, t_num_batches_tracked, t_running_mean, t_running_var, t_weight):
  # input: "cuda:0 f32[4, 128, 32, 32]"
  # t_bias: "cuda:0 f32[128]"
  # t_num_batches_tracked: "cuda:0 i64[]"
  # t_running_mean: "cuda:0 f32[128]"
  # t_running_var: "cuda:0 f32[128]"
  # t_weight: "cuda:0 f32[128]"
  t31 = torch.reshape(t_weight, (1, 128, 1, 1))  # t31: "cuda:0 f32[1, 128, 1, 1]"
    # t31 = ltorch.reshape(t_weight, (1, 128, 1, 1))  # t31: "cuda:0 f32[1, 128, 1, 1]"
      # t31 = prims.reshape(t_weight, (1, 128, 1, 1))  # t31: "cuda:0 f32[1, 128, 1, 1]"
  t32 = Tensor.expand(t31, (4, 128, 32, 32))  # t32: "cuda:0 f32[4, 128, 32, 32]"
    # t32 = ltorch.expand(t31, (4, 128, 32, 32))  # t32: "cuda:0 f32[4, 128, 32, 32]"
      # t32 = prims.broadcast_in_dim(t31, (4, 128, 32, 32), (0, 1, 2, 3))  # t32: "cuda:0 f32[4, 128, 32, 32]"
  del t31
  t39 = torch.reshape(t_bias, (1, 128, 1, 1))  # t39: "cuda:0 f32[1, 128, 1, 1]"
    # t39 = ltorch.reshape(t_bias, (1, 128, 1, 1))  # t39: "cuda:0 f32[1, 128, 1, 1]"
      # t39 = prims.reshape(t_bias, (1, 128, 1, 1))  # t39: "cuda:0 f32[1, 128, 1, 1]"
  t40 = Tensor.expand(t39, (4, 128, 32, 32))  # t40: "cuda:0 f32[4, 128, 32, 32]"
    # t40 = ltorch.expand(t39, (4, 128, 32, 32))  # t40: "cuda:0 f32[4, 128, 32, 32]"
      # t40 = prims.broadcast_in_dim(t39, (4, 128, 32, 32), (0, 1, 2, 3))  # t40: "cuda:0 f32[4, 128, 32, 32]"
  del t39
  [t18, t41] = nvFusion0(input, t32, t40, t_num_batches_tracked, t_running_mean, t_running_var)
    # t0 = prims.add(t_num_batches_tracked, 1)  # t0: "cuda:0 i64[]"
    # prims.copy_(t0, t_num_batches_tracked)
    # (t4, t5) = prims.var_mean(input, (0, 2, 3), correction=0)
    # t6 = prims.add(t4, 1e-05)  # t6: "cuda:0 f32[128]"
    # t7 = prims.rsqrt(t6)  # t7: "cuda:0 f32[128]"
    # t8 = prims.reshape(t7, (1, 128, 1, 1))  # t8: "cuda:0 f32[1, 128, 1, 1]"
    # t14 = prims.reshape(t5, (1, 128, 1, 1))  # t14: "cuda:0 f32[1, 128, 1, 1]"
    # t15 = prims.broadcast_in_dim(t14, (4, 128, 32, 32), (0, 1, 2, 3))  # t15: "cuda:0 f32[4, 128, 32, 32]"
    # t16 = prims.sub(input, t15)  # t16: "cuda:0 f32[4, 128, 32, 32]"
    # t17 = prims.broadcast_in_dim(t8, (4, 128, 32, 32), (0, 1, 2, 3))  # t17: "cuda:0 f32[4, 128, 32, 32]"
    # t18 = prims.mul(t16, t17)  # t18: "cuda:0 f32[4, 128, 32, 32]"
    # t19 = prims.mul(0.9, t_running_mean)  # t19: "cuda:0 f32[128]"
    # t20 = prims.mul(0.1, t5)  # t20: "cuda:0 f32[128]"
    # t21 = prims.add(t19, t20)  # t21: "cuda:0 f32[128]"
    # prims.copy_(t21, t_running_mean)
    # t23 = prims.mul(t4, 1.0002442002442002)  # t23: "cuda:0 f32[128]"
    # t25 = prims.mul(0.9, t_running_var)  # t25: "cuda:0 f32[128]"
    # t27 = prims.mul(0.1, t23)  # t27: "cuda:0 f32[128]"
    # t28 = prims.add(t25, t27)  # t28: "cuda:0 f32[128]"
    # prims.copy_(t28, t_running_var)
    # t33 = prims.mul(t18, t32)  # t33: "cuda:0 f32[4, 128, 32, 32]"
    # t41 = prims.add(t33, t40)  # t41: "cuda:0 f32[4, 128, 32, 32]"
  del t32, t40
  return {'output': t41, 'flat_args': [input, t_bias, t_num_batches_tracked, t_running_mean, t_running_var, t_weight], 'flat_output': (t41,)}, ((t18,), ())
m.num_batches_tracked=tensor(1, device='cuda:0')
jm.get_buffer('num_batches_tracked') = tensor(1, device='cuda:0')

I think I'm a little confused. This allows for operations like add_ to appear in traces, and then a pass converts those operations to something like
c = add(a, b)
copy_(a, c)

?
What happens to the copy_ operations?
In general I think we need a design review of how to handle inplace operations before merging PRs related to them.

ltorch.add_(a, b) is expressed with two subsymbols, they are t_something = add(a, b) and copy_(t_something, a) then the latter is removed by functionalization.

What happens to the copy_ operations? (https://github.com/Lightning-AI/lightning-thunder/pull/584#issuecomment-2168185877)

If it's in the user script it's not traced today and it's not traced in this PR. The only way to introduce copy_ is from within Thunder.

According to https://github.com/Lightning-AI/lightning-thunder/pull/584#issuecomment-2169124164 num_batches_tracked of BatchNorm is correctly updated in-place with an nvFuser region. I hope nvFuser's fusion performance is not suddenly destroyed by this. We've got one benchmark case to try it https://github.com/Lightning-AI/lightning-thunder/blob/21a222b180009616a4cc48176958b4506894a330/thunder/benchmarks/targets.py#L199

I now think OpTags.IN_PLACE would not work quite well given that there are some functions that takes inplace as their argument such as torch.relu whose ltorch def is https://github.com/Lightning-AI/lightning-thunder/blob/8309fc015c1ea9d684337cdcf95138524cd8645c/thunder/torch/init.py#L1458-L1462 which I cannot pass this tag separately

I now think OpTags.IN_PLACE would not work quite well given that there are some functions that takes inplace as their argument such as torch.relu whose ltorch def is
https://github.com/Lightning-AI/lightning-thunder/blob/8309fc015c1ea9d684337cdcf95138524cd8645c/thunder/torch/__init__.py#L1458-L1462
which I cannot pass this tag separately

The IN_PLACE tag is used more like a MAYBE_INPLACE in the implementation. Maybe switching to that?

Glorious.


Enumerated Value lists Description written to the ISO 19110 output?

I tried to translate a valid fgdc XML file to ISO 19110 XML and the enumerated values list descriptions were not being created. See file here https://gist.github.com/palmerj/5b04d52307f2a4d7c991759bc8ce77d9

Looks like the FGDC reader is assigning the first overall domain(first domain from first parsed attribute) to each attribute instead of the the first domain assigned to the individual attribute (the mdTranslator and mdJSON spec only support one domain assignment for each attribute).
Will adjust the logic to use the first domain assigned to each individual attribute in FGDC (I would think that having multiple domains assigned to an attribute is more of an edge case, excepting range domains which are handled differently).  Look for the patch in v2.17.1. @palmerj Thanks for reporting this.

Thanks heaps @jlblcc

Just a heads up, but we quite often have multiple domains per attribute.
This may be to account for coded values within a numeric field, resulting
in a range domain and a codeset domain.
On Wed, Nov 6, 2019 at 6:05 PM Josh Bradley<EMAIL_ADDRESS>wrote:

Looks like the FGDC reader is assigning the first overall domain(first
domain from first parsed attribute) to each attribute instead of the the
first domain assigned to the individual attribute (the mdTranslator and
mdJSON spec only support one domain assignment for each attribute).
Will adjust the logic to use the first domain assigned to each individual
attribute in FGDC (I would think that having multiple domains assigned to
an attribute is more of an edge case, excepting range domains which are
handled differently). Look for the patch in v2.17.1. @palmerj
https://github.com/palmerj Thanks for reporting this.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/adiwg/mdTranslator/issues/218?email_source=notifications&email_token=ABPKCL6VAILRSL3FNHXWZTDQSOATFA5CNFSM4JIJ3QJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDIYVMQ#issuecomment-550603442,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABPKCL7ZS3L4NWCCONAOXT3QSOATFANCNFSM4JIJ3QJA
.

@dwalt The FGDC reader handles range domains differently. In fact, they are not interpreted as "domains" at all. The mdJSON schema has the valueRange property which the CSDGM range domains map to. Therefore, if you have a single codeset domain and any number of range domains, you should not lose anything in the translation.

Good to know, thanks for the clarification.
On Fri, Nov 8, 2019 at 10:31 AM Josh Bradley<EMAIL_ADDRESS>wrote:

@dwalt https://github.com/dwalt The FGDC reader handles range domains
differently. In fact, they are not interpreted as "domains" at all. The
mdJSON schema has the valueRange
https://mdtools.adiwg.org/#viewer-page?v=4-0-10-0-8-0-17 property which
the CSDGM range domains map to. Therefore, if you have a single codeset
domain and any number of range domains, you should not lose anything in the
translation.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/adiwg/mdTranslator/issues/218?email_source=notifications&email_token=ABPKCL265KU3XIQ2F7NYGDLQSW46VA5CNFSM4JIJ3QJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDTD6RY#issuecomment-551960391,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABPKCL77EJVISBITHDJNWF3QSW46VANCNFSM4JIJ3QJA
.


FIX django jet integration

Jet expects for jquery to be loaded and fails (from years)
https://github.com/geex-arts/django-jet/issues/148
This fixes the problem

Thanks for this patch, however I don't think that it is a proper solution. If django-jet expects jQuery to be loaded they can always override the template (even by changing a init_function block). Failing tests are also bad symptoms.


dask.dataframe groupby(as_index=False) does nothing

When doing a groupby, the index gets set even when specifying as_index=False. This combined with issue #734 means that groupby has to be the last operation, otherwise we're losing columns.
Also it seems that groupby works fine with multiple columns, even though multiindex are not supported, which doesn't seem very consistent.

Yes, we should at least raise a NotImplementedError here.
Can you give an example of losing columns?

What I mean by losing columns is that once a column becomes the index in dask, I see no way to bring it back as a normal column. If I use set_index(drop=False) that would work, but groupby silently creates an index without giving that option. The example is a little contrived, but hopefully conveys what I'm trying to achieve:
df = pd.DataFrame({'A': [1,1,2,2,3,3], 'B': [1,2,-1, 2, 3, 4]})
df2= df.groupby('A', as_index=False).max()
df3 = df.groupby('B').mean()

In dask, A would be the index of df2, and then I don't see any way to operate on A, which is what I mean by losing columns.

OK, this makes sense to me.  I'm a bit saturated this week but may be able to pick this up next week.  At the very least reset_index should be trivial to add if we don't mind having a non-sensical index (e.g. [0, 1, 2, 3, ... 0, 1, 2, 3, ... 0, 1, 2, 3])

Of course it'd be great if anyone else can pick this up in the meantime.

I can pick this up.

I'm confused by this. What was the approach you had in mind @mrocklin ?

We should probably check keyword arguments in groupby and raise notimplementederrors accordingly.  We should probably also implement reset_index which will just map self._partition_type.reset_index onto the blocks and set divisions = [None] * (self.npartitions + 1)

I don't think I've yet fixed @thrasibule's problem. Wouldn't we have to allow as_index=False I don't know the group by code very well, would this be too hard?

is groupby(..., as_index=False)... equivalent to groupby(...)....reset_index()?

Yes. But the current implementation drops the name of the index, and just calls it 'index'. Which is what pandas does when the index is not named. Fixing this now.

This is kind of tricky to add since we are not tracking the index name like we do columns. I'm still figuring out how to do this.

is this issue still open or the functionality is already available?
please not this stackoverflow question that could really use some clarification in the manner.

@cowlicks

This doesn't appear to be fixed (using dask version 1.1.5, Python 3.7.0). Performing a simple .groupby raises the following:
TypeError: __init__() got an unexpected keyword argument 'as_index'
In dask\dataframe\core.py the DataFrameGroupBy class is constructed and **kwargs are passed. The DataFrameGroupBy class uses the _GroupBy class from, dask\dataframe\groupby.py, as it's base (and I'm assuming uses its constructor as well), however the constructor of _GroupBy is defined as:
class _GroupBy(object):
    def __init__(self, df, by=None, slice=None):

I can see that _GroupBy inherits from object class, but I don't think that helps with accepting kwargs.
If I add **kwargs to the constructor and the meta.groupby I no longer get the error...
[764] def __init__(self, df, by=None, slice=None, **kwargs):
         ...
[797]    self._meta = self.obj._meta.groupby(index_meta, **kwargs)

But the result is exactly the same as if as_index is set to True (default). Can this issue be reopened, or could somebody direct me to the current issue that has absorbed this? I still suspect that this can be fixed by passing the kwargs down through to the right level, but I have yet to get past the obj._meta.groupby() statement.

Thanks @thrasibule .  At this point I recommend raising a new issue with a minimal reproducible example, if you have the time.


Turning polyg_19 inactive

Creating a non .py file to avoid build failures while exploring options for making code less massive/resource intensive

@michaelavs The following links show similar discussions about having Hawaii and Alaska near CONUS in a cartopy map. They are also iterating through shape files of the states but using different plotting methods than what we already used in this function. The packages and functions may be of help to reduce the running time of the current implementation.


Fix paths for tick.png and cross.png

Fix couple of trivial img src paths.

Thanks for your contributions!


Slugification for copied files

Enter your suggestions in details:
Thank you for creating lume, I love it so far!
One thing that would be great would be a way to slugify also the names of copy()ed files. Because right now, the interaction of copying and slugification seems kind of bad.
Unless I am missing something (which might well be!), right now, the behavior is the following (assuming the slugify plugin is loaded):

Suppose in my .src directory contains a path with spaces and Capitals/, which contains:

a static file with spaces and Capitals/more spaces and Capitals.bin (with site.copy(['.bin'])
a processed file  with spaces and Capitals/With Spaces.md

I'll be getting two directories in _site:

with spaces and Capitals, which contains more spaces and Capitals.bin
with-spaces-and-capitals, which contains with-spaces.html

Ideally, I would like to have:

One directory,  with-spaces-and-capitals, which contains more-spaces-and-capitals.bin and  with-spaces.html

I know I can fiddle with the url of the copy()ed files via the second argument to copy(), but such a solution would be cumbersome and somewhat brittle (e.g., suppose the slugify options change).

I guess one of the reasons for the current behavior is that copy()ed files are not processed at all, hence the slugify plugin has no chance to intervene.
Maybe it would be an option to provide (in the slugify plugin?) a copyAndSlugify() method?
Or is my "ideally" above already possible, I just missed how?
If not, I'd be willing to work on a pull request for this.

Hi.
Yes, it makes sense. Right now, the plugin only affects to loaded pages, but not filed copied statically. Maybe the plugin should have an option to enable it. I imagine something like:
site.use(slugifyUrls({
  staticFiles: true,
});

For now, as a workaround, you can use the beforeRender event:
site.addEventListener("beforeRender", () => {
  const files = site.files; // the files to be copied statically

  // Change the outputPath property
  files.forEach((file) => {
    file.outputPath = slugify(file.outputPath);
  });
});

Thanks for the quick reply!

site.use(slugifyUrls({
  staticFiles: true,
});

Seems sensible - in principle, I think it would even make sense to have this option activated by default ... but that would be a breaking change.
Thank you for the workaround, that makes things easier for me in the meantime!

I just made some changes in Lume to slugify static files.
The extensions option now is applied to both loaded files and copied files. By default is .html so I don't think it's a breaking change.
If you want to slugify some files copied statically, for example .pdf files, you can do:
site.use(slugifyUrls({
  extensions: [".html", ".pdf"]
});

To slugify all files, use *:
site.use(slugifyUrls({
  extensions: "*"
});

This change will be available in Lume v1.18.2. It's not released yet, but you can test it by upgrading Lume to the latest development version with deno task lume upgrade --dev.

Works like a charm!
Thank you for making this happen so quickly!xt
A suggestion/question: Wouldn't it make sense to change the default to extensions: "*" for lume 2? Like, if someone wants slugification, they probably want it for all/most things?
(I might be missing something that makes this a bad idea, and anyways, having an extra line for this in _config.ts is not a big deal, just wondering.)

Yes, good idea. I'll change it to * in v2.
Thanks!


bugfix: remove clear pass (https://github.com/lapce/lapce/issues/120)

this should resolve this problem: https://github.com/lapce/lapce/issues/120
why is the swapchain cleared on a seperate render pass. this might be a work around for the issue since I'm not really clear on the original change. there is a multisample example in wgpu that I was looking at and this seems consistent with that.

Thanks for the PR.
Lapce is now using the opengl branch which has issues as well. Would you mind taking a look at the opengl branch for me?


Flutter .ci.yaml format should be modular/support imports

For flutter/flutter, the .ci.yaml file is currently 5561 lines long: https://github.com/flutter/flutter/blob/master/.ci.yaml#L5561.
These files are parsed by the script at https://github.com/flutter/cocoon/blob/main/app_dart/bin/generate_jspb.dart and the protocol buffer at https://github.com/flutter/cocoon/blob/main/app_dart/lib/src/model/proto/internal/scheduler.proto.
Complicating this, I believe one workflow of this script CURLs the file from github, which would complicate imports: https://github.com/flutter/cocoon/blob/main/app_dart/bin/generate_jspb.dart#L20

This would help my workflow when trying something on the infra, such as attempting to reproduce flakes or optimizing test sharding. I frequently make changes to .ci.yaml when investigating flakes. For example, I shut off all uninteresting shards, and I multiply shards that are interesting, which requires a lot of changes in the file. However, that leads to frequent merge conflicts. I think modularizing it would make changes like that much smaller.

Ideally, this file would be generated by Dart code, or some other standard build language, such as Starlark.

There's a few paths forward here that I've discussed:

Matrix support - ci.yaml is 50%+ duplicate pieces. We could instead refactor to expand various tests to run on different platforms.
Modular configs - This has the largest unknowns. I suspect the Cocoon server would need to maintain a Flutter checkout on it's machines to quickly aggregate the various configs, and build the scheduling graph.
Remove unused parameters

There's room for a cleanup that removes parameters that are no longer used, duplicate of other parameters, or move into the platform properties

Ideally, this file would be generated by Dart code, or some other standard build language, such as Starlark.

We can easily do that, and get rid of the yaml. The only core piece that needs to be updated is https://github.com/flutter/cocoon/blob/main/app_dart/bin/generate_jspb.dart


WIP: Add token_id to the url

Added token_id to the URL
In the search results make token links more specific

 Открывать определенный токен (сохранять в URL)

Hold on, I forgot to upgrade the link here, will be back in an hour

Done


Fix format of ARM esf_dump

Signed-off-by: Andrew Fernandes<EMAIL_ADDRESS>

This patch fixes formatting for dumping floating point registers.
Before: (notice the extra linefeeds and misaligned registers)

After: (much easier on the eyes)


Account request denied

hello, my mail yandex.com
The answer has come.
Account request denied
Unfortunately, your request for an Amazon SageMaker Studio Lab account was denied. Your email is associated with activity that may have violated our Terms of Service
sincerely,
— The Amazon SageMaker Studio Lab team
Do you not accept yandex mail?
Why was I not accepted?

Hi Bekahose,
I cannot say for certain why your request was denied, but try an email with a different domain. Let me know how that goes.
Thanks!
Michele


Fix link to the dns addon readme

Hi!
I noticed that the link to the dns addon readme was broken. This PR fixes the route.

Thanks!


feat: retrieve ConfigurationService from ConfigurationServiceProvider

Depends on #1013

Does this help with quarkus extension too? or the point is just to have a global config serivce?

Does this help with quarkus extension too? or the point is just to have a global config serivce?

I'm not sure yet… It started with the idea that it would help but I need to try it out…


Fix broken specification link in docs

This should make the link work in both github and the docs site.
We may need to fix the sed calls in the docs build process and see if we can address this in hugo.
Signed-off-by: Stephen J Day<EMAIL_ADDRESS>

@moxiegirl PTAL

cc @dmp42 @samalba

LGTM.  These appear to be working with my current seds.
In testing the docs, I found two broken links in  the configuration docs. I'll file an issue against that page.  I recommend checking with Check my links chrome extension -- there are similar tools in other browser.
Also, the code samples in the configuration page are using ``` for code designation. We've standardized on indentation in engine and other projects. Let me know if you have any questions.

@moxiegirl I'd recommend not standardizing on using indentation for code blocks. Using indented blocks makes getting indentation of the sample very challenging. Certain languages, such as yaml and python, are very sensitive to white-spacing. This is simply a standard that I'm will not sure we will follow or enforce. We use github on a daily basis, so we should standardize on that.
The syntax has a number of benefits. First, it is very easy to align the the preceding structure by getting the backtics in the right place. The approach also let's one provide code highlighting hints. For example, here is some json:
{
    "aKey": [1, 1.5 "aString"],
}

The above is rendered from this:
```json
{
    "aKey": [1, 1.5 "aString"],
}

@samalba @dmp42 @endophage @diogomonica


PARQUET-2483: Update references to parquet-mr in Readmes

Make sure you have checked all steps below.
Jira

[x ] My PR addresses the following Parquet Jira issues and references
them in the PR title. For example, "PARQUET-1234: My Parquet PR"

https://issues.apache.org/jira/browse/PARQUET-XXX
In case you are adding a dependency, check if the license complies with
the ASF 3rd Party License Policy.

Tests

[x ] My PR adds the following unit tests OR does not need testing for this extremely good reason:

Commits

[x ] My commits all reference Jira issues in their subject lines. In addition, my commits follow the guidelines
from "How to write a good git commit message":

Subject is separated from body by a blank line
Subject is limited to 50 characters (not including Jira issue reference)
Subject does not end with a period
Subject uses the imperative mood ("add", not "adding")
Body wraps at 72 characters
Body explains "what" and "why", not "how"

Style

[x ] My contribution adheres to the code style guidelines and Spotless passes.

To apply the necessary changes, run mvn spotless:apply -Pvector-plugins

Documentation

[x ] In case of new functionality, my PR adds documentation that describes how to use it.

All the public functions and the classes in the PR contain Javadoc that explain what it does

If no objections I can Squash merge this and resolve the jira by hand?


Swap # with ?

In url.

Throwing error
Uncaught TypeError: Cannot read property 'lat' of undefined`.
11.L.Projection.SphericalMercator.project @ leaflet-src.js:1420
11.L.CRS.latLngToPoint @ leaflet-src.js:1460
11.L.Map.L.Class.extend.project @ leaflet-src.js:1955
11.L.Map.L.Class.extend._getNewTopLeftPoint @ leaflet-src.js:2278
11.L.Map.L.Class.extend._resetView @ leaflet-src.js:2094
11.L.Map.include.setView @ leaflet-src.js:873225../src/leaflet_options @ printing.js:22

Errors here /printing.js#22 But threw some on this function while testing, that syntax look legit @danpat ?

it looks like parsedOptions.center is not a valid object.  It's still being set from window.location.hash here https://github.com/Project-OSRM/osrm-frontend-v2/blob/redesign/printing.js#L10

Having an issue passing the correct parameters from the _printPage function src/tools.js#L120-L133 center  and zoom added to var options are legit values

But the entire link values seems to be problematic. In console.log you don't see the options pass from links.format(link, options))

It's passed correctly in Patrick's version, and options is showing as a proper object.

Which leads me to the functions formatLink in src/links.js#L55-L78 and parseLink in src/links.js#L80-L118. My version seems to jump straight to parseLink and not run formatLink.
Is the fix simpler than this @danpat? Feel like I'm getting into deep waters...

Looks like I'm missing some requires in links.js ...

Print working https://github.com/Project-OSRM/osrm-frontend-v2/commit/43bf9ba26724c44f79aa3b6ff19b98b1f5cc4677


Clarify remote name <-> remote branch

This fixes the original issue from #1209 . The vcs segment now shows <remote_branch>@<remote_name>, if there is a remote. The delimiter is configurable by setting P9K_VCS_REMOTE_DELIMITER.

In the screenshot I have a local branch next2 pointing at next from origin.
I hope that clarifies what the remote name is and what the remote branch is. Performance might got a bit worse, if a remote was detected (one subshell more)..
Additionally, this PR fixes some documentation issues and moves truncating the branch name in a better named hook (git-branch, instead of git-remote-branch).
// cc @Syphdias @romkatv

A few observations:

The first time I tried it, I ended up with master→origin/master@ since I had set some git hooks. I then added git-gather-data, that led to loosing the branch entirely. This will definatly confuse people if the modify (or have modified) their hooks
The @-syntax is understandable but is not really git-syntax that can be copied. Just something to consider. Also setting the delimiter will not make that true since it's <branch><remote>.
I would consider making the test a little bit more solid (one if these asserts actually fails):

diff --git a/segments/vcs/vcs_git.spec b/segments/vcs/vcs_git.spec
index b963109b..859b5aac 100755
--- a/segments/vcs/vcs_git.spec
+++ b/segments/vcs/vcs_git.spec
@@ -425,11 +425,15 @@ function testAlwaysShowRemoteBranch() {

   git clone . ../vcs-test2 1>/dev/null 2>&1
   cd ../vcs-test2
+  git remote rename origin some/remote

-  assertEquals "%K{002} %F{000} master→master@origin %k%F{002}%f " "$(__p9k_build_left_prompt)"
+  assertEquals "%K{002} %F{000} master→master@some/remote %k%F{002}%f " "$(__p9k_build_left_prompt)"

   local P9K_VCS_GIT_ALWAYS_SHOW_REMOTE_BRANCH='false'
   assertEquals "%K{002} %F{000} master %k%F{002}%f " "$(__p9k_build_left_prompt)"
+
+  git branch -m master new/ref/master
+  assertEquals "%K{002} %F{000} new/ref/master→master@some/remote %k%F{002}%f " "$(__p9k_build_left_prompt)"
 }

 function testGitDirClobber() {

Thanks for the review @Syphdias . Yep, how we merge that configuration array is still unsolved. I'm open to suggestions ;) The obvious one - merge that automatically - won't work, as we cannot know if a user configured that hook away for any reason, or if that hook was added by us..
I deliberately went away from the git syntax, because the git syntax is ambiguous as well (<remote>/<branch>; at least if using git rev-parse), if your branch contains slashes. A whitespace could be another solution. Do you like that better?
Agreed with making the tests more robust. Will do.

Thanks for the review @Syphdias . Yep, how we merge that configuration array is still unsolved. I'm open to suggestions ;) The obvious one - merge that automatically - won't work, as we cannot know if a user configured that hook away for any reason, or if that hook was added by us..

Two things:

I don't entirely get why you split it into two hooks. I suppose you need git-gather-data because you do something irreversible in a later hook and need the data. Could you make it a normal function that is called in the hook(s) where you need it, so there are no hooks depending on another hook? I'm not sure if there are other "hook dependencies" but I would like to avoid them firstly from a UX perspective and second to avoid github issues (aka work for us :wink:) which will be caused from people using it "wrongly".
The @ at the end I described should be easily avoidable by something like this in +vi-git-remotebranch (ugly but functional):

[[ -n ${remote_name} ]] \
  && hook_com[branch]+="${__P9K_ICONS[VCS_REMOTE_BRANCH]}${remote_branch}${P9K_VCS_REMOTE_DELIMITER}${remote_name}" \
  || hook_com[branch]+="${__P9K_ICONS[VCS_REMOTE_BRANCH]}${remote_branch}"

I deliberately went away from the git syntax, because the git syntax is ambiguous as well (<remote>/<branch>; at least if using git rev-parse), if your branch contains slashes. A whitespace could be another solution. Do you like that better?

Just to be clear: I'm not totally disagreeing with the @. It's just usually used differently in git references. Not sure if whitespace would work.
I also thought of // since you can neither start a branch with / nor end a remote on it; but also non-standard.
Github uses : in PRs which cannot be used in either branch or remote name but is used in pushing afaik.
I would opt for : but I'll leave it up to you.

[...] I suppose you need git-gather-data because you do something irreversible in a later hook and need the data.

Correct. It is possible to truncate long branch names. That is why I saved the original branch name as early as possible.

[...] Could you make it a normal function [...]?

Well. The problem with that approach would be that we either need to cache the value on the first call (and there is no guarantee that the first call already truncated the branch name), or that we have to query git all the time to get the branch name..

Github uses : in PRs which cannot be used in either branch or remote name but is used in pushing afaik.

Fair point. The main problem is that our approach is still not very flexible. We are bound to the initial structure (branch first, remote second information). Sure, we could change that, but not the user (I'd love to have some simple templating for such things).
GitLab uses a slash, GitHub a colon, but both write first remote, then branch name. I'll change to colon as well and remote first.

Hmm. I even introduced a new hook git-branch-icon, that shows the icon. With this hook, users can decide, where the branch icon should show up. This could be done as function as well, but then we could not decide, if the icon was already show. This is necessary, to show the icon for remote (git-remote-branch) and local branches (git-branch). Of course, if we do not want to show an branch icon for the remote branch, we could just include the icon in the normal git-branch hook..

Friendly reminder, this is still an issue:

Additional info this even happens with P9K_VCS_GIT_ALWAYS_SHOW_REMOTE_BRANCH=false. Maybe this could work?
diff --git a/segments/vcs/vcs.p9k b/segments/vcs/vcs.p9k
index e3581168..3cc48e51 100644
--- a/segments/vcs/vcs.p9k
+++ b/segments/vcs/vcs.p9k
@@ -217,7 +217,7 @@ function +vi-git-remotebranch() {
   local remote=${$(command git rev-parse --verify HEAD@{upstream} --symbolic-full-name 2>/dev/null)/refs\/(remotes|heads)\/}

   # Only show the remote if it differs from the local
-  if [[ -n ${remote} \
+  if [[ -n ${remote} && -n ${__P9K_VCS_DATA[branch]} \
       && ( \
         "${P9K_VCS_GIT_ALWAYS_SHOW_REMOTE_BRANCH}" == 'true' \
         || "${remote#*/}" != "${__P9K_VCS_DATA[branch]#heads/}" \

Also, I think we discussed this before. Is this wanted behaviour, showing the remote if it's not names "origin"?

My idea to checking this in the tests:
diff --git a/segments/vcs/vcs_git.spec b/segments/vcs/vcs_git.spec
index 662af683..efc165d6 100755
--- a/segments/vcs/vcs_git.spec
+++ b/segments/vcs/vcs_git.spec
@@ -429,6 +429,7 @@ function testAlwaysShowRemoteBranch() {
   assertEquals "%K{002} %F{000} master %k%F{002}%f " "$(__p9k_build_left_prompt)"

   git remote rename origin some/remote
+  assertEquals "%K{002} %F{000} master %k%F{002}%f " "$(__p9k_build_left_prompt)"
   local P9K_VCS_GIT_ALWAYS_SHOW_REMOTE_BRANCH='true'
   assertEquals "%K{002} %F{000} master→some/remote:master %k%F{002}%f " "$(__p9k_build_left_prompt)"

And my approach to fixing it (this includes the bug fix from above):
diff --git a/segments/vcs/vcs.p9k b/segments/vcs/vcs.p9k
index e3581168..dd544527 100644
--- a/segments/vcs/vcs.p9k
+++ b/segments/vcs/vcs.p9k
@@ -217,12 +217,12 @@ function +vi-git-remotebranch() {
   local remote=${$(command git rev-parse --verify HEAD@{upstream} --symbolic-full-name 2>/dev/null)/refs\/(remotes|heads)\/}

   # Only show the remote if it differs from the local
-  if [[ -n ${remote} \
+  local remote_name=$(command git config branch.${__P9K_VCS_DATA[branch]#heads/}.remote)
+  if [[ -n ${remote} && -n ${__P9K_VCS_DATA[branch]} \
       && ( \
         "${P9K_VCS_GIT_ALWAYS_SHOW_REMOTE_BRANCH}" == 'true' \
-        || "${remote#*/}" != "${__P9K_VCS_DATA[branch]#heads/}" \
+        || "${remote#${remote_name}/}" != "${__P9K_VCS_DATA[branch]#heads/}" \
       ) ]]; then
-    local remote_name=$(command git config branch.${__P9K_VCS_DATA[branch]#heads/}.remote)
     # Remote Branch is the remote branch name, without the remote name.
     # Additionally, remove trailing whitespace and escape percent signs.
     local remote_branch=${${${remote#${remote_name}/}// /}//\%/%%}

Sorry that I'm turning you into the reviewer now :sweat_smile:
I still think this might case some issues with people who do not use the default hooks. We might need to inform users above the change, but I'm not sure if that causes more or less confusion.
PS: I find this exceptionally hard to test with all the possibilities and chances of weird edge cases. I think it is very hard to get this segment perfect. Kudos to you for trying!


ui and nuxt export different version of NavDrawer

I recently have the opportunity to use the ui package and I found that some props doesn't work as expected while using NavDrawer from @gits-id/ui package. Meanwhile, in another project that uses the same component from @gits-id/nuxt with the same props applied, works as expected (per documentation and storybook example).
Diving into the code, it seems that these package export different version of NavDrawer as VNavDrawer.  Below are the export code in ui and nuxt:
https://github.com/gitsindonesia/ui-component/blob/cda5923c77eea564f1df3696753e7b21a5da97c5/packages/nuxt/src/module.ts#L266-L270
https://github.com/gitsindonesia/ui-component/blob/cda5923c77eea564f1df3696753e7b21a5da97c5/packages/ui/src/index.ts#L31
https://github.com/gitsindonesia/ui-component/blob/cda5923c77eea564f1df3696753e7b21a5da97c5/packages/ui/src/index.ts#L96
And this is how NavDrawer actually export its components
https://github.com/gitsindonesia/ui-component/blob/cda5923c77eea564f1df3696753e7b21a5da97c5/packages/nav-drawer/src/index.ts#L1-L3

Based on the above findings, I assume that the reason why NavDrawer behave differently between ui and nuxt is because the one exported by ui is the deprecated one which by storybook example does not implement some props that currently exist in not-deprecated one.

Hi. Yes it is intended for preventing breaking change. For older user will still use the deprecated version, while the new user like in the nuxt starter will use the new component.

Okay, so it's advisable for newer user to export NavDrawer from gits-id/nav-drawer then?
If so, maybe there should be a note in ui package, because the docs doesn't exactly have a page dedicated for the old version of NavDrawer nor point out which props are available from specific ver. onwards. Or, maybe in upgrade path or something. Just a section to tell how user can use the new version of certain components while waiting for new major ver. release to have this as default would be helpful.

Yes. It's recommended to use the new NavDrawer component. The old one could be removed on the new major version.
import {NavDrawer} from '@gits-id/nav-drawer`;

I already document and add deprecation info on the old nav-drawer page: https://gitsindonesia.github.io/ui-component/components/nav-drawer.html
The new NavDrawer doc is here: https://gitsindonesia.github.io/ui-component/components/navigation-drawer.html

My bad, somehow my eyes skipped that entry. Thanks for the link, I've read the deprecated one now. I know of the new one, but I guess my eyes glazed over when I see the deprecated ones.
I'll close this issue and remove the bug tag as it wasn't a bug.


MIC-95 / MIC-152 referral/contributory-factors-comments screen

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

Project coverage is 74.00%. Comparing base (17b7954) to head (ea8b9fe).

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #55      +/-   ##
==========================================
+ Coverage   73.51%   74.00%   +0.48%
==========================================
  Files          92       94       +2
  Lines        1333     1358      +25
  Branches      211      214       +3
==========================================
+ Hits          980     1005      +25
  Misses        342      342
  Partials       11       11

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


Add a back button on the program settings page

Add a back button on the program settings page.
From Miriam: "Can the back link be dynamic and either show '← Back to all programs' or '← Back to [Program name] program edit page'"

All of the other similar UIs in the app work the same way (any kind of form submit -- e.g. the optional toggle or the program metadata edit page). I think we could fix this with an iframe but not sure it's worth the effort.


Handle the org rename

This renames the project from github.com/coreos/coreos-cloudinit to github.com/flatcar/coreos-cloudinit. Also updated the the old flatcar-linux links to it's flatcar counterparts.

The gofmt change conflict seems to come from different versions being used in the GitHub Action and locally by you?

Yeah, seems to be a difference between golang 1.18 (as used by CI) and 1.19 (as used by me locally). Reverted that change. Something to revisit if we bump the golang version in CI to a later version.


Running model.test in a loop

Running model.test() in a loop gives variable scope error
Variable feature_extractor/conv1_1/weights already exists, disallowed. Did you mean to set reuse=True or reuse=tf.AUTO_REUSE in VarScope?
The error originates from line 11 of network.py
net['conv1_1'] = slim.conv2d(x, 16, stride=2, scope='conv1_1')

The error is that  some variables are defined more than once, but I have set reuse=True to avoid the issue. Please check your code again!


TF survey metadata

Need to update how survey_metadata is set in TF.  Currently survey_metadata is a single object and station_metadata are separate objects.  Need to update so that there is a single metadata object survey_metadata from which station_metadata is derived from.  That way you need to only set survey_metadata if you alreaday have one built from say an MTH5 object.

[ ] update mt_metadata.transfer_function.core.TF to have a single metadata object
[ ] update any fall out from that
[ ] update tests.

Codecov Report
Patch coverage: 51.02% and project coverage change: -0.64% :warning:

Comparison is base (3f0a53c) 81.96% compared to head (39fc09d) 81.32%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the GitHub App Integration for your organization. Read more.
Additional details and impacted files
@@            Coverage Diff             @@
##              fcs     #159      +/-   ##
==========================================
- Coverage   81.96%   81.32%   -0.64%
==========================================
  Files         266      267       +1
  Lines       18631    18939     +308
==========================================
+ Hits        15271    15403     +132
- Misses       3360     3536     +176

Files Changed
Coverage Δ

tests/tf/io/edi/test_cgg_edi.py
99.31% <ø> (ø)

tests/tf/io/edi/test_empower_edi.py
99.38% <ø> (ø)

...s/tf/io/emtfxml/test_tf_read_derived_quantities.py
97.29% <ø> (ø)

tests/tf/io/emtfxml/test_tf_read_no_site_layout.py
97.22% <ø> (ø)

tests/tf/io/emtfxml/test_tf_read_poor.py
97.56% <ø> (ø)

tests/tf/io/zonge/test_tf_read.py
97.67% <ø> (ø)

tests/tf/io/zonge/test_tf_read_newer.py
97.67% <ø> (ø)

mt_metadata/transfer_functions/tf/survey.py
42.02% <42.02%> (ø)

mt_metadata/transfer_functions/core.py
66.94% <49.54%> (-3.52%)
:arrow_down:

mt_metadata/transfer_functions/io/edi/edi.py
70.77% <66.66%> (-0.34%)
:arrow_down:

... and 13 more

... and 1 file with indirect coverage changes

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


Add instructions for handling the opensihift-ansible submodule

Some users may not understand git submodules and need some help in populating the openshift-ansible directory. Probably best to add this to the README.md file?
I think this would be something like this:
git submodule init
git submodule update
cd openshift-ansible/
git pull
git checkout master

Good suggestion, fixed with #5


firebase.JWKS public keys expire and don't get refreshed

This took me a while to track down. I would sometimes get {"detail":"JWK public Attribute for authorization token not found"} after 7 days of the fastapi instance being up. This hinted towards something expiring.
The firebase.JWKsVerifier class sets self._jwks_to_key = jwks.keys; where jwks is a firebase.JWKS instance. JWKS.firebase is constructed like so:
    @classmethod
    def firebase(cls, url: str) -> "JWKS":
        """
        get and parse json into jwks from endpoint for Firebase,
        """
        certs = requests.get(url).json()
        keys = {
            kid: jwk.construct(publickey, algorithm="RS256")
            for kid, publickey in certs.items()
        }
        return cls(keys=keys)

What this means is the keys are queried with certs = requests.get(url).json() and stored for as long as the instance is up, but they are never refreshed.
@tokusumi I can raise a PR to fix this if you're too busy; but i'd like your take on how to proceed with it. I'm not sure where to even do the detection for expired keys.

It's worth noting: The URL<EMAIL_ADDRESS>has an expires header which indicates a ~6 hours TTL. This is much lower than the time they actually disappear; probably on purpose to give time to roll over. My take is that we should store the expires header, and simply update the keys if they have expired (probably with some kind of lock to prevent a bunch of attempts re-querying at the same time).

@jleclanche Thank you for your issue and PR!
This problem is fixed in Release 0.4.1


Add Examples

Create an examples package that demonstrates usage of all primitives exposed by the library. The examples do not need to be exhaustive, but instead a jumping-off point for those wishing to understand how they might use the library.

+1 on this. Just wanted to note that it would help if these examples provided some context/references to edify themselves for people starting off with SSI. As an observation from someone just joining in on the project: I'm not sure yet exactly where to start. Perhaps another issue should be raised (or is this on the same issue), which gives a "walkthrough" for newbies.

@decentralgabe can you assign this to me?

Closing this in favor of specific example issues to be added.


Added 2 new jokes in jokes-es

Description
Added 2 simple Spanish jokes, one about binary and one for C and Java.
Motivation and Context
To add more Spanish jokes since there were only 5.
How Has This Been Tested?
Locally tested and jokes display without issues. Proper structure was used when adding the jokes.
Checklist

[ x] I have read and followed the Contributing Guide
[ x] I have read and accept the Code of Conduct (TLDR: just behave in a friendly manner)
[ x] My code follows the general style of this project (explained here)
[ N/A] I have commented my code, particularly in hard-to-understand areas
[ N/A] I have made corresponding changes to the documentation (if applicable)
[ x] I ensured that the automated checks that ran on this PR have completed successfully
[ x] I added myself to the package.json file (optional but highly encouraged :)

Thanks for submitting jokes!

As soon as PR #239 is closed, your jokes will be live, until then you can see them on the stage server here


Improved processes handling

Added processes to PlayStateData, and their states (isSuspended, processesSuspended)
When you have more than one game opened, now you will be able to pause/resume the currentGame always. So, if you open Game1, and after you open Game2, but after a while you close Game2, you will be able to fully control again Game1.
Refactored code to allow in the future handle several games at the same time (show notifications for another game that is not the currentGame, pause/resume other game that is not the currentGame, etc).

I have verified that:

[x] These changes work, by building the extension and testing.
[x] That the changes comply with the rules indicated in the repository.
[x] Pull request is targeting master branch.

@darklinkpower all requested changes done I think.


feat(build): make this a fullblown cmake project

Description

This PR will make the whole project able to be built using CMake. There is still A LOT of work left to do before this will be ready.
Known TODOs:

[x] find category for lone misc patch
[x] move third-party to cmake build directory and only apply patches to that location (keep git tree clean)
[x] add custom targets for each step
[x] properly define paths for each dependency/step: https://stackoverflow.com/a/40285224/11214013
[ ] allow skipping dependency steps and instead use system installed versions
[ ] final step to depend on previous targets
[ ] include source code as part of dist branch (allow easy building of ffmpeg directly in Sunshine if packager doesn't want to use a pre-compiled target)
[ ] update readme with build instructions
[x] use Ninja

[ ] ninja not working for Linux cross compilers, probably something in the toolchain messing with the environment

[x] update CI
[ ] no working c compiler found for x264 in Windows (GitHub runner only, local is okay)

Once this PR is complete, it will be easier to add new targets such as for Fedora using the container option in CI.
Screenshot

Issues Fixed or Closed

Type of Change

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Dependency update (updates to dependencies)
[x] Documentation update (changes to documentation)
[x] Repository update (changes to repository files, e.g. .github/...)

Checklist

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

@brad-richardson sorry for the ping, but hoping you can help shed some light on this question.
I am trying to work towards making our whole FFmpeg build a cmake project, which would then allow us to include it as a subdirectory in Sunshine for cases where our pre-builts are not sufficient.
I'm struggling to understand the cbs aspect, and why FFmpeg was configured and built 2 times. Is there some reason why we can't just configure FFmpeg once with the --enable-bsfs flag?
https://github.com/LizardByte/build-deps/pull/54


Update toggl to 7.4.139

After making all changes to the cask:

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} left no offenses.
[x] The commit message includes the cask’s name and version.

7.4.139 is a dev release, 7.4.129 is the current stable at https://www.toggl.com/toggl-desktop/ and https://assets.toggl.com/installers/darwin_stable_appcast.xml


What is meant by "create a target server per source server"

"In the target region, create a target server for each source server..."
What does this mean. The documentation then links to setting up a secondary database, here: https://docs.microsoft.com/en-us/azure/azure-sql/database/active-geo-replication-security-configure#how-to-configure-logins-and-users
Can you clarify on what it means to create a target server for each source server?
Do I have to setup a blank new server in the intended resource group?
Do I have to setup a new server with all prior configurations and users added as well?
Do I need to set this new server up with all prior databases and link it to a failover group with the original server I am trying to move?

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

ID: 1a37dc59-eac3-485c-5cdd-ba1b6d091df8
Version Independent ID: 070bf81b-d985-7675-ac73-2a2c0e2c9166
Content: Move Azure SQL resources between regions with Azure Resource Mover
Content Source: articles/resource-mover/tutorial-move-region-sql.md
Service: resource-move
GitHub Login: @rayne-wiselman
Microsoft Alias: raynew

@josmill Thank you for the question. We will look into this and get back to you shortly.

@josmill For SQL DB move cross region, we treat SQL server as a document resource where we ask customers to either leverage  an existing server in target region or create a net new server.
This is because we don’t have a move technology/mechanism for SQL server to move cross regions yet.
E.g If you are looking to move two SQL DBs A and B which are associated to SQL severs 1 and 2. You would need to ensure you have two servers (3 and 4) on target side (existing or new ones) and map the SQL DBs respectively to complete the move.  (You can map both DBs to same sever if you chose too, but I am assuming you want to keep the same pre-move topology as-is and make no changes).
•	Any configs which were present on source server , need to get configured on the target server as well. Resource Mover does not move or enable this in target region.
•	The SQL tutorial documents highlights how/when to create a target SQL server and what state it needs to be in (delete source pending) before you can start Prepare of the source SQL DB.
https://docs.microsoft.com/en-us/azure/resource-mover/tutorial-move-region-sql#move-the-sql-server
•	We utilize SQL GeoDR replication engine underneath to replicate the SQL Dbs.
Please also review the support matrix for SQL DB move: https://docs.microsoft.com/en-us/azure/resource-mover/support-matrix-move-region-sql
Hope this helps.

@josmill As we haven't heard back from you, we will close the issue for now. If there are further questions , please revert and we will be glad to assist you.


Checks for an empty, undefined or null object on transacting

Hi, description below. Tests included.
Please advice any further modification you consider
Fixes https://github.com/tgriesser/knex/issues/2079
Those values indicates that the developer probably made a mistake.

Thanks! Looks good

This is a majorly breaking change, since previously you could write functions that optionally participated in a larger transaction. For lots of select calls you may intentionally call a repository method without a transaction in order to capture the pre-transaction state of something.
e.g.
knex.transaction(async transaction => {
  await repo.update(....do something to the person...., transaction);
  // do some logic, oh nevermind, set it back
  const originalValue= await repo.lookup(...get the person, null/* no transaction, capture the outside version of the person */);
  // etc. set it back, whatever.
})

@Sammons if you don't have a transaction you can just omit the call to transacting, I don't see any issue there... why calling transacting if you don't want the query to use the transaction?
Can you put a knex specific example? (lookup method is not in the docs and I don't know what repo1/repo2 is)

@wubzz got it. I think you're partially right. It is true that this may break your current implementation. But that's actually intended, IMO. Knex does not have the responsibility on the developer mistake, but it needs a good API, and if your API leads you to bad usage, then is a bad API. We can discuss and change the message details, the chosen words, etc.
@Sammons true, adding an if will add a new branch to your coverage to test. However, if you in-distinctively called the same function with and without transaction object, and you did it with 100% test code coverage, then you have that test ready on the scenario in which the transaction has a value and on the scenario in which transaction does not have a value.
However I agree with both, technically speaking, that this may be considered a breaking change and left to a minor version change instead of a path. In my case I will switch to that new version immediately and put a notice on the readme about that issue for the 0.14 version.

@nicosommi Thank you. To be clear I'm just trying to emphasize that it's a lot of work to migrate, at least for us - even if the reasons why we have to do the work seem silly.
So there's no hope of rolling back this change in a future version? I understand the desire for consistency but it seems like a minor reason to introduce a breaking change, on something that appears to have had the same behavior for a very long time.

Reason for this kind of changes is to prevent accidental ’something was undefined by accident’ errors, which are many times really hard to track. We did this already before for .where clauses which were ignoring clause completely fron query if passed value was undefined.
There is no chance that this would be reverted, but I’am open for configuration switch would allow users to select not throwing errors, which could be deprecated some day maybe.
The reason why this hadn’t been considered breaking change was because passing undefined/null to transacting has been undefined behaviour earlier and code relaying to undefined behaviour .... well keeps workin undefined ways.
This discussion about breaking change seems to raise quite often, when we change some undefined behaviour to defined one.

Btw. this feature seems to be still undefined, since this PR didn’t fix documentation to tell about accepted parameters (at least I suppose there is no mention about accepted parameters... im too lazy to actually check docs on mobile)

@elhigu if I update the docs and add a configuration option, how would that sound? We already released the breaking change so the configuration should default to requiring the transaction to exist.

@Sammons that sounds good. It is definitely a good thing that parameters are verified to be valid by default.

@elhigu @nicosommi - What the approach would normally be for this config? Would this be stored in an environment variable, or should it be on the config object?

New property in configuration object. The same way with useNullAsDefault.

You wont believe me, but I've used passing empty value as a feature, to indicate that this query is not required to be a part of transaction.
@nicosommi

you can just omit the call to transacting

That isn't nice in chaining API.
before:
.select(…)
.transacting(tx) // `tx` may be empty value
.where(…)

now:
var q = … select(…)
tx && q.transacting(tx)
q.where(…)

Does knex has any of thru, pipe or noop?
(something like thru(q => tx && q.transacting(tx) || q) may suit for chaining API).
However, explicit is better than implicit, so I will mitigate the aftermaths of my side. But you definitely should have released 0.15 with this change that day.

That isn't nice in chaining API.

If you use transacting with an empty value "explicitly", then you should call all available methods explicitly as well according to that reasoning.
BTW chaining is not an impediment for this... as I said, you can omit the call.
const q = knex().select()
if (t) q.transacting(t)
q.where()...

"If an API leads you to bad usage, is a bad API."
Regarding to this being  a breaking change or not, I think that it was already discussed enough on this issue.

@nicosommi, no, you don't get my opinion. I mean, the accepted solution to throw on empty value is OK for me, because it's explicit (not mine, which is implicit, of course). I will handle empty values on my side.
However, I think that implicit solution is better in this particular case, on chaining API, since you don't need to break the chain.
There's no much sense to have an chaining API, which main purpose is to not to pass intermediate value all over the place, and to write snippets like yours or mine, where q is stored. Besides, knex query builder is stateful, so having multiple refs to query might lead to user thinking it is immutable and can be reused (in fact, it can't, you need to create fresh instance every time or clone). So, it's not an impediment, but by breaking the chain you create more confusion.

forces us to add an if statement to previously linear code

Agreed, so we translate complexity from library code to user code, which isn't good.

Honestly I don't think this should have been changed to throw an error. Needless to say this adds inconsistencies against how other functions handles "invalid input". Usually we just helpers.warn() to notify the user, but we don't throw unless absolutely neccessary. In this case I wouldn't consider it a necessity.

@wubzz I have to disagree with that. We already changed long ago to undefined bindings to throw an error, so this change was comparable to that.
Some people were using that as a feature also, but I have no regrets on denying it, since it was pretty dangerous behaviour. This might not be that dangerous, but just adding warning would give a bit mixed signal saying that "we kind of support writing that kind of code" (which actually makes your app more prone to errors). There are some people who needs to modify their code to be like this: https://github.com/tgriesser/knex/pull/2494#issuecomment-394207906 but to me that is a small price when this change help all that people who are passing undefineds to that method by accident.
IMO knex should throw a lot more errors when invalid parameters are passed to API methods.

@wubzz unefined bindings were handled earlier by dropping those parts of where clauses off from query. So there was a way how to handle them and people was using that as a feature. Nothing broke, except when that was done by accident.
Now with transacting() there was a way how to handle undefined transaction, which was "don't use transaction after all, but just grab a new connection from pool". Nothing broke, except when that was done by accident.
I don't see much difference in those cases (except that dropping parts of where was even more dangerous). I know this all depends where one draws the line. I suppose .limit() with bad arguments is older code, when knex never threw errors. IMO it should throw an error as well, just like many other places.

For consistency we should change every single one of these functions to do one or the other, and not mix.

Yes. To a style where invalid arguments throw an error :)

To say that nothing broke with undefined bindings is pretty far-fetched, at least for Postgres seeing as it previously threw runtime errors... Here's one example https://github.com/tgriesser/knex/pull/1417
In any case sounds like a pretty big Pull Request incoming. A quick search shows 38 cases where we warn instead of throw. I'll try get to this today.

To say that nothing broke with undefined bindings is pretty far-fetched, at least for Postgres seeing as it previously threw runtime errors... Here's one example #1417

Yup that would have been far fetched. I'm glad I didn't wrote "Nothing broke", but "Nothing broke, if it was done intentionally." Passing .where('id', undefined) was perfectly fine back in days even with postgresql. Can't remember specifics of #1417 what were the circumstances / root cause for that. Maybe some other changes done in certain way started causing that or something like that. Too bad there wasn't test case in that PR.

In any case sounds like a pretty big Pull Request incoming. A quick search shows 38 cases where we warn instead of throw. I'll try get to this today.

Sounds good, hopefully there isn't too much obstacles on that road.
I once started (maybe 1.5 years ago) actually writing bunch of tests for testing that in every place correct parameters are checked and ended up stashing that work to the distant future.


Add function/tool to cleanup Orphaned tmp_* tables created by the imp-exp

It would be great to have a little function that would go through and cleanup any Orphaned tmp_* tables created by the imp-exp.
Sometimes when a connection is interrupted during an export the tables get left behind. Not a huge issue but it would be nice to have a little function. I just checked a database and it has ~50 or so of these tables.
I assume it's fairly easy to remove these tables with some SQL.

The Importer/Exporter 5.0 has been changed to not commit temporary tables anymore to avoid polluting the 3DCityDB schema with orphaned tmp_* tables (see change log and PR #190).


add PIC for linux builds

Can you see if this breaks anything for you? @marcusrossel

This changes nothing on my end 👍


Improve test coverage in sklearn.py

I think there are 20 lines missing at the moment; see coverage report.

It's actually pretty good now.