text:
Extend AbstractExtension instead of using Twig_Extension

Twig_Extension is deprecated and to remove twig/extensions this needs to go

Sonata admin officially migrated to runroom-packages/sortable-behavior-bundle, try it instead.
https://symfony.com/bundles/SonataAdminBundle/current/cookbook/recipe_sortable_listing.html

Thanks for letting me know @dmitryuk

authors: dmitryuk martijnboers

repo: pix-digital/pixSortableBehaviorBundle


text:
Search :  entraide

Si aucun résultat  il y a "Recherche en cour qui tourne tjr "

Ok done ! C'étaoit commun à toutes les apps

source: gharchive/issue

license_type: permissive

license_source: bigquery


text:
sécuriser le champ de recherche

quand on tape des caractères spéciaux comme ( ; " ça provoque des erreurs pas cool du tout

ah j'ai vu ce bug depuis hier
mais c'est direct au chargement
ce n'edst pas que lier a la recherche

ca semble etre bon

authors: Kgneo oceatoon

repo: pixelhumain/communecter


text:
EKS Fargate Support

Is your feature request related to a problem? Please describe.
Pixie support the EKS-Fargate runtime.
https://docs.aws.amazon.com/eks/latest/userguide/fargate.html
Describe the solution you'd like
Pixie be installable on EKS-Fargate
Describe alternatives you've considered
NA
Additional context
Fargatge with EKS does not currently allow daemonsets

Daemonsets are not supported on Fargate. If your application requires a daemon, you should reconfigure that daemon to run as a sidecar container in your pods.

https://docs.aws.amazon.com/eks/latest/userguide/fargate.html

Would be nice to have!

Pixie uses eBPF to automatically capture telemetry data and so we're blocked on Fargate's current incompatibility with eBPF: https://github.com/aws/containers-roadmap/issues/1027.

authors: cobookman htroisi isaevdan

repo: pixie-io/pixie

license_source: github-api


text:
Add offscreen support

Closes #273

Based on and blocked by:

[x] #275

Done, re-tested, all tests pass

source: gharchive/pull-request

repo: pixiebrix/webext-messenger

license: MIT


text:
🛑 Edge Platform is down

In c15e27d, Edge Platform (https://edge.pixify.co.uk/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Edge Platform is back up in d7809ba.

repo: pixifydigitalagency/monitors


text:
Graphics with cacheAsBitmap clips the child object

If for Graphics object enable cacheAsBitmap, all children objects will be cut on the border original object. Is it bug or feature?
Example:

<!DOCTYPE html>
<html class="no-js" lang="en">
    <head>
        <meta charset="utf-8"/>
        <title>Test</title>
    </head>

    <body style="background-color: gray;"></body>

    <script src="https://cdnjs.cloudflare.com/ajax/libs/pixi.js/3.0.9/pixi.js" type="text/javascript"></script>
    <script>
    var makeTestObject = function() {
        var obj = new PIXI.Graphics();
        obj.lineStyle(3, 0xff0000, 1);
        obj.drawRect(0, 0, 50, 50);

        var subObj = new PIXI.Graphics();
        subObj.lineStyle(3, 0x00ff00, 1);
        subObj.drawRect(25, 25, 50, 50);
        obj.addChild(subObj);
        return obj;
    };

    var renderer = PIXI.autoDetectRenderer(300, 300, {transparent: true});
    document.body.appendChild(renderer.view);

    var stage = new PIXI.Container();
    var container = new PIXI.Container();
    stage.addChild(container);
    // container.cacheAsBitmap = true;  // clip

    var ex1 = makeTestObject();
    container.addChild(ex1);
    ex1.position.set(50, 50);
    ex1.cacheAsBitmap = true;   // clip
    console.log('ex1 bounds:', ex1.getLocalBounds());

    var ex2 = makeTestObject();
    container.addChild(ex2);
    ex2.position.set(150, 50);
    console.log('ex2 bounds:', ex2.getLocalBounds());

    renderer.render(stage);

    </script>

</html>

IIRC the calculated bounds of Graphics (and sprite) does not include children. Probably what causes this.

authors: boris-ulyanov englercj


text:
scrolling-text marquee in PIXI js

I have an application using Pixi.js and it uses WebGLRenderer.
I want to do a scrolling-text marquee with fade out gradient on the left and right edges similar to this CSS example below.
https://codepen.io/jamesbarnett/pen/kfmKa
Anyone has done it before ? any help is appreciated.

I have already done something similar in a old project.
By downloading the script, I think you should have a good idea to how proceed.
You need use mask and container for parent.
https://forums.rpgmakerweb.com/index.php?threads/pixi-text-multi-motions-styles-core-v1-0.86117/

@PappuBache closing as you have been kindly shown an example :)

authors: PappuBache djmisterjon themoonrat


text:
Sprite sizing when increasing the size of the texture's frame

Currently when I create a sprite, I sometimes want to increase the resolution of the sprite on the fly. To do that I update the Sprite's texture BaseTexture to a higher resolution image and then update the texture's frame to cover the new texture.
This causes the current sprites to increase in size.
Note: There's maybe another bug regarding updating a textures base texture, if I do not update the Textures frame then it seems to not update the Sprite size but still updates and shows the full resolution (which seems to me that it isn't always correctly respecting the textures frame).
Expected Behavior
When setting a sprites size by height and width (instead of scale) it should always be that height and width.
Current Behavior
When changing the sprites texture, updating the texture frame changes the size of the sprite
Possible Solution
If height and width are used to set a sprites dimensions, update the scale property when the texture frame is changed
Steps to Reproduce
Environment

pixi.js version: 4.5.1

Are you changing the frame, or are you changing the width/height? In PixiJS, width and height are just setters/getters of scale. There is no concept of "set this object to be X pixels wide", instead it is "set the scale to be a value that will make it X pixels wide right now".
If you want to adjust the sprite to have a specific width/height after the frame has changed, you will need to manually set width/height again.

I understand that's how it works now and that's how I currently use it, by rescaling once a texture has changed, which means that this may be more of a feature request than a bug report.
But given I am specifying the width and height of a sprite, I think it would be sensible to enforce those dimensions as that's what I would expect as a user, and automatically rescale if a height or width is set.
Is this is an unreasonable expectation/out of the scope of PIXI?

@SamStonehouse thanks for the feature suggestion.
I'm not sure I fully understand your use-case. You want to change the resolution of a Sprite on-the-fly? Could you explain why you'd want to do this? There are other paths in PixiJS to achieve the same thing and locking the width and height is a little counter to how the library currently handles sprites, as @englercj explained well above.
Another approach you might want to try is extending PIXI.Sprite and add or override APIs to set the a bounded width and height.
Personally, I think the suggestion is slightly out of scope of Pixi, but would love to hear what other folks think. If there's enthusiasm for a feature, we will consider.

My use case is as follows:

I have lots of the same sprites on the screen, at different (scalable) sizes, but they all use the same texture
My sprites are generated from SVG's, so when a new bigger sprite comes in I regenerate the texture so it's the size of the largest sprite (so it looks like it's a normal resolution)
I then re-scale all my other already existing sprites to not enlarge with the new texture dimensions

But I've already specified what width and height I want them to be in pixels and it makes sense to me that if I set the width and height then I don't expect it to be dependent on the texture size changing.
Extending the PIXI.Sprite is maybe an option, is there methods available to listen for a texture changing size or frame?

BaseTexture has an update event. You could also emit your own event on Texture or BaseTexture that your Sprite instances listen to and automatically react to.

I've spent a day looking at this and I definitely feel the current way doesn't work the way it's supposed to.
If I change the sprites texture then it obeys the height and width which is already set (and rescales automatically). However the same behavior does not happen when changing the current textures base texture (as described above).
But it does seem that updating the baseTexture of a Texture isn't handled that well? (or at all?)
Since that it doesn't re-apply some some BaseTexture listeners in Texture, it only applies them on initialisation, such as:
baseTexture.on('update', this.onBaseTextureUpdated, this);
Am I abusing PIXI by changing a textures base texture or is this just part of the API which hasn't been looked at in a while?

Could you please provide a jsfiddle or codepen demonstrating what you're trying to do? Would be helpful to see a simple example.

(or a playground: https://pixiplayground.com/#/edit) 😄

This is the gist of what I'm trying to do: https://pixiplayground.com/#/edit/6O5VSa8ll5lLTR~xVzqF0
At the bottom I have a timeout which does the change I'm intending to do after 1 second.
I've also included an example which works by creating a new texture, rather than updating the current texture's base texture. (Something I don't wish to do as I don't control sprites in the area of code this operates, it's only concern is updating textures).

If you create a texture from a canvas and then redraw you can called update on the baseTexture. For instance:
https://pixiplayground.com/#/edit/UTNuXvJ1r3KxtI_WV_7cf

You're still resetting the sprite height and width once changing the base texture that way which is what I'm trying to avoid. I don't have any sprite code near my texture engine due to separation of concerns, so I'd still like to know whether re-assigning a baseTexture is wrong? Or is it supposed to work similar to just setting a texture in which case there's a small bug which I think can be fixed by adding a baseTexture getter and setter.
That or make the Texture baseTexture property read only and updating the docs so it's clear you're not supposed to do that?

Reassigning a baseTexture isn't necessarily wrong but it's probably safe to say this is an antipattern. It's more common to swap Texture object between Sprite objects than it probably is to swap BaseTextures between Texture objects.

I'd agree if it was the case that I was using this to actively change the texture of a sprite, but I'm just updating the texture with a new resolution, which I want to do for all sprites in the scene, which use the same texture; this could be hundreds.
Using the same texture and updating the base texture once makes much more sense to me.
I'm definitely not saying that this should be the way to swap a sprites texture, just a way to update a texture.
Do you mind if I create a PR with better support for changing base textures?

Closing this as I believe the question has been answered :)

authors: SamStonehouse bigtimebuddy englercj themoonrat


text:
Don't use 'pretest' script in package.json

Right now, package.json contains the lines:
  "scripts": {
    ...
    "test": "floss --path test",
    "unit-test": "floss --path test",
    ...
  }

You might think that npm run test and npm run unit-test do the same thing. But they don't, because there's a "pretest" script in there as well:
  "scripts": {
    ...
    "pretest": "npm run lint && npm run build",
    ...
  }

Is there a reason to split these up? If not, I think this should be made more explicit and less spooky-action-at-a-distance:
  "scripts": {
    ...
    "test": "npm run lint && npm run build && npm run unit-test",
    "unit-test": "floss --path test",
    ...
  }

(#6925 documents my trouble figuring this out.)
Thanks!

Thanks for the suggestion, but I'm going to close this as it's unnecessary and breaks some intentional designed functionality mentioned above. The script npm test is used more for the CI-side of things and does build using pretest (an npm convention).

authors: bigtimebuddy joshuahhh


text:
[BUG] fps down to 30 after roblox new fps selecting feature

Acknowledgement of preliminary instructions

[X] I have read the preliminary instructions, and I am certain that my problem has not already been addressed.

What problem did you encounter?
joined server fps fell to 30, i have normal laptop set

Did you check to see what your framerate is set to in the escape menu?

Issue has been awaiting clarification for over a month, closing as stale. If you have anything further to add, just respond and I'll reopen.

repo: pizzaboxer/bloxstrap


text:
chore: cloudshell-tutorial to 0.0.1

chore: Promote cloudshell-tutorial to version 0.0.1

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
If they are not already assigned, you can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

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


text:
ConditionClause's join_type AND works wrong

ConditionClause's join_type AND works not my expectation
{
  "conditions": [
    {"key": "user_id", "value": "1234", "operator": "int_eq"},
    {"key": "last_logged_in", "value": "1598711598", "operator": "int_gte"}
  ],
  "join_type": "AND"
}

Expected result is
Device which satisfying "user_id" eq 1234 ALSO satisfying "last_logged_in" gte 1598711598
But in real
No result (because query is generated like: key='user_id' AND value_int=1234 AND key='last_logged_in' AND value_int >= 1598711598)

It can be tested with /devices/-/:search

Because of key=1 AND value=1 and key=2 AND value=3 intersection in one row is "inconsistence", AND operator works wrong than I thought.
IDEA:
For "Right Intersection", there should use INNER JOIN with AND operator
If we need resolve "user_id" eq 1234 ALSO satisfying "last_logged_in" gte 1598711598, SQL would be
SELECT distinct d2.device_id FROM `device_property` d1
INNER JOIN `device_property` d2
    WHERE d2.key='user_id' AND d2.value_int=1234
        AND d1.key='last_logged_in' AND d1.value_str>=1598711598

That means: user_id:1234 ALSO, last_logged_in: (gte) 1598711598
And It could be more complex
SELECT distinct d3.device_id FROM `device_property` d1
    INNER JOIN `device_property` d2
    INNER JOIN `device_property` d3
        WHERE
           (
                (d1.key='a' AND d1.value_str='b') OR (d2.key='c' AND d2.value_str='d')
           ) AND (
                d3.key='e' AND d3.value_str='f'
           )

That means: (a:b OR c:d) ALSO e:f

In this problem, MongoDB can be more reasonable solution.

repo: pjongy/jraze


text:
Обновить index.ts

Did I do the right thing?

@getneil ?

i don't see an az.json in translations; that would need to be added with appropriate content, i would think.

@adam50200 it looks like you'll need a few more changes, like this

@adam50200 please add the json file for the translation.

i don't see an az.json in translations; that would need to be added with appropriate content, i would think.

This one?
https://github.com/pkgxdev/ossapp/pull/832/files

I'm confused, my head already hurts, I don't understand

This and the other should be a single pull request.

no updates.

authors: adam50200 getneil jhheider mxcl

repo: pkgxdev/ossapp


text:
🛑 WAY👌 Blog is down

In e38a9aa, WAY👌 Blog (https://wayok.cn) was down:

HTTP code: 0
Response time: 0 ms

Resolved: WAY👌 Blog is back up in 6db7927 after 27 minutes.


text:
<PKHUD.FrameView> is being asked to animate its opacity. This will cause the effect to appear broken until opacity returns to 1.

It's quite strange that Xcode console log message, I don't know why?

I got this problem too & also don't know what happened. But it still works well, so I just ignore it

The origin of this problem is described here: http://stackoverflow.com/questions/26325141/xcode-warning-this-will-cause-the-effect-to-appear-broken-until-opacity-return
The problems are the following 3 lines of code in the following methods in 'Window.swift'
internal func showFrameView() {

       layer.removeAllAnimations()
        makeKeyAndVisible()
        frameView.center = center

        // ------------------------------
        // currently
        frameView.alpha = 1.0
        // how it should be
        frameView.backgroundColor = frameView.backgroundColor?.colorWithAlphaComponent(1.0)
        // ------------------------------

        hidden = false
    }

and
internal func hideFrameView(animated anim: Bool, completion: ((Bool) -> Void)? = nil) {
        let finalize: (finished: Bool) -> (Void) = { finished in
            if finished {
                self.hidden = true
                self.resignKeyWindow()
            }

            self.willHide = false
            completion?(finished)
        }

        if hidden {
            return
        }

        willHide = true

        if anim {
            UIView.animateWithDuration(0.8, animations: {

                 // ------------------------------
                // currently, causes error message
                self.frameView.alpha = 0.0
                 // how it should be
                self.frameView.backgroundColor = self.frameView.backgroundColor?.colorWithAlphaComponent(0.0)
                // ------------------------------

                self.hideBackground(animated: false)
            }, completion: finalize)
        } else {

            // ------------------------------
            // currently, causes error message
            self.frameView.alpha = 0.0
             // how it should be
            self.frameView.backgroundColor = self.frameView.backgroundColor?.colorWithAlphaComponent(0.0)
             // ------------------------------

            finalize(finished: true)
        }
    }

Please see #6 - There's an idea for a workaround (nesting the view in a containing UIView and animating that one), but I haven't gotten to implementing yet.

repo: pkluz/PKHUD

license: mit


text:
Add bucketize op and  tests

Add bucketize op and tests, use IE ref mode as ngraph can not run this operation.

Looks good! I think all that needs to happen now is:

Wait for plaidml/plaidml#1524 to land
Update the call to op::repeat to the new API from that PR

authors: XinWangIntel tzerrell

repo: plaidml/openvino


text:
number of playlist subscribers

Hi
Thank you for Spotipy! It's awesome. One quick question:
Is it possible to get the number of subscribers to a playlist using Spotipy?ck
I tried asking this on stackoverflow using the Spotipy tag which doesn't seem to exist
Thank you
Tom

That doesn't seem to be provided by the API

authors: ghost stephanebruckert

repo: plamere/spotipy


text:
feat: use vtpool when cloning poolable objects

This PR adds support for using the vtpool when cloning poolable objects.

Thanks for the PR! I don't love the new generated code using new() -- I have hopes that someday the Go compiler will optimize literal struct initialization to prevent zeroing of memory that will be overriden, but today is not the day, I guess.

authors: kruskall vmg

repo: planetscale/vtprotobuf


text:
Super cool

Just want ask some questions.

Do you use flux? If so, do you found some patterns already?
If you don't use cjsx how do you feel about things like
https://github.com/adelevie/react-tags
https://github.com/kalasjocke/react-coffee-elements
or just plain $ = React.DOM
Do you have an opinion on how to structure folder structures? For example like

components
pure_components
containers
pages

Coming from rails and ruby, i feel lack of established conventions yet, but hope we all get to the promise land.

Hi @onemanstartup. Sorry for the delay. I totally missed this:

We do use Flux. @seven1m has some great thoughts from his experience detailed here: https://github.com/planningcenter/flux-patterns
We never really felt the need to use react-tags or react-coffee-elements. Or goal in removing CJSX was to limit the number of dependencies we needed in place to write React components. In practice, we'll destructure the elements out of React.DOM, as you mentioned. To be quite honest, we've started writing less CoffeeScript and using JSX/JS. We do all new components in JS/JSX.
We put everything in components. Personally, I don't like the idea of separating/naming classes by pattern. But that argument definitely has to sides :)

Don't worry about delay :)
Everything in components will soon become unmanageable.
Anyway thanks for reply.

Yah. It does seem like containers seems like a totally logical dividing line.

authors: chantastic onemanstartup

repo: planningcenter/react-patterns


text:
Gracefully handle invalid authenticity token

In a vanilla Rails 4.1.9 installation with Devise 3.4.1 when protect_from_forgery with: :null_session is defined in ApplicationController in case of CSRF mismatch the following exception occurs:
NoMethodError (undefined method `to_key' for nil:NilClass):
  vendor/bundle/ruby/2.1.0/gems/devise-3.4.1/app/controllers/devise/registrations_controller.rb:50:in `update'
  vendor/bundle/ruby/2.1.0/gems/actionpack-4.1.9/lib/action_controller/metal/implicit_render.rb:4:in `send_action'
  vendor/bundle/ruby/2.1.0/gems/actionpack-4.1.9/lib/abstract_controller/base.rb:189:in `process_action'
  vendor/bundle/ruby/2.1.0/gems/actionpack-4.1.9/lib/action_controller/metal/rendering.rb:10:in `process_action'
  vendor/bundle/ruby/2.1.0/gems/actionpack-4.1.9/lib/abstract_controller/callbacks.rb:20:in `block in process_action'
  vendor/bundle/ruby/2.1.0/gems/activesupport-4.1.9/lib/active_support/callbacks.rb:113:in `call'
  vendor/bundle/ruby/2.1.0/gems/activesupport-4.1.9/lib/active_support/callbacks.rb:113:in `call'
  vendor/bundle/ruby/2.1.0/gems/activesupport-4.1.9/lib/active_support/callbacks.rb:149:in `block in halting_and_conditional'
  vendor/bundle/ruby/2.1.0/gems/activesupport-4.1.9/lib/active_support/callbacks.rb:149:in `call'
  vendor/bundle/ruby/2.1.0/gems/activesupport-4.1.9/lib/active_support/callbacks.rb:149:in `block in halting_and_conditional'
  vendor/bundle/ruby/2.1.0/gems/activesupport-4.1.9/lib/active_support/callbacks.rb:149:in `call'
  vendor/bundle/ruby/2.1.0/gems/activesupport-4.1.9/lib/active_support/callbacks.rb:149:in `block in halting_and_conditional'
...

To replicate just head over to /users/edit form as a signed-in user and before submitting the form alter its authenticity_token value.
Probably this happens due to the execution order of the action filters, i.e. :authenticate_scope! is performed before :verify_authenticity_token.
My current solution was to override handle_unverified_request as follows:
class ApplicationController < ActionController::Base

  # Overwrite unverified request handler to force a refresh / redirect.
  def handle_unverified_request
    super # call the default behaviour, including Devise override
    throw :warden, redirect: request.referer || request.url
  end
end

What is your opinion? Am I missing something?

The current override may not make much sense. The purpose of null session is to continue serving requests, if you are going to redirect, you may as well not use null session? Other than that, it looks fine.
That's exactly the problem with  null session, there will be code that assumes a session exists, and it will definitely break. On Devise and on your application.

@josevalim thank you for your response and sorry for coming back to this, but let's document a best practice or a recommendation on this. The question would be: What's the recommendation for handling invalid authenticity tokens?
My understanding is that there could be two flows:

Refuse the request as invalid, i.e. respond a 400 or a 498 (non-standard, but common) status.
To implement this someone could leave protect_from_forgery with: :exception and then write a rescue block handling the error:
rescue_from ActionController::InvalidAuthenticityToken do
  render text: 'Token expired/invalid', status: 498
end

Empty the session. This should force an authentication, as if the request came in with an empty session.
So, when protect_from_forgery with: :null_session is applied, someone could write this to handle the case:
def handle_unverified_request
  super # call the default behaviour, including Devise override
  authenticate_user!
end

there will be code that assumes a session exists, and it will definitely break

I believe that code may assume a session exists, if measures are taken in order to ensure that a session actually exists. Since Devise already overrides handle_unverified_request to do its stuff, it already takes a part in the flow of the handling of invalid authenticity tokens. Don't you think it's easy to write something like (2) above in Devise handle_unverified_request override?
In that case we are not limiting user choices since:

protect_from_forgery with: :exception: will raise an exception, code from Devise will not run, user should handle the exception as she wish.
protect_from_forgery with: :null_session: if we write something like (2) above in Devise handle_unverified_request override, Devise will re-authenticate user and the fact that "a session exists" is ensured.
protect_from_forgery with: :reset_session: the same as :null_session.

In that way, we could DRY this up and offer a general solution on this. I would be happy to write a PR for this, but I would face the following problems:

How without a session would I know which scope to authenticate?
Since this is an override on ApplicationController, how do I know if the inheriting controller actually needs authenticate_scope! and for which actions?

In my mind it would be easier if we could control the execution order in the before_action chain and somehow enforce the authenticate_scope! to execute after the protect_from_forgery callback.
What's your thoughts?

authors: ebababi josevalim

repo: plataformatec/devise


text:
feat: new env var to get the current URL

It would be great to have a PLT_APP_URL env var that contains the Entry Point URL.
In the dynamic workspace, the URL changes.
So:

You can't predict the URL, so you can't set up some webhooks automatically. Eg: a telegram bot requires to set the webhook URL: https://core.telegram.org/bots/api#setwebhook
You can't play with github envs, because you need to set the enviroment.url var. example: https://github.com/fastify/website/pull/141

@Eomm would you access that in the github action or in the cloud env?

@Eomm would you access that in the github action or in the cloud env?

In the cloud env first
Then having it as output in GHA would be icing on the cake

authors: Eomm mcollina

repo: platformatic/platformatic


text:
fix: Do not set a port when dealing with UNIX sockets.

Fixes #3223.
FWIW, there is also an "error" (is not technically an error but it might be confusing) in the user code. In the apps/express/app/index.ts he was doing this:
app.listen(port, host).on("listening", () => {
  logger.info(
    `Express server is listening on port http://${host}:${port}`
  );
});

But since Watt is changing the port, this would be more correct:
app.listen(port, host).on("listening", function () {
  logger.info(
    `Express server is listening on port http://${host}:${this.address().port}`
  );
});

Can you add a test, please?

I'll add as part of #3115, as I'll have to setup the entire test infrastructure anyway. That's the next issue I'll be working on.

Let's wait until there is a test in place then.

authors: ShogunPanda ivan-tymoshenko mcollina


text:
Manage activity script variables with the CLI

It seems like currently users have to use the API to manage activity scripts variables (add, delete, update).
See https://docs.platform.sh/integrations/activity.html#activity-script-variables
It would be nice to be able to use platform CLI to manage these variables too.
platform variable:create
platform variable:delete
platform variable:update

Maybe with --level=activity-script or something like this.

Testing integration

authors: chadwcarlson nicogommen

repo: platformsh/cli


text:
Volunteer collaborators are needed

We are looking for collaborators to work on this project. If you want to become a collaborator, please leave a comment below.
Collaborator responsibilities include:

Responding to issues
Reviewing and merging pull requests
Development contributions: add features, fix bugs

I think we are already in contact :)

Good idea. I was in the process of creating an own https://angular-polymer.slack.com. What makes more sense? To integrate in the existing polymer slack or a new one? In my opinion to get a channel in the existing polymer slack would be a bit better...
Friendly ping to @platosha :)

I think we should stay close to Polymer, we might as well be in there.

Agreed. I've already made a request in their slack for an own channel. I hope it's possible...

Works for me.
If using Polymer Slack is not possible, I would prefer to create a Gitter chat over Slack then. I like the gitter UI more, and also the webcomponents.org community chat is there.

@MarkPieszak We don’t have a design doc yet.
In short, pretty much all the current implementation is in the single file src/polymer-element.ts, and most of the job is done by the exported PolymerElement(name: string) function. The idea there is simple: it takes an element name from the argument, extracts the element’s prototype, generates a few directives based on the prototype, and returns them.
The only private part was BrowserDomAdapter, as far as I remember. As you probably know, the related part has already stopped working, and the renderer replacement is coming up.

Perfect yeah let me take a look at the implementation to see where I can help out!

Hi. Would love to help.

Wassim! Now it's a party :beers:

@manekinekko Never seen it but seems cool. Did you try it for production use? And how does it differ to this implementation?

@MarkPieszak haha! good to see you here. I'm glad Michael Prentice sent me here ^^
@BorntraegerMarc the interop implementation is straightforward. My goal was to use vanilla  Polymer with raw Angular (>=2) without any glue code (or at as little as possible). So this interop repo tries to serve as an implementation reference. It's not a library.
FYI, I've also implemented another interop repo for Web Components (v0 spec) here: https://github.com/manekinekko/angular-wc-interop
I'm was wondering what made you create this library?
PS: I'm  OK to continue this discussion on slack/gitter.

2 way binding with polymer mainly. @platosha could answer that best

It also does some work to hook up Form events and inputs with Polymer web components. In the past, it has had issues with accessing the window object to get window.Polymer which doesn't play well with Universal. So in addition to switching to the new Renderer interface, it would be nice to get it working with Universal.

@Splaktar Yeah definitely, we want it to play well with Universal/web-workers for sure. I talked with @platosha the other day so I started looking into a few things to get everything going to get the project up to date with everything.
We'll be switching everything to use the Renderer
At the very least just ignore window.Polymer and bail out if it doesn't exist, so we won't be able to render anything on the server, but at least it'll appear on the client later.
The other main issue is AoT since you can't have functions like PolymerElement()
Maybe we can all meet up sometime next week?
Anton and I have been talking in the Polymer slack if you guys are in there, think he's trying to get a channel for this as well.

I'm in the Polymer Slack, but I can't keep up with things in general. A specific channel would be really helpful.

We just got the https://polymer.slack.com/messages/polymer-angular/ channel :)

I would like to contribute to this project.
Can anyone tell me how to begin? Any straightforward issue to start working on it?

@manekinekko Unfortunately that example is out of date.

https://github.com/webcomponents/angular-interop/issues/3
https://github.com/webcomponents/angular-interop/issues/4

I think they need to upgrade to Polymer 2 and base the example on Angular CLI.

Hello guys i would like to contribute. Nowadays I am using this component and I can't update my anguar cli for this reason. Well what do we need to do for make this possible? How can I help?

authors: BorntraegerMarc MarkPieszak Splaktar ZiruZanrgeiff malkomich manekinekko platosha rjsteinert


text:
.ogg loop tags

See forum post for more info: https://forum.playcanvas.com/t/request-ogg-loop-tags/21290
In short: Ogg Vorbis is a lossy audio format that gives an option to put loop tags into the meta of the file which, if recognized by the audio player, can loop the song at any given point and repeat it indefinitely. This is mainly used so the song is able to have an intro that DOESN’T repeat once the song loops.

Wonder if we can do this for MP3s as well as a setting/property of the slot?

authors: MaldivirDragonwitch yaustar

repo: playcanvas/engine


text:
Improve Mesh class description docs

Improve formatting of JSDoc.
I confirm I have signed the Contributor License Agreement.

The multi-line format for vertex / index data is much cleaner!

authors: mvaligursky willeastcott


text:
Add ES Modules

ES Module Component System
This PR adds a  component system  to natively support ES Modules in PlayCanvas. This lays the ground work for further work such as bundling and editor support whilst retaining a familiar API. For further work and roadmap see #4767
New ESM format
const attributes = {
  number: { type: 'number', default: 10, ... },
  nestedObj: {
    number: { type: 'number', default: 10 },
  }
}

export default class MyModule extends EsmScriptType {

  static attributes = attributes;

  // Optional name that overrides 'MyModule'
  static name = 'Other Name'

  // @see https://developer.playcanvas.com/en/user-manual/scripting/anatomy/#initialize
  initialize(){}

  // @see https://developer.playcanvas.com/en/user-manual/scripting/anatomy/#update
  update(dt){}

  // @see https://developer.playcanvas.com/en/user-manual/scripting/anatomy/#postUpdate
  postUpdate(dt){}

  // Called when and entity is disabled or removed from the scene
  destroy(){}
}

New API
This method imports a esm script, registers it with the component, and performs a swap() when it updates if possible. See   the implementaiton
import * as Rotate from './utils/rotate'
const script = entity.esmscript.add(Rotate, { speed: 10 }, enabled )
// initialize() called synchronously
asset(entity.esmscript.get('Rotate') === script)

Few notes:

Familiar API to existing scripts with simple Class based syntax

Script type like functionality (events etc) provided via an optional EsmScriptType base class

Attribute definition is isolated from the class definition, it simply describes metadata for class props that are exposed to the editor. This metadata is not required at runtime. Attribute code can be shaken out.

One module exports one script

Attributes should ideally be statically analyzed, and not have to be executed in order to parse TBD

Execution order is in order for now. This will be changed to a global priority order in s separate PR. see #1857

This does not support HMR/hot swapping. HMR should not be part of production code, and will be part of the launcher

[x] Implement Script ESM Component system

[x] Implement initialize / destroy / update methods

I confirm I have read the contributing guidelines and signed the Contributor License Agreement.

Just personally reviewing this. I'm actually leaning more towards instance based prop attributes, because that's how it currently works, and it just makes so much more sense to think of this.value. Thoughts @willeastcott
export const attributes = {
    aNumber: { name: 'String', default: 10, min: 0, max: 199 }
}

class MyModule {

    aNumber

    constructor(entity, app){}
    update(dt){}
    destroy(){}
}

This is vastly different functionality from the current ScriptType.
Few things:

Attributes are not editor-only, as they do provide better initialisation process and provide runtime events.
Swap method is not a destroy/create, and is an optional, "transparent" hot-reload. In destroy/create developers sometimes handle a lot more than what swap needs: just a transfer of data from old instance to the new one.
Events of a ScriptType are usefull and important, so not providing them by default might confuse at first.
Default properties, such as entity, app, etc, are defined automatically, so it simplifies development for the developer.

Also, class redefenition - can be a blocker, in case of multi-application context, swap, and lazy-loading, using a class - can lead to blockers.
If there is a way to provide class alternative for a ScriptType, it would be great to not reduce the functionality, but actually improve it as well. Justifying only by syntaxis (class vs prototype) IMHO would be not a reasonable feature.

Thanks @Maksims. Great to get your input on this. There's still ongoing discussion around this, so we'll take this all into account as we go.

@marklundin If you don't declare the instance property, IntelliSense is gonna spit out a bunch of errors because aNumber with be undefined and the type willl not be discernable.

I am curious if it is a replacement to ScriptType, or a feature next to it.
Some notes:

We use EventHandler events on scripts a lot. This allows not to pollute the event handler on application level with game related events. The shorter the event list, the faster the lookup is.
The inherited entity and app properties are useful. We kind of assume they are always available for us and we use them often. What would be an alternative way to find the current entity the script is attached to and app instance? Are those ES module scripts even "attacheable"?
We must have a multi-application support. We do it for heavy-weight apps to manage the loading times. Perhaps pc could offer a factory, if import paths are not possible.
I tend to delete the generated boilerplate script contents, whenever I create a new script. At this point its more of a nuisance to me, than a convenience. I'd rather have it blank, honestly, but we can't do it, obviously. I wish I would be able to define my own template that is generated when a new script is created.
I don't use prototype syntaxis, and avoid it when I have an option.
We rarely use script attributes. Mostly to expose them to Editor for general application configuration. If Editor would have a support for custom panels that would affect the launched game (similar to native project settings), then we probably won't use attributes at all. Game scripts occasionally use them, but then again, only for Editor access.
If some developers are using swap, then it should be at least supported in the current form, so we don't break their projects. None of our projects are using it, though, as the cost of maintenance is too high in its current form.

I wish this new script type, would be a sister to ScriptType. The way I see it is that if some or all of the ScriptType features are needed, he would simply create a ScriptType script, or somehow inherit all its features in a new type. If he doesn't need ScriptType features, he could create a new type, possibly inheriting EventHandler. It would be great to have paths supported, so a same module name could live in a different folder asset and we could do imports using paths.

Well, no one really stopping developers of doing their own classes for script systems, the only thing you need a way to attach them from the Editor, which you probably can do by small classic ScriptType with json+array attributes.
If there is a change to the way ScripyTypes would be created, it should be a significantly better than a current system.
Lets first specify what ScriptType is not satisfying, and what are shortcomings are based on developer needs.

Thinking about this more, we probably should focus on the primary task here, which is to add support for ES Modules, anything outside this is secondary, and it doesn't actually require any significant change to the API. Any issues/pain points the existing ScriptType API we can tackle as a separate issue and shouldn't really block the main objective.
I'll spend some time thinking about this more

Thinking about this more, we probably should focus on the primary task here, which is to add support for ES Modules, anything outside this is secondary, and it doesn't actually require any significant change to the API. Any issues/pain points the existing ScriptType API we can tackle as a separate issue and shouldn't really block the main objective.
I'll spend some time thinking about this more

Well, if this will be replacement to a ScriptType, then it is a relevant conversation.
If it is just an alternative, then it will lead to 2 ways of doing the same thing and code segregation between developers.

Thanks for all your input. We've outlined some more detailed design thoughts in this RFC https://github.com/playcanvas/engine/discussions/5770

How do you define a name of a script and attach it to the entity?

How do you define a name of a script and attach it to the entity?

Scripts will be identified by their path, so entity.esmscript.import('./path/to/esmscript.js').  I think this will make it easier to identify what script is being used vs a name

How do you define a name of a script and attach it to the entity?

Scripts will be identified by their path, so entity.esmscript.import('./path/to/esmscript.js'). I think this will make it easier to identify what script is being used vs a name

How that would work in Editor and how that will work with defining scripts on Entities that are not yet loaded?
Also, assets in Editor are all located in a flat way, and do not follow asset folder structures, as folder assets are purely Editor organizational tool.
Also how this will work with concatenation/bundling, and how it will react to re-organizing scripts around the folders?

assets in Editor are all located in a flat way, and do not follow asset folder structures, as folder assets are purely Editor organizational tool.

There is work to create an additional route that matches the directory structure of the asset registry and resolves asset ID's.

Also how this will work with concatenation/bundling, and how it will react to re-organizing scripts around the folders?

The import will be context aware and fetch the bundle if necessary and resolve the ESM script it export. It should also handle code splitting. If you're consuming a PlayCanvas project though as part of a bigger project, and you're manually moving stuff around, then import maps, but this would be a similar case if you moved around regular modules. It would be good, if you had some use-cases to test against.

How that would work in Editor and how that will work with defining scripts on Entities that are not yet loaded?

Could you clarify? Do you mean lazy loading of scripts here?

The import will be context aware and fetch the bundle if necessary and resolve the ESM script it export. It should also handle code splitting. If you're consuming a PlayCanvas project though as part of a bigger project, and you're manually moving stuff around, then import maps, but this would be a similar case if you moved around regular modules. It would be good, if you had some use-cases to test against.

Current implementation simplifies a need to track where scripts are located. So it reduces a chance to break references to scripts when you are moving them between folders or even renaming.
Also it is common use case when two script files implement scripts of the same name, and during development you don't load one, but load the other for swapping purposes.

Could you clarify? Do you mean lazy loading of scripts here?

Every asset in PlayCanvas is assumed to be asynchronous, this is also true for scripts. In large projects it is not viable to load all scripts straight away, but they are loaded in async manner depending on application logic. Most basic example of it: load menu related scripts on initial load (preload), then allow users to interact, then in background load the rest of scripts required by the gameplay.
This is similar to the way web is loading pages and their scripts when you navigate between pages.

Gotcha thanks!

The import will be context aware and fetch the bundle if necessary and resolve the ESM script it export. It should also handle code splitting. If you're consuming a PlayCanvas project though as part of a bigger project, and you're manually moving stuff around, then import maps, but this would be a similar case if you moved around regular modules. It would be good, if you had some use-cases to test against.

Current implementation simplifies a need to track where scripts are located. So it reduces a chance to break references to scripts when you are moving them between folders or even renaming.

Agreed, although this avoids collisions, which would be important if you start importing other code libraries that use the same name id. I think moving folders around is ok, as most people are familiar with having to update imports when they do, plus I really like the idea of having auto-complete for Monaco paths

Also it is common use case when two script files implement scripts of the same name, and during development you don't load one, but load the other for swapping purposes.

Could you clarify? Do you mean lazy loading of scripts here?

Every asset in PlayCanvas is assumed to be asynchronous, this is also true for scripts. In large projects it is not viable to load all scripts straight away, but they are loaded in async manner depending on application logic. Most basic example of it: load menu related scripts on initial load (preload), then allow users to interact, then in background load the rest of scripts required by the gameplay.
This is similar to the way web is loading pages and their scripts when you navigate between pages.

Yep this should work, so if modules are marked 'preload' or similar they are pre-fetched ahead of time, same as is now, either via bundle or not, and then subsequent imports do not trigger network request. If they are not marked preload, then the import is dynamic/lazy and request happens after load.
Also, in bundling, we will code split, so that code shared between entry point A and B (different scenes) can be split into a shared chunk, which minimizes loading of new scenes.

I'd like to see an example with more complex / nested / array attributes to see how it can be used / works.

I just tried to run the Misc/Hello-Script-Modules example and it errors:

Thanks @kungfooman, that's my oversight. It should be fixed now if you want to try again. I'm also in the midst of creating a set of tests as part of this PR which should help

class Test {
  static attributes = {
    layer: {
      type: 'object',
      default: 0,
      title: 'Layer',
      description: 'Which Layer to print the debug lines on'
    }
  };
}
const entity = new pc.Entity("test");
entity.addComponent('esmscript');
entity.esmscript.add(Test);

In the old system you could just set 0 to act as "default" value for type: 'object', but now that errors and the default value is simply dropped - I understand the "type error", but since it was possible before, we should at least be able to express the intention in a better way? Something like: optional: true or something?

These error messages should also contain the given "wrong type value" for reference, could just add { value } as last parameter to Debug.assert.
Another potential issue:
Before we would do something like entity.script.Test to access the script instance (name is our "own" choosen name), but now it would be entity.esmscript.get("Test"); - dependent on the classes name. Whenever a uglifier/minifier went over the code, we can say good-bye to the class names and script instances won't be returned any longer (no one wants broken minified release builds).
Last thing I just want to point out:
Since the esmscript classes are classes without inheriting from e.g. pc.ScriptType or pc.EventHandler, functionality like this.on('attr:color', ...) is dropped and has to be rewritten via pairs of getters/setters. I'm not sure about the consequence for Editor plugins, @LeXXik just mentioned that @leonidaspir depends on this in some of his tools/plugins. How exactly that would affect 3rd party editor plugins is beyond my imagination, but maybe others can share what they think about it. In the beginning it may be no problem since no one made the effort to switch to esmscript yet, but sooner or later developers will adopt and then it may show up.

A couple of questions:

How to know when the script got disabled/enabled without events?
If get/set is not specified for the class, but the attribute is, will the class have a property defined on initialization, and will it be set in realtime when changed in Editor UI?
How to implement lazy-loading if the reference of the class is used instead of the name?
Why not use entity.script.Test still? Isn't calling an extra function unnecessary here?
object attribute type, this is same or different from json (current implementation)? The reason it is json, is that it communicates clearly that it is parseable JSON. Parsing from string and back to json is used by internal loaders as well as save systems that people build. Why change name to object?
If new scripts don't extend some base class, what about basic functionality: enabling/disabling like any other Component?
Entity, Texture, AppBase, Material, and many other classes have destroy method, that is called explicitly by the developer. ScriptType, Entity and few other classes have an event destroy of when it is destroyed. Is there a reason to go against common practice within the engine? This might confuse users and require extra adjustment from ScriptType. Less differences in naming/mechanics there are, easier it will be to switch for users, as well as easier it will be to read either code that can be easily used within both systems.
If an entity is not enabled, will initialize still be called when a script is added to it?

(2) Just tested, yes, it is set then:
class Test {
  static attributes = {
    layer: { type: 'number', default: 123}
  };
  initialize() {
    console.log("TEST", this.layer);
  }
}
const entity = new pc.Entity("test");
demo.app.root.addChild(entity);
entity.addComponent('esmscript');
entity.esmscript.add(Test, null, true);

Outputs: TEST 123
I wonder about possible refactoring of something like (as in scripts/textmesh/text-mesh.js):
    // Handle any and all attribute changes
    this.on('attr', function (name, value, prev) {
        if (value !== prev) {
            if (name === 'font') {
                if (this.font) {
                    this.fontData = opentype.parse(this.font.resource);
                } else {
                    this.fontData = null;
                    this.destroyCharacters();
                }
            }
            if (this.fontData) {
                this.createText();
            }
        }
    });

Sorry about (5), I realized it was my own mistake - I took @LeXXik's AMMO Debug Drawer some years ago as basis and tweaked it a lot for making it "standalone" and for making a repo to show how it works and just some testing between the two module types (legacy vs ScriptType):
https://github.com/kungfooman/playcanvas-test-es/blob/b3aa00e541797a594c6074f544d39be542fc6846/es6/example.js#L3-L14
I never realized before that I used it wrong, since there was no error and everything just worked. So testing this PR actually found a mistake in my own script :+1:
(6) I also don't know how to enable/disable a script besides reimplementing pretty much pc.ScriptType
(8) Just tested, it depends on the last argument of entity.esmscript.add and not on the entity enabledness:
class Test {
  initialize() {
    console.log("Test#initialize called");
  }
}
const entity = new pc.Entity("test");
demo.app.root.addChild(entity);
//entity.enabled = false;
entity.addComponent('esmscript');
entity.esmscript.add(Test, null, true); // last arg called "enabled" is "true" = enabled -> call's inittialize

Regarding the whole of this PR, why not use classes notation with existing system and extend it, instead of creating a new one?
I just did this:
class TestClass extends pc.ScriptType {
    initialize() {
        console.log('initialize');
    }

    update(dt) {
        this.entity.rotate(dt * 90, 0, 0);
    }
}

And then:
entity.script.create(TestClass);

And it worked perfectly. With only a few adjustments to the existing pc.ScriptType, we can ensure that attributes are parsed from static property, and we do not lose any functionality, it works already. It will be easier to add Editor support, and you can do imports as you want.

@Maksims
I’ve opted for a separate system for a few reasons.
We’re planning to allow a global script priority, so users can specify an execution order to types of scripts. This is outlined in a separate issue but existing scripts specify a local script execution order, and so the semantics are different.
Also, I believe it’s important a script shouldn’t require a base class in order to work. It shouldn’t break, or worse partially work with wrong results if it doesn’t inherit from the right class. It need only implement the methods it uses and expose the attributes it requires.
Removing the dep on a super class gives much more flexibility for users, keeps the dependancy between a users scripts and the engine as loose as possible and we also don’t have to worry about maintaining a base class that is difficult to upgrade else it breaks users projects. A base class imported by the user can be versioned independently from the engine. Also attribute events etc are useful, but not everyone uses them, users should be able to use what they need and omit what they don’t.
Also, there’s a fair bit of conditional logic to handle legacy scripts, and I’m reluctant to add another layer for ESM Scripts which is likely needed as they’d need separate Handlers to load them and maybe in other places too.
Taken together, keeping the ESM Scripts as a logically separate component/system makes sense. It keeps things isolated, allows us to provided new functionality without breaking existing code, and is done in a way inline with current practice of upgrades (Model vs Render component).

@kungfooman I'm AFK at the moment, but thanks for reviewing this all. Will get back to you both when I can. Appreciate all the work 🙏

We’re planning to allow a global script priority, so users can specify an execution order to types of scripts. This is outlined in a separate issue but existing scripts specify a local script execution order, and so the semantics are different.

Such system can be implemented to work with an existing scripting system.

Also, I believe it’s important a script shouldn’t require a base class in order to work. It shouldn’t break, or worse partially work with wrong results if it doesn’t inherit from the right class. It need only implement the methods it uses and expose the attributes it requires.

On what basis this is a requirement? Is it a problem with an existing system? Is it a blocker for some commercial projects?
Pretty much every engine in different languages that implements scriptable components - do inherit some sort of a base class. e.g. Unity - MonoBehaviour.

Removing the dep on a super class gives much more flexibility for users, keeps the dependancy between a users scripts and the engine as loose as possible and we also don’t have to worry about maintaining a base class that is difficult to upgrade else it breaks users projects. A base class imported by the user can be versioned independently from the engine. Also attribute events etc are useful, but not everyone uses them, users should be able to use what they need and omit what they don’t.

Not having a base class will have "loose rules" over of how the class should be defined/used. Underlying system will have to forever support such rules. Having a base class will actually provide a stable versioning and migrations approach. That allows users to consciously migrate to another base class if required.
Editor > Engine workflow heavily relies on quick iterations, that what makes real-time workflow a major feature of the Editor. And it heavily relies on attributes: using Editor UI to iterate on things and see in Launcher updated, as needed. As well as in runtime - we use attributes a lot, and pretty much in every project from small to large.
If some features are not desirable, e.g. attribute events, then a feature for the pc.createScript in form of options, or static property on a class - is a good way to control such features.

Also, there’s a fair bit of conditional logic to handle legacy scripts, and I’m reluctant to add another layer for ESM Scripts which is likely needed as they’d need separate Handlers to load them and maybe in other places too.

Yep, there are two systems already, Legacy Scripts, and Scripts 2.0. So adding a third system will not make it better here.

Taken together, keeping the ESM Scripts as a logically separate component/system makes sense. It keeps things isolated, allows us to provided new functionality without breaking existing code, and is done in a way inline with current practice of upgrades (Model vs Render component).

Every move of PlayCanvas to deprecate some component, e.g.: Model > Render, Audio > Sound, Legacy Scripts > Scripts 2.0, Animation > Anim.
Reason for a switch was due to a fundamental shift in underlying data and limitations of previous system, without ability to do graceful improvements of the system without breaking. There decisions had to be massively weighted with cons/pros, to consider them.
Introducing a full on new script component has a major impact:

Split in learning path for all users.
Split in documentation, user manual, forum posts, tutorials etc of old / vs new system. This also worsens learning and accumulation of the community knowledge.
Another system to support.
Another system to deprecate and still support.
Different workflows of achieving essentially the same thing - bad for learning and using any tool/API.

I still have not seen a real problem with a current ScriptType that justified a full switch to a new component system. Please provide actual reasons backed by problems from commercial projects.

One of the lacking features for us with ScriptType is inability to add modules from NPM ecosystem. Given how modules are widespread today, some libraries don't even bother generating IIFE or ES5 variants, so it adds to our burden to bundle them in a way that would work in PlayCanvas. Importing modules should be as natural. It is a hassle at the moment.
I personally don't use TypeScript, but I'm aware of projects that wish they could chose if they want to use TypeScript or Javascript, similar to Babylon. I believe the ESM modules system would allow to make it happen.

One of the lacking features for us with ScriptType is inability to add modules from NPM ecosystem. Given how modules are widespread today, some libraries don't even bother generating IIFE or ES5 variants, so it adds to our burden to bundle them in a way that would work in PlayCanvas. Importing modules should be as natural. It is a hassle at the moment.
I personally don't use TypeScript, but I'm aware of projects that wish they could choose if they want to use TypeScript or Javascript, similar to Babylon. I believe the ESM modules system would allow to make it happen.

We can add ESM modules with existing ScriptType. ESM modules mostly require small improvements to ScriptType, and integration to Editor, it does not require whole new component system at all.

To be honest, this has caused a few headaches in the past...
const c = Color()
script.color = c
c.r = 1
(script.color.r === 1) // nope

Fully disagree. In engine classes it's forgivable, but using a superclass to invisibly override the public members declared by a user in a subclass is super weird.
This is more pronounced in ES class syntax
class MyClass {
  // This is somehow changed to a copy ???
  colorAttr = new Color()
}

If you do this in your code, this is not a copy, that creates a new member and assigns your vector:
class MyClass {
  colorAttr = new Color()
}

but the example Max added:
script.color = new Color()

I would expect the setter of the color would copy the color to its private property, to make sure the user cannot change its content without it being pushed through the setter, where this might need to be handled.
We had issues with this in many cases, where the user would initialize multiple bounding boxes with the same vectors, and when one changes, the other would change too. Also, they'd use Vec3.ZERO to assign it to a property, and later internally this would modify the ZERO static member, causing hard to find issues.

Also it is common to do this:
element.color = pc.Color.RED;

I'm very happy to see discussion around ownership details! Right now values like vectors aren't even cloned yet properly:
function cloneEntityAndFitStuff(entity) {
    const clone = entity.clone();
    const cloneScript = clone.esmscript.get("Test");
    cloneScript.a.scale(0.000001);
    cloneScript.b.scale(0.000001);
    cloneScript.c.scale(0.000001);
    return clone;
}
class Test {
  static attributes = {
    a: { type: 'vec3', default: [  1,  2,  3]},
    b: { type: 'vec3', default: [ 11, 22, 33]},
    c: { type: 'vec3', default: [111,222,333]},
  };
  initialize() {
    console.log("TEST", this.a, this.b, this.c);
  }
}
const entity = new pc.Entity('test');
demo.app.root.addChild(entity);
entity.addComponent('esmscript');
entity.esmscript.add(Test);
const clone = cloneEntityAndFitStuff(entity);
const {a, b, c} = entity.esmscript.get("Test");
console.log("Initial/uncloned entity values are now", JSON.stringify({a, b, c}, null, 2));
console.log("Test *should* be false", entity.esmscript.get("Test").a === clone.esmscript.get("Test").a);

Outputs:

Basically because this is true currently:
entity.esmscript.get("Test").a === clone.esmscript.get("Test").a

Now lets convert the same test script to make it use pc.ScriptType:
function cloneEntityAndFitStuff(entity) {
    const clone = entity.clone();
    const cloneScript = clone.script.Test;
    cloneScript.a.scale(0.000001);
    cloneScript.b.scale(0.000001);
    cloneScript.c.scale(0.000001);
    return clone;
}
class Test extends pc.ScriptType {
  static _ = (
    this.attributes.add('a', {type: 'vec3', default: [  1,  2,  3]}),
    this.attributes.add('b', {type: 'vec3', default: [ 11, 22, 33]}),
    this.attributes.add('c', {type: 'vec3', default: [111,222,333]})
  );
  initialize() {
    console.log("TEST", this.a, this.b, this.c);
  }
}
pc.registerScript(Test, 'Test');
const entity = new pc.Entity('test');
demo.app.root.addChild(entity);
entity.addComponent('script');
entity.script.create("Test");
const clone = cloneEntityAndFitStuff(entity);
const {a, b, c} = entity.script.Test;
console.log("Initial/uncloned entity values are now", JSON.stringify({a, b, c}, null, 2));
console.log("Test *should* be false", entity.script.Test.a === clone.script.Test.a);

Outputs:

Using ScriptType test from above:

I'm also happy that we don't inject a reference from somewhere else into the script.
Whereas this PR script system is replacing "internals":

We could kinda forget about the difference if we would write code more like this:
entity.script.Test.a.copy(d);

This also relates to this PR: https://github.com/playcanvas/engine/pull/4925
One problem of flipping internals via loose ownership: if you assign a frozen object, the type is suddenly "read-only", but no one  defined that type being read-only anywhere. So we ended up with more code testing that in different places (where possible):
Debug.assert(!Object.isFrozen(center), `The constructor of 'BoundingBox' does not accept a constant (frozen) object as a 'center' parameter`);
        Debug.assert(!Object.isFrozen(halfExtents), `The constructor of 'BoundingBox' does not accept a constant (frozen) object as a 'halfExtents' parameter`);

To sum up what I think:

we need a bunch of ownership unit tests that ensure clones are unentangled with source entity references
keep it unified, prefer hard ownership over a loose one

Assigning attribute via the editor/launcher should be efficient, but can be handled outside the class and shouldn't override user code or alter accessor semantics. If the engine needs to monitor attribute changes, we should consider using proxies. Users should explicitly handle attribute changes across scripts, even if it's more verbose but clearer.

I think it should a balance, of convenience and stability. Copying has no runtime memory impact, and a small compute impact, while provides safety. While reference usage gives better init memory, faster execution, but can suffer from safety. Common devs without knowing the implications will end up in problematic situations more often, than they require very precise performance and efficiency in such non-impactful area. If a power user requires such micro-optimisation they are not limited to implement own accessors. Don't forget, we are power users, while majority don't know insides of the engine, and safety for them is more important.

This has now been updated based on feedback

Before we would do something like entity.script.Test to access the script instance (name is our "own" choosen name), but now it would be entity.esmscript.get("Test"); - dependent on the classes name. Whenever a uglifier/minifier went over the code, we can say good-bye to the class names and script instances won't be returned any longer (no one wants broken minified release builds).

The scripting system should now be resistant to mangling, by requiring an explicit class identifier. I've also added tests to cover this. Also it seems that ScriptType has this problem

I also don't know how to enable/disable a script besides reimplementing pretty much pc.ScriptType

enabled is now a property of the script itself and can be used to enable or disable it in the standard way.

Before we would do something like entity.script.Test

Agree with this @kungfooman , although I don't like the idea of overriding a classes props. I'm less concerned with the issue of changing a types shape and more that if a user adds a class system{} it would override the components system prop. I wonder if something like entity.esm.scripts.Test would work, so it's all namespaced under a empty proxy object. Open to suggestions @mvaligursky @willeastcott

I still haven't seen a strong reason for another component system that does exactly the same. Instead of improving ScriptType and extending it. Basically allowing users to use same components as they had, and even attributes in Editor won't need to be changed and hierarchy. No need to parse new extra stuff, no need to support two separate systems!
There will be no possibility for gradual migration as two component systems will not provide same execution order.

Hey @Maksims, so these are friction points in the current ScriptType.
Overriding of class props
This becomes more confusing in class based syntax, but it's also inconsistent applied across types
class MyClass extends ScriptType {
   vec = new Vec3()
   curve = new Curve()
}

vec = script.MyClass.vec
vec.x = 10 // this works
script.MyClass.vec = myOtherVec
myOtherVec.x = 10 // does not work
vec.x = 10 // this works

curve = script.MyClass.curve
curve.x = 10 // this works
script.MyClass.curve = myOtherCurve
myOtherCurve.x = 10 // does not update class
curve.x = 10 // this does not work

This is not an argument against copying per-se, just that it should be clear and transparent to the user what is happening, and something they can opt in and out of. Performing invisible copies is hard to debug. In the engine code itself, this is fine.
Inflexible inheritance
Anecdotal feedback shows users prefer to choose their own base class. This provides more flexibility to the user. Conformance to an ESM Script api is done via an "interface", which will also work for TypeScript type checking class MyScript implements ESMScriptInterface.
Attributes can't be inherited
You can't extend a Script as it's attributes will not work. Attributes are tied to the file they're declared in.
Class name is susceptible to mangling
The __getStaticName function relies on the function name, which can change if a bundler uses Terser or similar.
Scripts override component props
pc.registerScript(class App {}, 'app') // Overrides app base
This goes for any prop of the script component class and any prop in the inheritance chain. This is problematic and can be easy to override, but also makes it difficult to add any new properties to the script component. Also it's not ideal from a JIT perspective as it changes the shape of hidden classes which can cause a deopt. It would be better to access the script instances via a vanilla object
Importing
Current scripts are loaded using a script tag which doesn't work in Node, Deno etc. Using ESM imports is now a standardised way of importing code across environments.
Concatenation + Hot reloading
Not a huge one but existing scripts are compiled using simple string concatenation. Modules would need to be properly bundled in order to retain correct module scope and provide better more modern bundling fearures. Additionally, arguably HMR code should be removed from production code.
Overall
Overall it would be non-trivial to iteratively update the current scripts without breaking existing projects. Using a separate components system gives use more flexibility to move forward in a safe way. Moreso, it allows us logically isolate newer language features from older ones. If a user elects to use ESM modules, we can make assumptions and user newer language  features. Similarly, if they chose to want to use older scripts, they can do so without having to load newer features.  It also provides a way to migrate user as we can point them to a new separate component system

class MyClass extends ScriptType {
   vec = new Vec3()
   curve = new Curve()
}

vec = script.MyClass.vec
vec.x = 10 // this works
script.MyClass.vec = myOtherVec
myOtherVec.x = 10 // does not work
vec.x = 10 // this works

curve = script.MyClass.curve
curve.x = 10 // this works
script.MyClass.curve = myOtherCurve
myOtherCurve.x = 10 // does not update class
curve.x = 10 // this does not work

I'm sorry, but your code is incorrect. These assignments do work.
Properties work here as they work in your class definitions. Just like they do work currently with ScriptType.
Please test the code you've provided.
Current behavior is this:
class TestClass extends pc.ScriptType {
    static name = 'test';

    vec = new pc.Vec3();
    curve = new pc.Curve();
}

// ...

const script = entity.script.test;
const otherVec = new pc.Vec3();
script.vec = otherVec;
otherVec.x = 10;
script.vec.x === 10; // true

Inflexible inheritance
Anecdotal feedback shows users prefer to choose their own base class. This provides more flexibility to the user. Conformance to an ESM Script api is done via an "interface", which will also work for TypeScript type checking class MyScript implements ESMScriptInterface.

In JavaScript there is no interface, inheritance is implemented using extends. Which you can use with the current system:
class NetworkScript extends pc.ScriptType {
    // implements networking
}

class Barrel extends NetworkScript {
    static name = 'barrel';
}

So you can use inheritance the way you want. Also, this is common practice in the industry and across pretty much all engines - to inherit the base class. Can you please provide a poll or some source of PlayCanvas user preferences on this topic?

You can't extend a Script

We can tackle that issue for existing ScriptType which will solve it for prototype and class approaches.

attributes will not work. Attributes are tied to the file they're declared in.

This is not an engine issue, but the way the Editor loads and parses scripts. So it has no context of other scripts. Nothing to do with the engine. This will be same issue for your ESM Scripts implementation. Please either upvote the relevant ticket one Editor's repo or create a new Issue there.

Class name is susceptible to mangling

The same issue for the ESM Script implementation.

Current scripts are loaded using a script tag which doesn't work in Node, Deno etc. Using ESM imports is now a standardised way of importing code across environments.

You can load scripts in node.js: you can import and you can provide exports. We use PlayCanvas in node.js and have no problems with it.
If you want to load scripts with automatic loading, then this can be easily improved, just create a PR for the non-browser loading path.

Not a huge one but existing scripts are compiled using simple string concatenation. Modules would need to be properly bundled in order to retain correct module scope and provide better more modern bundling fearures. Additionally, arguably HMR code should be removed from production code.

Do you have a good stats on this? Haven't had a single issue or heard of one regarding concatenation process. It does what it supposed to: concatenates scripts, minifies them and ensures they work exactly same way as non-concatenated or minifed.
It also solves few important things: order of execution, same scoping, order of script regestration.
Do you have a better option for more efficient minifiers? If so, feel free to propose a better solution in Editor's repo, as it is Editor's task to concatenate and minify scripts.
As for concatenation or minifacation for engine-only users. They can already use whatever systems they want, and minify the way they want. There are no blockers.
Hot-reloading, is extremely slim part of the codebase, and people use it. We use it even on node.js back-end production with multiplayer projects, where we can update gameplay not only during development, but also hot-patch stuff in production. And it is extremely powerful. Please provide a strong argument and production cases where it caused any issue that it requires a removal.

Even though these could be individually solved. It would be non-trivial to iteratively update the current scripts without breaking existing projects.

I strongly disagree. The users and the engine have their ways and have been working pretty well. It can be improved - and progressive improvements are the way to go. Unless there is a major roadblock, which then requires an alternative (e.g. Audio > Sound component, or Model > Render).
This has to be done and can be done like everything before, updating the engine without breaking stuff. This is the way the engine has been developed since the beginning - it always works, and doesn't break older stuff. It is important for developers that trust the engine.

Using a separate components system gives more flexibility to move forward in a safe way. Moreso, it allows us to logically isolate newer language features from older ones. If a user elects to use ESM modules, we can make assumptions and use newer language features. Similarly, if they want to use older scripts, they can do so without having to load newer features.

I'm sorry, but I've provided a major list of issues with a new system, and it does not solve all the list you've provided regarding the current system. So the new system will suffer as much from the same issues. As they need to be tackled separately.

It also provides a clean an straightforward way to migrate users.

There is no need to migrate. That's the point.
We can improve existing ScriptType, to satisfy certain things and provide a very gradual alternative. Without the need to migrate. Implementing a separate scripting component will not be supported by Editor straight away, and actually will have issues of to be implemented with Editor. And will require a full migration by users, which is way more intrusive.
I might point out, that I've referring to the majority of users, which are Editor users. Engine-only users are important too, but the solution has to serve both environments.
Implementing a whole new scripting component system, that is almost identical to ScriptType, and it does not still solve the majority of issues you have listed here because they come from Editor and other places. I'm sorry, but I don't believe this should be part of the Engine.

We've opted to use the existing ScriptType to support ES Modules. Closing for now

authors: LeXXik Maksims kungfooman marklundin mvaligursky willeastcott


text:
Disable clustered lighting

Viewer doesn't need clustered lighting and startup is impacted on windows.

Do you have any stats for loading that olive bowl with it enabled/disabled for example?

Do you have any stats for loading that olive bowl with it enabled/disabled for example?

I tested startup on MacOS and saw only a small difference. I don't have access to a windoze machine unfortunately.

authors: slimbuck willeastcott

repo: playcanvas/model-viewer


text:
Enhance Helm chart to use Secrets created by External Secrets Operator

Success Criteria:

We can run our fork of the openshift-actions-runner-chart without supplying any secrets at the command line

https://github.com/ploigos/openshift-actions-runner-chart

The secrets that the chart uses come from Vault, via the Secret that the External Secrets Operator creates

@aarongreen85 the idea was #34 / #36 make Helm create ExternalSecrets. This issue is about using them to do something useful (i.e. consuming the info in the Secrets). It's possible that no additional work is required for that latter part, or that it would be easier to roll that scope into the other tickets. I'm fine however you want to divide the work.

Closed by #34 and #36

authors: dwinchell gfulton-redhat

repo: ploigos/infra-ops


text:
Duplicated error message

Running plot.confusion_matrix(df.predicted_price, df.real_price)
Gives this traceback, in the end of it the community slack message shows twice:
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
Cell In[74], line 1
----> 1 plot.confusion_matrix(df.predicted_price, df.real_price)

File ~/opt/miniconda3/envs/py310/lib/python3.10/site-packages/sklearn_evaluation/telemetry.py:51, in SKLearnEvaluationLogger.log.<locals>.wrapper.<locals>.inner(*args, **kwargs)
     49     metadata["exception"] = str(e)
     50     telemetry.log_api("sklearn-evaluation-error", metadata=metadata)
---> 51     raise e
     53 return result

File ~/opt/miniconda3/envs/py310/lib/python3.10/site-packages/sklearn_evaluation/telemetry.py:47, in SKLearnEvaluationLogger.log.<locals>.wrapper.<locals>.inner(*args, **kwargs)
     44 telemetry.log_api("sklearn-evaluation", metadata=metadata)
     46 try:
---> 47     result = func(*args, **kwargs)
     48 except Exception as e:
     49     metadata["exception"] = str(e)

File ~/opt/miniconda3/envs/py310/lib/python3.10/site-packages/ploomber_core/exceptions.py:85, in modify_exceptions.<locals>.wrapper(*args, **kwargs)
     82 @wraps(fn)
     83 def wrapper(*args, **kwargs):
     84     try:
---> 85         return fn(*args, **kwargs)
     86     except ValueError as e:
     87         message = e.args[0] + COMMUNITY

File ~/opt/miniconda3/envs/py310/lib/python3.10/site-packages/sklearn_evaluation/plot/classification.py:208, in confusion_matrix(y_true, y_pred, target_names, normalize, cmap, ax)
    172 @SKLearnEvaluationLogger.log(feature="plot")
    173 @modify_exceptions
    174 def confusion_matrix(
    175     y_true, y_pred, target_names=None, normalize=False, cmap=None, ax=None
    176 ):
    177     """
    178     Plot confusion matrix.
    179
   (...)
    206
    207     """
--> 208     return ConfusionMatrix.from_raw_data(
    209         y_true=y_true,
    210         y_pred=y_pred,
    211         target_names=target_names,
    212         normalize=normalize,
    213         cmap=cmap,
    214     ).ax_

File ~/opt/miniconda3/envs/py310/lib/python3.10/site-packages/ploomber_core/exceptions.py:85, in modify_exceptions.<locals>.wrapper(*args, **kwargs)
     82 @wraps(fn)
     83 def wrapper(*args, **kwargs):
     84     try:
---> 85         return fn(*args, **kwargs)
     86     except ValueError as e:
     87         message = e.args[0] + COMMUNITY

File ~/opt/miniconda3/envs/py310/lib/python3.10/site-packages/sklearn_evaluation/plot/classification.py:151, in ConfusionMatrix.from_raw_data(cls, y_true, y_pred, target_names, normalize, cmap)
    141 """
    142
    143 Notes
   (...)
    146     Added ``cmap`` argument.
    147 """
    148 target_names, cmap = _confusion_matrix_validate(
    149     y_true, y_pred, target_names, cmap=cmap
    150 )
--> 151 cm = _confusion_matrix(y_true, y_pred, normalize)
    152 return cls(cm, target_names=target_names, normalize=normalize, cmap=cmap).plot()

File ~/opt/miniconda3/envs/py310/lib/python3.10/site-packages/sklearn_evaluation/plot/classification.py:164, in _confusion_matrix(y_true, y_pred, normalize)
    163 def _confusion_matrix(y_true, y_pred, normalize):
--> 164     cm = sk_confusion_matrix(y_true, y_pred)
    166     if normalize:
    167         cm = cm.astype("float") / cm.sum(axis=1)[:, np.newaxis]

File ~/opt/miniconda3/envs/py310/lib/python3.10/site-packages/sklearn/metrics/_classification.py:317, in confusion_matrix(y_true, y_pred, labels, sample_weight, normalize)
    232 def confusion_matrix(
    233     y_true, y_pred, *, labels=None, sample_weight=None, normalize=None
    234 ):
    235     """Compute confusion matrix to evaluate the accuracy of a classification.
    236
    237     By definition a confusion matrix :math:`C` is such that :math:`C_{i, j}`
   (...)
    315     (0, 2, 1, 1)
    316     """
--> 317     y_type, y_true, y_pred = _check_targets(y_true, y_pred)
    318     if y_type not in ("binary", "multiclass"):
    319         raise ValueError("%s is not supported" % y_type)

File ~/opt/miniconda3/envs/py310/lib/python3.10/site-packages/sklearn/metrics/_classification.py:106, in _check_targets(y_true, y_pred)
    104 # No metrics support "multiclass-multioutput" format
    105 if y_type not in ["binary", "multiclass", "multilabel-indicator"]:
--> 106     raise ValueError("{0} is not supported".format(y_type))
    108 if y_type in ["binary", "multiclass"]:
    109     y_true = column_or_1d(y_true)

ValueError: continuous is not supported
If you need help solving this issue, send us a message: https://ploomber.io/community
If you need help solving this issue, send us a message: https://ploomber.io/community

thsi has been fixed in ploomber-core https://github.com/ploomber/core/pull/42

authors: edublancas idomic

repo: ploomber/sklearn-evaluation


text:
Standard input thread

supersedes https://github.com/plotly/Kaleido/pull/50

I just added another change to make sure the standard input thread gets restarted if needed

repo: plotly/Kaleido


text:
[WIP] DashR Shiny LinkedClick App

Issue for app: #177
App pull request

[ ] This is a new app
[x] I am improving an existing app (redesigns/code "makeovers")

About

Current gallery app URL: https://plot.ly/r/shinyapp-linked-click/

Workflow

[x] I have created a branch in the appropriate monorepo, and the
elements necessary for successful deployment are in place.
[ ] If the app is a redesigned and/or restyled version of an
existing gallery app, I've summarized the changes requested in the
appropriate Streambed issue and confirm that they have been applied.
[ ] If the app is on the Dash Gallery portal, I have added a link to
the GitHub repository for the source code in the portal description.
[ ] If the app is a reimplementation of a Python gallery app for the
DashR gallery, the app in this PR mimics, as closely as possible,
the style and functionality of the existing app.=
[x] I have removed all Google Analytics code from the app's
assets/ folder.

The pre-review review
I have addressed all of the following questions:

[ ] Does everything in my code serve some purpose? (I have removed
any dead and/or irrelevant code.)
[x] Does everything in my code have a clear purpose? (My code is
readable and, where it isn't, it has been commented appropriately.)]
[ ] Am I reinventing the wheel? (I have used appropriate packages to
lessen the volume of code that needs to be maintained.)

As per https://github.com/plotly/streambed/issues/13854, I am closing this as the new deployment process is in place.
If you need any changes from this branch, please recreate your changes against master and create a new pull request. Let me know if you need help and I am happy to jump in.

authors: josegonzalez milaroisin

repo: plotly/dash-sample-apps


text:
🛑 Dick Pluim.com is down

In 04c9242, Dick Pluim.com (https://dickpluim.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Dick Pluim.com is back up in 9f565ab after 13 minutes.


text:
repo: create labels.yml

This PR adds a labels.yml file to our .github directory which will sync labels from there (though it may not delete old labels, which we may have to do manually). I got these labels from https://github.com/autoparallel/learner

A note for the Pluto gang -- I prefer having labels synced like this. We should consider it on all our repos and template them moving forward :)

Before merging, we should add any of the ronkathon specific labels we already have in here and want to keep.
A good example would be the "bounty" label.

Don't merge yet -- I will merge when ready then.
Let me add some that we have that aren't currently in this yml

repo: pluto/ronkathon


text:
🛑 Google is down

In 56801b2, Google (https://www.google.com) was down:

HTTP code: 429
Response time: 308 ms

Resolved: Google is back up in ef7ac06 after 7 minutes.


text:
Dockerfile not working : ImportError: libcuda.so.1: cannot open shared object file: No such file or directory

Hello, this project looks promising, but I can't get the Dockerfile to yield a successful build.
I run this:
sudo docker build --build-arg CUDA_BASE_VERSION=9.0 --build-arg CUDNN_VERSION=7.6.0.64 --build-arg UBUNTU_VERSION=16.04 --build-arg TENSORFLOW_VERSION=1.12.0 -t dirt .
and I get this during the build process:
ImportError: libcuda.so.1: cannot open shared object file: No such file or directory
I think it's due to an incompatibility between tensorflow version and cuda version, but I've tried various tensorflow versions, with the same result.
Could you communicate the arguments that work with you? You wrote down the driver versions and OS version, but not the tensorflow version
thanks!

This is docker-specific; DIRT should work fine with those versions. @dboyle25-40124186, could you take a look please?

Apologies @francoisruty, I won't be able to properly take a look at this until Monday.
Going by the CUDA compatibility versions here, the tensorflow and CUDA versions you've given should be compatible.
I'm assuming you've got Nvidia-docker installed and have either edited the docker daemon configuration or ran the image with --runtime=nvidia to allow GPU access to the container?

@DomhnallBoyle Hello guys thanks for the quick response, no worry on my side for waiting a few days, thanks for all your work :)
Yes I've installed nvidia-docker, configured docker properly etc (I'm running other tensorflow-gpu containers on the same machine).
I can't use the --runtime=nvidia flag for docker build (this flags for docker runs but not docker build). AFAIK it's not possible to use nvidia-docker for docker builds.
Did one of you managed to make a docker build? If yes I'm interested in the OS + the exact Dockerfile and docker build command, at this time I'm just trying to use docker to get the given samples up and running
(then I'm planning to edit the code to have it work with python 3 and Tensorflow 2.0 alpha, I'll gladly share my edits)

@francoisruty I was able to get this working. My host machine had Ubuntu 18.04 with CUDA 9.0 and I'm pretty sure the commands I used were exactly like yours above using tensorflow 1.12:
sudo docker build -t <image_name> --build-arg CUDA_BASE_VERSION=9.0 --build-arg CUDNN_VERSION=7.6.0.64 --build-arg UBUNTU_VERSION=16.04 --build-arg TENSORFLOW_VERSION=1.12.0  .
Could you just double check if you've added "default-runtime": "nvidia" in /etc/docker/daemon.json and restarted the daemon, I'm pretty sure this allows Nvidia runtime access for docker build.
Apologies if not, let me try this tomorrow and I'll get back to you

Hello, I apologize, I had indeed enabled the nvidia runtime, but I wasn't aware you could set it as the default one, enabling one to have GPU available during docker builds!
I tried your command and it works!
I'll try the samples, and see how it goes with python 3 and tensorflow 2, I'll create other issues or PR if needed!
all the best

Just another comment, it doesn't work with CUDA 10.0 and tensorflow 1.14.0 (those 2 versions are supposed to be compatible), I get:
Installing collected packages: dirt
  Running setup.py install for dirt: started
    Running setup.py install for dirt: finished with status 'error'
    Complete output from command /usr/bin/python -u -c "import setuptools, tokenize;__file__='/tmp/pip-sNYYMd-build/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /tmp/pip-L9TnEM-record/install-record.txt --single-version-externally-managed --compile:
    /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'python_requires'
      warnings.warn(msg)
    running install
    running build
    -- The CXX compiler identification is GNU 5.4.0
    -- The CUDA compiler identification is NVIDIA 10.0.130
    -- Check for working CXX compiler: /usr/bin/c++
    -- Check for working CXX compiler: /usr/bin/c++ -- works
    -- Detecting CXX compiler ABI info
    -- Detecting CXX compiler ABI info - done
    -- Detecting CXX compile features
    -- Detecting CXX compile features - done
    -- Check for working CUDA compiler: /usr/local/cuda/bin/nvcc
    -- Check for working CUDA compiler: /usr/local/cuda/bin/nvcc -- works
    -- Detecting CUDA compiler ABI info
    -- Detecting CUDA compiler ABI info - done
    CMake Warning (dev) at /usr/local/share/cmake-3.14/Modules/FindOpenGL.cmake:275 (message):
      Policy CMP0072 is not set: FindOpenGL prefers GLVND by default when
      available.  Run "cmake --help-policy CMP0072" for policy details.  Use the
      cmake_policy command to set the policy and suppress this warning.

      FindOpenGL found both a legacy GL library:

        OPENGL_gl_LIBRARY: /usr/local/lib/x86_64-linux-gnu/libGL.so

      and GLVND libraries for OpenGL and GLX:

        OPENGL_opengl_LIBRARY: /usr/local/lib/x86_64-linux-gnu/libOpenGL.so
        OPENGL_glx_LIBRARY: /usr/local/lib/x86_64-linux-gnu/libGLX.so

      OpenGL_GL_PREFERENCE has not been set to "GLVND" or "LEGACY", so for
      compatibility with CMake 3.10 and below the legacy GL library will be used.
    Call Stack (most recent call first):
      CMakeLists.txt:5 (find_package)
    This warning is for project developers.  Use -Wno-dev to suppress it.

    -- Found OpenGL: /usr/local/lib/x86_64-linux-gnu/libOpenGL.so
    CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
    Please set them or make sure they are set and tested correctly in the CMake files:
    Tensorflow_LIBRARY
        linked by target "rasterise" in directory /tmp/pip-sNYYMd-build/csrc

    -- Configuring incomplete, errors occurred!
    See also "/tmp/pip-sNYYMd-build/build/CMakeFiles/CMakeOutput.log".
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/tmp/pip-sNYYMd-build/setup.py", line 50, in <module>
        'Programming Language :: Python :: 3.7',
      File "/usr/lib/python2.7/distutils/core.py", line 151, in setup
        dist.run_commands()
      File "/usr/lib/python2.7/distutils/dist.py", line 953, in run_commands
        self.run_command(cmd)
      File "/usr/lib/python2.7/distutils/dist.py", line 972, in run_command
        cmd_obj.run()
      File "/usr/lib/python2.7/dist-packages/setuptools/command/install.py", line 61, in run
        return orig.install.run(self)
      File "/usr/lib/python2.7/distutils/command/install.py", line 601, in run
        self.run_command('build')
      File "/usr/lib/python2.7/distutils/cmd.py", line 326, in run_command
        self.distribution.run_command(command)
      File "/usr/lib/python2.7/distutils/dist.py", line 972, in run_command
        cmd_obj.run()
      File "/tmp/pip-sNYYMd-build/setup.py", line 24, in run
        build_csrc()
      File "/tmp/pip-sNYYMd-build/setup.py", line 18, in build_csrc
        subprocess.check_call(['cmake', os.path.join(base_path, 'csrc')], cwd=build_path)
      File "/usr/lib/python2.7/subprocess.py", line 541, in check_call
        raise CalledProcessError(retcode, cmd)
    subprocess.CalledProcessError: Command '['cmake', '/tmp/pip-sNYYMd-build/csrc']' returned non-zero exit status 1

That new error is due to a change made in tf 1.14; I've created #32 to track it and will fix soon.

awesome, many thanks!

@francoisruty  Support for tf 1.14 is now fixed; please open another ticket if there are further problems.

awesome!

I bumped into the same error when running a project requiring tensorflow-gpu 1.1.0 on an Azure 16.04 LTS Virtual Machine. The CUDA drivers displayed were shown to be N/A in nvidia-smi.
I solved it by running the following command and installing the nvcc toolkit:
sudo apt-get install nvidia-cuda-toolkit
Afterwards, in nvidia-smi, the CUDA drivers appeared to be the 10.1 version and my program successfully ran, with no error displayed.

authors: DanyEle DomhnallBoyle francoisruty pmh47


text:
Fix eslint configuration

Fix prettier's plugin error & add some more paths to check.

Thanks! LGTM

authors: Gusted TimvanScherpenzeel

repo: pmndrs/detect-gpu


text:
Remove 'Editing' Worry From 'Custom Charts' - view-samples/custom-charts

Very tiny suggestion, and you can close this off as soon as it is seen, I'm sure ... but could the concern about data integrity for custom charts and their inherent 'editability' be waylaid by sending a PATCH request with the following settings to make it read only?
URI:
https://YOUR_DOMAIN.sharepoint.com/_api/web/lists/GetById(guid'YOUR_LIST_ID')/Views/GetById(guid'YOUR_LIST_VIEW_ID')

Method:
PATCH

Header:
{
    "Content-Type": "application/json;odata=nometadata",
    "Accept": "application/json;odata=nometadata"
}

Body:
{
  "ReadOnlyView": true
}

( I performed my tests in Power Automate, hence the generous header setup allowing minimal fuss )

Obviously I could be way off, maybe you need the 'edit' ability in order for them to work ... but it's just a thought.

@'ing @Fedes365 as it's their amazing looking view sample

Hello @influential-eliot
Thanks for your very interesting contribution! I will take it into consideration for sure and will perform a test with Power Automate.
You can find me in LinkedIn too, so we can keep in touch.
Thanks again and see you soon!

repo: pnp/List-Formatting


text:
Enhancement: Extend aad o365group add with options to set resourceBehaviorOptions

resourceBehaviorOptions can be set only at creation time of an Microsoft 365 Group however currently we do not provide the ability to set them, therefore only the default behaviours are set. We should provide the ability to set these options to our own preference if they are provided.
Options

Option
Description

--allowMembersToPost [allowMembersToPost]
Set to true if only group members can post conversations to the group and false to allow any user in the organisation to post conversations to the group (default)

--hideGroupInOutlook [hideGroupInOutlook]
Set to true to hide the group in Outlook experiences and false to make the group visible and discoverable in Outlook experiences (default)

--subscribeNewGroupMembers [subscribeNewGroupMembers]
Set to true to subscribe all new group members to receive group conversation emails when new messages are posted in the group and false to not subscribe members to receive group conversation emails (default)

--welcomeEmailDisabled [welcomeEmailDisabled]
Set to true to not send welcome emails to new group members and false to send welcome emails when a new member joins the group (default)

Resources
resourceBehaviorOptions is a string collection that specifies group behaviors for a Microsoft 365 group. These behaviors can be set only on group creation (POST).

Set Microsoft 365 group behaviors and provisioning options https://docs.microsoft.com/en-us/graph/group-set-options
Create group https://docs.microsoft.com/en-us/graph/api/group-post-groups?view=graph-rest-1.0&tabs=http

Hi,
Can I work on this?

All yours @nanddeepn 👍🏻
Thank you for your help ❤

@garrytrinder great suggestion! Looking at the options, could they be flags? If we'd consider the value being not specified the default, which is the behavior we have now, and then specifying the value as true, wouldn't that be enough? What's the added value of specifying false in any of these options while creating the group and where false is already the default? I agree that it would be different in a set command where you might want to change a true value to false, but not in add, right?

I've submitted a similar request for the PnP PowerShell module, will this be supported as well?

I've submitted a similar request for the PnP PowerShell module, will this be supported as well?

Thanks for reaching out @EMaarten unfortunately I can't speak for the PnP PowerShell team, so I would suggest reaching out to that team for guidance.

Good observation @waldekmastykarz, I agree that these new options could be flags and your points, however the reason I chose true and false was based on aligning with the existing --isPrivate option and so it was consistent with other options that you may use on this command, see example below.

That's a good point. Would it be then the right thing to do to change --isPrivate into a flag to better express its intent? We could include it as part #2696 if it needs changing as it would be a breaking change.

Would it be then the right thing to do to change --isPrivate into a flag to better express its intent? We could include it as part #2696 if it needs changing as it would be a breaking change.

It is definitely the right thing to do, lets get it added to #2696 and I'll update the spec for this issue.

Thank you @garrytrinder
Just to confirm, --isPrivate will continue to be an option instead of flag (at least as of now for this issue)?

Correct @nanddeepn. We keep isPrivate as-is for now.

authors: EMaarten garrytrinder nanddeepn waldekmastykarz