Error with MQCNNEstimator in benchmark_m4 examples

Description
Using m4_weekly, for example, MQCNNEstimator yields NaN loss for each batch:
WARNING:gluonts.trainer:Batch [1] of Epoch[0] gave NaN loss and it will be ignored

On epoch end, the program crashes with the error:
gluonts.core.exception.GluonTSUserError: Got NaN in first epoch. Try reducing initial learning rate.

With hybridize=False, these errors do not show up anymore, but training exhibits funny loss values (in the range of a few hundreds). As a reference, DeepAREstimator yields consistent loss values (in a range less that 10), independently of hybridize being True or False.
On a side note, I wonder to which extent this bug is related to #833 .
To Reproduce
A simplified and adapted version of benchmark_m4 is in this gist.
Error message or code output
evaluating MQCNNEstimator on m4_weekly
learning rate from ``lr_scheduler`` has been overwritten by ``learning_rate`` in optimizer.
  0%|                                                                                | 0/50 [00:00<?, ?it/s]/usr/local/lib/python3.6/dist-packages/gluonts/time_feature/_base.py:121: FutureWarning: weekofyear and week have been deprecated, please use DatetimeIndex.isocalendar().week instead, which returns a Series.  To exactly reproduce the behavior of week and weekofyear and return an Index, you may call pd.Int64Index(idx.isocalendar().week)
  return index.weekofyear / 51.0 - 0.5
[06:49:54] src/operator/nn/./cudnn/./cudnn_algoreg-inl.h:97: Running performance tests to find the best convolution algorithm, this can take a while... (set the environment variable MXNET_CUDNN_AUTOTUNE_DEFAULT to 0 to disable)
WARNING:gluonts.trainer:Batch [1] of Epoch[0] gave NaN loss and it will be ignored
  2%|##                                                                                | 1/50 [00:01<00:57,  1.17s/it, epoch=1/100, avg_epoch_loss=nan]WARNING:gluonts.trainer:Batch [2] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [3] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [4] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [5] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [6] of Epoch[0] gave NaN loss and it will be ignored
 12%|############3                                                                                | 6/50 [00:01<00:07,  6.17it/s, epoch=1/100, avg_epoch_loss=nan]WARNING:gluonts.trainer:Batch [7] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [8] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [9] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [10] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [11] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [12] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [13] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [14] of Epoch[0] gave NaN loss and it will be ignored
 28%|############################5                                                                         | 14/50 [00:01<00:02, 15.93it/s, epoch=1/100, avg_epoch_loss=nan]WARNING:gluonts.trainer:Batch [15] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [16] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [17] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [18] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [19] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [20] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [21] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [22] of Epoch[0] gave NaN loss and it will be ignored
 44%|############################################8                                                         | 22/50 [00:01<00:01, 25.81it/s, epoch=1/100, avg_epoch_loss=nan]WARNING:gluonts.trainer:Batch [23] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [24] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [25] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [26] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [27] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [28] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [29] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [30] of Epoch[0] gave NaN loss and it will be ignored
 60%|#############################################################2                                        | 30/50 [00:01<00:00, 34.97it/s, epoch=1/100, avg_epoch_loss=nan]WARNING:gluonts.trainer:Batch [31] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [32] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [33] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [34] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [35] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [36] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [37] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [38] of Epoch[0] gave NaN loss and it will be ignored
 76%|#############################################################################5                        | 38/50 [00:01<00:00, 43.61it/s, epoch=1/100, avg_epoch_loss=nan]WARNING:gluonts.trainer:Batch [39] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [40] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [41] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [42] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [43] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [44] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [45] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [46] of Epoch[0] gave NaN loss and it will be ignored
 92%|#############################################################################################8        | 46/50 [00:01<00:00, 50.33it/s, epoch=1/100, avg_epoch_loss=nan]WARNING:gluonts.trainer:Batch [47] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [48] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [49] of Epoch[0] gave NaN loss and it will be ignored
WARNING:gluonts.trainer:Batch [50] of Epoch[0] gave NaN loss and it will be ignored
100%|######################################################################################################| 50/50 [00:01<00:00, 26.63it/s, epoch=1/100, avg_epoch_loss=nan]
Traceback (most recent call last):
  File "benchmark_m4_sample.py", line 89, in <module>
    evaluate("m4_weekly", "MQCNNEstimator")
  File "benchmark_m4_sample.py", line 69, in evaluate
    predictor = estimator.train(dataset.train)
  File "/usr/local/lib/python3.6/dist-packages/gluonts/model/estimator.py", line 276, in train
    **kwargs,
  File "/usr/local/lib/python3.6/dist-packages/gluonts/model/estimator.py", line 249, in train_model
    validation_iter=validation_data_loader,
  File "/usr/local/lib/python3.6/dist-packages/gluonts/mx/trainer/_base.py", line 392, in __call__
    "Got NaN in first epoch. Try reducing initial learning rate."
gluonts.core.exception.GluonTSUserError: Got NaN in first epoch. Try reducing initial learning rate.

Environment

Operating system: Ubnutu 18.04
Python version: 3.6.9
GluonTS version: 0.6.7
MXNet version: 1.7.0
CUDA: 10.1
CUDNN: 7

Hey @pbruneau thanks for submitting this!
One note:

With hybridize=False, these errors do not show up anymore, but training exhibits funny loss values (in the range of a few hundreds). As a reference, DeepAREstimator yields consistent loss values (in a range less that 10), independently of hybridize being True or False.

This is not necessarily an issue, since DeepAREstimator and MQCNNEstimator optimize rather different losses: the former optimizes negative log-likelihood wrt some parametric distribution family, the latter optimizes the average quantile loss over the grid of quantile levels it is configured with.

Hi @lostella, thank you for the timely answer and explanation! After checking the final result, the metrics eventually obtained do not look absurd indeed.
I guess only the main issue of NaN loss values showing up with MQCNNEstimator and hybridize=True remains then.

Hi, I am facing same issue even if I used MQCNNEstimator with mxnet-cu101==1.8.0.
Here is the trainer and estimator parameters:
!pip install git+https://github.com/awslabs/gluon-ts.git
!pip install mxnet-cu101==1.8.0 -f https://dist.mxnet.io/python/all

trainer=Trainer(
                batch_size=32, # also tried with 64
                clip_gradient=10.0,
                ctx=ctx,
                epochs=20,
                hybridize=False,
                init="xavier",
                learning_rate=0.0001, # also tried with 0.001
                # learning_rate_decay_factor=0.05,
                # minimum_learning_rate=5e-05,
                num_batches_per_epoch=50,
                patience=10,
                # weight_decay=1e-08,
                )

estimator = MQCNNEstimator(freq="M",
                            prediction_length = prediction_len,
                            context_length = prediction_len*2,
                            trainer=trainer,
                            use_feat_static_cat = False,
                            use_feat_dynamic_real = True,
                            scaling=False, # also tried with True
                            # cardinality = stat_cat_cardinalities,
                            distr_output = StudentTOutput(),
                            channels_seq=[30,30,30],
                            dilation_seq=[1,3,5],
                            )

I also tried with hybridize/scaling True and False and with various learning rates. I am still getting this error:
/usr/local/lib/python3.7/dist-packages/gluonts/dataset/common.py:324: FutureWarning: The 'freq' argument in Timestamp is deprecated and will be removed in a future version.
  timestamp = pd.Timestamp(timestamp_input, freq=freq)
/usr/local/lib/python3.7/dist-packages/gluonts/dataset/common.py:327: FutureWarning: Timestamp.freq is deprecated and will be removed in a future version
  if isinstance(timestamp.freq, Tick):
/usr/local/lib/python3.7/dist-packages/gluonts/dataset/common.py:338: FutureWarning: Timestamp.freq is deprecated and will be removed in a future version
  return timestamp.freq.rollforward(timestamp)
/usr/local/lib/python3.7/dist-packages/gluonts/transform/split.py:36: FutureWarning: Timestamp.freq is deprecated and will be removed in a future version
  return _shift_timestamp_helper(ts, ts.freq, offset)
/usr/local/lib/python3.7/dist-packages/gluonts/transform/feature.py:352: FutureWarning: Timestamp.freq is deprecated and will be removed in a future version
  self._min_time_point, self._max_time_point, freq=start.freq
  0%|          | 0/50 [00:00<?, ?it/s]Batch [1] of Epoch[0] gave NaN loss and it will be ignored
/usr/local/lib/python3.7/dist-packages/gluonts/transform/split.py:36: FutureWarning: Timestamp.freq is deprecated and will be removed in a future version
  return _shift_timestamp_helper(ts, ts.freq, offset)
Batch [2] of Epoch[0] gave NaN loss and it will be ignored
Batch [3] of Epoch[0] gave NaN loss and it will be ignored
Batch [4] of Epoch[0] gave NaN loss and it will be ignored
Batch [5] of Epoch[0] gave NaN loss and it will be ignored
Batch [6] of Epoch[0] gave NaN loss and it will be ignored
Batch [7] of Epoch[0] gave NaN loss and it will be ignored
Batch [8] of Epoch[0] gave NaN loss and it will be ignored
Batch [9] of Epoch[0] gave NaN loss and it will be ignored
Batch [10] of Epoch[0] gave NaN loss and it will be ignored
Batch [11] of Epoch[0] gave NaN loss and it will be ignored
Batch [12] of Epoch[0] gave NaN loss and it will be ignored
Batch [13] of Epoch[0] gave NaN loss and it will be ignored
Batch [14] of Epoch[0] gave NaN loss and it will be ignored
Batch [15] of Epoch[0] gave NaN loss and it will be ignored
Batch [16] of Epoch[0] gave NaN loss and it will be ignored
Batch [17] of Epoch[0] gave NaN loss and it will be ignored
Batch [18] of Epoch[0] gave NaN loss and it will be ignored
Batch [19] of Epoch[0] gave NaN loss and it will be ignored
Batch [20] of Epoch[0] gave NaN loss and it will be ignored
 40%|████      | 20/50 [00:10<00:15,  1.98it/s, epoch=1/20, avg_epoch_loss=nan]Batch [21] of Epoch[0] gave NaN loss and it will be ignored
Batch [22] of Epoch[0] gave NaN loss and it will be ignored
Batch [23] of Epoch[0] gave NaN loss and it will be ignored
Batch [24] of Epoch[0] gave NaN loss and it will be ignored
Batch [25] of Epoch[0] gave NaN loss and it will be ignored
Batch [26] of Epoch[0] gave NaN loss and it will be ignored
Batch [27] of Epoch[0] gave NaN loss and it will be ignored
Batch [28] of Epoch[0] gave NaN loss and it will be ignored
Batch [29] of Epoch[0] gave NaN loss and it will be ignored
Batch [30] of Epoch[0] gave NaN loss and it will be ignored
Batch [31] of Epoch[0] gave NaN loss and it will be ignored
Batch [32] of Epoch[0] gave NaN loss and it will be ignored
Batch [33] of Epoch[0] gave NaN loss and it will be ignored
Batch [34] of Epoch[0] gave NaN loss and it will be ignored
Batch [35] of Epoch[0] gave NaN loss and it will be ignored
Batch [36] of Epoch[0] gave NaN loss and it will be ignored
Batch [37] of Epoch[0] gave NaN loss and it will be ignored
Batch [38] of Epoch[0] gave NaN loss and it will be ignored
Batch [39] of Epoch[0] gave NaN loss and it will be ignored
Batch [40] of Epoch[0] gave NaN loss and it will be ignored
 80%|████████  | 40/50 [00:22<00:05,  1.76it/s, epoch=1/20, avg_epoch_loss=nan]Batch [41] of Epoch[0] gave NaN loss and it will be ignored
Batch [42] of Epoch[0] gave NaN loss and it will be ignored
Batch [43] of Epoch[0] gave NaN loss and it will be ignored
Batch [44] of Epoch[0] gave NaN loss and it will be ignored
Batch [45] of Epoch[0] gave NaN loss and it will be ignored
Batch [46] of Epoch[0] gave NaN loss and it will be ignored
Batch [47] of Epoch[0] gave NaN loss and it will be ignored
Batch [48] of Epoch[0] gave NaN loss and it will be ignored
Batch [49] of Epoch[0] gave NaN loss and it will be ignored
Batch [50] of Epoch[0] gave NaN loss and it will be ignored
100%|██████████| 50/50 [00:30<00:00,  1.65it/s, epoch=1/20, avg_epoch_loss=nan]
---------------------------------------------------------------------------
GluonTSUserError                          Traceback (most recent call last)
[<ipython-input-10-6a21663e1979>](https://localhost:8080/#) in <module>()
      1 predictor_2019_12_t, test_data_2019_12 = model(prediction_len = prediction_len, all_df=all_df_2019_12, distr_output = StudentTOutput(),
----> 2                                                epochs=20, num_batches_per_epoch=50, learning_rate=0.0001, scaling=False)

7 frames
[/usr/local/lib/python3.7/dist-packages/gluonts/mx/trainer/learning_rate_scheduler.py](https://localhost:8080/#) in on_epoch_end(self, epoch_no, epoch_loss, training_network, trainer, best_epoch_info, ctx)
    231             if best_epoch_info["epoch_no"] == -1:
    232                 raise GluonTSUserError(
--> 233                     "Got NaN in first epoch. Try reducing initial learning rate."
    234                 )
    235

GluonTSUserError: Got NaN in first epoch. Try reducing initial learning rate.

Thanks in advance!

I am having the same issue, any help is appreciated!

If this happens when StudentTOutput is used, the problem may be related to #1894


[wip] revisiting shutdown

Description

Notes & open questions

Change checklist

[ ] Self-review.
[ ] Documentation updates if relevant.
[ ] Tests if relevant.

Closing, as we have merged #2227


NewCorner label

As we are displying only that contributers whose atleast one PR is accepted.. so "contributer" label assign to them.. so no need more "Newcorner" label..

/assign

done, removed now!


[$250] Firefox - All the dropdown options appear gray in color and different font

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Access staging.new.expensify.com
Log in any account
Navigate to settings by clicking on the user avatar over LHN
Click on Profile
Click on “Preferred Pronouns” or Select any of the dropdowns in the settings page (preferences, or from the workspace editor)

Expected Result:
Dropdowns will have same font as in the app and background color should be white
Actual Result:
Dropdown options appear gray backgroud color and different font
Workaround:
Visual
Platform:

Where is this issue occurring?

Web - Firefox

Version Number: 1.1.73-0
Reproducible in staging?: Y
Reproducible in production?: Y
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos:

Upwork Job Link: https://www.upwork.com/jobs/~011c612d785f81ca45
Issue reported by:
Applause internal team
Slack conversation:
View all open jobs on GitHub

Weird/interesting, this is only a problem in firefox (not chrome) 😄
@kavimuru do you know if it was a regression?
For whomever gets to work on this, I'm curious to know where this problem is from (and if we can track it to a regression).

Posted to upwork, link here - https://www.upwork.com/jobs/~011c612d785f81ca45

Proposal
Issue
Dropdown options appear gray backgroud color and different font
Fix
Firefox doesn't allow setting fontFamily in  if this font is not installed on the device since the page is consulted.
For example:
Set Futura font to  that is install.

Everything works well.
But if you remove Futura from the device.

We have the same problem.

Now, knowing that the required font cannot be assigned, how do we avoid displaying such a different font.
 It's like a backup font.
Even better, assign a group of fonts that looks like ours. In this case Sans-Serif o font-family: 'revert'
Option 1: With font-family: 'revert' (Best option)
Revert property

Option 2: With fontFamily:  'GTAmericaExp-Regular, Sans-Serif'

Between option 1 or option 2 there is only a slight difference in the font when the list of options is displayed.
As it currently looks
Mac/Safari/Dark mode

Mac/Chrome/Dark mode

Mac/Mozilla/Dark mode

Mac/Safari/Light mode

Mac/Chrome/Light mode

Mac/Mozilla/Light mode

This proposal would only affect Web/Mozilla

Thanks for the insights! Which font is it not getting? Can we not somehow force install it?

GTAmericaExp-Regular is the font that the project is using.
We cannot force the installation of any font on the devices.

Thanks. Pardon my ignorance -- how does this work on other platforms / devices?
@mananjadhav what are you thoughts?

@flodnv In webkit browsers (chrome, safari). the  tag can't be styled through CSS. This depends on the operating system.
In Firefox, some styles can be styled via CSS, for example: font-family can be assigned a custom font, but it depends on whether the font exists in the OS.
This is a list of  tag:

Please give me time to check possible causes for FF. I vaguely we had set up @font-face and relative paths to the fonts in FF for other projects. Let still find some information and get back.
Thank you for your comments @JosueEchandiaAsto.

Thanks for the insights @JosueEchandiaAsto.
@flodnv I spent some time digging into different approaches to solve this. @JosueEchandiaAsto is right, that the option tag doesn't inherit the page/parent font. We can set styles like bold, etc, but not font-family.
I tried multiple faces to force font and @font-face, etc. but none of them worked. I also checked other apps like Slack. They don't use the default select-option tag for dropdown, but a custom implementation with div-span.
We have the following ways to approach this:

Do nothing as no functionality is breaking or is such a bad UX which makes the app/feature unusable. Firefox has about 7% users.
Add a fallback font like Serif that firefox supports by default.
Replace the Picker component to something that uses div-span so that appropriate styling can be performed.

Let me know your thoughts.

Thanks @mananjadhav. I posted in Slack about this https://expensify.slack.com/archives/C01GTK53T8Q/p1655492405932969 (which we should do when we have to make such big decisions)

@flodnv & @mananjadhav - Should we hold on doubling the price of this job this until we reach a verdict on how to style dropdown options in New Expensify?

Agreed, HOLDing!

Closing per discussion in the slack thread above 👆 . This will be fixed when we re-work the push to page functionality (i.e. dropdowns are going away).


AA0232 The FlowField XXX of "TableName" should be added to the SIFT key

This bug is reported on Sep 14, 2020 in https://github.com/microsoft/AL/issues/6140 but still not fixed.
Have MS new feedback about that?

Looking at the linked issue, it seems that this rule is both useful for performance reasons and affects a large amount of partners for multiple years. Marking it for triage

@BazookaMusic Would you then reopen and process this one as well?
https://github.com/microsoft/AL/issues/6348

I will let the team decide on that. We can bundle the two bugs together as they seem to need the same fix

Yaay, four years have passed :)


{Monitor} Migrate monitor to track2

Description
Migrate monitor to track2
Testing Guide

History Notes

[Component Name 1] BREAKING CHANGE: az command a: Make some customer-facing breaking change.
[Component Name 2] az command b: Add some customer-facing feature.

This checklist is used to make sure that common guidelines for a pull request are followed.

[ ] The PR title and description has followed the guideline in Submitting Pull Requests.

[ ] I adhere to the Command Guidelines.

[ ] I adhere to the Error Handling Guidelines.

Monitor

Monitor

VM part looks good to me.

VM part looks good to me.

@jsntcy Can you help summarize common code changes in this PR?

@jsntcy Can you help summarize common code changes in this PR?


display_errors() does not work properly with multi line inputs.

The right side is master, the left side is this PR's changes.

For multi-line inputs, printing the span lines, makes it more readable - I think :)

@googlebot I signed it!

Nice. That looks much better. Thanks for doing that @aminroosta !


Ignore stacktrace part of error screen to be screenshot

📝 Description
fix flawkyness of playwright tests regarding the OS unsupported test.
❓ Context

Impacted projects: LLD
Linked resource(s): n/a

✅ Checklist

[x] Test coverage
[x] Atomic delivery
[x] No breaking changes

📸 Demo

🚀 Expectations to reach
Please make sure you follow these Important Steps.
Pull Requests must pass the CI and be internally validated in order to be merged.

/generate-screenshots

/generate-screenshots

if this issue is a problem again, someone will need to find a solution but this PR didn't address the fact the UI is randomly stretching with different width and it seems that playwright selector approach won't work because the "dark square" that replace the content will change of width.
closing this PR because i don't have time to dig more, feel free to reopen if it is a new issue to fix in future


GDScript match binding reports a warning

Godot version: 3.1.2.stable.official
Issue description: match's binding pattern produces this warning: The variable 'new_var' was used but never assigned a value.
Steps to reproduce: Use match's binding pattern in a project as per the documentation (search for binding pattern).
Minimal reproduction project:
match true:
	var new_var: # This line produces the warning
		print(new_var)

Issue is confirmed to be present on 3.2.beta.custom_build.406dac191 (commit 406dac191)
OS: Arch Linux, kernel 5.4.6-arch3-1
Graphics: Intel Integrated Graphics UHD 620 (Whiskey Lake)
For those who don't understand the error, the binding pattern displayed above is like the default case in other languages, except it gives the default value a variable name. In the case above, it assigns the variable new_var the boolean value true since no other cases exist.

This is also the case for the array patterns, not just the catch-all match case.
match [1,2]:
    [1, var x]: # Produces the same warning.
        print(x)


 It didn't work but that's lowkey usual with plugins so I tried it with /setblock redstone_block to activate a command block with the command that removes the permission but I figured out that luckperms isn't working with @p,@a,@s,@e,@r so my question is if it is fixable or I have to find another way to remove permission.

Try turning on the resolve-command-selectors option in the config

Try turning on the resolve-command-selectors option in the config

Yeah I've tried that too, but it still is not working

What server type / version?


Update animated parameters by getting current time from renderer

Hi,
This PR fixes bug #212. OSL materials and textures were not updated during animation rendering. Now they are working. What I did is instead of getting current with the call GetCOREInterface()->GetTime() I added a function to renderer to get currently rendered frame from the it.
Thanks for review!
Sergo.

Hi @dictoon ,
I added time parameter to the utility functions and then I noticed that only couple of other functions need to be changed in order to get rid of static get_time function. So I decided to change all the functions and now time is passed from the project builder to each material creation function.
It may seem too much of parameters to some of the functions, but it also makes it obvious that they all need time information to work correctly.

This might be relevant:
https://github.com/imageworks/OpenShadingLanguage/pull/828
OSL will have acess to global (or camera) frame.

So I decided to change all the functions and now time is passed from the project builder to each material creation function.

In my opinion, definitely the right solution as it makes dependencies clear.


Add a cross-platform Makefile

This will include the respective Makefile depending on the users's OS.
This is for all the people out there who are too lazy to type make -f posix.mak all the time and of course all the people who are new to the D build chain and who can now simply type the familiar make without needing to know anything about posix.mak.
See also: https://github.com/dlang/dmd/pull/7382

Any updates on the status of this or plans of going forward?

See https://github.com/dlang/dmd/pull/7382

Does it mean that the faith of this PR has been decided?

Seems like that's a "no" from Walter. Closing.


Uncaught (in promise) Error: Invalid request

Trying to execute a contract method like a simple transfer fails with the following error. No dialog pops up for approval.
Similar behavior in iPhone AlphaWallet.
I guess this could be related to a custom network I added to test my app because when I deploy the same contracts to Ropsten AlphaWallet works fine.
When I run the same app from desktop browser MetaMask works fine.

@aliveli186 how can we reproduce this?

It may already have been fixed; there has been a big refactor / improvement with dapp browser.

It may already have been fixed; there has been a big refactor / improvement with dapp browser.

When will be published?

This week, we're wrapping up all the issues found in the first Release Candidate today

We have released the new build on the PlayStore, can you check if the issue has been fixed?

iPhone version doesn't work.
Couldn't test the Android version (downloaded the APK directly from your site), since it crashes on launch inside emulator (Nox).

Have never tried to use NOX. Have you tried the emulator supplied by Android Google? It works correctly on that one.
Is Nox any good and why would ppl use it instead of the google default? Can you get root with Nox? If so I'm interested.

@JamesSmartCell Yes you can start rooted or not rooted.


Autolab Issue

Hello,
I am working on your Certs course and I have not been able to to get the Autolab portion with Multiple servers to work - The VM completion test never seems to pass after I run unattend-lab. Are their some logs I can send you to tell me what I can do to allow the lab to be built so I can continue the course? Thanks!

We need better logging no doubt about it. It is possible that everything works now.  What configuration are you using? The configurations can take longer than you think to converge. My suggestion is to open PowerShell (elevated). Change to the configuration directory. Run Get-VM. If you see any virtual machines for the configuration and they are running try running Validate-Lab to see if anything passes. Are there MOFs in the directory?
The only other suggestion I have is to wipe the lab, and run the steps outlined in Instructions.md instead of running it unattended.


climate recipes deleted and note on pre-processing in implementation

This PR removes the climate recipes that are not really very useful now that we broadened the scope to all ecosystems. I move some useful links and checks to the implementation sections of abiotic_simple and abiotic.
https://virtual-ecosystem.readthedocs.io/en/525-climate-data-resources-are-outdated-and-need-to-be-revisited/virtual_ecosystem/implementation/abiotic_simple_implementation.html
I promise this is the last docs PR for a bit ;-)
Fixes #525
Type of change

[x] New feature (non-breaking change which adds functionality)
[ ] Optimization (back-end change that speeds up the code)
[ ] Bug fix (non-breaking change which fixes an issue)

Key checklist

[x] Make sure you've run the pre-commit checks: $ pre-commit run -a
[ ] All tests pass: $ poetry run pytest

Further checks

[ ] Code is commented, particularly in hard-to-understand areas
[ ] Tests added that prove fix is effective or that feature works
[x] Relevant documentation reviewed and updated

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 94.93%. Comparing base (a51551a) to head (7cc4fcc).

Additional details and impacted files
@@           Coverage Diff            @@
##           develop     #526   +/-   ##
========================================
  Coverage    94.93%   94.93%
========================================
  Files           73       73
  Lines         4048     4048
========================================
  Hits          3843     3843
  Misses         205      205

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


strictNullChecks works unexpectedly with async-await

TypeScript Version:  2.1.5
Code
async function compileSuccess() {
    let id: string;
    Promise.resolve().then(() => {
        id = 'good luck!';
    }).then(() => {
        console.log(id);
    });
}

async function compileFailure() {
    let id: string;
    await Promise.resolve().then(() => {
        id = 'bad luck!';
    });
    console.log(id); // error TS2454: Variable 'id' is used before being assigned.
}

It might be related with https://github.com/Microsoft/TypeScript/issues/11498

Technically we can inline the function in then call since they are known to be executed before following statement (or throw an exception so following statement never reaches). But it might be very hard to tell whether a function is in then.
Yet, why not just stripping the function? Removing extraneous then function is supposed to be one feature of async/await.
async function compileFailure() {
    let id: string;
    await Promise.resolve()
    id = 'bad luck!';
    console.log(id);
}

😄
Because it was a try to make the real code simple.
async function scope(fn) {
  // doing something with bluebird disposer
  return await Bluebird.using(getSomeResource(), fn);
}

async function compileFailure() {
    let id: string;
    await scope(() => {
      id = 'bad luck!';
    });
    console.log(id);
}

I thought it would be hard to determine whether the inner code would be called or not. But bugs are bugs.

Duplicate of #11498


tools: add python interface to c++ Logreader

resolve: https://github.com/commaai/openpilot/issues/23358,  resolve: https://github.com/commaai/openpilot/issues/22500
it's fully backward compatibility with the old python interface. and added a new function findAll for faster filtering events

There are some other optimizations that need to be done. for example, msgs = list(LogReader(path)) should be changed to msgs = LogReader(path). This can reduce unnecessary copies, which can greatly improve performance.  I will commit these changes after this Pr is merged.


Removed some pre-fe code

Checking for RobloxLocked on players is useless as FE exists.
When fe wasn't a thing this made sense but it no longer does.
Not sure if some obscure code somewhere references these. If yes then those have to be removed too. (Plz check)

Not sure if some obscure code somewhere references these. If yes then those have to be removed too. (Plz check)

You should review these lines:
L558-L560: ccuser44/Adonis/MainModule/Server/Shared/Service.lua
L65, L177-L178: ccuser44/Adonis/MainModule/Server/Core/Core.lua
L1361-L1364: ccuser44/Adonis/MainModule/Server/Commands/Moderators.lua
L438-L470: ccuser44/Adonis/MainModule/Client/Core/Functions.lua
L1361-L1364: ccuser44/Adonis/MainModule/Client/Core/Anti.lua

uh oh conflict

i will fix later

Ok done. I fixed the conflict. And I removed the stuff from the other modules. I however kept stuff in the client anti as it may be usefull.
This can be merged now.


[BZ-1319742] skip xsd files not having a jaxb configuration

@mariofusco just a small note about the squashing. I think in cases like this (reproducer provided via PR) it would be better to have 2 commits. The first one would be from Marek with the reproducer and the second one from you with the fix. This would clearly separate who did what. Currently there is only a commit from Marek so he is also be the git author of the fix, which is a bit misleading. This is more about future us looking at the history and wondering who to go to ask about particular parts of the sources.

@psiroky I agree, I'll avoid the squashing in future.


Update baselines for VTK bump.

Goes with UV-CDAT/uvcdat#1348.

Thanks for making these new baselines!


LotFP generator builds characters with invalid equipment lists.

The LotFP generator uses Brendan's OD&D equipments tables. The big issue there is the price of armour is completely off. Characters from the generator will often be far better decked out than they should be.

Fixed in 33637117!


Gradient mismatch when using fp16 and freezing part parameters of model

❓ Questions and Help
Before asking:

search the issues.
search the docs.

What is your question?
I try to freeze part parameters of a model and train with fp16. But the parameter with required_grad=True do not update with the optimizer and some other parameters with required_grad=False are updating.
Code

What have you tried?
What's your environment?

fairseq Version (e.g., 1.0 or main): main
PyTorch Version (e.g., 1.0) 1.10
OS (e.g., Linux):
How you installed fairseq (pip, source): source
Build command you used (if compiling from source):
Python version:
CUDA/cuDNN version:
GPU models and configuration:
Any other relevant information:

@SefaZeng  Would you please provide your code? I have the same question.


Check if alerts exists

Check if alerts exists in routeCardHeader

@i0sea Can you tell us reviewers which locations we should search to pull up relevant routes with alerts? Ideally on dev-blue, but if there aren't enough alerts on there we can run the code locally with the dev API too.


Out of date packages failing snyk tests

V 11.2.1
I recently added this to one of my projects and instantly snyk notified me or dependency related CVEs, the ones it listed were:

From what I can see taffydb is not even used by the lib directly but instead via the jsdoc plugin so not sure why that's flagging on production level install.
Also not sure about uglify.
Can these be fixed by any chance?

Came across this today myself after adding Snyk to the project.....any input from the team?

Hi @dconeybe, @alexander-fenster, looks like both dependencies are coming from @protobufjs-cli through @google-cloud/firestore. Any thoughts on this? Thanks!

Tagging @ehsannas in my stead.

A quick update: This seems to be due to an indirect dependency of firestore@, a couple of levels deep. We are looking into the dependency tree, and we'll provide an update soon.

@ehsannas we are also facing the same issue. Is there any temporary estimate until we can get any fix for this?

Hi @pratyushKumarKarna , thanks for your patience. Since the fix is happening in Firestore's dependencies, we're still waiting for them to complete this task. Once that is done, both firestore and firebase-admin-node can update their dependencies. Internally tracked by b/247113547.

Hi everyone. I wanted to follow up on this as it was a bit hard to see what the current state of the issue is :pray:
according to this chain<EMAIL_ADDRESS>›<EMAIL_ADDRESS>›<EMAIL_ADDRESS>›<EMAIL_ADDRESS>›<EMAIL_ADDRESS>›<EMAIL_ADDRESS>Security information, does it mean you (firebase team) have to wait on all the owners of these dependencies to fix their reference to taffydb?
thank you so much for looking into it.

yes. IIUC protobufjs-cli has a new release today that should address it. Next, google-gax needs to pick up the newest version of protobufjs-cli and make a new release.

https://github.com/firebase/firebase-admin-node/issues/2061#issue-1563527424
Still Happening in 2023
Is it Safe to use ?

If you really can't wait for the update to get through the dependency chain, you can temporarily add the override to your package.json, which should fix audit messages and dependabot alerts. However, I can't attest to this not breaking stuff:
  "overrides": {
    "jsdoc": "^4.0.0"
  }

I'd expect this issue is about to get a lot more traffic as this hard started showing up in yarn audit

Thanks everyone for your patience! This issue is now fixed in google-gax: v3.5.3.
Once nodejs-firestore update google-gax in their dependency chain and release a new version, we will include that in the next firebase-admin release. In the meantime, a fresh install of firebase-admin should pull the latest google-gax version with the fix. If you already have firebase-admin installed then you might have to clean up the node_modules and package-lock.json before running npm install (please keep in mind that this could upgrade other dependencies in your project based on your package.json).

nodejs-firestore's latest release now (6.4.3) has updated google-gax (3.5.3). @lahirumaramba can you make a new firebase-admin-node release?

Should also be addressed in #2147, which we will release this week. Thanks!


Clean up function does not work

Runtime exceptions are thrown when the clean up function in main.c is executed. Right now, it's commented out and the operating system should know to reclaim the memory, but it would be a better practice to free all of the allocated memory.

After trying multiple methods of input, there were no runtime errors.


Lognames not allowed to be one character long

Fixes #214
Summary of Changes
Changed regex to allow LogName to be one character long.

Codecov Report

Merging #220 (9a27265) into master (e3dfd6a) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #220   +/-   ##
=========================================
  Coverage     71.40%   71.40%
  Complexity      818      818
=========================================
  Files           121      121
  Lines          2850     2850
  Branches        426      426
=========================================
  Hits           2035     2035
  Misses          633      633
  Partials        182      182

Impacted Files
Coverage Δ

.../main/java/seedu/address/model/person/LogName.java
83.33% <ø> (ø)

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more


Update dotnet-core-2-1.md

Does only work with
AppContext.SetSwitch("System.Net.Http.UseSocketsHttpHandler", false);

Summary
old:
AppContext.SetSwitch("System.Net.Http.useSocketsHttpHandler", false);

does not work.
new:
AppContext.SetSwitch("System.Net.Http.UseSocketsHttpHandler", false);

seems to be correct.

See also: SourceCode:HttpClientHandler.cs


digital input...issue after reading 8th input

Hey there! greatly appreciate your work. It seems to work flawlessly when reading analog input from 16 potentiometers annnd writing to 16 LEDS. Aw yeee!
I was trying out using it for reading digital input and it seems to work pretty well for buttons I have wired up to 0-7 on the multiplexer but after that for some reason if I have buttons wired up for pins 8-16 things get weird.
Heres a copy of the code I've cobbled together.
Note: I have wired up things as such:
en-> pin 24
s0-> pin 12
s1-> pin 11
s2-> pin 10
s3-> pin 19
sig -> pin 8
Each button i have wired up has a leg attached to a resistor to gnd.
`/**

This example demonstrates how to write digital signals
It assumes there are LEDs+resistors with the positive lead of the LEDs
connected to the 16 channels of the 74HC4067 mux/demux, respectively

For more about the interface of the library go to
https://github.com/pAIgn10/MUX74HC4067
*/

#include "MUX74HC4067.h"
// Creates a MUX74HC4067 instance
// 1st argument is the Arduino PIN to which the EN pin connects
// 2nd-5th arguments are the Arduino PINs to which the S0-S3 pins connect
MUX74HC4067 mux(24, 12, 11, 10, 9);
void setup()
{
// Configures how the SIG pin will be interfaced
// e.g. The SIG pin connects to PIN 3 on the Arduino,
//      and PIN 3 is a Digital Output
mux.signalPin(8, INPUT, DIGITAL);
}
// Writes to the 16 channels a HIGH value, one after the other
void loop()
{
int data;
for (int i = 0; i < 16; ++i)
{
// Connects to channel i and writes HIGH
data = mux.read(i);
if ( data == HIGH ) Serial.println(i);
delay(25);
}
mux.disable();  // Disconnects the SIG pin from any channel
delay(25);

}`
if i press my button 0 it will print to serial both 0 and 8 for some reason...

ive wrote some additional code which includes output to LEDS so you can visualize the problem a bit better and recorded a video...seems to be inputs 0,1 and 2 that are having this issue.
heres the new code
`/**

This example demonstrates how to write digital signals
It assumes there are LEDs+resistors with the positive lead of the LEDs
connected to the 16 channels of the 74HC4067 mux/demux, respectively

For more about the interface of the library go to
https://github.com/pAIgn10/MUX74HC4067
*/

#include "MUX74HC4067.h"
// Creates a MUX74HC4067 instance
// 1st argument is the Arduino PIN to which the EN pin connects
// 2nd-5th arguments are the Arduino PINs to which the S0-S3 pins connect
MUX74HC4067 mux(24, 12, 11, 10, 9);
MUX74HC4067 muxLEDS(6, 5, 4, 3, 2);
void setup()
{
// Configures how the SIG pin will be interfaced
// e.g. The SIG pin connects to PIN 3 on the Arduino,
//      and PIN 3 is a Digital Output
mux.signalPin(8, INPUT, DIGITAL);
muxLEDS.signalPin(1, OUTPUT, DIGITAL);
}
// Writes to the 16 channels a HIGH value, one after the other
void loop()
{
int data;
for (int i = 0; i < 16; ++i)
{
// Connects to channel i and writes HIGH
data = mux.read(i);
if ( data == HIGH ) {Serial.println(i);
muxLEDS.write(i,HIGH);}
delay(25);
}
mux.disable();  // Disconnects the SIG pin from any channel
delay(25);

}`
and heres the video
https://www.youtube.com/watch?v=NPcc54w_GcM&feature=youtu.be

Hi @snoophuman, thank you for the feedback (I really like the last experiment you put together).
I cannot test the code myself at the moment, so I gonna have to ask for your help.
I made a little change that I think might be causing the problem. Please give the unstable/en branch a try.

I gave it a shot, no luck.
with the new code, if buttons 0-7 are pressed it flip flops between printing out a few different numbers. If i hold them down itll print the numbers repetitively.
When buttons 8-15 are pressed, nothing at all is printed.
here's a table of what happens when each button is pressed
button 0: 1, 8, 12, 1, 8, 12, 1, 8, 12, 1, 8, 12, 1, 8, 12,
button 1: 1, 9,13, 1, 9,13, 1, 9,13, 1, 9,13, 1, 9,13, 1,
button 2: 2, 10, 14, 2, 10, 14, 2, 10, 14, 2, 10, 14,
button 3. 11, 3. 11, 3. 11, 3. 11, 3. 11, 3. 11, 3. 11,
button 4: 4,12, 4,12, 4,12, 4,12, 4,12, 4,12, 4,12,
button 5: 5, 13, 5, 13, 5, 13, 5, 13, 5, 13, 5, 13,
button 6: 6, 14, 6, 14, 6, 14, 6, 14, 6, 14, 6, 14, 6, 14,
button 7: 7, 15, 7, 15, 7, 15, 7, 15, 7, 15, 7, 15, 7, 15,
button 8: nothing
button 9: nothing
button 10: nothing
button 11: nothing
button 12: nothing
button 13: nothing
button 14: nothing
button 15: nothing
here is an additional video
https://www.youtube.com/watch?v=3HR-CvC_5Os&feature=youtu.be
i dont know much about binary and shift registers but heres a copy of the datasheet...i noticed theres a table in there that has a lot of 1s and 0s...maybe that has something to do with it
https://www.sparkfun.com/datasheets/IC/cd74hc4067.pdf
heres a link to the product page as well just in case im using the wrong hardware or somethin
https://www.sparkfun.com/products/9056

I cannot associate what's happening in your circuit with something in the code. I'd like to say I tested everything when I created the library, but I cannot remember at this point. I'm gonna have to test this myself to see if there is anything wrong with the library. But this is not going to happen soon.
In the meantime, if you are willing to continue testing, you can try a few more things (with the original code):

use different pins on the teensy
replace the pcb with a circuit you build on the breadboard
use an arduino in place of the teensy

good idea, ill try those options out! and let ya know how it goes

PROBLEM SOLVED!
It turns because I was using a Teensy (4.1 in this case) it caused an unexpected problem...
Teensys are much faster than Arduino. Apparently this caused problems with reading inputs.
Luckily PaulStoffregen from the Teensy forum had the solultion - adding a 5 millisecond delay to the setChannel() function in MUX74HC4067.cpp
here is a link to his post if you would like to read in more detail
https://forum.pjrc.com/threads/57248-Teensy-3-6-Problem-with-Mux-(CD74HC4067)-and-Reading-Buttons?p=212832&viewfull=1#post212832
simply changing this bit of code in MUX74HC4067.cpp
void MUX74HC4067::setChannel(int8_t pin, uint8_t set)
{
digitalWrite(enable_pin, HIGH);
current_channel = pin;
for (uint8_t i = 0; i < num_of_control_pins; ++i)
{
digitalWrite(control_pin[i], pin & 0x01);
pin >>= 1;
}
enable_status = ENABLED;
if ( set == ENABLED ) digitalWrite(enable_pin, LOW);
}
to this
void MUX74HC4067::setChannel(int8_t pin, uint8_t set)
{
digitalWrite(enable_pin, HIGH);
current_channel = pin;
for (uint8_t i = 0; i < num_of_control_pins; ++i)
{
digitalWrite(control_pin[i], pin & 0x01);
pin >>= 1;
}
enable_status = ENABLED;
if ( set == ENABLED ) digitalWrite(enable_pin, LOW);
delayMicroseconds(5);

}
fixes everything.
I also simplified my code a little bit. Here is the final version of my code.
It reads input from 16 buttons on a breakout board I made (each wired with pulldown resistors)
and lights up a corresponding LED on another little breakout board I made.
/**

This example demonstrates how to read digital signals
It assumes there are push buttons with pullup resistors
connected to the 16 channels of the 74HC4067 mux/demux

For more about the interface of the library go to
https://github.com/pAIgn10/MUX74HC4067
*/

#include "MUX74HC4067.h"
// Creates a MUX74HC4067 instance
// 1st argument is the Arduino PIN to which the EN pin connects
// 2nd-5th arguments are the Arduino PINs to which the S0-S3 pins connect
MUX74HC4067 muxBUTTONS(24, 12, 11, 10, 9);
MUX74HC4067 muxLEDS(7, 6, 5, 4, 3);
void setup()
{
Serial.begin(9600);  // Initializes serial port
// Waits for serial port to connect. Needed for Leonardo only
while ( !Serial ) ;
// Configures how the SIG pin will be interfaced
// e.g. The SIG pin connects to PIN 3 on the Arduino,
//      and PIN 3 is a digital input
muxBUTTONS.signalPin(8, INPUT, DIGITAL);

muxLEDS.signalPin(2, OUTPUT, DIGITAL);
}
// Reads the 16 channels and reports on the serial monitor
// if the corresponding push button is pressed
void loop()
{
byte data;
for (byte i = 0; i < 16; ++i) //cycles through inputs 0-15 on the multiplexer board
{

	data = muxBUTTONS.read(i);		// Reads from channel i and returns HIGH or LOW

	//if the button is pressed - print out the number of the channel that has been pressed
	if ( data == HIGH ) {
	  Serial.print("Push button at channel ");
              Serial.print(i);
              Serial.println(" is pressed");
             muxLEDS.write(i,HIGH); //turn on the LED
	} else if ( data == LOW ) {
            muxLEDS.write(i,LOW); //turns off the LED when the button is released
}

}

}

Awesome news :+1:
Please give my branch another shot if you will (it's something that should be fixed regardless).
And feel free to create a pull request with your fix.


Added some recently renamed Belgian schools

If you remove thomasmore.txt and vives.txt I can merge this request.

Why do they have to be removed? vives and thomas more both have several campuses though, does it need to be separated?

@lyzidiamond: I deleted them for now

They were both already added to the database, which was causing a merge conflict.

The checks seem to fail for some reason, but I don't think it's a problem.

@lyzidiamond Reminder

@lyzidiamond, @leereilly:  these should be able to be merged now, right?

thanks @pchaigno :smile:


Cmake error for OSX

➜  build cmake ../ -G Xcode
-- The C compiler identification is AppleClang <IP_ADDRESS>20042
-- The CXX compiler identification is AppleClang <IP_ADDRESS>20042
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at contrib/civetweb/cmake/DetermineTargetArchitecture.cmake:30 (execute_process):
  execute_process attempted to output into a file: into a source directory.
Call Stack (most recent call first):
  contrib/civetweb/CMakeLists.txt:37 (determine_target_architecture)

-- Configuring incomplete, errors occurred!
See also "/Users/lin/s2client-api/CMakeFiles/CMakeOutput.log".
See also "/Users/lin/s2client-api/CMakeFiles/CMakeError.log".

You're trying to do an in source build (generating object file alongside coffee which is frowned upon for polluting the source tree.
Instead, from your root source directory, mkdir build && cd build && cmake .. -G Xcode. You can actually build to any directory other than your source directory if you'd prefer to have your build directory elsewhere. Look up out of source building for more info

Actually, after looking at the error again, sorry I just woke up, are you already building into a build folder separate from your source tree?

Was in the CMakeLists.txt folder and mkdir build && cd build && cmake ../ -G Xcode
and the same error.

So your folder structure looks like this right?
/Users/lin/s2client-api/build/
Also if there are any generated cmake files from your earlier attempts, make sure to delete those before trying again.

Interestingly enough I just did this on OSX and it works fine. :/ Though with a LOT of deprecation warnings. :)

Actually, wasn't civetweb just updated?
Maybe refresh your local submodules and try again? Also, what @KevinCalderone is saying. Your folder target should be s2client-api/build. And being there, cmake .. && cmake --build ..

Thanks,it solved by remove the folder and clone then cmake again.


[Feature Request] project-wise gerrit settings

Could you please add the feature that one can set up the gerrit url and login info per project-base?
Sometimes, we might be in several projects using different gerrit sites or login infos.
Thanks.

Duplicate of #159.


Can better display PDF with SVG way in PDF.js

Here are some advantages:

Can` adapt to the mobile end
Mobile end enlarge the font will not be blurred
Can copy text

I will share the code file with you. You can refer to it if you need to
src.zip

Add a screenshot:


Add event framework (Log Lossy Feed events)

This PR introduces an event framework for driving defined system events
through a sink interface. A logrus logging sink is implemented
initially for logging event locally but event could also be
dispatched to alternative metrics/logging mechanisms.
The initial event which is added for this is to log and
identify potential loss of data between polling intervals.
This lossy feed problem is detailed in issue #83 and whilst
this doesn't fix the problem, it can help to identify and monitor
occurrences of this issue within a long running production environment.
Lossy feed event checking and dispatch is added as a utility in the feeds package
and is implemented within the currently supported feeds which have the potential to be lossy
(crates, npm, pypi, rubygems).

As this is essentially opening up a new data type that can be put 'on the wire', (including the scope to have pubsub sinks in a similar fashion to the existing package publishers) does it make sense to have a defined expectation on what constitutes an 'event'?.
The event introduced here exercises all of the methods provided by the interface (component, type, message) when generating the logrus output, Could DispatchEvent() potentially pass a validated struct/schema constructed from the interface methods to the event handlers AddEvent() instead of the event itself?

As this is essentially opening up a new data type that can be put 'on the wire', (including the scope to have pubsub sinks in a similar fashion to the existing package publishers) does it make sense to have a defined expectation on what constitutes an 'event'?.

I think that the definition of an event can remain quite flexible, the exact reasoning behind a new event can be discussed during the implementation and review of specific event additions. As for how verbose this becomes, we can review this at a later date but the sinks can dispatch events in a filterable manner e.g. to specific type topics for a kafka sink (for example).

The event introduced here exercises all of the methods provided by the interface (component, type, message) when generating the logrus output. Could DispatchEvent() potentially pass a struct (validated with a schema for expected fields, format etc as with packages) constructed from the interface methods to the event handlers AddEvent() instead of the event itself?

Yeah I think this might need some tweaking to have an easily method of encoding data for transmission. We might want some form of standardised event payload which the individual Event implementations can populate. The current method of having the sink switch based on the event type isn't very extendable for many sinks and many events.

Extending the event framework for event serialization for future sinks is being tracked as part of issue https://github.com/ossf/package-feeds/issues/96.


[BUG] sporadic concurrent_modification_exception during query in 2.14

Describe the bug
As you can see from the screenshot, there is a ConcurrentModificationException going on.

Graylog users that started to use OpenSearch 2.14 noticed that as a problem happening for them in queries, so we started to investigate.
The resulting output from an msearch, that carries this exception looks like the following:
"failed":1,"failures":[{"shard":0,"index":"graylog_0",
"node":"jxRdA49HT4uuwWu7VVGyjw","reason":{"type":"concurrent_modification_exception","reason":null}}]}

So there is no stacktrace or logs at all.
While trying to reproduce the problem, I was lucky to have the debugger attached that caught the exception/resulted in the screenshot above.
The following line in private void updateStaleCountOnCacheInsert(CleanupKey cleanupKey) { throws the exception: https://github.com/opensearch-project/OpenSearch/blob/5b93f2e429996f6324248cb0bc5e2dd3a2150dbb/server/src/main/java/org/opensearch/indices/IndicesRequestCache.java#L571
which was introduced with https://github.com/opensearch-project/OpenSearch/pull/12707 if I'm correct - which also means that it could have/should have probably already hit in 2.13?
The error condition seems to be a bit awkward to reproduce:
A graylog instance that has a random message generator running where I had the attached script/query running reproduced the error quite consistently every 2.5/3k queries against an OpenSearch 2.14 in docker.
Reproducing it, running OpenSearch via ./gradlew run and attaching the debugger takes ca. 40-50k queries until the error shows up.
msearch3-loop.sh.txt
msearch3.req.txt
The query stays identical but fails at some point. I think there needs to be some traffic on the index so that the query is evaluated every time and not cached.
Let me know if you need more infos.
Related component
Search
To Reproduce
We're working on a setup.
Expected behavior
no concurrent modification exception should occur
Additional Details
Plugins
Please list all plugins currently enabled.
Screenshots
If applicable, add screenshots to help explain your problem.
Host/Environment (please complete the following information):

OS: [e.g. iOS]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

@kiranprakash154 Hi, may I ask you to take a look? I think, because it's a backport, the error will still occur in 3.0.0?

Hey @janheise, Thanks for reporting, let me take a look.

@janheise what were the contents of your index - "graylog_0" ?
Can you provide me that ? It will be easier for me to repro this.

@kiranprakash154 I attached two files: one that shows the index structure and some data. The data get's randomly generated. Is this what you need?
graylog0_def.json
graylog0_query.json


Kulfy: Watch thelinuxuser.com

Kulfy requests the watch of the watch_keyword thelinuxuser\.com. See the MS search here and the Stack Exchange search here.

thelinuxuser\.com has been seen in 0 true positives, 0 false positives, and 0 NAAs.


Added garimasingh128's gitsetgo project

Adding back garimasingh128's GitSetGo project after a bot forced-push to their branch and deleted their code (see #45).

Merging this project!


Using typed slotables causes static bits to be sent down for every event

Thanks as always for everything you're doing with Surface! ❤ I'm hoping to get some direction and answers about some behavior I'm seeing.
Context
Our company has a page that showcases a plethora of generic components (tabs, pagination, cards, etc) and I noticed that I would fire an event (like submitting a form) and Phoenix would send back a 250kb payload seeming to contain (almost) the entirety of the page.
Experiment
I started cutting code until I had a minimal example: https://github.com/paulstatezny/surface-repro
(It's a standalone Phoenix app that doesn't require a DB, so feel free to clone and run it.)
If you run the app and go to http://localhost:4000, you'll see this:

The navigation tabs at the top are dynamic; you can click on them and it changes which one is highlighted.
Note the LiveView and Surface component here:
https://github.com/paulstatezny/surface-repro/blob/master/lib/surface_repro_web/live/surface_live.ex
https://github.com/paulstatezny/surface-repro/blob/master/lib/surface_repro_web/live/tabs.ex
There are links to pages with a "vanilla" LiveView version (no Surface) and another Surface version that doesn't use typed slotables.
Observed Behavior
Turns out, if you generate code with typed slotables then every time an event happens Phoenix regenerates all of the static bits and sends them over the wire. (See the "s" key below.)
 {
    "0":" phx-click=\"tab_changed\"",
    "1":" phx-value-key=\"team\"",
    "2":" class=\"ml-8 first:ml-0 py-4 px-1 border-b-2 text-red-600 border-red-500 bg-red-100\"",
    "3":"My Team",
    "s":[
       "<button",
       " type=\"button\"",
       "",
       ">\n  ",
       "\n</button>\n"
    ]
 }

This can result in payloads that are much larger.
From the "vanilla" LiveView, containing only dynamic bits:

From the Surface example:

Not a big deal at "example scale", but our "real world" example sent 250kb payloads for every event. Not ideal.
You can view websocket payloads from each example here: https://github.com/paulstatezny/surface-repro/issues/1
Conclusion
Are typed slotables intended to act this way? It seems if this is accepted behavior they should be avoided.

Hey @paulstatezny!
Thank you so much for the detailed report and for isolating the problem on a separate project. I'll clone it and try to track the root of the problem.

@paulstatezny after a few tests I was able to simulate the problem using vanilla LiveView. Is seems the problem is related to the live_component function itself, which is used under the hood by Surface. If you change your vanilla example to:
defmodule SurfaceReproWeb.Tab do
  use Phoenix.LiveComponent

  def render(assigns) do
    ~L"""
    <button type="button" phx-click="<%= @click %>" phx-value-key="<%= @key %>" class="<%= class(@selected == @key) %>">
      <%= @label %>
    </button>
    """
  end

  @base_classes "ml-8 first:ml-0 py-4 px-1 border-b-2 "

  defp class(true = _selected), do: @base_classes <> "text-red-600 border-red-500 bg-red-100"
  defp class(false = _selected), do: @base_classes <> "text-gray-500 border-transparent hover:border-gray-300"
end

defmodule SurfaceReproWeb.TabsVanilla do
  use Phoenix.LiveComponent

  def render(assigns) do
    ~L"""

        <%= for {key, label} <- @tabs do %>
          <%= live_component(@socket, SurfaceReproWeb.Tab, click: @click, key: key, label: label, selected: @selected) %>
        <% end %>

    """
  end
end

you'll see that it sends ["<button type="button" phx-click="", "" phx-value-key="", "" class="", "">↵ ",…] the same way.
Please, let me know you can confirm that. If so, we'll need to report to the Phoenix LIveView team to make sure this is the expected behaviour or if it's a bug.

BTW, if you convert the component into a live component (by adding an id to it) like:
<%= live_component(@socket, SurfaceReproWeb.Tab, id: key, click: @click, key: key, label: label, selected: @selected) %>

the response size gets much smaller: 532bytes.
More interesting is that if you do the same thing in Surface, like:
  defmodule InternalTab do
    use Surface.LiveComponent # LiveComponent will require an id
   ...
  end

and
<InternalTab
  id={{ tab.key }}
  :for={{ tab <- @tabs }}
  click={{ @click }}
  key={{ tab.key }}
  label={{ tab.label }}
  selected={{ @selected == tab.key }}
/>

The response get even smaller: 345bytes.

Ok. I just confirmed that this is the expected behaviour when using live_component. If it's stateless (no id), it always sends the static parts.

@paulstatezny I'm closing this as it's the expected behaviour for live_component.
BTW, were you able to find a workaround? Is converting some of the components into stateful components a feasible solution for your case?

@msaraiva It turns out:

Converting components to Surace.LiveComponents and then providing ids does make the websocket payloads more lightweight.
But then you're forced to sprinkle ids all over the place.
Most importantly: Our use case explicitly violates the recommendations of the LiveView docs.

"You should also avoid using stateful components to provide abstract DOM components." - the docs

The docs recommend using functions, not LiveComponents to do this.

This leaves us a bit stuck between a rock and a hard place. How do we do with Surface in a way that's friendly to LiveView?

Should Surface be considering using functions under the hood instead of LiveComponents in certain cases?

@paulstatezny I'd certainly consider but first we need to confirm that assumption. Have you tried using functions instead of live_component in your vanilla LV? I'm not sure it will make any difference regarding the payload. I believe a function may be considered as stateless, consequently the static bits might be sent too. I hope it works. This way we have a fairly easy solution to this problem.

@paulstatezny do you have any updates on this? I'm curious if converting the components you have to functions would improve anything. If you want to create a separate private project (in case you can't make it public) containing only that big LV you have, I'd be glad to take a look and run some experiments to see what we can do about it.
Cheers.

@msaraiva Sorry for the radio silence!
Regarding using functions: I modified the Vanilla LiveView example to use functions in place of live components. Here are the results. As you can see, static content is pushed down the wire on each event.
As the data in that issue suggests, using a prop instead of typed slotables to pass in lists of maps is a painless way around the problem.

On a separate note, we did some experimentation with converting our Surface.Components into Surface.LiveComponents to make the websocket payloads smaller. The payloads did shrink, but at the cost of bloating the memory footprint on the server. It seems like abusing stateful components is not a scalable solution, unless either (1) you won't have a large amount of concurrent users or (2) money isn't an object and you can rent servers with a lot of RAM. 😄 (RAM needs would be directly connected to your application design, of course.)

Thanks for the offer to look at our code!
If necessary, we can look down that road. But I think the facts are pretty clear. With LiveView, any markup that isn't 100% static HTML gets sent over the wire any time an event happens. Even if it hasn't changed.
This means that by the nature of LiveView, any page that is designed to hold a lot of content, with frequent Phoenix events (handle_events) will simply cause lots of redundant data to be sent over the wire frequently.
Our team finds that unoptimal. (It'd be great if LiveView can detect that some section of markup hasn't changed, so don't send that section over the wire!) Nevertheless, we want to experiment with building out some real apps and getting them in production. That'll reveal if this is even a problem in practice. After all, if the payload is only 35kb or something, is it really that big of a deal?

Oh! And here are the LiveView and associated functions for reference:
https://github.com/paulstatezny/surface-repro/blob/master/lib/surface_repro_web/live/vanilla_functions_live.ex
https://github.com/paulstatezny/surface-repro/blob/master/lib/surface_repro_web/live/tabs_vanilla_functions.ex


seqpage/pageselectpage TI led

Requires https://github.com/yatli/mdhack/pull/20
Demonstrates two TI trigled modes: normal and rec.
PageSelectPage uses the normal mode to show the current selected page. Playing notes will be displayed on the TI.
SeqPage uses the rec mode to show MCL mask data plus the current playing cursor.

Just testing this out now.
The latency is much improved. still a few ms delay on the MD side. But good enough for now.
There is a bug, if you enable REC on the MD. you will input step sequencer data on the MD sequencer, without seeing it visually.

Can we re-name REC mode to something else. STEPINPUT perhaps ?

In "REC" mode we need to show the current selected trigs, in addition to the trig mask.

Trig Latency appears to affect the MD's standard step edit mode.

9725f5d
Step input should feel more responsive now. Step will be set if empty, even if you hold trig.

We should disable MD step edit mode if in MCL step edit mode.

There is a bug, if you enable REC on the MD. you will input step sequencer data on the MD sequencer, without seeing it visually.

This is because currently our TI hack only handles the non rec mode path.
We can setup a MCL presence flag in the FW, and disable the MD step edit accordingly.
Then we can use the MD rec button to enter the MCL step edit mode?

Then we can use the MD rec button to enter the MCL step edit mode?

I thought about this. but it might not be desirable. For instance I ergularly find myself in the MD step edit mode with the MC attached.
--
Just noticed that MUTE step leds are now broken too when in MCL step edit. Same issue as above.

Makes sense. I'll think about the precedence and override rules.

@jmamma
  // Do not show stepedit trigled if:
  // - trigger interface is not activated
  // - MD rec mode is activated
  // - MD bank selection is activated
  // - MD seq edit (mute, slide etc.) is activated
  if (BankButtonPressIndexForPopup >= 0  ||
      md_menu_cmd.md_menu_cmd5 != RecordDeactivated ||
      md_menu_cmd.md_menu_cmd4 != 0 ||
      !trigger_interface_en){
    return LEDS_dynamic[i] ^ LEDS_static[i];
  }

@jmamma
  // Do not show stepedit trigled if:
  // - trigger interface is not activated
  // - MD rec mode is activated
  // - MD bank selection is activated
  // - MD seq edit (mute, slide etc.) is activated
  if (BankButtonPressIndexForPopup >= 0  ||
      md_menu_cmd.md_menu_cmd5 != RecordDeactivated ||
      md_menu_cmd.md_menu_cmd4 != 0 ||
      !trigger_interface_en){
    return LEDS_dynamic[i] ^ LEDS_static[i];
  }

does this work?

https://github.com/yatli/mdhack/pull/20/commits/727de6923811a3930e10034fdef04b293336e6a7
Try the latest one.
When MD rec mode is active, the LEDs display the internal sequencer state (same for mute/accent etc.)

It even works with bank selection. When the popup times out, the stepedit TI comes back online :D

Only issue, MD does not know the MC step cursor position. I'm currently using the internal sequencer step cursor.
Can we sync the SCALE SETUP over from MC?

Tried more patterns with the PageSelectPage TI led index indicator -- maybe we should go exclusive instead of overlay

Overlay leds for chain/write indicator would be fun. I can then see which tracks are playing notes and chain those.

Only issue, MD does not know the MC step cursor position. I'm currently using the internal sequencer step cursor.
Can we sync the SCALE SETUP over from MC?

Yeah that would be awesome. I found myself trying to change the current "page" of the sequence using the scale button on the MD. Only to remember i had to do in the MC.

this is really good now.

We need another mode. to hide the sequencer events.

see https://github.com/jmamma/MIDICtrl20_MegaCommand/pull/123/commits/3e3f9426533e0481c9e23cdb7f73a33751130ac4

PageSelectPage not sending the first leds update

see 3e3f942

need the patch on the MD side.

Forgot to commit...
https://github.com/yatli/mdhack/pull/20/commits/6bb64b040476a41c2b4de934630dc780b9c7d587

Forgot to commit...
yatli/mdhack@6bb64b0

yep that's perfect.
--
Now just the issue of the step indicator.
This will be broken for track speeds and different track lengths.

merging this one for cleaner code review on https://github.com/jmamma/MIDICtrl20_MegaCommand/pull/124


Fix typing bug of group(By(...), By(traversal))

Although the group method is defined so that the type of g.V().group(By.label,  By(__[Vertex]().count()).head().get("label") becomes JCollection[Long], the type at runtime is actually Long.

Thank you! I'll look into this today.


Pin neovim version

Currently we're using neovim-unwrapped from nixos-unstable, which may change inbetween nixpkgs input bumps, or for those overriding the nixpkgs input.
I propose that we get the neovim-unwrapped package from the neovim repository directly, using the flake they provide in the contrib directory, allowing us to pin the branch directly as follows:
# ...

inputs.neovim-unwrapped.url = "github:neovim/neovim/v0.9.5?dir=contrib";

# ...

and also allows users to do so at their own peril.
Overriding the package has been made easier already through the help of the customizable package option that I've added recently, but I do like the idea of making the input customizable also.
CC @FrothyMarrow and @horriblename for feedback.

seems like a good change, no objections.

Same here, sounds like a good idea.


create ssh keys at startup for Esxi

Fix ODR-259
create ssh keys for Esxi at startup since it can't be persistent.
@RackHD/corecommitters @panpan0000 @iceiilin

:+1:

BUILD on-http #2812 : ABORTED

** BUILD build-config-setup  #150817: SUCCESS
** BUILD unit-tests  #10022: SUCCESS
** BUILD smoke-test  #3748: ABORTED

test this please.


Add tee(1) to new_binary_tools

It would be great to have tee(1) to be guaranteed to be available, so the mail() related PHPTs could finally be unified for Linux and Windows. The current situation where one has to employ ext/imap to test mail() on Windows is very unfortunate.

Thanks for checking, Christoph. Itself, the tee utility would work as expected. But, the redirection like >/dev/null wouldn't when run through cmd.exe. Taking the fact, sendmail_path is a system option, ini_set() wouldn't work as well, so it couldn't be done conditionally as >nul within the test body. So we'd still need to duplicate the test, or find another way to trick it. Also, still the SMTP part wouldn't be tested, even if we'd get it to work. I've added tee.exe anyway, probably need to think a bit more about how to make it useful for the tests.
Thanks.

Oh, I've totally forgotten the /dev/null vs. NUL issue. Maybe we could use cat - > file/name instead of tee? Trying that for ext/standard/tests/mail/mail_basic.phpt works on Linux and Windows. That would require cat(1), though.
And yes, it's probably best to have actual SMTP tests on Windows, but nonetheless it would be great to have all Unix mail() tests also running on Windows (AFAIR, several tests are Unix only currently).
Anyhow, thanks for adding tee(1) so quickly. :-)

Well, thanks you for checking the new SDK! Still fixing some small bugs and preparing for the build hosts, otherwise it might be already ok for master at least.
I thought more about touching the run-tests.php. Maybe introducing some template var, like PHP_TEST_NULL_DEVICE and/or some others alike, so it would be auto replaced on the corresponding platform. But just need an idea, how to design that. It doesn't look to be worth it to fork the whole test in this case.
The tee  command itself, however, can be useful independent from that. Cat should work as well, can be added, if we need it. What I'd basically see with the tools - only adding those that are obviously needed or usefil, avoiding conflicting commands as everything is directly on the path and still keeping the SDK package small.
Thanks.


Charm restarts snap.microceph.rgw service for every config key, triggering systemd start-limit-hit event

The consequence of this behavior is that the deployment needs manual help to complete in the form of manually issuing:
sudo systemctl stop snap.microceph.rgw.service
sudo systemctl start snap.microceph.rgw.service

on each throttle event until configuration is done.

Is restarting necessary at all?
If it is, could it be aggregated into a final restart after all config keys have been set?

Note that due to the fact that Juju seraializes events on each machine, this behavior also holds up the entire sunbeam deployment.

Jul 02 09:59:15 sunbeam-1 microceph.rgw[23673]: 2024-07-02T09:59:15.412+0000 7f8d35e9c640 -1 received  signal: Terminated from /sbin/init  (PID: 1) UID: 0
Jul 02 09:59:15 sunbeam-1 microceph.rgw[23673]: 2024-07-02T09:59:15.412+0000 7f8d396ba0c0 -1 shutting down
Jul 02 09:59:15 sunbeam-1 systemd[1]: snap.microceph.rgw.service: Deactivated successfully.
Jul 02 09:59:15 sunbeam-1 systemd[1]: Stopped Service for snap application microceph.rgw.
Jul 02 09:59:15 sunbeam-1 systemd[1]: snap.microceph.rgw.service: Consumed 2.457s CPU time.
Jul 02 09:59:15 sunbeam-1 systemd[1]: Started Service for snap application microceph.rgw.
Jul 02 09:59:16 sunbeam-1 radosgw[401339]: looking for plugins in '/usr/lib/x86_64-linux-gnu/sasl2', failed to open directory, error: No such file or directory
Jul 02 09:59:16 sunbeam-1 systemd[1]: Stopping Service for snap application microceph.rgw...
Jul 02 09:59:16 sunbeam-1 microceph.rgw[401339]: 2024-07-02T09:59:16.312+0000 7f12325fe640 -1 received  signal: Terminated from /sbin/init  (PID: 1) UID: 0
Jul 02 09:59:16 sunbeam-1 microceph.rgw[401339]: 2024-07-02T09:59:16.312+0000 7f1235e1c0c0 -1 shutting down
Jul 02 09:59:16 sunbeam-1 systemd[1]: snap.microceph.rgw.service: Deactivated successfully.
Jul 02 09:59:16 sunbeam-1 systemd[1]: Stopped Service for snap application microceph.rgw.
Jul 02 09:59:16 sunbeam-1 systemd[1]: Started Service for snap application microceph.rgw.
Jul 02 09:59:17 sunbeam-1 radosgw[402224]: looking for plugins in '/usr/lib/x86_64-linux-gnu/sasl2', failed to open directory, error: No such file or directory
Jul 02 09:59:17 sunbeam-1 microceph.rgw[402224]: 2024-07-02T09:59:17.488+0000 7f82029a9640 -1 received  signal: Terminated from /sbin/init  (PID: 1) UID: 0
Jul 02 09:59:17 sunbeam-1 microceph.rgw[402224]: 2024-07-02T09:59:17.488+0000 7f82061c70c0 -1 shutting down
Jul 02 09:59:17 sunbeam-1 systemd[1]: Stopping Service for snap application microceph.rgw...
Jul 02 09:59:17 sunbeam-1 systemd[1]: snap.microceph.rgw.service: Deactivated successfully.
Jul 02 09:59:17 sunbeam-1 systemd[1]: Stopped Service for snap application microceph.rgw.
Jul 02 09:59:17 sunbeam-1 systemd[1]: Started Service for snap application microceph.rgw.
Jul 02 09:59:18 sunbeam-1 radosgw[403156]: looking for plugins in '/usr/lib/x86_64-linux-gnu/sasl2', failed to open directory, error: No such file or directory
Jul 02 09:59:18 sunbeam-1 microceph.rgw[403156]: 2024-07-02T09:59:18.436+0000 7f4caadf2640 -1 received  signal: Terminated from /sbin/init  (PID: 1) UID: 0
Jul 02 09:59:18 sunbeam-1 microceph.rgw[403156]: 2024-07-02T09:59:18.436+0000 7f4cae6100c0 -1 shutting down
Jul 02 09:59:18 sunbeam-1 systemd[1]: Stopping Service for snap application microceph.rgw...
Jul 02 09:59:18 sunbeam-1 systemd[1]: snap.microceph.rgw.service: Deactivated successfully.
Jul 02 09:59:18 sunbeam-1 systemd[1]: Stopped Service for snap application microceph.rgw.
Jul 02 09:59:18 sunbeam-1 systemd[1]: Started Service for snap application microceph.rgw.
Jul 02 09:59:19 sunbeam-1 radosgw[404075]: looking for plugins in '/usr/lib/x86_64-linux-gnu/sasl2', failed to open directory, error: No such file or directory
Jul 02 09:59:19 sunbeam-1 microceph.rgw[404075]: 2024-07-02T09:59:19.496+0000 7fca8608a640 -1 received  signal: Terminated from /sbin/init  (PID: 1) UID: 0
Jul 02 09:59:19 sunbeam-1 microceph.rgw[404075]: 2024-07-02T09:59:19.496+0000 7fca898a80c0 -1 shutting down
Jul 02 09:59:19 sunbeam-1 systemd[1]: Stopping Service for snap application microceph.rgw...
Jul 02 09:59:19 sunbeam-1 systemd[1]: snap.microceph.rgw.service: Deactivated successfully.
Jul 02 09:59:19 sunbeam-1 systemd[1]: Stopped Service for snap application microceph.rgw.
Jul 02 09:59:19 sunbeam-1 systemd[1]: Started Service for snap application microceph.rgw.
Jul 02 09:59:20 sunbeam-1 radosgw[404929]: looking for plugins in '/usr/lib/x86_64-linux-gnu/sasl2', failed to open directory, error: No such file or directory
Jul 02 09:59:20 sunbeam-1 systemd[1]: Stopping Service for snap application microceph.rgw...
Jul 02 09:59:20 sunbeam-1 microceph.rgw[404929]: 2024-07-02T09:59:20.420+0000 7ff0c1ea6640 -1 received  signal: Terminated from /sbin/init  (PID: 1) UID: 0
Jul 02 09:59:20 sunbeam-1 microceph.rgw[404929]: 2024-07-02T09:59:20.420+0000 7ff0c56c40c0 -1 shutting down
Jul 02 09:59:20 sunbeam-1 systemd[1]: snap.microceph.rgw.service: Deactivated successfully.
Jul 02 09:59:20 sunbeam-1 systemd[1]: Stopped Service for snap application microceph.rgw.
Jul 02 09:59:20 sunbeam-1 systemd[1]: snap.microceph.rgw.service: Start request repeated too quickly.
Jul 02 09:59:20 sunbeam-1 systemd[1]: snap.microceph.rgw.service: Failed with result 'start-limit-hit'.
Jul 02 09:59:20 sunbeam-1 systemd[1]: Failed to start Service for snap application microceph.rgw.
Jul 02 10:00:16 sunbeam-1 systemd[1]: Started Service for snap application microceph.rgw.
Jul 02 10:00:16 sunbeam-1 radosgw[420540]: looking for plugins in '/usr/lib/x86_64-linux-gnu/sasl2', failed to open directory, error: No such file or directory
Jul 02 10:00:21 sunbeam-1 systemd[1]: Stopping Service for snap application microceph.rgw...
Jul 02 10:00:21 sunbeam-1 microceph.rgw[420540]: 2024-07-02T10:00:21.451+0000 7f0acdbbf640 -1 received  signal: Terminated from /sbin/init  (PID: 1) UID: 0
Jul 02 10:00:21 sunbeam-1 microceph.rgw[420540]: 2024-07-02T10:00:21.451+0000 7f0ad13dd0c0 -1 shutting down
Jul 02 10:00:21 sunbeam-1 systemd[1]: snap.microceph.rgw.service: Deactivated successfully.
Jul 02 10:00:21 sunbeam-1 systemd[1]: Stopped Service for snap application microceph.rgw.
Jul 02 10:00:21 sunbeam-1 systemd[1]: Started Service for snap application microceph.rgw.
Jul 02 10:00:21 sunbeam-1 radosgw[422342]: looking for plugins in '/usr/lib/x86_64-linux-gnu/sasl2', failed to open directory, error: No such file or directory
Jul 02 10:00:22 sunbeam-1 microceph.rgw[422342]: 2024-07-02T10:00:22.167+0000 7fcc4f271640 -1 received  signal: Terminated from /sbin/init  (PID: 1) UID: 0
Jul 02 10:00:22 sunbeam-1 microceph.rgw[422342]: 2024-07-02T10:00:22.167+0000 7fcc52a8f0c0 -1 shutting down
Jul 02 10:00:22 sunbeam-1 systemd[1]: Stopping Service for snap application microceph.rgw...
Jul 02 10:00:22 sunbeam-1 systemd[1]: snap.microceph.rgw.service: Deactivated successfully.
Jul 02 10:00:22 sunbeam-1 systemd[1]: Stopped Service for snap application microceph.rgw.
Jul 02 10:00:22 sunbeam-1 systemd[1]: Started Service for snap application microceph.rgw.
Jul 02 10:00:22 sunbeam-1 radosgw[423309]: looking for plugins in '/usr/lib/x86_64-linux-gnu/sasl2', failed to open directory, error: No such file or directory
Jul 02 10:00:23 sunbeam-1 microceph.rgw[423309]: 2024-07-02T10:00:23.147+0000 7fa7e4068640 -1 received  signal: Terminated from /sbin/init  (PID: 1) UID: 0
Jul 02 10:00:23 sunbeam-1 systemd[1]: Stopping Service for snap application microceph.rgw...
Jul 02 10:00:23 sunbeam-1 microceph.rgw[423309]: 2024-07-02T10:00:23.147+0000 7fa7e78860c0 -1 shutting down
Jul 02 10:00:23 sunbeam-1 systemd[1]: snap.microceph.rgw.service: Deactivated successfully.
Jul 02 10:00:23 sunbeam-1 systemd[1]: Stopped Service for snap application microceph.rgw.
Jul 02 10:00:23 sunbeam-1 systemd[1]: Started Service for snap application microceph.rgw.
Jul 02 10:00:23 sunbeam-1 radosgw[424181]: looking for plugins in '/usr/lib/x86_64-linux-gnu/sasl2', failed to open directory, error: No such file or directory
Jul 02 10:00:24 sunbeam-1 systemd[1]: Stopping Service for snap application microceph.rgw...
Jul 02 10:00:24 sunbeam-1 microceph.rgw[424181]: 2024-07-02T10:00:24.151+0000 7f60e001f640 -1 received  signal: Terminated from /sbin/init  (PID: 1) UID: 0
Jul 02 10:00:24 sunbeam-1 microceph.rgw[424181]: 2024-07-02T10:00:24.151+0000 7f60e383d0c0 -1 shutting down
Jul 02 10:00:24 sunbeam-1 systemd[1]: snap.microceph.rgw.service: Deactivated successfully.
Jul 02 10:00:24 sunbeam-1 systemd[1]: Stopped Service for snap application microceph.rgw.
Jul 02 10:00:24 sunbeam-1 systemd[1]: Started Service for snap application microceph.rgw.
Jul 02 10:00:24 sunbeam-1 radosgw[425010]: looking for plugins in '/usr/lib/x86_64-linux-gnu/sasl2', failed to open directory, error: No such file or directory
Jul 02 10:00:25 sunbeam-1 microceph.rgw[425010]: 2024-07-02T10:00:25.051+0000 7f57960be640 -1 received  signal: Terminated from /sbin/init  (PID: 1) UID: 0
Jul 02 10:00:25 sunbeam-1 microceph.rgw[425010]: 2024-07-02T10:00:25.051+0000 7f57998dc0c0 -1 shutting down
Jul 02 10:00:25 sunbeam-1 systemd[1]: Stopping Service for snap application microceph.rgw...
Jul 02 10:00:25 sunbeam-1 systemd[1]: snap.microceph.rgw.service: Deactivated successfully.
Jul 02 10:00:25 sunbeam-1 systemd[1]: Stopped Service for snap application microceph.rgw.
Jul 02 10:00:25 sunbeam-1 systemd[1]: snap.microceph.rgw.service: Start request repeated too quickly.
Jul 02 10:00:25 sunbeam-1 systemd[1]: snap.microceph.rgw.service: Failed with result 'start-limit-hit'.
Jul 02 10:00:25 sunbeam-1 systemd[1]: Failed to start Service for snap application microceph.rgw.
Jul 02 10:00:28 sunbeam-1 systemd[1]: Started Service for snap application microceph.rgw.
Jul 02 10:00:29 sunbeam-1 radosgw[426724]: looking for plugins in '/usr/lib/x86_64-linux-gnu/sasl2', failed to open directory, error: No such file or directory
Jul 02 10:00:36 sunbeam-1 systemd[1]: Stopping Service for snap application microceph.rgw...
Jul 02 10:00:36 sunbeam-1 microceph.rgw[426724]: 2024-07-02T10:00:36.087+0000 7fe8924c6640 -1 received  signal: Terminated from /sbin/init  (PID: 1) UID: 0
Jul 02 10:00:36 sunbeam-1 microceph.rgw[426724]: 2024-07-02T10:00:36.087+0000 7fe895ce40c0 -1 shutting down
Jul 02 10:00:36 sunbeam-1 systemd[1]: snap.microceph.rgw.service: Deactivated successfully.
Jul 02 10:00:36 sunbeam-1 systemd[1]: Stopped Service for snap application microceph.rgw.
Jul 02 10:00:36 sunbeam-1 systemd[1]: Started Service for snap application microceph.rgw.
Jul 02 10:00:36 sunbeam-1 radosgw[428911]: looking for plugins in '/usr/lib/x86_64-linux-gnu/sasl2', failed to open directory, error: No such file or directory
Jul 02 10:00:36 sunbeam-1 microceph.rgw[428911]: 2024-07-02T10:00:36.875+0000 7f0631eb6640 -1 received  signal: Terminated from /sbin/init  (PID: 1) UID: 0
Jul 02 10:00:36 sunbeam-1 microceph.rgw[428911]: 2024-07-02T10:00:36.875+0000 7f06356d40c0 -1 shutting down
Jul 02 10:00:36 sunbeam-1 systemd[1]: Stopping Service for snap application microceph.rgw...
Jul 02 10:00:37 sunbeam-1 systemd[1]: snap.microceph.rgw.service: Deactivated successfully.
Jul 02 10:00:37 sunbeam-1 systemd[1]: Stopped Service for snap application microceph.rgw.
Jul 02 10:00:37 sunbeam-1 systemd[1]: Started Service for snap application microceph.rgw.
Jul 02 10:00:37 sunbeam-1 radosgw[429868]: looking for plugins in '/usr/lib/x86_64-linux-gnu/sasl2', failed to open directory, error: No such file or directory
Jul 02 10:00:37 sunbeam-1 systemd[1]: Stopping Service for snap application microceph.rgw...
Jul 02 10:00:37 sunbeam-1 microceph.rgw[429868]: 2024-07-02T10:00:37.907+0000 7f490778b640 -1 received  signal: Terminated from /sbin/init  (PID: 1) UID: 0
Jul 02 10:00:37 sunbeam-1 microceph.rgw[429868]: 2024-07-02T10:00:37.907+0000 7f490afa90c0 -1 shutting down
Jul 02 10:00:38 sunbeam-1 systemd[1]: snap.microceph.rgw.service: Deactivated successfully.
Jul 02 10:00:38 sunbeam-1 systemd[1]: Stopped Service for snap application microceph.rgw.
Jul 02 10:00:38 sunbeam-1 systemd[1]: Started Service for snap application microceph.rgw.
Jul 02 10:00:38 sunbeam-1 radosgw[430732]: looking for plugins in '/usr/lib/x86_64-linux-gnu/sasl2', failed to open directory, error: No such file or directory
Jul 02 10:00:38 sunbeam-1 systemd[1]: Stopping Service for snap application microceph.rgw...
Jul 02 10:00:38 sunbeam-1 microceph.rgw[430732]: 2024-07-02T10:00:38.919+0000 7fb9469f5640 -1 received  signal: Terminated from /sbin/init  (PID: 1) UID: 0
Jul 02 10:00:38 sunbeam-1 microceph.rgw[430732]: 2024-07-02T10:00:38.919+0000 7fb94a2130c0 -1 shutting down
Jul 02 10:00:39 sunbeam-1 systemd[1]: snap.microceph.rgw.service: Deactivated successfully.
Jul 02 10:00:39 sunbeam-1 systemd[1]: Stopped Service for snap application microceph.rgw.
Jul 02 10:00:39 sunbeam-1 systemd[1]: Started Service for snap application microceph.rgw.
Jul 02 10:00:39 sunbeam-1 radosgw[431614]: looking for plugins in '/usr/lib/x86_64-linux-gnu/sasl2', failed to open directory, error: No such file or directory

@hemanthnakkina the default snap version used is reef/stable right ? Trying to understand why the 2s life check is not working.

Thanks for reporting this @fnordahl, will look into it.

@fnordahl Are you using openstack channel 2024.1/edge?
@UtkarshBhatthere In general,
openstack channel 2024.1/edge --> charm-microceph/microceph channel reef/edge
openstack channel 2024.1/beta --> charm-microceph/microceph channel reef/beta
Users can always change versions using manfiest file option in sunbeam deployment


Spec 1.13.x 20170627

I think this gets us to where the last pull request (20170627) was.  Some of the things that were added shortly after this seem to be related to 1.14.x (e.g. static imports) so I want to get this squared away, and picked over to spec-1.1.14, before I try to deal with the rest.
Please take a good look at the commit from Ivan Dubrov ("Adding support for an explicit timezone") which I kept separate. Near as I can tell this is the only change that touches something outside gosu-test. I have no idea whether it was meant as a contribution that should have gone into core but got lost...or whether it was something that was supposed to stay local to our branch(es).

Thanks @roofpig95008 . The tests pass so we will merge anyway once I check with @rsmckinney about Ivan's change.
I just pushed a new commit 297642f8a6e8bd0047f44aedc03fe32cffbb138b to gosu-lang:spec-1.13.x to fix the error on our CI system. Sorry to ask you to be the guinea pig but do you mind rebasing this PR on that? It should be a piece of cake.


Change all instances of /var/tmp usage to /var/mmfs/tmp instead.

Using /var/tmp is a potential security risk, as it's world writable, and there
can be race conditions when creating files there.
Signed-off-by: Jan-Frode Myklebust<EMAIL_ADDRESS>

@janfrode Thanks for opening this PR. will take a look . thanks


Swagger JAX-RS endpoint returning empty class leads to odd spec generation

I have an endpoint that returns an empty class, say EmptyDTO. The reason why it's empty is because I had just added the endpoint and I wanted to quickly generate the spec and then codegen the java client to use in other parts of the projects making sure the API looked as it was supposed to.
My EmptyDTO obviously looks like this:
public class EmptyDTO {}

and the endpoint returning EmptyDTO led to the following spec being generated:
{
    "path": "/newEndpoint/{id}",
    "operations": [
        {
            "method": "GET",
            "summary": "",
            "notes": "",
            "type": "com.mypackage.dto.EmptyDTO",
            "nickname": "someMethod",
            "produces": ["application/json"],
            "authorizations": {},
            "parameters": [
                {
                    "name": "id",
                    "required": true,
                    "type": "string",
                    "paramType": "path"
                }
            ]
        }
    ]
}

No model gets generated and return type is set to the fully qualified class name. The codegen then complains:
Mar 18, 2014 5:47:21 PM com.wordnik.swagger.codegen.spec.SwaggerSpecValidator validate
WARNING: no models found for listing  www.mywebsite.com
missing models: Set(com.mypackage.dto.EmptyDTO)

And the generated method returns the undefined com.mypackage.dto.EmptyDTO.
I believe this is a bug.

Will test for this case for m2

this has been fixed in 1.5.x.  The model, when empty however, should be more like this:
{
  "type": "object"
}


Add typeChar as well

Just another column type and associated tests

Please do me a favor and add this to the CHANGELOG under v6.2.0. Thanks.

done


Added support for reading multiple OAML definition files

These changes allow applications making using of the OAML to load multiple OAML definition files.

Thanks! :)


kotlin - core code

why dont change core code to kotlin?

Firstly, this isn't an issue.
Secondly, this has bren answered countless times.
It's a lot of work that no one wants to do for little payoff.
It's already hard enough to maintain LibGDX, a whole rewrite is completely out of the question AFAIK.
If you want more descriptive or better answers Google, look in the forums, or closed issues about the same topic.
Requesting this to be closed.

I want to add that it also has some enormous drawbacks to use Kotlin.

@MrStahlfelge which one except of the Web part which is not usable with kotlin?

Another drawback is that it enlarges the APK size on Android. And another one that it makes the framework harder to use for Java developers.

But it has many benefits:
Kotlin Multiplatform for example, why ? you'll now be able to target:

Java Desktop
Java Android
JS Web
Native Desktop
Native iOS
Native Android
Native Web Assembly

We could even have a good working iOS-Backend and many things like the target code is provided by jetbrains so we could be more focused about LibGDX itself

Rewriting the entire framework in another language is a huge undertaking which is unlikely to happen. If it is important enough to someone, they are free to start porting it themselves.

LWJGL is NOT written in Kotlin.
It uses Kotlin to generate the glue code for interfacing with OpenGL, OpenCL etc but everything that is distributed is written in Java.

Kotlin is great and if someone starts porting, please, call me ;) LibGDX 2.0?
For now, this looks extremely convenient: #5599.

I'm ready to start port to kotlin when kotlin native is more stable

I did it already in D, C# and C++


Can't install node, relating to ./configure

Hi,
I'm getting an error when attempting to install nodejs. From the build process node downloads fine but then throws an error when it gets to the ./configure stage.
brew install node
==> Downloading https://nodejs.org/dist/v4.1.1/node-v4.1.1.tar.gz
Already downloaded: /home/wdev/.cache/Homebrew/node-4.1.1.tar.gz
==> Downloading https://ssl.icu-project.org/files/icu4c/55.1/icu4c-55_1-src.tgz
Already downloaded: /home/wdev/.cache/Homebrew/node--icu4c-55.1.tgz
==> ./configure --prefix=/home/wdev/.linuxbrew/Cellar/node/4.1.1 --without-npm --with-intl=small-icu
Last 15 lines from /home/wdev/.cache/Homebrew/Logs/node/01.configure:
Tue Oct 06 19:53:41 +0000 2015
./configure
--prefix=/home/wdev/.linuxbrew/Cellar/node/4.1.1
--without-npm
--with-intl=small-icu
Any help would be great, thanks

Any ideas why this might be happening?

Can you post the full brew gist-logs node, please? Thanks!

The formula should now complain if you try to build with an incompatible compiler, which was very likely the problem here.


Trying to make a new Image in the editor outputs an error

Godot version:

3.2.4.rc2
OS/device including version:

Windows 10
Issue description:

I got an error in the output but I expected a new Image to be created. If I'm not supposed to be able to create a new Image this way then I probably shouldn't be allowed to. The error was: drivers/gles3/rasterizer_storage_gles3.cpp:1105 - Condition "texture->data_size == 0 && !texture->render_target" is true. Returned: Ref<Image>()
Steps to reproduce:

Make TextureRect
Add new ImageTexture as texture
Attempt to add new Image as image

Minimal reproduction project:

Just seconding this is happening on v3.2.3.stable.mono.official.