Before step for plugins

See discussion on #1441.
If a plugin could determine when drone moves on to the build step or does not, all kinds of security/access control features could easily be introduced while keeping Drone's core small.
This kind of plugin would have to run before any other step, have access to all kinds of information (who created the commit, what changes are included, has .drone.yml changed, etc.) and have the ability to choose which stages of the drone pipeline to execute.
Some common use cases would be to restrict builds to only certain users or users in a single github org, but these conditions and actions should be arbitrary to allow for greater flexibility.

This would even allow for a strictly smaller amount of code in the drone core, as the functionality involved in monitoring the checksum of .drone.yml with drone.sec could be exported into a plugin, as could the configuration of not building PRs on public repos. (In fact, these might be the best first example plugins to show off this functionality).

I'm thinking the easiest way to integrate this sort of change would be to have some sort of before section to the yaml that runs a set of plugins before the build starts:
before:
  check_trusted:
    when:
      event: pull_request

I'm not sure what an example plugin would look like, but it might be nice to kick around some ideas for a real-world "trusted author" plugin (related to security and trusted users) so that we can make sure the above approach works and there aren't any gaps.

We are starting to accumulate a healthy pile of sections, though. I wonder if there gets to be a point where we just figure out how to execute an arbitrary list of plugins in a certain order, or define dependencies and do away with the sections.

This would even allow for a strictly smaller amount of code in the drone core, as the functionality involved in monitoring the checksum of .drone.yml with drone.sec could be exported into a plugin

@siddharthist the idea of moving the .drone.sec file to a plugin is appealing indeed. The only catch is that the .drone.sec file is parsed before the yaml is parsed, and the contents are injected into the yaml using simple string find / replace.
That being said, the .drone.sec contents could be unpacked and dumped to files that could be read by the other steps in the workflow, instead of using string interpolation in the yaml. I think this is something we need to explore further. Any ideas for improving the .drone.sec should probably be consolidated to https://github.com/drone/drone/issues/1250

We are starting to accumulate a healthy pile of sections, though. I wonder if there gets to be a point where we just figure out how to execute an arbitrary list of plugins in a certain order, or define dependencies and do away with the sections.

YES I completely agree and this is something that needs to be addressed after the 0.5 release (pull queue implementation) in the 0.6 release. In fact, I think these are the last major change required before we can move from beta to release candidate.

@bradrydzewski What changes would be necessary to drone to make this feasible? Could you perhaps provide an outline/plan for implementation? I'd be happy to help, but I don't know where to start...

I still think this is going to make the YAML parsing nuts. @bradrydzewski I know we talked about this but I can't seem to find an associated issue so my suggestion is that Drone supports a imperative path as well as the current declarative path. This is similar to a grunt/gulp scenario from the Node world.
So as an example what if I had.
var environment = drone.getEnvironment();

var pipeline = new Pipeline();
pipeline.add(new BuildStep('unit tests', 'sh unit_tests.sh'));

if (environment.branch == 'release') {
  pipeline.add(new BuildStep('functional tests', 'sh functional_tests.sh');
}

var result = pipeline.run();

if (result == drone.SUCCESS) {
  var publishNpm = new PublishNpm(environment.NPM_REGISTRY, ...);

  if (publishNpm.run() == drone.SUCCESS) {
    var notify = new NotifySlack(environment.SLACK_TOKEN, ...);

    notify.run();
  }
}

@donny-dont I completely agree.
It has become apparent that the current yaml has some flaws that need to be addressed and I don't want to release and freeze a 1.0 until they are resolved. I think this will take time to prototype and see what works and what doesn't.
I think we need to give @siddharthist some options to integrate this new class of plugin today, without having to wait for a yaml or build configuration re-design. So even though I cringe at the idea of introducing a new section, which I actively want to remove, it might be the best way to move forward until we have a new design.
Speaking of new yaml design with scripting options, I think we need to come up with an RFC for these changes. One thing I want to avoid is getting 100 different opinions on minor variations of yaml formats. We need to approach this with a set of goals that any proposed format would need to meet.
I've been intrigued by some ideas presented by @cusspvz in https://github.com/drone/drone/issues/1356#issuecomment-170650041 that treated the build as a single set of steps. I started playing around with some variations such as the following:
pipeline:
  clone:
    plugin: git

  cache:
    plugin: cache
    mount: [ node_modules ]

  mysql:
    image: mysql
    detach: true

  postgres:
    image: mysql
    detach: true

  build:
    image: golang
    commands:
      - go build
      - go get

  deploy:
    plugin: heroku
    app: foo
    token: $$HEROKU_TOKEN
    when:
      event: [ push, tag ]
      branch: master

catch:
  rollback:
    plugin: heroku_rollback
    token: $$HEROKU_TOKEN
    app: foo

finally:
  notify:
    plugin: slack
    token: $$SLACK_TOKEN

I like that it declares the pipeline. I'm just thinking things are going to get weird when you start throwing in when statements everywhere.

@donny-dont I think perhaps this is where a JS / scriptable option would be beneficial. Tools like gradle and gulp have show programming languages can work very well for build configuration.

Lua would be really sweet for this, but that's coming from a JS hater.

I think there's a Golang JavaScript interpreter so easy to roll that in

Appears theres a Lua implementation https://github.com/Shopify/go-lua as well as a JavaScript one https://github.com/robertkrimen/otto.

Hey all, it might be useful to make another issue for tracking ideas for improving the YAML spec. Seems like a lot of good ideas floating around!

Here's my outline of what needs to happen to add a homogenous plugin-based before step. Could somebody please review and let me know what's missing? Then I can get to work on implementing it.
Changes:
 1. Add another step to [Config][Config], which is `Before PluginSlice`
 2. Add another Node type, [`NodeBefore`][NodeBefore] that is created with
 `newPluginNode`.
 3. Add another rule to [Load][Load], specifically "Before." that looks a lot
 like "Plugin.", except is attached to `conf.Before.Slice()` and has type
 `NodeBefore`.

Tests:
 1. Add another test case with a "Before" clause to [parse\_test.go][parse_test]

[Config]: https://github.com/drone/drone-exec/blob/7dc4524fc4c8115d1dcc6cc5027f75606a3069ea/yaml/types.go#L5
[NodeBefore]: https://github.com/drone/drone-exec/blob/7dc4524fc4c8115d1dcc6cc5027f75606a3069ea/parser/node.go#L25
[Load]: https://github.com/drone/drone-exec/blob/7dc4524fc4c8115d1dcc6cc5027f75606a3069ea/parser/parse.go#L35

[parse_test]: https://github.com/drone/drone-exec/blob/7dc4524fc4c8115d1dcc6cc5027f75606a3069ea/yaml/parse_test.go

Wouldn't be significantly better to add a catch plugin that would catch errors from the latest stage?
The example I've provided on https://github.com/drone/drone/issues/1356#issuecomment-170650041 has already piping control, just because stages are processed on series and jobs on parallel.
I also don't think you need to include jobs into a key, such as parallel or jobs. If we set a list of names users can't use on jobs, such as: stages, image and some others; you can gather everything as jobs (plugins would be plugged on each job, script runner would be a plugin as well).

I think we need to come up with an RFC for these changes

I agree.

Wouldn't be significantly better to add a catch plugin that would catch errors from the latest stage?

I'm not sure how this would work. This isn't really what plugins are used for. Have you really dug into the Drone plugin model and build runner? I ask because I respect your ideas (I put a lot of thought into your comment) but to move forward with an RFC Yaml improvements it will require a deep understanding of how the build runner and plugins work, and how Drone orchestrates containers.

I've just made a new issue for the purposes of discussing a new config format :)

@siddharthist your outline is pretty spot on. The only thing I would include is that we have a bunch of rules to transform the yaml before execution, setting default values, etc.
https://github.com/drone/drone-exec/blob/master/parser/funcs.go

@bradrydzewski Thanks for the review! Do you think that those would have to be altered to make this change?

@siddharthist I looked through the codebase quickly and don't think any rules will need to be adjusted. I can do a deeper review once we have a PR

I'm not sure how this would work. Plugins are isolated Docker containers that run a task and return an exit code so handling orchestration is out of their scope / capability

Major problem I can see on current implementation is that stages are already pre-defined and all the code base relias on that definition, implementation of catchers with current Drone's logic would have to be written on the same way as well. I really would like to help you on that but unfortunately, inspite I can read and understand Go I cannot write awesomeness as I do with Javascript.

Have you had a chance to really dig into the Drone plugin model and build runner?

Yes I did, in fact, I had took almost an hour reading the logic of the most important repos (such as cli, job's logic and so on).

I hope this doesn't come off as negative (not my intention). I think you have good ideas and I want you to really understand the guts of Drone and how it works, and how it is different than GitLab, since I think it will really help us come up with a better proposal

Don't worry with that, I like to keep things positive and to understand others opinions. :) You already said this sort of major changes won't be able to be released until 2.0, and I completely understand your point on keeping things stable until 1.0 and yet your concern to enhance current yaml design.
Maybe we can have two separate discussion spots for describing RFC yaml drafts for 0.x -> 1.0 and 2.0 versions.

@bradrydzewski PR is in :smile:

closing since this is now possible with the current pipeline. For more strict gating this issue is now superseded by https://github.com/drone/drone/issues/1971


findTreeItem fails for an app resource child contributed by a yet-to-be-activated extension

Databases will persist the connected database for each workspace. On activation, if the workspace has a connected database saved it does findTreeItem to get the tree item and then connects to it.
This specific use case of findTreeItem fails fairly consistently. Since the tree item we're looking for is a child of an application resource, when findTreeItem is executed, its success depends on if the tree has updated to use the newly registered Databases branch data provider to get the tree items (rather than the DefaultApplicationResourceBranchDataProvider). Since if the tree still has the tree items given by DefaultApplicationResourceBranchDataProvider, they won't have children.
Not sure what the best solution is to this. Should we have mechanisms in RGs to solve this? This could be a common scenario, basically anytime you try to do findTreeItem for a tree item that is contributed by a yet-to-be-activated extension.
Note: this repros about half the time for me. Depends on how fast the extension activates and the tree refreshes I guess.

Doesn't the tree item have to be resolved before we can invoke findTreeItem on it? Maybe we can check the azExtResourceType property on the tree item and make sure the appropriate extension is activated before we look at which resolver to use?

Doesn't the tree item have to be resolved before we can invoke findTreeItem on it?

findTreeItem takes a tree item id, so you can call it whenever/however you want - even if the items haven't been resolved yet.

EDIT: I'm not entirely what the new implementation of findTreeItem is, but I assume it still has to travel down the tree (eventually hitting AppResourceTreeItem). If that's not the case, this wouldn't work whatsoever.

Correct, however we need this functionality for at least a few features I know of, and probably a lot more that I haven't thought of.
Calling findTreeItem to reveal a tree item that hasn't yet been displayed is pretty common. And with how the unified view works by lazy activating extensions, this scenario is probably pretty common.
I think one solution is if an extension contributes a BDP, to not show shallow tree items for those resources. Instead, just wait for the extension to activate and show the resolved tree items. I don't really like how it behaves anyway.
Video of what I'm talking about:
https://user-images.githubusercontent.com/12476526/199114378-245102a4-2483-4579-ae25-37f6926df20c.mov

Note: this only reproduces for Databases if the extension hasn't activated when user expands the group tree item.

We really need to reconsider features that require one extension to access another's tree nodes. That's a bad design and now's the time to revisit it.


feat: add version check based on -subscriptionUrl

Summary

Enhanced Add-ContentLibrary cmdlet to check the VMware Cloud Foundation version when adding a subscribed content library. If the version is 5.0.0 or later and the -subscriptionUrl parameter is set to wp-content.vmware.com, a warning message is displayed and the cmdlet exits.
Updated CHANGELOG.md.
Updated module version to <IP_ADDRESS>2

Type

[ ] Bugfix
[x] Enhancement or Feature
[ ] Code Style or Formatting
[ ] Documentation
[ ] Refactoring
[ ] Chore
[ ] Other
Please describe:

Breaking Changes?

[ ] Yes, there are breaking changes.
[x] No, there are no breaking changes.

Test and Documentation

[x] Tests have been completed.
[ ] Documentation has been added or updated.

Issue References

Closes #318
Additional Information

LGMT!

Rebased!


ARROW-11586: [Rust][Datafusion] Remove force unwrap

Fix for https://issues.apache.org/jira/browse/ARROW-11586

Codecov Report

Merging #9479 (ed800b7) into master (5e3fcfa) will decrease coverage by 0.01%.
The diff coverage is 88.57%.

@@            Coverage Diff             @@
##           master    #9479      +/-   ##
==========================================
- Coverage   82.32%   82.31%   -0.02%
==========================================
  Files         233      234       +1
  Lines       54446    54461      +15
==========================================
+ Hits        44823    44828       +5
- Misses       9623     9633      +10

Impacted Files
Coverage Δ

rust/arrow/src/array/builder.rs
84.93% <ø> (ø)

rust/arrow/src/compute/kernels/sort.rs
93.56% <ø> (ø)

rust/arrow/src/compute/kernels/substring.rs
98.29% <ø> (ø)

rust/arrow/src/compute/util.rs
98.92% <ø> (ø)

rust/arrow/src/json/reader.rs
82.82% <ø> (ø)

rust/benchmarks/src/bin/tpch.rs
38.33% <0.00%> (+0.18%)
:arrow_up:

rust/datafusion/src/datasource/memory.rs
80.00% <ø> (ø)

rust/datafusion/src/logical_plan/dfschema.rs
85.52% <ø> (ø)

...tafusion/src/physical_plan/datetime_expressions.rs
93.28% <ø> (+0.24%)
:arrow_up:

...atafusion/src/physical_plan/expressions/in_list.rs
75.37% <ø> (ø)

... and 41 more

Continue to review full report at Codecov.

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

I've un-drafted it.

Thanks @marcprux


Remove crypto dependencies from js-threads components required by client: threadsid + multiaddr

See also #55


Inconsistent redirect behavior

When using a "native" HTTP PUT request (eg using CURL) I will be redirected to the main page (/) with a PUT request, while if using a HTTP POST request with a "_method=put" parameter (which is resolved as a PUT request within the Laravel framework) I'm redirected with a GET request, which in my opinion should be the behavior also with a "native" request. I'm using the Laravel Framework Version 5.2.35.
routes.php
    // request target
    $router->put('check', function (\Illuminate\Http\Request $request) {
        return redirect('/');
    });

    // redirect targets
    $router->get('/', function (\Illuminate\Http\Request $request) {
        echo 'GET redirect';
    });

    $router->post('/', function (\Illuminate\Http\Request $request) {
        echo 'POST redirect';
    });

    $router->put('/', function (\Illuminate\Http\Request $request) {
        echo 'PUT redirect';
    });

requests
// Curl POST request
 curl -L  --data "_method=PUT" http://mydomain/check
// GET redirect

// another Curl POST request
 curl -L -X POST --data "_method=PUT" http://mydomain/check
// POST redirect

// Curl PUT request
curl -L -X PUT http://mydomain/check
// PUT redirect

Addition:
Checking the incoming curl requests with
$request->method();
shows that all are resolved as PUT requests, but the redirect differs for every request.

I believe _method is only read as a pseudo request if it is sent in a post request.
See the docs here: https://laravel.com/docs/5.2/routing#form-method-spoofing

Thanks for your remark. I have checked this and it is like you said, the "_method" parameter seems only to be resolved for POST requests. I have updated my question regarding to this. But now Laravels behavior looks even more Inconsistent to me than before. One POST request is redirected with POST and the other with GET.

Have you tried it without the post request and just the put request? Does laravel read the post with _method=put and trigger the put route?

All three requests trigger the PUT route (/), but then they are redirected to different routes.
When checking the used method with
$request->method();
all three are resolved as PUT requests.

Hmmm, Mite be better to hear something from @GrahamCampbell or @taylorotwell see if this is intended behaviour or not

The method spoofing with _method is only enabled for http posts since it's a workaround for browser forms only supporting get and post. A client able to send put/delete requests directly has no need for it.
The docs for curl 7.43.0 states...

-L, --location
(HTTP/HTTPS) If the server reports that the requested page has moved to a different location (indicated with  a  Location:  header and a 3XX response code), this option will make curl redo the request on the new place. If used together with -i, --include or -I, --head, headers from all requested pages will be shown. When authentication is used, curl only sends its credentials to  the  initial  host.  If  a  redirect takes curl to a different host, it won't be able to intercept the user+password. See also --location-trusted on how to change this. You can limit the amount of redirects to follow by using the --max-redirs option.
When curl follows a redirect and the request is not a plain GET (for example POST or PUT), it will do the following request with a GET  if  the  HTTP  response  was  301,  302, or 303. If the response code was any other 3xx code, curl will re-send the following request using the same unmodified method.
[...]

-X, --request
(HTTP)  Specifies  a  custom  request method to use when communicating with the HTTP server.  The specified request method will be used instead of the method otherwise used (which defaults to GET). Read the HTTP 1.1 specification for details  and  explanations. Common additional HTTP requests include PUT and DELETE, but related technologies like WebDAV offers PROPFIND, COPY, MOVE and more.
Normally you don't need this option. All sorts of GET, HEAD, POST and PUT requests are rather invoked by using  dedicated  command line options.
This  option  only changes the actual word used in the HTTP request, it does not alter the way curl behaves. So for example if you want to make a proper HEAD request, using -X HEAD will not suffice. You need to use the -I, --head option.
The method string you set with -X will be used for all requests, which if you for example use -L, --location may cause  unintended side-effects when curl doesn't change request method according to the HTTP 30x response codes - and similar.
[...]

`curl -L --data="_method="PUT"``
Issues a POST (since you've sending data), Laravel sees a PUT, and curl uses a GET for redirection.

curl -L -X POST --data "_method=PUT"
Same as above, but you force the redirection to use POST.

curl -L -X PUT
Issues a PUT, and forces a PUT for redirection.

Basically, you're telling curl which http method to use for the redirect with -X, and not just the initial request. This isn't a Laravel issue, but just the way you tell curl to behave.

Thanks for your great answer. This totally makes sense. I haven't found any differences at Laravels redirect responses, because there weren't any. I was absolutely mislead, because the HTTP client (HttpRequester) I used before had the same behavior (maybe it uses curl under the hood). With this new knowledge I have checked more HTTP clients and some (for example Postman) are following the redirect (as expected by me) with a GET method. My conclusion is to be very careful with redirects within an API/Webservice context. Laravel is behaving correct. Therefore this issue can be closed.


Request: feature for other way arround, maximized = show and desktop = hide

Hey ChanpleCai,
This application looks great, but im just looking for a way to have it the other way around
I love to make my desktop as clean as possible and if you would make this feature my desktop would look super clean.
I would love it if you would make it so:
Maximized Windows = Taskbar shows and it doesnt auto hide
Desktop Visible = Taskbar hidden and auto hide is enabled
As I said I would like it reversed 😁
Thanks!
BlackBearFTW

I will add full custom features in future versions.

So I didn’t see any update or I didn’t hear anything about a upcoming update? When are you going to add this feature

okay so its been a while! did you have any time to add this feature yet?

still waiting.................. 😥

I also wanted a feature like this, any update yet @ChanpleCai ?

Same thing here. I want the reverse auto feature. I've googled it anywhere but I couldn't find any application that worked like this. Hope you can do it.

Sorry, I forgot this.

Bumping this up in case you forgot it again LOL also if you can make it always show but still behave like in auto hide so it can go well with a semi/transparent taskbar in a maximized window anyways hope you can work on it soon and thanks.


Actually pass through the env vars to the Haskell installer

Fixes the env vars not being passed to the sudo command as detailed in https://github.com/devcontainers-contrib/features/pull/94#issuecomment-1330004657
@DaneWeber Is this commit/fix what you had in mind?
This PR will...

Add the following vars to the sudo context:

export BOOTSTRAP_HASKELL_NONINTERACTIVE='$BOOTSTRAP_HASKELL_NONINTERACTIVE'
export GHCUP_USE_XDG_DIRS='$GHCUP_USE_XDG_DIRS'
export BOOTSTRAP_HASKELL_GHC_VERSION='$BOOTSTRAP_HASKELL_GHC_VERSION'
export BOOTSTRAP_HASKELL_CABAL_VERSION='$BOOTSTRAP_HASKELL_CABAL_VERSION'
export BOOTSTRAP_HASKELL_DOWNLOADER='$BOOTSTRAP_HASKELL_DOWNLOADER'
export BOOTSTRAP_HASKELL_INSTALL_NO_STACK='$BOOTSTRAP_HASKELL_INSTALL_NO_STACK'
export BOOTSTRAP_HASKELL_ADJUST_BASHRC='$BOOTSTRAP_HASKELL_ADJUST_BASHRC'
export BOOTSTRAP_HASKELL_INSTALL_NO_STACK_HOOK='$BOOTSTRAP_HASKELL_INSTALL_NO_STACK_HOOK'

This should be thoroughly checked before being merged to avoid things like #136 and others.

I just saw this notification. I'll test it out locally in a minute.

Something is weird about the install. GHCI, Cabal, and Stack are getting installed and are accessible, but they aren't being managed by GHCup:
vscode ➜ /workspaces/haskell_example $ ghcup list -c installed
   Tool  Version  Tags               Notes
✔✔ ghcup <IP_ADDRESS> latest,recommended
vscode ➜ /workspaces/haskell_example $ ghc --version
The Glorious Glasgow Haskell Compilation System, version 9.2.4
vscode ➜ /workspaces/haskell_example $ cabal --version
cabal-install version <IP_ADDRESS>
compiled using version <IP_ADDRESS> of the Cabal library
vscode ➜ /workspaces/haskell_example $ stack --version
Version 2.9.1, Git revision 409d56031b4240221d656db09b2ba476fe6bb5b1 x86_64 hpack-0.35.0

If I run the following as a non-root user in the same base image but without the Feature installed, I get the following behavior:
Setup commands:
sudo apt-get update -y
sudo apt-get -y install --no-install-recommends curl build-essential libffi-dev libffi8ubuntu1 libgmp-dev libgmp10 libncurses-dev libncurses5 libtinfo5
export BOOTSTRAP_HASKELL_NONINTERACTIVE=1
export GHCUP_USE_XDG_DIRS=1
export BOOTSTRAP_HASKELL_GHC_VERSION=9.2.4
export BOOTSTRAP_HASKELL_CABAL_VERSION=<IP_ADDRESS>
export BOOTSTRAP_HASKELL_DOWNLOADER=curl
export BOOTSTRAP_HASKELL_INSTALL_NO_STACK=
export BOOTSTRAP_HASKELL_ADJUST_BASHRC=true
export BOOTSTRAP_HASKELL_INSTALL_NO_STACK_HOOK=
curl --proto '=https' --tlsv1.2 -sSf https://get-ghcup.haskell.org | sh

Results:
vscode ➜ ~/.cache/ghcup/logs $ ghcup list -c installed
[ Warn  ] New ghc version available. To upgrade, run 'ghcup install ghc 9.4.3'
   Tool  Version  Tags               Notes
✔✔ ghc   9.2.4    base-<IP_ADDRESS>
✔✔ cabal <IP_ADDRESS>  latest
✔✔ stack 2.9.1    latest,recommended
✔✔ ghcup <IP_ADDRESS> latest,recommended
vscode ➜ ~/.cache/ghcup/logs $ ghc --version
The Glorious Glasgow Haskell Compilation System, version 9.2.4
vscode ➜ ~/.cache/ghcup/logs $ cabal --version
cabal-install version <IP_ADDRESS>
compiled using version <IP_ADDRESS> of the Cabal library
vscode ➜ ~/.cache/ghcup/logs $ stack --version
Version 2.9.1, Git revision 409d56031b4240221d656db09b2ba476fe6bb5b1 x86_64 hpack-0.35.0

I'm going to dig a little more, but it seems like something is getting a little messed up with the sudo install.

@DaneWeber I actually have no idea why it's different. 🤷♂ Maybe we should ask the official source? https://github.com/haskell/ghcup-hs
Btw thanks for testing this! ♥ Good thing you did too! 😅
Your quick and easy $HOME bodge is looking better and better, but this way's more fun. 😉

That likely means that the shell you are testing this in doesn't have export GHCUP_USE_XDG_DIRS=1 set and so ghcup looks at ~/.ghcup.

That likely means that the shell you are testing this in doesn't have export GHCUP_USE_XDG_DIRS=1 set and so ghcup looks at ~/.ghcup.

@hasufell I don't know 🤔. It seems like it should be set to 1 since...
https://github.com/jcbhmr/devcontainers-contrib-features/blob/patch-1/src/haskell/install.sh#L32
export GHCUP_USE_XDG_DIRS=1

https://github.com/jcbhmr/devcontainers-contrib-features/blob/patch-1/src/haskell/install.sh#L57
export GHCUP_USE_XDG_DIRS='$GHCUP_USE_XDG_DIRS'
# This is inside the sudo <<EOF heredoc, thus the $GHCUP_USE_XDG_DIRS *should* be replaced with '1'
# before it gets passed to the bash interpreter, so the bash interpreter sees:
export GHCUP_USE_XDG_DIRS='1'
# ...Right?

But then again, I don't really know 🤷♂

That likely means that the shell you are testing this in doesn't have export GHCUP_USE_XDG_DIRS=1 set and so ghcup looks at ~/.ghcup.

Ahh. As in, the install is actually working fine, but when I open the terminal as the nonroot user, GHCUP_USE_XDG_DIRS is not set at that point. Checking...

That's it! Thanks, @hasufell! 🎉
Test results:
vscode ➜ /workspaces/haskell_example $ ghcup list -c installed
[ Info  ] downloading: https://raw.githubusercontent.com/haskell/ghcup-metadata/master/ghcup-0.0.7.yaml as file /home/vscode/.ghcup/cache/ghcup-0.0.7.yaml
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
   Tool  Version  Tags               Notes
✔✔ ghcup <IP_ADDRESS> latest,recommended
vscode ➜ /workspaces/haskell_example $ /usr/bin/env | grep GHCUP
vscode ➜ /workspaces/haskell_example $ export GHCUP_USE_XDG_DIRS=1
vscode ➜ /workspaces/haskell_example $ /usr/bin/env | grep GHCUP
GHCUP_USE_XDG_DIRS=1
vscode ➜ /workspaces/haskell_example $ ghcup list -c installed
[ Info  ] downloading: https://raw.githubusercontent.com/haskell/ghcup-metadata/master/ghcup-0.0.7.yaml as file /home/vscode/.cache/ghcup/ghcup-0.0.7.yaml
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
[ Warn  ] New ghc version available. To upgrade, run 'ghcup install ghc 9.4.3'
   Tool  Version  Tags               Notes
✔✔ ghc   9.2.4    base-<IP_ADDRESS>
✔✔ cabal <IP_ADDRESS>  latest
✔✔ stack 2.9.1    latest,recommended
✔✔ ghcup <IP_ADDRESS> latest,recommended

Now we just need to add that env var to the _REMOTE_USER's sessions.

🎉 Nice job @hasufell and @DaneWeber!


Gif image markNeedsLayout every frame.

Steps to reproduce

Use Image load gif with only width or height.

When frame update with set image(ui.Image? value) in RenderImage, markNeedsLayout is called if missing one of width or height(or both).
If last _frame and current frame has same size, relayout is redundant.
We have to handle gif image so carefully in case a huge tree would be relayout.
Code: https://github.com/flutter/flutter/blob/e9de4484209472079d3db1cc0dfd1fcf54570b65/packages/flutter/lib/src/rendering/image.dart#L99
Code sample
Code sample
import 'dart:math';

import 'package:flutter/material.dart';

void main() {
  runApp(MaterialApp(home: MyApp()));
}

class MyApp extends StatefulWidget {
  @override
  _MyAppState createState() => _MyAppState();
}

class _MyAppState extends State<MyApp> {

  var testKey = UniqueKey();
  var num = 0;

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: const Text('example app'),
      ),
      body: Column(
        mainAxisAlignment: MainAxisAlignment.center,
        children: [
          Row(
            mainAxisAlignment: MainAxisAlignment.center,
            children: [
              RepaintBoundary(
                child: Image.network(
                  'https://img.zcool.cn/community/01584659ccc891a801218e18e4097e.gif',
                  width: 200,
                  // height: 200, // only supply width or height
                ),
              ),
              CustomPaint(
                painter: MyPainter(),
                size: Size(50, 50),
              ),
            ],
          ),
          CustomPaint(
            painter: MyPainter(),
            size: Size(50, 50),
          ),
        ],
      ),
    );
  }
}

class MyPainter extends CustomPainter {

  final Paint _paint = Paint();

  @override
  void paint(Canvas canvas, Size size) {
    var randomColor = Colors.primaries[Random().nextInt(Colors.primaries.length)];
    _paint.color = randomColor;
    canvas.drawCircle(Offset(size.width / 2, size.height / 2), size.width / 2, _paint);
  }

  @override
  bool shouldRepaint(covariant CustomPainter oldDelegate) {
    return false;
  }
}

Performance profiling on master channel

[X] The issue still persists on the master channel

Timeline Traces
Timeline Traces JSON
{
}

Video demonstration

Video demonstration

What target platforms are you seeing this bug on?
Android, iOS
OS/Browser name and version | Device information
Any
Does the problem occur on emulator/simulator as well as on physical devices?
Yes
Is the problem only reproducible with Impeller?
No
Logs
Logs
empty

Flutter Doctor output
Doctor output
┌─────────────────────────────────────────────────────────┐
│ A new version of Flutter is available!                  │
│                                                         │
│ To update to the latest version, run "flutter upgrade". │
└─────────────────────────────────────────────────────────┘
[✓] Flutter (Channel stable, 3.7.7, on macOS 14.0 23A344 darwin-arm64, locale zh-Hans-US)
    • Flutter version 3.7.7 on channel stable at /Users/seven/ws/sdk/fvm/3.7.7
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 2ad6cd72c0 (9 months ago), 2023-03-08 09:41:59 -0800
    • Engine revision 1837b5be5f
    • Dart version 2.19.4
    • DevTools version 2.20.1
    • Pub download mirror https://pub.flutter-io.cn
    • Flutter download mirror https://storage.flutter-io.cn

⣽sevenn LocalProcessManager run: pod --version, in null, env={LANG: en_US.UTF-8}
[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.0)
    • Android SDK at /Users/seven/Library/Android/sdk
    • Platform android-33, build-tools 33.0.0
    • ANDROID_SDK_ROOT = /Users/seven/Library/Android/sdk
    • Java binary at: /Applications/Android Studio 2.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.15+0-b2043.56-8887301)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 15.0.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 15A507
    • CocoaPods version 1.11.2

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2022.1)
    • Android Studio at /Applications/Android Studio 2.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.15+0-b2043.56-8887301)

[✓] IntelliJ IDEA Community Edition (version 2022.1.3)
    • IntelliJ at /Applications/IntelliJ IDEA CE.app
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart

[✓] VS Code (version 1.84.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.76.0

⡿sevenn LocalProcessManager run: /Applications/Google Chrome.app/Contents/MacOS/Google Chrome --version, in null, env=null
⣯sevenn LocalProcessManager run: /Users/seven/Library/Android/sdk/platform-tools/adb devices -l, in null, env=null
[✓] Connected device (2 available)
    • macOS (desktop) • macos  • darwin-arm64   • macOS 14.0 23A344 darwin-arm64
    • Chrome (web)    • chrome • web-javascript • Google Chrome 115.0.5790.102

[✓] HTTP Host Availability
    • All required HTTP hosts are available

• No issues found!

Hi @omgseven
Could you share the actual result you are observing from the example? Please also share the output of flutter doctor -v as well. Thanks!

@huycozy flutter doctor output has been replenished.
What I am observing is when Image widget missing width or height playing multiframe image, RepaintBoundary outside Image widget won't work.

What I am observing is when Image widget missing width or height playing multiframe image

Could you be more specific on the Video demonstration? I see it still can be loaded normally.
Also, your Flutter version is quite old, the current latest stable is 3.16.0, please try this on the latest stable or master channel to see if it has any changes.

flutter doctor -v (stable and master)
[✓] Flutter (Channel stable, 3.16.0, on macOS 14.1 23B74 darwin-x64, locale en-VN)
    • Flutter version 3.16.0 on channel stable at /Users/huynq/Documents/GitHub/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision db7ef5bf9f (8 hours ago), 2023-11-15 11:25:44 -0800
    • Engine revision 74d16627b9
    • Dart version 3.2.0
    • DevTools version 2.28.2

[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
    • Android SDK at /Users/huynq/Library/Android/sdk
    • Platform android-34, build-tools 34.0.0
    • ANDROID_HOME = /Users/huynq/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 15.0.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 15A507
    • CocoaPods version 1.13.0

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2022.3)
    • Android Studio at /Applications/Android Studio Giraffe.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b829.9-10027231)

[!] Android Studio (version unknown)
    • Android Studio at /Applications/Android Studio Preview.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    ✗ Unable to determine Android Studio version.
    • Java version OpenJDK Runtime Environment (build 17.0.8+0-17.0.8b1000.22-10799086)

[✓] Android Studio (version 2022.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • android-studio-dir = /Applications/Android Studio.app/
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)

[✓] VS Code (version 1.84.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.76.0

[✓] Connected device (3 available)
    • RMX2001 (mobile) • EUYTFEUSQSRGDA6D • android-arm64  • Android 11 (API 30)
    • macOS (desktop)  • macos            • darwin-x64     • macOS 14.1 23B74 darwin-x64
    • Chrome (web)     • chrome           • web-javascript • Google Chrome 119.0.6045.123

[✓] Network resources
    • All expected network resources are available.

! Doctor found issues in 1 category.

[!] Flutter (Channel master, 3.17.0-15.0.pre.28, on macOS 14.1 23B74 darwin-x64, locale en-VN)
    • Flutter version 3.17.0-15.0.pre.28 on channel master at /Users/huynq/Documents/GitHub/flutter_master
    ! Warning: `flutter` on your path resolves to /Users/huynq/Documents/GitHub/flutter/bin/flutter, which is not inside your current Flutter SDK checkout at /Users/huynq/Documents/GitHub/flutter_master. Consider adding /Users/huynq/Documents/GitHub/flutter_master/bin to the front of your path.
    ! Warning: `dart` on your path resolves to /Users/huynq/Documents/GitHub/flutter/bin/dart, which is not inside your current Flutter SDK checkout at /Users/huynq/Documents/GitHub/flutter_master. Consider adding /Users/huynq/Documents/GitHub/flutter_master/bin to the front of your path.
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 2949638e82 (2 hours ago), 2023-11-26 19:35:25 -0500
    • Engine revision ebebb25aaa
    • Dart version 3.3.0 (build 3.3.0-152.0.dev)
    • DevTools version 2.30.0-dev.4
    • If those were intentional, you can disregard the above warnings; however it is recommended to use "git" directly to perform update checks and upgrades.

[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
    • Android SDK at /Users/huynq/Library/Android/sdk
    • Platform android-34, build-tools 34.0.0
    • ANDROID_HOME = /Users/huynq/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 15.0.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 15A507
    • CocoaPods version 1.13.0

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[!] Android Studio (version unknown)
    • Android Studio at /Applications/Android Studio Preview.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    ✗ Unable to determine Android Studio version.
    • Java version OpenJDK Runtime Environment (build 17.0.8+0-17.0.8b1000.22-10799086)

[✓] Android Studio (version 2022.3)
    • Android Studio at /Applications/Android Studio Giraffe Patch 3.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b829.9-10027231)

[✓] Android Studio (version 2022.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • android-studio-dir = /Applications/Android Studio.app/
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)

[✓] VS Code (version 1.84.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.76.0

[✓] Connected device (3 available)
    • RMX2001 (mobile) • EUYTFEUSQSRGDA6D • android-arm64  • Android 11 (API 30)
    • macOS (desktop)  • macos            • darwin-x64     • macOS 14.1 23B74 darwin-x64
    • Chrome (web)     • chrome           • web-javascript • Google Chrome 119.0.6045.159
    ! Error: iPhone has recently restarted. Xcode will continue when iPhone is unlocked. (code -14)

[✓] Network resources
    • All expected network resources are available.

! Doctor found issues in 2 categories.

@huycozy flutter doctor output has been replenished. What I am observing is when Image widget missing width or height playing multiframe image, RepaintBoundary outside Image widget won't work.

Maybe I didn't describe it clearly. The problem that bothers me is not the loading and display of images, but that if the width or height of the Gif image is not specified, the RepaintBoundary wrapped outside it during the Gif playback process will not play a role in limiting the redraw area. , because Gif updates cause relayout, and RepaintBoundary cannot prevent relayout from spreading upward until it encounters relayoutBoundary, which may lead to a larger range of relayout. What I hope is that when the Gif lacks width or height, determine the size of each frame during playback. If the size changes, trigger relayout instead of relayout directly.
I tried version 3.16.3 and the problem still exists. The code that causes relayout is here
https://github.com/flutter/flutter/blob/3.16.3/packages/flutter/lib/src/rendering/image.dart#L98

Thanks for the explanation. I can see the difference with demo below:

use width and height for image
only width or height for image

flutter doctor -v (stable and master)
[✓] Flutter (Channel stable, 3.16.3, on macOS 14.1 23B74 darwin-x64, locale en-VN)
    • Flutter version 3.16.3 on channel stable at /Users/huynq/Documents/GitHub/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision b0366e0a3f (23 hours ago), 2023-12-05 19:46:39 -0800
    • Engine revision 54a7145303
    • Dart version 3.2.3
    • DevTools version 2.28.4

[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
    • Android SDK at /Users/huynq/Library/Android/sdk
    • Platform android-34, build-tools 34.0.0
    • ANDROID_HOME = /Users/huynq/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 15.0.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 15A507
    • CocoaPods version 1.13.0

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[!] Android Studio (version unknown)
    • Android Studio at /Applications/Android Studio Preview.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    ✗ Unable to determine Android Studio version.
    • Java version OpenJDK Runtime Environment (build 17.0.8+0-17.0.8b1000.22-10799086)

[✓] Android Studio (version 2022.3)
    • Android Studio at /Applications/Android Studio Giraffe Patch 3.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b829.9-10027231)

[✓] Android Studio (version 2022.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • android-studio-dir = /Applications/Android Studio.app/
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)

[✓] VS Code (version 1.84.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.78.0

[✓] Connected device (2 available)
    • macOS (desktop) • macos  • darwin-x64     • macOS 14.1 23B74 darwin-x64
    • Chrome (web)    • chrome • web-javascript • Google Chrome 119.0.6045.199

[✓] Network resources
    • All expected network resources are available.

! Doctor found issues in 1 category.

[!] Flutter (Channel master, 3.18.0-7.0.pre.14, on macOS 14.1 23B74 darwin-x64, locale en-VN)
    • Flutter version 3.18.0-7.0.pre.14 on channel master at /Users/huynq/Documents/GitHub/flutter_master
    ! Warning: `flutter` on your path resolves to /Users/huynq/Documents/GitHub/flutter/bin/flutter, which is not inside your current Flutter SDK checkout at /Users/huynq/Documents/GitHub/flutter_master. Consider adding /Users/huynq/Documents/GitHub/flutter_master/bin to the front of your path.
    ! Warning: `dart` on your path resolves to /Users/huynq/Documents/GitHub/flutter/bin/dart, which is not inside your current Flutter SDK checkout at /Users/huynq/Documents/GitHub/flutter_master. Consider adding /Users/huynq/Documents/GitHub/flutter_master/bin to the front of your path.
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision c22c19b6e2 (4 hours ago), 2023-12-06 15:13:17 -0800
    • Engine revision 347f506a34
    • Dart version 3.3.0 (build 3.3.0-198.0.dev)
    • DevTools version 2.30.0
    • If those were intentional, you can disregard the above warnings; however it is recommended to use "git" directly to perform update checks and upgrades.

[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
    • Android SDK at /Users/huynq/Library/Android/sdk
    • Platform android-34, build-tools 34.0.0
    • ANDROID_HOME = /Users/huynq/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 15.0.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 15A507
    • CocoaPods version 1.13.0

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[!] Android Studio (version unknown)
    • Android Studio at /Applications/Android Studio Preview.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    ✗ Unable to determine Android Studio version.
    • Java version OpenJDK Runtime Environment (build 17.0.8+0-17.0.8b1000.22-10799086)

[✓] Android Studio (version 2022.3)
    • Android Studio at /Applications/Android Studio Giraffe Patch 3.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b829.9-10027231)

[✓] Android Studio (version 2022.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • android-studio-dir = /Applications/Android Studio.app/
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)

[✓] VS Code (version 1.84.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.78.0

[✓] Connected device (2 available)
    • macOS (desktop) • macos  • darwin-x64     • macOS 14.1 23B74 darwin-x64
    • Chrome (web)    • chrome • web-javascript • Google Chrome 119.0.6045.199

[✓] Network resources
    • All expected network resources are available.

! Doctor found issues in 2 categories.

Re-labeling to framework as this decision is made in the framework and not the image.

Since the dart:ui image object cannot change size, I do not believe the framework needs to call markNeedsLayout, just markNeedsPaint


Make "Extent" entries in items a reference

... so that they can be reused by different items.
Updating an Extent should automatically update it for all items referencing it.
from discussion with @maccraymer

@maccraymer is correct that we should make the Extent a register item class (or concept class in the new 19135 terminology). Since Extents are often reused, we should manage them as register items.

@maccraymer is correct that we should make the Extent a register item class (or concept class in the new 19135 terminology). Since Extents are often reused, we should manage them as register items.

From our chat I got a strong impression that we are not to make unilateral changes to register data model. Should we submit this for consideration to control body?

@maccraymer is the chair of the control body; this topic has been discussed extensively at the control body. However I do not know if we have had a formal "control body decision"?

For now extent import had been implemented for feature parity. This was discussed on the call first (but the issue was not filed, perhaps that point slipped through the cracks) as an important feature while extents are not separate items and cannot be referenced.


Terraform source configuration

Can I somehow change the source of terraform src while configuring the gradle terraform task as well as make the terraform task use remote state defined in backend.tf in my terraform sources?

Ok thank you very much 🙂
On Fri, Jan 14, 2022, 17:00 Lamberto Basti @.***> wrote:

The plugin infers that you are using a remote state by the fact that there
is no state file locally. When a remote state is used, all outputs and
plans are always re-evaluated, since the plugin has no knowledge of the
state last edit.
For modifying where the sources are stored:
terraform {
sourceSets {
main {
srcDir("path/to/new/folder")
}
}
}
—
Reply to this email directly, view it on GitHub
https://github.com/JetBrains/jetbrains-gradle-plugins/issues/11#issuecomment-1013249354,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACLFUFX2YJXHEYGYXPXXO4LUWBCBDANCNFSM5L7DHEBQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID:
@.***>


The font family setting isn't kept between restarts

Describe the bug
The font setting resets (only for certain fonts?) when CodeBrowser is restarted.
To Reproduce
Steps to reproduce the behavior:

Download and unpack Fixedsys.ttf.gz
Place Fixedsys.ttf to ~/.fonts
In CodeBrowser set the decompiler and disassembly font to Fixedsys Excelsior 3.01
Observe the font has changed as expected
Close and reopen CodeBrowser
Observe that an arbitrary font is used in place of fixedsys

Expected behavior
The font setting is kept between restarts
Screenshots
Before restart:

After restart:

Attachments
Fixedsys.ttf.gz
Environment (please complete the following information):

OS: Gentoo 17.0
Java Version: 11.0.2
Ghidra Version: 9.0

Ghidra's font usage relies on the OS to resolve font names when requested by the application.  It seems like there is a disconnect between font name that is initially loaded and the name that is saved in the tool options file.  If these two values do not match then the JVM will pick a font it things is a suitable replacement when the tool is restarted.
If you have setup Ghidra for debugging, then you can check these two values to see if they are inconsistent.
The code that uses the chosen font is in docking.options.editor.FontPropertyEditor  You can see the valid value that is picked (the fontNameChoice value) at line 216:
'font = new Font(fontNameChoice, styleChoice, sizeChoice);'
The code that saves the font to the options file is in ghidra.framework.options.WrappedFont starting at line 68:
	String family = font.getFamily();
	int pos = family.indexOf(".");
	if (pos > 0) {
		family = family.substring(0, pos);
	}
	saveState.putString(FAMILY, family);

Assuming these values do not match, then it is possible the code inside of WrappedFont needs to be updated.

I tried, can't dup with a custom font in my ./fonts directory.  Closing.


Partition promsum tables by year-month-day

Adds a partition column dt which is a timestamp formatted as a string like '2006-01-02' representing year-month-day.
Should improve performance when querying data. Since presto can avoid scanning files not in our time range.
This is a breaking change because we don't currently have this partition column, and we don't currently migrate schemas forward.

@EmilyM1 Nope, it's not using prometheus reportDataSource data. It's using the awsBilling reportDataSource which is a different thing, and actually already uses partitions.

Ok!


Do you have one-hand task settings?

I would like to do in-hand manipulation with only one robot hand (Like reorientation or pen spinning). I'm wondering if you have already defined such tasks. If so, it would be a great help to me if you could share it.

Dear @zheyu98,
Thanks for your issue. Sorry we don't specifically define any one-hand settings. But if you want to do some one-hand in-hand manipulation, you can refer to NVIDIA's official repository in https://github.com/NVIDIA-Omniverse/IsaacGymEnvs/blob/main/isaacgymenvs/tasks/shadow_hand.py. In fact, our repo is developed based on their implementation.
Hope this can help you.


Unable to captured not rendered widgets

Unable to convert not rendered widgets to image.

this version support capture only rendered widget ,
soon next version capture unrendered widget.

Check out https://pub.dev/packages/screenshot!


Creates customized eslint rules for checking the debugging global variables

Add eslint customized rules for checking the debugging global variables that they are set to false before being pushed.
https://github.com/CryptKeeperZK/crypt-keeper-extension/blob/0aa9c6b1f2ba9013f3e16a5dbf40b21c391f7602/src/background/backgroundPage.ts#L10

https://eslint.org/docs/latest/extend/custom-rules

Maybe we can use env variables it will be easier to achieve.

@0xmad I tried to use env variables before in the extension, but I still couldn't do it. Let me try do it again.


Modifications to Parent Transform (rotation) not applied to collider

Versions:

bevy_rapier3d: 0.19.0
bevy 0.9.0

I'm using bevy_rapier3d and I have a Sensor collider that has a Parent with a Transform. The collider gets set up correctly when it's spawned, but if a system later changes the rotation in the Transform of the Parent, that rotation doesn't get applied to the collider. The collider just stays in the same orientation.
Setup code:
    let melee_sensor = commands
        .spawn(Sensor)
        .insert(Collider::cuboid(0.75, 0.75, 0.25))
        // offset the collider so it's in front of the character model
        .insert(TransformBundle::from_transform(
            Transform::from_translation([0.0, 0.75, 0.8].into()),
        ))
        .id();
    let character_model = commands
        .spawn(SpatialBundle::from_transform(
              Transform::from_translation(Vec3::from([0.0, CHARACTER_DISTANCE_TO_GROUND, 0.0]))
                  .with_scale(Vec3::from([0.5, 0.5, 0.5])),
        )
        .push_children(&[melee_sensor])
        .id();

after this set up, the Debug view correctly shows a collider in front of the character model. If I give the character model a rotation in its setup code, the collider will be correctly rotated to the new front of the character model. But if the character model rotation changes during the game in a system, the collider won't rotate with it.

Is this a common/known issue? Anything obvious I could be doing wrong? Or any way to work around it?

I did some digging. This line gets called whenever my parent transform changes, so it seems to detect that the transform changed. But then the co.parent() in that line isn't None, so it doesn't do anything with that change.
I also tried to comment out that if/else and have it still call co.set_position even though co.parent() is not None. Then it very briefly sets the correct collider position, but before the next frame renders, it gets overwritten with the old wrong value again. Looks like some other system is writing the bad value back. Maybe based on a parent-relationship to some parent entity that didn't get updated correctly?

Yet some more digging: If I take out this then-branch and let all code always run into the else-branch there, then it suddenly works and the collider moves correctly with its parent rotation. Looks like it is indeed something with the parent/child setup.
I think the problem is that my entity hierarchy is
Character Controller (rigid body and collider, translation applies to this)
                |
                |
                v
Character Model (no rigid body, no sensor, no collider, rotation applies to this)
                |
                |
                v
Melee Sensor (sensor collider, fixed offset to Character Model)

The reason for rotation being on the Character Model level is that there is another child Character Camera of Character Controller that translates with the Character Controller, but rotates independently from the Character Model.
But bevy-rapier seems to search for a rigid body in the parent hierarchy of Melee Sensor, finds Character Controller, and makes it the direct parent of the Melee Sensor collider, completely ignoring the transform of Character Model. This is wrong. I think bevy-rapier should just ignore the whole parent-child hierarchy here and read the GlobalTransform of the Melee Sensor instead.

I have a related problem. As you can see, syncing is not implemented yet for the case with multi colliders per rigid object. As explained in the non-bevy guide, in this case the collider is "parented", meaning it is controlled by the "parent" (i.e. rigid body), so setting position with set_position will only last 1 frame. You need to set the position relative to the parent with set_position_wrt_parent.
In my case, since I already had a system to sync these collider based on some other internal info (IK), I only needed to add the following, after computing the new transform:
fn update_colliders(mut rapier: ResMut<RapierContext>,
// update transform coll_tr for collider entity here
let h = { rapier.entity2collider().get(&coll_ent).unwrap().clone() };
let c = rapier.colliders.get_mut(h).unwrap();
c.set_position_wrt_parent(Isometry::from_parts(coll_tr.translation.into(), coll_tr.rotation.into()));

But afaict this only works if you have a parent entity with the rigid body on it, & multiple direct bevy children with colliders. If you put colliders deeper, such as sensors, you can avoid them being detected as "children" in the rapier sense by adding a RigidBody::KinematicPositionBased entity in between. I also had this problem that my gizmos' sensors would be treated as part of the parent rigid body. So I have: parent RigidBody::Dynamic with collider, then child with RigidBody::KinematicPositionBased, then child with sensor & collider.


move Ollama static build to its own flag

static builds by default, allows skipping, forces build if OLLAMA_CPU_TARGET="static"

@dhiltgen My Jetson test with OLLAMA_SKIP_CPU_GENERATE=1 on passed the build and works with CUDA acceleration.
Anywhere there was a OLLAMA_SKIP_CPU_GENERATE in the Dockerfile such as https://github.com/ollama/ollama/blob/main/Dockerfile#L43 or OLLAMA_CPU_TARGET as with https://github.com/ollama/ollama/blob/main/Dockerfile#L71 (except ="static"), I added OLLAMA_SKIP_STATIC_GENERATE=1.

Resolves #3475


Split drag-n-drop implementations per platforms

Split drag-n-drop expect implementations across skiko source sets

Wrong branch

Hello, wondering if this is a prerequisite for https://github.com/JetBrains/compose-multiplatform-core/pull/1397


error importing react dist into Next.js 12 app

https://codesandbox.io/s/mediachrome-heroicons-react-notu1u

Related https://github.com/muxinc/media-chrome/pull/231
Relevant piece that isn't in that PR:

We should also update the react build to generate a cjs subfolder and have a package.json that splits imports between the esm and cjs files. (Also, if we generate it to the root rather than dist, the require/import could be media-chrome/react rather than media-chrome/dist/react

This is no longer happening, I think it was a CSB bug that got resolved


text collector doesn't collect when parameters are passed as a variable

Module version(s) affected
5.x
Description
the method collectFromCode doesn't collect if the third argument is a variable instead of a plain array. This makes using _t not very practical if you reuse injection arguments in multiple strings.
eg from my project
Here is some code
$metaDescription = _t(
    'Controller.Someentity',
    "Meet {name} {address}",
    $args
);

is never collected
    $metaDescription = _t(
      'Controller.Someentity',
      "Meet {name} {address}",
      [
          'name' => $office->Name,
          'city' => $city,
          'address' => $address->StreetAddress . " " . $address->PostalCode . ". " . $address->City
      ];
);

works fine
How to reproduce
In a controller, have
        $var = ['some' => 'var'];
        $ImNOTCollected = _t('PageController.ImNOTCollected', 'test {some}', $var);
        $ImCollected = _t('PageController.ImCollected', 'test {some}', ['some' => 'var']);

Run text collector
=> ImNOTCollected is not there
Possible Solution
No response
Additional Context
No response
Validations

[X] Check that there isn't already an issue that reports the same bug
[X] Double check that your reproduction steps work in a fresh installation of silverstripe/installer (with any code examples you've provided)

current fix if you have the issue, if you can live with a silly syntax ;-)
$ImCollectedAgain = _t('PageController.ImNOTCollected', 'test {some}', [...$var]);

I don't know that this is a bug so much as a desired enhancement. The text collector relies on what is currently a pretty crude hand-made static analysis. The capability to figure out what's in a variable would be a new capability, I think.

well, at least it could complain or make some kind of error
at the moment it fails silently even though i have a _t function
even a regex would do a better job :)

it also doesn't work on this
https://github.com/silverstripe/silverstripe-framework/blob/754ac17715c63298648b1d9a87bb44d791cdeb29/src/Dev/BulkLoader.php#L175
due to $type being a variable and not parsed correctly
or here
https://github.com/silverstripe/silverstripe-framework/blob/754ac17715c63298648b1d9a87bb44d791cdeb29/src/Security/PasswordValidator.php#L220
due to the function being used, see here, it's not there
https://github.com/silverstripe/silverstripe-framework/blob/754ac17715c63298648b1d9a87bb44d791cdeb29/lang/en.yml#L416-L419

@GuySartorelli i'm working on a PR that works with the relevant use cases. I think it makes a lot of sense in many places to be able to use variables as either the second or third argument


Better error message when invalid number detected

It would be nice if the error message below
EXIT: Invalid number in NLP function or derivative detected.

indicated which user-defined function was returning an invalid number.

Closed by #226


Add additional currencies to price peg

The price pegging option should also have the options of the three following currencies, if not more:
Chinese Yuan
Japanese Yen
South Korean Won
Danosphere's comment: These can be added through the SYS_RATES alias at any time, what we have in there right now is just what we use for testing, I can update it with more currencies or new rates for the current currencies. @sidhujag can you confirm that the UI elements in the wallet pull from the alias to populate things like the currency dropdown? If so we can close this...
moved from /syscoin issue 104.

@sidhujag issue still current on 6/18 build, can you confirm what @dwasyluk was asking as we can close this if so: @dwasyluk comment: These can be added through the SYS_RATES alias at any time, what we have in there right now is just what we use for testing, I can update it with more currencies or new rates for the current currencies. @sidhujag can you confirm that the UI elements in the wallet pull from the alias to populate things like the currency dropdown? If so we can close this...

Should def have CNY since we now are connected with our Chinese community.

Please reopen this issue at https://github.com/syscoin/pricepeg


How do we want to specify formats?

There are a few possibilites here. (Thanks to @robclark for the write-up.  I'm mostly just moving it to github.):

fourcc:

Simple and already used in many places (drm/kms, egl dmabuf extensions, v4l, etc)
Should be sufficient to describe anything that can be shared between multiple different gbm2_backends (ie. between scanout, gl/vk, camera, vidc, etc)

Khronos dataformat spec:

is more expressive than fourcc.. fourcc is not sufficient for describing “advanced” textures (mipmap levels + array and/or 3d, for example)..
This case is less likely to be involved in cross-device sharing, but could be used in cross-api sharing (ie. interop between $vendor’s gl and vk driver)
note that the interop case includes sharing between different versions of $vendor’s gl/vk driver (such as different version in a container/chroot) where layout of layers/levels might have changed)?

Straw man suggestions:

Use fourcc plus additional capabilities/constraints to fill in the gaps for gl/vk interop?
Use dataformat plus helper lib which can be used by backend to map from
Use fourcc together with (possibly device-specific) metadata.  Types of metadata supported would be handled by constraints

From @cubanismo:
Good summary Rob.  I personally think where dataformat will shine is in advanced use cases, probably many of which we aren’t seeing or haven’t thought of yet because the ability to share complicated surface formats isn’t exposed anywhere yet.  The dataformat spec was designed to fill in the gaps of fourcc.  I feel safer going with the dataformat spec as the basis of API because of that.  I agree some helper libs to actually make dataformat usable as an API interface is highly desirable, and I’ve discussed that a bit with Andrew Garrard, the spec author.  I believe we’re all in agreement that the data format spec by itself is not palatable for direct use in an API without some helper libs or headers defining some conversions and further data structures.

From @robclark:
Well, it looks like dataformat is serializable which is my big concern (ie. keep in mind that not all proc’s can open all devices) so if we get some helper libs to make dataformat easier to deal with for the common cases, then sounds good to me.

From Albert Freeman:
What about HDR and beyond (e.g. full cie xyz/luv/[or similar])?

Personally, I'd rather avoid the data format specification as it's way more verbose than we are likely to need.  However, if we're going to have a centralized allocator, we need some way to tell it the format so that it can perform the allocation.  For most things that can be shared between vendors, fourcc is sufficient.  Where it starts to run out is if I have some crazy non-scanout format that I want to share between Vulkan and CL for instance.  If we just had a vkGiveMeWhatINeedToShoveIntoGBM2 call, then we could allow some of these things to be vendor-specific.

What's wrong with verbosity if you have a function call like:
khrDataFormat = GetFormatFromVkFormat(VK_FORMAT_R8G8B8A8_UNORM);
and similar for other APIs?  That seems much better to me than falling back to opaque formats when we go beyond what fourcc can do.  Most apps won't care about the fancy stuff the data format spec can do, and those apps shouldn't need to think about it.  They can use helper functions and tables, which we could probably include in the same package with little effort.  But for the 1% that do care, it would be great to have it available.
Driver vendors could use inverse helpers and ignore formats with bits they don't support.  Maybe some driver vendors don't want to worry about anything advanced, but with HDR coming, perhaps some will soon care about things like defining an arbitrary white point for their YUV surface via its format.

I guess my biggest concern is dataformat seems like way overkill for something like a v4l camera or video decoder.  If we had some helpers that can map generic fourcc to dataformat and back (and return an error if passed a dataformat that doesn't map to a normal fourcc, perhaps) maybe it could work.
Maybe it could work the other way by using vendor capabilities to pass the extra information, since anything "fancy" would have to be supported by both sides of the sharing.
Unrelated, our header format is almost the same but not exactly as the dataformat descriptor block header.

@cubanismo For one, thing the line of code you cited doesn't work because Khronos data format specifiers are variable-length.  This makes them way more painful to work with than an emum.  Also, at least when I read it, it looked like VkFormat may not be enough information to actually construct a full data format (I may not understand it quite right though).  For YUV, at least, the data format includes a bunch of information that seems to more-or-less equate to tiling and/or plane locations.  That seems like something we may want decoupled.

@jekstrand Yes, in general the blocks are variable-sized, but for a fixed set of formats, the function could return pointers to static const data built at compile time.  Andrew at one point had a header that generated such a table for GL or Vulkan as an example I believe.
When converting from a less-detailed format description to a more-detailed one, yes there's not exact 1-1 mapping.  However, generally when going from less->more, there are some reasonable defaults that can be chosen.  Ideally the Vulkan working group would create a definitive mapping and publish it.  Going from more->less (data format -> fourcc) would be lossy, but that's inevitable.  I don't view the fact that dataformat is more expressive as a negative.  I view it as future-proofing.
I believe the additional YUV data you're referring to is sample positions and which plane a given component lives in?  It's unclear whether we want to allocate planar surfaces as one allocation or two in allocator library terms, but I don't think there's anything in the data format descriptors that don't belong in a format, and I think fourcc also describes some of the same properties you're concerned about.

@cubanismo If it's just a pointer to a const table, that's probably not substantially worse than the rest of the variable-sized blobs we've been talking about.  I'm still a bit conflicted on whether or not the extra information is future-proofing or just adding confusion and pain.  But my mind isn't 100% made-up yet.

@jekstrand Yes, the intent is that most APIs will effectively have an enum list of formats that they use, which can be used as an index into an array of pointers to data format descriptors. What you'd normally pass around is the enum - data format descriptors are intended to be short enough for fast processing, but they can't be sufficiently general without being substantially less efficient than a simple enum. I do have a version of this mapping for Vulkan and partly GL; I'm revising it for correctness since some formats changed after it appeared. It will also definitely be only an example mapping: Vulkan and GL make no statements about whether their R,G and B channels contain red, green and blue data or something entirely different. To talk to an external API and make sense, someone probably needs to have said something about this interpretation; to be useful, mappings probably need to describe the minimum common case. Some APIs might like to fill in their standard formats and allow the table to be extended by users importing external content or specifying their own more detailed approaches, but it was never the intent that hardware has to directly interpret the data format descriptor, and ideally that software should be doing so only infrequently.
The idea of having these mappings available is that you can then, for example, use them to determine how you want to do inter-API mapping. There are legitimate reasons that the user might consider all 32-bit (total) formats to be equivalent, or to believe that all RGB formats are equivalent irrespective of size. There are certainly APIs which will want to ignore the colour space aspect of the format. Rather than saying two things have to be the same, I think it's better to define what we mean by "the same".
The data format specification is intended to be FourCC on steroids. Two images may be the same "format" but store planes in different places, have different strides or be different sizes - as such that's assumed to be "outside the format". Interpreting a texel block (repeating pixel pattern), however, is part of the format - otherwise block compression wouldn't be considered part of the format. The data format spec therefore does specifically include sample position information, which can be used both for YUV chroma channel sample placement and for things like Bayer samples.
My experience is that image metadata tends to go missing when formats are transferred between APIs, especially if there's a helper library in between that doesn't know about the metadata. There are limits to what can sensibly be embedded in a general-purpose data format descriptor (the layout is extensible, so you could include a full ICC profile, but that's unlikely to be the general case) - but a best effort has been made to pack in as much as possible. There's also an effort to pack in things that you probably should have specified but might not have done - because there are a lot of home-rolled attempts to define this kind of thing in a way that requires incompatible extension. FourCC's belated addition of BT.709 and lack of discussion of full and narrow range YUV content is an example.
The data format spec currently needs updating to support the newest HDR TV standards. I'm on it. :-) It's likely that some additional metadata will always be appropriate in some environments - particularly some HDR video formats have frame-specific metadata which is probably not best encoded in the "format", although it could be held in an extension block if it was really decided that was the best approach. In most environments I wouldn't expect it to be sensible for the "format" to change this frequently, though.

@fluppeteer It's entirely possible that my desire for simplification comes from not having had to deal with the details of TV standards.  I'm not going to wish I had :-) but I'll grant that my knowledge is incomplete.

@jekstrand / @cubanismo  / @fluppeteer,
So some random thought, and something I mentioned in https://github.com/cubanismo/allocator/commit/d3c96b685f41ed92c467776e47cce9d748208aad but it seems like capability blocks are kinda the same thing as dataformat descriptors.. ie. if I understand dataformat properly it should describe all the combinations of things we are talking about with capability blocks/descriptors with respect to possible tiled/compressed/etc layout..
So maybe the question about fourcc vs dataformat is looking at things the wrong way around.  Maybe user asks for a fourcc in assertion_t and gets back a capability set consisting of dataformat descriptors plus corresponding constraint set?
I'm still not sure how user would ask for a particular format + 3d-array-mipmap.. maybe fourcc isn't the right input in assertion_t (or at least not without some additional parameters) but it does seem a bit like dataformat is the output of what the user asks for and not the input.. otherwise I'm not really sure how the user would know what dataformat to ask for.

@robclark, Yes, they do look similar but I'm not convinced they're the
same.  We could, in theory, base our final generated metadata on the data
format spec, but I don't think capabilities is a good match.
Note:  I'm not suggesting that we do.  I would rather have something
Intel-specific with an Intel format enum when it comes to the final
serializable image metadata blob.

@jekstrand fwiw, I'm assuming we don't have to exchange this over the wire every frame so the conversion between dataformat and intel format enum is inconsequential.  Admittedly I'm still at the "open mind" phase with this so just exploring other possibilities but I don't think "what enum we plug into the sampler state" is too important for how the "liballoc" (or whatever it ends up being called) API works..
My rough thoughts leading to that idea was mostly "dataformat looks a lot like constraint block/descriptor thing" and "dataformat seems too specific for a client to ask for" (ie. more appropriate as a driver response to what client asks for, or as a way to communicate description of some existing buffer between different APIs that client is using)

@robclark, just to be clear, I didn't mean that we shouldn't use data
format as part of the "what to send to the allocator" package.  I just
meant that we may not want so shove everything in as data format
extensions.  In the end, that distinction may be mute as capability and
constraint descriptions are looking a lot like data formats.

@jekstrand I guess an interesting question is what might we want in "capabilities block" that doesn't fit in dataformat?  It seems everything that I can think of that wouldn't fit belongs in the "constraint block" instead.
Anyways, I'm still in the "open mind" phase so figured it was a good time to ask this question.. we probably would need to spiff out assertion_t a bit since just a fourcc isn't sufficient to ask for "please give me a 3d-array with mip levels" and that sort of thing.. but there is at least some prior-art (for example gallium pipe_resource)

I'd asked  @fluppeteer about using data format descriptors to describe things like vendor tiling in the past, and he mentioned they weren't intended to work at this level.  I think the specific point he made was that the format is intended to encapsulate only things that describe the layout of a single pixel/texel, rather than the arrangement of texels relative to eachother.  However, while it might be an abuse of the spec from a design standpoint, I think it's technically feasible to describe things like tiling/swizzle/compression in a data format descriptor.
What @robclark said about looking at it another way (app gives fourcc or whatever, and gets back a data format block) is an interesting perspective.  I think I would still want the option of passing in a data format block too, perhaps describing it as a "template" data format that the library could munge to some defined extent and return, but allowing the use of other simpler formats directly in the API would probably be convenient.

@cubanismo, I think that's a good sum-up of my reservations about stuffing everything in a dataformat.

hmm, dataformat covering (standard) compressed formats does blur the lines a bit.  My assumption was that vendor-id's and types were intended to cover vendor tiling and compression, similar to how we are talking about capabilities block, without it being part of the core spec.  (Since I would expect you want that sort of information when exchanging between different APIs from same vendor.)   But I could be reading more into what dataformat was intended to cover than I should.
If people actively think those sorts of vendor extensions should not be in dataformat, then at least sharing the same header might be a reasonable idea.  And, yeah, having a simplified dataformat (without vendor stuff) as input template, to which driver / allocator backend tacks on extra stuff might also be an option.

I think my position was that there's a line between "how do you interpret this bit of data" (which I would reasonably call a "format") and "how do I address these pixels" (which, in the sense that stride and resolution aren't really "format", I thought of as different). Compressed formats are special because you need the whole compressed texel block to make sense of any given pixel. Bayer formats are special because you need the surrounding pixels to interpret your own - although strictly speaking you probably need more than the pixels just within the texel block to do that; the same is true for PVRTC2, of course.
The basic descriptor block (i.e. not using the extension mechanism in the data format descriptor) is intended to describe anything up to 128 pixels per dimension. More specifically, it can handle four dimensions (because ASTC supports 3D compression and if you're going to do three, you may as well do four...) and gives a byte to each dimension for describing a sample position. To be friendly to YUV formats with midpoint UV, the byte values are interpreted in halves of a (nominal) pixel size (if you need more precision than that for any reason you're probably looking at multiplying up your coordinates), so you've got up to 127.5 as a position coordinate for each sample.
You absolutely could describe a tiled pixel layout in this way except for the few tiles that are larger than 128 pixels across (and I know there are some layouts which do that). To do that, you'd describe every channel in every pixel in the tile separately in terms of its bit offset from the start of the tile. That's 16384 samples for a 64x64 tile of ARGB, or a format descriptor of about 256KB. I'd suggest that's not really a sensible "format", though, and that tiling should be metadata. :-)
The data format descriptor certainly doesn't solve all problems. It's intended to be just for the kind of thing most people think of as a "format", and that includes actual information about interpreting the content, preferably defined in some "standard" way. Note that there are several "undefined" enums for things like colour primaries - the intent is that, for example, format conversion functions know to give up in this case, but for other cases they may know how to perform the conversion, so you can still hand-wave if something isn't defined in your API, but there's a place to keep the information if it is defined.
Describing proprietary tiling in an extension block as a simple enum is another matter - I don't see a problem with that, but it could equally well be done outside the format. I don't really have a clear thought on how to handle things like hierarchical Z or lossless compression (AFBC-style) in this kind of scheme, but thus far all of this has tended to be proprietary and not used for interchange, so I've been able to ignore it.


Added listen command and fixed connect command.

I was able to connect with telnet to the TCP server in the browser!
Fixes #76

@willemneal thanks for catching the error and providing a fix. Sadly I think it's still fairly broken :( I initially copied UDP example and it seems I never actually updated to match an API 🤦♂

I'll provide some notes in the pull in case you'd be willing to spend more time fixing it.


ENH: Add new GitHub community issue templates.

Add new GitHub community issue templates.

Following Matt's suggestion.
A few comments:

I took the liberty of adding the following labels:

type:Compiler
type:Coverage
type:Design
type:Testing

I may not have found the appropriate the words to describe a deficiency, weakness or improvement area, so I used impact, but I'm not satisfied with it. If anyone has a better suggestion, please go ahead.

I tried to be clear in the template descriptions, and I think they serve for a purpose. That being said, if we could use icons or emojis like they do in the PowerShell repository templates, the list would be a little bit nicer. However, I did many, many attempts in a private repository to add them but the templates are either not being recognized again by GitHub or the icons are simply not rendered.

@hjmjohnson 's suggestions', along with the changes proposed in InsightSoftwareConsortium/pulls, have further impacts on the existence of some of these files (e.g. type:Bug), so I'll postpone any further changes until we reach consensus about these aspects.
IMHO, although virtually all can be considered as bugs, having a default type:Bug and associated template is not harmful. But not a strong preference.
As for the priorities, they were discarded when labels were first created a few months ago. I do not have a preference :question: If labels could be reserved for the admins, they would allow the admins to do the triage.

@jhlegarreta Please do not put this on hold.  Please take it to completion if possible.  I'll retract all my comments if they are going to hold these improvements up.  "Don't let perfection be the enemy of the good."  What you have is good, it should benefit the community as is.


Add AspectRatioContainer class

Closes godotengine/godot-proposals#69.
Based on work by @UgisBrekis in #32169, co-authored-by: @UgisBrekis (this will be reflected in commit history).

Main differences with #32169:

Alignment is changed to enum type rather than scalar, to achieve consistency with HBox/VBox containers. This actually made the implementation more complex, but this is the consensus I've inferred from godotengine/godot-proposals#69 as stated by @groud there https://github.com/godotengine/godot/pull/32169#issuecomment-535529095:

Ah indeed you are right and I was wrong here. But in that case, I do think this option could be removed from the H/VBoxContainers.
Edit: though I am not sure there is a simple way to achieve the same result without this option. The fact that those containers do not shrink automatically to the smallest size might makes things complex
Also, if we want it to be added, it will have to be consistent with the HBox and VBox containers, so it will have to be a enum. Consistency is more important here.

And I actually lean towards solution proposed by @UgisBrekis here. Initially, I've even removed those aligntment_x and alignment_y properties altogether, but the default alignment behavior was quite confusing, and I couldn't figure out how to do the alignment properly without those options, so I think those properties are indeed needed (even if they're just enum properties), else it would be quite confusing to beginners to figure this out (even if there's a way to achieve desired alignment without those properties). I think this kind of reasoning also applies to existing HBox/VBox containers, to make usage intuitive out of the box.

alignment_x/y renamed to alignment_horizontal/vertical, because they are grouped in the inspector anyway.

Generated and written documentation, based on description in godotengine/godot-proposals#69.

Various code/convention/consistency fixes and minor typos.

There's no editor icon, but perhaps someone could design one (or perhaps there's existing one which I left unnoticed).

Use case: creating thumbnails
AspectRatioContainer as elements of GridContainer
Ratio: 2
Stretch Mode: Cover
GridContainer/Custom Constants/VSeparation: 50
GridContainer/Custom Constants/HSeparation: 100
Alignment Horizontal: Center (default)

In this case, the frame aligned with AspectRatioContainer goes beyond origin, which is undesired in most cases due to potential clipping.
Alignment Horizontal: Begin

OK, this would be fine even with ScrollContainer on the rightmost side because I can dynamically manage the needed number of columns to fit frames dynamically now.
I hope you're happy now. 🙂
Test project:
thumbnails.zip

Ok, I don't think this example is the best one, but I guess I have the idea. I think I see a use case in the covered mode. If you want a thumbnail inside an AspectRatioContainer, with clipping enabled, you might want to be able to select the part of the thumbnail you want to show, not only the center. So it makes sense to keep this configurable, I agree.
I believe the only thing missing is to squash the commits together (please keep @UgisBrekis as co-author though).

I hope you're happy now. slightly_smiling_face

Making me happy is not important, it's making me convinced that is. :wink:

I have updated the PR to include a new icon:

This is a modification of Container.svg icon, IMO it should be good enough than no icon, if someone wants to change this later, feel free. 🙂

For the icon, since aspect ratios are often wide, perhaps the icon should be wide?
 AspectRatioContainerHorizontal.zip
However, I think it would be better to make a new icon, maybe with diagonal arrows or something?

For the icon, since aspect ratios are often wide, perhaps the icon should be wide?

While dealing with aspect ratios, what comes to my mind first is: A4 paper, smartphones, tables, more like 3:4 ratio in that sense, not widescreen 4k displays.

However, I think it would be better to make a new icon, maybe with diagonal arrows or something?

Sure, that's why I mentioned that it would be probably best if someone could enhance the existing version, or come up with a completely new one. 🙂

Thanks!

Please, make it to the 3.x branch as well @akien-mga :) It's urgently needed there.
Great work!

I can backport this to 3.2, upon approval of course.

I would really love to have AspectRatioContainer in Godot 3.2. Since Godot 4 is still months away, it makes sense to add it. Due to its absence, people have been using workarounds. Each one containing needlessly duplicated code and (potentially) bugs.

I would really love to have AspectRatioContainer in Godot 3.2. Since Godot 4 is still months away, it makes sense to add it. Due to its absence, people have been using workarounds. Each one containing needlessly duplicated code and (potentially) bugs.

How is this as an icon?

It looks a bit like a frame with the inner rectangle being golden ratio (10 x 6).

These are the current icons:

@Xrayez What do you think about the icon proposed above?

@boukew99 Do you have an SVG version of this icon?

@boukew99 Do you have an SVG version of this icon?
no

The problem is that 16x16 icons don't look nice if an icon has too many details, and that makes it problematic to represent golden ratio (if this was the original goal), especially when coordinates have to be snapped to pixels/integers so that they don't look blurry in the editor. It's difficult to say whether proposed icon would look good or bad in the editor, this is why SVG source is required to test this. I'm fine with the current icon, and the proposed icon looks fine at first glance as well, but might need modifications.
But I'm just a regular contributor, lets see what members say about this.

@boukew99 Do you have an SVG version of this icon?
no

See Editor icons documentation if you'd like to learn how to create SVG icons for the editor.

The problem is that 16x16 icons don't look nice if an icon has too many details, and that makes it problematic

I don't know about all that, but made some svg's as documented. Made a couple variations so that you have options. Note that the icons are not optimized yet and I used a slightly transparent color for the inner rectangle to distinguish it (except for 4), don't know if this is a problem.
AspectRatioContainerIcons.zip

done with class_name

Indicate golden ratio with negative space, altough the thick borders do not seem to fit very well.

A bit like those black aspect ratio bars

Accidently made NinePathRect with the rule of thirds :0

Last one, don't know what else to try

The first or the last would be the best imho.


Created Standup_meeting1

Great job on providing detailed updates about your progress during the standup meeting. It's evident that everyone is actively contributing to the project, and the progress looks promising. Keep up the good work!

Good job. Mentioned all the details about the project and issues about working with each team member.


[BUG] Frozen players can unfreeze by spawning a vehicle.

txAdmin/FXServer versions:
tx: v7.3.2
Describe the bug
When frozen you can get yourself out of it when you spawn a vehicle.

Hmm I see that this is kinda like a bug in the code, but... does it matter?
As I understand, this means that this only impacts admins, and if they are admins, then does it matter if they can bypass a freeze?

Thats fine if it only does that for admins

But, is it the case? Or did I miss something?

It lets people drive away when they spawn a car even if they aren't staff

It lets people drive away when they spawn a car even if they aren't staff

@FireFlame403 But people that aren't staff should not be able to spawn cars, right?

Yeah I can see how that can be an issue... I'll classify this as a bug.
But I will probably not work on fixing this for the next few months.
If anyone is interested in trying to fix it, feel free: https://github.com/tabarra/txAdmin/blob/master/resource/menu/client/cl_freeze.lua

there was an attemtpt
https://github.com/tabarra/txAdmin/pull/1003


[Integration] Add integration tests for unions with two fields of the same type

Describe the enhancement requested
In https://lists.apache.org/thread/z89xlvw7v1rwq89gknflhsj3c65x20kd it was pointed out that not all Arrow implementations properly support unions with several fields of the same type.
It turns out that our integration tests don't exercise this particular situation. We should probably add an integration test case for that.
Component(s)
Format, Integration

Related #40951


Bug/color fade

I got a lil sloppy, and this includes some typing updates for the new version of my library.
But it also fixes the bug with the color fading away!

Resolved the issue in #158. I also stretched out the animation for the color transition, it felt a little instant.


Update project version

Purpose

Update project version

Codecov Report

Merging #324 into master will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #324   +/-   ##
=========================================
  Coverage     64.35%   64.35%
  Complexity      132      132
=========================================
  Files            13       13
  Lines           648      648
  Branches         71       71
=========================================
  Hits            417      417
  Misses          192      192
  Partials         39       39

Continue to review full report at Codecov.

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


feat: Explore / propose strategy (if applicable, MVP implementation) for EVM Precompiled contract -> 0x07 ecMul

Feature Request
Describe the Feature Request
feat: Explore / propose strategy (if applicable, MVP implementation) for EVM Precompiled contract -> 0x07 ecMul
https://www.evm.codes/precompiled

ecMul for alt_bn128 is already implemented in Cairo here https://github.com/tekkac/cairo-alt_bn128/blob/c2ec87cc9b57846f2d89861f77b4bee69e2a5720/alt_bn128_g1.cairo#L240-L247

may I have this one assigned?


Any chance for no colour and separators?

Just a couple of ideas:
Personally I don't like having too much colour on my display so having the option to turn colour on and off would be great.
Also column/row separators could look quite neat - just lines down or across to group things together.

You could edit the MMM-COVID19.css file and remove the colors and replace with white

@Delfairen that is not the right way to do it.
You should edit css/custom.css file in order to add custom css to your Magic Mirror.

Greta thanks. I did not see any info on this in the readme.