How to fix the path for images and files in a subfolder?

Hey all,
I'm trying to fix the output of all the images and files I have in a subfolder/subpage, using Webpack 4 and Pug.
This is my folder structure:
| index.pug
+---chapter-1
-------| index.pug
+---files
+---img
-------| nat.png
+---js
+---scss
+---video
|  webpack.common.js
|  webpack.dev.js
|  webpack.prod.js

I'm importing the image from index.pug as
 img(src='./img/nat.png')

and in chapter-1/index.pug as
 img(src='./../img/nat.png')

my webpack config is the following (I'm using html-loader and pug-html-info-loader for the pug files)
const webpack = require('webpack');
const path = require('path');

const HtmlWebpackPlugin = require('html-webpack-plugin');
const currentTask = process.env.npm_lifecycle_event;
const path_img = process.env;
const VueLoaderPlugin = require('vue-loader/lib/plugin');
var metadata = require('./src/lang/lang.json')

module.exports = {

    entry: {
        main: './src/js/home.js',
        about: './src/js/about.js',
        work: './src/js/work.js',
        chapterOne: './src/js/chapters/chapterOne.js',
    },

    module:{
        rules: [
            //rule for JS
            {
                test: /\.js$/,
                exclude: /(node_modules)/,
                use:'babel-loader'
            },
            //rule for html
            {
                test: /\.pug$/,
                use: [
                    'html-loader',
                    {
                      loader: 'pug-html-info-loader',
                      options: {
                        data: {
                          globalConf:metadata['global'],
                        }, // set of data to pass to the pug render.
                        basePath: path.resolve(__dirname, './src')
                        // base folder path for local variables.
                      }
                    }
                  ]
              },
            {
                test: /\.vue$/,
                use: 'vue-loader'
            },
           //rule for img
           {
            test: /\.(png|svg|gif|jpg)$/,
                use: [
                    {
                        loader: 'file-loader',
                        options: {
                            name: "[name].[hash].[ext]",
                            outputPath: "img/",
                            publicPath: ( currentTask == "dev" ? './img/' : "http://localhost/framework-webpack/dist/img/" )
                        }
                    },
                ],
            },
         // // rule for pdf files
            {
                test: /\.(pdf)$/,
                use: {
                    loader: 'file-loader',
                    options:{
                        name: '[name].[ext]',
                        outputPath: "files/",
                        publicPath: './files/'
                    }
                },
            },

            // // Assets Loader
            {
                test: /\.(mp4|mov|avi|wmv|webm)$/,
                use: {
                    loader: 'file-loader',
                    options:{
                        name: '[name].[hash].[ext]',
                        outputPath: "video/",
                        publicPath: './video/'
                    }
                },
            },

            // Font Loader
            {
                test: /\.(woff|woff2|svg)$/,
                exclude: [path.resolve(__dirname, './src/img/')],
                use: {
                    loader: 'file-loader',
                    options:{
                        name: '[name].[ext]',
                        limit: 4096,
                        mimetype: "application/font-woff",
                        outputPath: 'css/fonts/',
                        publicPath: './css/fonts/',
                    }
                },
            }

        ],
    },
    plugins:[
        new VueLoaderPlugin(),
        new HtmlWebpackPlugin({
            filename: './index.html',
            template: './src/index.pug',
            inject: 'body',
            chunks: ['main'],
        }),
        new HtmlWebpackPlugin({
            filename: './about.html',
            template: './src/about.pug',
            inject: 'body',
            chunks: ['about'],
        }),
        new HtmlWebpackPlugin({
            filename: './chapter-1/index.html',
            template: './src/chapter-1/index.pug',
            inject: 'body',
            chunks: ['chapterOne'],
        }),
    ],
    resolve: {
        alias: {
            '@scss': path.resolve(__dirname, 'src/scss'),
            '@img': path.resolve(__dirname, 'src/img'),
            '@subimg': path.resolve(__dirname, 'src/img'),
            '@': path.resolve(__dirname, 'src')
        }
    }

}

What I'm currently doing is changing the publicPath depending on the environment. While in build mode, I point to an absolute path:
 publicPath: ( currentTask == "dev" ? './img/' : "http://localhost/framework-webpack/dist/img/" )

This works, but I wonder if there's another way of doing this instead of adapting publicPath, like using a plugin or setting my config differently.
Thanks in advance! 🚀

Firstly - please use the issue template if you think it is bug (respect time of other developers), also if it is the question please use Discussions.

This works, but I wonder if there's another way of doing this instead of adapting publicPath, like using a plugin or setting my config differently.

You have the problem, because you change publicPath in many places not considering that paths can be relative, avoid using publicPath in many places and use output.publicPath to change it, other publicPaths to edge cases, I'm sure you don't need it

Feel free to feedback


reactive_date_time_picker hintText doesnt show up

Hello, im using, this code, and hint and helperText doesnt show up.
ReactiveDateTimePicker(
                    formControlName: 'date',
                    type: ReactiveDatePickerFieldType.date,
                    decoration: InputDecoration(
                      hintText: 'hint', // DOESNT WORK
                      label: const Text('fooa'), //WORKS
                      helperText: 'foo', //DOESNT WORK
                      //suffixIcon: const Icon(Icons.calendar_today),
                    ),
                  ),

pubspec
reactive_date_time_picker: ^0.5.0

Thank you for such quick response. I have to wait for easy_localization to update to intl 18 until i can update to 0.6.1. Then i can try it.

you are amazing! thank you!


Switch to OpenStreetMaps

Should get location from OpenStreetMaps Api using v 0.2 of LocationState.

@imsickofmaps Please review.

Looks good, just drop the extra fields and make the search on town and I think we're good

:+1:

Opened a new issue: https://github.com/praekelt/go-jsbox-location/issues/30, and changed address limit to 4.

@gsvr Travis happy, I added a commit to the README to trigger a test run. :+1:


Temporarily remove step to save ccache from scheduled jobs

Saving ccache is resulting in some errors finalizing the upload
which is preventing scheduled jobs from running. Removing this
step temporarily till its resolved.

This is caused by an underlying, flakey issue of the artifacts back end, there is nothing we can do see https://github.com/actions/upload-artifact/issues/543
Removing the step is a bit heavy handed we can just add continue-on-error to avoid the job failing if the action fails.

Actually it seems the latest release updated the npm package used to work with the backend, I'll drop the version used in the action down to 4.3.0 for now.


WIP - Azure and AWS Bindings - Azure Auth MSI

Description
Testing the waters here to see how to get some changes in:
The change to Azure Auth allows the Default Credential to move through the chain of potential creds including the Azure CLI that is useful from the developer desktop
For AWS SQS queue it is possible to have a cred that allows reading of the queue but not use of the method GetQueueURL on the AWS Client. The change enables the use of the full URL in the component spec of the binding.
For Azure Service Bus binding the send and receive will look to see if the message has populated user properties in addition to the standard system properties.
Issue reference

Looks like this is in flux with the move to the new Azure SDK for GO
Addresses an issue I have in a live scenario
same as 2

I have (2) and (3) running in an AKS cluster with a custom build of Dapr and seems to be working well
Checklist
Test changes are a bit limited and no document changes at this time.
Happy to discuss

[X] Code compiles correctly
[X] Created/updated tests
[ ] Extended the documentation / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]

Thanks for this contribution @HarryAcker! I pinged a coupe of folks to start reviewing this.

Hi @HarryAcker  thanks a lot for this contribution.
I have two thoughts on this:
First
WRT to the thing @yaron2 specifically @ me for, I agree that supporting Azure CLI credentials would be really helpful especially during development. There are however a few issues with this PR:

The authentication/azure package currently must provide authentication tokens for 2 different versions of the Azure SDKs. GetTokenCredential(), the method you modified, provides the credentials for the "track2" SDKs only (these are the new SDKs which are not yet available for all Azure services). Whatever solution is implemented there, needs to be implemented in GetAuthorizer() too, which is for the "track1" (older) SDKs.
Even in the case of the "track2" auth code, I would prefer not to rely on NewDefaultAzureCredential because that has its own pipeline which has some duplication (it again reads from the env and from MSI).  Instead, I'd add to the auth pipeline just NewAzureCLICredential to support the missing CLI credentials.
What I'm not 100% sure about is whether the credentials from the Azure CLI have a wide enough scope however. Those will definitely work for ARM calls (which I don't believe we make any), but will not work for things like Cosmos DB, because in that case you need a principal which is explicitly authorized to access your database. I am not sure they will work with Key Vault too.

Second
This PR is quite big in scope, and it would be great if you could please split it in 3:

The work on AWS binding
The work on the Azure Service Bus binding (which note that I'm rewriting literally these days to upgrade to the track2 SDK, so I can incorporate that change but it would need to be reviewed and merged separately!)
The part around authenticating with Azure

This would make it much easier to review the changes since they're quite different from each other :)

All good.  Firstly I'll move these out to three separate PRs.
AWS Binding - My problem with what is currently implemented is the call to client.GetQueueUrl requires a specific level of auth which the credentials may not allow.  I'll stick with my custom build and take a look at the pub/sub implementation.
Azure Binding - Sounds like the move to the new Azure SDK will carry some significant change so will take a look at a track 2 implementation.
Azure Auth - I'll switch to adding NewAzureCLICredential and validate it works for me in my dev and test environment.
In general appreciate the quick feedback and must say this being my first serious attempt at contributing to an OSS project.. it's going to be fun!

Try to keep your PRs as self contained as possible. Multiple PRs are fine - but only change one component at a time if at all possible :)

This may not be the way to do it, but is anyone going to propose an alternative that resolves the underlying need for local development?

Please file a new issue @onionhammer or discuss in our discord. It's unclear what need you are speaking of, and a closed PR isn't the place to discuss.


Add distributing of users by groups in administration page.

When number of users increase it is hard to find needed user (e.g. from team that work directly with you). I suggest to add an opportunity to distribute users by groups in administration page. Also, it can help to solve issue #236 (If we make opportunity to create folders of users in right sidebar it seems logically that one of the folders will contain groupmates).

Hmm, maybe.  I think I'm more excited about an implementation of #236 as a next step towards making progress on the direction of scaling the user lists; I think it's very possible the right solution here for the administration page is just to have a good search feature.

Depending on the use-case, a group-based approach can be nice in that, with some additional modifications, it enables a User creating a Stream to easily subscribe an entire swag of Users (versus picking through the entire User list).
@Alpus We've implemented this approach in our project and it works well.  Our project has made enough mods so to not be able to merge back, but I can share some code and screenshots, if interested.

Cool @danshev.  Some screenshots of how you did groups support would be great!  One of the big challenges with this sort of thing is always figuring out how to make the UI for a groups feature work well.

Our access paradigm is very different, so our implementation can thankfully be pretty basic.  Just sharing for the sake of ideas for others:

In a User's profile settings page, they can freely subscribe / unsubscribe to Groups:

For subscribing an entire Group to a Stream, we use the TextExt jQuery Plugin to handle the UI.  The plugin takes a suggestions array, which we populate with people.get_rest_of_realm() and a list of the Realm's Groups, which we pass on initial load as page_params.group_list.

Using TextExt creates a little work as far as reversing from full_name to email, but the UI is much better.  For any value that doesn't resolve to an email (i.e. a Group name), we just pass the Group name.  This requires a little work in streams.py on the backend (i.e. handling email addresses and raw group names), but it's not too bad.

Cool.  Your screenshots reminded me that it'd be great to have that kind of name boxes in the compose box, so I opened https://github.com/zulip/zulip/issues/595 for that issue.


Optimize UUID string decoding

I realized that 30% of the request time in our app is spent by hydrating the uuid (We are using Doctrine and in this specific request I was accidentally hydrating few thousands entities).
Luckily, I remembered the #160 and tried to do similar optimization for uuid decoding. It resulted in 10-20% performance improvement (it is not much, but every millisecond counts).
Benchmark: last commit in https://github.com/mhujer/uuid/commits/mh-uuid-decoding-speedup-benchmark
Benchmark results (Blackfire): https://blackfire.io/profiles/compare/42276a3a-cb45-47e2-80c4-61420b3c61bd/graph

Coverage increased (+0.4%) to 99.661% when pulling 4eefce356d50040e3e001ce2660a71b78d86fba5 on mhujer:mh-uuid-decoding-speedup into ff6ad53a00c6364862699805de2875854f97fd23 on ramsey:master.

Good catch! Thanks for contributing.

Thanks for quick merge and release! 👍


Self verification

Fixed the out-of-bounds access that was found by verification. It's a one-line-change to the computation of offsets in the advanced DLE backend. There's also a new test that fails on the master branch and passes on this branch.

thanks @jhueckelheim
Don't forget to add to the paper that fact that now the bug fix is in master
Merging...

Merged.


Adding straight-visit-package-local-repo

This PR adds a interactive function to visit the local-repo of an installed package. I had this in my local config, which I find very helpful. Figured I'd add it here itself.

There was another long-line complaint, but I've fixed it.
Merged into develop.
Thanks again, Ahmed.


Cannot launch windows pod

Hi,
I'm trying to get windows pods working on GKE but for both the jnlp and shell container I get the following errors:
Error: failed to start container "jnlp": Error response from daemon: CreateComputeSystem jnlp: The system cannot find the file specified.

Error: failed to start container "shell": Error response from daemon: CreateComputeSystem shell: The system cannot find the file specified.

This is using the sample pipeline:
/*
 * Runs a build on a Windows pod.
 * Tested in EKS: https://docs.aws.amazon.com/eks/latest/userguide/windows-support.html
 */
podTemplate(yaml: '''
apiVersion: v1
kind: Pod
spec:
  containers:
  - name: jnlp
    image: jenkins/jnlp-agent:latest-windows
  - name: shell
    image: mcr.microsoft.com/powershell:preview-windowsservercore-1809
    command:
    - powershell
    args:
    - Start-Sleep
    - 999999
  nodeSelector:
    beta.kubernetes.io/os: windows
''') {
    node(POD_LABEL) {
        container('shell') {
            powershell 'Get-ChildItem Env: | Sort Name'
        }
    }
}

Here's an outline the commands I used to setup the cluster:
gcloud beta container clusters create jenkins-cd \
  --num-nodes 2 \
  --machine-type n1-standard-2 \
  --scopes "https://www.googleapis.com/auth/source.read_write,cloud-platform" \
  --enable-ip-alias \
  --release-channel=rapid

gcloud container clusters get-credentials jenkins-cd

gcloud beta container node-pools create windows-pool \
  --cluster=jenkins-cd \
  --image-type=WINDOWS_SAC \
  --no-enable-autoupgrade \
  --machine-type=n1-standard-2

wget https://get.helm.sh/helm-v2.16.1-linux-amd64.tar.gz

tar zxfv helm-v2.16.1-linux-amd64.tar.gz
cp linux-amd64/helm .

kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=$(gcloud config get-value account)

kubectl create serviceaccount tiller --namespace kube-system
kubectl create clusterrolebinding tiller-admin-binding --clusterrole=cluster-admin --serviceaccount=kube-system:tiller

./helm init --service-account=tiller
./helm update

./helm version

./helm install -n cd stable/jenkins -f jenkins/values.yaml --version 1.2.2 --wait

kubectl get pods

export POD_NAME=$(kubectl get pods -l "app.kubernetes.io/component=jenkins-master" -o jsonpath="{.items[0].metadata.name}")
kubectl port-forward $POD_NAME 8080:8080 >> /dev/null &

kubectl get svc

printf $(kubectl get secret cd-jenkins -o jsonpath="{.data.jenkins-admin-password}" | base64 --decode);echo

Then I login into Jenkins and try to run the sample pipeline for windows but I cannot get it to work.
The following error also appears in the jenkins master log:
Error in provisioning; agent=KubernetesSlave name: windows-test-8-hn1vc-q3pg0-k4x83, template=PodTemplate{, name='windows-test_8-hn1vc-q3pg0', namespace='default', label='windows-test_8-hn1vc', nodeUsageMode=EXCLUSIVE, workspaceVolume=EmptyDirWorkspaceVolume [memory=false], annotations=[org.csanchez.jenkins.plugins.kubernetes.PodAnnotation@aab9c821, org.csanchez.jenkins.plugins.kubernetes.PodAnnotation@c92c82e4]}
java.lang.IllegalStateException: Pod has terminated containers: default/windows-test-8-hn1vc-q3pg0-k4x83 (jnlp, shell)
	at org.csanchez.jenkins.plugins.kubernetes.AllContainersRunningPodWatcher.periodicAwait(AllContainersRunningPodWatcher.java:183)
	at org.csanchez.jenkins.plugins.kubernetes.AllContainersRunningPodWatcher.periodicAwait(AllContainersRunningPodWatcher.java:204)
	at org.csanchez.jenkins.plugins.kubernetes.AllContainersRunningPodWatcher.await(AllContainersRunningPodWatcher.java:144)
	at org.csanchez.jenkins.plugins.kubernetes.KubernetesLauncher.launch(KubernetesLauncher.java:139)
	at hudson.slaves.SlaveComputer.lambda$_connect$0(SlaveComputer.java:292)
	at jenkins.util.ContextResettingExecutorService$2.call(ContextResettingExecutorService.java:46)
	at jenkins.security.ImpersonatingExecutorService$2.call(ImpersonatingExecutorService.java:71)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

I can deploy an image via kubectl apply -f jenkins-windows.yaml with the following template successfully:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: jenkins-windows
  labels:
    app: jenkins-windows
spec:
  replicas: 0
  selector:
    matchLabels:
      app: jenkins-windows
  template:
    metadata:
      labels:
        app: jenkins-windows
    spec:
      nodeSelector:
        kubernetes.io/os: windows
      containers:
      - name: jnlp
        image: jenkins/jnlp-agent:latest-windows
      - name: shell
        image: mcr.microsoft.com/powershell:preview-windowsservercore-1809
        ports:
        - containerPort: 80

I'm not sure how to debug this really. The error says The system cannot find the file specified but I am not sure what file this refers to. Is it related to workspaceVolume not being set? I would have thought the sample pipeline would work without that though (and I don't yet know how to configure that).
Any help would be really appreciated else I will have to drop Kubernetes and just use VMs.
For good measure here is also the log from the job:
Created Pod: windows-test-9-mdt6s-t2kj3-dsr2n in namespace default
Still waiting to schedule task
‘windows-test-9-mdt6s-t2kj3-dsr2n’ is offline
Created Pod: windows-test-9-mdt6s-t2kj3-dcqvw in namespace default
Created Pod: windows-test-9-mdt6s-t2kj3-kvr05 in namespace default
Created Pod: windows-test-9-mdt6s-t2kj3-k9v52 in namespace default
Created Pod: windows-test-9-mdt6s-t2kj3-tbn3g in namespace default
Created Pod: windows-test-9-mdt6s-t2kj3-2qv1t in namespace default
Aborted by admin

I forgot to mention that linux based pods work fine.

Wrong repo sorry.

Actually the proper repo doesn't have an issue tracker, does anyone know where to ask for help?

maybe this helps someone in the future:
I had the same issue, if i used the mcr.microsoft.com/dotnet/framework/sdk:4.8 image directly in jenkins, it worked.
when I build a custom image based on mcr.microsoft.com/dotnet/framework/sdk:4.8, the jenkins job did not work anymore. The error for me was misleading, but in the end the fix was pinning the dotnet image even more, to:
mcr.microsoft.com/dotnet/framework/sdk:4.8-windowsservercore-ltsc2019

turns out, when i was building the custom image, i was using windows server 2022, but both the jnlp container and the hosts where eks is running was using windows server 2019.


Fixed react warning: switching input element from uncontrolled to con…

Making display of date dependent on "value" prop causes react to display a warning and also causes quirky display when clearing the field. This should fix #27

Thanks!


Add a new RFC for cloud event data mapping

This is work in progress. You are welcome to comment, propose changes, or even for the repository and create PRs for the branch this PR is based on.
Also see: https://github.com/drogue-iot/drogue-cloud/issues/29

Hi @ctron
I have done a bit more digging with the GCP equivalent (by no means exemplar), UDMI envelope as well as other examples are on the CloudEvents adapters page.
Google adopt a layered approach where eventarc provides the CloudEvents headers, followed by their own custom event data format generated by the MQTT endpoint which is actually part of the payload including their additional IoT attributes followed by the payload itself.  I think if Drogue can populate the CloudEvents headers in a more complete way the middle event data format can be removed.
A lot of this information can be included in the source attribute as per your draft document.  This could mitigate the need for the deviceid extension attribute.  Regarding the existing device_id attribute I believe if it is kept the snake case should be dropped as per https://github.com/cloudevents/spec/pull/321.
It looks like the type should be something Drogue IoT specific e.g. io.drogue.message_published.
The subject could be passed through from the subFolder property of the MQTT topic as per the UDMI envelope.  This could include things like telemetry and command as used by Hono or pointset, config, metadata etc. as used by UDMI.
Examples below are in json but the CloudEvents headers would most likely be sent to knative as HTTP headers.
Proposed Drogue IoT:
{
  "specversion": "1.0",
  "id": "b280e845-b3c5-458f-af84-896f90bd2019",
  "source": "//example.com/my-tenant/my-device",
  "type": "io.drogue.message_published",
  "datacontenttype": "application/json",
  "time": "2021-02-11T13:52:25.646Z",
  "subject": "pointset",
  "dataschema": "https://raw.githubusercontent.com/faucetsdn/udmi/1.3.6/schema/event_pointset.json",
  "data": {
    "version": 1,
    "timestamp": "2021-02-11T13:52:25Z",
    "points": {
      "recalcitrant_angle": { "present_value": 40 },
      "faulty_finding": { "present_value": false },
      "superimposition_reading": { "present_value": 72 }
    }
  }
}

GCP IoT Core + eventarc:
{
 "specversion": "1.0",
 "id": "2008878765719495",
 "source": "//pubsub.googleapis.com/projects/my-project/topics/my-iot-project",
 "type": "google.cloud.pubsub.topic.v1.messagePublished",
 "datacontenttype": "application/json",
 "time": "2021-02-11T13:52:25.646Z",
 "data": {
   "message": {
     "attributes": {
       "deviceId": "my-device",
       "deviceNumId": "2852723095039291",
       "deviceRegistryId": "my-iot-project",
       "deviceRegistryLocation": "europe-west1",
       "projectId": "my-project",
       "subFolder": "pointset"
     },
     "data": {
       "version": 1,
       "timestamp": "2021-02-11T13:52:25Z",
       "points": {
         "recalcitrant_angle": { "present_value": 40 },
         "faulty_finding": { "present_value": false },
         "superimposition_reading": { "present_value": 72 }
       }
     },
     "messageId": "2008878765719495",
     "message_id": "2008878765719495",
     "publishTime": "2021-02-11T13:52:25.646Z",
     "publish_time": "2021-02-11T13:52:25.646Z"
   },
   "subscription": "projects/my-project/subscriptions/eventarc-europe-west1-trigger-pubsub-sub-249"
 }
}

@garyedwards This is great, I really like it!
What do you think about adding application (the field formerly known as tenant) and device additionally to the extension attributes? I understand that it would not be necessary, but that way you can directly extract them (e.g. for filtering) without the need to split strings.
I already changed device_id to device in the current main branch. That was a mistake, one that the rust cloudevents SDK didn't spot, but the Java SDK rejected :grin:

I also think that we should support the portioning extension: https://github.com/cloudevents/spec/blob/v1.0.1/extensions/partitioning.md … and probably fill it with a app/device ID combination.

I think device and application would make sense to include to allow filtering to be as simple as possible.
The UDMI envelope.json does a pretty good job at picking out useful additional attributes for IoT.
I am not sure if projectId and deviceNumId make sense in Drogue but could be pretty handy if available.
I have not used partitioning, it looks like it would be specific to the internal workings of Drogue.  I guess if used it would also make sense to include the aforementioned projectID if available.  How would it look different from the source?
Regarding naming, you could follow UDMI and just drop the camel case. I think your proposed naming looks cleaner but could be a XKCD 927 situation.  I guess other systems use different naming anyway and it would be simple to map between:

projectId = project?? Id of Drogue instance?  Maybe the hostname although this may differ per endpoint?
deviceRegistryId = application
deviceNumId = deviceuuid?? Does Drogue give a device a UUID in addition the name provided on creation?
deviceId = device
subFolder = subject part of the main ca spec derived from MQTT topic as per previous comment.

Drogue flavour:
{
  "specversion": "1.0",
  "id": "b280e845-b3c5-458f-af84-896f90bd2019",
  "source": "//example.com/my-application/my-device",
  "type": "io.drogue.message_published",
  "datacontenttype": "application/json",
  "time": "2021-02-11T13:52:25.646Z",
  "subject": "pointset",
  "dataschema": "https://raw.githubusercontent.com/faucetsdn/udmi/1.3.6/schema/event_pointset.json",
  "project": "example.com",
  "application": "my-application",
  "device": "my-device",
  "deviceuuid": "40b6a495-b92c-4a71-b5f2-ea8b9ac6fbcf",
  "data": {
    "version": 1,
    "timestamp": "2021-02-11T13:52:25Z",
    "points": {
      "recalcitrant_angle": { "present_value": 40 },
      "faulty_finding": { "present_value": false },
      "superimposition_reading": { "present_value": 72 }
    }
  }
}

Drogue UDMI flavour:
{
  "specversion": "1.0",
  "id": "b280e845-b3c5-458f-af84-896f90bd2019",
  "source": "//example.com/my-application/my-device",
  "type": "io.drogue.message_published",
  "datacontenttype": "application/json",
  "time": "2021-02-11T13:52:25.646Z",
  "subject": "pointset",
  "dataschema": "https://raw.githubusercontent.com/faucetsdn/udmi/1.3.6/schema/event_pointset.json",
  "projectid": "example.com",
  "deviceregistryid": "my-application",
  "deviceid": "my-device",
  "devicenumid": "40b6a495-b92c-4a71-b5f2-ea8b9ac6fbcf",
  "data": {
    "version": 1,
    "timestamp": "2021-02-11T13:52:25Z",
    "points": {
      "recalcitrant_angle": { "present_value": 40 },
      "faulty_finding": { "present_value": false },
      "superimposition_reading": { "present_value": 72 }
    }
  }
}

I also think that we should support the portioning extension: https://github.com/cloudevents/spec/blob/v1.0.1/extensions/partitioning.md … and probably fill it with a app/device ID combination.

In most messaging systems, messages within a partition provides guaranteed ordering of events, so I think a particular application consuming events will prefer some notion of ordering within an app + device.

@garyedwards This is great input! I really appreciate it. I hope this goes into the right direction for you as well!

Regarding naming, you could follow UDMI and just drop the camel case. I think your proposed naming looks cleaner but could be a XKCD 927 situation.

Yea, there are lots of other mappings. If considering UDMI, then we would also need to evaluate other standards, and find a common denominator. And I am not sure if that time is well invested. I think we should spend the time on making this look nice in the context of Drogue, and then spend some time on exemplary mappings to other standards. Same for OPC UA, probably Sparkplug, and a "few" others :grinning:

Does Drogue give a device a UUID in addition the name provided on creation?

Currently no. But that might be an interesting idea. Currently the ID of the device is assigned by the user. However, every device has a set of aliases, one being the ID itself. That allows you to create and replace a device later on, keeping the ID stable on the cloud side. If we would make the initial ID optional, and put a UUID in place, then we would have the same feature I guess. Which means that we would need to put in fields in the event for "reported device id" (as reported by the device) and "stored device id" (as stored in the registry). The "stored" ID should go out on the cloud side, while we could add the "reported" to the events as well. That should allow the device and deviceuuid fields, if needed.

I am not sure if projectId and deviceNumId make sense in Drogue but could be pretty handy if available.

I am not sure what the meaning of deviceRegistryId is, or projectid. It sounds a bit like project would be the application. And device registry would be the instance. In any case, if we add some static "instance id", then we would have both values, and could map them to e.g. UDMI. So the new information would be instance I guess.
As Ulf mentioned, the partionkey is more an internal field, which we would need to set for Kafka to keep an order that makes sense for the consumer. A combination of application/device makes sense, as that would mean that an application would receive messages in order per-device. When we move to a per-application Kafka topic in the future, we could drop the application part from the key and simply use the device ID as key.
I guess two things we didn't really think about are timestamp (source, received, …) and gateways. Currently there is no "received by gateway X" indication in the event. As a gateway is just another device in the same application, I guess a simple gateway (ID) field would be sufficient.

@ctron defiantly going in the right direction, this is a really great project.  Agree there are many standard, better to make it work for Drogue and map later.  I think projectid = instance and deviceRegistryId = application per the Drogue glossary so instance would be the new extension attribute as you say:

instance
application
device

deviceuuid would be a nice to have depending on how data is being used downstream.  It sounds like the registry is not set up in this way at the moment and application/device would be unique anyway.
I think time is handled correctly at the moment being when the message is received by Drogue.  If the device generates a timestamp this should be in the payload which Drogue will not necessarily understand.  For the gateway this could refer to the "authenticated device" which would always be populated by the gateway or device.  This may be less legible though and gateway is just turned on and off in the attributes as needed.
I did notice that a lot of my suggestion where already implemented in 0.2.0 so have re invented the wheel a bit in my comments. They seem to generally match which is comforting.  Looking forward to spinning up 0.3.0 for a test run on GKE and k3s.

I think time is handled correctly at the moment being when the message is received by Drogue. If the device generates a timestamp this should be in the payload which Drogue will not necessarily understand.

Good point :+1:

For the gateway this could refer to the "authenticated device" which would always be populated by the gateway or device. This may be less legible though and gateway is just turned on and off in the attributes as needed.

That is a great idea! So we would have device and gateway … where gateway would be equal to device if there is no gateway involved. Which might make it hard to understand :) … however, if we find a proper name for this field, then this would be a much better overall solution I think. authenticateddevice feels a bit too much though … via could be a candidate. peer, `by, … not sure …
We already had a discussion in the chat about writing a "book", or at least some pages of documentation. I think this would help, as "documentation" is currently spread all over the place. And is hard to track down.

Looking forward to spinning up 0.3.0 for a test run on GKE and k3s.

Awesome! I would love some feedback!

That is a great idea! So we would have device and gateway … where gateway would be equal to device if there is no gateway involved. Which might make it hard to understand :) … however, if we find a proper name for this field, then this would be a much better overall solution I think. authenticateddevice feels a bit too much though … via could be a candidate. peer, `by, … not sure …

If it's hard to find a new name, I think gateway would work just fine.

Sorry for the long delay. However, I already started to adopt the ideas from this RFC in a development branch of mine:

I added the instance field
I also used the suggested field names: instance, application, device…
I added an internal ID (borrowed uid from Kubernetes) to implement the functionality that @garyedwards described, to have an internal and a stable id. That helps detecting a delete + create operation with the same name, and also makes it easier add "names" to the entity. The special use of the id field did feel a bit awkward in the past.

I need to finish up a few things, and will come back to this in a few days.

That is a great idea! So we would have device and gateway … where gateway would be equal to device if there is no gateway involved. Which might make it hard to understand :) … however, if we find a proper name for this field, then this would be a much better overall solution I think. authenticateddevice feels a bit too much though … via could be a candidate. peer, `by, … not sure …

If it's hard to find a new name, I think gateway would work just fine.

So yes, that would work. However is would somehow imply that the event traveled through a gateway, which wouldn't be the case.
Taking a look at SMTP, we have the Received header:  https://tools.ietf.org/html/rfc5321#section-3.7.2 … However, it doesn't feel like a good fit. It is more a debugging tool, each mail gateway adding itself to the list of hops. So that would more the gateway adding itself, rather than the cloud side adding the gateway.
However, peeking at the spec if notices the header sender, which sounded like a great match to me. In indicates who "sent" the message. That could be a gateway, the device itself, another service.
So my proposal would be to use the sender field for that, always filling this with the ID/name of the device that sent the information.

I found some time (and need :grin:) to update the RFC, integrating the comments/feedback. Thanks for that!
I think this looks good. I am only not completely sure about the *uid variants of application and device. Because not only the device has a UID, but the application too. It adds more the overall event size, it is worth it? I don't know. More information is better. Less bytes too :)
I still kept it in there, as I don't see another way to obtain this information through a different way.

I am only not completely sure about the *uid variants of application and device

I think deviceuid is the key one.  application and instance are likely to be more limited in number and be more deliberately controlled / named when compared to devices.  Ideally care is taken when naming everything...  I think it is reasonable to keep deviceuid and drop the other *uid to keep the size down.  Also you can find the application and instance from the device registry with the deviceuid but not the other way around.


Swift 4 Compiler Error

Issue persists on current version.
Simple fix to remove the parenthesis after the .progress case.

@laohanme you should use the release/swift4
pod 'PKHUD', :git => 'https://github.com/pkluz/PKHUD.git', :branch => 'release/swift4'

Thanks for the answer

You are welcome. As soon I fix the issue with Objc I will release a new pod version


Avoid string allocations in AlphCompare

Related to https://github.com/godotengine/godot/issues/13199, https://github.com/godotengine/godot/pull/14717
Without PR, one call of ClassDB::get_api_hash takes 24 ms on my machine, with the PR this goes down to 11 ms.
Details: the sort using AlphCompare is the main hit in ClassDB::get_api_hash:

sort is slow due to the string management in AlphCompare::operator():

With PR, sort no longer rules the profiling:

@akien-mga I don't remember why why didn't merge this one

IIRC from irc talks, remi said he didn't want it in beta2.

Ah yeah we were supposed to merge afterwards
On Dec 27, 2017 1:46 AM, "qotob"<EMAIL_ADDRESS>wrote:

IIRC from irc talks, remi said he didn't want it in beta2.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/pull/14744#issuecomment-354051465,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z20iu_zDhIwISwptmMezBzMTGBox0ks5tEcubgaJpZM4REXIK
.

OK guys, test and make sure nothing breaks


Both log4j-over-slf4j.jar and slf4j-log4j12.jar in the management webapp

Which may trigger an IllegalArgumentException at startup:
java.lang.IllegalStateException: Detected both log4j-over-slf4j.jar AND slf4j-log4j12.jar on the class path, preempting StackOverflowError. See also http://www.slf4j.org/codes.html#log4jDelegationLoop for more details.

i think it is  better to give proper link to solution instead of un-useful discussion.

I opened an issue and provided the PR, not sure to understand what you mean by "un-useful discussion".

i resolved this issue  in two ways,
i) remove the log4j-over-slf4j.jar  if existed (or)
ii) remove the log4j-over-slf4j.jar(here i used storm,so i removed this jar from "/storm/lib/"

The issue is resolved and is linked to the pull request that provides a solution. Is there more we could help you with?


Evaluate dns-autoscaler as replacement of HPA for CoreDNS

How to categorize this issue?

/area auto-scaling networking
/kind enhancement
/priority 3
What would you like to be added:
Evaluate dns-autoscaler as replacement of HPA for CoreDNS.
Currently simple horizontal pod autoscaler that scales based on the CPU usage. The community provides a guideline how dns-autoscaler to be used for the CoreDNS. This solution also respect the size of the cluster and can help in large clusters.
Why is this needed:

/cc @DockToFuture @ScheererJ Seems to use https://github.com/kubernetes-sigs/cluster-proportional-autoscaler under hood, which we were talking about just now. Thanks @vpnachev !

/remove lifecycle/stale

I would like to introduce the cluster proportional dns autoscaling as described in the guideline as an option next to the existing horizontal pod autoscaling of core dns. Both approaches have up- and downsides. While the former one takes the cluster size into account, the latter one considers the actual cpu load. Therefore, I believe it would be beneficial if operators could choose between both modes of operation depending on their scenario.
As the switch is not only temporary, I think it makes sense to extend the shoot cluster specification accordingly. My proposal is to add an autoscaling flag to shoot.spec.dns:
...
spec:
...
  dns:
    autoscaling: horizontal|cluster-proportional
    domain: ...
    providers: ...
...

What do you think?

shoot.spec.dns is about the external address of the API of the cluster and also some DNS configurations for the requested hostname, i.e. it is not about the CoreDNS.
Personally, I think it should be in shoot.spec.addons.

I am with @vpnachev, though, maybe we should introduce a new section .spec.systemComponents and can have .spec.systemComponents.coreDNS.autoscaling.mode: horizontal|cluster-proportional. The .spec.addons section was always referring to optional components like k-dashboard or nginx-ingress. WDYT?

Hmm... I have difficulties with this proposal in general. If you make it configurable, I see mostly downsides:

We have the effort to offer that
We have the burden to maintain both approaches
We will be asked for a recommendation anyway, because how should people know
We will be confronted with the statement that it's our responsibility to do it right (no other managed service provider offers that as a configuration option)
Above else, if it fails, we cannot deflect to the cluster owners and they will still insist that it's our responsibility (and it is)
And if they switch and it doesn't work, then for other reasons, we are back at square one

So, I have difficulties. Why are these thoughts wrong? If they are not, shouldn't we rather hold our horses and think about a better solution? If both approaches have flaws and neither we nor the cluster owners know what's better, then we should not do something hastily and reconsider our options again, should we not?

@vlerenc From my perspective, the main reason for making it configurable was that we will need a longer period of time to switch from one solution to another for such a crucial thing as dns. In the discussion with @rfranzke annotations came up as an option, but was voted against as ugly if it was to stay like that mid term. Therefore, the idea was to introduce something in the shoot spec instead.
In general, I believe our current solution for dns autoscaling is very limited. We have already seen some clusters (most recently in December) hitting the limits of the 5 coredns replicas. A mitigation for this is node-local-dns with its own set of problems, especially when switching it off again (essentially requiring to roll the cluster). The dns-autoscaler as linked in the issue mostly falls in between the current solution and a solution with node-local-dns, but it can add more flexibility in terms of configuration (if we want to allow it). The only downside it can have is that for smaller clusters it might result in less coredns replicas than the existing solution. This is why I would not want to switch everything automatically and cautiously move slowly.
Not sure why you assume that there would be no default/documentation when both are standard in the gardener context. To spill it out load: I want to have a default option and this default might change over time. We could provide more flexibility in terms of configuration in that cluster operators could adapt the autoscaling according to their needs, e.g. if a cluster simply performs more dns queries it could increase the number of replicas.
For me, the goal would be to move over completely to dns-autoscaler in the long run, but this might take a long time (read: year(s)). Please let me know in case you

agree with the approach/proposal
disagree and want to stay with the current dns solution (Then we might want to close the issue.)

Obviously, any feedback in between is also welcome.

Thanks @ScheererJ @DockToFuture for the out-of-band discussion. Now I understand better and indeed, I share your view that we should make it configurable (as part of the shoot spec). Not so much as a temporary solution to test the auto-scaler, as I initially thought was the intention, but, as you have pointed out, as means to allow stakeholders to tweak the settings should the auto-scaling solution not work as expected/good enough. We aren't in the line of fire then anymore and people can help themselves. The alternatives (or compensating side-solutions) aren't available yet (we see unbalanced DNS pod usage, so need vertical scaling as well, but VPA has many shortcomings and we haven't resolved those yet; node-local DNS has some unexplained technical issues as well that we haven't fully understood and has some limitations we haven't resolved yet). That gives us not many other options, if we want to resolve the DNS issues anytime soon, but that's what we want/need, so your proposal is the best and we should do as you suggested.

/assign @ScheererJ


Documentation not clear how to use CompareLog to add exclusion for property on specific entity.

Please can you describe how to programmatically add an exclusion for a property of a specific entity.
Could it be something like this? using SubLogs?
        var userCompareLog = new CompareLog(CompareType.Entity, CompareState.Different, nameof(User), CompareAttributes.TableName);
        userCompareLog.SubLogs.Add(new CompareLog(CompareType.Property, CompareState.Different, nameof(User.FullName), CompareAttributes.DefaultValueSql, expected: null, found: "''"));

The Suppress errors via AddIgnoreCompareLog explains how to suppress a general set of errors. That means it any CompareLog that matches. That means you can't match to a CompareLog and its SubLog.


Load dpctl lib on Linux using libDPCTLSyclInterface.so.0

Fixes #700.
Issue in dpctl: https://github.com/IntelPython/dpctl/issues/777

It is great that you pinned the problem to the issue with loading the DPCTLSyclInterface, but the proposed solution is not right.
We should load .so files instead, or why keep the .so file otherwise? Can you check if in your layout the .so and .so.0 files are symbolic links, or hard files?

Thanks for IntelPython/dpctl#777. Once this is fixed, this fix wont be necessary

We should load .so files instead, or why keep the .so file otherwise?

I think it is normal to pin to .so.0. It pins to compatible version like other so libraries do.

The real reason why the fix works is that it makes llvm permanently load the same hard file library that the CPython native extensions open:
(dev) [08:49:00 vmlin numba-dppy]$ ldd <elided>/envs/dev/lib/python3.9/site-packages/dpctl/_sycl_queue.cp*
        linux-vdso.so.1 (0x00007ffea0f68000)
        libDPCTLSyclInterface.so.0 => <elided>/envs/dev/lib/python3.9/site-packages/dpctl/libDPCTLSyclInterface.so.0 (0x00007feef9d95000)
        libstdc++.so.6 => <elided>/envs/dev/lib/python3.9/site-packages/dpctl/../../../libstdc++.so.6 (0x00007feef9c20000)

The merge fix hard codes the happenstance, but if the dpctl native extensions are post processed with readelf to relink them to a different hard copy of the library the problem will return.
The key is to maintain consistency between what shared objects of native extensions link to with what ll.load_library_permanently loads.
For this consistency to be maintained the path to open should be determined dynamically from shared objects of dpctl extensions. This determination is best delegated to dpctl itself.


add BLOCK_SHELL_TASK to CCM delegate guide

Thanks for contributing to the Harness Developer Hub! Our code owners will review your submission.
Description
Need to document the ability to block a delegate from taking shell tasks when installing a delegate for pure CCM usage.

Please describe your changes: __________________________________
Jira/GitHub Issue numbers (if any): ______________________________
Preview links/images (Internal contributors only): __________________

PR lifecycle
We aim to merge PRs within one week or less, but delays happen sometimes.
If your PR is open longer than two weeks without any human activity, please tag a code owner in a comment.
PRs must meet these requirements to be merged:

[ ] Successful preview build.
[ ] Code owner review.
[ ] No merge conflicts.
[ ] Release notes/new features docs: Feature/version released to at least one prod environment.

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

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://66632a3b802ab04705d65891--harness-developer.netlify.app


docker-machine upgrade for vbox will not work if machine is powered off when command is invoked

This one is funny to me.  If the machine is powered off, we cannot actually call over SSH to get /etc/os-release, so we cannot actually run the upgrade because this hangs forever.  Guess we need to either power the machine on first (hack, as it will then immediately get turned off) or start storing OS information locally / in the Driver so that we can access it later.  I think we should do (1) for the short term, and consider the latter for the future.  cc @ehazlett

I agree -- option 1 to start.  Option 2 brings an entirely different set of potential issues.  I think it's OK to start it then upgrade.

SGTM -- I will put in a PR for this today

awesome thx!


Wait for step conditions in Install

Moves time.Duration values used by context.WithTimeout and wait.PollImmediateUntil into waitParameters structs within the Installer struct.
The new field in the Installer struct, timing, is a map of strings to waitParameters structs. The strings refer to blocks of code, some of which are in functions bearing the same name.
Centralizing this timing information would make it easier to make future changes to timeout and interval values throughout the install process.

im up for it. Anything, that collapses distributed hardcoded values is good. im just trying (in my head) to come up with a unit test, which would make use of this? Wouldn't we mock those calls and timeout would not be applicable for us?

im up for it. Anything, that collapses distributed hardcoded values is good. im just trying (in my head) to come up with a unit test, which would make use of this? Wouldn't we mock those calls and timeout would not be applicable for us?

That's a good point - if we mock everything properly, then we shouldn't have to worry about that.
I was unsure about where to put these duration values and how to access them. As you said, it still seems better to not hardcode the values throughout the install process. Is this solution viable, or should I just close this PR and we can revisit how we want to refactor this later?

@nilsanderselde let's discuss this on Bluejeans.

/azp run e2e

/azp run E2E

Hoping we can run an e2e on this before merging, watch this space.

/azp run e2e

hmm, auth issue on backend.  I'm going to merge this.


Fork pyxrootd

This resolves a bug in the processor.run_uproot_job tool which causes things to completely hang if using futures_executor with xrootd files.

I found a better solution, going into uproot


Upgrade antd to 3.4.3

Keeping on top of antd releases. There are no visible changes to the UI.
This is the result of running yarn upgrade antd.
If you're running this locally you'll need to run yarn before running yarn webpack etc.

hmmmm bin/docker-build completes with no errors for me :(

@siggy perhaps that was a transient networking issue?  This builds cleanly for me.


Where is region_txt2img_sample2.json?

area3.zip
I didn't keep it on hand, but it's just a different mask to refer to.


trying the model on fresh datasets

Hi!
I trained the model according to your instructions (with laptop dataset) and now I want to test the model on a different dataset, like the restaurant dataset of SemEval14.  I have some questions:
1) I already put my state-dict file in the inferring_dataset folder.  I don't know what to add as my inferring dataset here (can I just add Restaurants_Test_Gold.xml.seg from datasets/apc_datasets/semeval2014 ?)
2) Where should I add the path and name of the dataset I want to do the inferring on?

Um, why do you want to test the trained model on uncorresponded dataset?
Anyhow, follow the format of given examples for infering, the code detects corresponding file by https://github.com/yangheng95/LC-ABSA/blob/90ae7f41b3766761005caf015292926127fe3949/apc_infer.py#L147
Just keep the hyperparameters intact as training process.

I want to extract aspects and their corresponding sentiments and their polarities in a certain document or just a sentence.

Hello,
How can I test the model I trained on laptop dataset on restaurant dataset to see it's accuracy?

See the aspect term extraction and sentiment classification tutorial https://github.com/yangheng95/pyabsa/tree/release/examples/aspect_term_extraction.


Movenet update requirements

The original pytorch version specified in the movenet requirements is outdated, and not compatible with recent NVIDIA GPUs (e.g. RTX 3000 series), resulting in the inability to run the pose detection algorithm, throwing
RuntimeError: CUDA error: no kernel image is available for execution on the device

Beside pytorch, related libraries have been updated for compatibility.

I managed to test this and everything seems to work fine also on our machines.
the install process takes a lot longer at this point: I think it is related to torchvision==0.15.0 in that it says it is incompatible and needs to yoink a specific commit version. then it installs a whole bunch of different versions of what seem like cuda libraries.
The final image size goes from 6.5GB to 10GB
I can merge this request but if you have any easy way to test to see if some different combination of versions may improve the docker compile time and the image size it would be great @marcogfedozzi

also @gaurvigoyal did you mange to look at this and see if it had any clashes?

I managed to test this and everything seems to work fine also on our machines. the install process takes a lot longer at this point: I think it is related to torchvision==0.15.0 in that it says it is incompatible and needs to yoink a specific commit version. then it installs a whole bunch of different versions of what seem like cuda libraries.
The final image size goes from 6.5GB to 10GB
I can merge this request but if you have any easy way to test to see if some different combination of versions may improve the docker compile time and the image size it would be great @marcogfedozzi

It might have to do with the cuda version installed in the EDPR docker container, as pytorch has dropped support for cuda<=11.6 (and that's probably why it's pulling cuda libs now).
I had already tested on my machine with cuda11.8 and saw no issue, would it be okay for me to update the EDPR dockerfile accordingly?


Please update version to support new commands

Hi
Thanks for the tool, useful.
Do you think it would be possible to update the redis server on try.redis.io to a more recent version?
For example ZRANGEBYLEX and friends are missing :(
Thanks in advance

Will do that this weekend, thanks for the reminder :)

*LEX commands are now supported by try.redis. :)


Using Retries using headers set in settings file rather than manual retries

The default headers point to envoy.
Removing the earlier retries at PynamoDB layer.
The settings can be overridden by setting the environment variable.
Default max retries is 3. Will retry on 5xx, and connect-failure.
@danielhochman  @mattklein123

Coverage decreased (-0.2%) to 97.453% when pulling 2bd73ffd50be1836b8e7399ef04960efb73c2254 on lyft:ENVOY-RETRY into 010951c4626e80ed489b3af9b667e22f52f35f12 on jlafon:devel.

Coverage decreased (-0.2%) to 97.453% when pulling 60ce2ec8b90d0f30b8883bedf4cf3c33183a9d70 on lyft:ENVOY-RETRY into 010951c4626e80ed489b3af9b667e22f52f35f12 on jlafon:devel.

Coverage decreased (-0.2%) to 97.453% when pulling a464d32b4a5259d233e6bdd49afb7136e6d605a7 on lyft:ENVOY-RETRY into 010951c4626e80ed489b3af9b667e22f52f35f12 on jlafon:devel.

Coverage decreased (-0.1%) to 97.5% when pulling 02cd6fb811857726a07100684d93a2d1f9a5bfcb on lyft:ENVOY-RETRY into ebbf3348d614008f9d2e61a94f3037e7339c9101 on jlafon:devel.

Coverage decreased (-0.1%) to 97.501% when pulling 7cc6a100a22515e2784c9c7821b86f6e5f07db87 on lyft:ENVOY-RETRY into ebbf3348d614008f9d2e61a94f3037e7339c9101 on jlafon:devel.

Coverage decreased (-0.01%) to 97.612% when pulling b6e29f8dd43780632aa44f631b829712fe49e9bb on lyft:ENVOY-RETRY into ebbf3348d614008f9d2e61a94f3037e7339c9101 on jlafon:devel.

Coverage decreased (-0.2%) to 97.404% when pulling a0af3da30a130ca0ba544bb7bf3bc2fc5874dd20 on lyft:ENVOY-RETRY into ebbf3348d614008f9d2e61a94f3037e7339c9101 on jlafon:devel.

Coverage decreased (-0.01%) to 97.612% when pulling e76b628fc316690ee14f067193e338b44999f7f5 on lyft:ENVOY-RETRY into ebbf3348d614008f9d2e61a94f3037e7339c9101 on jlafon:devel.

Coverage decreased (-0.2%) to 97.474% when pulling 74d717dceb19b3d6cb6b2c3ed12c7b243ee69e86 on lyft:ENVOY-RETRY into ebbf3348d614008f9d2e61a94f3037e7339c9101 on jlafon:devel.

Changes Unknown when pulling a5d31e3a1b969b15b58eae50a8b886e018a2bace on lyft:ENVOY-RETRY into ** on jlafon:devel**.

Changes Unknown when pulling a5d31e3a1b969b15b58eae50a8b886e018a2bace on lyft:ENVOY-RETRY into ** on jlafon:devel**.

Changes Unknown when pulling d684f8a8fd7c0366f99ee45982008002e851eaab on lyft:ENVOY-RETRY into ** on jlafon:devel**.

Changes Unknown when pulling 6916a3d2d18dac01560ed3219037ff84af193b40 on lyft:ENVOY-RETRY into ** on jlafon:devel**.

Changes Unknown when pulling 6916a3d2d18dac01560ed3219037ff84af193b40 on lyft:ENVOY-RETRY into ** on jlafon:devel**.

Changes Unknown when pulling 6fbe1fb445e37ec16823baddbcb5fee97d82b9bf on lyft:ENVOY-RETRY into ** on jlafon:devel**.

Changes Unknown when pulling a6212b481ab4c2e8889798edc4c26f8f822b85bc on lyft:ENVOY-RETRY into ** on jlafon:devel**.

Changes Unknown when pulling fa4b92a4e1b2c730abda5e32804d6135c090b45c on lyft:ENVOY-RETRY into ** on jlafon:devel**.

+1


feat: add rust-hex src

Encoding and decoding data into/from hexadecimal representation.
Log: rust-hex src would be added.
Issue: https://github.com/deepin-community/sig-deepin-sysdev-team/issues/143

@chenchongbiao 麻烦老师检查一下这个PR

/check obs

/lgtm


Ability to pull in rules from remote repos

Link to original issue on forked repo: https://github.com/inclusive-dev-tools/woke/issues/1
Problem Statement
Right now the code looks locally for the rules file, but we want to be able to source it from any public URL to allow for reuse of external rule sets
Acceptance Criteria

Ability to run the linter on a publicly accessible ruleset file by pointing to it in the cli arguments. e.g. woke -u https://raw.githubusercontent.com/get-woke/woke/main/example.yaml

This is a feature I've very much been wanting. I have some thoughts around it, but generally I'd like to be able to support:

Defining N ruleset urls as cli arguments (like you suggested, but woke doesn't support defining rulesets outside of the config yet)
Define a remote config woke -c https:///...
Extend the ruleset in your config (see https://github.com/get-woke/woke/issues/67#issuecomment-832677822)
Stretch goal: support advanced download protocols, like ssh, s3 (for private repos/buckets for example) -- Came across https://github.com/hashicorp/go-getter which is promising but it doesn't seem to work very well with single files

🎉 Released in v0.16.0


Script tags are not added to the child pages when build SSR project

Which @angular/* package(s) are the source of the bug?
Don't known / other
Is this a regression?
No
Description
In certain scenarios when we build an SSR project the child pages are not getting script tags injected, thus any interactions on that pages are impossible.
The only page the gets references to the main scripts is index.html.

If the app's root tag specified as a self-closing tag, then after building the project the app's root tag will wrap the script tags. Internal pages won't get main script tags injected.
src/index.html:
<body>
  <app-performance-root />
</body>

dist/<project-name>/browser/index.html:
<body>
  <app-performance-root>
    <script src="polyfills.js" type="module"></script>
    <script src="main.js" type="module"></script>
  </app-performance-root>
</body>

If the app's root tag specified as a "normal" html tag, then everythings builds in order. Internal pages will get main script tags injected.
src/index.html:
<body>
  <app-performance-root></app-performance-root>
</body>

dist/<project-name>/browser/index.html:
<body>
  <app-performance-root></app-performance-root>
  <script src="polyfills.js" type="module"></script>
  <script src="main.js" type="module"></script>
</body>

Please provide a link to a minimal reproduction of the bug
No response
Please provide the exception or error you saw
n/a

Please provide the environment you discovered this bug in (run ng version)
Angular CLI: 17.3.5
Node: 20.11.1
Package Manager: yarn 1.22.19
OS: macOS Sonoma 14.4.1 (23E224)

Angular: 17.3.5
... animations, cdk, cli, common, compiler, compiler-cli, core, forms, material
... platform-browser, platform-browser-dynamic, router, platform-server, ssr

Package                         Version
---------------------------------------------------------
rxjs                            7.8.1
typescript                      5.4.2

Anything else?
No response

Duplicate of https://github.com/angular/angular/issues/52922


[DO NOT MERGE] Configure esy monorepo workflow (2)

This is a 2nd attempt at esy monorepo workflow (replaces #42).
The PR works only with esy nightly builds for now:
% npm install -g @esy-nightly/esy

How it works
esy.json links to each package in the repository using
link-dev:./path/to/package.json.
Each package linked with link-dev: behaves exactly like a root package in a regular esy workflow:

Its corresponding "devDependencies" are installed
"buildDev" command is executed on build (if it's defined, falls back to "build")
Build commands have access to their corresponding "devDependencies"

Workflow
Install dependencies:
% esy install

Build dependencies (each package has access to its "devDependencies", runs
"buildDev" command if it's defined):
% esy build

Build dependencies in release mode (run "build" command w/o access to "devDependencies"):
% esy build --release

Discussion
Is it possible to run builds commands for a specified package?
Yes, use esy build-package command:
% esy build-package ./rely.json

Is it possible to run commands in a build env of a specified package?
Yes, use esy build-exec command:
% esy build-exec ./rely.json ls

The command esy build-exec CMD is an analogue of esy build CMD command but
allows to specify the package.
Is it possible to make change detection more granular?
When one changes sources (do touch ./src/console/Console.re for example) all
packages are being rebuilt (actually they are not being rebuilt, esy just runs
build commands but as dune works incrementally those commands are noop).
It's possible to make esy detect changes in a more granular fashin but that requires moving package roots into different dirs, for example:
% mv rely.json src/rely/package.json

I've experimented with this approach and it doesn't work with the current setup
for common - if we move package root to the src/ then copy_files doesn't
work as it can't copy files from outside the package root.
If we change how we vendor code from common/ dir we can enable more granular
change detection with esy.
Changes

394ecfc
Convert to esy monorepo

esy.json links to all packages via link-dev: This collects & installs
all "devDependencies" for packages and makes them available to 'build"
command (or "buildDev" if it's configured).

Fixes src/refmterr/lib/dune to have access to Common (not sure why it's
worked before).

Adds "buildDev" with refmterr for those packages
(file-context-printer) which only rely on refmterr in dev.

c53ee3f
Add @reason-native/tests package
This package hosts tests.

1d24018
Use esydune wrapper for dune
This configures "build" (and "buildDev" where needed) with esydune
instead of dune. This makes sure we invoke dune with the right arguments,
this effectively enables warnings in reason-native.
Then this commits update dune files with flags to disable erroring on 29
(unused bindings) and 9 (unbound record fields in patterns) warnings.

5310521 Update esy.lock (not for review)

% esy build --release

That seems good to have even without monorepos.

Is it possible to run builds commands for a specified package?
Yes, use esy build-package command:

% esy build-package ./rely.json
Is it possible to run commands in a build env of a specified package?
Yes, use esy build-exec command:

% esy build-exec ./rely.json ls
The command esy build-exec CMD is an analogue of esy build CMD command but
allows to specify the package.

I think these could be confusing to newcomers just because they already have to
learn esy @pkg.json cmd. It's not immediately clear to noobs how it's
different.  Also esy build-exec sounds like esy x ("esy exec").
What about:
esy build --package=./rely.json cmd

Then it's clear this is just an extension of the esy build cmd command - not
something really new to learn.
This is a kind of rare command to need, so a little extra verbosity would not be bad.

It's possible to make esy detect changes in a more granular fashin but that
requires moving package roots into different dirs, for example:
% mv rely.json src/rely/package.json

I'm confused because I thought that for linked packages with out of source
builds, esy won't do anything to try to do change detection, it will just call
the build system for each linked package and expect it to be incremental.  What
would we gain by doing some more granular sub-package change detection for
linked packages if we never use that change detection for linked packages?
Other question: How was the circularity solved?

% esy build --release

That seems good to have even without monorepos.

Yep, this is needed as we've added buildDev.

Is it possible to run builds commands for a specified package?
Yes, use esy build-package command:

% esy build-package ./rely.json
Is it possible to run commands in a build env of a specified package?
Yes, use esy build-exec command:

% esy build-exec ./rely.json ls
The command esy build-exec CMD is an analogue of esy build CMD command but
allows to specify the package.

I think these could be confusing to newcomers just because they already have to
learn esy @pkg.json cmd. It's not immediately clear to noobs how it's
different.  Also esy build-exec sounds like esy x ("esy exec").
What about:
esy build --package=./rely.json cmd

Then it's clear this is just an extension of the esy build cmd command - not
something really new to learn.
This is a kind of rare command to need, so a little extra verbosity would not be bad.
It's possible to make esy detect changes in a more granular fashin but that
requires moving package roots into different dirs, for example:
% mv rely.json src/rely/package.json

This can be done for esy build CMD but:

cmdliner doesn't expose the API for that and thus I have a hardcoded hack
for --release arg, we can add the same hack for --package PKG too.
Other commands like esy build-plan / build-env / ... already accept package
as position argument. Though I suppose we can change that.

Overall - I agree, let's implement it that way instead of adding a new command.

I'm confused because I thought that for linked packages with out of source
builds, esy won't do anything to try to do change detection, it will just call
the build system for each linked package and expect it to be incremental.  What
would we gain by doing some more granular sub-package change detection for
linked packages if we never use that change detection for linked packages?

Other question: How was the circularity solved?

Packages now specify their dependencies/devDependencies in their own
package.json files and thus they control circularity with needed granularity:

Those packages which refmterr depend on can't specify refmterr as devDep
Others can

I'm confused because I thought that for linked packages with out of source
builds, esy won't do anything to try to do change detection, it will just call
the build system for each linked package and expect it to be incremental.  What
would we gain by doing some more granular sub-package change detection for
linked packages if we never use that change detection for linked packages?

Nope, we always check for staleness but I think we could indeed don't do that for out of source builds.

New CLI in latest nightly allows to use esy build CMD with -p/--package option to target specific packages, for example:
% esy build -p ./rely.json dune runtest

Therefore esy build-exec is no longer needed.

Looking really good!
I think we really need an esy version field in the json asap. I wish we had one already supported earlier because then we could just land this, and users on older versions of esy would get a nice error message saying they need to do npm remove -g esy && npm install -g esy

I'm guessing this is no longer relevant and can be closed given how old it is.


MandelbrotDiscovery seems to be broken

MandelbrotDiscovery seems to be broken, as the set and calc commands work once only, then the image freezes.

Now that the upper-layer interface adds the graphic-file suffix, Discovery was actually creating files with two suffices. This is a very simple repair, now cycling in #145.


Context manager leads to unbound variables if __exit__ explicitly returns Literal[False]

Environment data

Language Server version: 2021.6.1-pre.1
OS and version: Windows 7
Python version (& distribution if applicable, e.g. Anaconda): 3.8.10 Anaconda

Sample
from typing import Literal

class C0:
    def __enter__(self) -> None:
        pass
    def __exit__(self, *args, **kwargs):  # (method) __exit__: (self: C0) -> Literal[False]
        return False

class C1:
    def __enter__(self) -> None:
        pass
    def __exit__(self, *args, **kwargs) -> Literal[False]:  # (method) __exit__: (self: C1) -> Literal[False]
        return False

with C0():
    a = 0
print(a)

with C1():
    b = 0
print(b)

C0 and C1 are similar except for that the return type of C1.__exit__ is declared explicitly.
Expected behavior
Both a and b are bound before being printed.
Actual behavior
bis possibly unbound.

This is the convention adopted by type checkers and by typeshed. If __exit__ has an annotated return type that is bool, it is assumed to handle exceptions. If it is unannotated or explicitly annotated to return None, it is assumed to not handle exceptions. If you want to indicate that your context manager doesn't handle exceptions, you should annotated it to return None.

Got it.


Navigation bar overlaps the content below

Hello.
How can I make navigation bar to not overlaps the content?

+1

Try adding
sceneStyle={{paddingTop: 64}}

to your Router.
See issue #103.


RFC: Adding a backend for HPy.

This PR is a first effort for the long-term goal to add an HPy backend to Cython. The main objective here is to get some feedback on how to structure the code and what else needs to be considered. So, this is an explicit request for comments.
The main idea is to move C code generation into the CCodeWriter. For that, I've introduced a new class HPyCodeWriter that inherits from CCodeWriter and the new writer emits HPy API calls/code instead of CPython API calls/code. Then, we can use two different writers to run the same generation step.
As we have already discussed in a meeting on September 3rd, 2021 with @scoder, Cython now emits C API and HPy API code and the different sections are protected by ifdefs like this:
# ifndef HPY
  /* C API code */
#endif

#ifdef HPY
  /* HPy API code */
#endif

This is realized by introducing code sections for HPy (see Code.py: code_layout).
Some of the sections are independent of the API and can be shared (e.g. string_decls which defines global const char * variables).
A lot of work still needs to be done (of course) but the first simple example hpy_basic.py is already working (C only).

Wow, thanks. That's … huge. :)
Do I understand correctly that this duplicates the C code, using two separate code writers? Or is the duplication limited to certain sections or constructs?
What I would like to avoid is that we end up with two separate copies of the user code in the same file. I was hoping that we could do as much as possible through C macros, without actually duplicating generated code.

Do I understand correctly that this duplicates the C code, using two separate code writers? Or is the duplication limited to certain sections or constructs?

The duplication is limited to certain sections. The easiest for now was to introduce respective sections as specified in GlobalState.code_layout. The HPy-specific sections have prefix hpy_sectionname. If there is such a section, the hpy_sectionname is surrounded by #ifdef HPY ... #endif and the related section sectionname is surrounded by #ifndef HPY ... #endif.
I've tried to share any API independent code. For example, section string_decls is not duplicated.
This is, maybe, one of the main question: what should be the granularity of sharing. My opinion was that multiplexing code on a statement-level is too fine-grained.
Also, it would in some cases just not work out because we need to generate a significantly different structure. One example would be Python types: While it is common to define and fill a static type struct in the C API, for HPy we will need to generate a type specification.

What I would like to avoid is that we end up with two separate copies of the user code in the same file. I was hoping that we could do as much as possible through C macros, without actually duplicating generated code.

I absolutely agree. I will do my best to share as much code as possible. Sometimes it's just a trade-off between Cython source code complexity and generate source code sharing.

@scoder Thanks for your comments. My main question, of course, is: How should I proceed? Is it fine to move code generation into the code writers? Or should we have a separate utility for that?
It may also be interesting to look at the generated C code of the hpy_basic example (see attachment hpy_basic.c.gz ).

I mostly agree with @da-woods regarding the code writer changes. Anything that is specific to the way a syntax node (or a certain kind of nodes) generates code should stay in the node classes. I'm not convinced yet that we need a second kind of code writer. If we can solve the issue with C macros, then we should.

* I'm not completely sure where we draw the distinction, but HPy feels more like a ["compiler option"](https://cython.readthedocs.io/en/latest/src/userguide/source_files_and_compilation.html#compiler-options) than a compiler directive to me.

I agree. Also that the distinction isn't very clear. :)
This feature leads to a potentially large amount of additional code being generated, in which case users should enable it very explicitly. However, I do still hope that the amount won't be that large in the end. (Which reminds me that this huge bunch of defines from the module state struct code still needs to be cleaned out…)

  1. For every module we generate both HPy and CPython code, and select between them by passing a C compiler define. This matches what we currently do, and I think was the solution that @scoder was keen on
  2. Based on what the user requests, we generate _only_ of HPy or CPython code. I think this is closer to what you're doing.

  Personally, I was always more comfortable with option 2 - I thought that the two interfaces were sufficiently different that it'd be hard to do only with `#define`s.

I was thinking that Cython should generate more HPy-like code and map that back to "legacy" C-API code with C macros. My impression was that this approach might be easier than the other way, since HPy makes stricter assumptions. Also, since HPy code is supposed to work on CPython, that layer partly already exists. Although it probably needs to be tuned for Cython to avoid any regressions.

For example, I believe that HPy will distinguish between long-lived references (objects in a class or a generator) and short-lived references (objects in a function), which isn't a distinction that Cython currently makes.

Interesting. I wasn't aware that such a distinction was needed. Why is that?

While it is common to define and fill a static type struct in the C API, for HPy we will need to generate a type specification.

We already generate type specs for CPython. HPy could either use those, adapt those as needed, or add one more (in the order of preference).

For example, I believe that HPy will distinguish between long-lived references (objects in a class or a generator) and short-lived references (objects in a function), which isn't a distinction that Cython currently makes.

Interesting. I wasn't aware that such a distinction was needed. Why is that?

Quoting from https://docs.hpyproject.org/en/latest/overview.html:

handles are intended to be short-lived, but sometimes one needs a long-lived reference to a Python object. In HPy, we call this long-lived reference an HPyField, but we still need to implement it. We also need HPy_Store and HPy_Load to save and load these fields. This will allow alternative implementations to use a moving GC.

Quoting from https://docs.hpyproject.org/en/latest/overview.html:

handles are intended to be short-lived, but sometimes one needs a long-lived reference to a Python object. In HPy, we call this long-lived reference an HPyField, but we still need to implement it. We also need HPy_Store and HPy_Load to save and load these fields. This will allow alternative implementations to use a moving GC.

I don't think that's actually implemented yet though... (edit: yes it actually says that and I just didn't read thoroughly)

Hmm. Is that a strict requirement, though? I'd rather get things working without this, and then adapt where we deem it helpful. Globals are probably ok, but I'm not sure yet about object struct references. Let's try not to optimise prematurely here.

Hmm. Is that a strict requirement, though? I'd rather get things working without this, and then adapt where we deem it helpful. Globals are probably ok, but I'm not sure yet about object struct references. Let's try not to optimise prematurely here.

I think it's probably not a strict requirement given it's on the HPy plan but not yet implemented. I expect it'll reduce the performance of some GCs rather than break anything.

Again, thanks for your feedback.

I mostly agree with @da-woods regarding the code writer changes.

Okay, I'll move that code back to the nodes. I'm currently experimenting with using more meta-programming do solve that problem. For example: I've introduced a macro __Pyx_OBJECT_CTYPE which is PyObject * for the C API and HPy for HPy.

I'm not completely sure where we draw the distinction, but HPy feels more like a "compiler option" than a compiler directive to me.

That's, ofc, fine for me. I'll go for the compiler option. If I understood correctly: Cython should only generate HPy code if this option is enabled, right?

I was thinking that Cython should generate more HPy-like code and map that back to "legacy" C-API code with C macros. My impression was that this approach might be easier than the other way, since HPy makes stricter assumptions.

Sounds good.
Concerning HPyField: Yes, it's already implemented but not included in any release yet. We plan to include it in HPy 0.0.4. My current (local) changes don't use it but I think I will adopt.
The point is: In HPy, we do not guarantee that there is just one global HPy context and normal handles do only exist in the scope of an HPy context. The current HPy implementation for CPython just uses one context but that's subject to change (in particular for sub-interpreters or similar).
So, storing objects into C globals must use HPyField.
Also thanks for quoting from https://docs.hpyproject.org/en/latest/overview.html . I need to update it.
I'll incorporate your feedback and will push these changes ASAP.

Cython should only generate HPy code if this option is enabled, right?

Yes. And it should be enabled by default, as soon as there is anything useful in the port.

Sorry that it took that long but I just pushed a major update to this PR that changes a lot.
As far as I understood the comments, the main problem was that I've moved code generation into the code writers. I now reverted this and also removed the HPyCCodeWriter. Code and its structure are now generated in the same places as before.
Additionally, there are two major additions compared to the previous changes:

I'm now properly using HPyField to store objects in global variables.
I migrated the majority of the module initialization code that sets up Cython's caching of builtins and other objects.

Also, where needed, I've changed the structure of the generated code such that it suits for both, C API and HPy. For example:
For building tuples, in the C API you would just do:
PyObject *tuple = PyTuple_New(n);
PyTuple_SET_ITEM(tuple, 0, x);
PyTuple_SET_ITEM(tuple, 1, y);
...
/* use variable 'tuple' */

where in HPy you need to use a tuple builder:
HPyTupleBuilder builder = HPyTupleBuilder_New(ctx, n);
HPyTupleBuilder_Set(ctx, builder, 0, x);
HPyTupleBuilder_Set(ctx, builder, 1, y);
...
HPy tuple = HPyTupleBuilder_Build(ctx, builder);
/* use variable 'tuple' */

So, I've changed the structure in Cython such that it would work with the builder pattern but where the build step in C API is just a no-op.
In order to cover all possible use cases, I've introduced a Python class named Backend which is used to generate the API-specific code (very fine-grained). There are three API backends:

CApiBackend: generate bare C API code (as close to the state before this PR as possible)
HPyBackend: generate bare HPy API code
CombinedBackend: uses meta-programming to generate code that suites for both, C API and HPy. One can decide for which API to compile just by defining (or not) macro "HPY". So, if the cythonized code will be included in an HPy extensions, this will automatically happen. This, for example, looks like that:

  __PYX_OBJECT some_function(__PYX_CONTEXT_DECL __PYX_OBJECT x) {
      int result;
      result = __PYX_LONG_AS_INT(__PYX_CONTEXT x);
  }

where __PYX_OBJECT is a macro that defines the Python object C type which is PyObject * for the C API and HPy for HPy.
The CombinedBackend is probably the one that will in the end be the default but when we first merge changes, I would set the CApiBackend as default and this would generate code almost as before.
There are, of course, still some open points and tasks to be done before this can be merged. Here are some points I want to discuss:

How should the decision been made which backend to use? I suggest to introduce a compiler options like the language option.
Functions that return borrowed references and following increfs are in general a problem (in particular, function make_owned_reference doesn't work for HPy). Is it suitable to make all of them return a new reference?

Functions that return borrowed references and following increfs are in general a problem (in particular, function make_owned_reference doesn't work for HPy).

Why not? Doesn't it just dup() a handle if necessary?

Is it suitable to make all of them return a new reference?

I'd like to avoid that if at all possible.

in HPy you need to use a tuple builder

I wonder if we could just generate an inline helper function for each tuple length. There can't be that many different literal tuple or list sizes in a module, after all. The reference counting would still happen outside, but that function would then just steal a reference to each of its item arguments.

Has there been more progress on this? Would love to see it! Great work!

Hi @HiperMaximus , no, I'm sorry. I couldn't make progress on that since I was focusing on NumPy/HPy in the last months. @mattip tries to make some progress on this (see https://github.com/fangerer/cython/pull/1 ). We were also in the progress of figuring out how we can split this big change set into smaller pieces such that we can merge small chunks.

Hi! I was wondering, is this feature still on the list and is it possible to see it in some way in the future?

Hi @igorcoding! Yes, this is definitively something we (the HPy dev cores) want to do. This particular PR served as a proof-of-concept to explore ways how we can/should do it. Currently, I'm not personally working on this topic since I spend most of my HPy-time on HPy itself or on NumPy/HPy. However, a colleague started to work on it here.

Awesome! Great to hear!


Add gather_classes

PR corresponding to #66

I don't understand the solution. It seems unnecessarily overcomplicated

Much of this was simplified when assuming that the block_num could be reliably derived from the name. The code should be more straightforward now.


Add ability to update counters in restapi

resolves #688

Ty @dougwettlaufer for all the hard work and attention to this as a priority!
Request:
curl --location --request PUT 'https://[clusterId]-us-east1.apps.astra.datastax.com/api/rest/v2/keyspaces/memegen/memes_likes/161865971' \
--header 'X-Cassandra-Token: [authToken]' \
--header 'Content-Type: application/json' \
--data-raw '{
    "likes": "+1"
}'

Response: (200)
{
    "data": {
        "likes": "+1"
    }
}


Updated Precommit field to most recent API

Precommit v1.7 changed the field from sha to rev: https://pre-commit.com/#pre-commit-configyaml---repos

Superceded by #178 , so this can be closed.

Superceded by #178 , so this can be closed.

Agreed, thanks @CAM-Gerlach

Agreed, thanks @CAM-Gerlach


chore: add the type property to the package.json.

From the node.js docs

Package authors should include the type field, even in packages where all sources are CommonJS. Being explicit about the type of the package will future-proof the package in case the default type of Node.js ever changes, and it will also make things easier for build tools and loaders to determine how the files in the package should be interpreted.

Adding this for all the nodeshift org modules

Coverage: 100.0%. Remained the same when pulling fa31a7c0140b08ca6c9310af65344c09c8542452 on lholmquist:add-type-property into f60a73d8b5fd2103fa8baa7ff07b1f4a020f24b3 on nodeshift:main.


Machine Learning Tutorial

Can you make one on machine learning..... there are many out there but no one tells how it works means not about how our code is executing, I am talking about why and how that neural net or machine learning doing what it is doing

It may be a more advanced topic that the intended level of newcoder.

can you suggest me any tutorial?

https://github.com/hangtwenty/dive-into-machine-learning/blob/master/README.md - try this one maybe


Multiple rows in table header don't show proper borders

Consider the following table:

Weights

kg	lbs

1.0	2.20462

Since the cells are all bordered, I expected the spanning heading to also be bordered on every side, but obviously they're not here. Not sure if intentional.
I also can't control the width of the table using the grid classes.

I haven't tested this at all. I will give it a shot and see what happens and figure out the best way to deal with the issue. Thanks for reporting it!

Update
As far as multiple rows in the
 are concerned: While this is valid HTML and causes no real problems, it seems like it needs a lot of workarounds to be fully accessible (as seen here).
As far as controlling the table's width using grid classes, I consider this a bad idea, as tables do not behave properly when styled with flexbox. It's always a better idea to let tables style themselves properly. Smaller screens will change to card view to deal with the situation and, if you want to have a better time viewing tables, you can always use .horizontal tables.
Provided that none of these issues can be "fixed" in a very specific way, I will add notes and workarounds in the table module's documentation, so that people are aware of the limitations and problems that might exist.

Just some thoughts:

Nice find on the accessibility issues, so simply documenting aria-hidden requirements for such column-spanning headers would be totally fine IMO. The visual styling should just work though, and seems doable.
Re: letting tables style themselves, this isn't always feasible. It's not uncommon to have cells whose text you don't want to wrap, where other cell text can wrap as needed. I always think of widths in terms of grid columns, but that isn't necessarily applicable to any single framework. Note that you don't need to use flexbox to style the tables, you can overload the meaning of the grid classes for th/td so they work with tables.

As far as the visual styling is concerned, I will post a fix in a note or a Do section in tables, to help people get started. Lots of testing and maybe some sort of redesign might be required to make this work by default, as there are many issues that need solving in respect to tables.

Overloading the grid classes would bloat the framework quite a lot and the tradeoff is not worth all that in terms of functionality. I will look further into the matter and hopefully find a solution that is at least satisfactory enough, but I cannot promise that this will be resolved before v2.1.0. I might add this functionality in a later patch.


Allow dragging BottomSheet by grabbing Backdrop

Google Maps allows you to scroll the BottomSheet vertically by grabbing and dragging the Backdrop. Lib is missing this functionality. What do you figure is the best way to implement this?

hum? I'm a little confused, is that functionality not implemented yet? or is a different one? I mean, I just tried with the app in the market that I published last week and I can drag up or down the BottomSheet grabbing the Backdrop.

It's not working for me using the lib demo app...

Sorry I take it back! It's working - there is a problem on my end!


Access _env once baked

I bake a command and pass it to a utility which executes it.  How can I access the environment a command was baked with prior to execution?
>>> ls = sh.ls.bake(_env=os.environ)
>>> ls._env
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/jodewey/.pyenv/versions/molecule2-env-2.7.13/lib/python2.7/site-packages/sh.py", line 1219, in __getattribute__
    val = getattr(name)
AttributeError: 'Command' object has no attribute '_env'

Short answer: you can't
Longer answer: cmd._partial_call_args["env"], but you should not rely on it, since that private attribute will likely change in the future and it will break your code
Longest answer: if a function needs to know the environment of the command passed to it, you are better off passing the environment into the function along with the command, rather than trying to dig it out of the function.

Thanks @amoffat


torch.cuda.OutOfMemoryError: CUDA out of memory.

Hello, my friend
During the training of LLAMA2-13b on an A30 GPU equipped with 24GB of video memory, I am facing an error concerning GPU memory allocation. Are there any feasible solutions or code modifications that can resolve this issue?
error：torch.cuda.OutOfMemoryError: CUDA out of memory. Tried to allocate 2.00 MiB (GPU 0; 23.50 GiB total capacity; 23.16 GiB already allocated; 2.81 MiB free; 23.16 GiB reserved in total by PyTorch) If reserved memory is >> allocated memory try setting max_split_size_mb to avoid fragmentation.  See documentation for Memory Management and PYTORCH_CUDA_ALLOC_CONF
Thanks!

Our recommended setup includes an A40 (48GB) GPU for training and inference. If the CUDA memory is insufficient, you can switch to smaller models like Llama-2-7B, or reduce the batch size, among other adjustments.


Copy sigma inotify to k8s.io utils

Importing https://github.com/sigma/go-inotify into k8s.io/utils with history preserved.
needed to fix up problems mentioned here:
https://github.com/kubernetes/kubernetes/issues/75526

/assign @sigma @thockin
cc @cpuguy83

Thanks!
/lgtm
/approve

going to merge this as-is and then @Pothulapati offered to fix up the lint issues in a follow up.


gradients

Implements gradients for mark fill. For now this is only attached to area charts but that can be expanded to other mark types in the future.

example


Incorrect subscribe/unsubscribe bookend when a topic is moved from unsubscribed to subscribed stream.

A subscribe and unsubscribe bookend is added when a message is moved from an unsubscribed stream to a subscribed stream.
Steps to reproduce in dev server -

Login as 'Iago' and move a topic from a stream, say A to which cordelia is not subscribed, to a stream B to which cordelia is subscribed.
Login as 'Cordelia' and narrow to stream B and scroll to the topic which was moved. There will be subscribe and unsubscribe bookends around the moved topic.

Below is a screenshot from czo, where I have been subscribed to design stream since I joined the server and have not unsubscribed since then, but the bookend is shown around the topic alert-word-highlight which was moved from mobile-team stream, to which I am not subscribed.

Some discussion here - https://chat.zulip.org/#narrow/stream/9-issues/topic/incorrect.20subscribe.20and.20unsubscribe.20bookend

@zulipbot add "bug" "difficult"

@zulipbot claim

@zulipbot  Can I take this task?

@zulipbot claim


Never ending loop in RAMJobStore.acquireNextTriggers

the problem is in this:
while (true) {
TriggerWrapper tw;
            try {
                tw = timeTriggers.first();
                if (tw == null)
                    break;
                timeTriggers.remove(tw);
            } catch (java.util.NoSuchElementException nsee) {
                break;
            }

            if (tw.trigger.getNextFireTime() == null) {
                continue;
            }

it fins a TriggerWrapper and then the removed doesn't really remove it anymore because te SimpleTriggerImpl has changed its data at some point without that it was removed frist from timeTriggers and then added again..
i could remote debug to a server where this happens (i can't reproduce it (yet) in a sample or test case)

you see the key (down below) which it wants to remove is wit id 121 that one is found if you go from the root 2 times to the left
Problem is that with the TriggerTimeComparator it goes right away "right" from the root, so it never finds it and never removes it
So how can this exactly happen? 82: SimpleTriggerImpl.nextFireTime is set internally i think quite a bit
for example it is set to null twice here: updateAfterMisfire()
so is this possible?

so resumeTrigger() is called on RAMJobStore
that gets one from the triggersByKey and goes on with it calling applyMisfire()
and that could result in the nextFireTime  to be set (to null) but the problem is that then the timeTriggers is screwed up right?
The thing is why does this almost never happen.. Only 1 customer of us has this problem and we are using quartz already for years on many other installations.. But this installation can get a server in this wrong state after a few days running..

this is for us still a problem, but not able to reproduce it locally but only at one customer
that can just get the RamJobStore in a fully incorrect state..
For now we just give a alternative to not use quartz but use for simple stuff (run this a bit in the future) a normal java ThreadPool with a scheduler. Else there system will hang only after a few hours of running