munin: 2.0.70 -> 2.0.71

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/munin/versions.
meta.description for munin is: "Networked resource monitoring tool"
meta.homepage for munin is: "https://munin-monitoring.org/"
meta.changelog for munin is: ""
Updates performed

Version update

To inspect upstream changes

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.0.71 with grep in /nix/store/q9641aq16wy3nqfqwx3viw6m4m1ap76l-munin-2.0.71
found 2.0.71 in filename of file in /nix/store/q9641aq16wy3nqfqwx3viw6m4m1ap76l-munin-2.0.71

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
munin

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/q9641aq16wy3nqfqwx3viw6m4m1ap76l-munin-2.0.71 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A munin https://github.com/r-ryantm/nixpkgs/archive/c177826aa7bfb3f93fa656edc179d0ac0e1d2da5.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/q9641aq16wy3nqfqwx3viw6m4m1ap76l-munin-2.0.71
ls -la /nix/store/q9641aq16wy3nqfqwx3viw6m4m1ap76l-munin-2.0.71/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

munin

Maintainer pings
cc @bjornfor for testing.

Result of nixpkgs-review pr 193400 run on x86_64-linux 1

1 package built:

munin

Not sure how to test it :(


Ability to turn off excessive logging for debug builds

Because I don't want controller to spam me with NSLog() in my debug build.

#106

Sorry for the delay. Realm is announcing something new next week and I have been heads down all summer.


libwebp vulnerability

Since the description mentions image RCEs already and says there are none, it may be appropriate to mention the current libwebp CVE, which could affect old discord desktop versions and mobile versions, and is an image RCE

yeah fair point but you fail to understand that i wrote that when this exploit didnt exist 💀 and it will likely be patched soon nevermind the fact that it's already very situational and probably not practical

when did i say it existed when you wrote that? the whole point of issues is
to propose changes, lol. your decision, obviously, but this is a big
vulnerability and PoCs already exist so it's definitely practical/feasible,
so I was just suggesting that it might be mentioned
On Thu, Sep 28, 2023 at 3:58 PM DeKrypt @.***> wrote:

yeah fair point but you fail to understand that i wrote that when this
exploit didnt exist 💀 and it will likely be patched soon nevermind the
fact that it's already very situational and probably not practical
—
Reply to this email directly, view it on GitHub
https://github.com/dekrypted/discord-image-logger/issues/92#issuecomment-1739927732,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKEN7JE6M7YG4GU76OQV27DX4XJGVANCNFSM6AAAAAA5LNB3BE
.
You are receiving this because you authored the thread.Message ID:
@.***>

i dont think its practical to repeatedly be on the lookout for niche exploits and update all my things when they come out just to remove it once it's patched


refactor: remove PokePool from the PoolI interface, define on extension instead

Closes: #3031
What is the purpose of the change
This PR removes PokePool method from the pool interface and defines it on the PoolI instead.
The reason is that only balancer pool has the concept of weights. Therefore, it does not make sense to have this method on stableswap pool as well.
Instead, we can define this via extension and verify via type checking.
Additionally, I regenerated the mock pool upon changing the interface.
Brief Changelog

removed PokePool from PoolI
defined on extension
balancer pool implements extension
do type check in keeper
tests

Testing and Verifying
This change added tests and can be verified as follows
Documentation and Release Note

Does this pull request introduce a new feature or user-facing behavior changes? no
Is a relevant changelog entry added to the Unreleased section in CHANGELOG.md? yes
How is the feature or change documented? not applicable

This should be independent of the concentrated liquidity direction because, according to the spec and the balancer implementation of PokePool, it only seems to be concerned about pools with weights. So stableswap doesn't seem to need it.
However, I would like to get an ack from @ValarDragon to make sure I'm not missing anything

I'm going to merge this since this is unrelated to concentrated liquidity + 2 approvals.
If issues arise, will address them separately.


[Event Request] Codeunit 134: "Import Attachment - Inc. Doc." - Function CreateNewSalesPurchIncomingDoc

Could You add the following event to the codeunit 134 to manage document attachments in additional tables?
Object: Codeunit 134 "Import Attachment - Inc. Doc."
Function: CreateNewSalesPurchIncomingDoc
Publisher Event: OnBeforeImportAttachmentCreateNewSalesPurchIncomingDoc
Reason: To implement custom business logic and manage document Attachments in additional tables
Where is the event placed (see image attached)?:

At the begining of the function CreateNewSalesPurchIncomingDoc insert the call to the event Function with the parameter Handled.
IsHandled := false;
OnBeforeImportAttachmentCreateNewSalesPurchIncomingDoc(IncomingDocumentAttachment, IncomingDocEntryNo, IsHandled);
if IsHandled then
exit(IncomingDocEntryNo);
with IncomingDocumentAttachment do begin
Event Code:
[IntegrationEvent(false, false)]
local procedure OnBeforeImportAttachmentCreateNewSalesPurchIncomingDoc(var IncomingDocumentAttachment: Record "Incoming Document Attachment";  var IncomingDocEntryNo: Integer, var IsHandled: Boolean)
begin
end;
Thanks in Advance

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability.


Infinite update cycle

Update in my case from 2.3.2 to 2.3.10 finished well. But on next launch Atom asking to update again. All other packages updating well.

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/20428128-infinite-update-cycle?utm_campaign=plugin&utm_content=tracker%2F535900&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F535900&utm_medium=issues&utm_source=github).

It looks like Atom issue. Try to remove and install package again.

It's helped. Thanks.
Strange thing... I had emmet and emmet-atom packages.


ounit: fix: http -> https

Sanity check --- are you just doing this for efficiency?  The existing https URL works fine for me.

Oh, I'm sorry for that. Thanks for checking! I guess something didn't work back then when I was trying to integrate XenServer.


[REFACTOR] Update HTTP Method for Retrieving GSM Records (/gsm/get) API to GET and Retrieve Fields via Query Parameters Instead of Request Body

Feature Description
Currently, the GSM Retrieve API (/gsm/get) accepts requests using the POST method, with fields being submitted in the request body. Ideally, it should be a GET method API, with fields accepted as query parameters
Possible Implementation
Change the HTTP method of the GSM Retrieve API (/gsm/get) to GET and modify it to accept fields in the query parameters

I would like to work on this :)

Sure, @goku321, I've assigned it to you. Thanks for your interest. Feel free to use the issue thread or our Discord channel if you have any queries.

Sure, @sai-harsha-vardhan. Thanks :)

Hey @goku321, If you are stuck / need some help, please feel free to ask queries here / our discord channel. Thanks!

Hi @sai-harsha-vardhan Thanks for the follow up. I started making the changes but then got caught up with some other things. I will try to finish this within this week. Will reach out if I have any questions. Thanks :)

@goku321, Thanks for the update!

Hi, I would like to ask if @goku321 is still working on this and if not, @sai-harsha-vardhan is this still something someone is working on? Because we need this so the openapi spec is correct, and does not generate a warning about a body in a get; delete request.
Thanks

Hi @GunniBusch I made multiple attempts but couldn't conclude it due to a busy schedule. Please feel free to take this up. I would really appreciate that. Thanks for your patience


[Sitemaps] Fix the Tester Util's Logic

The scenario is running the SitemapTester on a sitemapIndex in a GZ file.

This is the current method stamp of the sitemapParser:
parse(URL url, String mt, boolean recursive)

As you see, the second argument is the MediaType, which never changes in the
current tool.

So the problem occurred when one tried to parse a GZ file (so he sent
"application/gzip" as media type) recursively, where inside the SitemapIndex
were other sitemaps, for example plain/text, and our parser then tried to get
the URLs from those sitemaps with the Media Type of "application/gz"...

The solution is to use the new method in issue39, where our library detects the
MediaType on the fly using Tika.

Original issue reported on code.google.com by<EMAIL_ADDRESS>on 4 Jul 2014 at 9:26

Blocking: #44
Blocked on: #65

@Chaiavi can this be closed?

Closing for now. @Chaiavi please reopen if necessary


Storage

Codecov Report
Base: 87.11% // Head: 88.38% // Increases project coverage by +1.26% :tada:

Coverage data is based on head (52ed905) compared to base (34e4f2b).
Patch coverage: 87.75% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #76      +/-   ##
==========================================
+ Coverage   87.11%   88.38%   +1.26%
==========================================
  Files          16       20       +4
  Lines         458      551      +93
==========================================
+ Hits          399      487      +88
- Misses         33       36       +3
- Partials       26       28       +2

Impacted Files
Coverage Δ

cmd/wallet-sdk-gomobile/memstorage/memstorage.go
79.31% <79.31%> (ø)

pkg/memstorage/memstorage.go
100.00% <100.00%> (ø)

...et-sdk-gomobile/openid4vp/documentloaderwrapper.go

...allet-sdk-gomobile/openid4vp/keyresolverwrapper.go

pkg/credentialquery/credentialquery.go
100.00% <0.00%> (ø)

...et-sdk-gomobile/credentialquery/credentialquery.go
91.42% <0.00%> (ø)

internal/gomobilewrappers/keyresolverwrapper.go
100.00% <0.00%> (ø)

internal/gomobilewrappers/documentloaderwrapper.go
100.00% <0.00%> (ø)

cmd/wallet-sdk-gomobile/openid4vp/openid4vp.go
93.93% <0.00%> (+0.83%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


chore(ci): bump actions/setup-python & conda-incubator/setup-miniconda

close #750
close #752

Nice, thanks 👍🏻


Cc and optimization pr

this is #30 and #33 on top of #36

@pietdevaere: the integration pieces look basically sound. I have some minor comments as you can see. It's going to take me some time to review the congestion piece, and I see it doesn't have any tests so I suggest we land that separately. Specifically, I suggest:

Clean up the issues I noted.
Add a dummy congestion controller that just allows sending at all times. Thanks for doing an interface there, that makes things much easier.
Fix the merge issues (I may be able to help with that, as it looks like in part you just have duplicate commits)
Land all the code except for congestion.go

We should be able to do that today or tomorrow depending on your availability.
Separately, we can:

Write tests for congestion.go
Review congestion.go
Land it

I don't plan to work on that file myself (modulo review), so it shouldn't cause any merge/rebase issues.
Does that work for you?

That should work for me. I can make time for this tomorrow (and maybe tonight). I was planning to work on the congestion controller soon anyway (adding RTT estimation, not to big of a change).
Three remarks:

I can not see your comments. Can you check what's up with that?
That the congestion controller is easy to swap out is by design. I thought it would be useful to make it easy to experiment with different congestion controllers.
congestion.go is a pretty direct implementation of draft-ietf-quic-recovery-06. That probably makes it easier to review.


_this Problem.

this explains itself.
CoffeScript:
_thisProblem = =>
_this = 'Problem'
alert @
_thisProblem()

JavaScript:
var _thisProblem,
_this = this;
_thisProblem = function() {
_this = 'Problem';
return alert(_this);
};
_thisProblem();

this may cause problems for users that are unaware of it.

Another issue cause by not having two-pass variable naming. I think we should mark this as a duplicate of #1574. @jashkenas: agree?

Yep.


add build-push job for saasherder

also adds maorfr to admin-list

Can one of the admins verify this patch?

[test]

[test]

LGTM


finishedEvent fires on start and end of video

The finishedEvent is triggered on start and end of video, while it should only be triggered at the end:
<VideoPlayer ... (finishedEvent)="onVideoFinished($event)"></VideoPlayer>
onVideoFinished(event) {
    console.log(event);   // triggered on start and end of video
}

Can't reproduce with the demo app. It's possible you have the event wrong event listener or it's a work flow issue.
Demo app sets the listener here and when the demo app starts it logs the following...
JS: Video.errorEvent executed
JS: Video.playbackStartEvent executed
JS: Video.playbackReadyEvent executed

JS: Video.finishedEvent executed


nosetest warning

I've 'pip3 install' bayespy in my virtualenv, but saw a warning when I run nosetest:
---------- begin log ---------------
(myvenv) Weis-MacBook-Air:~ weiliu$ pip freeze
bayespy==0.3.5
Cython==0.22.1
h5py==2.5.0
matplotlib==1.4.3
nose==1.3.7
numpy==1.9.2
pyparsing==2.0.3
python-dateutil==2.4.2
pytz==2015.4
scipy==0.15.1
six==1.9.0
(myvenv) Weis-MacBook-Air:~ weiliu$ nosetests bayespy
................................................................................................E..................
ERROR: Failure: RuntimeWarning (numpy.ufunc size changed, may indicate binary incompatibility)
Traceback (most recent call last):
File "/Users/weiliu/myvenv/lib/python3.4/site-packages/nose/failure.py", line 39, in runTest
raise self.exc_val.with_traceback(self.tb)
File "/Users/weiliu/myvenv/lib/python3.4/site-packages/nose/loader.py", line 418, in loadTestsFromName
addr.filename, addr.module)
File "/Users/weiliu/myvenv/lib/python3.4/site-packages/nose/importer.py", line 47, in importFromPath
return self.importFromDir(dir_path, fqname)
File "/Users/weiliu/myvenv/lib/python3.4/site-packages/nose/importer.py", line 94, in importFromDir
mod = load_module(part_fqname, fh, filename, desc)
File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/imp.py", line 235, in load_module
return load_source(name, filename, file)
File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/imp.py", line 171, in load_source
module = methods.load()
File "", line 1220, in load
File "", line 1200, in _load_unlocked
File "", line 1129, in _exec
File "", line 1471, in exec_module
File "", line 321, in _call_with_frames_removed
File "/Users/weiliu/myvenv/lib/python3.4/site-packages/bayespy/utils/covfunc/tests/test_distance.py", line 16, in
import scipy.spatial.distance as dist
File "/Users/weiliu/myvenv/lib/python3.4/site-packages/scipy/spatial/init.py", line 90, in
from .ckdtree import *
File "init.pxd", line 861, in init scipy.spatial.ckdtree (scipy/spatial/ckdtree.c:21116)
RuntimeWarning: numpy.ufunc size changed, may indicate binary incompatibility

Ran 115 tests in 14.507s
FAILED (errors=1)
======= end of log ===============
Any insights about this issue? Seems a upstream issue (bumpy binary compatible), though.
Thanks. And, this package is great work!

Well I don't think it's a issue since I'm going through the user tutorial and don't see any problems. May be closed.

As far as I can tell, it looks like an upstream issue, or a package installation issue. Maybe your SciPy has been compiled against a different version of NumPy than you're using in the virtual environment? If you get further insight about this and feel that it's an issue in BayesPy, please re-open this issue.


Allow metrics logged together with hparams

Before submitting

[ ] Was this discussed/approved via a Github issue? (no need for typos and docs improvements)
[x] Did you read the contributor guideline, Pull Request section?
[ ] Did you make sure to update the docs?
[ ] Did you write any new necessary tests?
[x] If you made a notable change (that affects users), did you update the CHANGELOG?

What does this PR do?
Fixes #1228 .
PR review
Anyone in the community is free to review the PR once the tests have passed.
If we didn't discuss your PR in Github issues there's a high chance it will not be merged.
Did you have fun?
Make sure you had fun coding 🙃

Hello @justusschock! Thanks for opening this PR.

In the file pytorch_lightning/loggers/tensorboard.py:

Line 104:72: W291 trailing whitespace

Do see the Hitchhiker's guide to code style

@justusschock awesome!


⚠ Bofrost.at has degraded performance

In 388e138, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 827 ms

Resolved: Bofrost.at performance has improved in 798b8ea after 6 minutes.


custodian: add re-config wifi prompt media file

Checklist

[x] npm test passes

Please describe why do you wanna add the new media?

Please describe why do you wanna add the new media?

The bug https://bug.rokid-inc.com/zentaopms/www/index.php?m=bug&f=view&bugID=18606
needs a new speech file.

The CI failed :)


Add VJC Token

Please check the following to ensure a successful verification of Token Profile
.json and .png document checklists

[x] logo dimensions: 120*120 px
[x] logo background: Transparent
[x] At least one transaction on the token contract
[x] For ERC-20 project teams: Upper and lower capitalized alphabets in token address (For checksum purposes)
[x] Same document name for both .json and .png (Including capitalization)

Project background:
Official announcement:
Project team background:
Project basic information:
Media publications:
Tradeable exchanges:
Recommended Gas Limit (For ERC-20 project teams) for transaction: (Default is 60,000)

Official announcement:
Project team background:
Project basic information: VENJOCOIN provides a high value asset decentralized marketplace for consumers to buy authenticated assets whose provenance is tracked and stored on the blockchain.
Media publications: http://telecom.chinabyte.com/46/14607546.shtml | http://telecom.chinabyte.com/46/14607546.shtml
Tradeable exchanges: https://app.stex.com/en/trade/pair/BTC/VJC/1D
Recommended Gas Limit (For ERC-20 project teams) for transaction: (Default is 60,000)

Official announcement: https://venjocoin.io/announcement/notice.html


.5px border width adds spacing between video and border

Current Behavior
If I add a border to react-player and the width of the border ends with .5px than there will be a spacing between the video and the border (top and left side).
Expected Behavior
It should display a nice border without any spacing, even if I add a 1.5px width border
Steps to Reproduce

Just open the codesandbox link

Environment

URL attempting to play: https://vimeo.com/552793693
Browser: Chrome 91.0.4472.114
Operating system: macOS Big Sur 11.4
codesandbox example: https://codesandbox.io/s/reactplayer-sample-forked-xc5gi?file=/src/index.js

Other Information

This seems like a browser/CSS quirk, and not something that this library needs to solve.


[server] Apply default consumer receive buffer setting only if not provided via configs

Apply default consumer receive buffer setting only if not provided via configs
How was this PR tested?

CI
Does this PR introduce any user-facing changes?

[x] No. You can skip the rest of this section.
[ ] Yes. Make sure to explain your proposed changes and call out the behavior change.

Thanks, @nisargthakkar for the review!


Could use guidance on how to train

I have a highly curated data set with hundreds of thousands of wav files that I was using for experimenting with using a GAN to generate audio. Recently I created a technique where I translate machine generated data into natural language text for a Diffusion model.
I've been reading on the Discord server but I'm not 100% sure I got things figured out..
Here's what I'm thinking so far, please correct me where I am making mistakes.

Use the CLI to convert the wav files to spectrograms
Generate my text prompts for using my python machine data to natural language text script; save to json for Dreambooth training
Use the normal Dreambooth training process to fine tune on my audio data
Use the diffusion model to generate an spectrogram
Use the CLI to convert the spectrogram to a wav file

Things I'm unclear on

I'm not sure if this model can be imported into Riffusion
If the model can't be imported into Riffusion, I should be able to do inferencing in a notebook like Automatic1111
Unclear if ImgToImg, in & out painting can be used
-I have hundreds of thousands of wav files that I can label automatically, can/should I scale it this high, what is reasonable vs unreasonable

Hey @dustyny! Yes you can use any standard training or dreambooth method as long as you have compatible spectrogram images with text. And you can use the CLI example to help convert with your desired parameters. Whether you fine tune or use dreambooth depends on how much data you have, typically dreambooth is for a much smaller dataset than hundreds of thousands of files.
The model can be imported into riffusion, and you can use it within automatic1111 (an extension to convert to audio also exists). Img2img, outpainting, and so on all work.

I'd be keen to hear about your use case if you DM me on discord as well.

I really appreciate the response, I'll connect with you on discord to discuss more in depth. It sounds like standard training (I want to understand what you mean by that) is my best approach, I have a lot of data that I can use for training.

I got fine-tuning to run using the examples/train_text_to_image.py script in diffusers. You do need to format your data, but that's in the HF docs so not a huge issue.
In my case I had to download the riffusion model—I was getting errors when trying to get it directly from HF (i.e., in code). So I used git to download a local copy (you need lfs—also covered in the model card page).
The problem I'm having is that, when trying to run the fine-tuned model, I get a type error: RuntimeError: Input type (c10::Half) and bias type (float) should be the same
This is happening in F.conv2d(). Full trace:
Traceback (most recent call last):
  File "/home/james/anaconda3/envs/riffusion/lib/python3.9/site-packages/streamlit/runtime/scriptrunner/script_runner.py", line 565, in _run_script
    exec(code, module.__dict__)
  File "/home/james/src/somms/riffusion/riffusion/streamlit/pages/text_to_audio.py", line 102, in <module>
    render_text_to_audio()
  File "/home/james/src/somms/riffusion/riffusion/streamlit/pages/text_to_audio.py", line 78, in render_text_to_audio
    image = streamlit_util.run_txt2img(
  File "/home/james/anaconda3/envs/riffusion/lib/python3.9/site-packages/streamlit/runtime/caching/cache_utils.py", line 428, in wrapper
    return get_or_create_cached_value()
  File "/home/james/anaconda3/envs/riffusion/lib/python3.9/site-packages/streamlit/runtime/caching/cache_utils.py", line 401, in get_or_create_cached_value
    return_value = func(*args, **kwargs)
  File "/home/james/src/somms/riffusion/riffusion/streamlit/util.py", line 103, in run_txt2img
    output = pipeline(
  File "/home/james/anaconda3/envs/riffusion/lib/python3.9/site-packages/torch/autograd/grad_mode.py", line 27, in decorate_context
    return func(*args, **kwargs)
  File "/home/james/anaconda3/envs/riffusion/lib/python3.9/site-packages/diffusers/pipelines/stable_diffusion/pipeline_stable_diffusion.py", line 531, in __call__
    noise_pred = self.unet(latent_model_input, t, encoder_hidden_states=text_embeddings).sample
  File "/home/james/anaconda3/envs/riffusion/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1194, in _call_impl
    return forward_call(*input, **kwargs)
  File "/home/james/anaconda3/envs/riffusion/lib/python3.9/site-packages/diffusers/models/unet_2d_condition.py", line 421, in forward
    sample = self.conv_in(sample)
  File "/home/james/anaconda3/envs/riffusion/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1194, in _call_impl
    return forward_call(*input, **kwargs)
  File "/home/james/anaconda3/envs/riffusion/lib/python3.9/site-packages/torch/nn/modules/conv.py", line 463, in forward
    return self._conv_forward(input, self.weight, self.bias)
  File "/home/james/anaconda3/envs/riffusion/lib/python3.9/site-packages/torch/nn/modules/conv.py", line 459, in _conv_forward
    return F.conv2d(input, weight, bias, self.stride,
RuntimeError: Input type (c10::Half) and bias type (float) should be the same

Any thoughts as to what might be going on?


Roll Engine from f6ea6186eecc to c0e1f31a258d (28 revisions)

Roll Engine from f6ea6186eecc to c0e1f31a258d (28 revisions)
https://github.com/flutter/engine/compare/f6ea6186eecc...c0e1f31a258d
2022-02-22<EMAIL_ADDRESS>Roll Fuchsia Mac SDK from LGycQA_aX... to M5s9oCF7p... (flutter/engine#31599)
2022-02-22<EMAIL_ADDRESS>Roll Skia from cd0e20276742 to ed0e1a8af762 (1 revision) (flutter/engine#31598)
2022-02-21<EMAIL_ADDRESS>Roll Dart SDK from 42fb757902d7 to 27f6d32f083d (1 revision) (flutter/engine#31597)
2022-02-21<EMAIL_ADDRESS>Roll Fuchsia Linux SDK from Y8PWtUeLw... to ePY_4hKRD... (flutter/engine#31596)
2022-02-21<EMAIL_ADDRESS>Roll Dart SDK from 7d43846b4279 to 42fb757902d7 (1 revision) (flutter/engine#31590)
2022-02-21<EMAIL_ADDRESS>Roll Fuchsia Mac SDK from z-0ixRwDG... to LGycQA_aX... (flutter/engine#31588)
2022-02-21<EMAIL_ADDRESS>Roll Dart SDK from ef4160e0de31 to 7d43846b4279 (1 revision) (flutter/engine#31587)
2022-02-21<EMAIL_ADDRESS>Roll Fuchsia Linux SDK from WYWoigmrk... to Y8PWtUeLw... (flutter/engine#31585)
2022-02-21<EMAIL_ADDRESS>Roll Skia from 19a779987f53 to cd0e20276742 (1 revision) (flutter/engine#31584)
2022-02-21<EMAIL_ADDRESS>Roll Skia from 3d1667b34914 to 19a779987f53 (1 revision) (flutter/engine#31583)
2022-02-21<EMAIL_ADDRESS>Change FlutterViewController default opaque value to NO (flutter/engine#30664)
2022-02-21<EMAIL_ADDRESS>Roll Dart SDK from 4193ada22586 to ef4160e0de31 (1 revision) (flutter/engine#31581)
2022-02-21<EMAIL_ADDRESS>Roll Fuchsia Mac SDK from K0snBGHfk... to z-0ixRwDG... (flutter/engine#31580)
2022-02-20<EMAIL_ADDRESS>Roll Fuchsia Linux SDK from -z0Yvt3kP... to WYWoigmrk... (flutter/engine#31579)
2022-02-20<EMAIL_ADDRESS>Roll Fuchsia Mac SDK from 9ksAdcxnR... to K0snBGHfk... (flutter/engine#31578)
2022-02-20<EMAIL_ADDRESS>Roll Skia from ac41af4e4ca0 to 3d1667b34914 (1 revision) (flutter/engine#31577)
2022-02-20<EMAIL_ADDRESS>Roll Skia from b9c27d3e7c77 to ac41af4e4ca0 (1 revision) (flutter/engine#31576)
2022-02-20<EMAIL_ADDRESS>Roll Fuchsia Linux SDK from iTZ2zk0F5... to -z0Yvt3kP... (flutter/engine#31574)
2022-02-20<EMAIL_ADDRESS>GN targets to create flutter_web_sdk. (flutter/engine#31556)
2022-02-20<EMAIL_ADDRESS>Roll Dart SDK from 8bdcc1fd53e5 to 4193ada22586 (1 revision) (flutter/engine#31573)
2022-02-20<EMAIL_ADDRESS>Roll Dart SDK from 3ffaf75396c3 to 8bdcc1fd53e5 (1 revision) (flutter/engine#31572)
2022-02-19<EMAIL_ADDRESS>Roll Fuchsia Mac SDK from IT4CxO_gN... to 9ksAdcxnR... (flutter/engine#31571)
2022-02-19<EMAIL_ADDRESS>Roll Dart SDK from 81a28e7947bd to 3ffaf75396c3 (1 revision) (flutter/engine#31570)
2022-02-19<EMAIL_ADDRESS>Roll Dart SDK from abcc945d2079 to 81a28e7947bd (1 revision) (flutter/engine#31569)
2022-02-19<EMAIL_ADDRESS>Roll Fuchsia Linux SDK from 2lxj0jcGf... to iTZ2zk0F5... (flutter/engine#31568)
2022-02-19<EMAIL_ADDRESS>Roll Dart SDK from 5b29f2b50059 to abcc945d2079 (1 revision) (flutter/engine#31567)
2022-02-19<EMAIL_ADDRESS>Roll Fuchsia Mac SDK from QdGBI6Rde... to IT4CxO_gN... (flutter/engine#31566)
2022-02-19<EMAIL_ADDRESS>Roll Dart SDK from a565c735913c to 5b29f2b50059 (1 revision) (flutter/engine#31565)
Also rolling transitive DEPS:
fuchsia/sdk/core/linux-amd64 from 2lxj0jcGf6m2 to ePY_4hKRD9w4
fuchsia/sdk/core/mac-amd64 from QdGBI6RdeX2J to M5s9oCF7pxWy
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md
...

Commit queue failed; closing this roll.


fix archive/full download link

This was also an error of the Python2 -> 3 conversion ...

Codecov Report

Merging #2929 into dev will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##              dev    #2929   +/-   ##
=======================================
  Coverage   95.21%   95.21%
=======================================
  Files          73       73
  Lines       13993    13993
=======================================
  Hits        13323    13323
  Misses        670      670

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 fe2395b...831a359. Read the comment docs.


Feature/gee recent imagery

Some thoughts/bugs:

Dropdown's from selectors aren't appearing directly below input
Calendar selector input has flashing cursor when clicked on (but not input)
Can we limit the calendar to not go past the current month, as it is not needed?
Clicking the 'i' button in the map layer legend doesnt open anything
Hovering on the tiles doesn't show the text properly above it (blurry)


MaterialApp Theme

How Theme could be assigned to the MaterialApp ?
Theme depends on context - screen width / system theme type and etc - so it could be:
1.
MaterialApp(
        home: child,
        builder: (context, child) => AnimatedTheme(
          data: appTheme(context),
          child: child!,

but it duplicate AnimatedTheme(data: ThemeData.light() creation in the MaterialApp
2.
MediaQuery(
  data: MediaQueryData.fromWindow(window),
  child: MaterialApp(
        home: child,
        theme: appTheme(context),

but it duplicate MediaQuery creation (or alternative widget as sample above has no MediaQuery changes notifications for the theme) in the MaterialApp
Is there any simple way to disable duplicate AnimatedTheme creation for 1.? Could it be MaterialApp parameter or etc?

Hi @zs-dima

How Theme could be assigned to the MaterialApp ?

You just have to pass it: MaterialApp(theme: ThemeData.dark())
I'm not sure what you mean with this issue. AnimatedTheme is a widget and you can't pass it into theme parameter of the MaterialApp. If you want to animate an entire page, you can try to wrap the widget passed into the home parameter into a AnimatedTheme widget.

@pedromassangocode
MaterialApp(theme: appTheme(context)) - will lead to exception when I will try to access MediaQuery.of(context).size.width in the appTheme(context) method

Therefore I created this issue

as I mention in the issue description:

@zs-dima  it is not expected to create themes that depends on the context during the MaterialApp creation as you may not have a valid context.
You can either: create a theme with ThemeData.dark(), ThemeData.light(), ThemeData() as those does not depends on context. As I mentioned above: you need to create your theme (that needs a context) on the widget you pass in the home parameter.

@pedromassangocode how could I set font size depends on device screen size then?

and keep font size and etc updating when user change device orientation?

it is basics of responsive layouts, so strange if Flutter doesn't not support basic responsive themes

@pedromassangocode how could I set theme font sizes depends on device screen size/width then?

It seems you are asking for assistance on personal code. Please see https://flutter.dev/community for resources and asking questions like this, you may also get some help if you post it on Stack Overflow and if you need help with your code, please see https://www.reddit.com/r/flutterhelp/
Closing, as this isn't an issue with Flutter itself. If you disagree, please write in the comments and I will reopen it.
Thank you

@pedromassangocode - it is Flutter issue with bad MaterialApp design that does not allow to use themes correctly. So I asking to fix this issue. I created new one as you closed current issue.

It seems you are asking for assistance on personal code.
No

it is Flutter issue with bad MaterialApp design that does not allow to use themes correctly.

Can you please provide a code sample that demonstrate that? Sorry but it is not clear to mw what is the real issue here. I would be happy to reopen this issue once it is clear enough what this is about.
Thank you


Ignored files are watched by hugo server

Recently, I ran into an issue where hugo server simply hangs after building the website. After some investigation (see https://github.com/lowRISC/opentitan/issues/12322), it looks like the problem is caused by the Hugo server watching for changes in files that should be ignored.
I was able to reproduce a minimal example of this problem with the latest version. Here's the terminal transcript:
Initial setup; I just downloaded the latest binary locally and set up a new site and an empty index.md:
$ mkdir hugo_test && cd hugo_test
$ curl -sL https://github.com/gohugoio/hugo/releases/download/v0.97.3/hugo_extended_0.97.3_Linux-64bit.tar.gz | tar -xzO hugo > bin/hugo
$ alias hugo=~/hugo_test/bin/hugo
$ chmod +x bin/hugo
$ hugo version
hugo v0.97.3-078053a43d746a26aa3d48cf1ec7122ae78a9bb4+extended linux/amd64 BuildDate=2022-04-18T17:22:19Z VendorInfo=gohugoio
$ hugo new site test
Congratulations! Your new Hugo site is created in /home/jadep/hugo_test/test.
<...full output clipped...>
Visit https://gohugo.io/ for quickstart guide and full documentation.
$ ls
bin  test
$ hugo new test/index.md

Then I created a minimal config.toml with the following contents:
$ vim config.toml
$ cat config.toml
contentDir = "."
ignoreFiles = ["foo"]
watch = true

So far, so good. I could then run hugo server without issues:
$ hugo server --config config.toml
Start building sites …
hugo v0.97.3-078053a43d746a26aa3d48cf1ec7122ae78a9bb4+extended linux/amd64 BuildDate=2022-04-18T17:22:19Z VendorInfo=gohugoio
WARN 2022/04/28 12:23:27 found no layout file for "HTML" for kind "taxonomy": You should create a template file which matches Hugo Layouts Lookup Rules for this combination.
WARN 2022/04/28 12:23:27 found no layout file for "HTML" for kind "taxonomy": You should create a template file which matches Hugo Layouts Lookup Rules for this combination.
WARN 2022/04/28 12:23:27 found no layout file for "HTML" for kind "home": You should create a template file which matches Hugo Layouts Lookup Rules for this combination.

                   | EN
-------------------+-----
  Pages            |  3
  Paginator pages  |  0
  Non-page files   |  2
  Static files     |  0
  Processed images |  0
  Aliases          |  0
  Sitemaps         |  1
  Cleaned          |  0

Built in 149 ms
Watching for changes in /home/jadep/hugo_test/{bin,public,resources,test}
Watching for config changes in /home/jadep/hugo_test/config.toml
Environment: "development"
Serving pages from memory
Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender
Web Server is available at //localhost:1313/ (bind address <IP_ADDRESS>)
Press Ctrl+C to stop

However, then I added a symlink to a very large directory (~/.cache). I'd expect that the symlink should be ignored, because foo is in ignoreFiles in config.toml. However, instead, hugo server just hangs after building the website, consuming a substantial portion of CPU the whole time:
$ ln -s ~/.cache foo
$ hugo server --config config.toml
Start building sites …
hugo v0.97.3-078053a43d746a26aa3d48cf1ec7122ae78a9bb4+extended linux/amd64 BuildDate=2022-04-18T17:22:19Z VendorInfo=gohugoio
WARN 2022/04/28 12:32:14 found no layout file for "HTML" for kind "home": You should create a template file which matches Hugo Layouts Lookup Rules for this combination.
WARN 2022/04/28 12:32:14 found no layout file for "HTML" for kind "taxonomy": You should create a template file which matches Hugo Layouts Lookup Rules for this combination.
WARN 2022/04/28 12:32:14 found no layout file for "HTML" for kind "taxonomy": You should create a template file which matches Hugo Layouts Lookup Rules for this combination.

                   | EN
-------------------+-----
  Pages            |  3
  Paginator pages  |  0
  Non-page files   | 14
  Static files     |  0
  Processed images |  0
  Aliases          |  0
  Sitemaps         |  1
  Cleaned          |  0

Built in 324 ms
<no further output, cancelled after 5 minutes>

I believe this behavior has to do with the "watch for changes" routine, because if I pass --watch=false, then the behavior goes away. I am confident it's not an issue with the pattern-recognition in ignoreFiles, because if I symlink foo to a small directory then this problem disappears and I can see that foo reappears and disappears from the output as expected when I change ignoreFiles. I also checked if it was a problem with symlink cycles by creating one under foo, but that also doesn't cause the hanging behavior. My best guess is that it has to do with the size of the link target.
But the exact cause of the hanging behavior is slightly orthogonal here; I simply wouldn't expect Hugo to be watching those files, since they're explicitly excluded in config.toml.

What version of Hugo are you using (hugo version)?

$ hugo version
hugo v0.82.0-9D960784+extended linux/amd64 BuildDate=2021-03-21T17:28:04Z VendorInfo=gohugoio

Does this issue reproduce with the latest release?
Yes, I've replicated it with the latest binary (<IP_ADDRESS>)

Hugo's file watching is mostly directory based (we also watch some single config files), and that has to be so for it to scale.
So, currently we drop change events for ignored files, but you're right in that we would also drop watching directories that matches the ignore expression(s).


☂-Issue for elimination of Helm charts in favor of Golang implementation

How to categorize this issue?

/area dev-productivity robustness quality testing
/kind enhancement
/priority 3
What would you like to be added:
This is an umbrella issue for improving our existing code, mainly in the operation and botanist packages.
We lack unit and/or integration tests at too many places and should improve this. One important pain point is that the data flow is too distributed, many values are duplicated in Helm charts (e.g., labels, ports, names, ...) which makes it very hard to introduce a change as this might break unexpectedly.
One proposal is to leverage the recently introduced component interfaces (#1980) and eliminate the Helm charts in favor of Golang structs (see #2731). Another proposals is (at the point of time writing this issue) currently evaluated by @timebertt and discussed in two days.
Once agreed upon the preferred approach how to proceed, we can replicate it for the majority of the task functions in the shoot reconciliation and deletion flows.
Agreements:

With the node-local-dns refactoring, we experienced that it can be cumbersome to compare for equality the serialized obj in from the ManagedResource secrets. The order of annotations in the serialized obj was changing based on the ConfigMap data. While other components like vpnshoot, coredns rather have static ConfigMaps/Secrets and the annotations keys and the order of annotations is not changing that often. That's why for node-local-dns we decided to compare the obj (the DaemonSet) using golang struct. If a component hits similar issue to the node-local-dns, it can use compare the obj using golang struct (first deserialize the obj, then compare it to the expected one).

Tasks
The following Helm charts still need to be refactored:

shoot-core/components:

[ ] @oliver-goetz apiserver-proxy (create botanist/component/apiserverproxy package)
[x] https://github.com/gardener/gardener/pull/7401
[x] https://github.com/gardener/gardener/pull/6134
ℹ podsecuritypolicies should not be refactored since PSPs are deprecated, we should rather work on https://github.com/gardener/gardener/issues/5250

shoot-addons: (here, we should first decide whether we want to keep them since they are already only allowed for shoots < 1.22 or evaluation shoots >= 1.22 (see https://github.com/gardener/gardener/pull/4213))

[x] https://github.com/gardener/gardener/pull/7267
[x] https://github.com/gardener/gardener/pull/7294

seed-bootstrap{-crds}:

[x] https://github.com/gardener/gardener/pull/6210
[ ] grafana (after https://github.com/gardener/gardener/pull/7007 and https://github.com/gardener/gardener/pull/7318 got merged)
[x] Other Monitoring-related charts (Keep them but move them into existing botanist/components/monitoring package and deploy via ManagedResource) (will be replaced eventually as part of GEP-19)
[x] Logging-related charts (Keep them but move them into existing botanist/components/logging package and deploy via ManagedResource) (will be replaced eventually as part of GEP-19)
[x] https://github.com/gardener/gardener/pull/6133
[x] https://github.com/gardener/gardener/pull/6135
[x] https://github.com/gardener/gardener/pull/6186

istio:

[x] https://github.com/gardener/gardener/pull/5946
[x] https://github.com/gardener/gardener/pull/6165

seed-monitoring (here, we should ideally move it out to an extension, but since this is unclear we should at least clean up the structure for now (see also https://github.com/gardener/gardener/issues/3553)):

[x] https://github.com/gardener/gardener/pull/6210
[ ] grafana (after https://github.com/gardener/gardener/pull/7007 and https://github.com/gardener/gardener/pull/7318 got merged)
[x] Keep other Helm charts but move them into existing botanist/components/monitoring package and deploy via ManagedResource (partially dropped for now in favor GEP-19)

Especially the deployment via ManagedResources for the seed system components will yield to better observability and seed conditions now that we have https://github.com/gardener/gardener/pull/5274.

One proposal is to leverage the recently introduced component interfaces (#1980) and eliminate the Helm charts in favor of Golang structs (see #2731). Another proposals is (at the point of time writing this issue) currently evaluated by @timebertt and discussed in two days.

I did a rough sketch of how it could look like, if we want to keep the helm charts, but still implement a proper data flow of chart values and tests for those charts.
I started with #2731 and applied my ideas on top of it, while bringing back the charts and mostly keeping the tests proposed in @rfranzke's PR. You can sneak a peek here in #2766.
We will discuss both approaches in the afternoon and decide on which approach we like to proceed with.

/unassign @timebertt - thanks for investigating different approaches!
/assign @danielfoehrKn for a refactoring for the DeployKubeControllerManager task (similar to #2731).

/unassign for now as #2783 is merged

/assign @BeckerMax for gardener-resource-manager deployment refactoring
/assign @rfranzke for OperatingSystemConfig refactoring

/assign @BeckerMax for gardener-resource-manager deployment refactoring
/assign @rfranzke for OperatingSystemConfig refactoring

/unassign as #3445 was merged

(In progress) Refactor nginx-ingress Helm chart into component

The next task of this umbrella issue is refactoring the kube-proxy Helm chart in order to optimize the rollouts.

The following Helm charts still need to be refactored:

shoot-core/components:

[ ] apiserver-proxy (create botanist/component/apiserverproxy package)
[ ] network-policies (ideally put into existing botanist/component/networkpolicies package)
[ ] shoot-info (ideally put into existing botanist/component/shootsystem package)
ℹ podsecuritypolicies should not be refactored since PSPs are deprecated, we should rather work on https://github.com/gardener/gardener/issues/5250

shoot-addons: (here, we should first decide whether we want to keep them since they are already only allowed for shoots < 1.22 or evaluation shoots >= 1.22 (see https://github.com/gardener/gardener/pull/4213))

[ ] kubernetes-dashboard (create botanist/component/kubernetesdashboard package)
[ ] nginx-ingress (ideally merge with existing botanist/component/nginxingress package)

seed-bootstrap{-crds}:

[ ] Monitoring-related charts (Keep them but move them into existing botanist/components/monitoring package and deploy via ManagedResource)
[ ] Logging-related charts (Keep them but move them into existing botanist/components/logging package and deploy via ManagedResource)
[ ] hvpa and its CRD (create botanist/component/hvpa package)
[ ] reserve-excess-capacity (create botanist/component/seedsystem package (similar to shootsystem))
[ ] priorityclass-shoot-controlplane.yaml (create botanist/component/seedsystem package (similar to shootsystem)) - there might be more such PriorityClasses in the future, see https://github.com/gardener/gardener/issues/5634

istio:

[ ] (@acumino) Keep Helm chart but move it into existing botanist/components/istio package and deploy via ManagedResource

seed-monitoring (here, we should ideally move it out to an extension, but since this is unclear we should at least clean up the structure for now (see also https://github.com/gardener/gardener/issues/3553)):

[ ] Keep Helm charts but move them into existing botanist/components/monitoring package and deploy via ManagedResource

Especially the deployment via ManagedResources for the seed system components will yield to better observability and seed conditions now that we have https://github.com/gardener/gardener/pull/5274.

/assign @wyb1 @istvanballok @rickardsjp
for the grafana component refactoring

/assign

/unassign @oliver-goetz @rfranzke

/assign @acumino @shafeeqes
for blackbox-exporter and node-exporter.

/unassign

The plutono charts are the last that we want to refactor as part of this issue. I think the prerequisites are completed and this task can be picked up.

/assign


add more flows

feat: add explain flow for getting some explanation
feat: add summarize flow for getting some explanaiton

:tada: This PR is included in version 1.3.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


(Fix) rename repo and

Problem:

repo has oracles in the name
combine-solidity is not
Solutions:
remove oracles. not sure if we need to add poa- prefix

@rstormsf what do you think will be a good name?
solidity-flattener is taken
solc-flattener ?

js is not important here
solc is known by fewer people than solidity
let's use solidity-flattener


Install time must be radically improved

Is your feature request related to a problem? Please describe.
It isn't reasonable in some cases to prebuild VM images with az cli installed.   In those cases, when its needed an install must be on par if not better than installing terraform.
I have a github action that has these numbers;
 Install/Upgrade AZ CLI      4m 56s
    CONTAINER_NAME: intake
Run Start-Process msiexec.exe -Wait -ArgumentList '/I azure-cli-2.3.1.msi /quiet'
  Start-Process msiexec.exe -Wait -ArgumentList '/I azure-cli-2.3.1.msi /quiet'
  shell: C:\Program Files\PowerShell\7\pwsh.EXE -command ". '{0}'"

This is just the install as I had the installer checked in to my github repo.
Describe the solution you'd like
A az cli install must be in the seconds range. (10-30 seconds).  Frankly this should be a fast as a file copy.

hi @fengzhou-msft could you pls have a look? thanks

I changed my initial requirement.
az cli must install under 4 seconds.
Terraform installed in under 4s via a github action and that was with a wget in the mix.
If makes API calls to azure, as does az cli.
A 5 min install is not an acceptable time compared to this direct competitor.
 Install Terraform   4s
   200K .......... .......... .......... .......... ..........  1% 88.9M 2s
Run pushd './'
~/work/terraform-setup-azfunc-shorturl/terraform-setup-azfunc-shorturl ~/work/terraform-setup-azfunc-shorturl/terraform-setup-azfunc-shorturl
Reading package lists...
 The MSI package size is over 50 MB and the space on disk after installation is over 200 MB.
With the current design, it's hard to make dramatic improvement. We are working on a lightweight installer to improve the install time.

@fengzhou-msft    I was in a situation like this once where I had to change the design a bit so that I could zip the whole 100+ MB and slam it down to a folder.  That was the install portion - unzip and run.  Other than that, a rewrite in GO like terraform cli where its one big ole exe is the extreme option.  Thank you for looking at this.

Setting up this as a 50 MB zip package on a CDN within Azure would be reachable right? Then you could stream the unzip command from this CDN location towards the disk of the agent.
Or maybe preinstalling Az CLI on your shared agents. PowerShell Az Modules are already there with various versions.
Or, @ghstahl you could set up your self-hosted agent with Az CLI preinstalled.

Investigating options for having less files would probably be the most fruitful exercise. There is overhead for each file no matter how large it is. Especially on windows. 200mb can copy extremely fast. You can see this if you have 2 local drives. Copy the CLI from one to the other. Then copy one 200mb file. Measure the difference and that's your opportunity for improvement for something with 200mb size on disk.
Beyond that. There may be some low hanging fruit in the msi. Compare the install time after downloading to the copy time you measured above to see what the msi overhead is.

Here is a small change that will help a little. https://github.com/Azure/azure-cli/pull/16903

I will note that upgrade is the worst path here. I have some ideas that could improve that path more too.

@jiasli for awareness

Something failed WRT to the PR title but nothing telling me what it should look like. Let me know what needs to be adjusted.

I did some tests recently:

On Windows 11 running on my Surface Book and Windows 10 running on my desktop PC, Azure CLI MSI (https://azcliprod.blob.core.windows.net/msi/azure-cli-2.34.1.msi) takes around 1m15s to install.

On Ubuntu 20.04 running in WSL, Azure CLI DEB (https://packages.microsoft.com/repos/azure-cli/pool/main/a/azure-cli/azure-cli_2.34.1-1~focal_all.deb) takes around 30s to install.

For MacOS, I don’t have a MacOS physical device at hand right now, but according to a test I made with Azure DevOps MacOS 1.15 agent, it take 2m30s: https://dev.azure.com/azure-sdk/playground/_releaseProgress?_a=release-environment-logs&releaseId=980&environmentId=1052
2022-03-10T08:47:46.9799610Z brew install azure-cli –verbose
2022-03-10T08:50:17.9113860Z az --version

The installation time is mainly due to the file number of Python SDK which includes lots of "duplicated" files for all API versions.
The overall file number of Azure CLI 2.34.1 is 15667 and 8594 files are from Python SDK (more than a half of totally file number).

Reducing Python SDK size (https://github.com/Azure/azure-sdk-for-python/issues/11149) will certainly improve the installation time of Azure CLI.

Do we have any update on this? It takes more than 800s to install azure cli in Github Runner

Microsoft owns dotnet that is able to build awesome CLI tools and could help to reduce the size of the executable as well as produce a self-contained app:

https://github.com/spectreconsole/spectre.console
https://github.com/gui-cs/Terminal.Gui

Other options could be Go or Powershell. Python was a weird choice for this tool. It makes it even weirder when different teams within Azure build tools using their own stacks, e.g. https://github.com/Azure/static-web-apps-cli/
It makes us, the end users, to download a bunch of dependencies that we did not sign up for.

Just installed the latest release on a powerful windows 11 workstation and it takes FOREVER. It's still running. I don't understand how I can install office or solidworks faster than a CLI. This install time really needs to be improved when it updates frequently.


Deliver test images to CAPV nodes to avoid rate limit issue

Increase the disk size of CAPV nodes for image storage.
Deliver test images from the image node to CAPV nodes.

/test-all

/test-all

@XinShuYang Can we move this forward? Is it helping bypass rate limiting for pull?

@XinShuYang Can we move this forward? Is it helping bypass rate limiting for pull?

Sure. I believe this workaround can resolve the current rate limit issue. Since we've logged into the Docker account on the image node, there should be no pull rate limit when pulling images on this node. We can then distribute the necessary images to any new created nodes in the CAPV cluster.

/test-all

/test-all

/test-all

/test-all

Sure. I believe this workaround can resolve the current rate limit issue. Since we've logged into the Docker account on the image node, there should be no pull rate limit when pulling images on this node. We can then distribute the necessary images to any new created nodes in the CAPV cluster.

There is a limit for authenticated users, it's 200 pulls per 6 hour period. If we can get our Sponsored OSS status back, then there will be no limit.

@XinShuYang all the Jenkins jobs have been stuck waiting for an executor

The Sonobuoy test is stuck because its image pull policy is still set to Always...


HADOOP-16332. Remove S3A dependency on http core.

Contributed by Steve Loughran.
Change-Id: I53209c993a405fefdb5e1b692d5a56d027d3b845

Tested: S3 Ireland w/ DDB and versioning

@bgaborg @ben-roling

FWIW that new test is slow:
Tests run: 135, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 334.725 s - in org.apache.hadoop.fs.s3a.ITestS3ARemoteFileChanged

I know its better in parallel, but if there was a way to reduce the option space or test case setup/teardown costs that'd be very beneficial

full test run completed; one test timeout. Filed https://issues.apache.org/jira/browse/HADOOP-16333

Btw, you may already know this, but httpcore is currently a transitive, provided scope dependency via hadoop-common.
Whether it is really needed for anything that hadoop-aws does, I don't really know.  There's a good chance it isn't I would guess.
Nonetheless, I support the idea of limiting dependencies and have no objection to this change.  I wasn't sure about it when I added it in the first place and tried to call it out on one of the reviews but I think it slipped through the cracks.
Something else -- org.apache.http.HttpStatus is also included in aws-java-sdk-bundle.  I don't know how you feel about making reference to it given that?  You could potentially delete the httpcore dependency and still use HttpStatus due to that.  It does feel odd to depend on it coming from there though so using an internal constant still feels reasonable.
One last thing - ITestS3AConfiguration also refers to org.apache.http.HttpStatus.  Do you care to remove that reference as well?

the AWS bundle should only be including that http status as shaded, and so we should treat it as private. And yes, we should cut it there. I'm more worried about production dependencies than test ones though.
I did check through the IDE for httpcore use but could only see it in swift

+1 to the idea in general. There is that reference to HttpStatus.SC_MOVED_PERMANENTLY as well - maybe we should define these in Constants?

I'll take the +1 as clearance to commit.
If we are to pull these in (and there's a case, given their hard coded use in places), we should put them in org.apache.hadoop.fs.s3a.InternalConstants

merged; closing


Missing cv::viz::Viz3d::showWidget method

It doesn't get generated because one of its argument types Affine3 is currently not ported. It's a template class and those are currently need to be implemented manually.

Fixed in 0.31.0


onnxruntime-genai: init at 0.2.0-rc4

Description of changes
This PR adds microsoft/onnxruntime-genai library
This library provides the generative AI loop for ONNX models, including inference with ONNX Runtime, logits processing, search and sampling, and KV cache management.
I'm not really a C or python person, so this code was largely adapted from existing onnxruntime package. Not sure if I should include original maintainers.
While building the library I was faced with some weird issue where resulting wheel folder won't have write permissions and the only workaround I was able to find was to remove these steps via patch and perform them manually in postbuild
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

the package works and I can run phi3 model on CPU, but I haven't figured out the CUDA part just yet


Hidden classes

We have hidden fields that are skipped during lifting. We should have hidden classes whose objects are skipped as well. Syntax:
hidden class C(Int D) end

A hidden class can only have hidden subclasses.
Every field of a non-hidden class that has a hidden type, must be hidden as well.
Two points should be discussed:

How should hidden classes with a non-hidden superclass be treated during lifting?
Should we have hidden objects as well? This would mirror the structure of models and roughly have the following syntax: D d = hidden D();

Should we have hidden objects as well?

No strong opinion on that one, except that it would make the formal semantics of smol semantic lifting slightly more complex.
Concretely, instead of a predicate hidden(C), you'd have to handle the object case as well -- hidden(C(o)) \vee hidden(o)

The hidden modifier for fields is misnamed and not implemented at the master branch.

We decided to not implement hidden for classes:

For ISSA, it suffices to use it on field level for modeling in many cases, and it messes with the type system and ontology (cf. polymorphic lists where some object/subclasses are hidden, what are the axioms for prog:List_content?)
For ESSA, one can blacklist classes from lifting, like in Anton's work.

Figuring out how such a feature would interact with the type system and axioms would be a possible smaller project.


running the basic-demo manifest file results in error: CSV export criteria is not found in output path. Please append it after --output <path>#

Describe the bug
Trying to run a manifest file with the instructions in the readme results in the error:
CSV export criteria is not found in output path. Please append it after --output <path>#
To Reproduce
Steps to reproduce the behavior:

Install framework and plugins
Copy the contents of the assim-demo.yml file to your project.
Run assim-demo.yml:

ie --manifest manifest-files/manifest.yml --output manifest-output/manifest-out.yml
Receive error:
CSV export criteria is not found in output path. Please append it after --output <path>#
Expected behavior
Pipeline runs appropriately.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.

Hi - this error probably results from having the CSV option configured in your manifest file, but no metric specified on the command line.
If you are providing, e.g.
outputs:
  - csv

in your manifest, you also need to specify which metric you want to export by adding a hashtag and the metric name to the  CLI command, e.g. to export carbon to csv:
ie --manifest manifest-files/manifest.yml --output manifest-output/manifest-out#carbon

or remove the csv option from your manifest

Thanks!


set_default_tensor_type necessary in every test file

This is a bug, but everything is working because we are setting
# use cpu by default
torch.set_default_tensor_type("torch.FloatTensor")

in every test file file in /tests/ in order not to brake some cpu / gpu computations down the line. We need to investigate what exactly goes wrong here and how we can set the default tensor type globally.

Adding it to tests/conftest.py should work:
https://docs.pytest.org/en/2.7.3/plugins.html?highlight=re#conftest-py-local-per-directory-plugins


feat: Add parameter to allow error printing suppression

Allow for _send to fail silently without printing the error message. Often it is useful to handle (and print) the error outside the _send function. This commit adds a print_err argument (defaults to True), so to suppress the error printing one can simply set this to False.
This should be especially useful if more sophisticated error handling and logging is implemented to customize the errors without having prints that are neither formatted nor have any debug level associated to it.

Just saw that there are some PRs that go into the same direction (#16, #19) so there is need for such a solution. I would propose to user logging (+ use of log levels) as in #19, as it is part of the Python standard library.


Issue/2880 resource deps loading (#2969)

Pull request opened by the merge tool on behalf of #2969

Merged in 89f9b0bf29229b917fcca652a97ca3414d9254fa


Deprecate Firebase pod, Firebase module, and Firebase.h

Firebase has historically enabled all public APIs for all installed products to be available via importing the Firebase module or Firebase.h.  This is implemented via preprocessor commands in Firebase.h along with some fake module infrastructure.
As Firebase becomes more Swift-centric, it's not clear we can continue supporting that functionality since Swift does not allow similar preprocessor logic and its modules would require all dependencies to be built - defeating the purpose of only installing/building what is needed.
As a result, starting the next major release, Firebase users will need to import a Firebase module for each Firebase product used.
Let us know if you have any concerns about this proposal or suggestions for alternatives.

Could you add some screenshots or snippets for future references?

@emmanuel-montoya Yep, we'll do a full docs/samples/snippets scrub if we implement this.

Hello, @paulb777. Are you planning to implement this feature?
I replaced internal links to several Firebase/s so let me know if it is good to go on.

Thanks @a-25! We do plan to implement, but not until our next major release, which isn't yet scheduled.  It will likely be sometime between the spring and fall of this year.  Once we get closer, we'll evaluate and merge these changes.

Perhaps, we should keep the Firebase pod even without the module to ease transition and beta version specification?  cc: @ryanwilson

Based on experimentation and https://developer.apple.com/documentation/swift/imported_c_and_objective-c_apis/importing_swift_into_objective-c, I'm not able to find a way to check for existence from Swift Package Manager. #import "FirebaseFunctions-Swift.h" is only visible from the current module. Otherwise a module import is needed and there doesn't seem to be a corresponding directive in Objective C to the Swift canImport

Swift Forum question at https://forums.swift.org/t/canimport-for-objective-c-clients-of-swift-packages/55294

#9333 demonstrates a way to use the Firebase pod for CocoaPods with its Firebase.h. If we can find a similar solution for Swift PM, we may be able to keep the Firebase pod. cc: @a-25

@paulb777, do you see any advantage of keeping Firebase pod? I think it could be technically removed.

@a-25 The major advantage to keeping it is to avoid disruption to existing Firebase users who reference it in their Podfiles and import statements.

@paulb777
As I suppose, it will still available for the last released version. So if it is a reference in a Podfile, and the last released version is X, one will have the maximum X version in Podfile.lock. To upgrade further Firebase pod should be removed. So I wonder what disruption could occur. Do I miss anything?

True, but we want to make it as easy as possible for everyone to keep using the latest version.
Requiring edits to Podfiles and many .m files will likely keep more people on old versions.
One option is to continue support for CocoaPods, but not for Swift Package Manager.

We now expect to keep these working for the most part in Firebase 9. CocoaPods should maintain support.
We should still scrub our docs and samples to top using the Firebase pod, the Firebase module and Firebase.h. Assigning to @morganchen12 to review.

List of places that need to be updated, off the top of my head:

[ ] Import snippets across getting started guides
[ ] Imports in Console getting started flow
[ ] Imports in quickstarts and FirebaseUI

@morganchen12 Please update the check boxes above.

Docs CLs submitted.


Model may capture synthetic methods during export

It all starts with the following test failure on Jenkins:
wrappedMultipleItems(hudson.model.ApiTest)  Time elapsed: 15.874 sec  <<< FAILURE!
org.junit.ComparisonFailure: expected:<...><name>test1</name><[]/root>> but was:<...><name>test1</name><[name>test0</name><name>test1</name><]/root>>
at org.junit.Assert.assertEquals(Assert.java:115)
at org.junit.Assert.assertEquals(Assert.java:144)
at hudson.model.ApiTest.wrappedMultipleItems(ApiTest.java:100)

After looking through the Api class it became apparent that something must be going wrong during:
p.writeTo(bean,pruner,Flavor.XML.createDataWriter(bean,sw));

This was printing the test0 and test1 jobs twice into StringWriter, so I've started to investigate the recursive logic of writeNestedObject and after a few iterations it turned out that the model itself is incorrectly generated: Jenkins had two MethodProperty with name "jobs", one was referencing a List<TopLevelItem> getItems method, the other was referring to a Collection getItems method.
When debugging the model generation I could see both methods, but I could see that one method had modifier of 1 (public), whilst the other had 4161 (synthetic public volatile). Now I'm not that good at JVM internals, but I can only guess that this synthetic method is only there to make life easier for the JVM.
Anyways: the following little change appears to resolve the test failure in Jenkins. So far I could only see this test failing on OSX, so this test failure may be platform dependent, but I feel having this fix in place could simplify life for developers on OSX.

@aldaris It seems the PR was not attended by jenkins.ci.cloudbees.com. Could you close and & open the PR? So you'll force the build again.

Well that did not seem to make any difference :/

@aldaris Indeed. I'm going to investigate why this project is not in jenkins.ci.cloudbees.com

CI job

Doubt that the test would only fail on OS X. More likely a random issue: Class.getMethods in Java 7+ returns items in no particular order. If so, you should be able to reproduce on any platform by either using Collections.reverse, or not.

@jglick thanks for the info, haven't heard of this getMethods behavior before.
I'm just wondering if this fix could potentially improve Jenkins' performance when applied: exporting wouldn't call methods twice to get the same values, and there would be less serialization/deserialization overhead for the /api calls.

See https://github.com/stapler/stapler/pull/55 and JENKINS-26775 for more details.

The #55 PR looks more appropriate to me, and has unit test as well, I'm closing this PR in the hopes that somebody will merge #55 (soon).


image from newtork

Hi,
Any plan to load image from network with sprite?
thanks

Sprites on Flame are loaded based on a dart:ui Image class, so it is pretty easy to obtain an image from the network, without the need of Flame.
You just need to use a http package like the http or even Dio package, than you can use the decodeImageFromList from the dart:ui, and then just pass it to your Sprites. So I don't really think there is much thing need on the Flame side for this. Or do you have any suggestion?

closing due inactivity


stack issues with non trivially copyable types

Required information
The stack is movable and copyable by default. The raw data array is copied implicitly in the compiler generated function which does not take the copy or move operations into account as well as the destructor when the stack is destroyed or pop'ed elements are overridden with push.
This can be solved by explicitly implementing the copy and move operations as well as the destructor to handle non trivially copyable types inside the stack.
Another approach could be to restrict the stack to trivially copyable and destructable types.

cc @elBoberido


fix: regeneration of graphql docs for a new version of github.com/99designs/gqlgen

Graphql docs require of regeneration after upgrading of github.com/99designs/gqlgen to version v0.17.32

Codecov Report

Merging #241 (528bbf4) into master (4275987) will not change coverage.
The diff coverage is n/a.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files

@@           Coverage Diff           @@
##           master     #241   +/-   ##
=======================================
  Coverage   34.05%   34.05%
=======================================
  Files          41       41
  Lines        1301     1301
=======================================
  Hits          443      443
  Misses        836      836
  Partials       22       22

Flag
Coverage Δ

unittests
34.05% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Continue to review full report in Codecov by Sentry.

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


Fix installment struct

Hi, I would like to fix certain things that I found when I use this repo.

a missing code on this struct InstallmentTermsDetail
on this field Terms there is have a different type, Term must be an object instead of array of object
https://snap-docs.midtrans.com/#request-body-json-parameter

Fixed https://github.com/veritrans/go-midtrans/issues/61


Dynamic workers based on RAM usage

Description
Change the number of workers based on RAM availability
Use case / motivation
I would like for mapply number of workers to be dynamic with memory intensive operations or at least to consider RAM availability
Related Issues
I have detailed the issue in #43. The main complaint there is that there is no message telling me that not sufficient RAM

Hi @thoughtfuldata 👋
This sounds like a cool feature! However in reality I think it's near impossible to estimate RAM usage in advance, without running through it (and crashing) at least once beforehand.
Currently, the amount of workers is calculated in advance, and I think dynamic pool resize would mean a lot of new (low-level) code to write and maintain.
In these scenarios, I think your best bet is to run a small sample and then adjust n_workers accordingly for the big run.
Hope that helps!

Probably a duplicate of upstream issue https://github.com/uqfoundation/pathos/issues/243


[Request] Paginate a laravel Collection

It would be cool, if we could paginate collections.
Why we need this: If you make up a custom collection or need sorting/filtering items, that can not simple be done directly via the database.
EG: My user has clients which have projects which have times. To get all times I have about the following code:
$clients = Auth::user()->clients();
$single_times = array();
foreach($clients as $client){
    foreach($client->projects as $project){
        foreach($project->times as $time){
            $single_times[] = $time;
        }
    }
}

$times = new Illuminate\Database\Eloquent\Collection($single_times);
$total = $times->count();
$pp = 5;
$times = Paginator::make($times->toArray(), $total, $pp);

However $times is now an array and contains all times (not only 5).
Suggestion: make a Collection paginatable like: $some_times = $times->paginate(5);

I wrote a gist for a way to do this using a Collection macro. Hope it helps in those situations when a model isn't the right solution

It would be easy for soring based on sorting based on external data like google map distance matrix API result

Thanks @simonhamp, your gist saved my day!


Refactor spec runner CLI for extensibility

Introduce Spec::CLI class as new entry point of Spec runner. This new interface makes more easy to extend runner's behavior and options by extensions or formatters, overriding #setup and using previous definition:
# TAP formatter extension (spec/tap.cr)
require "spec/cli"

class Spec::CLI
  def setup
    # important: include previous definition!
    previous_def

    # extend with new option
    parser.on("--tap", "use my own TAP formatter") do
      options.default_formatter = Spec::TAPFormatter.new
    end
  end
end

# my spec_helper.cr
require "spec"
require "spec/tap"

With these changes will be possible to extend Spec runner with other formatters or extensions.
It provides 1:1 behavior found in spec.cr, but it can be improved more easily moving forward (ie. register formatters, etc.)
Ref. #5662

This is exactly the feature I was thinking about yesterday :smiley: (spec's CLI extending) Nice PR!

This would be useful for #5671 as well.

I've pushed additional changes based on the feedback provided. I would prefer to squash the commits before merging (once this gets approved).
Cheers.

I don't see the point in the Options class, you just twiddle bits in a class just to copy the exact same settings to Spec.

Spec.* is global state, it cannot be tweaked during tests without introduce issues. So Spec runner itself cannot be tested.
The introduction of the Options class is a first step for later introduce further changes to Spec runner itself, like, not having a global state? Maybe initialize by an Options instance.

In fact I don't see much point in this whole PR - what are the usecases for monkey-patching spec options parsing?

I can list a few cases:

Be able to fully test spec runner without expensive shelling out
Add test coverage to a piece of code that is bundled within Crystal itself
Be able to extend it by introducing new formatters or additional options not present in stock Spec runner.

The whole idea here is to avoid monkey patching and offer a framework to others introduce additional changes without having to wait an entire release cycle.
This is the purpose of this change, as mentioned in the PR description, relates to #5662 and other issues/PR associated.
Apologies if the whole purpose of this PR wasn't clear from the description, hope the above provides the proper background.
Cheers.

Spec.* is global state, it cannot be tweaked during tests without introduce issues. So Spec runner itself cannot be tested.

That's the problem.

The introduction of the Options class is a first step for later introduce further changes to Spec runner itself, like, not having a global state? Maybe initialize by an Options instance.

I'd rather have the Spec instance be the Options instance.

That's the problem. I personally think that should come before or in this PR.

I have to disagree with that. In my personal experience and monitoring PR requests and process at Crystal, there is a tendency for huge PR to age without review for long time.
I would rather get smaller, digestible-size PRs that progressively drive us to that objective than a single, 400+ lines PR that sits for months in the pool without nobody looking at it.
Of course, there are downsides like in this case: a smaller PR that doesn't fulfill everybody expectations, but there isn't a perfect PR, like there isn't a perfect language, library, etc.

I'd rather have the Spec instance be the Options instance.

That is great to hear, and perhaps will be great if your ideas get drafted somewhere, like a RFC issue where others can weight in and help design a solution for this.
In the meantime, this is my little contribution towards a better outcome.
Cheers.

I'd suggest to make this PR a little bit smaller and remove the Options class. It's not necessary to have a separate class for that. If that happens to change at some point, it can always be introduced later.
Also, I'm not sure if the class should be called Spec::CLI - why not simply call it Spec?
I'll point out a few simplifications in the line comments.

Thank you @straight-shoota for the feedback and the willing to get this moving forward. I'm a bit limited on time the upcoming days but might take a look soon and even better send a proper RFC on some of the architecture changes that will make the work on this PR obsolete.
Cheers.


Add git tag and git commit to parameters

Prefix
Hi guys!
Firstly, big thanks for this project as it helped me setting up stable CI/CD workflow via Gitlab and Bitrise.
Secondly, the issue I am submitting is a suggestion, which I already implemented for myself. It relates to the way Bitrise clones project.
Suggestion
As title of the issue says, I propose to add options to refer repository by either tag or commit hash, which is officially supported - check Bitrise API) and their manual on referencing repo by tag or commit hash.
Reasoning
My personal use case, that has driven me to implement this functionality, is that I wanted to trigger certain Bitrises's  "beta" workflow for my iOS project, only when pushing new tag to the repo, as I got used  (therefore, Bitrise should reference project by this exact tag). Current state of Gitrise project did not fullfill my needs, as it only allows to reference repo by branch, which instantly limits opportunities to trigger Gitlab's pipeline only by merge requests and pushes, because to take branch name in pipeline's job, it should be present in predefined variables (otherwise you must write some kind of branch-name-extracting script before running gitrise.sh). Gitlab's Predefined Env Vars says:

...
$CI_COMMIT_REF_NAME - The branch or tag name for which project is built
...
$CI_COMMIT_BRANCH - The commit branch name. Present only when building branches.
...

Which means that branch name is not built-in functionality.
Also, as I decided to implement tag-referencing functionality, the subsequent decision was to implement referencing by commit_hash, as it relates to same section of build_params of Bitrises's build trigger API and combined with both branch and tag parameters completely covers repo referencing configuration for this endpoint.
Implementation

Added two parameters to be parsed when executing gitrise.sh:

-c or --commit - to set the Git Commit Hash to reference repo by
-T or --tag - to set the Git Tag to reference repo by (capital T is used to not interfere with -t flag which enables test logs)

Included description of these params to usage() function (triggered by zero params or -h flag)

Extracted "build_params" content of json payload of request to trigger build to script's variable $BUILD_PARAMS in order to separate configuring build parameters from this step

Created a function that prepare_build_params() that sets up this variable

Made parameters --commit, --tag, --branch mutually exclusive to and prioritized them in order.

Contribution checks

[x] Ran shellcheck against my version of script
[ ] Written tests

Postfix
I already implemented for my purposes and so I am looking forward to adding this functionality to Gitrise project. In case owners of this project are interested in this issue resolving, I will setup tests and submit a pull request.
Thanks!

#26

Hey @be4rd,
Sorry for the long delay. A lot has been going on and I just managed to go through the open issues.
First, thank you for your interest in Gitrise! Glad to hear it has been helping you as well!
Also, thank you for your detailed explanation of the new feature. It does make sense and I was wondering if you are still interested in opening a PR for it.

Hey @alexist, I appreciate you submitting the PR. However, @be4rd 's solution is more complete and fits our project a little better.

Hi @alexist,
Glad to hear Gitrise is helping you as well!!
Regarding the different building options: tag, commit, and branch, I should mention that you can pass as many of them as you want, but Bitrise will only use one of them and that makes sense.  When cloning a project, Bitrsie will choose the checkout option according to its priority list which is as follows: commit, tag, branch. This means if you pass a tag and a branch to Gitrise, Bitrise will only use the tag. Even if you pass all three of them and they all have valid values, Bitrise will use the commit. But then again, you should only pass one of these options to Gitrise.
Once again, thank you for opening the PR. Because of all the interest in this feature, I looked into it myself and updated Gitrise to support different build options. You can now trigger a build for a branch, a commit, or a tag!! For now, the updates are only available on develop branch. Will release a new version of Gitrise tomorrow. In the meantime, feel free to try it out and let me know how it works out for you!!

Hi,
unfortunately, passing empty tag to bitrise has a side effect that i didn't see at first. When you want to filter builds by tag on bitrise builds page, you will see builds with empty tag.
The proper way seem to had tag only if tag is not empty, this is why i ended with this code :
    if [ -n "${TAG}" ]; then
      payload=$(echo "$payload" | jq  ".build_params +={\"tag\": \"${TAG}\"}")
    fi

About branch + commit option, i also have a requirement to filter builds by branch on bitrise. But my pipeline trigger build by commit hash to handle concurrent build on same branch. If i didn't set branch option, i don't think i can filtert by branch (a commit hash can be in many branches).
(I'v not yet tested your change)

Hi @alexist ,
I’m not sure how exactly you are intending to use Gitrise. But to clarify how it should be used with different build options, I’ve updated the README and have added some example use cases there. Hope you find that helpful!
I’m closing this issue since it was originally opened to request support for building a tag or a commit and that is done now. If you are still having problems using Gitrise or are interested in a new feature, please open a new issue so that we can discuss it there.


Enhancement request: process open public repositories without authorization

Hi!
I would like to use issue-graph on our open public git repository with lots of interconnected (referenced) issues but required authorization prevents me to do that (i have no permissions for that).
AFAIK https://developer.github.com/v3/issues/ allows one to collect all the issue-related information for a open public repository...
Therefore I wonder why does this application really requires all those permissions?
Would it be possible to allow issue-graph to work with open public repositories directly without any authorizations, e.g. similarly to https://9-volt.github.io/bug-life/ ?
Thank You!

Ok, i know about the GitHub's requests rate limit... but would be enough in many demo cases


When we start jupyterlab from jupyterhub we get Missing required environment $JUPYTERHUB_SERVICE_URL

Jupyterlab is not loading
    Traceback (most recent call last):
      File "/venv/lib/python3.11/site-packages/jupyterhub/singleuser/extension.py", line 274, in wrapped
        r = f(self, *args, **kwargs)
            ^^^^^^^^^^^^^^^^^^^^^^^^
      File "/venv/lib/python3.11/site-packages/jupyterhub/singleuser/extension.py", line 472, in load_config_file
        raise KeyError("Missing required environment $JUPYTERHUB_SERVICE_URL")
    KeyError: 'Missing required environment $JUPYTERHUB_SERVICE_URL'

We may need to update helm:
helm repo update
helm upgrade --cleanup-on-fail vl-laserfarm jupyterhub/jupyterhub --version=2.0.0 --values vl-laserfarm.yaml -n vl-laserfarm


Add Powerline Symbols Support

Use Noto Mono for Powerline font to support Powerline Symbols.
As mentioned at issue #16.

The proper place to add this would be: /src/css/style.css since the "npm run build" script references the files in /src and builds the scripts which live in /public.
This is not something that I want to bring in as a feature, but it's left up to the individual to customize /src/css to their linking and "npm run build" to compile. It's very nice though.

Closing. Individual preference, can be easily added by locally modifying files in /src/css files and rebuilding. May look into providing an alternate method to support CSS customization in the future.


Fix bug preventing default attributes if instance attributes not defined

This simple PR just removes a bad check, that will incorrectly abort initialization of attributes just because the instance attributes "holder" object (i.e. __attributesRaw) is not defined. Even if the instance attributes object __attributesRaw is not defined, default attributes should still be assigned to a newly created script instance. In addition, the check is also redundant since it is being done (correctly) later in the same function.

Hm.. I'm really liking that you actually go deep into guts of engine, and getting a grasp on things!
Will have a look into that a bit more precisely. Reasoning of that check was to prevent that method from executing unless there are really a need to set attributes, and defined __attributesRaw was an indicator of that. There are quiet a few scenarios where __initializeAttributes is called from, and will need to test all those cases first to make sure we do not do unnecessary initialising of default attributes multiple times, as well as attributes are still available when they are needed.
If there were a particular problematic scenario that lead to this change?

Thank you for your kind words, @Maksims!
I've actually written a complete Unity3D prefab to PlayCanvas converter (including dependencies). I work for Animech Technologies, I believe some of your colleagues have meet some of mine :)
Anyway, the check I removed in the PR, is causing default attributes for scripts instantiated in run-time (using entity.scripts.create('MyScript')) to not be assigned. Obviously a possible workaround is to just pass a empty custom attributes like entity.scripts.create('MyScript', { attributes: {} }), but that is not a obvious workaround and shouldn't be necessary IMHO :)
I understand the optimization aspect. Another way to fix this scenario more specifically would be to change the following line in /src/framework/components/script/component.js:

attributes: args.attributes || null -> attributes: args.attributes || {}

I can update my PR. What do you think?

I need to test few things, there were complicated scenarios that lead to this reason, and they are that you can use default values for example "resource_id" for entity type attribute, or asset id, but you can't guarantee that entity or asset will be available during creating of script instance on script component, as that happens way before final initialisation process. Which then leads to racing condition of what gets first and where.
That's why there was a decision to delay attributes initialisation and that delaying depends on case of creating script, for example if it is a cloning of entity with script and children scripts, or it is an initial initialisation.
So I will test many cases next week, and will let you know about impact of this :)

I've change the PR to use the alternative solution I proposed, i.e. just changing this line:

attributes: args.attributes || null -> attributes: args.attributes || {}

I'm closing this PR as it is no longer a priority for us.


Unable to delete volume - UI

I can not delete a volume.

but I can manually remove the volume from the backend use command
kubectl -n longhorn-system delete volumes.longhorn.io  ,

I find the longhornio/longhorn-engine:v0.7.0 state is Deploying.

kubectl describe engineimage.longhorn.io ei-ec95b5a -n longhorn-system :

Name:         ei-ec95b5ad
Namespace:    longhorn-system
Labels:
Annotations:
API Version:  longhorn.io/v1beta1
Kind:         EngineImage
Metadata:
Creation Timestamp:  2019-11-19T05:09:21Z
Finalizers:
longhorn.io
Generation:        1
Resource Version:  24826987
Self Link:         /apis/longhorn.io/v1beta1/namespaces/longhorn-system/engineimages/ei-ec95b5ad
UID:               1f1f4748-51ed-4d63-86ec-3905b64a2f60
Spec:
Image:  longhornio/longhorn-engine:v0.7.0
Status:
Build Date:                  2019-11-15T03:47:06+00:00
Cli API Min Version:         2
Cli API Version:             2
Controller API Min Version:  2
Controller API Version:      2
Data Format Min Version:     1
Data Format Version:         1
Git Commit:                  0b3aa9c4e2976240a1dc5316a10c16f72b3580e9
No Ref Since:
Owner ID:                    k8s-worker02
Ref Count:                   6
State:                       deploying
Version:                     v0.7.0
Events:

@awlleon Hi, have you figured out the reason?


Enum. Convert string properties to enums where appropriate

Most restricted strings could be converted to enums.
https://github.com/strusoft/femdesign-api/blob/71ef4cce6d0aba528d1d74cefdfcbdfaa780c8ad/src/GenericClasses/RestrictedString.cs
Used by the user (C#, Dynamo, Grasshopper)

[x] Country
[x] LoadCaseType
[x] LoadCaseDurationType
[x] LoadCombType
[x] CmdUserModule
[x] ForceLoadType
[x] DirectionType
[x] SfRcFace
[x] VerticalAlign
[x] WireProfileType
[x] SteelMadeType
[x] ~EurocodeType~ Leaving this as a string property
[x] ~EdgeType~ Might be better to just use different geometry classes instead of having an enum that must correspond to the number of points and angles etc. provided.

Used internally
Enums not intended for users should be set to internal to reduce confusion.

[x] PanelType
[x] BarBucklingType
[x] DetachType
[x] LoadDirType
[x] SlabType

Note: Converts string values to enums for Grasshopper and Dynamo. This means the deconstruct methods must convert them to back to string values before returning values to the main program.

@andosca Restricted string for LoadCaseType includes the following "seis_max", "deviation", "notional". But I have not been able to create these in the FemDesign GUI. Should these have an enum and if so, what do they represent?

Decision to make for dynamo:
Components take a string input argument that gets converted to an enum or Dynamo default implementation for enum with combonents for each enum value.

@andosca Restricted string for LoadCaseType includes the following "seis_max", "deviation", "notional". But I have not been able to create these in the FemDesign GUI. Should these have an enum and if so, what do they represent?

These load case types are not directly accesibly to the user in the GUI but can be set to load cases generated by macros in, e.g deviation and notional:

A struxml-model might contain these load cases so they should be implemented:
https://github.com/strusoft/femdesign-api/blob/1daa2907062f13a66dcf6bb9652ddb7bc51eaacc/FemDesign.Core/Loads/LoadCaseTypeEnum.cs#L16-L19

@andosca Restricted string for LoadCaseType includes the following "seis_max", "deviation", "notional". But I have not been able to create these in the FemDesign GUI. Should these have an enum and if so, what do they represent?

These load case types are not directly accesibly to the user in the GUI but can be set to load cases generated by macros in, e.g deviation and notional:


README

README
User story
As a Boot camp student
I want the prework notes to be on a satructered webpage
So that I can easily find and read the information
Acceptance Criteria
GIVEN the pre work project Repositroy,
WHEN I view the README for the Repository,
THEN I can see a proffesional README that provides information on the project and how to use it.

This issue has been resolved.


feat: adding basic workflows for gpg and ssh keys

@chaychoong are you in our Discord server? If so what's your username so I can add the contributor role?
https://discord.gg/warpdotdev

@elviskahoro chay#2987 thanks

@chaychoong  Friendly ping on this--mind addressing the open comments on this PR or close this out? I'm trying to reduce the number of stale PRs. Thanks so much!

Closing this since there's been no activity. Feel free to reopen!


Fix requires_grad of input must be true for activation checkpoint layer in pipeline train.

mechanism FYI https://github.com/prigoyal/pytorch_memonger/blob/master/tutorial/Checkpointing_for_PyTorch_models.ipynb?short_path=e1e8ee7#L282C244-L282C257
For discrete input, could make activation for the embedding layer.
For image input,  no need to calculate and save grads for input.
Have verified on megatron-deepspeed train/cifar10 train ut (test_pipe. py). Under the same seed, the data of parameter and gradient updates is exactly equal to before this addition.
It can reduce  small memory on rank0  (stage0 contains embedding layer)

Thank you for submitting this PR, @inkcherry! Is the goal of this to stop creating gradients of inputs when it is unnecessary?
Can you also clarify intentions of some changes?

thanks for your review and apologies for not explaining clearly.
Yes, currently,  requires_grads of input of the first checkpoint layer must be true. I think this is a limitation, and the current code may have 2 following logic to work around this limitation in two scenarios.  please correct me if I'm wrong.
1 For image input, set requireds_ grad=true  for input from the dataset, this will calculate and save grads for the input image, which I think may cost memory and computing time with large size input. related issue.
https://github.com/AGI-Collective/multimodal/issues/16
2 Secondly, for LLM, notice the comment https://github.com/microsoft/DeepSpeed/blob/64c670ef021118ed42a98d5dde249f35878a07a7/deepspeed/runtime/pipe/module.py#L621, it  hooks transformer layer(force make embedding layer as a non-checkpoint layer,
which take input with requires_grad=False and ouput tensor with requires_grad=True).
For this limitation, we could pass a dummy input that requires grad but isn't necessarily used in computation  FYI.
https://github.com/prigoyal/pytorch_memonger/blob/master/tutorial/Checkpointing_for_PyTorch_models.ipynb?short_path=e1e8ee7#L282C244-L282C257  , here wrapping a ``WrapModule``` at the first layer to achieve this.

@tohtana , I've made some changes to the code. Any suggestions?  would appreciate your feedback.

Hi @inkcherry, thank you for the fixes. Overall, this looks okay to me.
On the other hand, I just reviewed #4118 and this might solve a part of the issue you addressed. I didn't notice this PR until very recently, and I'm sorry that I couldn't share it with you.
We want to merge the PR, and I am wondering if we can simplify the changes in this PR using the new features proposed in #4118. Can you share your thoughts on this?

@tohtana, yes I agree, https://github.com/microsoft/DeepSpeed/pull/4118 is great！
I could try based on  https://github.com/microsoft/DeepSpeed/pull/4118 merged when it is merged.

@inkcherry, #4118 is now merged. Also, could you please add a unit test when you retry? Thanks!

moved to https://github.com/microsoft/DeepSpeed/pull/4224
close this one


Hydromt expects strictly a string when using to_raster

FloodAdapt version checks

[X] I have checked that this issue has not already been reported.
[X] I have checked that this bug exists on the latest version of FloodAdapt.

Reproducible Example
When running a scenario, it gives the error "Windowspath does not have endswith". Running every non-risk scenario should give this error
Current behaviour
gives an error
Desired behaviour
doesnt give an error
Task list

[] fix

Additional context
No response

Impeded by hydromt_sfincs issue #150

Should be fixed in hydromt_sfincs