Head of develop breaks global-whitespace-mode

Observed behavior
Put this in config.el
(global-whitespace-mode)

Run make and I got:
There was an unexpected error:
  Error in private config (doom-private-error)
  config.el
  (void-variable frame)

System information

Click to expand
Doom Doctor
Emacs v26.1
Doom v2.0.9 (dbff052c)
shell: /bin/zsh
Compiled with:
  XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY ACL
  GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11
  MODULES THREADS LIBSYSTEMD LCMS2
uname -a:
  Linux node-02 4.20.13-arch1-1-ARCH #1 SMP PREEMPT Wed Feb 27 19:10:28 UTC 2019
  x86_64 GNU/Linux

Checking your OS...
Checking your fonts...
Checking gnutls/openssl...
Testing your root certificates...
Checking for GNU/BSD tar...
DOOM Running doom hook: evil-mode
DOOM Running doom hook: +evil|init-popup-rules
DOOM Initialized evil-collection-debug [feature/evil]
DOOM Initialized evil-collection-comint [feature/evil]
DOOM Initialized evil-collection-custom [feature/evil]
DOOM Initialized evil-collection-help [feature/evil]
Attempt to load DOOM: failed (config.el (void-variable frame))

There is 1 warning!

Whoops. Copy-pasta bug! fe28c40 should fix this error. Thanks for bringing it to my attention!

@hlissner Thanks for the quick fix!
BTW, how do I get a stack trace in this situation? I tried doom -d refresh but that didn't give me a stack trace.

No problem!

BTW, how do I get a stack trace in this situation? I tried doom -d refresh but that didn't give me a stack trace.

That -d didn't produce one is a separate bug I'll need to address. It would normally be enough.


[Feature] Support trait with custom resource be dispatched to hubcluster

Is your feature request related to a problem? Please describe.
By default, traits cr are dispatched to managed clusters along with component, and we want the ability for traits to be dispatch to hubcluster.
Describe the solution you'd like
Firstly, add a new field hubClusterDispatchOnlyEnabled in the trait-definition and applicationrevision to identify whether the trait is delivered to the hubcluster
            spec:
              description: A TraitDefinitionSpec defines the desired state of a TraitDefinition.
              properties:
                appliesToWorkloads:
                  items:
                    type: string
                  type: array
                conflictsWith:
                  description: 'ConflictsWith specifies the list of traits(CRD name,
                  Definition name, CRD group) which could not apply to the same workloads
                  with this trait. Traits that omit this field can work with any other
                  traits. Example rules: "service" # Trait definition name "services.k8s.io"
                  # API resource/crd name "*.networking.k8s.io" # API group "labelSelector:foo=bar"
                  # label selector labelSelector format: https://pkg.go.dev/k8s.io/apimachinery/pkg/labels#Parse'
                  items:
                    type: string
                  type: array
                manageWorkload:
                  description: ManageWorkload defines the trait would be responsible
                    for creating the workload
                  type: boolean
                podDisruptive:
                  description: PodDisruptive specifies whether using the trait will
                    cause the pod to restart or not.
                  type: boolean
                revisionEnabled:
                  description: Revision indicates whether a trait is aware of component
                    revision
                  type: boolean
                hubClusterDispatchOnlyEnabled:
                  description: hubClusterDispatchOnlyEnabled indicates which cluster is dispatched to
                  type: boolean

Secondly, deploy the hubcluster trait cr separately
		readyWorkload, readyTraits, err := renderComponentsAndTraits(h.r.Client, manifest, appRev, overrideNamespace, env)
		if err != nil {
			return nil, nil, false, err
		}
		checkSkipApplyWorkload(wl)
		dispatchResources, hubClusterOnlyTraits := checkHubClusterOnlyTraits(wl.Traits, readyTraits, af.Namespace)
		if !wl.SkipApplyWorkload {
			dispatchResources = append(dispatchResources, readyWorkload)
		}

		if err := h.Dispatch(ctx, clusterName, common.WorkflowResourceCreator, dispatchResources...); err != nil {
			return nil, nil, false, errors.WithMessage(err, "Dispatch")
		}
		localCtx := multicluster.ContextWithClusterName(ctx, "local")
		if err := h.Dispatch(localCtx, "local", common.WorkflowResourceCreator, hubClusterOnlyTraits...); err != nil {
			return nil, nil, false, errors.WithMessage(err, "Dispatch")
		}

Thirdly, some examples are as follows

An example of hubClusterDispatchOnlyTrait hubcpuscaler is as follows

hubcpuscaler: {
	type: "trait"
	annotations: {}
	labels: {
		"ui-hidden": "true"
	}
	description: "Automatically scale the component based on CPU usage."
	attributes: {
		appliesToWorkloads: ["deployments.apps"]
		hubClusterDispatchOnlyEnabled: true
	}
}

template: {
	outputs: hubcpuscaler: {
		apiVersion: "autoscaling/v1"
		kind:       "HorizontalPodAutoscaler"
		metadata: name: context.name
		spec: {
			scaleTargetRef: {
				apiVersion: parameter.targetAPIVersion
				kind:       parameter.targetKind
				name:       context.name
			}
			minReplicas:                    parameter.min
			maxReplicas:                    parameter.max
			targetCPUUtilizationPercentage: parameter.cpuUtil
		}
	}

	parameter: {
		min: *1 | int
		max: *10 | int
		cpuUtil: *50 | int
		targetAPIVersion: *"apps/v1" | string
		targetKind: *"Deployment" | string
	}
}

An example of application with hubClusterDispatchOnlyTrait hubcpuscaler  is as follows

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: fourierapp03
  namespace: fourier
spec:
  components:
    - name: fourierapp03-fouriercomponent-01
      type: webservice
      properties:
        image: busybox:latest
        imagePullPolicy: IfNotPresent
        cmd: [ "sleep", "1000000000" ]
        cpu: "0.1"
        mem: "100Mi"
      traits:
        - type: hubcpuscaler
          properties:
            min: 1
            max: 10
            cpuPercent: 60
        - type: annotations
          properties:
            abc: "def"
        - type: expose
          properties:
            port: [ 80 ]
  policies:
    - name: fourierapp03-topology-01
      type: topology
      properties:
        clusters: [ "kind01" ]
        namespace: fourier01
    - name: fourierapp03-topology-02
      type: topology
      properties:
        clusters: [ "kind02" ]
        namespace: fourier02
  workflow:
    steps:
      - type: deploy
        name: fourierapp03-deploy-01
        properties:
          policies: [ "fourierapp03-topology-01","fourierapp03-topology-02" ]

Describe the situation you'd expected

Additional context

HubClusterDispatchOnlyTraits does not currently support deployment in the form of helm release, Git Repo, etc.

/assign

The general idea LGTM, but the field name in hubClusterDispatchOnlyEnabled should be better.
I propose the name to be  controlPlaneOnly :
hubcpuscaler: {
	type: "trait"
	annotations: {}
	labels: {
		"ui-hidden": "true"
	}
	description: "Automatically scale the component based on CPU usage."
	attributes: {
		appliesToWorkloads: ["deployments.apps"]
		controlPlaneOnly: true
	}
}
...

Any better suggestion? @Somefive

controlPlaneOnly looks good to me. hubClusterDispatchOnlyEnabled  is a bit long but also clear.
The purpose is okay to me but I'm afraid I the implementation solution could lead to some potential problems.

What will happen if one trait resource is initially intended to be dispatched into cluster-a and cluster-b but then both are redirected to the local cluster? Will there any conflicts? Or sharing?
If the trait resource is redirected to local cluster and recorded as belonging to local cluster in ResourceTracker, how can we know which (cluster, namespace, component) it belongs to after we dispatched it? It will break the current resource view.
What if one trait contains multiple resources and only some part of those resources are intended to be dispatched in hub cluster?

Therefore, instead of directly adding fields in TraitDefinition, which on the other hand can be seen as a move to the OAM model, I prefer to use special annotation keys in the output resource and handle it in resourcekeeper dispatch function for now. Although using annotation key is dirty and not elegant, I would prefer to see more practical use cases.
Besides, this hub-cluster dispatch behavior can be related to ComponentDefinition to some extent. For example, the Terraform typed component also needs to dispatch resource (Terraform Configuration) within the hub cluster. Should this design to cover both ComponentDefinition and TraitDefinition? It might worth a broader and deeper discussion IMO.

controlPlaneOnly looks good to me. hubClusterDispatchOnlyEnabled  is a bit long but also clear. The purpose is okay to me but I'm afraid I the implementation solution could lead to some potential problems.

What will happen if one trait resource is initially intended to be dispatched into cluster-a and cluster-b but then both are redirected to the local cluster? Will there any conflicts? Or sharing?
If the trait resource is redirected to local cluster and recorded as belonging to local cluster in ResourceTracker, how can we know which (cluster, namespace, component) it belongs to after we dispatched it? It will break the current resource view.
What if one trait contains multiple resources and only some part of those resources are intended to be dispatched in hub cluster?

Therefore, instead of directly adding fields in TraitDefinition, which on the other hand can be seen as a move to the OAM model, I prefer to use special annotation keys in the output resource and handle it in resourcekeeper dispatch function for now. Although using annotation key is dirty and not elegant, I would prefer to see more practical use cases.
Besides, this hub-cluster dispatch behavior can be related to ComponentDefinition to some extent. For example, the Terraform typed component also needs to dispatch resource (Terraform Configuration) within the hub cluster. Should this design to cover both ComponentDefinition and TraitDefinition? It might worth a broader and deeper discussion IMO.
Reply to 1.
Whether a trait is dispatched to the hub cluster is defined by the developer of the trait, not by the person using the trait.
If a trait wants to be dispatched to the hub cluster, at the same time want to be dispatched to the managed cluster, I think there are only two traits with different controlPlaneOnly values.
Therefore, there is no situation in which a trait is initially deployed in cluster-a and then deployed in local. These two situations are isolated.
Reply to 2.
Traits deployed to hubclutser are separate from normal traits and workloads to be dispatched. so the ResourceTracker.ManagedResource can record the cluster,ns,component.
I have implemented it and verified that it is fully compatible with the original resourcetracker dispatch, GarbageCollect
deploy the hubcluster trait cr separately
Reply to 3.
If a trait contains multiple resources, I think it is possible to divide a trait into multiple trait implementations and deploy only a part of the cr in the hubcluster.
Reply to 4.
Regarding annotations, it is simple, convenient and efficient. If it is a platform resource, we think it is acceptable to add annotations, but we do not think it is necessary to add annotations to user resources.
Reply to 5.
About the Terraform typed component.
I'm not sure if it means helm release, Git Repo, if so, I think it can be achieved in this way.
Because I don't know much about helm component, I haven't implemented it for now, I will support helm release, Git Repo in another pr in the future

Reply to 1.
Whether a trait is dispatched to the hub cluster is defined by the developer of the trait, not by the person using the trait.
If a trait wants to be dispatched to the hub cluster, at the same time want to be dispatched to the managed cluster, I think there are only two traits with different controlPlaneOnly values.
Therefore, there is no situation in which a trait is initially deployed in cluster-a and then deployed in local. These two situations are isolated.
Reply to 2.
Traits deployed to hubclutser are separate from normal traits and workloads to be dispatched. so the ResourceTracker.ManagedResource can record the cluster,ns,component.
I have implemented it and verified that it is fully compatible with the original resourcetracker dispatch, GarbageCollect
deploy the hubcluster trait cr separately
Reply to 3.
If a trait contains multiple resources, I think it is possible to divide a trait into multiple trait implementations and deploy only a part of the cr in the hubcluster.
Reply to 4.
Regarding annotations, it is simple, convenient and efficient. If it is a platform resource, we think it is acceptable to add annotations, but we do not think it is necessary to add annotations to user resources.
Reply to 5.
About the Terraform typed component.
I'm not sure if it means helm release, Git Repo, if so, I think it can be achieved in this way.
Because I don't know much about helm component, I haven't implemented it for now, I will support helm release, Git Repo in another pr in the future

Reply to 1.
Whether a trait is dispatched to the hub cluster is defined by the developer of the trait, not by the person using the trait.
If a trait wants to be dispatched to the hub cluster, at the same time want to be dispatched to the managed cluster, I think there are only two traits with different controlPlaneOnly values.
Therefore, there is no situation in which a trait is initially deployed in cluster-a and then deployed in local. These two situations are isolated.
Reply to 2.
Traits deployed to hubclutser are separate from normal traits and workloads to be dispatched. so the ResourceTracker.ManagedResource can record the cluster,ns,component.
I have implemented it and verified that it is fully compatible with the original resourcetracker dispatch, GarbageCollect
deploy the hubcluster trait cr separately
Reply to 3.
If a trait contains multiple resources, I think it is possible to divide a trait into multiple trait implementations and deploy only a part of the cr in the hubcluster.
Reply to 4.
Regarding annotations, it is simple, convenient and efficient. If it is a platform resource, we think it is acceptable to add annotations, but we do not think it is necessary to add annotations to user resources.
Reply to 5.
About the Terraform typed component.
I'm not sure if it means helm release, Git Repo, if so, I think it can be achieved in this way.
Because I don't know much about helm component, I haven't implemented it for now, I will support helm release, Git Repo in another pr in the future
ping @wonderflow @Somefive

After an offline discussion with @fourierr , I generally accept the idea proposed here. Slight modification to the implementation is recommended. One of the key point here is that when dispatching one component in multiple clusters, the hub-located trait resource is actually shared. This is a pretty interesting feature.

Great work.

@fourierr  Great work.


Support using env vars

I don't want to check in things like usernames and passwords into source. I'd rather be able to set those as environment variables, which can be done with most CI platforms securely. Then, the json config for my test could read those values.

Key in OCRProvider of EngineConfig.json is ready for environment variable.
ActionArgument in Steps of TestE2E json file is ready for environment variable.
It's in v.1.1.1 branch now.


Comparison of ASCII arrays against str not working

Context: https://github.com/UAVCAN/gui_tool/issues/26

Addressed in PyUAVCAN v1.0, see the branch uavcan-v1.0.


Session does not have any test

I believe that the resource https://github.com/pagarme/pagarme-js/blob/master/lib/resources/session.js should have a test (there is no session.spec.js) :)

@LeoNero could you pick this one for the next sprint? ;)

Yeaaaah :D @MarcoWorms

Todo:
[ ] - Add test for session
[ ] - Ensure session id is valid (just like API key testing)


How to create a function on Netlify using this v2?

Hi,
I try to access this function
https://sonnet-18.netlify.app/.netlify/functions/github
but got 404
instead, the function created on Netlify is
https://sonnet-18.netlify.app/.netlify/functions/next_compare?repos=FinnWoelm%23next-on-netlify,cassidoo%23sonnet-18
Is this because of next-on-netlify v2 or multiValueHeaders change?

Hi @Djepri,
Great to hear from you!
I believe you are referring to https://github.com/cassidoo/sonnet-18? The github.js function (https://github.com/cassidoo/sonnet-18/blob/master/functions/github.js) and the next_compare.js function are actually not related.
next-on-netlify v2 now creates one Netlify Function for every page that requires server-side rendering (any page that uses either getStaticProps with fallback: true, getServerSideProps, or getInitialProps). Each page now gets its own Netlify Function. So the next_compare function is created for server-side rendering the pages/compare.js page: https://github.com/cassidoo/sonnet-18/blob/master/pages/compare.js. This keeps the functions small and makes it easier to look through the function logs in the Netlify web interface.
The functions are written to out_functions and this is what should be in the netlify.toml file. Previously it was functions. See the README or let me know if there's anything you're unsure about.
next-on-netlify 2 completely ignores the functions folder. If you want to define API endpoints, the best way is to follow the NextJS aproach and place them in pages/api. That way, next-on-netlify automatically converts them into Netlify Functions. You can read about that here: https://nextjs.org/docs/api-routes/introduction
If you want a plain Netlify Function, you can copy it into the out_functions folder yourself. You should do this after running next-on-netlify, because next-on-netlify completely empties the folder every time it runs. For example, you could set up your package.json file like this:
  "scripts": {
    "build": "next build && next-on-netlify && cp functions/myFunction.js out_functions/myFunction.js"
  }

Does that help? Let me know if anything is unclear. Super happy to help!
- Finn

I originally had a custom Netlify function but I didn't know about the pages/api feature, I like that a lot! Might not be bad to add a note about this in the readme, it's a very good solution to the problem.

That helps me a lot
Thank you very much

Hey @Djepri, glad it helped! Do let me know if you run into any other issues at any point.
@alxhghs: Yes! I've really been wanting to update the demo repo and showcase the API feature there... will do soon!


feat(app): Add cron jobs to app chart

Ties up with this guardian issue - https://github.com/odpf/guardian/issues/191 to be able to run guardian jobs separately as cron jobs.

is it possible to have this as part of stable/guardian only?
cc @AkarshSatija @rohilsurana @ravisuhag

@bsushmith Yes, let's make this part of the Guardian chart only. cc @rahmatrhd

@ravisuhag @rahmatrhd made the changes as part of the app chart itself. Felt it could be useful for other applications, so instead of just for guardian, added to app chart itself directly.

@rahmatrhd @rohilsurana can you folks please check this?

@bsushmith can you add default values in https://github.com/odpf/charts/blob/main/stable/guardian/values.yaml for running guardian jobs as well?

@bsushmith can you add default values in https://github.com/odpf/charts/blob/main/stable/guardian/values.yaml for running guardian jobs as well?

@rahmatrhd will add that as a separate pr once this is done since that would involve updating app dependency in the guardian chart.


Fix the Product method

There is currently a method called product that lives in /lib/product.js.
It is incomplete and needs to be fixed!
Acceptance Criteria:

Running yarn test product results in tests passing.

Please include the skeleton of a new method + an accompanying test for someone else to work on at the time of creating a pull request!

would love to take a crack at it. I'll let you know what comes up

Thanks @chromaticity !


Handle null-bytes in session handler module

Session handler module embedded in Aerospike PHP Extension can not store data containing null bytes strings (\0).
As null-bytes string is quite usual in PHP session values, that makes extension module unusable for most cases.
I am not a C programmer but maybe storing serialized data as a binary could solve this problem?
I mean Using as_record_set_bytes instead of as_record_set_str, and as_record_get_bytes instead of as_record_get_str in the following code:
https://github.com/aerospike/aerospike-client-php/blob/master/src/aerospike/aerospike_session_handler.c#L363
https://github.com/aerospike/aerospike-client-php/blob/master/src/aerospike/aerospike_session_handler.c#L300
Is it the right track?
Or someone has another idea how to solve this problem of null bytes?
For now, the workaround for storing sessions in Aerospike is to implement your own session handler, using Aerospike\Bytes class as described in documentation but it is unfortunate not to use the integrated session mode...

What character set are you using that allows null bytes in strings?
I think the actual issue is to detect the character set that PHP is running in, and convert from that character set to UTF-8 by default. Or to allow you to use your local character set then not be able to access the strings from other languages.

In Phalcon Incubator we always use sort of wrapper to prepare data before writing / after reading

I noticed such null-bytes on some websites using Symfony Framework (SF 2.8). Charset is utf-8.
As you can read in the PdoSessionHandler section from Symfony documentation, we must expect some null-bytes in session data:

Session data is a binary string that can contain non-printable characters like the null byte. For this reason it must be saved in a binary column in the database like BLOB in MySQL.

http://api.symfony.com/2.8/Symfony/Component/HttpFoundation/Session/Storage/Handler/PdoSessionHandler.html

Hi,
Actually you can expect a null byte when you serialize an object which has a private property.
I just posted a gist. You can reproduce the exact same output on PHP 5.6, compiling the aerospike extension with "--loglevel TRACE".

I pushed a Dockerfile, check out that: https://github.com/xavierleune/aerospike-client-php/pull/1/files
You'll easily reproduce the error :smile:
Thanks

Hi everyone,
Did you had a chance to take a look on this issue ? Actually we are stuck with this :'(

ping @rbotzer

Hi @bbulkow and @rbotzer.
Our teammate @aterrien just pushed the Pull Request #103 to address this issue. Can you please review it ?
Thanks!

Definitely will be. I'm heading to the office and going to talk to @jboone100 about it, though I'm sure he's seen the notification by now.

This has been merged in v3.4.9.
Closing the issue.


runner-storage should be created with the correct permissions

This is obsolete, we are moving to k8s and we have an alternative approach. See web previews


⚠ Bofrost.lu has degraded performance

In 7aa9823, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1805 ms

Resolved: Bofrost.lu performance has improved in 595b2b6 after 6 minutes.


Panel side and links '#!' don't work in WP 8.1

Hi @EmanuelM,
Are you using the function phonon.navigator().changePage(...) to change the page or the ontap event?
Thanks in advance.

I use the event ontap
I tested panel side now and works fine, my bad

Hi again @EmanuelM ;)
Please, can you try the release v1.2.4 on Windows Phone.
I normally fixed the ontap event thanks to:

https://patrickhlauke.github.io/touch/tests/results/
https://blogs.windows.com/buildingapps/2012/11/15/adapting-your-webkit-optimized-site-for-internet-explorer-10/
and this issue :)

No, for me It still doesn't work :(

Hi @EmanuelM,
Sorry for the late reply. Can you give me the output of the following:
console.log('PHONON EVENTS')
console.log(phonon.event.start)
console.log(phonon.event.move)
console.log(phonon.event.end)


Add non breaking space before the end of li

When screen readers render these li, all of the links tend to render in one block. the   helps keep them separated and shouldn't affect the style.

Thank you !

This PR has been merged, but I would really have more information on the issue ("all of the links tend to render in one block") you had. Can you explain it a bit more?

During our first accessibility test, we discovered that when these links were listed, they rendered as
"legifrance.gouv.frgouvernement.frservice-public.frdata.gouv.fr" instead of "legifrance.gouv.fr gouvernement.fr service-public.fr data.gouv.fr"
This makes it unclear/confusing for users who use a screen reader.  I didn't expect change of style that it causes and clearly missed that.
I'm open to reverting this change considering the change of style, and considering that different screen readers may treat this html differently. I'm also interested in your opinion on the subject.

What kind of test did you run?

It was a user test -- We have an accessibilty team in-house who are implicated during development to test the accessibility during the process.  This was the first of those tests. We will also run an accessibilty audit prior to deployment.

As it's standard ul > li > a, there's no reason it should be rendered in a particular way by screen readers.
From what I know, screen readers are used by people who can't read (so it provides an audio or using Braille), so I don't understand how / why it should display text?
IMHO, if there's a real accessibility issue on the DOM, it should be handled by the core DSFR team?

I agree @enguerranws

Hi @isMattCoding,
I'm sorry but I'll rollback this change, I don't understand it.
As expected it create some visual offset.

And accessibility is green around the board for the footer:

Ok cool 👍🏻
Yes it's best to go to the source for theses kind of fixes so it applies for everyone, not just React users.


docs-bug(*): Missing migration guide to v19

Documentation Feedback
I'm struggling to migrate from Angular Material v18 (with MD3) to v19. I did not find any migration guide and the new guides do not explain the basics as deeply as in the previous version.
Here are the most important use cases that I don't know how to deal with:

Note: I'm trying to remove the old $theme = mat.define-theme(...) to use the new @include mat.theme mixins

Styling custom components
Before
.my-component {
   background-color: mat.get-theme-color(theme.$theme, neutral, 98)
}

After
I cannot use mat.get-theme-color because I don't have a $theme anymore (previously from mat.define-theme). How can I do that?
Material 3 theme setup
Before
@include mat.core();
:root {
   @include mat.core-theme(theme.$light-theme);
}

After
It has been automatically replaced to:
@include mat.elevation-classes();
@include mat.app-background();
:root {
   @include mat.elevation-classes();
   @include mat.app-background();
}

What is it for? Why isn't it present if I create a new application with Angular Material? Should it be duplicated? I don't see any documentation mentioning those mixins.
Customising material components
Before
I could do this:
@include mat.chips-color(theme.$theme, $color-variant: primary);
@include mat.form-field-density(-3);

After
How to do the same? Do I need to use the new overrides mixins and set each color tokens? For example, that would be 25 colors for the chip component.
Affected documentation page
https://material.angular.io/guide/theming

This is not only an issue when you want to migrate to the new mat.theme and override mixins. According to the comment in _core.scss, mat.core() is deprecated and doesn't do anything in v19. It took us some time to find out why .mat-app-background was no longer being defined when updating to v19.
If this is a breaking change it should at least be mentioned in the Changelog, but I can't find mat.core being mentioned there either.

And while this is not related to documentation, may I also suggest to keep the scss in mat.core as it was and just add the deprecation annotation / warning rather than immediately changing the behavior and adding a comment that it is going to be removed in v21? Because if you already have to modify your code to get the old behavior why keep an empty mixin around?

Thanks for the feedback. Our previous theme config system was fairly complex and required a deep guide on its mechanics. We're hoping this new system is more straightforward with how it operates, but this means the guide might feel more lightweight than before.
Styling custom components
In the same pattern of system CSS variables, I'd recommend simply creating a top-level CSS variable for colors you want to use within your application. E.g.
--my-app-theme-neutral98: map.get($my-palette, neutral, 98);

This bypasses the need to create a separate mixin in your component styles that accepts a theme config, and allows you to just put the style directly in your component style.
If you want to continue using the mixin concept, you can pass it the palette or color directly.
Otherwise, you can always continue creating a theme config that can be passed around, in parallel to using mat.theme.
Material 3 theme setup
mat.core was replaced by elevation-classes and app-background since those styles were previously included in its old implementation. However, mat.core-theme should not have been replaced. If that happened in the update schematic, it should be filed as a bug.
For a new app, we don't really recommend using elevation-classes or app-background anymore. Elevation can be applied using the system level variables instead. And the app background can be set yourself if necessary (this is pointed out in the theming guide), which has the benefit of being explicit rather than a black-box mixin.
Customizing material components
What are you trying to achieve in the line for chips-color? Isn't the default going to be primary?
If you are trying to set it with a different color, you can write a selector that targets your mat-chips and redefine the theme as described in https://material.angular.io/guide/theming#context-specific-themes
This applies for density as well - you can target the form field and call mat.theme((density: -3)); or otherwise call the form field's overrides mixin and directly customize the tokens, e.g.
  @include mat.form-field-overrides((
    container-height: 44px,
    container-vertical-padding: 10px,
    filled-with-label-container-padding-top: 10px,
    filled-with-label-container-padding-bottom: 10px,
  ));

However, the density mixin still exists and you can continue calling mat.form-field-density(-3)

This is not only an issue when you want to migrate to the new mat.theme and override mixins. According to the comment in _core.scss, mat.core() is deprecated and doesn't do anything in v19. It took us some time to find out why .mat-app-background was no longer being defined when updating to v19. If this is a breaking change it should at least be mentioned in the Changelog, but I can't find mat.core being mentioned there either.

mat.core should have been replaced through the schematic to be:
@include mat.elevation-classes();
@include mat.app-background();

If this wasn't the case, it'd be helpful to have an issue filed. Our intention is to keep the same behavior/styling preserved for applications in the update process

It's not obvious to me how to handle typography for non-component styles. The default styles of h1, h2 etc. don't seem to look very nice with just the @include mat.theme(...) approach (I think the mixin doesn't touch the styles on these tags). I used to include the typography-hierarchy mixin and use the classes listed in type scale levels. I couldn't find relevant documentation and if it's missing, I think the documentation would benefit from touching on this subject.

If this wasn't the case, it'd be helpful to have an issue filed. Our intention is to keep the same behavior/styling preserved for applications in the update process

Thanks, I wasn't aware of an update schematic. My colleague updated the Angular core libraries using ng update before the cdk & materials packages were available in v19. A day later, he updated the material packages directly without running ng update. I retried going v18 to v19 from scratch and everything updated automatically so this is actually working fine.
Still - please consider adding this change to CHANGELOG.md as I consider this to be a breaking change and it is not mentioned there. Automatic migrations are nice if they work but knowing what and why something will change is also essential when upgrading.

Because some of my comments on this issue goes beyond the scope "Migrating v18 to v19", I have created a specific request on "how to get theme values without relying on private APIs", see #30083
My main concern now is: How to easily migrate v18 mat.<component>-color mixins to v19?
If the solution is using the new mat.<component>-overrides mixin, could you consider adding a new mixin to quickly change color for a single component without specifying every color tokens?

For context, here is a before/after comparison on how to change the chip component color:
Before in v18:
@include mat.chips-color(theme.$theme, $color-variant: primary);

After in v19:
@include mat.chips-overrides((
   elevated-selected-container-color: map.get(theme.$palettes, primary, 90),
   selected-label-text-color: map.get(theme.$palettes, primary, 10),
   selected-trailing-icon-color: map.get(theme.$palettes, primary, 10),
   selected-hover-state-layer-color: map.get(theme.$palettes, primary, 10),
   selected-trailing-action-state-layer-color: map.get(theme.$palettes, primary, 10),
   selected-focus-state-layer-color: map.get(theme.$palettes, primary, 10),
   with-icon-selected-icon-color: map.get(theme.$palettes, primary, 10)
));

It's much more complicated now, and if we want to keep the same level of contrast (here tones 10 and 90) we have to inspect the generated code and find the equivalent in the new palette.
Proposed solution
In v18 we had to pick a color from our theme, which wasn't very flexible. An ideal solution would be:
@include mat.chips-color(#FF0000); // <== We could pass any color here and the mixin would compute the tones

If not doable, then the same behavior as v18 would be good enough:
@include mat.chips-color(theme.$palettes, primary);
// or
$primary-palette: map.get(theme.$palettes, primary);
@include mat.chips-color($primary-palette);

For example in 18 you can define:
.secondary-button {
  @include mat.button-color($theme, $color-variant: secondary);
}

In 19 you have :
.secondary-button {
   @include mat.button-overrides((
    filled-container-color: orange,
    filled-label-text-color: red,
    ....
  ));
}

For some control like icon, it is easy because there is single color, but for other it may be quite complicated. For now, as a workaround I have just done:
.secondary-button {
    --mat-sys-primary: var(--mat-sys-secondary);
  }

This works but it is just temporally solution. IMO mat.{component}-overrides should support changing color with single input parameter (for controls that are based on single color) like:
.secondary-button {
   @include mat.button-overrides((
    primary-color: var(--mat-sys-secondary),
  ));
}

It would be great to have public APIs to rely on instead of CSS variables that cannot be checked during compilation."

@martinboue The system level variables should be considered part of the public API. Any changes made to them in the future will be considered breaking and I'd expect us to build schematics to auto-update folks (e.g. renaming or removing variables)

Is there any way to generate only component related properties?

@martinboue You can use the component mixins like mat.chip-density(-3) to output only chip-related density tokens

Also, now I need to specify every kind of chips (mat-chip, mat-chip-row and mat-chip-option) and rely on private CSS class or material host tag, both of which can change in the future and are not checked at compile time. Is there any other solution?

@martinboue You shouldn't need to target a specific selector, just include that in your html or wherever you want that CSS variable definition to apply

It's not obvious to me how to handle typography for non-component styles.

@rars The typography hierarchy was a Material 2 typography spec, but that is no longer defined for Material 3. We did our best to mimic a reasonable hierarchy, but since it's not part of the spec I think it makes more sense for clients to set it themselves. You can use this as a reference and modify it if needed:
h1 {
    font: var(--mat-sys-display-large);
}

h2 {
    font: var(--mat-sys-display-medium);
}

h3 {
    font: var(--mat-sys-display-small);
}

h4 {
    font: var(--mat-sys-headline-large);
}

h5 {
    font: var(--mat-sys-headline-medium);
}

h6 {
    font: var(--mat-sys-headline-small);
}

@andrewseguin

The system level variables should be considered part of the public API. Any changes made to them in the future will be considered breaking and I'd expect us to build schematics to auto-update folks (e.g. renaming or removing variables)

From my understanding, system variables are useful for changing global styles or reusing it for non-material components but are not ideal for customizing material components.

You can use the component mixins like mat.chip-density(-3) to output only chip-related density tokens

Yes it works for density, but what about color? It's a very common use case to change a material component color but there is no way to do it easily like we used to with mat.<component>-color mixin.
Could you please give us an example in v19 of how to change the color of a chip where the result is the equivalent of the mat.chip-color mixin in v18?

Expanding on @andrewseguin input. For anyone that is updating to the new mat.theme and used typography-hierachy before here is what I did to get the same effect.
theme-typography.scss:
@mixin my-typography-hierarchy {
  // Display styles
  h1 {
    font: var(--mat-sys-display-large);
    letter-spacing: var(--mat-sys-display-large-tracking);
    margin: 0 0 16px;
  }

  h2 {
    font: var(--mat-sys-display-medium);
    letter-spacing: var(--mat-sys-display-medium-tracking);
    margin: 0 0 16px;
  }

  h3 {
    font: var(--mat-sys-display-small);
    letter-spacing: var(--mat-sys-display-small-tracking);
    margin: 0 0 16px;
  }

  // Headline styles
  h4 {
    font: var(--mat-sys-headline-large);
    letter-spacing: var(--mat-sys-headline-large-tracking);
    margin: 0 0 16px;
  }

  h5 {
    font: var(--mat-sys-headline-medium);
    letter-spacing: var(--mat-sys-headline-medium-tracking);
    margin: 0 0 12px;
  }

  h6 {
    font: var(--mat-sys-headline-small);
    letter-spacing: var(--mat-sys-headline-small-tracking);
    margin: 0 0 12px;
  }

  // Body styles
  body {
    font: var(--mat-sys-body-large);
    letter-spacing: var(--mat-sys-body-large-tracking);

    p {
      margin: 0 0 12px;
    }
  }

  // Additional body classes
  .body-small {
    font: var(--mat-sys-body-small);
    letter-spacing: var(--mat-sys-body-small-tracking);
  }

  .body-medium {
    font: var(--mat-sys-body-medium);
    letter-spacing: var(--mat-sys-body-medium-tracking);
  }

  .body-large {
    font: var(--mat-sys-body-large);
    letter-spacing: var(--mat-sys-body-large-tracking);
  }

  // Additional display classes
  .display-small {
    font: var(--mat-sys-display-small);
    letter-spacing: var(--mat-sys-display-small-tracking);
  }

  .display-medium {
    font: var(--mat-sys-display-medium);
    letter-spacing: var(--mat-sys-display-medium-tracking);
  }

  .display-large {
    font: var(--mat-sys-display-large);
    letter-spacing: var(--mat-sys-display-large-tracking);
  }

  // Additional headline classes
  .headline-small {
    font: var(--mat-sys-headline-small);
    letter-spacing: var(--mat-sys-headline-small-tracking);
  }

  .headline-medium {
    font: var(--mat-sys-headline-medium);
    letter-spacing: var(--mat-sys-headline-medium-tracking);
  }

  .headline-large {
    font: var(--mat-sys-headline-large);
    letter-spacing: var(--mat-sys-headline-large-tracking);
  }

  // Additional label classes
  .label-small {
    font: var(--mat-sys-label-small);
    letter-spacing: var(--mat-sys-label-small-tracking);
  }

  .label-medium {
    font: var(--mat-sys-label-medium);
    letter-spacing: var(--mat-sys-label-medium-tracking);
  }

  .label-large {
    font: var(--mat-sys-label-large);
    letter-spacing: var(--mat-sys-label-large-tracking);
  }

  // Additional title classes
  .title-small {
    font: var(--mat-sys-title-small);
    letter-spacing: var(--mat-sys-title-small-tracking);
  }

  .title-medium {
    font: var(--mat-sys-title-medium);
    letter-spacing: var(--mat-sys-title-medium-tracking);
  }

  .title-large {
    font: var(--mat-sys-title-large);
    letter-spacing: var(--mat-sys-title-large-tracking);
  }
}

And then i use it in styles.scss:
...
@use "./theme-typography.scss" as m3-theme-typography;

html {
  @include mat.theme((
    ...
  ));

  @include m3-theme-typography.my-typography-hierarchy;
}

I do find this slightly better mainly because of future discoverability/maintainability and while I understand the reasoning, I just wished it was mentioned somewhere without searching through issues.

Recently, I spent several days figuring out how to style a theme in Material 18, including working with use-system-variables, system-variables-prefix, density, and typography, because the documentation is very superficial.
Now, I need to do all of this again with Material 19. Additionally, the old API is not fully supported, but the code does not throw any errors, even though my theme no longer works as expected after migration.
You really need to improve the documentation and include more examples with links to various templates on GitHub. Perhaps it’s worth considering hiring someone specifically to handle this aspect.

I've recently investigated how to use Material 18 and thought I had it all figured out. Now, when actually starting the project and using Material 19 I find out the typography mixin is now missing. When/where was that communicated? I inspected the CHANGELOG but can't seem to find the moment in time or a related reference.

As there are several subjects in this issue, I have a created a specific feature request on "How to change a material component color" which sums up the original problem I had, here: https://github.com/angular/components/issues/30241


do_objectID / layer.id not unique

Hello,
I'm writing a plug-in for my coworker designer and I have faced very strange problem. While do_objectID (as parsed from file) or layer.id (as read by plugin or script) look like UUID, they repeat. Not only between files, but also within file. Can you clarify if this is a bug and what are minimum uniqueness guarantee for layer.id? Global (obviously broken), within document (obviously broken), within artboard, within parent layer?

Hi @adontz, could you please send an email with a sample file to<EMAIL_ADDRESS>so we can take a look? Thanks!

@bomberstudios Can you kindly answer my original question?


Italian translation

Pls find attached italian translation file.
it.zip
Code to include in module.json file:
   {
      "lang": "it",
      "name": "Italiano",
      "path": "lang/it.json"
    },

I hope you'll include it in your next release. Thanks

Thank you for submitting these translations.
They have been integrated and will be included in the next release


External Webcam supported on Big Sur with OpenCore?

I have similar spec Hackintosh with OpenCore. Everything works apart from external webcam. Are you facing the same issue or is it functioning properly for you?

I have an HD920 C Logitech which works fine in Big Sur. Not tested in Monterey. You need proper USB port mappings, so the correct speed capabilities of the ports are applied. Otherwise everything defaults to USB 2.0 speeds.

@arshak-kahnputers USB Cameras work for me too (Catalina, Big Sur, Monteray), you just need proper USB Mapping

Actually it was properly mapped but it the webcam itself that had little to no support. I tried Logitech webcam and it works fine.


add image-to-text and visual question answering example

What does this PR do?

Fixes # (issue)
Before submitting

[ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
[ ] Did you make sure to update the documentation with your changes?
[ ] Did you write any new necessary tests?

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

@sywangyi I'll review this PR shortly. FYI this PR was merged so that generation kwargs can be passed when calling the pipleine (if we want to disable HPU graphs for instance).

yes, later we could pass generation kwargs in VQA example when transformers in optimum-habana is upgraded to contain the fix

https://github.com/huggingface/transformers/pull/29342 is upload to fix multi-batch incorrect output for image-to-text.


448: fix link in files table

What this PR does / why we need it:
Adds versionNumber to the FilePreview object so it can be used in the link to the File Page from the files table in Dataset Page
Which issue(s) this PR closes:
Closes #448
Special notes for your reviewer:
I made datasetVersionNumber optional in FilePreview because it is only needed in the files table of the Dataset Page, it's not needed in the FileCard (the other component using FilePreview)
Suggestions on how to test this:
Create a dataset that has a file.  Edit Dataset and publish the dataset multiple times to create multiple versions. Go to an older version of the Dataset Page by using the version param.  In the files table of the Dataset Page, click on the file link.  It should go to the File Page showing the same version as the dataset.
Does this PR introduce a user interface change? If mockups are available, please link/include them here:
No
Is there a release notes update needed for this change?:
No
Additional documentation:

coverage: 97.547% (-0.05%) from 97.592%
when pulling 272ccd579ec82e5a11a1099d121b187a20fbdbac on file-table-link
into 393e9269ebcd8ceb04504b2a389291df1bc46186 on develop.

@GermanSaracca I think you are right that changing the interface introduced more changes than was necessary for that small piece of logic, so I added a check for null as suggested 👍

For when you are back, can you please resolve the conflicts? thanks! @ekraffmiller

@GPortas I have resolved merge conflicts, can you take a look if everything still looks fine?


Collapse all invocations in local tab

Requests

Dan https://serverless-stack.slack.com/archives/C01HQQVC8TH/p1642699280052700

We are transition this repo to https://github.com/sst/v2 and are closing this issue for now. If it is still relevant please reopen it there - sorry for the trouble


Reorganize UWP and desktop docs

The new develop category under desktop development has pages with links to APIs in various forms (WinRT, Win32 and .NET) as well as WindowsAppSDK. This is a good step in merging the docs into a single place however unlike Win32 and .NET APIs which are under their own sections, guideline pages for WinRT APIs are located under the UWP section. While some of the APIs are UWP specific, a lot of them are consumable from desktop apps as well and have nothing to do specifically with UWP however the current organization misleads the developer. Consider moving all of them that are not specific to UWP under the desktop category itself. Win32 and .NET APIs listed can remain in the same place.

For example, this section should be moved here and content should be enhanced to add info for desktop apps if needed.

While APIs that are specific to UWP or UWP XAML will not be moved, example

Currently the desktop section seems to be mainly a docs for WindowsAppSDK. In my opinion it should also have the non-UWP WinRT stuff.
Also the publish section should also be under the desktop section and not UWP:

Hello! Thank you for providing your feedback. I appreciate you taking the time to contact us. I can tell you we are deep into a substantial re-organization of our content in time for Build this yes. Please have a look at our docs in late May, as we hope we'll address these and other issues. Thank you! -John


Using connect() with Immutable.Map state object

My store is an Immutable.Map object, and I would like to pass it down my tree of React components. I suppose that in most cases I can get good performance by using something like PureRenderMixin (or ES2015 equivalent) when doing so.
I started out simple decorating my App class with @connect(state => state), and I got this error:
“Uncaught Error: Invariant Violation: mapStateToProps must return an object. Instead received Map {…”
I’m able to do something like @connect(state => {return {state};}), and then unwrap the object in App’s render(), but I get the sense that this is not an ideal solution.

The return of the mapStateToProps needs to be an object because the object is spread as props to the wrapped component. Your work around is in fact the idiomatic way to use @connect. In this case your wrapped component will have a prop named 'state' which is an Immutable.Map
Now you may want to consider passing the entire app state to your connected component however. This will make refactoring your state shape a lot harder when your app is more complicated. Though in simple cases it is fine.

Ah, I understand.
I already pass what that I consider being the app state. By passing the entire app state, do you mean doing @connect(state => state.toJS())?
I haven’t fully decided whether or not I want the immutable or a plain JavaScript object floating through the component tree, but performance is the number one priority in this particular case. I need to look into how shouldComponentUpdate() and each alternative will work with my data. I also consider using several @connect() a bit higher up the tree, instead of one at the root component.

I already pass what that I consider being the app state. By passing the entire app state, do you mean doing @connect(state => state.toJS())?

That would be slow. I suggest you don't do that, and if perf is your main concern, use @connect granularly.

I need to look into how shouldComponentUpdate() and each alternative will work with my data.

Actually @connect already implements a rather decent shouldComponentUpdate so don't worry about it too much.

Indeed, as @gnoff said above, you can't just return Immutable object because we spread over the values you return, and this wouldn't make sense with Immutable.

I’m able to do something like @connect(state => {return {state};}), and then unwrap the object in App’s render(), but I get the sense that this is not an ideal solution.

The idiomatic way is to do this:
connect(state => ({
  stuff: state.get('stuff'),
  otherStuff: state.get('otherStuff')
})

only for the fields you actually care about, so @connect can bail out when the parts the component doesn't need, did not change. I don't suggest using toJS() because AFAIK it's deep, but deep conversions won't be as performant as just extracting the stuffy you want.

I also consider using several @connect() a bit higher up the tree, instead of one at the root component.

This is the way to go, and it's more performant than just one @connect at the top.

btw if you're concerned about performance, make sure you check out reselect and Computing Derived Data.

Great, thank you both!

Thanks! This really cleared up the same issue I was having.

@gaearon Hey Dan, what are your thoughts of running immutable AND reselect together versus just one or the other?

Feel free to use them together. They're solving different problems and can be used complementary.

Wasn't aware connect() implemented a shouldComponentUpdate() which is great to know... is this in the docs somewhere? Is there a suitable way of making props immutable further down the tree to prevent more nested components updating unnecessarily?

Wasn't aware connect() implemented a shouldComponentUpdate() which is great to know... is this in the docs somewhere?

This is an implementation detail. We say “performant” in the repo description but I wouldn’t detail the optimizations as they may change.

Is there a suitable way of making props immutable further down the tree to prevent more nested components updating unnecessarily?

Not sure what you mean. Any connected component does a shallow comparison. If its props (including props from store) don’t change, it doesn’t update.

Sorry, I can see how that made little sense. Well, If I have a container (uses connect()) that has an array of components (could be 100+) which may update frequently but sporadically, would it be possible to only update those that changed in some way? Or would it simply be a case of having to redraw them all as it is the Container that uses connect()?

What do you mean by “update”? React only updates DOM when necessary. There is a cost for reconciliation process (which is where it compares the element trees), and shouldComponentUpdate() lets you bail out of this process.
When you use connect() on a component, it is subscribed to the store, and if the calculated props change, it will cause reconciliation on the connected component.
So if you connect a list to the store, and a list renders 100 rows, if the calculated props change after a store update, React will reconcile those 100 row elements. Then it will look at rows themselves. If your row components implement shouldComponentUpdate() you can bail out there. If your row components are connected, the shouldComponentUpdate() implementation we provide will bail out if props are shallowly unequal.
Does this make sense?

Yes. Thanks for your wisdom, Dan! Just as I think I'm understanding things then 'WHAM!'... something else comes up. :)

Sorry for commenting a closed issue but I keep coming here when googling for a similar issue.
I spent a lot of time to understand how to integrate Immutable with Redux, even implementing my own version of connect, and finally understood how to use the @connect from 'redux-connect'
I just wanted to understand @gaeron answer from 17 august 2015
connect(state => ({   stuff: state.get('stuff'),   otherStuff: state.get('otherStuff') })
It seems to work ( and looking at the shallowEqual code it seems reasonable ) when state.get('stuff') and state.get('otherStuff') are Immutable objects, not plain JS.
Can someone confirm it is the case or am I missing something ?

The actual return value from mapState does need to be a plain object.  However, the values within that object can certainly be Immutable.js data structures.  So, in that example, if "stuff" was an Immutable Map, and "otherStuff" was an Immutable List, that would be just fine, as long as your actual component is expecting to get a Map and a List, rather than a plain JS object and a plain JS array.
As a side note, there are a number of utilities out there already to integrate Immutable.js into a Redux app.  See https://github.com/markerikson/redux-ecosystem-links/blob/master/immutable-data.md#immutableredux-interop for a list of some of them.

Our project uses an Immutable.Map as our store and connect like so,
  App = connect(state=>state.toObject())(App);

Which seems to neatly pass everything from the map into the App.

@bherrmann7 How about those nested immutable Data?They can't be converted to plain object by toObject() function.Only by toJS() can we convert all nested immutable data.


Add github action workflow for linting

Fixes #1032
I tested this in my forked website repo, and here's a PR with the workflow in action: https://github.com/jamessspanggg/Website-1/pull/2
Acc No: c54c04774efaae20746fd3f29cdd619fea512e119bc1082b863572b2e8844104

@jamessspanggg Can we have a failure scenario for this available as a PR ?

@lapstjup can check from the PR for the failure scenario

@jamessspanggg Cool stuff man :D.
Few doubts here since I am not well equipped with its knowledge :-

What happens when the code is directly pushed to master or development (which can only be done by core team ) ? This action will run in the terminal itself and fail for linting errors ?
Also what if a person uses Github GUI to commit directly to remote master/development ?

Few doubts here since I am not well equipped with its knowledge :-

What happens when the code is directly pushed to master or development (which can only be done by core team ) ? This action will run in the terminal itself and fail for linting errors ?

If you are directly pushing it to the team's master or development branch, the checks will still occur on Github. Note that the checks run after you have pushed to the branch, so it won't prevent you if it fails. But however, it will show the status of each commit. i.e. the green tick or a red cross in the commit as shown below, clicking on the tick/cross will show you more details on the checks:

Also what if a person uses Github GUI to commit directly to remote master/development ?

Committing directly using github's gui will have the same effect as I have described above, have tested it in my own master branch. (Don't worry I will rebase and force push it)


Add 2.13.4 support

Just pr adds in support for 2.13.4 which we would like to include in our Metals release that supports 2.13.4.

Just pushed an extra commit that will (hopefully) address the compilation errors. (That's because some conversions were marked as non explicit in 2.13.4, look for CharSequence in the 2.13.4 release notes.)

Just pushed an extra commit that will (hopefully) address the compilation errors. (That's because some conversions were marked as non implicit in 2.13.4, look for CharSequence in the 2.13.4 release notes.)

Hey! Thanks for taking a peak! I just threw this up here this morning before work hoping for the best 😬 , but I had planned on taking a look back after work. It looks like it's still failing, so if you do want to keep working on it, by all means please do! If not I'll try to take a look tonight at what's going on.

@ckipp01 Feel free to have a look later on. I'm not sure I'll be able to have a look today.

So I don't really get what's going on here and why the changes are affecting those tests...


Test type on HTTP response code

It would be useful to distinguish between HTTP codes as a test type.
Currently all 404s and 500s are treated as a failure by JMeter, but in some REST applications, a 404 might be an "expected" request. A Passed Transactions test is unable to distinguish these.
(This is a feature request)
Alternatives in JMeter configuration:

User could add a Response Assertion to allow 404 to not be an error

See http://stackoverflow.com/questions/36824822/teamcity-jmeter-performance-metrics-calculation-check-reference-values

Passed transactions test considers an error whatever JMeter considered to be an error. If your JMeter test considers 404 to be success, it will be reported as success in CSV file and subsequently processed by Lightning. I don't see a reason why Lightning should re-evaluate what JMeter considers to be success.


Add cache tests for different values of StorageLevel

Storage level defines where the cache will be stored. e.g. DISK_ONLY, MEMORY_AND_DISK etc
We need tests to make sure we support them and possibly catch any problems if any

@razajafri I am trying to understand a bit where this is coming from? Did we run into some errors with the other modes? This feels more like we are testing Spark instead of testing our code.

I have been reached out to a few times asking if we support different storage modes. To me, it's clear that all modes should be supported but I thought adding a few tests would be sufficient to rest any doubts.


Enabling Cilium With ha-cluster

Hi,
With a single node I've had issues with networking not working between pods after I run microk8s stop and microk8s start
It seems to happen with both ha-cluster enabled and disabled. With ha-cluster disabled if I enable cilium this seems to fix it. Cilium also seems to retain source ip addresses of requests as flannel does.
I'm wondering can I enable cilium with ha-cluster enabled? I'm not sure how deeply calico is needed by the ha-cluster plugin. I intend to use 2 more servers to setup a 3 node cluster but this networking issue would be quite a big problem in a production cluster so I'm hoping cilium would be the way to fix it until I can get better stability out of flannel or calico.

I didn't mention I'm using 1.19/stable

Hello @sstubbs

With a single node I've had issues with networking not working between pods after I run microk8s stop and microk8s start

Does this mean pods can't talk to each other intermittently?  I recall for calico, this can be an issue for nodes with multiple interfaces.  Could it be the case? Like the one here? https://github.com/ubuntu/microk8s/issues/1554#issuecomment-691426908
As far as i know the use of calico is nothing especially related to HA, other than it uses the apiserver instead of directly etcd.  Since from 1.19 MicroK8s dqlite is the default.
I haven't got the chance to use cilium on a multi node ha cluster for a significant time.
Also, i will probably wait for some fixes on the 1.19 MicroK8s to arrive before putting this up for prod.  But if you're up for a test, that will be great too. 😊
Thanks once again!

Hi @balchue
It seems itermittent. Only a few pods seem to have this issue and it seems random as each time it's different pods in different namespaces giving me this each time I restart.
I would rather stick with 1.19 to be honest as I need quite a bit of time getting everything up and running each time and if more work is going into the new ha solution that is definitely preferable for me. I have backups so it's not the end of the world if there are problems.
So if I enable cilium will this revert to flannel and install cilium in addition to flannel? Just trying to understand what I'm actually doing. If i disable cilium will it go back to calico?

If the cluster is an ha-cluster, it will fall back to calico when Cilium is disabled.  But if you disable ha, the it ideally should fall back to flannel (but i've not tried this)

ok thanks for the clarification.

This issue can probably be closed then.

Thanks


Motor discovery

Spawns controllers based on the list in the configuration file instead of a fixed number like 2 or 4 controllers.

Codecov Report

Merging #7 (c515ee8) into main (c680572) will increase coverage by 2.10%.
The diff coverage is 97.05%.

@@            Coverage Diff             @@
##             main       #7      +/-   ##
==========================================
+ Coverage   64.34%   66.44%   +2.10%
==========================================
  Files          30       26       -4
  Lines        1708     1675      -33
==========================================
+ Hits         1099     1113      +14
+ Misses        609      562      -47

Impacted Files
Coverage Δ

plico_motor_server/__version__.py
0.00% <0.00%> (ø)

plico_motor_server/utils/process_startup_helper.py
100.00% <ø> (ø)

plico_motor_server/utils/starter_script_creator.py
100.00% <ø> (ø)

setup.py
0.00% <ø> (ø)

plico_motor_server/process_monitor/runner.py
90.62% <100.00%> (+1.60%)
:arrow_up:

plico_motor_server/scripts/controller.py
100.00% <100.00%> (ø)

plico_motor_server/utils/constants.py
100.00% <100.00%> (ø)

test/integration/integration_test.py
99.31% <100.00%> (+0.03%)
:arrow_up:

plico_motor_server/controller/controller.py
95.45% <0.00%> (-1.52%)
:arrow_down:

Continue to review full report at Codecov.

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


us-west-2 does not show up in selector

In a previous config it showed up, we need to ensure that the 4 us-regions us-west-1, us-west-2, us-east-1 and us-east-2 will always show up in the list

This was my error, it shows up


No revertDiff functionality

First of all, awesome diffing library! I use it for undo/redo management of objects. However, I am missing a revertDiff function that does exactly the opposite of applyDiff:
b === applyDiff(a, diff(a, b))
a === revertDiff(b, diff(a, b))
The only way to add this functionality is to alter the library, since the deepDiff (not exposed to the outside) function needs to be called. Before I start fiddling in the module code, I was wondering if there was a good reason that this functionality is not there yet, and if there might be something that I am overlooking.

Figured out that the API was not quite what I expected it to be. Possible improvement:

Clarify in docs that you do not need to provide the actual diff object to applyDiff. I expected that applyDiff applied a precomputed diff to a given object, hence my quest for the revertDiff function.
Documentation on the arguments and return values of the API would have helped me a great deal to quickly grab the meaning of these functions.
Remove the need to provide a source argument to both the revertChange and applyChange function. The arguments are not used, and are confusing. After all, we just want to apply/revert a change to an object.

After having these things clarified for myself, the lib works great! Thanks for all of your efforts!

Thanks for the feedback; I'll try to update the docs.


Can this model produce infinitely long videos?

Hi, thanks for presenting this incredible work. Since the architecture is auto-regressive, can it be extended to generate infinitely long videos?

Technically yes, but we have not resolved the quality degradation in autoregressive generation. Please refer to Diffusion Forcing (https://arxiv.org/abs/2407.01392) and GameNGen (https://arxiv.org/abs/2408.14837) for their design details.

Thanks for your reply.


Trying parallel SDK tests

Closing as @Voxelot will just do that in https://github.com/FuelLabs/sway/pull/3181. This does seem to work though and cuts down the total time by around 10 min which is nice.


Rename plugin and config params

Kong is making an effort to use inclusive language and eradicate racially-sensitive terms from our vocabulary. Can you please update the plugin name and any properties that use the term "whitelist" to a term such as "allow"?
On the docs side, we can make any necessary parallel changes to your plugin doc on the Kong Plugin Hub (https://docs.konghq.com/hub/seifchen/kong-path-whitelist/).
Based on work done in: https://github.com/Kong/docs.konghq.com/pull/2119

ok, I will do it

@lena-larionova  I have finished this, do I still need to modify my plugin doc on the Kong Plugin Hub(https://docs.konghq.com/hub/seifchen/kong-path-whitelist/)

Thanks! I'll go ahead and update it, it's fine :)

@lena-larionova Thanks! I closed this issue


Gorious Dependency Bloat

Description of the new feature / enhancement
Now to be fair on MeasureTool - It uses a different Microsoft.Windows.SDK.NET.dll ... But otherwise there are 14x copies of the same dependency:

This isnt just limited to the .NetSDK , others are duplicate also - overall, it makes for a MASSIVE folder that is mostly just unmanaged duplicate dependency bloat.
Scenario when this would be used?
yes
Supporting information
No response

What version are you on. This should be heavily reduced now a days. /needinfo

this is fantastic news! I will load up and check shortly

Clint, I'm back after the reboot and can confirm that upgrading past u72 fixed the issue. I am now on 0.75.1 and can confirm that I got back 3GB of storage space on my surface pro.
Thanks for the solution - what a ripper


Adding Drop Zone Id value clears items from the Power Drag Drop list

I bound the component to a collection and set the "Id Column" and "Zone Column" as well as added a Field to display the Items in the list. As soon as I add a value to the "Drop Zone Id" those items are cleared away. See animated GIF for clarity.

I have the same problem. Did you manage to solve it yet?

Hi, I have the same problem. Did you manage to solve it yet?

Unfortunately I did not. I was hoping it was something simple I was missing.

Your data is structured so that the Zone Column for those records is set to blank. When you set the Drop Zone ID for that control to something other than blank, it no longer will grab those records with a blank Zone Column.

Ensure the Drop Zone ID matches the name specified in the collection.


Refined the README

Added links to builds and mentioned the Discussions tab.

Looks good, thank you @ilyakooo0


Add affected attribute format

Following up on #149 it seems like we have general agreement on what this format should be, so I've gone ahead and kicked off the PR 🎉 I took a liberty in how to deliniate two attributes (with a ;). Happy to change that if there's disagreement on how to delimit multiple different attributes on the same osv payload. The osv payload is explicitly called out as equivalent to the dot-colon single line format as well.
~I also added a brief section linking to the osv schema.~ I did in a prior version of the commit then removed it after noticing there was already a link to the osv schema 🤦
Happy to move the target of this change or to change the wording or whatever :)

Pushed up some changes based on the feedback and I made the json examples more explicit as well. Any other thoughts/spot any errors I made 👀 ?

Accepted both suggestions. 👍


[BUG] Expose borked

Describe the bug
Expose doesn't work.
********** Crash dump: **********
Build fingerprint: 'oculus/hollywood/hollywood:12/SQ3A.220605.009.A1/50686620069900150:user/release-keys'
#00 0x0000000000089c8c /apex/com.android.runtime/lib64/bionic/libc.so (abort+168) (BuildId: d42b3c66bf003339077ec517126abf7f)
#01 0x000000000f9be118 /data/data/com.beatgames.beatsaber/files/libcodegen.so (std::get_unexpected()) (BuildId: 95192ba5ae8ca4fe9d26bdaf01a5aed5c5149fe8)
Crash dump is completed

See imb11/colorama branch 3.0.0

Its hard to explain the issue when the crash is useless. On 0.1.11 lapiz

Duplicate of #39


Docgen Phaser.GameObjectFactory.json "returns" property is null

The GameObjectFactory.json file generated by docgen is not generating the "returns" object, else it gets a null value in the case of the methods image(...) and sprite(...).

Yes this is a known issue I'm afraid since we updated the docs generally across Phaser. For now please use the json file generated by jsdoc itself, or alternatively you're welcome to try and patch it and submit a pull request. Development on docgen is currently on hold as we complete other areas.


[All OSs] .NET 5.x will be removed from the images on February, 6

Breaking changes
All the pre-cached .NET 5.x versions will be removed from all operating systems.
Target date
The rollout will start on February, 6 and will take 3-4 days to propagate the image to all the environments.
The motivation for the changes
According to our Software and image guidelines tools and versions have to be removed 6 months after they are deprecated or have reached end-of-life. The .NET 5 has reached EOL on 5 May 2022.
Possible impact
If your project depends on a pre-installed .NET 5.x it can be broken.
Platforms affected

[X] Azure DevOps
[X] GitHub Actions

Runner images affected

[X] Ubuntu 18.04
[X] Ubuntu 20.04
[ ] Ubuntu 22.04
[X] macOS 11
[X] macOS 12
[X] Windows Server 2019
[X] Windows Server 2022

Mitigation ways
To install any version in runtime you can use the following action\task:

https://github.com/actions/setup-dotnet for GH actions
https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/tool/dotnet-core-tool-installer?view=azure-devops task for AzDO

Access

Removed. Changes will be released next week.

Deleted

Not entirely on topic, but what is the best way for consumers of these images to become aware of impending removals like this?
Following this repo and sorting through all the issues doesn't really appeal. Otherwise should we note down the EOL dates for the software we care about, add 6 months and create calendar entries for ourselves? I looked for a way to subscribe to an issue label, or to get an RSS feed for issues tagged with a label, and came up short.
Thanks.


[e2e] mark TestUpgrade_Agent_OCI_then_DebRpm as flaky

What does this PR do?

Mark TestPackages/agent_centos_7_x86_64/TestUpgrade_Agent_OCI_then_DebRpm as flaky
Motivation

incident-28477
Centos7 is EOL and just changed its mirror list for yum. We need to update the list in our custom image and update the AMI id in platform.json and in test-infra-definitions
Additional Notes

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

/merge

/merge -c

/merge

/merge


rsa_padding_add_PKCS1_OAEP_mgf1_with_libctx(): fix check of |md|

In the FIPS module, the code as written generate an unconditional
error.
Fixes #11865

Why didn't our tests pick this issue up?

Why didn't our tests pick this issue up?

I have no idea.  Please someone investigate

yeah I will look.

This is test test case for the rsa pading:
$ ./util/shlib_wrap.sh test/rsa_test
1..4
    # Subtest: test_rsa_pkcs1
    1..3
    ok 1 - iteration 1
    ok 2 - iteration 2
    ok 3 - iteration 3
ok 1 - test_rsa_pkcs1
    # Subtest: test_rsa_sslv23
    1..3
    ok 1 - iteration 1
    ok 2 - iteration 2
    ok 3 - iteration 3
ok 2 - test_rsa_sslv23
    # Subtest: test_rsa_oaep
    1..3
    ok 1 - iteration 1
    ok 2 - iteration 2
    ok 3 - iteration 3
ok 3 - test_rsa_oaep
    # Subtest: test_rsa_security_bit
    1..12
    ok 1 - iteration 1
    ok 2 - iteration 2
    ok 3 - iteration 3
    ok 4 - iteration 4
    ok 5 - iteration 5
    ok 6 - iteration 6
    ok 7 - iteration 7
    ok 8 - iteration 8
    ok 9 - iteration 9
    ok 10 - iteration 10
    ok 11 - iteration 11
    ok 12 - iteration 12
ok 4 - test_rsa_security_bit

note I even added a test for SSLV23_PADDING when I
reworked that constant time RSA padding,
I would say it should be impossible how this test succeeds.

I would say it should be impossible how this test succeeds.

My guess is its only testing the default provider not the FIPS provider (which is where this issue occurs).

My guess is its only testing the default provider not the FIPS provider (which is where this issue occurs).

Although I would have expected evp_test to test this padding - and that should cover both providers.

and this compiles, so FIPS_MODULE is never defined:
diff --git a/crypto/rsa/rsa_oaep.c b/crypto/rsa/rsa_oaep.c
index 8ffde9f..fdfdf92 100644
--- a/crypto/rsa/rsa_oaep.c
+++ b/crypto/rsa/rsa_oaep.c
@@ -71,6 +71,7 @@ int rsa_padding_add_PKCS1_OAEP_mgf1_with_libctx(OPENSSL_CTX *libctx,
     if (md == NULL)
         md = EVP_sha1();
 #else
+ssss
         RSAerr(0, ERR_R_PASSED_NULL_PARAMETER);
         return 0;
 #endif

... Now I'm lost, the FIPS code is probably dead alltogrther,
and should be removed.

I have no idea what you're doing, @bernd-edlinger. When I add an "ssss" line like you fid, my compiler does complain!

hmm.
I have master  e9e7b5d
here, and the code in question does compile perfectly for me.
diff --git a/crypto/rsa/rsa_oaep.c b/crypto/rsa/rsa_oaep.c
index 8ffde9f..05dc5d8 100644
--- a/crypto/rsa/rsa_oaep.c
+++ b/crypto/rsa/rsa_oaep.c
@@ -67,10 +67,12 @@ int rsa_padding_add_PKCS1_OAEP_mgf1_with_libctx(OPENSSL_CTX *libctx,
     unsigned char seedmask[EVP_MAX_MD_SIZE];
     int mdlen, dbmask_len = 0;

+asm("int3");
 #ifndef FIPS_MODULE
     if (md == NULL)
         md = EVP_sha1();
 #else
+ssss
         RSAerr(0, ERR_R_PASSED_NULL_PARAMETER);
         return 0;
 #endif

make
gcc  -I. -Iinclude -Iproviders/common/include -Iproviders/implementations/include -Icrypto/include  -DSTATIC_LEGACY -pthread -m64 -Wall -O0 -g -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib/engines-3\"" -DMODULESDIR="\"/usr/local/lib/ossl-modules\"" -DOPENSSL_BUILDING_OPENSSL  -MMD -MF crypto/rsa/libcrypto-lib-rsa_oaep.d.tmp -MT crypto/rsa/libcrypto-lib-rsa_oaep.o -c -o crypto/rsa/libcrypto-lib-rsa_oaep.o crypto/rsa/rsa_oaep.c

but the int3 makes the test/rsa_test fail:
$ test/rsa_test
1..4
    # Subtest: test_rsa_pkcs1
    1..3
    ok 1 - iteration 1
    ok 2 - iteration 2
    ok 3 - iteration 3
ok 1 - test_rsa_pkcs1
    # Subtest: test_rsa_sslv23
    1..3
    ok 1 - iteration 1
    ok 2 - iteration 2
    ok 3 - iteration 3
ok 2 - test_rsa_sslv23
    # Subtest: test_rsa_oaep
    1..3
Trace/Breakpoint ausgelöst (Speicherabzug geschrieben)

I have configured with ./config -d no-asm no-pic no-dso

With no-pic, you don't get a FIPS module...

With no-pic, you don't get a FIPS module...

Perhaps Configure should output a message about that.

Yeah, if I want to debug something, I do usually try to build everthing statically,
debugging shared object is of course more fun....

OTOH, when there is not FIPS which test case should complain about that ?

03-test_fipsinstall.t .............. skipped: Test only supported in a fips build
that is probably the hint I overlooked :-)

but how can it be, that the no-pic version with int3 in the oaep code path
has only
15-test_rsa.t ...................... Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/10 subtests
	(less 2 skipped subtests: 7 okay)
80-test_cms.t ...................... Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/7 subtests

but @mattcaswell you said that the evp test should also trigger?
why doesn't it trigger here?

Okay, now shared object: ./config -d
diff --git a/crypto/rsa/rsa_oaep.c b/crypto/rsa/rsa_oaep.c
index 8ffde9f..2a0e428 100644
--- a/crypto/rsa/rsa_oaep.c
+++ b/crypto/rsa/rsa_oaep.c
@@ -71,6 +71,7 @@ int rsa_padding_add_PKCS1_OAEP_mgf1_with_libctx(OPENSSL_CTX *libctx,
     if (md == NULL)
         md = EVP_sha1();
 #else
+asm("int3");
         RSAerr(0, ERR_R_PASSED_NULL_PARAMETER);
         return 0;
 #endif

@levitte yes, the ssss version does not compile but int3 does not cause any test failures.
so again the result is this is dead code.
the code in crypto/rsa/rsa_oaep.c is only used for cms  and the deprecated RSA API,
and those are not available in FIPS.
That explains why this defect cant be found in our tests.

The same duplication I already saw with the AES code.
The new code is in the providers, but the old code is still
needed for the CMS and probably engines to use.
Nobody can maintain a code base that is designed that way.
Which alpha release will remove the duplication ?

Hmm, is it possible that the deprecated legacy AES API is
also not using the provider @slontis ?

It's possible that our OAEP tests aren't performed with the FIPS module. That doesn't make the code dead.

I wouldn't call it a good sign either.
How is this code supposed to be tested?

How is this code supposed to be tested?

There are a number of OAEP tests in test/recipes/30-test_evp_data/evppkey.txt. The EVP tests are supposed to be run by both the default provider and the FIPS provider, so I would have expected those tests to pick up this issue. I haven't investigated why it didn't.

Ah, the answer is easy:
grep crypt.*OAEP 30-test_evp_data/evppkey.txt
Decrypt=RSA-OAEP-1
Decrypt=RSA-OAEP-1
Decrypt=RSA-OAEP-1
Decrypt=RSA-OAEP-1
Decrypt=RSA-OAEP-1
Decrypt=RSA-OAEP-1
Decrypt=RSA-OAEP-2
Decrypt=RSA-OAEP-2
Decrypt=RSA-OAEP-2
Decrypt=RSA-OAEP-2
Decrypt=RSA-OAEP-2
Decrypt=RSA-OAEP-2
Decrypt=RSA-OAEP-3
Decrypt=RSA-OAEP-3
Decrypt=RSA-OAEP-3
Decrypt=RSA-OAEP-3
Decrypt=RSA-OAEP-3
Decrypt=RSA-OAEP-3
Decrypt=RSA-OAEP-4
Decrypt=RSA-OAEP-4
Decrypt=RSA-OAEP-4
Decrypt=RSA-OAEP-4
Decrypt=RSA-OAEP-4
Decrypt=RSA-OAEP-4
Decrypt=RSA-OAEP-5
Decrypt=RSA-OAEP-5
Decrypt=RSA-OAEP-5
Decrypt=RSA-OAEP-5
Decrypt=RSA-OAEP-5
Decrypt=RSA-OAEP-5
Decrypt=RSA-OAEP-6
Decrypt=RSA-OAEP-6
Decrypt=RSA-OAEP-6
Decrypt=RSA-OAEP-6
Decrypt=RSA-OAEP-6
Decrypt=RSA-OAEP-6
Decrypt=RSA-OAEP-7
Decrypt=RSA-OAEP-7
Decrypt=RSA-OAEP-7
Decrypt=RSA-OAEP-7
Decrypt=RSA-OAEP-7
Decrypt=RSA-OAEP-7
Decrypt=RSA-OAEP-8
Decrypt=RSA-OAEP-8
Decrypt=RSA-OAEP-8
Decrypt=RSA-OAEP-8
Decrypt=RSA-OAEP-8
Decrypt=RSA-OAEP-8
Decrypt=RSA-OAEP-9
Decrypt=RSA-OAEP-9
Decrypt=RSA-OAEP-9
Decrypt=RSA-OAEP-9
Decrypt=RSA-OAEP-9
Decrypt=RSA-OAEP-9
Decrypt=RSA-OAEP-10
Decrypt=RSA-OAEP-10
Decrypt=RSA-OAEP-10
Decrypt=RSA-OAEP-10
Decrypt=RSA-OAEP-10
Decrypt=RSA-OAEP-10

You can't have a known answer test when the encyption is randomized.

You can't have a known answer test when the encyption is randomized.

We should perhaps add a roundtrip (i.e. encrypt then decrypt) test in evp_extra_test for OAEP.

Could we add encryption stanzas for evp_test?

Could we add encryption stanzas for evp_test?

Well, I think the problem there is as @bernd-edlinger points out "You can't have a known answer test when the encyption is randomized."

"You can't have a known answer test when the encyption is randomized."

You can if you supply the entropy.

You can if you supply the entropy.

Do we have that capability in evp_test?

not yet :)

now, I am curious, are there FIPS test vectors for that?

Do we have that capability in evp_test?

We do at the moment but not in a nice manner.  The DRBG tests implement something that is adequate.
The changes in #11682 will break what is currently done but the capability needs to be available and it is on the TODO list.

now, I am curious, are there FIPS test vectors for that?

I cant see any..
Interop tests with another toolkit would probably be better.
(Or debug another toolkit to grab its internal data).

24 hours has passed since 'approval: done' was set, but as this PR has been updated in that time the label 'approval: ready to merge' is not being automatically set.  Please review the updates and set the label manually.

Merged
e637d47c9122d74d4f3a40a8cbe867de29468ba3 rsa_padding_add_PKCS1_OAEP_mgf1_with_libctx(): fix check of |md|


cv2.resize blocks forever when called by multiple processes(with multiprocessing module)

Expected behaviour
N/A
Actual behaviour
I encountered a strange behavior of cv2.resize. I prepared a snippet that reproduces the strange behavior. pool.map blocks forever in the code below because any of those processes doesn't finish its job. The reason why I see it strange is that the code works okay when pool.map is not followed by "Single processing" code.
Steps to reproduce
#example code

import cv2
import multiprocessing

def process_image(image_path):
    proc = multiprocessing.current_process().name
    print proc, "processing image.."
    img_input = cv2.imread(image_path, 0)
    scale = 1.2
    cv2.resize(img_input, (0, 0), fx=scale, fy=scale)
    print proc, "finished"

def main():
    image_path = '.../image.jpg'
    # Single processing. If you comment out the line bellow, main function works just okay
    process_image(image_path)

    # Multi processing
    num_processes = 5
    pool = multiprocessing.Pool(num_processes)
    pool.map(process_image, [image_path]*num_processes)

if __name__ == '__main__':
    main()

operating system / architecture (e.g. x86)
Ubuntu 16.04 / x86_64

version
python 2.7.14(Anconda)
opencv-python==<IP_ADDRESS>

This is not opencv-python issue. The underlying library, OpenCV, is known to have problems with multiprocessing environments, see for example https://github.com/opencv/opencv/issues/5150. I can't fix this problem in this package. See the linked issue and other issues which link to it. You can always try to upgrade the package (latest is <IP_ADDRESS>) but I believe it won't help in this case.


Reformat CONTRIBUTING.md for better readability

This patch does not change the content of the CONTRIBUTING.md but
merely reformats the markdown for better readability of the source code.
Namely:

The URLs are extracted from the text and specified separately.
The tables are formatted so that the columns are aligned (and
readable in a text editor).
All sentences are put on a single line ("unbroken") so that it is
easier to diff changes in Git.

@g1zzm0 FYI


chore(main): release 1.1.2-beta

:robot: I have created a release beep boop
1.1.2-beta (2023-07-13)
Bug Fixes

git url http ssh convertion issue (04dcdd6)
sync error format (da14308)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/appblocks-hub/BB-CLI/releases/tag/v1.1.2-beta :sunflower: