feat: create pair and add liquidity on AMM in launch_memecoin function

Issue: Implement Pair Creation and Liquidity Addition in launch_memecoin Function
Description
We need to enhance the launch_memecoin function to include the creation of a trading pair and the addition of liquidity to an Automated Market Maker (AMM) platform. This process involves using the Memecoin contract's internal balances (both the memecoin itself and a counterparty token like ETH or USDT) to establish the initial liquidity in the trading pool.
Requirements

Pair Creation: Implement functionality within launch_memecoin to create a trading pair for Memecoin and a counterparty token (e.g., USDT, ETH) on the selected AMM platform.
Liquidity Addition: Modify launch_memecoin to use the internal balances of Memecoin (MT) and the counterparty token, which are sent to the Memecoin contract address, to add liquidity to the newly created trading pair.

Example Workflow

Memecoin (MT) is deployed at address 0xAA.
The owner sends 1000 MT tokens and 1000 USDC to address 0xAA.
The launch_memecoin function utilizes these internal balances (1000 MT and 1000 USDC) to add liquidity to the MT/USDC pair on the selected AMM.

Implementation Notes

Ensure that the function checks for sufficient balances of both tokens before attempting to add liquidity.
Consider gas optimization and security practices while implementing the liquidity addition process.
Implement error handling for scenarios where the pair creation or liquidity addition fails.

gm! please also @dubzn


[0.0.5] - Migrate to JDK 8

Try to adapt the project for running in JDK8. The SonarCloud doesn't allow to run it in JDK 7.

[ ] After migration, fix coding smell: https://sonarcloud.io/project/issues?id=Miuey_happytree&resolved=false&types=CODE_SMELL

There is a necessity to update maven for the 3.6.3 version to be compatible with Java 1.8 running the following command:
mvn package


Add Requirements

I understand "NOTE: The documentation is in progress.".
Even in that situation, the current README is not easy to understand for many people.
So I added Requirements.

You are our hero!
Thank you so much ✨


Checking which paths are ignored by Git cripples path searching performance

https://github.com/atom/fuzzy-finder/blob/59836e1a9ec39ec5c7a3ef305487f67f1f23388e/lib/load-paths-handler.js#L39
Disabling the line included above causes the searching of paths to go from 6000-7000ms to 2000-3000ms.
I am benchmarking by opening this project and the Linux Kernel in Atom. Although the Linux Kernel is an extreme case when considering #88 every improvement to path searching counts.
A proof of concept implementation with scandal seems to be able to drop the initial scanning time to 5000-6000ms and then 3000-4000ms for future searches.

I believe this has been improved substantially by #366 and will improve even further with #369 - please let me know if you think this issue should remain open.


Website example requires latest unreleased github version

Came across this project from your blog post, where the example given threw:
TypeError: hours_estimate() got an unexpected keyword argument 'include_globs'
I needed pip install git+git://github.com/wdm0006/git-pandas.git to get it to work.
On an unrelated note, it would be more convenient to be able to specify a set of subdirectories to limit results in addition to the include/exclude globs. It's not clear from the docs if including 'dir/*.py' will be smart enough to work recursively, but I assume not.

Thanks for the heads up, this project is long due for a release, I'll try to cut one before too long.  Using the glob syntax, dir/*.py will work 'recursively' in that it will include any file whose full path starts with dir/ and ends with .py, so dir/foo/bar.py and dir/baz.py would both be ignored/included.


Where is the i_TYPE macro defined?

Hi
Thank you for building this, it is a lovely library.
As I had just starting out to learning C (I know Rust, Go, Python and TypeScript), I am curious where is the i_TYPE macro defined, as it seems to generate i_type define macro and hence it is the type that has the data structures (maps, vector, etc) operate with.
Just wonder how this generic programming is being done.

Hi, you could find their definations in <stc/types.h> and  <stc/priv/template.h>

i_TYPE will be replaced by i_type in V5.0, so it is deprecated until it is removed.
You can define the container name/type by defining i_type NAME [, KEYTYPE [, VALTYPE]].
Or define i_type NAME and i_key KEYTYPE (and i_val VALTYPE for maps) separately.


getting a error in debian 8.6

apache 2.4.10
AH00526: Syntax error on line 51 of /usr/share/modsecurity-crs/optional_rules/modsecurity_crs_16_session_hijacking.conf:

Hi @broros,
Most likely this is related to an Apache configuration parser error. please try to add an space before or after the rule.


An index dimension mismatch problem was encountered

Thank you for your outstanding work
However, I have encountered a problem that I would like to ask you, which is that when writing the confusion matrix in the first verification step, the error shows that the index does not match.
The following is the error message:
root@autodl-container-138c41aa1e-268199cb:~/elgcnet# python main_cd.py
True
[0]
cuda:0
================ (Wed May  8 21:12:16 2024) ================
gpu_ids: [0] project_name: elgcnet_levir checkpoint_root: ./checkpoints vis_root: ./vis num_workers: 8 dataset: CDDataset data_name: LEVIR batch_size: 32 split: train split_val: val img_size: 256 n_class: 2 dec_embed_dim: 256 pretrain: None net_G: ELGCNet loss: ce optimizer: adamw lr: 0.00031 max_epochs: 300 lr_policy: linear lr_decay_iters: [100] checkpoint_dir: ./checkpoints/elgcnet_levir vis_dir: ./vis/elgcnet_levir
training from scratch...
lr: 0.0003100
0%|                                                                                | 0/14 [00:00<?, ?it/s]/root/miniconda3/lib/python3.8/site-packages/torchvision/transforms/functional.py:404: UserWarning: Argument interpolation should be of type InterpolationMode instead of int. Please, use InterpolationMode enum.
warnings.warn(
/root/miniconda3/lib/python3.8/site-packages/torchvision/transforms/functional.py:404: UserWarning: Argument interpolation should be of type InterpolationMode instead of int. Please, use InterpolationMode enum.
warnings.warn(
/root/miniconda3/lib/python3.8/site-packages/torchvision/transforms/functional.py:404: UserWarning: Argument interpolation should be of type InterpolationMode instead of int. Please, use InterpolationMode enum.
warnings.warn(
/root/miniconda3/lib/python3.8/site-packages/torchvision/transforms/functional.py:404: UserWarning: Argument interpolation should be of type InterpolationMode instead of int. Please, use InterpolationMode enum.
warnings.warn(
/root/miniconda3/lib/python3.8/site-packages/torchvision/transforms/functional.py:404: UserWarning: Argument interpolation should be of type InterpolationMode instead of int. Please, use InterpolationMode enum.
warnings.warn(
/root/miniconda3/lib/python3.8/site-packages/torchvision/transforms/functional.py:404: UserWarning: Argument interpolation should be of type InterpolationMode instead of int. Please, use InterpolationMode enum.
warnings.warn(
/root/miniconda3/lib/python3.8/site-packages/torchvision/transforms/functional.py:404: UserWarning: Argument interpolation should be of type InterpolationMode instead of int. Please, use InterpolationMode enum.
warnings.warn(
/root/miniconda3/lib/python3.8/site-packages/torchvision/transforms/functional.py:404: UserWarning: Argument interpolation should be of type InterpolationMode instead of int. Please, use InterpolationMode enum.
warnings.warn(
7%|████████████▊                                                                                | 1/14 [00:12<02:38, 12.23s/it]Is_training: True. [0,299][1,14], imps: 138.45, est: 8.62h, G_loss: 0.65767, running_mf1: 0.47853
100%|███████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 14/14 [00:37<00:00,  2.66s/it]
Is_training: True. Epoch 0 / 299, epoch_mF1= 0.50163
acc: 0.85369 miou: 0.44794 mf1: 0.50163 iou_0: 0.85272 iou_1: 0.04317 F1_0: 0.92051 F1_1: 0.08276 precision_0: 0.95535 precision_1: 0.05825 recall_0: 0.88812 recall_1: 0.14289
Begin evaluation...
/root/miniconda3/lib/python3.8/site-packages/torchvision/transforms/functional.py:404: UserWarning: Argument interpolation should be of type InterpolationMode instead of int. Please, use InterpolationMode enum.
warnings.warn(
/root/miniconda3/lib/python3.8/site-packages/torchvision/transforms/functional.py:404: UserWarning: Argument interpolation should be of type InterpolationMode instead of int. Please, use InterpolationMode enum.
warnings.warn(
Traceback (most recent call last):
File "main_cd.py", line 72, in
train(args)
File "main_cd.py", line 11, in train
model.train_models()
File "/root/elgcnet/models/trainer.py", line 332, in train_models
self._collect_running_batch_states()
File "/root/elgcnet/models/trainer.py", line 203, in _collect_running_batch_states
running_acc = self._update_metric()
File "/root/elgcnet/models/trainer.py", line 198, in _update_metric
current_score = self.running_metric.update_cm(pr=G_pred.cpu().numpy(), gt=target.cpu().numpy())
File "/root/elgcnet/misc/metric_tool.py", line 55, in update_cm
val = get_confuse_matrix(num_classes=self.n_class, label_gts=gt, label_preds=pr)
File "/root/elgcnet/misc/metric_tool.py", line 155, in get_confuse_matrix
confusion_matrix += __fast_hist(lt.flatten(), lp.flatten())
File "/root/elgcnet/misc/metric_tool.py", line 150, in __fast_hist
hist = np.bincount(num_classes * label_gt[mask].astype(int) + label_pred[mask],
IndexError: boolean index did not match indexed array along dimension 0; dimension is 65536 but corresponding boolean dimension is 1048576
There is another warning message:
UserWarning: Argument interpolation should be of type InterpolationMode instead of int. Please, use InterpolationMode enum.
warnings.warn(
I sincerely hope to receive your reply

Hi,
As training step is completed successfully and its scores are computed without error, so it seems that there is no issue with the code. Instead check with the dataset images, especially check that ground truth labels are single channel. If your ground truth labels are 3 channel images then you can add [:,:,0] at the end of line 118 in CD_dataset.py.
Hope it helps.

Thanks for the reply and clear explanation.
But it doesn't seem to be the problem with the dataset, I'm using the LEVIR dataset, which labels images as 1024 × 1024 single-channel grayscale images，After I added [:,:,0], it got the following error
0%|          | 0/56 [00:00<?, ?it/s]True
0%|          | 0/56 [00:00<?, ?it/s]
......
......
......
File "G:\elgcnet-main\elgcnet-main\datasets\CD_dataset.py", line 118, in getitem
label = np.array(Image.open(L_path), dtype=np.uint8)[:,:,0]
IndexError: too many indices for array: array is 2-dimensional, but 3 were indexed

Hi,
We used the pre-processed LEVIR-CD having image size of 256x256. You can either apply non-overlapped cropping on 1024x1024 sized images to get 256x256 sized images OR change the image size in main_cd.py file to 1024.

express my gratitude for your help，it works！

I really appreciate your help,
However, at runtime, it seems that a V100 graphics card can hardly meet the overhead of the network. Is your device multi-card parallel?
In addition, is the lightweight version mentioned in your paper also included in this project? How do you use and train it?
Thanks again for your patience.

I really appreciate your help,
However, at runtime, it seems that a V100 graphics card can hardly meet the overhead of the network. Is your device multi-card parallel?
In addition, is the lightweight version mentioned in your paper also included in this project? How to use and train it?
Thanks again for your patience,

I will recommend you to use 256x256 image size. You can do the non-overlap cropping of 1024x1024 sized image to obtain 16 sub-images of size 256x256. Otherwise, you can try with reduced batch size, and increase the kernel size and stride of pooling layers in attention.
Additionally, you can use the decoder with less parameters from the code below:
class LightHeadDecoder(nn.Module):
    """
    Transformer Decoder
    """
    def __init__(self, in_channels = [32, 64, 128, 256], embedding_dim=64, output_nc=2, align_corners=True):
        super(LightHeadDecoder, self).__init__()

        #settings
        self.align_corners   = align_corners
        self.in_channels     = in_channels
        self.embedding_dim   = embedding_dim
        self.output_nc       = output_nc
        c1_in_channels, c2_in_channels, c3_in_channels, c4_in_channels = self.in_channels

        # Channel reduction of feature maps before merging
        self.linear_c4 = LinearProj(input_dim=c4_in_channels, embed_dim=self.embedding_dim)
        self.linear_c3 = LinearProj(input_dim=c3_in_channels, embed_dim=self.embedding_dim)
        self.linear_c2 = LinearProj(input_dim=c2_in_channels, embed_dim=self.embedding_dim)
        self.linear_c1 = LinearProj(input_dim=c1_in_channels, embed_dim=self.embedding_dim)

        # linear fusion layer to combine mult-scale features of all stages
        self.linear_fuse = nn.Sequential(
           nn.Conv2d(in_channels=self.embedding_dim*len(in_channels), out_channels=self.embedding_dim, kernel_size=1, padding=0, stride=1),
           nn.BatchNorm2d(self.embedding_dim)
        )

        self.diff_c1 = Fusion_Block(in_channels=self.embedding_dim)
        self.diff_c2 = Fusion_Block(in_channels=self.embedding_dim)
        self.diff_c3 = Fusion_Block(in_channels=self.embedding_dim)
        self.diff_c4 = Fusion_Block(in_channels=self.embedding_dim)

        #Final predction head
        self.dense_2x   = nn.Sequential(nn.Conv2d(in_channels=self.embedding_dim, out_channels=self.embedding_dim, kernel_size=3, padding=1, stride=1),
                                        nn.ReLU(),
                                        nn.BatchNorm2d(self.embedding_dim),
                                        nn.Conv2d(in_channels=self.embedding_dim, out_channels=self.embedding_dim, kernel_size=3, padding=1, stride=1, groups=self.embedding_dim),
                                        )

        self.dense_1x   = nn.Sequential(nn.Conv2d(in_channels=self.embedding_dim, out_channels=self.embedding_dim, kernel_size=3, padding=1, stride=1, groups=self.embedding_dim),
                                        nn.ReLU(),
                                        nn.BatchNorm2d(self.embedding_dim),
                                        nn.Conv2d(in_channels=self.embedding_dim, out_channels=self.embedding_dim, kernel_size=1, padding=0, stride=1)
                                        )
        self.change_probability = ConvLayer(self.embedding_dim, self.output_nc, kernel_size=3, stride=1, padding=1)

        #Final activation
        self.active             = nn.Sigmoid()

    def forward(self, inputs1, inputs2):
        #img1 and img2 features
        c1_1, c2_1, c3_1, c4_1 = inputs1        # len=4, 1/4, 1/8, 1/16, 1/32
        c1_2, c2_2, c3_2, c4_2 = inputs2        # len=4, 1/4, 1/8, 1/16, 1/32

        ############## MLP decoder on C1-C4 ###########
        n, _, h, w = c4_1.shape

        outputs = []
        # Stage 4: x1/32 scale
        _c4_1 = self.linear_c4(c4_1)
        _c4_2 = self.linear_c4(c4_2)
        _c4   = self.diff_c4([_c4_1, _c4_2])
        _c4_up= resize(_c4, size=c1_2.size()[2:], mode='bilinear', align_corners=False)

        # Stage 3: x1/16 scale
        _c3_1 = self.linear_c3(c3_1)
        _c3_2 = self.linear_c3(c3_2)
        _c3   = self.diff_c3([_c3_1, _c3_2])
        _c3_up= resize(_c3, size=c1_2.size()[2:], mode='bilinear', align_corners=False)

        # Stage 2: x1/8 scale
        _c2_1 = self.linear_c2(c2_1)
        _c2_2 = self.linear_c2(c2_2)
        _c2   = self.diff_c2([_c2_1, _c2_2])
        _c2_up= resize(_c2, size=c1_2.size()[2:], mode='bilinear', align_corners=False)

        # Stage 1: x1/4 scale
        _c1_1 = self.linear_c1(c1_1)
        _c1_2 = self.linear_c1(c1_2)
        _c1   = self.diff_c1([_c1_1, _c1_2])

        #Linear Fusion of difference image from all scales
        _c = self.linear_fuse(torch.cat([_c4_up, _c3_up, _c2_up, _c1],dim=1))

        #Upsampling x2 (x1/2 scale)
        x = F.interpolate(_c, scale_factor=2, mode="bilinear")
        #Residual block
        x = x + self.dense_2x(x)

        #Upsampling x2 (x1 scale)
        x = F.interpolate(x, scale_factor=2, mode="bilinear")
        #Residual block
        x = x + self.dense_1x(x)

        #Final prediction
        cp = self.change_probability(x)
        outputs.append(cp)
        return outputs

You've been a great help,I appreciate!


Support soft wrap for line numbers plugin

Hello.
In my past project I had a requirement to highlight code, show line numbers and have support of soft wrap lines (so no horizontal scroll).
I found that originally line numbers plugin is very simple and doing its job very well but when it comes to white-space: pre-wrap - it is breaks.
I made a fix which adds support of soft wrap for this plugin.
Let's discuss it?
Generally the most interesting part, probably, is in 'sizer' functionality. It is calculating line-height. Why I not used line-height property? Because there are different problems with it: it can be line-height: normal (so God knows how much is that), the browser zoom level can be changed (and line-height actually is inc/decreasing) etc.
So, maybe it is a bit silly, but still working solution :) (any ideas how to make it better? Would be nice to discuss)

Any updates on this one?

This looks quite good to me, though I did not take the time to properly download it to test it.
Did you make sure it was still compatible with other plugins, different themes, etc.?

@Golmote one more update - I've updated test.html with support for testing plugins. I've tested in different browsers - everything is fine for me :)

Thanks for contributing!
However, it’s very difficult for us to review it and choose what to merge when you send one big pull request for multiple changes. Please split the changes into one PR for the test drive page and one for the soft breaks? Thanks!

On the topic of separate pull requests, if you wish to modify the general code structure of a file, please send a separate PR to do that and a separate PR for any other changes. In general, the smaller the PRs (obviously as long as they’re coherent), the better. From a quick look, it seems that the changes in the line numbers plugin are way more extensive than required for this change (but I might be wrong).

Also, I’m not a huge fan of using a line-numbers-break-word class here. Why not just get the computed value of white-space and if it’s pre-wrap or normal do the thing required to have proper line numbers with wrapped code? This would basically always do what the user expects, transparently, without having them think about what they need.

@LeaVerou, definitely, I will separate them soon when I will have time for it.
About class name. It was just my decision. I can make it to be automatically, if you wish so.

Okay, so I've separated updates to test.html to separate branch/pr at https://github.com/PrismJS/prism/pull/592.
Also I have updated current one, so now it is determining automatically soft-wrap as @LeaVerou proposed.
@LeaVerou, @Golmote, what can you say about this?

I can say that the indentation is a bit messed up right now. Please use tabs (and this applies to CSS too).
Also, please don't include the .gitignore file in this PR. (I just added .DS_Store to the list myself (1707e4e3a54a506e915c3b6ba7ca165fff9a2c1c))
Now about the plugin code itself:

The way you add the resize listener makes it impossible (or at least hard) to apply the plugin dynamically on code blocks, which should normally be doable by calling highlightElement() (which will execute the hook). I guess you could maintain a list of code blocks that require the resize check to allow this. (I'm not sure I'm making my point here, so feel free to tell me if you don't get what I mean)
The above point would also solve the issue of getting the computed style in each call of _resizeElement() since it would be called only for code blocks that have the soft-wrap.
The _resizeElement() function should probably be kept as small as possible since it's called on the resize event. For example, you could create lineNumberSizer element in the hook.

@Golmote the previous implementation was just about it - just when you adding a class - everything is rock & roll.
We can also move computed style to afterHighlight hook, so it would check if the block has proper white-space - and if it is - just add a class to it. (and, also, we can move back lineNumberSizer to afterHighlight hook). So, in the _resizeElement we would just query for .line-numbers.break-word (or whatever class name) and thats it.
What do you think?

+1! :)

Sorry for the long time waiting. It appears to work just fine. Thank you very much for this contribution!

@Golmote wow, man, 2.5 years. Amazing, I'm already married and visited 8 countries by this time :D

@VitaliyR Better late than never!

I seems line highlighting does not work properly when soft wrap is enabled.

@siavashs Indeed I should have expected that. Those are two different plugins... I'll open a new issue so that it can be handled at some point.


feat: allow using of current block in inclusion proofs

Fixes #4274

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

Current dependencies on/for this PR:

master

PR #4282

PR #4285   👈

This stack of pull requests is managed by Graphite.

Benchmark results
Metrics with a significant change:

note_successful_decrypting_time_in_ms (32): 1,054 (+19%)
note_trial_decrypting_time_in_ms (32): 41.9 (-78%)

Detailed results
All benchmarks are run on txs on the Benchmarking contract on the repository. Each tx consists of a batch call  to create_note and increment_balance, which guarantees that each tx has a private call, a nested private call, a public call, and a nested public call, as well as an emitted private note, an unencrypted log, and public storage read and write.
This benchmark source data is available in JSON format on S3 here.
Values are compared against data from master at commit 382dfbed and shown if the difference exceeds 1%.
L2 block published to L1
Each column represents the number of txs on an L2 block published to L1.

Metric
8 txs
32 txs
128 txs

l1_rollup_calldata_size_in_bytes
45,412
179,524
716,068

l1_rollup_calldata_gas
221,704
866,968
3,448,216

l1_rollup_execution_gas
314,191
984,708
3,667,873

l2_block_processing_time_in_ms
1,152
4,353
17,208

note_successful_decrypting_time_in_ms
272 (+8%)
:warning: 1,054 (+19%)
3,491 (+5%)

note_trial_decrypting_time_in_ms
81.0 (+25%)
:warning: 41.9 (-78%)
143 (-3%)

l2_block_building_time_in_ms
16,797 (+2%)
66,228 (+2%)
265,113 (+1%)

l2_block_rollup_simulation_time_in_ms
11,998 (+1%)
47,201 (+1%)
189,769

l2_block_public_tx_process_time_in_ms
4,770 (+5%)
18,884 (+5%)
75,099 (+5%)

L2 chain processing
Each column represents the number of blocks on the L2 chain where each block has 16 txs.

Metric
5 blocks
10 blocks

node_history_sync_time_in_ms
13,316
25,668

note_history_successful_decrypting_time_in_ms
2,410 (+12%)
4,388 (+5%)

note_history_trial_decrypting_time_in_ms
80.2 (-53%)
197 (+12%)

node_database_size_in_bytes
17,375,312 (+1%)
33,144,912

pxe_database_size_in_bytes
29,923
59,478

Circuits stats
Stats on running time and I/O sizes collected for every circuit run across all benchmarks.

Circuit
circuit_simulation_time_in_ms
circuit_input_size_in_bytes
circuit_output_size_in_bytes

private-kernel-init
221
44,897
26,193

private-kernel-ordering
181 (+2%)
44,513
14,929 (+1%)

base-rollup
1,262
128,970
881

root-rollup
81.7
4,088
677

private-kernel-inner
322 (+4%)
72,056
26,193

public-kernel-private-input
224 (+4%)
32,615 (+1%)
26,193

public-kernel-non-first-iteration
223 (+4%)
32,657 (+1%)
26,193

merge-rollup
7.60
2,608
881

Tree insertion stats
The duration to insert a fixed batch of leaves into each tree type.

Metric
0 deployed contracts
1 deployed contracts

tx_size_in_bytes
15,575 (+1%)
36,454 (+10%)

Transaction processing duration by data writes.

Metric
0 new commitments
1 new commitments

tx_pxe_processing_time_ms
402 (+2%)
1,147 (+3%)

Metric
1 public data writes

tx_sequencer_processing_time_ms
582 (+5%)


Can`t install on npm 6.13.4

prepareGitDep npm ERR<EMAIL_ADDRESS>prepare: svn checkout https://github.com/SteamDatabase/Protobufs/trunk protobufs && svn checkout https://github.com/SteamRE/SteamKit/trunk/Resources/ProtobufGen protobuf_gen && svn checkout https://github.com/SteamRE/SteamKit/trunk/Resources/SteamLanguage steam_language

Full log?

Sorry, my bad :) I migrate to the new mac os and get few troubles with command line, now it works.
Thank you :)

How you solve this problem?

How you solve this problem?

Can u please share ur errors log

I already solved this problem.But I have another question:
how can bot take the place of a coach in the lobby?
сб, 20 июн. 2020 г. в 00:05, Vladyslav Poshvaniuk<EMAIL_ADDRESS>
:

How you solve this problem?
Can u please share ur errors log
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/seishun/node-steam-resources/issues/8#issuecomment-646860023,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJX65CULIRNOWLJ4SKFLR33RXPHINANCNFSM4J657FJA
.

I already solved this problem.But I have another question: how can bot take the place of a coach in the lobby? сб, 20 июн. 2020 г. в 00:05, Vladyslav Poshvaniuk<EMAIL_ADDRESS>…
: How you solve this problem? Can u please share ur errors log — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#8 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJX65CULIRNOWLJ4SKFLR33RXPHINANCNFSM4J657FJA .

https://www.npmjs.com/package/dota2#module_Dota2.Dota2Client+setPartyCoach


bug: fix verification of attestations from rekor

Few different issues here

Intermediates from rekor need to be base64 decoded before using them.
Trusted time stamps were only being considered while parsing entries
from rekor but not while verifying envelopes in witness.Verify. To get
around this I added an option to attach a trusted time to a specific
DSSE signature which makes sure this gets used when verifying the
envelopes.

Signed-off-by: Mikhail Swift<EMAIL_ADDRESS>

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 1 (0.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.02%) to 38.56%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pkg/cryptoutil/x509.go
0
1
0.0%

Totals

Change from base Build<PHONE_NUMBER>:
-0.02%

Covered Lines:
600

Relevant Lines:
1556

💛  - Coveralls

https://asciinema.org/a/DOe2CyICz2IAeMO8xYHwIsYZC


Add files via upload

@gkiff domains/uk/sch/essex/brentwood.txt: this request has an incorrect file path format, please ensure that you are familiar with     this repository rules located at the bottom of this page and change     your request accordingly. If you don't know how to change request, close it and open a new one.     If you are not able to make the pull request according the instructions, please send us an email to<EMAIL_ADDRESS>Please mention this request URL in the message.

@gkiff Could you please provide us with:

the school official website URL
the school street address, including city and country
a proof, which shows that the school recognizes the domain you are submitting as an official email domain for the students.

@gkiff You might miss my previous comment. Please react.

@gkiff I am sorry, this request remains unanswered for a while. I have to close it without merging. Please reopen and comment if you have an update regarding the aforementioned issue. Thank you for your understanding!


R.useWith doesn't work as expected if called with R.__ for the function argument

See http://bit.ly/1Bdkpls vs. http://bit.ly/1K3MEZ5

I think the description of this is wrong.
The problem is not really with the use of R.__.  In fact, the fixed version continues to use R.__.
The problem is that this function is variadic.  If we wrote it to take one main function and a list of transformer functions, like this, this problem would go away.
I think we should do this.  Any objections?  It's another API change, of course,  But it's in line with the other recent ones removing variadic signatures.

fine with changing to useWith(fn, [fns]) in the near term, but longer term i'd like to find a way to combine some of the many compose functions we have.


[OpenAI] Migrate TestProxy recordings.

This PR migrates the test recordings using test proxy for OpenAI SDK to the assets repo.
Migrate recordings from language repositories to assets repo
Prerequisites:

The script generate-assets-json.ps1 will execute the initial migration of your recordings from within a language repo to the assets repo as well as creating the assets.json file for those assets.

Test-proxy needs to be on the machine and in the path. Instructions for that are here.

Running the script:
The script needs to be executed inside an sdk/ServiceDirectory/Library level directory.
C:/repo/sdk-for-java/sdk/formrecognizer/azure-ai-formrecognizer> ..\..\..\eng\common\testproxy\transition-scripts\generate-assets-json.ps1 -InitialPush

Examples of current assets.json locations:

sdk/data/aztables/assets.json
sdk/keyvault/azure-keyvault-keys/assets.json

After running a script, executing a git status from within the language repo, where the script was invoked from, will reflect two primary results:

A new assets.json will be present in the directory from which they invoked the transition script.
A bunch of deleted files from where their recordings were before they were pushed to the assets repo.

Running the script without the -InitialPush option will just create the assets.json with an empty tag. No data movement.

Using test proxy going forward:
https://github.com/Azure/azure-sdk-for-java/wiki/Test-Proxy-Migration#3-using-test-proxy-going-forward

C:\repo\azure-sdk-for-java.assets\tag-ref\java\sdk\storage\azure-storage-queue\src\test\resources\session-records\QueueServiceAsyncApiTests.listQueues[3].json
locally is where you should find your local copy of recordings.

API change check
API changes are not detected in this pull request.

/azp run java - openai - tests


Documentation for orGroup

Seriously no clue what this even does or how it works.
It's present in toolbox.yml but doesn't seem to do anything to my observations.

Done in a direct commit.


[BUG] : MenuBar cannot Accessible

Related Issue
Fixes:  #2524
Description
[BUG] : MenuBar cannot Accessible

Type of PR

[x] Bug fix
[ ] Feature enhancement
[ ] Documentation update
[ ] Other (specify): _______________

Screenshots / videos (if applicable)
Before
Screencast from 2024-07-17 20-42-46.webm
After
Screencast from 2024-07-21 08-13-44.webm
Checklist:

[x] I have made this change from my own.
[x] I have taken help from some online resources.
[x] My code follows the style guidelines of this project.
[x] I have performed a self-review of my own code.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] I have made corresponding changes to the documentation.
[ ] My changes generate no new warnings.
[ ] I have tested the changes thoroughly before submitting this pull request.
[ ] I have provided relevant issue numbers and screenshots after making the changes.

Hello @huamanraj ,
please merge this..


pass key to DictNode fields for error reporting

This improves error reporting a bit by passing the name that a dict field was given down to the child node (like WildcardDictNode does) so that it can reference itself by the name it was given, not just by its class name, which may not be the same.
'foo must be a str' instead of 'dummyfoo must be a str'
Sidenote, I also clarified the behavior of is_valid, which at least in the case of DictNode does not factor in the validity of its descendants. Not sure if that should be explored or not, I could see it both ways...I think the way that it is makes for more clear error reporting again? The dict itself may be just fine, and have the fields it is required to have, and then if a field has the wrong type then the error will only show up on that field, not on the field and the parent dict.

:+1:


Switch to Maven to manage dependencies

Right now, we have .jar files in the lib folder to handle dependencies, which is okay, but when we have a large number of .jars, it will get cumbersome to upload.
So for instance (on my computer) I have Selenium, Appium, Appium-Support, and Appium-Client jars in my lib folder. This means that there will be ~50 jar files that will need uploading. This is tedious! Working with Maven will eliminate the need to upload all of these jars.
I got this idea from this website: http://stackoverflow.com/questions/22113394/git-push-java-classpath-file

The new Maven project is ready and is located under the "/Code" directory. All new packages should be added into the "src\main\java\edu\wm\translationengine" directory.

To download dependencies:
First checkout and pull the updated repo. Then install Maven (either through Eclipse or the main Maven website). Then right-click on the project, select the "Maven" submenu, and then click on "Update project". Eclipse should then download all dependencies specified in the pom.xml file!


Feat: Effective Date Fixes - 2392

I have fixed the empty string and null error on tradeEffectiveDate and have added proper date validation on the field.


chore: update Coveo template

Thanks for contributing to the Harness Developer Hub! Our code owners will review your submission.
Description

Please describe your changes: \ update Coveo template
Jira/GitHub Issue numbers (if any): \ N/A
Preview links/images (Internal contributors only): \ N/A

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

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

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

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


[QUESTION] support for new version fastapi

Is this project still maintained by author?

I'm sorry for being late, I'm very busy lately
I will check on the new version asap

I've added dependabot so I won't miss on the updates
It will update to the latest Fastapi and more

I've added dependabot so I won't miss on the updates
It will update to the latest Fastapi and more


Philips Hue and personal username

I try to use my new Philips Hue with hyperion. The setup works perfectly good but for security reasons I would like to use another username than "newdeveloper" to link hyperion and my Hue bridge. Is-it possible to create username parameter in config file to do this ?
Actually the username "newdeveloper" is in "hard-text" in "libsrc/leddevice/LedDevicePhilipsHue.cpp ".
Best regards

I will look into this during this weekend. Regs...

Thank's.
Did you use the "transitiontime" parameter in the command sent to the bridge ? I see in Philips documentation the following information :
"When you set the light state, and update color, brightness etc., the light will not respond immediately because by default there is a transition time to the new state of 400 milliseconds. If you want the light to respond quickly to a state change, set the transition time in the light state to zero milliseconds."
http://www.developers.meethue.com/things-you-need-know

Added both config options. Default transition time is now 100 ms which makes it  a lot snappier. Did not implement it in the past due to worries about the performance of the bridge (only 30 commands per second possible). But seems to work out quite well now.

I saw your modifications, thank's a lot !
I just have to wait the next compil to try the news options.


Empty item in the Owned Schemas table for New User dialog

Azure Data Studio Version: main

Steps to Reproduce:

Open New User dialog
Add Owned Schemas to User

Expected: No blank rows
Actual:

I don't see an empty schema in the list being return from STS.  I think that must be added in ADS somewhere.

It looks like the issue is coming from this line https://github.com/microsoft/azuredatastudio/blob/main/extensions/mssql/src/objectManagement/ui/userDialog.ts#L104.  For new users "Default Schema" is blank, which lets the engine set the default when creating the user.  The create dropdown call adds a blank entry since the default schema isn't provided.
@alanrenmsft I'll reassign to you since I'm not sure how you want to fix.

Fix ported to release branch


Add support for host/port configuration in the XMPP adapter.

Necessary for those cases when the host/port can't be inferred by the JID. (Google apps for business in my case.)

Does this still work even if the HOST and PORT environment variables aren't set, or does some checking need adding?

Yes, will work. No checks needed.

Cool, I'll merge it in.


Insert key during screen reader not aligned correctly

Testing #177735
When testing the above item I used cmd+i and it brought up this box with the hover. If I did it quickly the hover ended up floating in the terminal and not going away when other lines crossed over it.

can you still reproduce this @eleanorjboyd ?

so I have enabled screen reader and then tried all 4 key bindings and none of them bring up the hover still. When I do "cmd+i" it jumps into the editor from the terminal and opens inline chat.

oh, the keybinding for this is cmd+k+cmd+i


Panel Version
1.11.7
Wings Version
1.11.13
Service
game_eggs/steamcmd_servers/the_isle/evrima
Modified
No, I did not modify the egg
Expected Behavior
I expected the server to start
Actual Behavior

Steps To Reproduce
Step 1 Install
Step 2 start the server
Install logs
https://nothing_to_do_with_wings

stop the server
replace the game.ini file with this one https://pastebin.com/yHugsuts
start the server again, it will not print anything or be marked as running but you will be able to join again


Bump the version of Go

ref: https://github.com/sigstore/fulcio/pull/1703#discussion_r1649450336

@cpanato can you take a look at if any of the GHAs need to be updated as well?

update this pr here: https://github.com/sigstore/fulcio/pull/1707

closing in favor of https://github.com/sigstore/fulcio/pull/1707


Add shortcut to move an entry up or down

Description of the new feature / enhancement
Hi,
When adding a new entry to the hosts file via the Hosts File Editor, it appears at the end. To more easily retrieve my IPs / hostnames when reading the hosts file, I am used to order them. With the Hosts File Editor, you can do this by right clicking on an entry and use the 'Move up' or 'Move down' items of the popup menu. But if you want to move up (or down) an entry for several positions, you have to repeat this action many times, which is not very handy.
It would be helpful to be able to select an entry and use a shortcut to move it up or down.
As the up and down arrows keys are already used to move the "focus" on an entry (which is fine), I guess something like CTRL + 'up arrow' and CTRL + 'down arrow' could be used for that purpose.
Note: It would also be very handy to be able to drag and drop an entry directly at the desired position.
Thank you.
Scenario when this would be used?
Add a new entry, which appears at the end of the list in the Editor.
Select the new entry.
Then use directly the shortcuts to move up and order this new entry at the position you want.
or
Directly drag and drop the entry at the desired position.
Supporting information
No response

Please retitle this as an issue. For example:

Hosts file editor: No shortcut to move an entry up or down


IFS Browser 2.0

Which is the same as the IFS Browser now (kind of)
Except it has the ability to create filters. The default filter is your working directory.

This will replace the current IFS browser.


Removed Ci pipeline to tag the aperture-go repo

Description of change

Removed the workflow to tag the aperture-go repo on Aperture release as it is archived for now.

This change is

Trying close and re-open to see if license/cla syncs that way


[FEATURE REQ] CreateIfNotExists/DeleteIfExists/Exists for File

Is your feature request related to a problem? Please describe.
Related to issue #7211
In the old API there are 'convenience' methods like CreateIfNotExists/DeleteIfExists for File and FileShare
Describe the solution you'd like
Helper methods (like CreateIfNotExists/DeleteIfExists) for Files
Describe alternatives you've considered
Can easily be worked around. Refer to #7211.
Additional context
Add any other context or screenshots about the feature request here.
Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

[x] Description Added
[x] Expected solution specified

In track 1, we have:

CloudFileShare.CreateIfExists(), .DeleteIfExists(), and .Exists()
CloudDirectoryClient.CreateIfExists(), .DeleteIfExists(), and .Exists()
CloudFileClient.DeleteIfExists(), .Exists().  I think we should also add CreateIfNoExists()

Resolved with https://github.com/Azure/azure-sdk-for-net/pull/10074


sunrisesetservice values for next day

A bug was spotted where the sunriseset service is returning us tomorrows values. Code needs to be worked so at least we are comparing with the correct time-span... even if its not for the correct day.

between logic I wrote had a bug. Added a fix


bug: Ionic serve should listen on all addresses on linux

From @MichaelBitard on May 10, 2015 12:14
Type: bug
Platform: all
When using ionic serve for the developments, It prompts for an interface selection:
Multiple addresses available.
Please select which address to use by entering its number from the list below:
 1) <IP_ADDRESS> (wlan0)
 2) localhost

Why not listen by default on <IP_ADDRESS> so it will be available both locally and remotely?

Copied from original issue: driftyco/ionic#3693

In 1.4.0, you will be able to run the server on <IP_ADDRESS>. :) :8ball:

That's great news, I can't wait for it to be released ;)


Allow From to be specified on email agents

Should fix #1307.
Note that if you're using Gmail, I think it'll still show your normal from (and add a X-Google-Original-From header instead) unless you add that from address as a valid sender on the account you use.

Nice, looks good to me!

Thanks!


Add animated loader to calender app

Went with a glowing FCC fire instead of a spinner. It may be a bit ridiculous :) - Can check out the pen here as alternate: https://codepen.io/tyday/pen/pQEQNK
I'm assuming
:root {   --color1: green;   --color2: #6E6E05;   --color3: #FFCB00; }
is inappropriate, but I don't know the react way of doing things.

Coverage remained the same at 100.0% when pulling c384932d9b1703aaada68d6c1229a49bbac4ec8a on tyday:iss35_A into c25cc6db71a17d2f2b67a52b023cfe674c49bb25 on FCCColumbus:dev.

@tyday Can you pull the latest from dev and rework your changes in please?


CMake: fix build for Apple Silicon hosts

When building with build-script using these arguments
utils/build-script --skip-build-benchmarks
  --skip-ios --skip-watchos --skip-tvos
  --swift-darwin-supported-archs "arm64"
  --sccache --release-debuginfo --test

the build fails with
ninja: error: 'stdlib/swift-test-stdlib-macosx-x86_64',
needed by 'stdlib/CMakeFiles/swift-test-stdlib', missing and no known rule to make it

I think that the "Getting Started" guide should avoid hardcoding x86_64 arguments, and suggest using $(uname -m) instead. SWIFT_PRIMARY_VARIANT_ARCH_default could also get its value from CMAKE_HOST_SYSTEM_PROCESSOR in the root CMakeLists.txt.

Resolves SR-13943.

@swift-ci please smoke test

Tagging @compnerd and @gottesmm, since they're my usual go-tos for CMake-fu.

Thanks for the PR. There are some other places where macosx-x86_64 is specified directly and you may want to update those. Specifically:

utils/coverage/coverage-generate-data
benchmark/README.md
clang-tidy instructions in docs/DebuggingTheCompiler.md.

@varungandhi-apple thanks for highlighting those, update now.

@swift-ci please smoke test

@MaxDesiatov can this be merged/are you waiting on something specific?

IDK, do I need for an explicit approval from @gottesmm before this can be merged? As @compnerd mentioned above:

Id want an okay from Michael on this as well

@MaxDesiatov @compnerd @varungandhi-apple I independently stumbled across this issue over break. (Too bad this PR wasn't merged then.) My version of a fix is in https://github.com/apple/swift/pull/35231 .
It uses SWIFT_HOST_VARIANT_ARCH instead of the fix in this PR. Which PR would be better to merge?

@MaxDesiatov @compnerd @varungandhi-apple I independently stumbled across this issue over break. (Too bad this PR wasn't merged then.) My version of a fix is in https://github.com/apple/swift/pull/35231 .
It uses SWIFT_HOST_VARIANT_ARCH instead of the fix in this PR. Which PR would be better to merge?

IMO we should merge this, since it also updates the documentation. We don't need to be blocked on review, we can change things after-the-fact if there's an issue.

IMO we should merge this, since it also updates the documentation. We don't need to be blocked on review, we can change things after-the-fact if there's an issue.

@swift-ci please smoke test macOS platform

@swift-ci please smoke test macOS platform


fix GUI startup

fixes issue #113

Several times on startup, with the serial connected but not to a MAX the program quits after about 1 second, returning to terminal.
If the program remains open the program works as expected.


[PRFC] Extendable components

[PRFC] Adaptable components

"Extendable" renamed "Adaptable"

TL;DR
How to make an adaptable component:
const { componentRef, MyComponent } =
  createAdaptableComponent<Props, Context>({
    Provider() { /* Prepare data, maybe async, provide context */ },
    Component() { /* The pure UI component, read above context */ },
  });

How to adapt a component:
adaptComponent(componentRef, {
  Adaptation({ value, Component }) {
    /* override default context values */
    return <Component value={ /* ... */ } />
  }
});

Rationale
As raised in #11035, there's a need to be able to configure (or adapt) components, especially core components. Implementors might want to add a tooltip around a component, intercept the to in Links (e.g to redirect internal corporate links user:@joe, slack:#channel-name), or add/change the UI of components (e.g. add custom action buttons to certain cards, enable/disable them given async logic).
If this is done globally at bootstrap time, it will affect such components being rendered anywhere. There will not be a need to customize this wherever components are used, which wouldn't be feasible.
It can also be useful to be able to scope this to a certain place in the React component tree, such that under a certain component, every <Something> is adapted a certain way. An example of this is the entity page header.
This can be done in several ways, but to be as powerful and useful as possible, it would be beneficial to be able to use asynchronicity (for async lookups), being able to handle errors, fallback to other UI's and maybe even tap into the React component lifecycle, so that the logic that adapts a component can e.g. subscribe to observables, and properly unsubscribe when the component is unloaded.
This PR provides a solution to this.
Back to the future
Soon after React came about, the concept of Active and Passive components became popular. Sometimes called Smart/Dumb components, or Components/Containers.
The concept of this is to separate the logic of components (networking, fetching, parsing, error handling, waiting) in Active components, to pure non-logic UI rendering of whatever is passed as props in Passive components.
Often, this was implemented using render props which is ineffective as they are re-evaluated every render, and when React got Context and functional components (with hooks), logic was quickly moved into hooks instead.
The fundemantal idea of Active and Passive components can still be employed though, to enable adapting components in a pretty slick way.
Provider/Component
For components to be adaptable, we need to make them adaptable, unless we go down the dark route of hacking into them.
To make a component adaptable, we can split it in two parts, but maintain its API surface to be just like before. Given the Active/Passive semantics described above, let's reason about them similarly under the names Provider and Component.

[Provider] A component that takes the props and performs whatever logic necessary (could be async or anything else), and turns the props that should be configurable and any other parsed/fetched result, as a context object to its inner Component.
[Component] A component that reads its input from the context provided by the Provider. It also has access to the raw props, and can use that if necessary (could be values that shouldn't be configurable or just passing things like className downstream).

Example:
The link component has a prop to, but also practically any other HTML element prop, including children. The API would be the same:
<Link to="url">Text</Link>

But the component is internally two components. We can choose to make to and children configurable by creating a LinkContext (side by side with LinkProps):
interface LinkContext {
  to: string;
  children: React.ReactNode;
}

In fact, in LinkProps, the to can be more than just a string, and handling this is something we can do in the LinkProvider. So when using a <Link>, this will turn into:
<LinkProvider to="url">
  <LinkComponent />
</LinkProvider>

The LinkComponent will read the to and children from the context instead of from its props.
Now let's introduce adaptations to the Link component. Adaptations are normal React components, and can intercept the context value. When adapting the Link component, the adaptations will become intermediate providers in between the Provider and Component:
<LinkProvider to="url">
  <Adaptations> { /* <-- adaptations end up here where they can rewrite the context */ }
    <LinkComponent />
  </Adaptations>
</LinkProvider>

Creating an adaptable component
To create an adaptable component, this PR proposes createAdaptableComponent() which returns the public API surfaced component, as well as a component ref which can be used to reference the component when adapting it.
Let's make this (very minimalistic) Link component adaptable:
export type LinkProps = { /* ... */ };

export function Link(props: LinkProps) {
  const to = String(props.to); // Stringify if not string
  return {props.children};
}

We do this using createAdaptableComponent, and by defining the LinkContext which is how the Provider communicates with the Component:
export type LinkProps = { /* ... */ };
export type LinkContext = {
  to: string;
  children: React.ReactNode;
};

export const { componentRef: linkComponentRef, Component: Link } =
  createAdaptableComponent<LinkProps, LinkContext>({
    id: 'Link:v1',
    Provider: ({ props, Component }) => {
      const value: LinkContext = {
        to: String(props.to),
        children: props.children,
      };

      return <Component value={value} />;
    },
    Component: ({ props, value }) => {
      return {value.children};
    },
  });

It might look like a lot of overhead, but remember this Link component is tiny. The extra work of splitting it in two is the same in absolute terms for more realistic components, and ends up being marginal.
We export LinkContext, even though it's not useful when using the Link component (only the component itself and its LinkProps are). But the context type is important when adapting the component, and even though likely not necessary to use it explicitly, it can still be useful.
In the export destructuring we export linkComponentRef which can be thought of as an apiRef in that it's opaque and used for referencing, and Link (with the same API as the original Link component). This is not a breaking change, the public API only has additions.
By providing the Props and Context types to createAdaptableComponent, the two components (the provider and the "UI component") have typesafe props. Let's examine them:
The Provider
The Provider part of the adaptable component is a component itself (hence can e.g. use hooks). Its props are:

props the props provided wherever <Link> is used in our example.
Component an opaque component. This will perhaps be the inner component, but it could also be intermediate component adaptations. It has a prop value (of type LinkContext) which needs to be set to the context value.

The Component
The Component part of the adaptable component is what renders the component. If making an existing component adaptable, most (if not all) of its internal React output (the "HTML") ends up here. Its props are:

props the raw props object provided to the <Link> in this example.
value the context object provided by the Provider, and potentially adapted (altered) by a component adaptation.

Lazy-loading
Both the Provider component, and the Component component can be lazy-loaded, by instead providing asyncProvider and asyncComponent:
export const { componentRef: linkComponentRef, Component: Link } =
  createAdaptableComponent<LinkProps, LinkContext>({
    asyncProvider: () => import('./my-component').then(m => m.Provider),
    asyncComponent: () => import('./my-component').then(m => m.Component),
  });

Adapting
If we want to adapt a component, we use adaptComponent. This can be used in the top-level app when setting it up, but plugins can also adapt components automatically as part of createPlugin. When plugins provide adaptations, they provide them in the createPlugin call, using createComponentAdaptationExtension rather than adaptComponent, to tie the adaptation to the plugin.
We can also locally adapt components somewhere in the React component tree (for sub components).
When adapting, not only can the context be rewritten, but what children components are rendered can be altered too. A component adaptation is a component, so it can return anything. Sometimes changing the context is useful, sometimes just changing what's rendered is useful.
Adaptations are created using adaptComponent() (or if locally in a React component and depending on local component state, useAdaptComponent()). The following example is silly by logic, but shows the syntax:
const adaptation = adaptComponent(linkComponentRef, {
  Adaptation({ value, Component }) {
    if (!canAdaptThis(value))
      // Fallback - can't adapt so just render the real component
      return <Component />;

    // Overwrite the context "to" field
    return <Component value={{ ...value, to: '/' }} />;
  },
});

The adaptation is a component itself. It can e.g. use hooks. It gets a mix of the props that the component itself gets:

value the context value (so far in the context stack)
Component an opaque component which renders the real inner component (or another intermediate adaptation). It has an optional prop value (like the Provider-side of the adaptable component) which can be used to set a new context value.
props the raw props (readonly), sometimes useful to make decisions from

The return value adaptation is opaque, and is either provided in createApp, in createPlugin or in <ProvideAdaptation> which enables adaptations scoped to a certain part of the React component tree. More on that below.
Example: change what's being rendered (not the context)
Let's say the Github plugin should adapt the Link component to add badges after links that goes to PR's so that we see a colorful dot after the link for whether it's open, merged or closed. The linkComponentRef can be imported (just like an API ref), and when used with adaptComponent it automatically provides types to ensure the adaptation is typesafe with regards to the context it can alter.
createPlugin({
  id: 'github',
  // ... ,
  adaptations: {
    link: createComponentAdaptationExtension(linkComponentRef, {
      id: 'github-link-adaptation',
      Adaptation({ value, Component }) {
        if (!isLinkToPr(value.to))
          // Fallback - can't adapt so just render the real component
          return <Component />;

        // Let's assume useGithubPrStatus exists and subscribes to some observable internally
        const status = useGithubPrStatus(getPrFromLink(value.to));

        return (
          !status // Maybe undefined on first rendering before observable emits
          ? <Component />
          : <Badge color={prColorFromStatus(status)}><Component /></Badge>
        );
      },
    }),
  }
});

The above clearly uses functions we don't have (isLinkToPr, useGithubPrStatus, getPrFromLink and prColorFromStatus), but, would be quite easy to write. If so, anywhere we render a regular <Link>, it could be decorated with PR/issue status badge. The same could happen for links to CI/CD builds, or anything else where it'd be useful to see status/progress live or just extra information.
If the Link component becomes adaptable, and it is being used in many different contexts (some of where UI decoration isn't always a good idea) perhaps adding a prop noDecoration?: boolean to it would make sense. The adaptations could then respect this, and not decorate it (but perhaps still change the to if that'd be useful).
How adaptable components work and when what kind of adaptations is a good idea, will likely be different for different components. The link is very generic, and used everywhere, other components are more esoteric.
Example: change context, not chrome
Note that we didn't set a value for <Component /> in the Github PR decorator adaptation, but rather wrapped the link with a <Badge> wrapper.
Other components could be adaptable in different ways. For example, a user Card showing the avatar and name of a user (perhaps in the Catalog), could have a set of action buttons at the bottom. If this card is made adaptable, the avatar, name and action buttons could all be turned into context values, adaptable/changeable by adaptations.
We can imagine such a card being used like this:
<UserCard entityRef={ /* ... */ } />

and it could be implemented, as an adaptable component, like this:
export type UserCardProps = { entityRef: string; };
export type UserCardContext = {
  avatarUrl: string;
  name: string;
  actionButtons: { href?: string; onClick?: () => void; text: string; }[];
};

export const { componentRef: userCardComponentRef, Component: UserCard } =
  createAdaptableComponent<UserCardProps, UserCardContext>({
    Adaptation: ({ props, Component }) => {
      const user = useEntityRef(props.entityRef);

      if (!user.value)
        return <Progress />;

      const value: UserCardContext = parseUser(user.value);

      return <Component value={value} />;
    },
    Component: ({ props, value }) => {
      return (
        <Card>
          <CardHeader>...</CardHeader>
          <CardContent>...</CardContent>
          <ActionButtons>...</ActionButtons>
        </Card>
      );
    },
  });

An adaptation could e.g. easily add its own action button:
adaptComponent(userCardComponentRef, {
  Adaptation({ value, Component }) {
    if (!shouldHaveExtraActionButton(value))
      return <Component />;

    const newValue = {
      ...value,
      actionButtons: [
        ...value.actionButtons,
        {
          text: 'My action',
          onClick: () => { /* ... */ },
        }
      ]
    };

    return <Component value={newValue} />;
  },
}),

Local adaptations in the React component tree
To add an adaptation to a component at a certain place in the component tree, use ProvideAdaptation. It has a prop adaptations which can be either 1 adaptation, or an array of adaptations.
useAdaptComponent is the same as adaptComponent but with a last deps argument like most React hooks. It memoizes the adaptation as long as the deps don't change.
function MyComponent(props: MyProps) {
  // This adaptation depends on props.someProp
  const adaptation = useAdaptComponent(
    userCardComponentRef,
    {
      Adaptation({ value, Component }) {
        if (someCondition(props.someProp))
          return <Component />;

        const newValue = {
          ...value,
          ...myOverrides,
        };

        return <Component value={newValue} />;
      },
    },
    [props.someProp]
  );

  // The adaptation will only be used for UserCard components under
  // this part of the React component tree.
  return (
    <ProvideAdaptation adaptations={adaptation}>
      <MyOtherComponentsGoesHere />
    </ProvideAdaptation>
  );
}

Lazy-loaded adaptations
Instead of providing the Adaptation component in adaptComponent, useAdaptComponent or createComponentAdaptationExtension, the implementation can be lazy-loaded and exposed in asyncAdaptation:
const adaptation = adaptComponent(
  userCardComponentRef,
  {
    Adaptation({ value, Component }) {
      // ...
    },

    // or

    asyncAdaptation: () => import('./my-adaptation').then(m => m.Adaptation),
  },
);

This will lazy-load the adaptation. The target component (UserCard in this case) will be immediately rendered without this adaptation (to not lag the UI). When the adaptation has loaded, it will be applied.
Props interception
Sometimes it makes sense to intercept props and alter them. This is not the same as injecting logic in-between the Provider and Component as above, but rather customizing props specific to the installation.
The adaptComponent and useAdaptComponent functions as used above, take an Adaptation (or asyncAdaptation) property, which is optional. The other optional property is interceptProps:
export type AdaptableComponentSpec = {
  /**
   * Intercept the props, to e.g. rewrite some of them
   */
  interceptProps?: (props) => typeof props;

  /**
   * An adaptation component to intercept the context
   */
  Adaptation?: /* */;
  asyncAdaptation?: () => Promise<typeof Adaptation>;
};

This is useful when e.g. rewriting the Link to to understand installation specific "magic" links, or perhaps to change props when running in dev-mode, during testing etc.
adaptComponent(
  linkComponentRef,
  {
    interceptProps: props => ({
      ...props,
      `${props.to}`.beginsWith('slack:#')
        ? fixSlackUrl(props.to)
        : props.to,
    }),
  }
);

When adaptations are applied, first all interceptProps functions get invoked, and then all Adaptation components get injected.
Ref
createAdaptableComponent() has a sibling function createAdaptableForwardableComponent() in which case the inner Component gets a React ref is such is provided. The resulting component (to be used anywhere) will then have a ref prop too.
Separate component ref factory
It is sometimes useful to be able to create component refs separately from its implemenation. In the example above, we use createAdaptableComponent which is a shorthand for createAdaptableComponentRef followed by implementAdaptableComponent.
export const { componentRef: linkComponentRef, Component: Link } =
  createAdaptableComponent<LinkProps, LinkContext>({
    id: 'link',
    Provider() { /* ... */ },
    Component() { /* ... */ },
  });

// is the same as:

export const linkComponentRef =
  createAdaptableComponentRef<LinkProps, LinkContext>({ id: 'link' });

export const Link =
  implementAdaptableComponent(linkComponentRef, {
    Provider() { /* ... */ },
    Component() { /* ... */ },
  });

Wiring up the app
Plugins expose adaptations they provide using createComponentAdaptationExtension. The resulting plugin object will have an adaptations property with a typed object keyed to the provided adaptations:
const githubPlugin = createPlugin({
  id: 'github',
  // ... ,
  adaptations: {
    link: createComponentAdaptationExtension(linkComponentRef, {
      id: 'github-link-adaptation',
      Adaptation({ value, Component }) { /* ... */ },
    }),
  }
});

githubPlugin.adaptations.link; // is the adaptation above

When wiring up the app using createApp, we can choose which adaptations to use:
createApp({
  // ...
  adaptations: [
    githubPlugin.adaptations.link,
    pluginX.adaptations.y,
    // ...
  ],
});

We can also choose to use all adaptations provided by the plugins by default, and opt-out of certain adaptations (or entire plugins), as well as including non-plugin provided adaptations:
createApp({
  // ...
  adaptations: {
    // Don't load _any_ adaptations from these plugins:
    excludePlugins: [
      pluginX,
      pluginY,
    ],
    // Don't load these particular adaptations:
    exclude: [
      pluginA.adaptations.foo,
    ],
    // Load these non-plugin adaptations:
    include: [
      myAdaptation1,
      myAdaptation2,
    ],
  },
});

Future concerns and thoughts
Errors in adaptations
Adaptations can (and therefore, in the future, will) have errors in them. That will propagate upwards the component tree to the nearest ErrorBoundary.
This PR currently won't wrap adaptation logic in try/catch (interceptProps) or Provider components in local ErrorBoundary. Perhaps that would be good to do. That way, we could silently unfail adaptations, but leave the component be. The error can be sent to the error log.
Link
The Link (which is turned into an adaptable component in this PR) has analytics logic hard-coded in it. Using the mechanisms in this PR, that could be replaced with an analytics plugin adapt Link and inject such logic that way.
We need a lot less coupling with esoteric logic in components when they are adaptable like this.
Adapt-all-the-things
It's probably not a good idea to preemptively turn all components into adaptable ones, but rather on a by-need basis. Especially as it's not always obvious what part of a component should be adaptable. As mentioned here, the Link is certainly useful. So are probably Button, Avatar, EmptyState, SupportButton and a few more. Apart from that, it would make sense for contributors to send PR's to turn components into adaptable ones when needed, as well as expanding on what can be adapted (for already adaptable components) together with a brief rationale of why this is needed.
Example
This PR contains a commit in which the GitHub actions plugin adapts Link. This is a dummy example, so THIS PR SHOULDN'T BE MERGED until that commit is removed. It's there to play around with for those who check out this branch locally. It currently appends "(this link goes to GitHub)" to each link's text, if the link goes to github.com. One can imagine instead rendering useful badges, hover tooltips or similar.

Thanks @kuangp, really great feedback!

Added required id to extendable components (as discussed in https://github.com/backstage/backstage/pull/11819#discussion_r888715834).
If we get something like https://github.com/backstage/backstage/pull/10260 merged, it could show a list of extensions and which one of them that are added to the app and which aren't.

Thanks for the feedback @Rugvip!
I think the main reasons for actually using components, rather middleware approach would be:

Middleware semantics are kind of broken similarly to callback based asynchrony (unlike promises). Missing to call next(), where would thrown errors end up?, calling next() but not returning but doing more things, maybe throwing, calling next() twice, etc. I've always found the code flow in callback based logic to easily become very iffy and hard to reason about, and hard to test. Unlike with promise/observable semantics, which React components are closer to.
Hook safety. An extension will likely use some hooks and then if/else return different pathways. If you chain multiple such extensions, the number of hooks (and the same hooks) might not match every render, which they must. Letting each component be a pure regular component, makes this a lot more clear and easy to reason about. We can also write test helpers to easily test these extensions (by wrapping the props it'll get).
Mixing middleware next with components: <Badge>{next()}</Badge> is iffy.

If very often returning the same glue (when only changing context values) is too expressive and cumbersome:
return <ComponentProvider value={...}>
  <Component />
</ComponentProvider>

we could certainly have a shortcut prop you can use, (called Next, say) but still being a real component:
return <Next value={...}/>

Wouldn't that feel very reasonable? It's practically as clean, but won't cause confusion as to what "next" is.
But then, maybe ComponentProvider could be allowed to be childless to do the same thing? If we rename ComponentProvider to Extend, it can be both these?
return <Extend value={...} /> // without children
// is a shortcut form of:
return <Extend value={...}><Component /></Extend>

Playing around with this code, and thinking twice about that shortcut, I wonder if it would make more sense to only have Component.

If returned as is return <Component /> then you don't alter the context. You can still wrap it in anything, like <Tooltip>.
If returned with a value: <Component value={...} /> then you alter the context.

No need for an explicit provider, no shortcut syntax. We could call this <Next /> and <Next value={...} /> instead, but that name wouldn't be as indicative of that what you render is (most likely) the real inner component.

To clarify, the intentions of the next function is that it's a render method, wrote it like that just to look more like middleware. Another way to write it that is a bit closer to your structure would be this:
extendComponent(linkComponentRef, {
  decorate(props, Component) {
    if (!isLinkToPr(props.to))
      return <Component {...props} />

    const status = useGithubPrStatus(getPrFromLink(props.to));
    if (!status) {
      return <Component {...props} />
    }

    return (
      <Badge color={prColorFromStatus(status)}>
        <Component {...props} />
      </Badge>
    )
  },
})

or
extendComponent(userCardComponentRef, {
  decorate(props, next) {
    if (!shouldHaveExtraActionButton(props)) {
      return <Component {...props} />
    }

    return <Component
      {...props}
      actionButtons={[
        ...props.actionButtons,
        {
          text: 'My action',
          onClick: () => { /* ... */ },
        }
      ]}
    />
  },
})

Either or really, don't have any strong opinion on which way. Important thing is that hooks work.

Yeah, I think we're approaching this very similarly. Only having Component is extremely slick. Whether context providers are used or not can be entirely transparent to the API surface.

Renamed extendable/extension adaptable/adaptation. Adaptation component Provider -> Adaptation.
Both adaptable components and adaptations themselves can now be lazy-loaded (dynamic import)
No forced opt-out, but either opt-in or opt-out
Can create adaptable component refs separately from implementation (good for dynamically imported implementations)
Adaptations are provided by plugins using createComponentAdaptationExtension (which creates an Extension<T>)

Opt-in / opt-out
Now when spinning up the app, by default no adaptations are loaded. You can opt-in and load them individually. Plugins provide them using createPlugin and they are available (named) on the plugin object:
createApp({
  // ...
  adaptations: [
    githubActionsPlugin.adaptations.link,
    // ... more adaptations
  ],
});

or you opt-out and load all plugins' adaptations by default:
createApp({
  // ...
  adaptations: {
    // Don't load _any_ adaptations from these plugins:
    excludePlugins: [
      pluginX,
      pluginY,
    ],
    // Don't load these particular adaptations:
    exclude: [
      pluginA.adaptations.foo,
    ],
    // Load these non-plugin adaptations:
    include: [
      myAdaptation1,
      myAdaptation2,
    ],
  },
});

Separate component ref factory
When creating an adaptable component, you can create the component ref first:
const myComponentRef = createAdaptableComponentRef({ id: 'my-component:v1' });

Then implement it:
const MyComponent = implementAdaptableComponent(myComponentRef, {
  Provider() {
    // ...
  },
  Component() {
    // ...
  },
});

This can make sense if you want to structure a plugin that way.
Lazy-loading
createAdaptableComponent, createAdaptableForwardableComponent (and implementAdaptableComponent) can now either take a Provider component or an asyncProvider function. The same goes for the Component and asyncComponent. This allows for lazy-loading the component implementation.
createAdaptableComponent<Props, Context>({
  id: 'MyComponent:v1',

  Provider: ({ props, Component }) => {
    return <Component value={...} />;
  },
  // or
  asyncProvider: () => import('./my-component').then(m => m.Provider),

  Component: ({ value }) => {
    // ...
  },
  // or
  asyncComponent: () => import('./my-component').then(m => m.Component),
});

It's still as typesafe.
For the adaptations, the same goes there:
createComponentAdaptationExtension(fooComponentRef, {
  id: 'my-plugin-foo-adaptation',

  Adaptation() { /* ... */ },
  // or
  asyncAdaptation: () => import('./extensions/foo').then(m => m.Adaptation),
}),

Lazy-loaded adaptations
When a component renders and has an adaptation provided that is lazy-loaded, by the nature of adaptations (they aren't supposed to be necessary, but entirely opt-in), the adaptation will load asynchronously, and the component will still render without the adaptation. When loading is complete, the adaptation is then applied. This means that there will be no lag to wait for adaptations before rendering components.

Updated PR message to reflect the latest changes

Fixed the issue of having a versioned context keyed on component ref objects (which could have multiple instances), into using the id (string) instead.
As discussed with @kuangp, being able to locally (in terms of React component tree) "unregister" previous adaptations would be good; Added reset, excludePlugins, excludeComponents and exclude to the AdaptationProvider:
<AdaptationProvider
  reset                     // Resets _all_ previous adaptations downstream from here
  excludePlugins={[...]}    // Exclude (reset) all previously registered adaptations from these plugins
  excludeComponents={[...]} // Exclude all previously registered adaptations for this/these component ref(s)
  exclude={[...]}           // Exclude specifically these previously registered adaptations
  adaptations={...}         // Start using these adaptations
>
  <ChildrenGoHere />
</AdaptationProvider>

All props are optional, so you can e.g. reset (but not having to add new adaptations), or just add new (without resetting previous ones), or any combination.
It's also not an error to exclude adaptations or plugins that actually weren't registered. That'll just be ignored.

[Renamed, refactored] Adaptable components
The latest commits changes how these adaptable components are created in a big way, after discussions with the maintainers.
Instead of having adaptable components have props only read-only through the adaptation chains, and a separate type Context being the values that can be (are allowed to be) changed, it's all props now.
An adaptable component, say Link has its props, same as before. Some of these props can be altered by adaptations. So, the interface for adaptations is the pair of LinkProps and a string union of which of the props are adaptable, e.g. 'to' | 'children'.
Abstract
We still have the ability for adaptable components to have an outer and an inner part, inbetween which adaptations will be injected.
The outer part is called the Prepare component. The inner is simply called Component. When this is rendered, the result will be:
<Prepare>
  <Adaptation1>
    <Adaptation2>
      ...
      <Component>

Unless the adaptable component needs to prepare props for adaptations, the Prepare can be ignored. This will be common.
Both of these are React components. For dynamic imports, you can instead provide asyncPrepare and asyncComponent when creating an adaptable component.
API: Adaptable component
An example of the adaptable Link component:
const adaptableLink = createAdaptableForwardableComponent<
  LinkProps,        // The adaptable Link has these props
  'to' | 'children' // And these props are adaptable, the rest not (readonly)
>({
  id: 'link:v1',
  Component: ({ props: { onClick, noTrack, ...props }, info: { ref } }) => {
    // ... actual <Link> code goes here.
    return <MuiLink {...someProps} />;
  },
});

export const linkComponentRef = adaptableLink.componentRef;
export const Link = adaptableLink.Component;

In this example, we skip providing a Prepare component, as we don't need to prepare any data for adapations, but it'd be a component side-by-side with Component.
API: Adaptation
An adaptation is a component and/or a simple "props interceptor" (a sync function props => adaptable props).
The adaptation is exposed/exported when creating a plugin, and added to the adaptations property. An adaptation is created using the componentRef to refer to the adaptable component. This binds them together, and ensures type safety.
// "My plugin" provides an adaptation to the "foo" component
// which may reside in another plugin

import { fooComponentRef } from '@acme/components';

export const myPlugin = createPlugin({
  id: 'my-plugin',
  adaptations: {
    link: createComponentAdaptationExtension(fooComponentRef, {
      id: 'my-plugin-foo-adaptation',
      asyncAdaptation: () => import(/*...*/),
      interceptProps: props => ({someProp: 'some-value'}),
    }),
  },
  // ...
});

Props interceptor
When all you need is a synchronous function rewriting props, use a props interceptor.
export const myPlugin = createPlugin({
  id: 'my-plugin',
  adaptations: {
    link: createComponentAdaptationExtension(fooComponentRef, {
      id: 'my-plugin-foo-adaptation',
      interceptProps: props => ({someProp: 'some-value'}), // <-- this
    }),
  },
  // ...
});

The props interceptor takes a props object as input, and returns an object with the rewritten props. The return type excludes the props that shouldn't be rewritten, only the adaptable props should be included.
Component-based adaptation
As in the example above;
export const myPlugin = createPlugin({
  id: 'my-plugin',
  adaptations: {
    link: createComponentAdaptationExtension(fooComponentRef, {
      id: 'my-plugin-foo-adaptation',
      asyncAdaptation: () =>
        import('./adaptations/foo.tsx').then(m => m.Adaptation), // <-- this
    }),
  },
  // ...
});

This creates a dynamically loaded adaptation, which is defined in ./adaptations/foo.tsx. A component-based adaptation is referring to the componentRef of the adaptable component, to get the types induced for the adaptable props. Specifically if using the type value TAdaptation which holds the type of an adaptation of the component.
// foo.tsx

// The fooComponentRef encapsulates the type of the component, and the adaptable keys
import { fooComponentRef } from '@acme/components';

export const Adaptation: typeof fooComponentRef.TAdaptation = ({
  props,
  Component,
}) => {
  // ... code goes here, e.g.: ...

  const shouldAdapt = decide(props.something);

  if (!shouldAdapt)
    // Don't adapt, just forward
    return <Component />;

  // Change/set some prop(s)
  return <Component set={{ someProps: 'some-value' }} />;
};

ping @backstage/maintainers, last push is a heavily simplified version, as discussed previously.
I can rebase and fix conflicts if you feel confident this would suffice for merging.

@grantila thank you! gonna try to find some time to have a proper look at this. I think it's best if you could handle the conflicts either way tbh? Just to make sure we're looking at the most up to date version

This sounds very useful! Has this been put on hold in favour of something else?


Apparently wrong framing of videos

The videos of evolved robots (so those running decently fast) appear to have a wrong composition of the frame, with the robot not being in the center, neither along $x$-axis, nor along $y$-axis. The latter should instead be centered.

Solved (still to be ported in a version of 2dmrsim here)!


Cannot Get App to Init

Hi,
First, thanks for making this utility.
I have been unable to get my app to initialize after converting my app to utilize AngularAMD. I have no idea why its not working, and therefore, have no where to begin troubleshooting.
Essentially, my app.js file is loaded and parsed, but execution never happens
Here is my main.js
require.config({
baseUrl: "js/",

// alias libraries paths
paths: {
    'jquery': 'https://ajax.googleapis.com/ajax/libs/jquery/1.11.3/jquery.min',
    'bootstrap': 'http://maxcdn.bootstrapcdn.com/bootstrap/3.3.6/js/bootstrap.min',
    'angular': 'https://ajax.googleapis.com/ajax/libs/angularjs/1.4.2/angular',
    'angular-route': 'https://ajax.googleapis.com/ajax/libs/angularjs/1.4.2/angular-route.min',
    'angularAMD': 'angularAMD'
},

// Add angular modules that does not support AMD out of the box, put it in a shim
shim: {
	  'angularAMD': ['angular'],
    'angular-route': ['angular'],
    'bootstrap': ['jquery']
},

// kick start application
deps: ['app']

});
Here is my app.js:
define(['angularAMD', 'angular-route', 'controllers/ctrlOne', 'controllers/ctrlTwo'], function(angularAMD) {
'use strict';
var app = angular.module('MyApp', ['ngRoute']);
console.log(app);
// yada yad yada
});
Can you tell me why that console.log() call never fires? I am using Firebug to set breakpoints where the yada yada yada comment is, but none of the code in the block executes. Can you see anything that I'm doing wrong?

@stljeff1 is that all of the content of your app.js ?
If yes then you will need something like.
// config your app
app.config(/* your config goes here... */);

// code...

// bootstrap with angularAMD and return an object, so requireJS/angularAMD can use it later
return angularAMD.bootstrap(app);

Also I can see that you are calling angular in your app.js without define the alias in define() block or config global alias in shim


Please consider fixing issues detected by repository checker

Notification from ioBroker Check and Service Bot
Dear adapter developer,
I'm the ioBroker Check and Service Bot. I'm an automated tool processing routine tasks for the ioBroker infrastructure. I have recently checked the repository for your adapter weather-warnings for common errors and appropiate suggestions to keep this adapter up to date.
This check is based the current head revisions (master / main  branch) of the adapter repository
Please see the result of the check below.
ioBroker.weather-warnings
   -
ERRORS:

[ ] :heavy_exclamation_mark: [E507] missing size attributes [xl] for select at admin/jsonConfig.json/items/_dwdpanel/dwdLanguage
[ ] :heavy_exclamation_mark: [E507] missing size attributes [xs,sm,md,lg,xl] for text at admin/jsonConfig.json/items/_whatsapp/whatsapp_Phonenumber

:thumbsup: No warnings found
:thumbsup: No suggestions found
Please review issues reported and consider fixing them as soon as appropiate.
Errors reported by repository checker should be fixed as soon as possible. Some of them require a new release to be considered as fixed. Please note that errors reported by checker might be considered as blocking point for future updates at stable repository.
You may start a new check or force the creation of a new issue at any time by adding the following comment to this issue:
@iobroker-bot recheck
or
@iobroker-bot recreate
Please note that I (and the server at GitHub) have always plenty of work to do. So it may last up to 30 minutes until you see a reaction. I will drop a comment here as soon as I start processing.
Feel free to contact me (@iobroker-bot) if you have any questions or feel that an issue is incorrectly flagged.
And THANKS A LOT for maintaining this adapter from me and all users.
Let's work together for the best user experience.
your
ioBroker Check and Service Bot
Note: This issue replaces issue #151
@mcm1957 for evidence
Last update at Sun, 10 Nov 2024 14:44:13 GMT based on commit f5d5b286fbdcc50a4d3b471be8c441b05519b42f
ioBroker.repochecker 3.2.2

@iobroker-bot recheck


Fix openshift-extra is same as openshift

Hi,
Thank you for the helpful tools,
but it seems the Dockfile in openshift and openshift-extra are the same,
so there is no extra tools in openshift-extra.
I have edited it basic on branch "openshift" and "alpine-extra"

it turns out the bug is already mentioned in issues: https://github.com/wbitt/Network-MultiTool/issues/1
and it seems my merge is not a functional version (tested in openshift) so I will close this pull request.


Need to update about bots article to reflect changes in the ActivityHandler class

The ActivityHandler now has new message reaction handlers.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 4ccf81d0-a7a0-1e2a-5b35-8cfd723c1225
Version Independent ID: e3ebe0a1-a22f-1535-c649-3f79158b4ece
Content: How bots work - Bot Service
Content Source: articles/v4sdk/bot-builder-basics.md
Service: bot-service
Sub-service: sdk
GitHub Login: @johnataylor
Microsoft Alias: johtaylo

fixed in PR.


feat(resourcesList): update blog links in nav

Overview

Update links to blog in resource list.

PR Checklist

[ ] Related to designs:
[x] Related to JIRA ticket: REACH-2420
[x] I have run this code to verify it works
[ ] This PR includes unit tests for the code change
[ ] This PR includes testing instructions tests for the code change
[ ] The alpha package of this PR is passing end-to-end tests in all relevant Codecademy repositories

Testing Instructions

Don't make me tap the sign.
PR Links and Envs

Repository
PR Link
PR Env

Monolith
Monolith PR
Monolith Env

Portal
Portal Link
Portal Env

Another Repo
Another Link
Another Env

📬Published Alpha Packages:@codecademy/gamut-kit@0.6.265-alpha.c372ae.0@codecademy/gamut-labs@34.1.0-alpha.c372ae.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://63c728b665342b4b39e2f92d--gamut-preview.netlify.appDeploy Logs


#20 cal test pr

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.McXymmer seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Use correct column name in GpuIf test [databricks]

Signed-off-by: Andy Grove<EMAIL_ADDRESS>Closes https://github.com/NVIDIA/spark-rapids/issues/4386
The first commit updates the test test_conditional_with_side_effects_cast to fix an error where the test was referencing the wrong column. This worked fine in Apache Spark presumably due to implicit casts being added. The test failed in Databricks.
The second commit simplifies the side-effect tests to use unary_op_df instead of two_col_df since these tests only reference a single column.

build


alpha installed instead of latest stable release

Describe the bug
pip3 install mariadb installs mariadb-1.1.1-alpha instead of latest stable
Expected behavior
Should install mariadb-1.0.7
To Reproduce
pip3 install mariadb
My Platform
Linux 64-bit, Ubuntu 20.10
Additional context
classifiers in setup.py contains "'Development Status :: 3 - Alpha',"

Hi, this issue tracker is for issues with the codebase behind https://pypi.org itself, not the projects hosted on PyPI.
This release was not published with a pre-release version and thus pip does not consider it a pre-release. Classifiers are not used during dependency resolution to determine pre-release status, so this is working as expected.
You should report this issue to the tracker for the project in question instead, asking them to yank the current releases and publish them with pre-release specifiers instead.


LAStools: 201003 -> 2.0.0

Motivation for this change
Per https://github.com/LAStools/LAStools/releases/tag/v2.0.0:

Due some requests we start to use the git release feature starting now.
LAStools use a versioning in YYMMDD scheme. This is common for most LAStools users for long time - so we keep this version numbers.
Additionally we will follow the git versioning guidelines for the open source releases. They may also flow into sourcecode next.
Cause we have quite something like a history we start straight away with version 2.0.0.

Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] 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/)
22.05 Release Notes (or backporting 21.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
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

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

1 package built:

LAStools


Optional class/id attribute

First off, great little plugin!
One small issue. It's purely aesthetic. The way Sanity spaces the fields in the form makes it feel like these notes aren't directly related to the field they're above. I'd like to bring the bottom margin down on these notes, so they look more like they're a part of the field for which they're noting, but there's currently no reliable identifier on the markup to hook into.
Can you please give the outer Card element a specific class name like sanity-plugin-note-field or let us add our own classes to the rendered Card element?
And before you say open a pull request, I probably will not. This seems simple enough to get around to whenever you can get around to it. Correct me if I'm wrong though. Maybe it's not trivial. ¯_(ツ)_/¯
It's a subtle change, but I think it makes a big difference.
Thanks!

Hey there @jamestrenda!
I totally understand your request, however note fields were never intended to be "related" to adjacent fields. They are stand-alone fields, much like any other field you'd add to your schema.
Additionally, the spacing between fields is not controlled by this plugin, but rather by the core Sanity Studio, through the use of a <Stack /> component.
There's no elegant way to provide a negative margin to negate the stack spacing, as that's not a valid value per the Sanity UI specs.
However, I think what I'd be willing to do is add a data-note attribute so that you could more easily target the field via custom CSS.
I can add this in on the next release 🤘


Deprecate Python 3.8 support

Summary
This commit deprecates Python 3.8 support. During the deprecation window we will continue to fully support Python 3.8 and test it in CI, but it will emit a warning that we will be removing support for 3.8 in the future to inform users to upgrade to Python 3.9 or newer. The removal will occur during the Qiskit 1.3.0 release as it is the first release scheduled to occur after the upstream Python EoL date in October 2024. [1]
On the development side once we create the stable/1.2 branch on the 1.2.0rc1 release, then we can drop Python 3.8 support and raise the minimum Python version to 3.9 (including in CI).
Details and comments
[1] https://devguide.python.org/versions/

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

2 of 2 (100.0%)  changed or added relevant lines in 1 file are covered.
6 unchanged lines in 2 files lost coverage.
Overall coverage increased (+0.007%) to 89.346%

Files with Coverage Reduction
New Missed Lines
%

crates/qasm2/src/expr.rs
1
94.03%

crates/qasm2/src/lex.rs
5
92.62%

Totals

Change from base Build<PHONE_NUMBER>:
0.007%

Covered Lines:
60243

Relevant Lines:
67427

💛  - Coveralls


[10.x] Fix route resource in groups

My Code Simplifies the Design of Resource Router Files.
At the moment, we can only write like this:
Route::apiResource('users', UserController::class);
Route::prefix('users')->name('users.')->group(function(){
    Route::get('insecureGet', UserController::class);
});

However, with my fix, the above code turns into a simple and concise code that is inside the group, and does not go beyond it, as the router resources do now:
Route::prefix('users')->name('users.')->group(function(){
    Route::apiResource('', UserController::class);
    Route::get('insecureGet', UserController::class);
});

I consider this a bug that was made at the initial stage of development of groups and resources in version 7.x.
#46593, #46547

Hi all!
I wanted to use a route resource inside an existing group without an additional name, however this was not possible, so I added the appropriate code.
The reason for this problem was that the ResourceRegistrar relied in creating the route name and the name of the substitution parameters on the received empty name and did not take it from the name of the last group stack, if one exists.
Please, merge it also to [10.x] branch.
Hi all!
I wanted to use a route resource inside an existing group without an additional name, however this was not possible, so I added the appropriate code.
The reason for this problem was that the ResourceRegistrar relied in creating the route name and the name of the substitution parameters on the received empty name and did not take it from the name of the last group stack, if one exists.
Please, merge it also to [10.x] branch.

Thanks for your pull request to Laravel!
Unfortunately, I'm going to delay merging this code for now. To preserve our ability to adequately maintain the framework, we need to be very careful regarding the amount of code we include.
If possible, please consider releasing your code as a package so that the community can still take advantage of your contributions!
If you feel absolutely certain that this code corrects a bug in the framework, please "@" mention me in a follow-up comment with further explanation so that GitHub will send me a notification of your response.


Replace k-means clustering with advanced k-means clustering

For a while, we have internally used an updated k-means clustering add-on for SpectralAnalysis. "Advanced k-means clustering" adds the following

5 distance metrics (Squared Euclidean, Manhatttan, Cosine, Correlation and Hamming)
3 initial cluster selection parameters  (Random, uniform random and preclustered)
The option of running replicate clustering runs
Choice of action on empty cluster formation (Error, remove or create new)
Option for online update phase (On, off)

I have also removed the old k-means clustering addon in this pull request to avoid confusion.
The script was originally written by Alex Dexter.

Hi Adam,
Thanks for your contribution. The latest version of k-means includes some of these, not all, but also includes some new functionality for optionally removing small spatial clusters. Missing are still initial cluster selection, empty cluster formation and online update phase.
Can you update the latest version with these features please?
Thanks,
Alan


Provide an example for AnySigner usage in v2.x for Go / C++

Is your feature request related to a problem? Please describe.
Because of the AnySigner refactoring the old AnySigner example  no longer works making the binary linked to recent wallet-core version crashing.
terminating with uncaught exception of type std::invalid_argument: Invalid private key data
SIGABRT: abort
PC=0x7fdc87685e97 m=0 sigcode=18446744073709551610

Describe the solution you'd like
Provide an example for new AnySigner for Go / C++ in samples/go/ samples/cpp/ to ease the pain for developers.
Also add in release notes that AnySigner interface has been changed and what to do in order to make it work again in v2.x version.
Additional context
This issue is actual for wallet-core >= v2.x

WIP in https://github.com/trustwallet/wallet-core/pull/890

Thanks!

@hewigovens there is no Go example though, only C++ one.
Can you add it as well please?
Thank you.


<context.slot> tag addition for “on player item takes damage” event

Could a tag be added for the slot the item taking damage is in?

I believe the event will only fire for the player's held item (not armor/etc) based on the description of the underlying Spigot event. The underlying Spigot event also does not supply slot info.
So, <player.item_in_hand.slot>.
If you can get it to actually fire for equipment/similar, reply below and I'll see about janking a way to get that data.

The event does indeed fire for when armor is damaged via mobs, cactus, explosion, etc.

That's... annoying, that Spigot doesn't have a slot value included.

Added via https://github.com/DenizenScript/Denizen/commit/e0b62d0540a3e05851795bef7f4cb944603c3ed1
Does some quick calculations to try to locate the item. I can't guarantee total accuracy but I think it should be correct.