Reproduce Result

Hi. Thanks your work. Could you show me your training log? I can't reproduce paper's results.
This is my log file and yaml file. I only change the batch-size to 48 because of my memory. Anything else is default.
hrnet_cm64_V1_hrnet.log
hrnet_cm64_V1_hrnet_yml.log

V1_hrnet_nopretrain_h36m,mpiinf,coco,mpii,lsp,muco,crowdpose_g0,1,2,3.log

@panshaohua
What is the number you get? I noticed that you didn't evaluate the results.
The log above is trained from scratch. The results would be much easier to reproduce if you use the pre-train backbone that I provided.

Thank you for your prompt attention.
I found my loss is smaller than you. Is something else wrong?
V1_hrnet_h36m,mpiinf,coco,mpii,lsp,muco,crowdpose_g0,1,2,3.log

It seems that your model gets the best results at Line 2733
['Evaluation'] on local_rank 0 +-----------+-------+----------+ |   DS/EM   | MPJPE | PA_MPJPE | +-----------+-------+----------+ | pw3d_vibe | 90.69 |  52.68   | +-----------+-------+----------+
This PA-MPJPE is even better than what I report in paper.
And then the performance gets worse and worse while traning goes on.
This may indicate that the model was not properly converged for training more epoches with batch size 48.
My log is for traning without any pre-training, in other word, from scratch. So the loss is relative big.

Thanks for your nice response. It's very helpful to me.

So, 5 stars for my service, may I ?
Glad that you like ROMP.

Haha. nice of you and your work!

Come and discuss with me if you like ROMP.
live long and prosper~ :)

It seems that your model gets the best results at Line 2733,
['Evaluation'] on local_rank 0
|   DS/EM   | MPJPE | PA_MPJPE |
| pw3d_vibe | 90.69 |  52.68   |

This PA-MPJPE is even better than what I report in paper. The huge difference between MPJPE and PA-MPJPE shows the domain gap between training and evaluation dataset, such as different skeleton defination, different camera defination, etc. MPJPE could be easily effected by the domain gap.
And then the performance gets worse and worse while traning goes on. This may indicate that the model was not properly converged for training more epoches with batch size 48.
My log is for traning without any pre-training, in other word, from scratch. So the loss is relative big.

Hi, I was wondering that if you meant that it was even without using 'trained_models/pretrain_hrnet.pkl'? I think 'trained_models/pretrain_hrnet.pkl' is pretrained on 2D pose estimation, instead of an initial weights from ImageNet, is this correct?

Both our logs didn't use the pretrain model. Please note that the best results is very likely not achieved by the model of the last epoch.
Yes, pretrained model is pretrained on 2D pose estimation and detection datasets.
To get the results in paper, you may need more epochs for training.
My posted log just takes 80 epochs and didn't use the pretrain model. Please try to train more epochs, you will find the model performs way more better with more training. The converge is relative slow. Because differet from 2D heatmap learning that directly supervise the whole map, we just take a few points from parameter maps for supervision. Infulenced by some uncertainty in training, you may need more time.
Besides, please try to reduce the shuffle_crop_ratio_3d  in v1.yml and add more middle scale augmentation if you can.
Feel free to reach to me, if you have any question.
I may update this respository later to include more training tricks I used to get the best results faster. Sorry I didn't include all of them before.

Both our logs didn't use the pretrain model. Please note that the best results is very likely not achieved by the model of the last epoch.
Yes, pretrained model is pretrained on 2D pose estimation and detection datasets.
To get the results in paper, you may need more epochs for training. My posted log just takes 80 epochs and didn't use the pretrain model. Please try to train more epochs, you will find the model performs way more better with more training. The converge is relative slow. Because differet from 2D heatmap learning that directly supervise the whole map, we just take a few points from parameter maps for supervision. Infulenced by some uncertainty in training, you may need more time. Besides, please try to reduce the shuffle_crop_ratio_3d  in v1.yml and add more middle scale augmentation if you can.
Feel free to reach to me, if you have any question. I may update this respository later to include more training tricks I used to get the best results faster. Sorry I didn't include all of them before.

Happy New Year! Thanks for your quick reply! I think I might just copy my question from my new issue and close that one:
Q1. Did you mean that both of you manually delete the code to automatically load 'trained_models/pretrain_hrnet.pkl' ? I think it's appeared in your log files and the logic of the code is to automatically load it if not args().fine_tune and not args().eval
Q2. I think 'trained_models/pretrain_hrnet.pkl' is a backbone pretrained on 2D pose estimation, instead of initialized weights from ImageNet, is this correct? But I saw the model_path in your log_file is not None, which means you should have used it as well.
As I understand, using v1.yml with pre-trained backbone: 'trained_models/pretrain_hrnet.pkl' should reproduce Table 2 and trained_models/ROMP_HRNet32_V1.pkl. Then, with this model and v1_hrnet_3dpw_ft.yml, should reproduce Table 3. Is this the case?
About fine-tuning:
Yes I have tried fine-tuning on 3DPW using trained_models/ROMP_HRNet32_V1.pkl and v1_hrnet_3dpw_ft.yml, it gave me a very similar results to your paper. And trained_models/ROMP_HRNet32_V1.pkl also gave me the same results as table 2. I'm just  trying to reproduce trained_models/ROMP_HRNet32_V1.pkl, which can be used for table2, and the following fine-tuning process as well

Q1 & Q2: Yes, in my code, it doesn't automatically load / use the pre-train model. You may observe that the loss in my posted log is relatively larger than his.
Q3: Yes, they are supposed to achieve that.
Glad to hear that.  Based on this information, I am more confident that the problem is more training time.
I took about two weeks to get ROMP_HRNet32_V1 with my previous code on 4 V100. How long did you take?

Q1 & Q2: Yes, in my code, it doesn't automatically load / use the pre-train model. You may observe that the loss in my posted log is relatively larger than his. Q3: Yes, they are supposed to achieve that.
Glad to hear that. Based on this information, I am more confident that the problem is more training time. I took about two weeks to get ROMP_HRNet32_V1 with my previous code on 4 V100. How long did you take?

Wow, so your log is completely training from scratch then, even without pre-trained backbone (not model, but backbone) and ImageNet? It's 80 epochs and still can't reproduce yet, so I guess it might take weeks to reproduce Table 2. But I think with your current code (which will automatically load pre-trained backbone), it will still need more or less the same time.
In fact, I found my performance is similar to your log, even with your current code, v1.yml, which will automatically load pre-trained backbone: 'trained_models/pretrain_hrnet.pkl', which I think it's pretrained on 2D pose estimation, and I trained for 2 days, less than 20 epochs.
Well I have to say that it's only a slightly better than yours. You spent only 9 epochs to get 91.57 |  52.97, and the following 68 epochs didn't really improve the results significantly as it's not even evaluated.
Using batchsize16, I can get similar results (91.87 | 53.49) in the fourth epoch and a slightly worse one in the first epoch 91.65 |  54.54.
But it's strange that it's a bit worse when I use 16 batchsize with 4 accumulation gradients, which should be similar to 64 batch size. Anyway, seeing from their best results, both of them can get PA_MPJPE  around 53~53.5. and MPJPE around 91~92.5 in the first 6 epochs
It's indeed faster in the first 5 epochs, But after that, I see no significant improvements.
So, I think in the long term, to fully reproduce your results of table 2, with only several epochs faster, using the pre-trained backbone or not doesn't really matter. Is this correct? If you didn't use pre-trained 2D pose estimation backbone at all, I think Pre-trained backbone is not really necessary then, 12 epochs it only several hours ahead of 4 epoch

Yes, I agree with you on most part. Really appreciate your interests in ROMP.
Here are some observations that might helpful.
1.The evaluation is only performed when we get better results on validation set, but this doesn't represent that the model is not getting better on test set.
2.I didn't try batch size 16, but ROMP_HRNet32_V1.pkl is trained with batch size 64.
3.Pretrain is necessary in two aspects, better detection and robustness in crowded scene.
3DPW is a great benchmark. It greatly promotes the development of this field. But it only contains ground truth of 1/2 people in the video lacking enough crowded scenes. Similarly, most training datasets, including 2D pose datasets, is relatively weak in this aspect. With pretraining on benchmarks like CrowdHuman, we are able to get a model that more robust for more challenging scene. In one word, we need to expect more than what current benchmark evaluation can reflect.

Yes, I agree with you on most part. Really appreciate your interests in ROMP. Here are some observations that might helpful. 1.The evaluation is only performed when we get better results on validation set, but this doesn't represent that the model is not getting better on test set. 2.I didn't try batch size 16, but ROMP_HRNet32_V1.pkl is trained with batch size 64. 3.Pretrain is necessary in two aspects, better detection and robustness in crowded scene. 3DPW is a great benchmark. It greatly promotes the development of this field. But it only contains ground truth of 1/2 people in the video lacking enough crowded scenes. Similarly, most training datasets, including 2D pose datasets, is relatively weak in this aspect. With pretraining on benchmarks like CrowdHuman, we are able to get a model that more robust for more challenging scene. In one word, we need to expect more than what current benchmark evaluation can reflect.

Thanks! So actually, if we only talk about the evaluation on 3DPW dataset, instead of further application, pre-training is not really indispensable, right (Seeing from the logs) ?

Yes, you can see it in that view.Get Outlook for Android

Yes, you can see it in that view.Get Outlook for Android

These 2 days, I have tried to comment this line of code and trained with v1.yml, but the performance is quite different from yours:
https://github.com/Arthur151/ROMP/blob/d463cbccc6a4456270d8d52fcfa1e9e26b6c4f02/romp/lib/models/modelv1.py#L34

The only difference is that I adapt the batch size to 16, and another setting to 16 with gradients accumulation 4 (which should be similar to 64). However it's much worse from your log and what I expected:
bs16x4_load.log
bs16x4_not_load_backbone.log
bs16_load.log
bs16_not_load_backbone.log

Once I comment the code that used for loading pre-trained backbone, the training completely failed with huge MPJPE... and RuntimeError: svd_cuda: (Batch element 0): The algorithm failed to converge because the input matrix is ill-conditioned or has too many repeated singular values (error code: 4).
16 batch size worked when I load pre-trained backbone(pretrain_hrnet.pkl)  or fine-tune, because I can get a similar result to his log using both 16 and 16*4. And I can get a similar result to table 3. using your pre-trained model ROMP_HRNet32_V1.pkl. What do you think might cause this? It's a quite huge deviation which I don't think is simply due to batch_size.

I have looked into your previous version of ROMP, it seems that from 2021.9.10, when you first released the training code, it already had the code to automatically load the pre-trained backbone. Can you still remember which version you were using actually?:
https://github.com/Arthur151/ROMP/blob/ee5e2f21f35a1072327a11ecd4a36c0c64d805e1/romp/lib/models/modelv1.py#L34

A lot of works have been made during Spring festival. You are too hard-working :+1: .
About your question.
I think that you might need to uncomment this line to start from a good intialization at least.
I have maintained my own version of ROMP & BEV for training, which is a little different from the one released. I will release the latest version with BEV in next update.
About training from scratch, there are some essential tricks that might take care of. Firstly, to ensure converge, the model need to learn from cropped single-person image firstly, which is much easier to learn than crowded image. To make this, we need to set shuffle_crop_ratio_3d=0.9, shuffle_crop_ratio_2d=0.9, which is the original effectiveness of these two settings. I think I might have done this before the formal training.
Without pretraining, we really need a large batch size to make it converge.

I think there is no need to uncomment the init_weights() in hrnet.py as it's already a part of ROMP(). self.modules in ROMP() would also return HRNet components as its children. And, in your last history version before releasing training code, there was no init_weights in hrnet.py as well.

I tried shuffle_crop_ratio_3d=0.9, shuffle_crop_ratio_2d=0.9 today. Although your log shows 0.4 and 0.1 as in v1.yml. However, the results are still far from yours. After epoch0 and epoch1, the MPJPE/PA_MPJPE is still approaching 180-200 and 100-120:
batch16.log
batch16x4.log

It's weird that I can get similar results like his when loaded the pre-trained backbone but having huge deviation from yours if not.
Are there any other differences between your version and the released version? Maybe 'cfg.new_training'? Have you ever tried to use the released code without self.backbone.load_pretrain_params() ?

No, I didn't try to train from scratch using released code. It would take weeks to go through the pretraining process. You will see it slowly converge to the performance similiar to the one with pretraining backbone.
Besides, I look into you log. There are some weird things. The loss of 16x4 is not the sum of det and reg loss. It seem like that the loss is averaged? Please check to ensure that using gradient caching has similar effects with using large batch size. We all know that large batch size is critical for the normal converge, especially in pretraining process.

No, I didn't try to train from scratch using released code. It would take weeks to go through the pretraining process. You will see it slowly converge to the performance similiar to the one with pretraining backbone.
Besides, I look into you log. There are some weird things. The loss of 16x4 is not the sum of det and reg loss. It seem like that the loss is averaged? Please check to ensure that using gradient caching has similar effects with using large batch size. We all know that large batch size is critical for the normal converge, especially in pretraining process.

No it just take several hours to confirm that its performance is similar to your own version (e.g. in the first several epochs).
The 16x4 version's loss is devided by 4 as suggested, simply adapted as below:

Anyway, I might be able to use large GPU in couple days, I would try again with the large ones then. With only 2 changes, comment self.backbone.load_pretrain_params(), and two crop ratio=0.9.

Sure, thanks for your interest. I may check this later.

@ZhengdiYu , besides, for the nan loss, you can use torch.isnan() to avoid its influence. About your problem, I have launch a training to locate the problem. Please consider to give more time for training from scratch. You will see the performance gets much better if you give ROMP enough training time. More time for training, better performance you could see.

@ZhengdiYu Hi, I have tried last night. Till now, the log is similar to yours.
V1_hrnet_nopretrain_check_h36m,mpiinf,coco,mpii,lsp,muco,crowdpose_g0,1,2,3.log
You are right. I might have load the pre-trained backbone before.
I have found the reason that occurs NaN loss. It is caused by the pkp2d loss. I will try to fix this in next update.

@ZhengdiYu Hi, I have tried last night. Till now, the log is similar to yours. V1_hrnet_nopretrain_check_h36m,mpiinf,coco,mpii,lsp,muco,crowdpose_g0,1,2,3.log You are right. I might have load the pre-trained backbone before. I have found the reason that occurs NaN loss. It is caused by the pkp2d loss. I will try to fix this in next update.

Thanks for your updates. I can see that your loss is lower than mine, maybe due to the large batch_size, but the MPJPE is indeed not as expected, although, still better than mine. However it seems yours is able to converge, now it's only 300 loss with 200 reg loss, I think it's not far from the converged loss. Let's wait and see. I think we can wait for some time and let's see what will happen to yours next.

Sorry, I was just to verify the log and bug. Currently, I have to move on to other urgent tasks. I will continue the training later when the schedule is available.

Sorry, I was just to verify the log and bug. Currently, I have to move on to other urgent tasks. I will continue the training later when the schedule is available.

That's OK! Thanks for your help~ Good luck


Build against 2.14.0

Need to update as:
https://github.com/tensorflow/tensorflow/blob/66b9b9befaf3f63be26f8ea68c0200deda0a0244/ci/official/requirements_updater/README.md
Same issue reported in #2849

Hi @seanpmorgan, TF 2.14 has been released. Any luck with the TF addons build?

Same thing we did against TF2.13 build. Given that we have about ~3 more releases left , I think we can just keep the lights on and not take the bazel workspace dependency on TF2.14 with hermetic python. The custom ops are compiled against TF2.14 as is written to .bazelrc
Open to a PR to clean up the build env (will also try to clean it up if I can get some free cycles).  tensorflow/build is still publishing a container for each python version so I don't see a huge need to adopt the new build strategy.


Configure Azure Pipelines

This pipeline configuration builds the application and produces a build for the Release configuration.

 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.:x: vaishalimo sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

hgh


Proposal for a new fixed fee plan

Our current business model is to take 5% of all donations coming through the platform. We picked this because this is what most crowdfunding websites are doing. So it was easy to explain and justify to everyone when we started.
Today, we think that this business model might not be the best to achieve our goal of building the common infrastructure for open communities around the world (in the same way that Wordpress built the needed common infrastructure for the blogging revolution).
That's why we want to test a new tiered pricing model and get feedback from the community. Our initial plan would be to test this with European collectives (in euros). That way we don't impact the majority of our existing collectives and we can see how things are going in one region. It's above all a learning opportunity.
Main objectives

Reduce the friction for communities to create an open collective
Grow the Open Collective platform and become financially sustainable

Why a commission based business model might not be the best for all communities?
The first reaction from people when they hear that we take a commission on their income is quite negative (5% platform fee and usually another 5% for the non profit fiscal host). It deters a lot of people from creating an open collective.
It hasn't been too much of a problem for open source communities because Open Collective is a real pain killer for them. Without Open Collective, there is really no other easy way to emit invoices to companies who want to support them financially. Each community would have to create and maintain a legal entity which is a massive overhead that could and should be mutualized (that's why we created the Open Source Collective 501c6 which is now already hosting 897 open source projects).
Also in the US, the concept of fiscal sponsorship is fairly well known. And the rate of 10% is a common industry rate. In Europe, much less so.
Once we get outside of online communities, open collective is not a pain killer (yet) but just a vitamin, an expensive one. In meat space, people can always accept cash. People trust one another much more as well. So they can receive a donation on a personal bank account on behalf of the community. All of that is a pain to manage but it's doable. Open Collective can definitely help but no way they are going to pay a 10% cut for this service.
That's why if we want to grow, we need to reduce the friction to get started.
It should be free to start a collective and get the first donations rolling.
We have also heard the feedback that people would much prefer pay a fixed amount every month rather than a commission so that they can better budget it and plan for it.
There are also some technical reasons why we may want to consider another business model: some payment methods don't allow us to automatically take a cut (e.g. paypal or manual wires to the bank account of the collective that is owned by the host). So it would be easier to eventually move everyone to a monthly bill for the platform fees. It will also make it easier for everyone's accounting. And backers won't feel like we are taking a cut out of their donation.
Last but not least, it would also change how we prioritize features. Instead of solely focusing on the amount of money going through the platform, we will focus more on other features that are needed by collectives to thrive (see also our blog post: rethinking the tools for collectives).
New tiered pricing (proposal)
Here is a first proposal for a new pricing model. The monthly budget represents the amount of money a collective receives per month (regardless of the payment method used).
Today's revenue is based on last month (October 2018) with our existing 5% commission (see also below the Data section for the datasets).

monthly budget
price
number of collectives
expected revenue
today's revenue

$0-$100
free
261
0
$245/m

$101-$200
$10/m
60
$600/m
$378/m

$201-$500
$20/m
39
$780/m
$588/m

$501-$1,500
$50/m
27
$1,300/m
$1,252/m

$1,501-$5,000
$150/m
20
$3,000/m
$1,645/m

$5,001-$10,000
$300/m
2 (material-ui, wwcodeatl)
$600/m
$495/m

$10,001+
$1,000/m
3 (webpack, babel, sustainoss)
$3,000/m
$2,084/m

TOTAL

414
$9,280/m
$6,687/m

Spending

~$60k/m

Loss

~$50k/m

Run way

20 months

Bear in mind that this is based on our current dataset. Of the 544 collectives that have been active in the past 3 months, 462 were in USD (84%), 61 in EUR (11%). 355 (65%) were open source communities hosted by the open source collective. As an initial test phase, such new pricing model would only be applied to collectives in EUR. So the "expected revenue" is really just a comparison point if we were to apply the same pricing to existing collectives.
On top of that, the collective will have to add the host fee if they decide to be hosted by another legal entity.
But given that outside of open source communities, it's more common to either already have a legal entity, or to trust someone in meat space to hold the money on their personal bank account on behalf of the community, most of them won't need to pay such host fee.
(As a side note, we should probably enable hosts to also charge a monthly or yearly fee instead of a commission to each of the collectives that they host.)
Data
I made an export of all transactions of the past 3 months with the associated fees (13,027 transactions, query). Everything is available in our public google drive on https://drive.opencollective.com (direct link to data exports).
Feel free to have some fun with those datasets. Just please share what you find with the community. It's always great to have fresh eyes looking at our data and bringing new perspectives.
Impact on hosts
Women Who Code
In October, WWCode had 17 active collectives that collected a total of $20k ($770 directly through us, the rest by manually adding external funds to the budget of the collectives). They only gave us $140 of platform fees. With this new pricing, they would have to contribute $1,110/m in platform fees (note: this would come from the budget of the 17 active collectives, not from the budget of the host).
Note: if we decide to only apply this new business model to Europe, it wouldn't impact Women Who Code.
BrusselsTogether
In October, BrusselsTogether had 15 active collective that collected a total of €13k (€2k directly through us). They paid €100 of platform fees. With the new pricing, they would have to contribute €730/m in platform fees.
Open Collective Paris
4 collective active, total donations: €222, platform fees: €9. New pricing: €10.
Open Collective Europe
In October, 13 active collective, €1,450, €66 platform fees. With new pricing: €40/m.
Other scenarios
I also looked at making the backers pay directly instead of the collectives.
Last month, we had 3k backers for a total of $137k donated (only looking at USD).

368 were organizations. They gave $93k (avg: $255, median: $25, total platform fees: $4.6k)

300 of them gave between $100 and $1k (50 of them to more than one collective)
25 gave more than $1k.

2,669 individuals gave a total of $43k (avg: $16, median: $5, total platform fees: $1.5k)

I think it would make sense to introduce a Pro plan for backers, especially geared towards companies. This would give them better reporting, consolidated invoices, purchase orders. All of that is extra work compared to individual backers and of great value to them.
E.g. $1k or $5k/year depending on company size
It will also incentivize them to spend more to amortize their investment (if they donate $10k/year, that's a 10% overhead, but if they give $100k, that's only a 1% overhead).
Based on the current numbers, I'd expect 25 companies to subscribe to a $1k/year pro plan and 10 of them to get on a $10k/year. That would make another $125k/year or $10k/month and would help us get to "ramen profitability".
Comparables
To put things in perspective, those are some of the tools that collectives pay for:

Meetup: $5/m for up to 50 members, $8/m unlimited, see https://www.meetup.com/pricing/
Mailchimp: free for first 2k subscribers with mailchimp banner, $10/m up to 500 subscribers, $20 up to 1.5k, ... see https://mailchimp.com/pricing/
NationBuilder: $35/m up to 5k members (1k emailable), $83 up to 15k members (3k emailable), see https://nationbuilder.com/pricing
Wix: $8.50/m, $12.5/m with forms, $16.5 with store, see https://www.wix.com/upgrade/website
Heroku: $7/m per dyno https://www.heroku.com/pricing
Patreon: 5% commission + payment processor fees, see https://support.patreon.com/hc/en-us/articles/204606125-How-do-you-calculate-fees-

Conclusion
I like the idea of a free tier with up to $100/month of donations and a cheap tier at $10/month that will get you up to $500/month of donations. For those amounts of donation, people don't need to worry about having a host (and paying additional host fees). This category represents today 75% of active collectives. And I think this category could grow a lot more. Especially in Europe.
I also like the idea of a pro plan for companies on open collective. It will incentivize them to donate more and to rally more communities that they want to support to the platform. We might want to do some research to see what would be a good price point for them. My intuition would be to offer a small organization plan at $1k/year, medium at $5k/y and large at $10k/y. What do you think? What would you love to get for this?
Please share your comments and ideas. The goal is to make sure we can sustain open collective as a platform (you still want us to be around for decades to come right?) and that we can enable more communities around the world to become sustainable while embracing the ethos of open source that are transparency, inclusiveness, collaboration.
Next steps

Gather feedback from the community
Implement such new pricing for new collectives hosted by our own Open Collective Europe non profit (https://opencollective.com/europe).
Gather more feedback, share the learnings

In parallel, if the idea of a pro plan for organizations on Open Collective is getting some interest, that's something that we could pursue in parallel and that would apply to all organizations on Open Collective, not just in Europe.

We need to reopen this discussion.
I am about to send out a marketing campaign to fiscal sponsor orgs, and I do a lot in the space of host onboarding generally. To me, the fiscal hosting aspect is the most exciting part of Open Collective, and each fiscal host has a potential magnifying impact of all their Collectives combined. But it's not really helping us thrive if we don't get any fees from them. And many will not come on board at all if we stick to the 5% platform fee for large amounts added manually (which is too high on a $50,000 grant for example).
Currently, our documentation says we charge a 5% platform fee for everything (implied that includes manual payments). In practice, this is not happening because we have not built any way to actually collect or invoice for fees that are not automatically deducted from credit card transactions. I have felt uneasy because I can't really give clear answers about our fees to potential hosts. Technically they can do manual payments for free, but I don't want to emphasise that because I think they should be paying something.
I like the overall thinking of @xdamman's pricing table above, but I am also playing with other ideas. (Note this is for platform fees only - host fees are a whole other discussion.)
idea: flat 2% fee on all funds added manually

calculate what they owe each month and charge their credit card on file
similar to how other apps charge based on usage (like Mailchimp or Slack)
could disincentivise transparency because they might not add funds to avoid charge
their motivation add funds would be for accurate budget tracking and accounting
removes weird incentives to avoid tipping into the next price "bracket" because it's a smooth curve instead of stair steps
no need to change the 5% fee on credit card donations we have in place now

I don't think my idea is necessarily better that the model @xdamman proposed. Either one would be waaaay better than the situation we have currently.

I like the idea of a free tier with up to $100/month of donations and a cheap tier at $10/month that will get you up to $500/month of donations. For those amounts of donation, people don't need to worry about having a host (and paying additional host fees). This category represents today 75% of active collectives. And I think this category could grow a lot more.

I like the free tier idea too (but we can't call it tiers! that word is taken in our world already - call it price plan or something). I don't understand the part about not needing a fiscal host though. You mean Open Collective Inc will serve as host for all these small Collectives?

I also like the idea of a pro plan for companies on open collective. It will incentivize them to donate more and to rally more communities that they want to support to the platform.

I think we should keep this discussion carefully seperate from anything related to a "pro" offering for sponsors or contributors who submit a lot of expenses. To me this issue is about how we charge for money flowing through fiscal hosts that's added manually and therefore we're not charging for.
In conclusion: I think we have a very valuable tool to offer fiscal host organizations, but lack of a way to charge them for the biggest chunks of money in the system is hurting us, plus lack of clarity about pricing is blocking new ones from coming on board.

(5% platform fee and usually another 5% for the non profit fiscal host). It deters a lot of people from creating an open collective.

Looking at our collective, we're getting skimmed off 20% which is quite substantial


Retyping to string fails when manually typing in data type

Describe the bug
Sometimes data is not correctly identified as a string in the Listing view, either it's all marked as undefined or partially undefined and partially a string. In the latter scenario, data can be retyped selecting data -> string from the right click menu, but not by selecting data -> choose data type -> string
To Reproduce
I don't think I should share the executable here because it's from a commercial game, but I suppose it should apply to any binary that uses strings? If not please do inform me if there's a way to share only the relevant sections of the binary data.
First off here's the relevant data. As you can see, the string "/admin" is in there but Ghidra failed to identify the / as being a part of it. I select the first memory location and press T to bring up the Data Type Chooser dialog and select the builtin string type:

A dialog pops up, I select yes to clear the conflicting data:

After this nothing in the listing changes and in the statusbar the message "Create string failed: Not enough space to create DataType string" appears.
However, when right clicking the same memory location as before but selecting "string" instead of "choose data type":

And clicking yes again in the same conflicting data dialog, it now succesfuly retypes the data without any error appearing:

Expected behavior
I would expect there to be no difference in behavior between manually typing in string and clicking on the predefined string option.
Environment:

OS: Windows 10 Pro 1903
Java Version: 11.0.2
Ghidra Version: 9.0.4

I believe this occurs with every datatype, not just with string.


⚠ ClamAV has degraded performance

In 7f5870f, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 90 ms

Resolved: ClamAV performance has improved in 5dc6b43 after 5 minutes.


Fix race condition on enrichers

Different gadgets use the different enricher interfaces to add
container information to the events received from the eBPF programs.
It could happen that by the time the tracer calls the enricher, the
container is gone and then the container information from the event
is missing.
This case is specially relevant when the container is killed after
executing the event, like using a capability not allowed or called
a syscall blocked by seccomp.
This commit fixes this by creating a container cache system: containers
are retained and made available to enrichers for a while after those
are removed from the container collection package, this allows the
enrichers to provide the container data even if the container is gone.
The container collection package is generic enough, hence this behavior
is only enabled when "WithTracerCollection" is used.
How to test
Check https://github.com/inspektor-gadget/inspektor-gadget/issues/1178#issuecomment-1396238600. (Check that you're able to reproduce without this PR first, because it's possible that the issue doesn't reproduce in all environments)
TODO

[ ] Implement test for WithTracerCollection
[ ] Update audit seccomp to use this mechanism instead of saving container names in ebpf code? (cc @alban)

Fixes https://github.com/inspektor-gadget/inspektor-gadget/issues/1178

Update audit seccomp to use this mechanism instead of saving container names in ebpf code? (cc @alban)

Ideally yes, we should avoid using different mechanisms in different gadgets for the same thing when we can avoid it.


Craigenator

Moving perimeter networking to environment/common in advance of firewall architecture change as well as other clean up

Thanks Mike, starting review, running changes....ETA up until 1300 Thu

Verifying on existing 2nd account at gcp.obrien.services
admin_super@cloudshell:~/cloudshell_open/pbmm-on-gcp-onboarding (landingzone-stg-os)$
Build history OK to start

testing
admin_super@cloudshell:~/cloudshell_open/pbmm-on-gcp-onboarding (landingzone-stg-os)$ git status
On branch main
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        deleted:    environments/bootstrap/examples/main.tf
        deleted:    environments/bootstrap/examples/outputs.tf
        deleted:    environments/bootstrap/examples/variables.tf
        modified:   environments/common/main.tf
        modified:   environments/common/variables.tf
        modified:   environments/nonprod/nonp-network.auto.tfvars
        modified:   environments/prod/main.tf
        deleted:    environments/prod/perimeter-network.auto.tfvars
        modified:   environments/prod/prod-firewall.auto.tfvars
        modified:   environments/prod/prod-network.auto.tfvars
        deleted:    environments/prod/prod-private-perimeter-firewall.auto.tfvars
        deleted:    environments/prod/prod-public-perimeter-firewall.auto.tfvars
        modified:   environments/prod/variables.tf
        modified:   modules/fortigate-appliance/main.tf
        modified:   modules/landing-zone-bootstrap/locals.tf
        modified:   modules/network-host-project/modules/network-peering/versions.tf

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        environments/common/perimeter-network.auto.tfvars
        environments/common/prod-private-perimeter-firewall.auto.tfvars
        environments/common/prod-public-perimeter-firewall.auto.tfvars
        writeids.sh

Expected issue
Note: redploy will require a 2 step
1 - run prod first
2 - run common after (contains new prod perim)
bootstrap, non-prod OK
common - error is caused by prod still deleting/redeploying

timing issue will rerun common (which contains prod permeter now)
Step #3 - "tf apply": │ Error: error creating project ospe-obs-obsprod-obspubper (OsPe-obs-obsprod-obspubper): googleapi: Error 409: Requested entity already exists, alreadyExists. If you received a 403 error, make sure you have the roles/resourcemanager.projectCreator permission
Step #3 - "tf apply": │
Step #3 - "tf apply": │   with module.net-perimeter-prj.module.project.google_project.project,
Step #3 - "tf apply": │   on ../../modules/project/main.tf line 9, in resource "google_project" "project":

recommend renaming line 8 of perimeter-network.auto.tfvar to not conflict with the original perimeter network in prod before this PR
public_perimeter_net = {

user_defined_string            = "obsprod" # must be globally unique

user_defined_string            = "obsprd" # must be globally unique

admin_super@cloudshell:~/cloudshell_open/pbmm-on-gcp-onboarding (landingzone-stg-os)$ git status
On branch main
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git restore ..." to discard changes in working directory)
modified:   environments/common/perimeter-network.auto.tfvars
no changes added to commit (use "git add" and/or "git commit -a")
admin_super@cloudshell:~/cloudshell_open/pbmm-on-gcp-onboarding (landingzone-stg-os)$ git add environments/
admin_super@cloudshell:~/cloudshell_open/pbmm-on-gcp-onboarding (landingzone-stg-os)$ git status
On branch main
Changes to be committed:
(use "git restore --staged ..." to unstage)
modified:   environments/common/perimeter-network.auto.tfvars
admin_super@cloudshell:~/cloudshell_open/pbmm-on-gcp-onboarding (landingzone-stg-os)$ git environments/
commit -m "#81 - review Mike C. PR - unique common prod perim vpc"
[main 67bb8e0] #81 - review Mike C. PR - unique common prod perim vpc
1 file changed, 1 insertion(+), 1 deletion(-)
ainin_super@cloudshell:~/cloudshell_open/pbmm-on-gcp-onboarding (landingzone-stg-os)$ git push csr m
Enumerating objects: 9, done.
Counting objects: 100% (9/9), done.
Delta compression using up to 4 threads
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 524 bytes | 524.00 KiB/s, done.
Total 5 (delta 3), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (3/3)
To https://source.developers.google.com/p/ospe-obs-osdev-sbx/r/observiceslzd
f07f726..67bb8e0  main -> main

all good with the perimeter network rename in common

Also note that we no longer experience the required rename issue in #44
reran all without a name change
closing #44

2nd containerized.org rebase
michael@cloudshell:~/cloudshell_open/pbmm-on-gcp-onboarding (landingzone-stg)$ git status
On branch main
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   environments/common/main.tf
        modified:   environments/nonprod/nonp-firewall.auto.tfvars
        modified:   environments/prod/main.tf
        deleted:    environments/prod/perimeter-network.auto.tfvars
        modified:   environments/prod/prod-firewall.auto.tfvars
        modified:   environments/prod/prod-network.auto.tfvars
        deleted:    environments/prod/prod-private-perimeter-firewall.auto.tfvars
        deleted:    environments/prod/prod-public-perimeter-firewall.auto.tfvars
        modified:   environments/prod/variables.tf
        modified:   modules/landing-zone-bootstrap/locals.tf
        modified:   modules/network-host-project/modules/network-peering/versions.tf
        modified:   writeids.sh

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        environments/common/perimeter-network.auto.tfvars
        environments/common/prod-private-perimeter-firewall.auto.tfvars
        environments/common/prod-public-perimeter-firewall.auto.tfvars

michael@cloudshell:~/cloudshell_open/pbmm-on-gcp-onboarding (landingzone-stg)$ git commit -m "rebase 20220517 main"
[main fbf5dd5] rebase 20220517 main
 12 files changed, 111 insertions(+), 13 deletions(-)
 rename environments/{prod => common}/perimeter-network.auto.tfvars (98%)
 rename environments/{prod => common}/prod-private-perimeter-firewall.auto.tfvars (100%)
 rename environments/{prod => common}/prod-public-perimeter-firewall.auto.tfvars (100%)
michael@cloudshell:~/cloudshell_open/pbmm-on-gcp-onboarding (landingzone-stg)$ git push csr main
Enumerating objects: 38, done.
Counting objects: 100% (38/38), done.
Delta compression using up to 4 threads
Compressing objects: 100% (17/17), done.
Writing objects: 100% (21/21), 5.81 KiB | 2.91 MiB/s, done.
Total 21 (delta 15), reused 4 (delta 4), pack-reused 0
remote: Resolving deltas: 100% (15/15)
To https://source.developers.google.com/p/dope-dod-dodev-dbx/r/containerizedlzd
   92e9f21..fbf5dd5  main -> main


arm64

Hi guys
First at all - thanks for a such great product
I have trouble with compiling on arm64 device (odroid c2)

~/go/src/github.com/gravitational/teleconsole $ go build
# github.com/gravitational/teleport/vendor/github.com/kr/pty
../teleport/vendor/github.com/kr/pty/pty_linux.go:34: undefined: _C_uint
../teleport/vendor/github.com/kr/pty/pty_linux.go:43: undefined: _C_int
# github.com/gravitational/teleport/vendor/github.com/boltdb/bolt
../teleport/vendor/github.com/boltdb/bolt/db.go:85: undefined: maxMapSize
../teleport/vendor/github.com/boltdb/bolt/db.go:85: invalid array bound maxMapSize

Can you help ?
Thanks

@slayer The issue is that Teleport (teleconsole dependency) has changed. I will update the dependencies and vendor teleport into this repo.

@slayer I am still waiting for Teleport 2.0 to come out to vendor it it. Meanwhile, you can build Teleconsole using the original Teleport version, i.e.:
$ cd $GOPATH/github.com/gravitational/teleport
$ git checkout v1.3.0
$ cd $GOPTATH/github.com/gravitational/teleconsole
$ make

same errors:
 (v1.3.0) vlad@germ ~/go/src/github.com/gravitational/teleport $ cd ../teleconsole/
 master vlad@germ ~/go/src/github.com/gravitational/teleconsole $ make
 make -C version
 make[1]: Entering directory '/home/vlad/go/src/github.com/gravitational/teleconsole/version'
 make[1]: Leaving directory '/home/vlad/go/src/github.com/gravitational/teleconsole/version'
 go build -i -ldflags -w -o out/teleconsole
 # github.com/gravitational/teleport/vendor/github.com/boltdb/bolt
 ../teleport/vendor/github.com/boltdb/bolt/db.go:85: undefined: maxMapSize
 ../teleport/vendor/github.com/boltdb/bolt/db.go:85: invalid array bound maxMapSize
 # github.com/gravitational/teleport/vendor/github.com/kr/pty
 ../teleport/vendor/github.com/kr/pty/pty_linux.go:34: undefined: _C_uint
 ../teleport/vendor/github.com/kr/pty/pty_linux.go:43: undefined: _C_int
 Makefile:15: recipe for target 'out/teleconsole' failed
 make: *** [out/teleconsole] Error 2

I can try to open ssh access to that device, is it interesting ?

@slayer I think you're compiling with 64-bit ARM (armv7) Golang is that true? Teleport (which Teleconsole is built on top of) does not officially support armv7 builds (because Teleport's own dependencies do not build on it).
We recommend using standard armv6 release of Go (the binary should run on ODROID C2 just fine). BTW, do you recommend ODROID? Is it stable? Thinking about replacing my aging Raspberry 1, which has been running for years on USB power with no problems.

@kontsevoy thanks, I will try.
I am using odroid as home server for a 2 months and does not have problems. Its pretty fast (4 64 bit cores). You can see benchmark https://www.jeffgeerling.com/blog/2016/review-odroid-c2-compared-raspberry-pi-3-and-orange-pi-plus


Chinese Translation & some bugs fixes

Add the Chinese language translation;
Fix bug:

Some typos in the English translation;
A few texts do not use the translation strings.

By the way, to facilitate the maintenance of subsequent Chinese translation, can I be the contributor of the translation files (if merged)?
Thank you!

Looks good. I'll include them in the next update.
As heads up, there will likely be a prelease for 1.16 at some point, where new translations will be introduced.


The global downstream_package_name option not respected for monorepo

@lsm5 hit an issue with the release of containers-common package: https://github.com/containers/common/releases/tag/v0.59.0
Config is here: https://github.com/containers/common/blob/79d954c7766303997d7dea4340442855e143fc5b/.packit.yaml
downstream_package_name: containers-common
upstream_tag_template: v{version}

packages:
  containers-common-fedora:
    pkg_tool: fedpkg
    specfile_path: rpm/containers-common.spec
  containers-common-centos:
    pkg_tool: centpkg
    specfile_path: rpm/containers-common.spec

This is what docs say:
downstream_package_name:

(string) Name of the RPM package in Fedora, defaults to the name of the GitHub repository. In case of using the packages key, the defaults are the keys of the dictionary.

This ends with the following Pagure error since we try to use the upstream repo name as the downstream name:
Page 'https://src.fedoraproject.org/api/0/rpms/common/git/branches' not found when calling Pagure API.
"Project not found"

As a workaround, one can set the downstream_package_name on the package/job level.

I just want to add a note.
No global key is respected in a monorepo configuration, exception made for upstream_project_url.
The behaviour has been described here and probably the description can be enhanced.
We could add another exception for the downstream_package_name, even though from the point of view of a monorepo itself it would be quite strange having the same downstream_package_name and still all the others keys will no work on the global section unless of doing other exceptions or totally change the way we deal with the configurations in monorepos.
The monorepo syntax in this case is used to solve a different problem than an upstream monorepo and we should probably discuss how to generally improve the monorepo syntax for this kind of use.

We decided we will fix the documentation and not change the behaviour.


[bug] --debug not passed to vite config

Describe the bug
right now if you build with tauri build --debug there is no way to know on the vite config side.
This is very important because you would want to have sourcemap enable in debug production builds when you could not want then in a normal release production build
Reproduction
run tauri build --debug
Expected behavior
There should be a way to know the --debug option was passed
Platform and versions
><EMAIL_ADDRESS>tauri
> tauri "info"

Operating System - Mac OS, version 11.6.0 X64

Node.js environment
  Node.js - 17.6.0
  @tauri-apps/cli - 1.0.0-rc.6 (outdated, latest: 1.0.0-rc.7)
  @tauri-apps/api - 1.0.0-rc.2

Global packages
  npm - 8.5.1
  pnpm - 6.32.3
  yarn - Not installed

Rust environment
  rustup - 1.24.3
  rustc - 1.58.1
  cargo - 1.58.0
  toolchain - stable-x86_64-apple-darwin

App directory structure
/resources
/node_modules
/.history
/.github
/src-tauri
/build
/.git
/.vscode
/src

App
  tauri - 1.0.0-rc.4
  tauri-build - 1.0.0-rc.4
  tao - 0.6.4
  wry - 0.13.3
  build-type - bundle
  CSP - default-src blob: data: filesystem: ws: wss: asset: mbtiles: http: https: tauri: 'unsafe-eval' 'unsafe-inline' 'self' img-src: 'self'
  distDir - ../build
  devPath - http://localhost:3000/
  framework - Svelte

Stack trace
No response
Additional context
No response

before(Dev|Build)Commands inject multiple env vars, one of them TAURI_DEBUG which should be set to true in build --debug too: https://tauri.studio/docs/api/config#build.beforeBuildCommand

@FabianLars awesome ! sorry for not finding this is the docs.
i ll close as soon as it tested this to work

i ll close as soon as it tested this to work

Yes please test it on your end too, but it should work. I added it specifically for conditional compilation using vite at work. We've been using it to great success ever since.

@JonasKruckenberg awesome! thanks for config. i upgraded mine with your changes!
And i confirm it works :D


Parse Report-To and NEL headers

We need to parse the values of Report-To and NEL headers to create all of the endpoint-related state described in the spec.

#7 covers Report-To


"Copy to Clipboard" not working on Example pages

The "Copy to Clipboard" button on http://esri.github.io/calcite-web/examples/core/ doesn't seem to work.  Tested on Chrome and Edge on Windows.

Fixed in #668 - deployed docs to fix in real life also.


iOS - numbers with the same digit count occupy different lengths

I want to put some new light on this issue: https://github.com/flutter/flutter/issues/86227
Steps to Reproduce

Run the code below both on iOS and Android.

import 'package:flutter/material.dart';

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home: MyHomePage(),
    );
  }
}

class MyHomePage extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(
        child: ElevatedButton(
          child: Text("Click me"),
          onPressed: () async {
            await showDialog(
              context: context,
              builder: (BuildContext context) {
                List options = [
                  '0107202101072021',
                  '1241515122341242',
                  '8932813023230123',
                  '3214141412414124',
                  '3587897518979901',
                  '4218412084120944',
                ];

                return SimpleDialog(
                  children: options.map((option) {
                    return SimpleDialogOption(
                      onPressed: () {},
                      child: Text(
                        option,
                        style: TextStyle(fontSize: 18),
                      ),
                    );
                  }).toList(),
                );
              },
            );
          },
        ),
      ),
    );
  }
}

Click the button.
Here is the result.

In the dialog, I am displaying numbers with the same digit count. As you can see, on Android they occupy the same or almost the same length. However, on iOS they occupy different lengths and the difference is so significant.
I understand that I am using proportional, not monospace font and the lengths can differ. However, IMO the difference on iOS is too big compared to Android. That's why I think it's a bug in Flutter.
Expected results:
Lines with the same number of digits should occupy approximately the same lengths as it is working on Android.
Actual results:
On iOS the difference between line lengths is too big.

Logs

n/a

n/a

[✓] Flutter (Channel stable, 2.2.3, on macOS 11.4 20F71 darwin-arm, locale en-PL)
    • Flutter version 2.2.3 at /Users/user/development/flutter
    • Framework revision f4abaa0735 (12 days ago), 2021-07-01 12:46:11 -0700
    • Engine revision 241c87ad80
    • Dart version 2.13.4

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    • Android SDK at /Users/user/Library/Android/sdk
    • Platform android-30, build-tools 30.0.3
    • Java binary at: /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_292-b10)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 12.5.1, Build version 12E507
    • CocoaPods version 1.10.1

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

[!] Android Studio
    • Android Studio at /Applications/Android Studio Preview.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    ✗ Unable to find bundled Java version.
    • Try updating or re-installing Android Studio.

[✓] Connected device (3 available)
    • sdk gphone arm64 (mobile) • emulator-5554                        • android-arm64  • Android 11 (API 30) (emulator)
    • iPhone 8 (mobile)         • 95840C96-E460-44E9-A6BF-5D8D588F5133 • ios            • com.apple.CoreSimulator.SimRuntime.iOS-14-5 (simulator)
    • Chrome (web)              • chrome                               • web-javascript • Google Chrome 91.0.4472.114

! Doctor found issues in 1 category.

Please do not file duplicates of your own issues.
The default fonts for a Material app on Android and iOS are not the same, per the Material spec. If you don't want the default font for your use case, use a different font.

That's why I think it's a bug in Flutter.

It is not, as explained in the previous issue.

Lines with the same number of digits should occupy approximately the same lengths

This is entirely font-dependent. It is not a true statement in general.

On iOS the difference between line lengths is too big.

Feel free to file a bug with Apple if you don't approve of the iOS system font.


My github repository DeepLearning shows wrong language

My github repository DeepLearning shows wrong language. It shows 'HTML' instead of 'Python'

This is happening because your repo contains five HTML files totalling over 4MB with GAN_GenerateFaces/dlnd_face_generation.html being over 2MB alone.

If you don't mind the (minimal) extra work you can manually override language definitions in a .gitattributes file or move the html:
https://github.com/github/linguist#overrides

Thanks! It worked.


Fix loading of long properties

In submitting this contribution, I agree to the current Software AG contributor agreement as referred to here:
https://github.com/quartz-scheduler/contributing/blob/main/CONTRIBUTING.md
Changes

loading longs as longs instead of ints

Checklist

[x] tested locally
[ ] updated the docs
[x] added appropriate test
[x] signed-off on the above mentioned SoftwareAG contributor agreement via git commit -s on my commits.
(If you're not using command-line, you can use a browser extension )

Fixes #1140
PS: Yes, I know that this project seems to be abandoned (#1134)

Unfortunately, due to the change of ownership of this project, the terms of contribution have been updated, and this PR will need to be re-created, agreeing to the new terms.

@kirmerzlikin can you resubmit this please


Causality pipeline

Dear @jdammers @pravsripad @lukasbreuer @fboers
I form the pipeline for the whole research work described in the manuscript. The directory 'jumeg_Causality' include 4 documents:
'causality_pipeline' includes 'ROIs defintion' and 'causality_analysis' functions.
'test_pipeline' gives the example to apply the functions in 'causality_pipeline'.
'plot_coor' plots the centroids of ROIs.
'dirs_manage' is imported, during causality functions aplying. It plays a role to store results into diferent directories.

@dongqunxi, are you planning any major changes to the causality analysis pipeline?

The pipeline is nearly finished, I have no plan to make a major change.
Once the issue of the unstable datasets is resolved, I will make a
conclusion of the causal pipeline.
Best wishes,
Qunxi Dong
2016-09-22 15:04 GMT+08:00 Praveen Sripad<EMAIL_ADDRESS>
@dongqunxi https://github.com/dongqunxi, are you planning any major
changes to the causality analysis pipeline?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jdammers/jumeg/pull/104#issuecomment-248828067, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ADqbM8OlZJ5GLS81TnOn2WY5Ev-tf8BHks5qsihigaJpZM4G_m4I
.


Default required

This adds the ability to set default required and nullable status.  It also adds the ability to override required and nullable status per array accessor.  It is built on top of PR #6, which adds Python 3 support.

Awesome - thanks!


Backspace/delete keys characters are broken in input

User story
As a user I want backspace and delete keys, especially in combination with left/right arrow, to work as I would expect from text input so that I don't get frustrated when using gash.
Technical details
When user types an input and then moves with left arrow to the middle of it, Backspace key does not delete the previous characters. It does however work when at the end of the input. Delete key produces space instead of any character.

Fixed by #8. Closing as done.


Added CLB (CoinLoanBank) token

Hello! Sadly, we do not support that list anymore. Thank you for your contribution attempt anyway.


update with changes to main

I'll sort this out later, so i can work on this branch with changes from main


update gherkin to dotnet 6

As this Pull Request was not complete, I pulled you code into a new branch and updated it in #10 . Thanks for you contribution!


feat: align output of searchcount component with neovim default

Neovim's default formatting for indicating the search result position, from :h search-commands:
  [1/5]         Cursor is on first of 5 matches.
  [1/>99]       Cursor is on first of more than 99 matches.
  [>99/>99]     Cursor is after 99 match of more than 99 matches.
  [?/??]        Unknown how many matches exists, generating the
                statistics was aborted because of search timeout.

Meaning of result.incomplete, from :h searchcount():
  0: search was fully completed
  1: recomputing was timed out
  2: max count exceeded

I have tested every case locally (result.incomplete == 0|1|2) it works here. Not sure about the performance impact though.
Also, idk why that blank line was included in the diff :confused:

Been using this for nearly 2 months now without any issues...


Please elaborate on file structure

It is a bit unclear on how countries should supply their test files.
In my mind each country has a directory, in which each test file reside. For example:

/SE/README.md - Describes the Swedish test files.
/SE/1.json - First test file.
/SE/2.json - ....

The current structure would be
/SE/Readme.md
/SE/2DCode/raw/1.json


Home and server directory

Add a home directory where you can view servers,  current account and switch to a different server. Accessed by /home
Commands:
/servers
/profile
/server [Server name or ID]
Server directory allows you to select servers and view channels. Accessed by /server
Commands:
/channels
/channel [channel name or ID]
/server_profile

I'll work on this after school on August 14, 2023.

Change of plans. I'll work on it when I have the motivation.


Feature/allen/extrude with multiple vars

Description
This PR adds a new operator to create stacked extrusions. It is an extension and enhancement of the original extrude operator so to allow extrusions by multiple variables. It also handles additional geometry that the extrude operator does not. This operator replicates everything in the current extrude operator. Ideally this operator would replace the extrude operator.
Type of change

[ ] Bug fix~~
[X ] New feature~~
[ ] Documentation update~~
[ ] Other~~

How Has This Been Tested?
There are test files for all types of supported meshes using both node and cell data. The documentation has been updated but not the release notes
Checklist:

[x] I have commented my code where applicable.~~
[ ] I have updated the release notes.~~
[x] I have made corresponding changes to the documentation.~~
[x] I have added some debugging support to my changes.~~
[x] I have added tests that prove my fix is effective or that my feature works.~~
[x] I have confirmed new and existing unit tests pass locally with my changes.~~
[ ] I have added new baselines for any new tests to the repo.~~
[x] I have NOT made any changes to [protocol or public interfaces][3] in an RC branch.~~

I did a major pass incorporating the suggestions over the week. The documentation and tests reflect the updates. At this point a full review is possible.

I made an additional pass to clean up issues and make the GUI mode friendly. I also greatly expanded the fixed extrusion options. Hopefully, the last major pass.


chore: release master

:robot: I have created a release beep boop
all-components: 1.9.0
1.9.0 (2023-09-01)
Features

modifications (#97) (4e293a5)

Dependencies

The following workspace dependencies were updated

dependencies

@allaround/input bumped from ^2.8.8 to ^2.9.0
@allaround/container bumped from ^1.7.1 to ^1.8.0
@allaround/common-scss bumped from ^1.2.3 to ^1.3.0
@allaround/heading bumped from ^1.2.2 to ^1.3.0
@allaround/icons bumped from ^1.0.2 to ^1.1.0
@allaround/sidebar bumped from ^1.0.6 to ^1.0.7
@allaround/navbar bumped from ^1.0.7 to ^1.0.8
@allaround/hooks bumped from ^1.0.8 to ^1.1.0
@allaround/textarea bumped from ^1.0.7 to ^1.0.8
@allaround/tags bumped from ^1.0.8 to ^1.0.9
@allaround/dropdown bumped from ^1.0.8 to ^1.0.9
@allaround/select bumped from ^1.0.8 to ^1.0.9
@allaround/upload bumped from ^1.0.8 to ^1.0.9
@allaround/scheduler bumped from ^1.0.8 to ^1.0.9
@allaround/video bumped from ^1.0.9 to ^1.0.10
@allaround/image bumped from ^1.0.8 to ^1.0.9
@allaround/checkbox bumped from ^1.0.8 to ^1.0.9
@allaround/tooltip bumped from ^1.0.8 to ^1.1.0
@allaround/switch bumped from ^1.0.5 to ^1.0.6
@allaround/progress-bar bumped from ^1.0.5 to ^1.0.6
@allaround/notification bumped from ^1.0.7 to ^1.0.8
@allaround/placeholder bumped from ^1.0.5 to ^1.1.0

@allaround/checkbox: 1.0.9
Dependencies

The following workspace dependencies were updated

dependencies

@allaround/container bumped from ^1.7.1 to ^1.8.0
@allaround/tooltip bumped from ^1.0.8 to ^1.1.0
@allaround/input bumped from ^2.8.8 to ^2.9.0

common-scss: 1.3.0
1.3.0 (2023-09-01)
Features

modifications (#97) (4e293a5)

container: 1.8.0
1.8.0 (2023-09-01)
Features

add mouse event props (#95) (8780086)

@allaround/dropdown: 1.0.9
Dependencies

The following workspace dependencies were updated

dependencies

@allaround/icons bumped from ^1.0.2 to ^1.1.0
@allaround/container bumped from ^1.7.1 to ^1.8.0
@allaround/tooltip bumped from ^1.0.8 to ^1.1.0

heading: 1.3.0
1.3.0 (2023-09-01)
Features

modifications (#97) (4e293a5)

hooks: 1.1.0
1.1.0 (2023-09-01)
Features

modifications (#97) (4e293a5)

Dependencies

The following workspace dependencies were updated

devDependencies

@allaround/container bumped from ^1.7.1 to ^1.8.0
@allaround/notification bumped from ^1.0.7 to ^1.0.8

icons: 1.1.0
1.1.0 (2023-09-01)
Features

modifications (#97) (4e293a5)

@allaround/image: 1.0.9
Dependencies

The following workspace dependencies were updated

dependencies

@allaround/upload bumped from ^1.0.8 to ^1.0.9
@allaround/tooltip bumped from ^1.0.8 to ^1.1.0
@allaround/icons bumped from ^1.0.2 to ^1.1.0
@allaround/container bumped from ^1.7.1 to ^1.8.0

input: 2.9.0
2.9.0 (2023-09-01)
Features

modifications (#97) (4e293a5)

Dependencies

The following workspace dependencies were updated

dependencies

@allaround/hooks bumped from ^1.0.8 to ^1.1.0
@allaround/container bumped from ^1.7.1 to ^1.8.0
@allaround/tooltip bumped from ^1.0.8 to ^1.1.0

@allaround/navbar: 1.0.8
Dependencies

The following workspace dependencies were updated

dependencies

@allaround/container bumped from ^1.7.1 to ^1.8.0

@allaround/notification: 1.0.8
Dependencies

The following workspace dependencies were updated

dependencies

@allaround/icons bumped from ^1.0.2 to ^1.1.0
@allaround/container bumped from ^1.7.1 to ^1.8.0

placeholder: 1.1.0
1.1.0 (2023-09-01)
Features

modifications (#97) (4e293a5)

Dependencies

The following workspace dependencies were updated

dependencies

@allaround/container bumped from ^1.7.1 to ^1.8.0

@allaround/progress-bar: 1.0.6
Dependencies

The following workspace dependencies were updated

dependencies

@allaround/container bumped from ^1.7.1 to ^1.8.0

@allaround/scheduler: 1.0.9
Dependencies

The following workspace dependencies were updated

dependencies

@allaround/hooks bumped from ^1.0.8 to ^1.1.0
@allaround/select bumped from ^1.0.8 to ^1.0.9
@allaround/icons bumped from ^1.0.2 to ^1.1.0
@allaround/container bumped from ^1.7.1 to ^1.8.0

@allaround/select: 1.0.9
Dependencies

The following workspace dependencies were updated

dependencies

@allaround/container bumped from ^1.7.1 to ^1.8.0
@allaround/icons bumped from ^1.0.2 to ^1.1.0
@allaround/hooks bumped from ^1.0.8 to ^1.1.0

@allaround/sidebar: 1.0.7
Dependencies

The following workspace dependencies were updated

dependencies

@allaround/container bumped from ^1.7.1 to ^1.8.0

@allaround/switch: 1.0.6
Dependencies

The following workspace dependencies were updated

dependencies

@allaround/container bumped from ^1.7.1 to ^1.8.0

@allaround/tags: 1.0.9
Dependencies

The following workspace dependencies were updated

dependencies

@allaround/hooks bumped from ^1.0.8 to ^1.1.0
@allaround/input bumped from ^2.8.8 to ^2.9.0
@allaround/icons bumped from ^1.0.2 to ^1.1.0
@allaround/textarea bumped from ^1.0.7 to ^1.0.8

@allaround/textarea: 1.0.8
Dependencies

The following workspace dependencies were updated

dependencies

@allaround/icons bumped from ^1.0.2 to ^1.1.0
@allaround/container bumped from ^1.7.1 to ^1.8.0

tooltip: 1.1.0
1.1.0 (2023-09-01)
Features

modifications (#97) (4e293a5)

Dependencies

The following workspace dependencies were updated

dependencies

@allaround/hooks bumped from ^1.0.8 to ^1.1.0

@allaround/upload: 1.0.9
Dependencies

The following workspace dependencies were updated

dependencies

@allaround/hooks bumped from ^1.0.8 to ^1.1.0
@allaround/input bumped from ^2.8.8 to ^2.9.0
@allaround/icons bumped from ^1.0.2 to ^1.1.0
@allaround/container bumped from ^1.7.1 to ^1.8.0

@allaround/video: 1.0.10
Dependencies

The following workspace dependencies were updated

dependencies

@allaround/progress-bar bumped from ^1.0.5 to ^1.0.6
@allaround/icons bumped from ^1.0.2 to ^1.1.0
@allaround/hooks bumped from ^1.0.8 to ^1.1.0
@allaround/container bumped from ^1.7.1 to ^1.8.0
@allaround/tooltip bumped from ^1.0.8 to ^1.1.0
@allaround/upload bumped from ^1.0.8 to ^1.0.9

allaround-components: 2.11.0
2.11.0 (2023-09-01)
Features

add mouse event props (#95) (8780086)
modifications (#97) (4e293a5)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/wholesome-ghoul/allaround-components/releases/tag/allaround-components-v2.11.0 :sunflower:

:robot: Release is at https://github.com/wholesome-ghoul/allaround-components/releases/tag/all-components-v1.9.0 :sunflower:

:robot: Release is at https://github.com/wholesome-ghoul/allaround-components/releases/tag/input-v2.9.0 :sunflower:

:robot: Release is at https://github.com/wholesome-ghoul/allaround-components/releases/tag/container-v1.8.0 :sunflower:

:robot: Release is at https://github.com/wholesome-ghoul/allaround-components/releases/tag/common-scss-v1.3.0 :sunflower:

:robot: Release is at https://github.com/wholesome-ghoul/allaround-components/releases/tag/heading-v1.3.0 :sunflower:

:robot: Release is at https://github.com/wholesome-ghoul/allaround-components/releases/tag/icons-v1.1.0 :sunflower:

:robot: Release is at https://github.com/wholesome-ghoul/allaround-components/releases/tag/sidebar-v1.0.7 :sunflower:

:robot: Release is at https://github.com/wholesome-ghoul/allaround-components/releases/tag/navbar-v1.0.8 :sunflower:

:robot: Release is at https://github.com/wholesome-ghoul/allaround-components/releases/tag/hooks-v1.1.0 :sunflower:

:robot: Release is at https://github.com/wholesome-ghoul/allaround-components/releases/tag/textarea-v1.0.8 :sunflower:

:robot: Release is at https://github.com/wholesome-ghoul/allaround-components/releases/tag/tags-v1.0.9 :sunflower:

:robot: Release is at https://github.com/wholesome-ghoul/allaround-components/releases/tag/dropdown-v1.0.9 :sunflower:

:robot: Release is at https://github.com/wholesome-ghoul/allaround-components/releases/tag/select-v1.0.9 :sunflower:

:robot: Release is at https://github.com/wholesome-ghoul/allaround-components/releases/tag/upload-v1.0.9 :sunflower:

:robot: Release is at https://github.com/wholesome-ghoul/allaround-components/releases/tag/scheduler-v1.0.9 :sunflower:

:robot: Release is at https://github.com/wholesome-ghoul/allaround-components/releases/tag/video-v1.0.10 :sunflower:

:robot: Release is at https://github.com/wholesome-ghoul/allaround-components/releases/tag/image-v1.0.9 :sunflower:

:robot: Release is at https://github.com/wholesome-ghoul/allaround-components/releases/tag/checkbox-v1.0.9 :sunflower:

:robot: Release is at https://github.com/wholesome-ghoul/allaround-components/releases/tag/tooltip-v1.1.0 :sunflower:

:robot: Release is at https://github.com/wholesome-ghoul/allaround-components/releases/tag/switch-v1.0.6 :sunflower:

:robot: Release is at https://github.com/wholesome-ghoul/allaround-components/releases/tag/progress-bar-v1.0.6 :sunflower:

:robot: Release is at https://github.com/wholesome-ghoul/allaround-components/releases/tag/notification-v1.0.8 :sunflower:

:robot: Release is at https://github.com/wholesome-ghoul/allaround-components/releases/tag/placeholder-v1.1.0 :sunflower:


Use the atom-workspace tag instead of the workspace class.

In keymaps/markdown-toc.cson: Use the atom-workspace tag instead of the workspace class.

Duplicate for #21

Thank you @danromuald  and @mainiak ,
today I published the GitHub code to atom.io as a package.
Happy coding,
Darius


The "view the curriculum" button shows white screen after going to next challenge & clicking it.

Describe your problem and - if possible - how to reproduce it
When I complete a challenge and go to next challenge by pressing Ctrl + Enter, then If I click the "view the curriculum" button then the whole screen turns white & the app supposedly crashes.
When I looked at the JS console of the browser, It shows the following error:
Uncaught TypeError: Cannot read property 'id' of undefined
    at Block.js:24
    at Array.map (<anonymous>)
    at Block.js:24
    at index.js?646b*:76
    at index.js?646b*:36
    at index.js?646b*:90
    at index.js?646b*:36
    at Function.q [as mapToProps] (Block.js:24)
    at r (wrapMapToProps.js:54)
    at Function.r.mapToProps (wrapMapToProps.js:63)

 Uncaught (in promise) DOMException: Quota exceeded.

Tell us about your browser and operating system

Browser Name: Chromium
Browser Version: 66.0.3359.181
Operating System: Ubuntu 18.04

If possible, add a screenshot here

https://github.com/freeCodeCamp/freeCodeCamp/issues/17339 <- similar issue

duplicate of https://github.com/freeCodeCamp/freeCodeCamp/issues/17309


Add font size option and make bigger defaults

@cpatrick PTAL. You can do this on a vcharts checkout to host the examples at http://localhost:8080/bullet.html:
bower install
gulp
python -m SimpleHTTPServer 8080 .


SNPE without prior is no longer working

Describe the bug
The prior is an optional argument to SNPE, see here. However, after the recent refactorings, one gets an error upon sampling when no prior is passed.
To Reproduce
from sbi.inference import SNPE
import torch

theta = torch.randn((100, 1))
x = torch.randn((100, 1))
inference = SNPE()
_ = inference.append_simulations(theta, x).train(max_num_epochs=10)
posterior = inference.build_posterior()

x_o = torch.as_tensor([[1.0]])
samples = posterior.sample((100,), x=x_o)

Error:
---------------------------------------------------------------------------
IndexError                                Traceback (most recent call last)
Cell In[18], line 11
      8 posterior = inference.build_posterior()
     10 x_o = torch.as_tensor([[1.0]])
---> 11 samples = posterior.sample((100,), x=x_o)

File ~/Documents/phd/sbi/sbi/inference/posteriors/direct_posterior.py:129, in DirectPosterior.sample(self, sample_shape, x, max_sampling_batch_size, sample_with, show_progress_bars)
    122 if sample_with is not None:
    123     raise ValueError(
    124         f"You set `sample_with={sample_with}`. As of sbi v0.18.0, setting "
    125         f"`sample_with` is no longer supported. You have to rerun "
    126         f"`.build_posterior(sample_with={sample_with}).`"
    127     )
--> 129 samples = accept_reject_sample(
    130     proposal=self.posterior_estimator,
    131     accept_reject_fn=lambda theta: within_support(self.prior, theta),
    132     num_samples=num_samples,
    133     show_progress_bars=show_progress_bars,
    134     max_sampling_batch_size=max_sampling_batch_size,
    135     proposal_sampling_kwargs={"condition": x},
    136     alternative_method="build_posterior(..., sample_with='mcmc')",
    137 )[0]
    139 return samples

File ~/anaconda3/envs/sbi/lib/python3.10/site-packages/torch/utils/_contextlib.py:115, in context_decorator.<locals>.decorate_context(*args, **kwargs)
    112 @functools.wraps(func)
    113 def decorate_context(*args, **kwargs):
    114     with ctx_factory():
--> 115         return func(*args, **kwargs)

File ~/Documents/phd/sbi/sbi/samplers/rejection/rejection.py:283, in accept_reject_sample(proposal, accept_reject_fn, num_samples, show_progress_bars, warn_acceptance, sample_for_correction_factor, max_sampling_batch_size, proposal_sampling_kwargs, alternative_method, **kwargs)
    278 # Update.
    279 # Note: For any condition of shape (*batch_shape, *condition_shape), the
    280 # samples will be of shape(*batch_shape, sampling_batch_size, d) and hence work
    281 # in dim = -2.
    282 num_sampled_total += sampling_batch_size
--> 283 num_remaining -= samples.shape[-2]
    284 pbar.update(samples.shape[-2])
    286 # To avoid endless sampling when leakage is high, we raise a warning if the
    287 # acceptance rate is too low after the first 1_000 samples.

IndexError: tuple index out of range

@manuelgloeckler I can have a look at this.


fix transaction too large error when use TiDB as storage

Closes #5749
TiDB can not delete many rows in one transaction.
so maybe we can use @xxxlxy2008 's genius idea --- split one delete stmt into multiple delete stmt with limit and loop until all wanted data has be deleted
to detect affect-row, users need ensure "useAffectedRows=true" must be configured in jdbc url.
to don't affect MySQL logic, we can extend a new TiDBStorageProvider, TiDB user can use
storage:
  tidb:

to replace
storage:
  mysql:

to use this patch.

remain question: delete ... limit N will became slower due to TiDB need scan delete tombstone again again, but maybe it can be improve in future, this PR just handle "transaction too large error"

@moonsphere I have a direct talk with PingCap's friends, right now, as a minor change, this deletion way seems the best choice.

@moonsphere Are you still working on this?

As no update, this is going to be replaced by #5844


Add tick system and fire rate.

Additionally, it might make sense to use 3 lists instead of 2. If the firing rate of the input neurons is now 0, then the neural network would still start completely from the beginning. This raises the question of whether neurons whose firing rate is 0, the following neurons nevertheless come into the open list. Theoretically, this should happen, because otherwise it becomes much more complex.
Therefore, I would suggest that the list is only generated during the first tick cycle and all subsequent cycles use the list already created.

For performance reasons, the closed list could perhaps be dropped, since the list is worked through from start to finish anyway.
Likewise, you could abandon the silent list and instead briefly check the fire rate to see if it is == 0.


Migrate to Swift 5 and use native Result

What did you change and why?
I've migrated the project to Swift 5 and use platform's native Result to remove third party dependency.
Potential risks introduced?
None.
What tests were performed (include steps)?
All tests are passing and sample app works correctly.
Checklist

[x] Unit/UI tests have been written (if necessary)
[x] Manually tested

Hey @dhavalshreyas,
Is there anything I need to do to get this pr merged?


"slow" movement

Hi!
I really love the TeensyStep Lib. Sad story, that it is quite difficult to get teensy 3.5.
So I tried the new one! (Thanks a lot!) but it seems to be quiet slow?
I run a 256 TMC2209 via 256 micro stepping at a 200 resolution stepper.  Sams stepper is way faster with the TMC2209 nativ velocity function which drives it via UART.
Is it possibly since the teensy 4.1 should be way faster than the 3.5?

Actually, as mentioned in the Readme the library is just a quick and dirty experiment. It needs a complete rewrite, but I currently don't find time for this.

Is it possibly since the teensy 4.1 should be way faster than the 3.5?

Unfortunately the interrupt system of the T4 is not much faster that the one on the T3.5/6. This is due to synchronization issues between the internal busses which run on different speeds. See here for more information on this: https://forum.pjrc.com/index.php?threads/teensy-4-intervaltimer-max-speed.57959/#post-218567

Thanks for your fast reply! I know that you don't find the time at the moment. That is perfectly fine. :)
Maybe I get things done be myself. For a start, where would you look for to fix the issue in the experimental TeensyStep4?
With the current setup I get approximately 200.000 steps per second. (I am for the 500.000 which are possible with the Teensy 3.5)

For a start, where would you look for to fix the issue in the experimental TeensyStep4?

TeensyStep4 uses the 16bit TMR timers instead of the 32bit PIT modules I used for the T3x boards. That would allow for a dedicated timer for nearly each pin (not yet implemented) Thus, the annoying 4 timer limit of the old lib would be gone. However, since the timers are 16bit only one needs to play with the prescaler.
Currently you can only choose a fixed prescaler value (default: 5). You can change that here:
https://github.com/luni64/TeensyStep4/blob/42e1f69450902c7f96d7cd11ab079036adc36d18/src/timers/Teensy4/TMR/TMR.h#L29
Choosing a smaller value would increase both, the max as well as the min speed of the motors. Hope that helps.
Nice project by the way!

Nice! Thanks a lot. That worked! Lowering the  prescale = 4 and at the same time setting a 70.000 steps/s speed limit worked fine for my tmc2209 at 256 microstepping, while keeping the noise low and increasing speed of the stepper to 3 turns per second. More would be possible, but the noise of the stepper increases and now the limit is the stepper, which can't handle too many steps/s, which the lib now delivers. 👍

Great, have fun


[fixed] vulnerability found in package @angular/core [MASTER PR]

v2.0.5
removed unused package codelyzer
JIRA https://scheduleonce.atlassian.net/browse/ONCEHUB-73311

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign so-abahadur
You can assign the PR to them by writing /assign @so-abahadur in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

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

/retest

[APPROVALNOTIFIER] This PR is APPROVED
Approval requirements bypassed by manually added approval.
This pull-request has been approved by: raghavaggarwalOH
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

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

[APPROVALNOTIFIER] This PR is APPROVED
Approval requirements bypassed by manually added approval.
This pull-request has been approved by: raghavaggarwalOH
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

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


Single image uploading mode

What do you particularly mean?

I mean replace image in preview bar

@mitin123 is it something like that you want to upload only one image, previewed and replace same image with other?


Fix issue #123 build ftp fails on linux

This fixes #123 and improves the setup.sh file that install.sh creates.  When install.sh builds prerequisites from source, "source setup.sh" sets LD_LIBRARY_PATH correctly for both 32- and 64-bit builds on Linux and OS X and it adds gfortran/gcc/g++ to PATH and correctly detects when to add m4 to the PATH.

Current coverage is 39.12%

Merging #133 into master will not affect coverage as of 97c14df

@@            master    #133   diff @@
======================================
  Files            2       2
  Stmts          892     892
  Branches         0       0
  Methods          0       0
======================================
  Hit            349     349
  Partial          0       0
  Missed         543     543

Review entire Coverage Diff as of 97c14df

Uncovered Suggestions

+1.92% via src/mpi/mpi_caf.c#1903...1919
+1.58% via src/mpi/mpi_caf.c#2001...2014
+1.58% via src/mpi/mpi_caf.c#1557...1570
See 7 more...

Powered by Codecov. Updated on successful CI builds.

LGTM

LGTM too


Warning fixes

It's important to fix compiler warnings. Many warnings indicate real problems with the code. In particular, unused variables often indicate remote date that is read but not used. Those warnings are not fixed. They should be fixed by those who can improve the code.
What is fixed is the easy stuff, the warnings that obscure bigger problems.
In addition to the compiler warnings, a warning from Valgrind has been fixed. Intercepting SIGKILL doesn't work and should not be done.

I don't like using g_write("\n") instead of g_writeln("")
The purpose of writeln is so that you don't need to think about EOL.
\r\n in Windows and \r on mac and \n in Linux.

Good point, I'll redo that part. I'm torn between adding "-Wno-format-zero-length" for compilers that support it (that warning is not that useful anyway) and having a new macro for a newline. Let me see what would look better.
By the way, xrdp would greatly benefit from using glib - it has a lot of stuff xrdp has to implement on its own, including logging: https://developer.gnome.org/glib/stable/glib-Message-Logging.html
Also, the unnamed semaphores don't work in MacOS. glib would fix that easily. Perhaps we need a separate forum to discuss glib. MacOS is a good platform to support, it has Microsoft RDP client, and it's good to have a reference client and a server on the same system.

I made a version with variadic g_writeln. The problem is, it uses ##__VA_ARGS__ - most compilers support it, but it's not a standard. I don't want to use the alternative, knows as argument counting, as it's ugly and has its limitations (http://stackoverflow.com/questions/5588855/standard-alternative-to-gccs-va-args-trick)
I'll try "argument counting lite", i.e. some simple macro trick to enable g_writeln with no arguments or something like that.
I thought of GCC pragma to suppress the warning, but I'll need to check that it doesn't break any other compilers.
There is always an option to disable the warning in configure.ac if nothing better cam be done.
Please feel free to merge two other patched for now.

@proski
so if we do g_writeln("%s", "");
it's ok, right?

That looks too complex for adding a newline. I want something that is simple, readable, secure, not wasteful, and doesn't set a bad example. Introducing a new function to print the newline would not be readable either - that's one more thing to remember. The gcc warning for empty format is only useful if the format is used as is, not when something is appended. I'm very close to disabling that warning, which should be easy with Autoconf archive macros. But I still want to try some macro magic, just in moderate amounts - two or three lines.

I've been trying to avoid variable parameter macros.  They are not standard.
I prefer the double (( )) instead like the LLOGLN macro

I still prefer g_writeln("%s", "");
over changing g_writeln to a variadic macro


jf mvn install with osgi bundle doesn't upload pom

Describe the bug
With a simple maven project which have a pom with a bundle packaging and use maven plugin org.apache.felix:maven-bundle-plugin, when i perform a jf mvn install command, only the bundle is published on artifactory.
When I execute mvn deploy command without Jfrog CLI, the jar and the pom are published.
Current behavior
with this command jf mvn install, I can see this in the log 👍
INFO org.apache.maven.cli.event.ExecutionEventLogger - --- maven-install-plugin:3.0.1:install (default-install) @ transverse.hazelcast.model ---

INFO org.codehaus.plexus.PlexusContainer - Installing pom.xml to /root/.m2/repository/com/sncf/geomobiles/transverse.hazelcast.model/<IP_ADDRESS>-SNAPSHOT/transverse.hazelcast.model-<IP_ADDRESS>-SNAPSHOT.pom
INFO org.codehaus.plexus.PlexusContainer - Installing target/transverse.hazelcast.model-<IP_ADDRESS>-SNAPSHOT.jar to /root/.m2/repository/com/sncf/geomobiles/transverse.hazelcast.model/<IP_ADDRESS>-SNAPSHOT/transverse.hazelcast.model-<IP_ADDRESS>-SNAPSHOT.jar

INFO org.apache.maven.cli.event.ExecutionEventLogger - --- maven-bundle-plugin:3.3.0:install (default-install) @ transverse.hazelcast.model ---
INFO org.apache.felix.obrplugin.ObrInstall - Writing OBR metadata
INFO org.apache.felix.obrplugin.ObrInstall - Installing com/sncf/geomobiles/transverse.hazelcast.model/<IP_ADDRESS>-SNAPSHOT/transverse.hazelcast.model-<IP_ADDRESS>-SNAPSHOT.jar
INFO org.apache.felix.obrplugin.ObrInstall - Writing OBR metadata
 [pool-5-thread-1] INFO org.jfrog.build.extractor.maven.ArtifactoryManagerBuilder - [pool-5-thread-1] Deploying artifact: https://artefact-repo.apps.eul.sncf.fr/artifactory/.../com/sncf/geomobiles/transverse.hazelcast.model/<IP_ADDRESS>-SNAPSHOT/transverse.hazelcast.model-<IP_ADDRESS>-SNAPSHOT.jar

```

So the install command install pom and jar in my local maven repository and the the  maven-bundle-plugin:install goal is executed and only the jar is published on artifactory

### Reproduction steps

- With a simple osgi bundle maven project ([example](https://github.com/sharma-gaurav/osgibndle))
- run a `jf config add` command to configure artifactory platform authentication
- run `jf mvn install` command

### Expected behavior

I expect the pom file to be published by the `jf mvn install` command

### JFrog CLI version

2.26.2

### Operating system type and version

Linux (Docker: maven:3-openjdk-11 image)

### JFrog Artifactory version

7.41.7

### JFrog Xray version

3.55.2

sorry for the late but it's ok

Was this resolved as i am still experiencing this issue?


rebased canonical/json off go 1.5.1

ping @tianon @runcom @tonistiigi @tiborvass

:) LGTM

@jfrazelle did you have to change anything or it's a simple conflict-free rebase?

conflict free!! :) it was so nice i had to do it twice to be sure hahaha

LGTM

LGTM. Test failing is unrelated to this change. Merging.


Support for private docker repositories

What type of PR is this?
/kind feature

What this PR does / why we need it:
Adds a way to additionally add a secret for docker repositories
Which issue(s) this PR fixes:

Special notes for your reviewer:
Does this PR introduce a user-facing change?:

Add support for private repositories

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign admiral0
You can assign the PR to them by writing /assign @admiral0 in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

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

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: fntlnz
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [fntlnz]

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


Usage with HOC loading

Just a tip on how to use this library together with a HOC-loader like redux-connect:
// Your wrapped component
const MyAsyncComponent = loadable(() => import('./MyAsyncComponent/MyAsyncComponent'))

// Utility to extract the wrapped component if loadable-HOC will conflict with your other HOCs
const loadableWrapper = (cb, LoadableComponent) => {
  LoadableComponent.load().then((Comp) => {
    cb(null, Comp)
  }).catch((error) => {
    console.log('Error loading', error)
  })
}

<Route path='/some-path' getComponent={(nextState, cb) => loadableWrapper(cb, MyAsyncComponent)} />

Later discovered that for SSR intial render we need to extract loadable-id and set a loadable key on the loaded component. If not the component would not be included in the script-tag, and you will have a flicker with nothing on the screen after intial SSR render while client-side is taking over. I use Preact and Preact-compat in production and it works fine now.
// Your wrapped component
const MyAsyncComponent = loadable(() => import('./MyAsyncComponent/MyAsyncComponent'))

// In your router-file
import { LOADABLE } from 'loadable-components/constants'

// Utility to extract the wrapped component if loadable-HOC will conflict with your other HOCs
const loadableWrapper = (cb, LoadableComponent) => {
  LoadableComponent.load().then((Comp) => {
    // Add LOADABLE-key and loadable-componentId to the component you send back to react-router (v3)
    Comp[LOADABLE] = () => LoadableComponent
    Comp.componentId = LoadableComponent.componentId
    cb(null, Comp)
  }).catch((error) => {
    console.log('Error loading', error)
  })
}

<Route path='/some-path' getComponent={(nextState, cb) => loadableWrapper(cb, MyAsyncComponent)} />

Thanks for this :)

@gerhardsletten you're rock! Do you work around with the react loadable and this issue? I can't repeat a same behaviour.

The above code is with react-router v3, but with react-router v4 (and redux-connect) combining both the async Hoc and make the container lazyload is not possible. You need to re-organize your code having the Hoc above, and inside it lazyload the View with all heavy dendencies, like this:
import React, { Component } from 'react'
import { connect } from 'react-redux'
import { asyncConnect } from 'redux-connect'
import loadable from 'loadable-components'
import { isLoaded as isPageLoaded, load as loadPage } from 'redux/modules/page'

const PageView = loadable(() =>
  import(/* webpackChunkName: "PageView" */'./PageView')
)

@asyncConnect([
  {
    promise: ({ store: { dispatch, getState }, location: { pathname } }) => {
      const promises = []
      if (!isPageLoaded(getState(), pathname)) {
        promises.push(dispatch(loadPage(pathname)))
      }
      return Promise.all(promises)
    }
  }
])
@connect(
  state => ({
    page: state.page.data
  })
)
export default class PageViewContainer extends Component {
  render() {
    return <PageView {...this.props} />
  }
}

Hi.
Is this still the right way to work with asyncConnect'ed components? It seems like the load() method is not available on the loadable component.

Hi @jjblumenfeld
I just updated my latest commend from 9 august with the new scoped package-name for loadable.
Mark that the load-method is from my own projects redux-ducks modules, it return a promise used within @asyncConnect to reflect when the pages content is loaded
...
import { isLoaded as isPageLoaded, load as loadPage } from 'redux/modules/page'

Thanks. I am trying that now, it is not quite working yet for me. I am using react-router v3.2.1 and redux-connect v6.0.0, so I'm not sure if I should be using something more like the first example or the second one?

redux-connect just published v9 that supports<EMAIL_ADDRESS>(new context api), maybe you need to update. Is the problem redux-connect and loading everything on server that is the problem, or is it the code-splitting that does not work?

I was able to get code-splitting working, but loading everything serverside
is not working for me.
On Tue, Mar 12, 2019 at 5:30 AM Gerhard Sletten<EMAIL_ADDRESS>wrote:

redux-connect just published v9 that supports<EMAIL_ADDRESS>(new
context api), maybe you need to update. Is it redux-connect and loading
everything on server that is the problem, or is it the code-splitting that
does not work?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/smooth-code/loadable-components/issues/15#issuecomment-471920281,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACAh5jJKRPmRobeqSbXwIlLV2UgXdNKCks5vV3OfgaJpZM4P-5bT
.

Its hard to tell you what you do wrong without seeing some code, please provide that and I will look into it. But in the server, its important to call redux-connects loadOnServer before ChunkExtractor from @loadable/server, and you can only do code-splitting below asyncConnect

Thanks again for your patient replies!
I found my issue. When I was re-factoring my code I had left some of the loadable/code-splitting code above an asyncConnect. I have re-factored it to put the asyncConnect around a wrapper which contains the loadable component as you had in your second example and it all works nicely now.

Great!

@jjblumenfeld Can you provide your working example here? Actually, I am also stuck on the same problem. asyncConnect is not working in SSR after migrating from loadable-component 2.2.2 to 5.6

Hi @jjblumenfeld
I just updated my latest commend from 9 august with the new scoped package-name for loadable.
Mark that the load-method is from my own projects redux-ducks modules, it return a promise used within @asyncConnect to reflect when the pages content is loaded
...
import { isLoaded as isPageLoaded, load as loadPage } from 'redux/modules/page'

Hey @gerhardsletten, can you please share what is inside your import { isLoaded as isPageLoaded, load as loadPage } from 'redux/modules/page'? I wan't to see how do you load the component.

I'm trying to solve Did not expect server HTML to contain a <div> in <div>. this problem about for about a week already and no success. On server, I did everything correctly, put ChunkExtractor after loadOnServer.
On the client, I wrapped hydration with loadableReady, but whenever I add loadable to any route, it starts showing me the error above.

Here is the screenshot with the populated HTML from server

and this one is after hydration

this is our home page route, wrapped to our asyncConnectWithModifications which is same as asyncConnect

@gloompi Taking a look at your screenshot, and I think the connected Component needs to be a regular react-component and not a "loadable"-component, so if you add
const Home = loadable(() => import('./Home'))
// Insert this
const HomeContainer = (props) => {
  return <Home {...props} />
}

And at the end you pass this HomeContainer:
)(HomeContainer)

@gerhardsletten I have tried this approach as well, but it didn't work. I still think that it's related to async load somehow, can you share what are you were doing inside the redux? Especially the loadPage action?

@gloompi Could you extract this into an example and share this on github? Getting it right with ssr also involves your babel-config, webpack setup and both your server.js and client.js entrypoint. Most likely you have something one places that cases this problem.

@gerhardsletten sure, I actually had open an issue here https://github.com/gregberge/loadable-components/issues/633.
And there you can find all the examples with configs.

@gerhardsletten if it's not enough, I can try to create a repo with similar configs

@gloompi It would be great if you could extract a runable example

@gerhardsletten hey, glad to inform you that the new version of loadable/components solved my issue.

@gloompi Great, all good debug-sessions starts with npm update ;-)


[Service Bus] Allow settling messages irrespective of receiver being active

Currently, the renewlock for received messages and the settlement for non-deferred messages would fail if the receiver is not open or doesn't exist.
These operations technically do not need an active receiver.
TO DO

Verify if the settlement and renewlock need the receiver
Check if there are any perf implications for switching over to the alternative
If not, lift the restrictions of needing to have a receiver to settle/renewlock

This is candidate for Track 1 too as it can greatly help existing users for who see broken links/connection being recovered and now cannot settle their messages

#8406 - track 1
#8340 - track 2
Both the PRs are merged. Closing the issue.


⚠ ClamAV has degraded performance

In be6d0ee, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 441 ms

Resolved: ClamAV performance has improved in bce9490.