Multiple api calls on column filter change in manual mode while using UseEffect hook

material-react-table version
v2.13.0
react & react-dom versions
v18.3.1
Describe the bug and the steps to reproduce it
Does anybody knows a solution or faced a issue of api getting called multiple times while column filter is changed. This is causing Table fetching state to render twice and show a loader twice. I am using a manual mode with UseEffect hook.
Please check a below video which demonstrate a issue itself from the code examples.
Minimal, Reproducible Example - (Optional, but Recommended)
https://www.material-react-table.com/docs/examples/remote
Screenshots or Videos (Optional)
https://github.com/user-attachments/assets/016ecdca-901e-487a-ac6a-92fb5c1170b5
Do you intend to try to help solve this bug with your own PR?
None
Terms

[X] I understand that if my bug cannot be reliably reproduced in a debuggable environment, it will probably not be fixed and this issue may even be closed.

Probably just a symptom of react strict mode. Else, any debouncing logic could fix


Near-complete Regions Unexplored support

First off, apologies for the duplicate pull requests. I am still learning how to submit pull requests to other repos.
This pull request includes near-complete support for Regions Unexplored. It does not include support for Alpha Leaves, Apple Oak Leaves, Flowering Leaves, or Palm Leaves, because the textures for these leaves broke when I added support in the same way I did for the others. Not sure if there is a workaround for that. Small Oak Leaves work by default and break when support is added in this way, so I have removed those files too. Tested with Regions Unexplored <IP_ADDRESS>.
I also included the shell script I wrote to generate these files (add_block.sh) which can be run with the modpack-id and the block-id as arguments to auto-generate compatibility files for other mods. Deleted these files to keep the folder clean, you can grab the .sh from the commits still if you like :)

This is really amazing!
Also thank you very much for the generator script, I've been working on one of my own, but never had the motivation to finish it, this will provide a solid base for that.


[Task]: Add bulk migration script runner in RTS

Is there an existing issue for this?

[X] I have searched the existing issues

SubTasks

Create script for bulk migration
Introduce APIs for triggering, checking and stopping bulk migrations
Integrate with Java Server on startup

Not going down this path


feature request: show status check indicator for current checked out branch

related to #84 which was closed because of inactivity.
But this is till an issue.
The original description:

When working on a specific branch inside vscode, only show the Pin workflows and see their status updates for the currently checked out branch.
This is better for multi-user projects. I want to see the status checks of the work I'm doing atm, and not see what's up when ever a user pushes to a public branch.
I'll try and implement this myself if I'll have the time. thanks for a great extension!

There is now the Current Branch view that provides that - at least in some form.


-generate-seed is a bit cumbersome

Having to add the argument --generate-seed is a bit cumbersome, especially that you have to add it once and then not again.
Ideally it would not be required and the seed would be automatically generated. Or, generate-seed is ignored if a seed was already generated before.

yes, I'd propose to just auto-generate on first startup. On the xmr-btc project we do that and did not get complaints (e.g. about money not been there after changing data dir).


False warnings for Heroku apps

The security tester checks if an app is hosted on a Heroku domain to whitelist Heroku apps with regard to TLS testing.
However some apps are hosted on Heroku, using a custom domain.  These apps are not whitelisted.  In principle this can be checked through a DNS query, and see if the domain points through a CNAME record to a Heroku domain.

Thanks for the heads up -- I figured that logic wasn't bulletproof.
Could you please include an app key, url to descriptor, or marketplace link to your app? I'll take a look at it for you.

@seanmarpo information requested is in a CDAC message.

Got it, thanks. Working on a fix now.


How to properly implement retry

Hi there! Thanks for such an awesome library. :D
I have an application that was just bitten by this panic. I'd like to implement the missing retry logic, but I'm not really sure that I understand the approach that I should take in doing so. Do you have any guidance about how I should approach adding this feature?

Hi. Unfortunately there is no good way to retry this so far. Is the issue reproducible?

Not currently. It has only happened once, but it crashed the entire application. Given that this panic originates on a goroutine that isn't started by application code directly, it's difficult to recover from, and it isn't clear if oto can still be used after recovering.
I will keep an eye out for it happening again and try to narrow down the cause. In the meantime though, is there anything that can be done to contain this failure so that the panic doesn't bring down the entire app? We are specifically hitting this case that is marked TODO, though the panic is a little later.

Yeah, as the TODO says, we should keep an error instead of panicking. However, as I am not so familiar with the audio API, I am not sure if we really can recover from this state or not. I'd like to know when this error happens. Thank you for investigating!


call jquery's .remove(), so we can listen on cleanup events.

call jquery's .remove(), so we can listen on cleanup events.

:+1:


Wlmon_Flash

Continuation of own WL_Flash implementation, partially already in main. TODOs in linked issue.

[ ] decide on proper log levels

closes #2

TODO: Safety and Performance modes: need detection? gain info specific to them? what is dump sector in performance?


PG 11 partitioning support

Why are we implementing it? (sales eng)
What are the typical use cases?
Communication goals (e.g. detailed howto vs orientation)
What features do we also support in citus? One in particular Samay mentioned is having unique indices in a parent table for use with upserts.
Good locations for content in docs structure
How does this work? (devs)
Example sql
Corner cases, gotchas
Are there relevant blog posts or outside documentation about the concept/feature?
https://h50146.www5.hpe.com/products/software/oe/linux/mainstream/support/lcc/pdf/PostgreSQL_11_New_Features_beta1_en_20180525-1.pdf
Link to relevant commits and regression tests if applicable

Murat's email captures details about this.

Just FYI:
PostgreSQL 11 adds support for foreign keys for partitioned tables. In Citus 8.0, we have two issues/limitations with foreign keys from partitioned tables.
The first one is related with Citus MX:  https://github.com/citusdata/citus/issues/2406
The other one is related with Online rebalancer when a partitioned table have a foreign key to a reference table: https://github.com/citusdata/citus-enterprise/issues/284
Do we want to capture the limitations in the docs?

Yep, we should capture any limitations in the Docs as well.
Thanks!
On Fri, Oct 19, 2018 at 12:31 AM Önder Kalacı<EMAIL_ADDRESS>wrote:

Just FYI:
PostgreSQL 11 adds support for foreign keys for partitioned tables. In
Citus 8.0, we have two issues/limitations with foreign keys from
partitioned tables.
The first one is related with Citus MX: citusdata/citus#2406
https://github.com/citusdata/citus/issues/2406
The other one is related with Online rebalancer when a partitioned table
have a foreign key to a reference table: citusdata/citus-enterprise#284
https://github.com/citusdata/citus-enterprise/issues/284
Do we want to capture the limitations in the docs?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/citusdata/citus_docs/issues/783#issuecomment-431271656,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACeeC4bZJ37tk_iiiYArSGBueUX2IC00ks5umX_pgaJpZM4W9XWL
.

--
Sumedh Pathak
Co-founder and VP Engineering | Citus Data |<PHONE_NUMBER>


Continue PR/3655

This is continuation of PR-3655 to add support for np.average

Reference an existing issue

I did a review confirming that all review questions originally from https://github.com/numba/numba/pull/3655 are already addressed.


Support alt.datum[signal_name] in addition to "datum[signal_name]"

Currently using alt.datum in altair does not support passing a signal/parameter whereas writing the expression string directly as JS-like string does (an example of dynamically passing fields via parameters here  https://github.com/altair-viz/altair/pull/3357/files (both the chart title and calculate transform).
Here is another example:
import altair as alt
from vega_datasets import data

dropdown = alt.binding_select(
    options=['Horsepower', 'Displacement', 'Weight_in_lbs', 'Acceleration'],
    name='X-axis column '
)
xcol_param = alt.param(
    value='Horsepower',
    bind=dropdown
)

alt.Chart(data.cars.url).mark_circle().encode(
    x=alt.X('x:Q').title(''),
    y='Miles_per_Gallon:Q',
    color='Origin:N'
).transform_calculate(
    x=f'datum[{xcol_param}]'
    # x=alt.datum[xcol_param.name]
).add_params(
    xcol_param
)

The reason it fails is that alt.datum[xcol_param.name] inserts additional quotation around the parameter name in the VL spec:
"transform": [{"calculate": "datum['param_1']", "as": "x"}],

whereas the VL spec for f'datum[{xcol_param}]' does not:
"transform": [{"calculate": "datum[param_1]", "as": "x"}],

Open the Chart in the Vega Editor
Personally I think the cleanest would be if we could support just using the variable name without the .name suffix when using alt.datum, as in this example from the docs:
param_color_js_expr = alt.param(expr=f"{param_width.name} < 200 ? 'red' : 'black'")
param_color_py_expr = alt.param(expr=alt.expr.if_(param_width < 200, 'red', 'black'))

But even if that doesn't work, just supporting the use of the .name suffix without the quotes inserted would be great. Here are a few examples of how these datums and expressions get translated with differential quoting:

Thanks for writing this up, I think alt.datum[xcol_param] rather than alt.datum[xcol_param.name] makes good sense

@joelostblom I've seen you mention this issue a few times.
Directly fixing alt.datum[Parameter] escaping would only require a small change like:
diff altair/expr/core.py

I would replace the hasattr()(s) with a @runtime_checkable protocol - just trying to keep this diff simple:
diff --git a/altair/expr/core.py b/altair/expr/core.py
index e7872ada..aa0b4d25 100644
--- a/altair/expr/core.py
+++ b/altair/expr/core.py
@@ -18,7 +18,11 @@ class DatumType:
         return GetAttrExpression("datum", attr)

     def __getitem__(self, attr) -> GetItemExpression:
-        return GetItemExpression("datum", attr)
+        if hasattr(attr, "param_type") and hasattr(attr, "name"):
+            expr = GetItemExpression("datum", attr.name, escape=False)
+        else:
+            expr = GetItemExpression("datum", attr)
+        return expr

     def __call__(self, datum, **kwargs) -> dict[str, Any]:
         """Specify a datum for use in an encoding."""
@@ -230,11 +234,12 @@ class GetAttrExpression(Expression):

 class GetItemExpression(Expression):
-    def __init__(self, group, name) -> None:
-        super().__init__(group=group, name=name)
+    def __init__(self, group, name, *, escape: bool = True) -> None:
+        super().__init__(group=group, name=name, escape=escape)

     def __repr__(self) -> str:
-        return f"{self.group}[{self.name!r}]"
+        r = self.escape
+        return f"{self.group}[{repr(self.name) if r else self.name}]"

My main question is what does alt.datum[(Parameter|Parameter.name)] represent?
I can test out things for myself, but it isn't immediately obvious to me what the difference is between:

alt.datum[Parameter.name]
alt.datum[Parameter]
Either of those but for

alt.datum(...)
alt.datum.__getattr__(...)

Using Parameter directly
What relation (if any) this has to alt.expr

Is there any documentation on this I've missed?

I think adding something like Parameter.to_datum() might be a clear way to represent this.
Maybe there's a more fitting name, but your first example would then become:
Code block

https://github.com/vega/altair/issues/3366#issue-2189513304
import altair as alt
from vega_datasets import data

dropdown = alt.binding_select(
    options=['Horsepower', 'Displacement', 'Weight_in_lbs', 'Acceleration'],
    name='X-axis column '
)
xcol_param = alt.param(
    value='Horsepower',
    bind=dropdown
)

alt.Chart(data.cars.url).mark_circle().encode(
    x=alt.X('x:Q').title(''),
    y='Miles_per_Gallon:Q',
    color='Origin:N'
).transform_calculate(
    x=xcol_param.to_datum()
    # x=f'datum[{xcol_param}]'
    # x=alt.datum[xcol_param.name]
).add_params(
    xcol_param
)

We'd also be able to add some examples in the docstring of where this should be used, along the lines of our discussion in https://github.com/vega/altair/issues/3500#issuecomment-2313271440

It's not the parameter becoming a datum, so I don't personally think Parameter.to_datum() would be a good fit.

That's fair @jonmmease!
I've had another read through these, but I'm having a hard time pinning down a more accurate name for this op

https://altair-viz.github.io/user_guide/interactions.html#encoding-channel-binding
https://github.com/vega/vega-lite/issues/7365

Very open to any other suggestions 😄

Thanks for looking into this @dangotbanned! Do we need a name for this operation or can we just support alt.datum[param] rather than Parameter.method_name()? This is the closest to the existing Vega-Lite JS syntax and like Jon mentioned alt.datum['column_name] can be used to reference any column in the data, so it seems intuitive to me that having a param that stores a string value can be passed instead of a string directly.

Thanks for looking into this @dangotbanned! Do we need a name for this operation or can we just support alt.datum[param] rather than Parameter.method_name()? This is the closest to the existing Vega-Lite JS syntax and like Jon mentioned alt.datum['column_name] can be used to reference any column in the data, so it seems intuitive to me that having a param that stores a string value can be passed instead of a string directly.

Yeah we can just support alt.datum[Parameter] without the additional method @joelostblom.
I would say the general aim I had there was to try and improve discoverability of this feature.
If we can do that without a method I'm happy with a different route.
Alternate proposal
We could make the following changes to update alt.datum in line with alt.expr

(#3600-expr.__init__.py)
https://github.com/vega/altair/pull/3466

DatumType -> _DatumMeta

.__repr__()
.__getattr__()
.__getitem__()

Make the functional changes in my earlier comment
Add doc examples

alt.datum[str]
alt.datum[Parameter]

datum (variable) -> datum (class)

.__call__() -> .__new__()

Add a backwards compat alias

DatumType = _DatumMeta

Then we include datum in the API Reference under the same section as expr:
https://github.com/vega/altair/blob/17968ea95489cc88de647381d3d1974b49dab88e/tools/generate_api_docs.py#L128-L130
Benefits

Provide the support this issue was opened for
Make the operation visible in both the API Reference & an IDE


Add the user to start the service as a constructor parameter

This is needed in the case of flume-syslog

Missed that.  Damn that hard-coded, low-number port in rsyslog-forwarder-ha.


Tensorflow fails to find GPU device

Operating System: Ubuntu 16.04
Installed version of CUDA and cuDNN: CUDA 8.0.27, cuDNN 5.1.5

$ ls ~/bin/cuda-8.0/lib64/libcud*
/home/maxim/bin/cuda-8.0/lib64/libcudadevrt.a    /home/maxim/bin/cuda-8.0/lib64/libcudart.so.8.0.27  /home/maxim/bin/cuda-8.0/lib64/libcudnn.so.5
/home/maxim/bin/cuda-8.0/lib64/libcudart.so      /home/maxim/bin/cuda-8.0/lib64/libcudart_static.a   /home/maxim/bin/cuda-8.0/lib64/libcudnn.so.5.1.5
/home/maxim/bin/cuda-8.0/lib64/libcudart.so.8.0  /home/maxim/bin/cuda-8.0/lib64/libcudnn.so          /home/maxim/bin/cuda-8.0/lib64/libcudnn_static.a

nvidia-smi shows the GPU.

Environment variables:

declare -x CUDA_HOME="/home/maxim/bin/cuda-8.0"
declare -x PATH="/home/maxim/bin/anaconda2/bin:/home/maxim/bin/cuda-8.0/bin:/home/maxim/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin"
declare -x LD_LIBRARY_PATH="/home/maxim/bin/cuda-8.0/lib64:"

Tensorflow version: 0.10.0rc0 (installed by Anaconda)
Note that on the same machine Theano works perfectly:

$ python theano_check1.py
Using gpu device 0: GeForce GTX 960M (CNMeM is disabled, cuDNN 5105)

But Tensorflow does not:
Could not satisfy explicit device specification '/device:GPU:0' because no devices matching that specification are registered in this process; available devices: /job:localhost/replica:0/task:0/cpu:0

How did you install TensorFlow? Official binaries (11rc0 and before) don't support CUDA 8.0, only CUDA 7.5

How did you install TensorFlow?

conda install tensorflow
It looks like 0.10.0rc0 is the latest version in Anaconda.
I have also tried 0.11.0rc0 from pip, nothing's changed.

Official binaries (11rc0 and before) don't support CUDA 8.0, only CUDA 7.5

Interesting. The doc says "The GPU version works best with Cuda Toolkit 7.5 and cuDNN v5"
BTW Nvidia lists CUDA Toolkit 7.5 and below under "archived":
https://developer.nvidia.com/cuda-toolkit-archive
And CUDA Toolkit 8.0 is the only version supported for Ubuntu 16.04, so I guess I don't have a workaround to downgrade CUDA.

@maxim5 yeah, I had to downgrade my Ubuntu down from 16.04 in order to get CUDA working

In case anyone has the same problem: tensorflow supports CUDA 8.0, if you build it from sources *and configure accordingly).
The following post worked for me: https://alliseesolutions.wordpress.com/2016/09/08/install-gpu-tensorflow-from-sources-w-ubuntu-16-04-and-cuda-8-0-rc/
The issue is therefore: support CUDA 8.0 out of the box, because it is the primary CUDA version now.

CUDA 8.0 will be supported soon. Right now we only officially support 7.0 - 7.5. Please see #2559 which is tracking this.


Mock DbErr

Resolves #1235

@robot-head does this work for you?

Looks good to me! Great job, thank you

What a smart way to avoid breaking existing public API :)

Yeah honestly impressed, a much better solution than I proposed, learning here!

Feeling flattered.
https://github.com/SeaQL/sea-orm/releases/tag/0.10.4


video/audio: add videojs previewer for a/v files

uses videojs to preview audio and video files
closes #7

Screenshots
Audio previewer

Initial Video

Paused Video

Notes

We will be in the process of testing this internally over the next couple of weeks to see what else to be considered.
The CI is failling in general for tinymce it looks like.

Excellent contribution, much appreciated! 🚀

Tested with nginx server, with Firefox on Ubuntu client. Works well enough. Important thing is to have a fronting server like nginx that can respond to range request (mostly for video). I didn't have to make other nginx config adjustments (other than already done X-Accel-Redirect configuration which allows file serving by nginx in the first place).

Rebased. I don't have the repo rights to merge this one though. @lnielsen or someone else can do it now.


New version: JackenWu.MSearcher version 1.4.0

Pull request has been created with komac v2.8.0 :rocket:
Microsoft Reviewers: Open in CodeFlow

为了触发需要注意


Add ability to play animation reverse(#3837) and some comment to TextureManager.js

Please do not update the README or Change Log, we will do this when we merge your PR.
This PR (delete as applicable)

Updates the Documentation
Adds a new feature
Fixes a bug

Describe the changes below:

Add a feature to play animations in reversed sequence (issue #3837)
I added a attribute reverse in AnimationConfig. default value is false.
if reverse is true, that animation's sequence is reversed. it seems to works in my test case. Feedback please.

Add some descriptions to TextureManager.js

I`m trying to solve this in a different way, you basically are reversing the frame orders, I am trying to create a revert function that can reverse the animation at any time, also a playReverse function that runs the animation in reverse mode.
I don´t know which solution is the best one  @photostorm can tell us?

I also thought about that. However, too many functions and classes are associated and all of that should be modifed to implement that way. It can cause many errors so I was trying to find a solution that doesn't have to touch original source code.
If you can implement that function safely, your solution will be better than mine.

Thanks for the PR @Edwin222 ! I think I'd rather do proper reversed animation support than just flipping the array. However, the comments you added into the Texture Manager are great so I'd like to merge those! Would you mind removing the reverse change, then I'll gladly pull in the rest. Every little bit helps when it comes to the docs!

Thank you for feedback. I change it.

Thank you :) Just to say that reverse animation support will be coming in 3.12!


Missing box-sizing:border-box style in self compiled css v5.2.3

Prerequisites

[X] I have searched for duplicate or closed issues
[X] I have validated any HTML to avoid common problems
[X] I have read the contributing guidelines

Describe the issue
I am using bootstrap 5.2.3 version & had  some strange issue with grid. I was getting horizontal scroll bar in browser while implementing nested grid columns.
When I compared with precompiled version & example of grid at bootstrap docs, I found below specific style in bootstrap docs site's loaded bootstrap.min.css but missing in my self compiled using webpack.
When I looked at npm installed package bootstrap 5.2.3 package, I found it in all precompiled css files but it has no mention in scss files which are using self compiled version.
*,::after,::before{box-sizing:border-box}
Adding it in webpage independently, it solved my scrollbar & over width issue of container.
Sorry If I am missing any more technical information, you can ask me anytime!
Is there anything I am doing wrong Or there is anything really missing at<EMAIL_ADDRESS>Reduced test cases
@import "~bootstrap/scss/functions";
@import "~bootstrap/scss/variables";
$body-color: #005487;
$app_lblue : #00A1DF;
$custom-colors: (
"app_lblue": $app_lblue,
'white'    : $white,
'black'    : $black,
);
$theme-colors: map-merge($theme-colors, $custom-colors);
$theme-colors-rgb: map-loop($theme-colors, to-rgb, "$value");
@import "~bootstrap/scss/maps";
@import "~bootstrap/scss/mixins";
@import "~bootstrap/scss/utilities";
@import "~bootstrap/scss/root";
$tooltip-bg     : #8C8989;
$tooltip-opacity: 1;
$enable-rounded              : false;
$enable-shadows              : true;
$enable-gradients            : true;
$enable-responsive-font-sizes: true;
$input-focus-box-shadow      : 0 0 0;
$link-color        : $app_lblue;
$table-border-color: $app_lblue;
$hr-border-color   : $app_lblue;
$border-color      : $app_lblue;
$input-border-color      : $app_lblue;
$input-focus-border-color: $app_lblue;
$input-color             : $app_lblue;
$input-plaintext-color   : $app_lblue;
$input-focus-color       : $app_lblue;
$input-placeholder-color : $secondary;
$form-check-input-checked-bg-color : $app_lblue;
@import 'bootstrap/scss/bootstrap';
@import<EMAIL_ADDRESS>What operating system(s) are you seeing the problem on?
Windows
What browser(s) are you seeing the problem on?
Chrome
What version of Bootstrap are you using?
v5.2.3

Hey @mrunalpittalia.
If I understand this issue correctly, what you're looking for is in https://github.com/twbs/bootstrap/blob/492187de6468efe8ac774ff25f00522181364af1/scss/_reboot.scss#L16-L20.
You can find some help in Customize > Sass documentation where it is recommended to also include reboot which seems to be missing in your reproducible example.
You need to remove import 'bootstrap/scss/bootstrap'; as well since you've chosen to import things yourself.

Hey Juliean,
Thanks for quick action!
I will make changes & respond here in next few hours.

Including Reboot is the right move here, it's where we set box-sizing as mentioned by @julien-deramond. Either include that stylesheet or your own box-sizing.

Yeah, the suggestion worked fine.
Can be closed now


fix: also remove binaries of pruned environments

The fix is that the pruning function now takes care of both the environment and the binaries at the same time.

Yes, I had removed the binary deleting and moved it into the clean_environment_binaries but it didn't call them from the sync function anymore so that is fixed with this.

Understood! Let's merge this then.


add share screen method

Using package called stream-display to getDisplayMedia that sends screen video feed as ImageData then changed to ImageBitmap so can be decoded with nimiq/qr-scanner
For this PR, I add 2 features

Share Screen as mentioned in #1
Auto Submit (using share screen)

Thanks! I really appreciate it.


Support for electron/fuses

Is there any consideration for supporting electron/fuses? I would like to encrypt the cookies with [FuseV1Options.EnableCookieEncryption]: true fuse with my application, but making any fuse changes causes the python -m castlabs_evs.vmp sign-pkg command to fail with the following error. It makes binary level changes to executable to flip fuses, which causes the bad signature I think.
(evs-env) PS C:\Users\eXhumer\Projects\eXViewer> python -m castlabs_evs.vmp sign-pkg .\out\eXViewer-win32-x64\
Signing: .\out\eXViewer-win32-x64\eXViewer.exe
 - Verifying existing VMP signature
 - Signature invalid: Failed to verify signature
 - Requesting VMP signature
HTTPError: Signing request failed: 400 Bad Request
 <- ValidityError: Binary signature denied

The sign-pkg command has no issues if no fuses are changed from default.
By default, the following fuses are used
(evs-env) PS C:\Users\eXhumer\Projects\eXViewer> yarn run electron-fuses read --app .\out\eXViewer-win32-x64\eXViewer.exe      yarn run v1.22.19
$ C:\Users\eXhumer\Projects\eXViewer\node_modules\.bin\electron-fuses read --app .\out\eXViewer-win32-x64\eXViewer.exe
Analyzing app: eXViewer.exe
Fuse Version: v1
  RunAsNode is Enabled
  EnableCookieEncryption is Disabled
  EnableNodeOptionsEnvironmentVariable is Enabled
  EnableNodeCliInspectArguments is Enabled
  EnableEmbeddedAsarIntegrityValidation is Disabled
  OnlyLoadAppFromAsar is Disabled
  LoadBrowserProcessSpecificV8Snapshot is Disabled
Done in 0.49s.

This is actually something that would be interesting to add support for. For now it is not planned, and it is likely to be rather complicated to add safely (so I can't give an estimate or anything), but I will make sure it is put up for consideration.


minor front-end changes to home and login pages

the more specific you can be about your changes with each commit the easier they are to review


extra %20 after links

There seems to be an extra %20 attached to links like project, articles, etc. causing the links to break.

Duplicate of # #14


Extend the usage of build ENV USE_LOCAL_IMAGES

Problem:

https://github.com/harvester/harvester/issues/6489
Solution:

Allow specify a tag (e.g. for all 3 Harvester related images) via the ENV USE_LOCAL_IMAGES to skip the qualified images directly.
Related Issue:
https://github.com/harvester/harvester/issues/6489
Test plan:

export USE_LOCAL_IMAGES=fix6486-head && make build-iso
the build log:
...
[ImageCache] docker.io/rancher/harvester-pcidevices:v0.4.0 exists.
[ImageCache] docker.io/rancher/harvester-seeder:v0.3.0 exists.
[ImageCache] docker.io/rancher/harvester-upgrade:fix6486-head meets the specified tag from USE_LOCAL_IMAGES.
[ImageCache] docker.io/rancher/harvester-upgrade:fix6486-head exists.
[ImageCache] docker.io/rancher/harvester-vm-import-controller:v0.4.0 exists.
[ImageCache] docker.io/rancher/harvester-webhook:fix6486-head meets the specified tag from USE_LOCAL_IMAGES.
[ImageCache] docker.io/rancher/harvester-webhook:fix6486-head exists.
[ImageCache] docker.io/rancher/harvester:fix6486-head meets the specified tag from USE_LOCAL_IMAGES.
[ImageCache] docker.io/rancher/harvester:fix6486-head exists.
[ImageCache] docker.io/rancher/support-bundle-kit:master-head has "-head" suffix.
[ImageCache] docker.io/rancher/support-bundle-kit:master-head: pulling...
master-head: Pulling from rancher/support-bundle-kit
Digest: sha256:c9464513d387e6acadc38144eec0758d5e6896e8678d543a2237594591bc1e4b
Status: Image is up to date for rancher/support-bundle-kit:master-head

@mergify backport v1.4

Neat!
We'll need to also update the wiki page at https://github.com/harvester/harvester/wiki/Build-ISO-images once this is merged.

@tserong
The wiki page https://github.com/harvester/harvester/wiki/Build-ISO-images is updated as well.

Thanks @w13915984028!


Always infer JSDoc for parameters

If there are no inferences found, use any.
I only do this for parameters because I couldn't come up with any uses of variables or class members that didn't already succeed using (1) the type of the initialiser or (2) control flow analysis (for variables).
Based on our discussion with VS Code.

Actually, I think I'll make this a more comprehensive change in my upcoming PR, so that it applies to (1) suggestions in TS files and (2) all JS files.
This requires knowing when noImplicitAny is a suggestion in a TS file.


No way to get service/method descriptors for GRPC services?

It seems to me that the generated Go code for a proto file with services does not allow a general way to obtain descriptors for services. As a consequence, there is no way of inspecting custom ServiceOptions or MethodOptions extensions at runtime.
The only exported symbols are the Register... method for the service side, and New...Client... methods for the client. Both are not suitable for obtaining a descriptor. While it maybe possible to get to that information via the FileDescriptorProto, there likewise is no general way to obtain a file descriptor from the Go code generated from a proto file - after all, no messages might be declared in that same file.
Am I missing something here? This seems to be a surprising omission.

@misberner Feel free to re-open this discussion if you think adding a method to the grpc package to do this is the wrong approach.

I would personally like the ability to retrieve the file descriptors, and ideally the service descriptors too.
I don't think this would be inconsistent with the current API, as messages (structs) already include a Desciptor() method, and the file descriptor bytes can be indirectly retrieved via proto.FileDescriptor(filename). But it would be much more convenient if the file descriptor were exposed directly in the generated code so that the retrieval of the file descriptor is decoupled from the filename. eg. mypackage.FileDescriptor()

@paranoiacblack if I'm understanding correctly, the option of adding a method to the grpc package requires that a service already be registered with a grpc server. I would like to be able to inspect the ServiceDescriptorProto and ServiceDesc without having to register with a server.
The use case here is for doing introspection on the service, so that we can do things like:

Check if a service being passed in is already registered with the server
Dynamically register services with the server as-needed
List the methods a service implements for presenting to a user (or program), from a client perspective, without the protobuf available

In general though, having FileDescriptor and ServiceDescriptor exported is useful for doing introspection on the protobuf without having to resort to reflection. This is something I believe is decently common practice within Google when writing framework-level code around protobufs and rpc services, at least for Java/Python, though I left Google quite a while ago and that may have changed.
I made https://github.com/golang/protobuf/pull/516. It's a minimal PR to expose the ServiceDescriptorProto and ServiceDesc.

Hi @mightyguava, you mention being able to inspect ServiceDescriptorProto and ServiceDesc without having to register with a server. I suppose that is not unreasonable, but it's not clear how this helps with your use cases.

Checking if a service is already registered. It seems that regardless of how easy it is to access the service descriptor, you ultimately have to ask the grpc.Server to tell you if something is already registered. If not, you'd need to keep track of your own registration list. I don't see how this is an improvement over a grpc provided method such as func (s *grpc.Server) IsRegistered(service name) bool. Having the exact value of the service descriptor won't help with multiple registration of the same named service.

I'd make a similar argument. It seems like you would need both assistance from grpc's library and to keep track of your own set of registered services to achieve this. If grpc provided the method I mentioned earlier, you would combine your stored information for dynamic re-registration via grpc.Server.RegisterService(grpc.Server.GetServiceDesc(name)). It isn't clear to me how exporting service descriptors makes this much easier, except that it means gRPC does not have to add this method.

This is a fine use-case, but it's not clear to me how you can do this without the protobuf available. Can you elaborate? It seems like you need to protobuf no matter what and exporting it only gives you a fast path to listing each of the individual methods in a service. If you are referring to listing the methods on a server, again, you need help from gRPC to tell you this information; the protos have no idea with which server they are registered.

I think accessing these fields via reflection is a bad idea, as you stated. #516 seems okay on the face of it, but it would be much better if you could show me code that demonstrates how you're using it to achieve your goal. I still don't think exporting these descriptors gets you very far because it does not answer any particular questions about your service; it just gives you a simpler way to query it.

@alecthomas I agree that it is not inconsistent with current exposure of the FileDescriptor. Although, I would argue that the proto package is something that can help you inspect and use protos similarly to the grpc package helps you inspect and use servers. Whether or not it is more convenient is unclear to me. Having a single place/import/package that can answer my meta-questions about protobufs seems like a good separation of concerns whereas having each generated proto learn to answer meta-questions about itself seems awkward in my experience with these libraries. Has anyone tried to make an issue with gRPC to hear their opinion on this? I'm willing to make very similar arguments there.

@paranoiacblack For 1 and 2, you are right, in principle, that having an IsRegistered(service name) bool is better for dynamically registering services. However, how does one get the service name? As far as I am aware, the canonical name is only available in 2 places: in ServiceDesc.Name, and in the service descriptor, neither of which is exposed. There aren't even any server structs that one can pass in in place of it for the grpc library to reflect on. Even if there were, how would I print the canonical name of the service? Do I have to ask grpc for it? And if say we were to generate the canonical name of the service and expose it on the protobuf, how do I get the canonical method name for it? Do I open another issue to ask grpc to implement it for me?
I'm sure there can be some way for all of this to be provided by the grpc library, this sounds like a rabbit hole. Should the grpc package predict, implement, and constrain all possible uses of grpc services and wrap all reflection operations? Or should enough information about services be exposed so that the clients of the protobufs and the grpc library can do it themselves, safely?
I think you make a good point that the grpc package is probably the right place for most things around inspecting and use of servers in place. I'd like to add to that argument that the protoc-gen-grpc plugin also belongs in the grpc package, because the stubs appear to be for the exclusive use of the grpc package. It does not belong in this repo. Following along this line of reasoning, that the grpc plugin belongs in the grpc package, I think it makes perfect sense that code generated for and by the grpc package offer the ability to introspect services. It doesn't appear to be technically feasible to separate the plugin from proto though, since the plugin system isn't actually pluggable.
On point 3, I phrased it poorly. By client I meant the client fo the grpc library and the end-user, not the grpc client. I am not referring to listing methods on the server. I am referring to listing the canonical name of the service and methods of the service.
For my use case, I would like to, before registering a service dynamically with a server, know which methods this service will be adding. I don't need information on the server they are being registered against because the server hasn't been created yet and I have full knowledge of the parameters it will have. I can do this by directly inspecting either the ServiceDesc or ServiceDescriptor. The ServiceDesc provides at a higher level the properties of the service and methods. The ServiceDescriptor provides basically full information about the service. This information can be useful for logging and debugging when dynamically registering grpc services to a server. I don't really want to write out additional code here, since my use case is pretty context dependent and wouldn't make much sense outside my project, as would be many other uses of this feature, or grpc in general really.

The third place the canonical names are listed, on a given server, is https://godoc.org/google.golang.org/grpc#Server.GetServiceInfo, which also would answer your questions about whether or not that service is registered or not as well as which methods the server claims exist. My understanding of your change is that you would just use the ServiceDesc to get a canonical name to lookup, rather than going through the ServiceInfo mapping to discover it. There's not unreasonable, but I'd like to demonstrate its use in some test code or something before moving forward on that change. If the way you were going to use this is different, please explain.
I don't buy the argument that protoc-gen-grpc belongs in the grpc package, it's just a code generator that relies on grpc internals. It doesn't know anything about grpc, particularly, really, except how to invoke a method using a name it generated. The regular proto compiler could also do this work, but it's wasted effort if there actually aren't any services in your proto.
About information about services being exposed to clients, I thought that was the intention behind https://github.com/grpc/grpc/blob/master/doc/service_config.md, although it seems like you would be unable to use this if you are dynamically registering services and methods.
So to your actual problem, you want to do this all a-priori, before there's any server running I suppose. I'd still like you to provide a unit test that demonstrates how to use this feature, though. If your use-case is context dependent, we can massage it a bit into a reasonable test case. To be clear, I think your request is reasonable and appreciate the clarification. Please move forward with a small example and we can try adding this.

@dfawley Can you share any thoughts on the line between grpc's service introspection and what the grpc proto plugin can provide to the user. I'm on the line about this change because it isn't clear to me how this interacts with services that use interception or service/method renaming. It seems like regardless of what any given generated service descriptor might tell you, grpc is the only package that can tell you the true state of any given server. Am I missing something?

Hey @paranoiacblack, thanks for reopening the issue. What I'm trying to do is definitely context-dependent.
Not really sure what you are looking for in terms of a unit test. I couldn't find any tests for the grpc generator in this repo. Here's a test that demonstrates the use of the ServiceDesc. https://github.com/mightyguava/protobuf-1/commit/a5540aaa8465730bf26eacf34578a5a71dfbac87
A practical use of the descriptor proto in code would be very context dependent and doesn't really add any value here. If the goal is correctness and regression testing, golden tests should suffice. If the goal is understanding further why someone would want to introspect a service descriptor before registering with a server, let me know what I can add here other than the comments above.

@paranoiacblack,
In an ideal world, the grpc proto plugin should only need to generate the stubs the user needs to use grpc with protobufs in a type-safe and user-friendly way.  It should not be relied upon to provide "core" proto functionality like introspection/reflection of proto definitions themselves -- operations that could be useful with all RPC services.
I'm sure there's a good reason for this, but can we not export fileDescriptor<n> from the generated code as a slice?  Then a user with access to a package could trivially get the FD protos for it without needing to know its name.
Short of that, I'm not really sure what the best path forward is.  The default proto generator currently doesn't generate any symbols for services.  The grpc plugin only generates interfaces for services, meaning we can't attach a Descriptor() method to them like message types have.  We could theoretically generate FooDescriptor() functions that return ServiceDescriptorProtos for every service, but it wouldn't be possible to programmatically find this function without reflection, so I'm not sure it would have much value.
I also would like to learn more about use cases 1 and 2, and see how these would work in code.
For 3, in case you aren't already aware, gRPC offers a reflection service that can be used to retrieve FileDescriptorProtos for all the registered services in a given server.  But as @mightyguava seems to want to avoid, you'd need to first register the service with the server before using this.

We could theoretically generate FooDescriptor() functions that return ServiceDescriptorProtos for every service, but it wouldn't be possible to programmatically find this function without reflection, so I'm not sure it would have much value.

Having FooDescriptor() is actually fine for my purposes. I would really just like any way to reference the ServiceDescriptorProto for a service. It currently can't even be done with reflection. It would be nicer if I could iterate over all Services in a file, but I could move on without it.
I think you make a very key argument here, that exposing the descriptor allows "operations that could be useful with all RPC services."

I also would like to learn more about use cases 1 and 2, and see how these would work in code.

I admit, these are more hypotheticals to make a case for exposing the ServiceDescriptorProtos. I don't personally have a use for this. Care more about case 3.

For 3, in case you aren't already aware, gRPC offers a reflection service that can be used to retrieve FileDescriptorProtos for all the registered services in a given server. But as @mightyguava seems to want to avoid, you'd need to first register the service with the server before using this.

Exactly. I am aware of the reflection service. But it would be super roundabout to register an implementation of a service on a dummy server, then register the reflection service, just to get the descriptor proto. It kind of defeats the purpose of using protobuf at all.

I am thinking maybe exposing the ServiceDesc would actually help the reflection service to be injectable, rather than relying on a registration pattern.
Then this can also help to solve this
https://github.com/grpc/grpc-go/issues/1873
If we have this simple example:
s := grpc.NewServer()
pb.RegisterYourOwnServer(s, &server{})
reflection.Register(s)
s.Serve(lis)

The reflection.Register can then call ServiceDesc to get the service descriptor.
Ah ok maybe that won't work, since the ServiceDesc does not have all the information.

@dfawley Thanks for the feedback. We could export fileDescriptor<n> as you stated, but it seems like that's really just another way for users to get to the ServiceDescriptor and they'll have to write these GetServiceDesc functions in each of their clients or servers, anyways. I suppose it's fine to provide this mechanism.
@awalterschulze I'm not really familiar about the intersection between proto reflection and service registration. But yes, this could be used to get partial information about the service, such as its canonical name and canonical method set, before the service is altered on registration.
@mightyguava Let's move forward with your change in #516. I still haven't seen a compelling use-case for this feature and you haven't provided a demonstration of its utility because you say it's context-dependent. So I'm reluctant to be exporting yet another poorly understood feature in this library, but I'm willing to take on the technical debt for when we end up breaking it. Overall, it seems reasonable, even if I don't understand it.

@paranoiacblack maybe we should chat more about this offline, but my hope was that by exporting the full FileDescriptorProtos for every package directly, we could avoid the need for GetFooServiceDesc[riptor] functions in the grpc code generator.  Users could pretty easily scan through the services in the package until they find the one they need by its name.  The issue AIUI is that right now the only way to get access to the ServiceDescriptorProtos is by using the filename that contains the service, which may not be known at runtime.
@mightyguava in #516, why do also want access to ServiceDescs?

@dfawley I want to be able to programmatically reference something that I can use to inspect the service. It doesn't matter as much whether this is a getFooServiceDescriptor() method or a getFooServiceDesc() method. I exposed both in the PR figuring that someone would tell me one is better than the other. I don't think we touched on this point in the discuss over the past few weeks...
Did you guys end up chatting offline? I can see having list of FileDescriptorProtos for the package can open up a lot of possibilities. It doesn't solve the specific use case of being able to reference the descriptor/desc though.

It doesn't solve the specific use case of being able to reference the descriptor/desc though.

Why not?  The FileDescriptorProtos should contain the ServiceDescriptorProtos you need -- no?

I would like to be able to directly reference getFooServiceDesc() or getFooServiceDescriptor() in code, rather than have to find it by string.

I apologize for jumping into this discussion late in the game.
I've been working on #364, which provides a behaviorally complete API for interfacing with proto messages. In order to do this, there needs to be an abstraction over the protobuf type system, which are encapsulated in proto as descriptors. As such, the API I'm working on fundamentally needs to involve some abstraction over the ProtoDescriptors. As I continue to work on this, it is becoming increasingly clear to me that Service and Method descriptors should be a part of the API that allows you to get the descriptors for all proto declarations.
I understand there is a desire for this feature today, but perhaps it should wait until work on #364 is complete. I'd rather not add another function that we will likely mark as deprecated in the near future.

It just occurred to me that this is entirely a subset of #293. Closing as duplicate.

For the OP's question, here's a simple way to get custom method and service options:
https://github.com/prasek/go-grpc-info


Login

- In this Repo:

Created the Login page
Created the sign-up page

STATUS: APPROVED!!! 🎉 🎉 🎉
Hi @felixDev22
Good job !!!
To Highlight! 👏 🟢
✔ Good commit messages

✔ Clean Code
✔ Descriptive Readme file
Your project is complete! Great work. There is nothing else to say other than... it's time to merge it :shipit:
Congratulations! 🎉 🎉 🎉

Important Notes 📝
Feel free to leave any questions or comments in the PR thread if something is not 100% clear. Please, remember to tag me in your question so I can receive the notification.


414 Request URI Too Large when updating a single file in the repository

Hi/Bonjour!
I have with the FileClient.Update method of the API because it writes the file content directly in the URL query parameters. I think the parameter should be passed in the body instead.
I can gladly do a PR for that but before I would like an active contributor to confirm if there's an actual reason for this behavior.
Thanks!

Hi,
Maybe previous version of GitLab required the parameter to be in the query string. Or maybe someone wrongly implemented the method.
If this is supported, feel free to create a PR that moves the content to the body.
Note that CommitClient.Create doesn't have this limitation.

I think it should be already fixed in #443.


Can we add an optional input to the Pass If Error and Fail if Error for error number?

Sometimes you are expecting a very specific error.
With the pass if error, you want it to pass if that specific error is raised, but only if that specific error is raised. If some other error is raised, you want that other error to propagate.
VI tester does support this. Sorry to keep comparing LUnit to VITester, but it is what I know.
Here is what it looks like in VI Tester.

If you make that input optional, then it should be backwards compatible.
Of course, there is a workaround in that I can just break down the error cluster myself and check the code manually.

Thanks for providing the feedback and suggestions Sam.
I have never found the need for this myself, but if you think it is useful I'd be happy to add the feature as it would not break anything.
I do like VI Tester and the initial goal for LUnit was to have feature parity with it. Let me know if you have other feature ideas.

Added two new assertions "Pass on Specific Error.vi" and "Fail on Specific Error.vi". Decided to not change the existing assertions as they probably meet 90% of use cases. Adding the optional terminal clutters the API and the additional logic adds some very slight overhead.
The new assertions are in a new subpalette called Advanced Assertions. I feel there are likely more assertions which could be useful. One which I use a lot in LMock is "Pass on match" for string comparison, i.e. pass if regex is found in string.
The new assertions are available from this release:
https://github.com/Astemes/astemes-lunit/releases/tag/v1.4.15
/Anton

I very much like the idea of "Pass On Match"
another one to consider might be "pass if set match" - I don't know if that is the right name, but I often find myself testing VIs that output arrays (that probably should be sets instead) where I don't care about the order.  I find them cumbersome to test, because I have to take the output and turn it into a set.


add rcon panel

add rcon panel for managing the server from the app
add it on the frontend using a npm package

note to self :) watch out for this: https://github.com/xtermjs/xterm.js/discussions/4615

https://github.com/pterodactyl/panel/blob/a9bdf7a1ef27a65f07ebbf71d8ea20285cdaf30f/resources/scripts/components/server/console/Console.tsx


Optionally allow unregistered users to view challenges

Add a Config entry view_challenges_unregistered to indicate whether
unregistered users can view challenges. Add the setting to the admin config
page.
Add can_view_challenges() to utils to test if a user is either authed, or the
configuration allow unauthenticated users to view the challenges.
Return a HTTP 401 Unauthorized error when the /chals/solves API can't provide
results for an unauthenticated user. This is needed because the client side
code in chalboard.js doesn't know if it's logged in or not and requests this
anyway. (And AJAX doesn't handle redirects very well.) Alternately the client
could actually know if they're logged in and not make needless API calls.
When an unregistered user attempts to submit a flag, it will also fail. The
user will be redirected to a login page.

Storing all the config data in the db as strings is kind of ugly. And it converts types at random times. It could be cleaned up some.
Also, you will need to recreate the database. The new Config entry needs be created during setup.

I originally stored data as strings in the db so that I wouldn't have to recreate databases as often. It would just be a try-except for existence and creation. But it is a little janky. The right solution is probably to implement database migration.
I like the idea, and I can always change stuff later :+1:


Implement expected file methods on Cog's queue logger

Since we're overwriting sys.std{out,err} with our custom logger, it
needs to implement the file methods present on the overwritten objects.
Signed-off-by: andreasjansson<EMAIL_ADDRESS>

@andreasjansson test failures look real :(

@bfirsh fixed


AniApi Compromised

AniApi is currently being used for malvertising

Outlinks on AniApi.com are also malicious in nature. Additionally, the original maintainer has archived  the project. It would be in everyone's best interest to remove this API from recommended APIs.

This is an automated response to help you with this issue. Please let us know if you need further assistance.

Anyone available to merge? It's a basic fix.


Feature feedback form

added endpoint to accept user feedback from orgbook bc
changed contact endpoint to accept additional form inputs and json data
renamed feedback endpoint => contact

Changes for v2 are only name changes. I wanted a bit of clarity so that the v2 feedback endpoint (which sends a contact request) isn't confused with the v4 feedback endpoint (which sends back user like/dislike feedback). I can remove the name changes to v2 if you would like.


compiler crash: checked decl cannot have error type

Describe the bug
the following test program crashes the compiler:
func test()
{
    let x:[Int] = []
    let y:[Int] = []
    let z:[Int] = []
    for (x, (y, (z, w))) in zip(x, zip(y, z))
    {
    }
}

error: compile command failed due to signal 6 (use -v to see invocation)
checked decl cannot have error type
(var_decl range=[test3.swift:6:10 - line:6:10] "x" type='<<error type>>' interface type='<<error type>>' let readImpl=stored immutable)
Please submit a bug report (https://swift.org/contributing/#reporting-bugs) and include the project and the crash backtrace.
Stack dump:
0.      Program arguments: /home/ec2-user/.swiftenv/versions/DEVELOPMENT-SNAPSHOT-2022-09-06-a/usr/bin/swift-frontend -frontend -c -primary-file test3.swift -target x86_64-unknown-linux-gnu -disable-objc-interop -color-diagnostics -new-driver-path /home/ec2-user/.swiftenv/versions/DEVELOPMENT-SNAPSHOT-2022-09-06-a/usr/bin/swift-driver -empty-abi-descriptor -resource-dir /home/ec2-user/.swiftenv/versions/DEVELOPMENT-SNAPSHOT-2022-09-06-a/usr/lib/swift -module-name test3 -o /tmp/TemporaryDirectory.YIyLiZ/test3-1.o
1.      Swift version 5.8-dev (LLVM a049441a0549936, Swift a973fe5375d3851)
2.      Compiling with the current language version
3.      While walking into decl 'test()' (at test3.swift:1:1)
4.      While walking into body of 'test()' (at test3.swift:1:1)
5.      While verifying VarDecl 'x' (at test3.swift:6:10)
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
/home/ec2-user/.swiftenv/versions/DEVELOPMENT-SNAPSHOT-2022-09-06-a/usr/bin/swift-frontend[0x67cbe23]
/home/ec2-user/.swiftenv/versions/DEVELOPMENT-SNAPSHOT-2022-09-06-a/usr/bin/swift-frontend[0x67c9afe]
/home/ec2-user/.swiftenv/versions/DEVELOPMENT-SNAPSHOT-2022-09-06-a/usr/bin/swift-frontend[0x67cc1af]
/lib64/libpthread.so.0(+0x118e0)[0x7fa44d2918e0]
/lib64/libc.so.6(gsignal+0x110)[0x7fa44b5b4ca0]
/lib64/libc.so.6(abort+0x148)[0x7fa44b5b6148]
/home/ec2-user/.swiftenv/versions/DEVELOPMENT-SNAPSHOT-2022-09-06-a/usr/bin/swift-frontend[0x1c8433e]
/home/ec2-user/.swiftenv/versions/DEVELOPMENT-SNAPSHOT-2022-09-06-a/usr/bin/swift-frontend[0x1c8460b]
/home/ec2-user/.swiftenv/versions/DEVELOPMENT-SNAPSHOT-2022-09-06-a/usr/bin/swift-frontend[0x1c7caac]
/home/ec2-user/.swiftenv/versions/DEVELOPMENT-SNAPSHOT-2022-09-06-a/usr/bin/swift-frontend[0x1c860b7]
/home/ec2-user/.swiftenv/versions/DEVELOPMENT-SNAPSHOT-2022-09-06-a/usr/bin/swift-frontend[0x1c89961]
/home/ec2-user/.swiftenv/versions/DEVELOPMENT-SNAPSHOT-2022-09-06-a/usr/bin/swift-frontend[0x1c89a57]
/home/ec2-user/.swiftenv/versions/DEVELOPMENT-SNAPSHOT-2022-09-06-a/usr/bin/swift-frontend[0x1c891b8]
/home/ec2-user/.swiftenv/versions/DEVELOPMENT-SNAPSHOT-2022-09-06-a/usr/bin/swift-frontend[0x1c88853]
/home/ec2-user/.swiftenv/versions/DEVELOPMENT-SNAPSHOT-2022-09-06-a/usr/bin/swift-frontend[0x1c8b6e6]
/home/ec2-user/.swiftenv/versions/DEVELOPMENT-SNAPSHOT-2022-09-06-a/usr/bin/swift-frontend[0x1c8608e]
/home/ec2-user/.swiftenv/versions/DEVELOPMENT-SNAPSHOT-2022-09-06-a/usr/bin/swift-frontend[0x1c86023]
/home/ec2-user/.swiftenv/versions/DEVELOPMENT-SNAPSHOT-2022-09-06-a/usr/bin/swift-frontend[0x1e35a18]
/home/ec2-user/.swiftenv/versions/DEVELOPMENT-SNAPSHOT-2022-09-06-a/usr/bin/swift-frontend[0x1c733a8]
/home/ec2-user/.swiftenv/versions/DEVELOPMENT-SNAPSHOT-2022-09-06-a/usr/bin/swift-frontend[0x1f2f0b7]
/home/ec2-user/.swiftenv/versions/DEVELOPMENT-SNAPSHOT-2022-09-06-a/usr/bin/swift-frontend[0x17165fd]
/home/ec2-user/.swiftenv/versions/DEVELOPMENT-SNAPSHOT-2022-09-06-a/usr/bin/swift-frontend[0x1714168]
/home/ec2-user/.swiftenv/versions/DEVELOPMENT-SNAPSHOT-2022-09-06-a/usr/bin/swift-frontend[0x1714144]
/home/ec2-user/.swiftenv/versions/DEVELOPMENT-SNAPSHOT-2022-09-06-a/usr/bin/swift-frontend[0x6ea7a9]
/home/ec2-user/.swiftenv/versions/DEVELOPMENT-SNAPSHOT-2022-09-06-a/usr/bin/swift-frontend[0x6df0ea]
/home/ec2-user/.swiftenv/versions/DEVELOPMENT-SNAPSHOT-2022-09-06-a/usr/bin/swift-frontend[0x6df087]
/home/ec2-user/.swiftenv/versions/DEVELOPMENT-SNAPSHOT-2022-09-06-a/usr/bin/swift-frontend[0x68eec9]
/home/ec2-user/.swiftenv/versions/DEVELOPMENT-SNAPSHOT-2022-09-06-a/usr/bin/swift-frontend[0x4c1f4c]
/lib64/libc.so.6(__libc_start_main+0xea)[0x7fa44b5a213a]
/home/ec2-user/.swiftenv/versions/DEVELOPMENT-SNAPSHOT-2022-09-06-a/usr/bin/swift-frontend[0x4c111a]

i reproduced the crash on DEVELOPMENT-SNAPSHOT-2022-08-18-a and DEVELOPMENT-SNAPSHOT-2022-09-06-a.

Went from a fallback diagnostic (type of expression is ambiguous without more context) to a crash :/

It seems like we're creating AllowTupleTypeMismatch and IgnoreUnresolvedPatternVar fixes, but it doesn't end up in the Fixes array for the solution so applySolution does not call applySolutionFixes.

Hi, I have time to chase this down. Please assign bug to me

On it


Unit 3: Issue Installing Gym

Seems like Unit 3 suffers from the same issue installing gym we saw in issues #251 and #253.
Suggesting we add a cell to Unit 3's notebook !pip3 install setuptools==65.5.0 right before the requirements.txt cell:
!pip install -r requirements.txt
# Since colab uses Python 3.9 we need to add this installation
!pip install gym[atari,accept-rom-license]==0.21.0

@simoninithomas I saw you were going to do a big update Tuesday. Did you want to add this to that update? If not I can make a quick PR for it on my end.

Hey there, if you can make a PR I will merge it today 🤗 thanks


Model Server Energy Prediction

Retrieves model weights from the Kepler Model Server and uses the weights for energy prediction.

thank you @KaiyiLiu1234

looking forward to integrating this to the collector
cc @sunya-ch

@KaiyiLiu1234 can you rebase?

Ok will do. I will also make a small change to how the model server exports the weights.

Working to resolve.


bitbucket basic not working

I tried both basic as well as oauth to connect to bitbucket but both cases I get following error
ForbiddenAccessException
Can't fetch access_token.
I am not sure why is it going to OAuth2Listener.php line 79 when I am using basic driver.
I read another thread you mentioned that you were never able to make it work via oauth, but basic did work. BTW I am using the master branch as of today.

yeah... I tried but never succeed in using the oauth with bitbucket, so I ended up using user and password


Set limit for number of displayed associated persons per event

Each event is limited to showing 6 associated persons.
Example:

Closes #106

Codecov Report

Merging #231 into master will decrease coverage by 0.15%.
The diff coverage is 6.25%.

@@             Coverage Diff              @@
##             master     #231      +/-   ##
============================================
- Coverage     60.80%   60.65%   -0.16%
- Complexity      872      880       +8
============================================
  Files           140      140
  Lines          3238     3299      +61
  Branches        378      385       +7
============================================
+ Hits           1969     2001      +32
- Misses         1098     1125      +27
- Partials        171      173       +2

Impacted Files
Coverage Δ
Complexity Δ

src/main/java/seedu/address/ui/EventCard.java
0.00% <0.00%> (ø)
0.00 <0.00> (ø)

...ddress/logic/commands/events/EditEventCommand.java
73.07% <100.00%> (+0.26%)
14.00 <0.00> (ø)

src/main/java/seedu/address/model/event/Event.java
42.55% <0.00%> (-13.01%)
9.00% <0.00%> (-1.00%)

...ava/seedu/address/model/event/UniqueEventList.java
40.67% <0.00%> (-12.99%)
14.00% <0.00%> (+2.00%)
:arrow_down:

...ress/logic/commands/events/DeleteEventCommand.java
100.00% <0.00%> (ø)
9.00% <0.00%> (+1.00%)

.../logic/commands/contacts/DeleteContactCommand.java
100.00% <0.00%> (ø)
9.00% <0.00%> (+1.00%)

...ic/parser/contacts/DeleteContactCommandParser.java
100.00% <0.00%> (ø)
2.00% <0.00%> (ø%)

...rc/main/java/seedu/address/model/ModelManager.java
65.62% <0.00%> (+0.54%)
40.00% <0.00%> (ø%)

src/main/java/seedu/address/model/event/Time.java
63.82% <0.00%> (+0.78%)
15.00% <0.00%> (ø%)

... and 4 more

Continue to review full report at Codecov.

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


Multi-Homed VM KO, cpi error in mac addresses

I expected to vcloud CPI to support multi-homed VM.
https://bosh.io/docs/networks.html#multi-homed
https://bosh.io/docs/networks.html#cpi-limitations
My tests where unsuccessfull. Bosh Director gives 2 IP adress (ok on bosh vms), but the stemcell fails to configure the second NIC.
Having a look at the file /var/vcap/job/settings.json, I see that the 2 nics are set on the same MAC (whereas i have 2 distincts generated MACs, confirmed in vcloud portal).
For me its a blocker. I would be glad if you had any workaround.

I did previously open an issue on this point (maybe in a wrong location)
https://github.com/cloudfoundry-attic/bosh_vcloud_cpi/issues/16
Had no time to reproduce the issue, but its looking very similar (vcloud cpi, multi homed nics)

Moved issue to bosh-vcloud-cpi-release.


SDN-5186: Add OVNObservability feature gate as Tech Preview.

This feature is planned as Tech Preview in 4.17
https://issues.redhat.com/browse/OCPSTRAT-488

/approve
/lgtm

/retest

/retest


Alpha version

First quick and dirty version of the e57 python bindings including file reading functionality.

closed by #3


Non model definition for 2D Primitives (Circle, Rectangle...)

Description of the feature
Add a parameter in create_x 2d primitives to enable/disable model property. This is useful if the user wants to create a new primitive when the project is solved
Steps for implementing the feature
No response
Useful links and references
No response

Implemented


⚠ Bofrost.at has degraded performance

In 2fea9ac, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 2145 ms

Resolved: Bofrost.at performance has improved in 704d074.


Emmet: svg abbreviations dont work

Testing #11139

VSCode Version: 1.5.0- Insiders (dated 8/31)
OS Version: Windows 10

Steps to Reproduce:

Create svg file. Type gl and hit TAB

As per the abbreviations in lib/snippets.json#L892, gl should have expanded to <glyph>
Instead, it expands to <gl></gl>
Same result with other abbreviations for svg
Similarly, if you associate any language with svg syntax profile, you cannot get any abbreviations expansion.

This might be because the svg files are associated with xml language mode.
Other file types like haml, slim, sass, styl and stylus have plaintext as their language mode. But none of these have any extra abbreviations or snippets like svg. Therefore one can set xml or css as language mode for these file types to get xml/html emmet features.
But svg has loads of extra emmet abbreviations that we are losing out on.

@ramya-rao-a,
Unfortunately, we do not support SVG with Emmet.
VS Code used Emmet v1.3.1 (see package.json#L19), but support for SVG in Emmet was added in version (see emmet/6efa2234cd3a72a9bd1232fa79783a878d556107).
More details on this issue: https://github.com/Microsoft/vscode/pull/9002#issuecomment-234944128.

With #19655 we can now support svg abbreviations but only after mapping the current language mode to "svg" in emmet.syntaxProfiles setting.
We should investigate having svg as an embedded language like we do for html inside jsx

Closing this issue as there is no sufficient interest from the community in getting this done.
We can revisit if there is any interest in the future


add greeting of new team members

https://github.com/slackapi/node-slack-sdk/blob/master/lib/data-store/memory-data-store.js


Analyze and decide if we should integrate with greenkeeper.io

Reference: https://greenkeeper.io

Moved here: https://github.com/MitocGroup/run-jst/issues/15


Several fixes

Fixes #8553.
Fixes #8364.
Fixed problem with intersection node and getName error.

cc @nobuti @viddo (for the wait:true thing).

Frontend tests passing 🎉  💃


Wrong tab order on first try

It seems that tab-switcher activates only after user executes "tab-switcher:next" or "tab-switcher:previous" the first time. And only after activation tab-switcher starts to track the tab activation order. Therefore the first time you use tab-switcher after starting atom, it does not open the previous/next tab that you had active.

It can be fixed by removing activationComands entry from package.json.
Probably there is any reason to choose this lazy loading behavior, I have no idea.

The only reason is to try to be a "good citizen" and not add to the editor's startup time.
The package takes < 20ms to load for me, though and the only alternatives I can think of have shortcomings, so I'm going to merge @keskiju's PR.
Thanks for the contributions!


Add migration to populate company address fields

Description of change
This adds a data migration to populate company address fields from trading address or registered address whichever is defined.
Mainly for local environments as all other environments have been already updated using the temporary populate_company_address_fields celery task.
Checklist

[ ] Has a new newsfragment been created? Check changelog/README.rst for instructions
[ ] Have any relevant search models been updated?
[ ] Have any relevant fixtures (fixtures/test_data.yaml) been updated?
[ ] Have any relevant select-/prefetch-related field lists in the views and search apps been updated?
[ ] Has the admin site been updated (for new models, fields etc.)?
[ ] Has the README been updated (if needed)?

@elcct @marcuspp 🙏

@marcofucci Looks good to me. :+1:
Are you expecting the script to not find any companies that need updating on the Live platform. So this will run really quickly?

@marcuspp yep double-checked and no companies in prod


Add Carthage support

This PRs changed a lot of small things, but doesn't touch the code at all. So, to add Carthage support here what it changes:

New ISHLogDNA.Ixcworkspace which is containing:

ISHLogDNA.xcodeproj which has one shared scheme ISHLogDNA generating a ISHLogDNA.framework
ISHLogDNA Example.xcodeproj which contains the two sample apps

Following this, I have changed a bit the sources files organisation. Here a few screens:

I have one test failing, but still have to check if it's new or was already failing before.

Closing, now it's time for SPM


"prefer-function-over-method" should allow methods that are required to satisfy an interface

Bug Report

TSLint version: 5.7.0
TypeScript version: 2.4.2
Running TSLint via: CLI

TypeScript code being linted
interface SomeInterface {
  someMethod: () => void;
}

class Impl implements SomeInterface {
  someMethod(): void {
    return;
  }
}

with tslint.json configuration:
{
    "rules": {
        "prefer-function-over-method": true
    }
}

Actual behavior
ERROR: test.ts[6, 3]: Class method does not use 'this'. Use a function instead.
Expected behavior
TSLint should pass, because extracting this method into a function would cause the class to no longer satisfy the interface.
I know you can add the "allow-public" config, which would allow this to pass, but I want to catch other public methods that aren't required by interfaces.

Will this pass?
interface ISomeInterface {
    doSomething: () => void;
}

export class SomeClass implements ISomeInterface {
    public doSomething: () => void = foo;
}

export function foo(): void {
    // ...stuff
    return;
}

Doesn't seem too bad. And the rule in question is for those who want to use the function syntax whenever possible after all.

I have run into this as well.  I think the workaround in the previous comment is clever, but my preference for overrides (both public and protected) is to keep them in the class.  I think the aliasing technique makes the code a little harder to read.  I use the rule to detect helper methods that should be functions, not "all methods that could be functions".
So, my preference would be to make the change as requested by @treythomas123.  If there are people who prefer the aliasing technique, then an acceptable plan B would be to add an allow-override config option.

allow-override is a great idea

@ajafff I'm interested in your opinion here.  You wrote this line in preferFunctionOverMethodRule.ts:
// TODO: handle the override keyword once it lands in the language

Is it necessary to wait for the override keyword - is it possible to detect a matching signature in a parent class or interface?  If so, should such methods always be exempt, or should a config option be necessary?

Any update on this? My current work around is to use allow-public, but I would rather this.

@rope-hmg no update other than #4534. This issue will be closed soon if no PR is sent to address it. If you have the time, that'd be swell!

☠ TSLint's time has come! ☠
TSLint is no longer accepting most feature requests per #4534. See typescript-eslint.io for the new, shiny way to lint your TypeScript code with ESLint. ✨
It was a pleasure open sourcing with you all!

🤖 Beep boop! 👉  TSLint is deprecated 👈 (#4534)  and you should switch to typescript-eslint! 🤖
🔒 This issue is being locked to prevent further unnecessary discussions. Thank you! 👋


How to get raw data from  VideoFrameMut or VideoFrame

Hello, I want use raw data to render, How to get VideoFrame.ptr pointer data?

I just learned rust,  So can I get data from  ‘VideoFrame.planes()；?  I don’t know how to receive its return value

another question ： I want to add h264 raw data to Packet, but the Packet don't offer change data length usize.

I want use raw data to render, How to get VideoFrame.ptr pointer data?

You don't need the pointer to the video frame to access/modify frame data. You can simply use the planes() or planes_mut() methods on VideoFrame or VideoFrameMut.

So can I get data from ‘VideoFrame.planes()；? I don’t know how to receive its return value

The return value is a list of picture planes (it can be dereferenced to a slice). The number of planes and their size depends on the pixel format. For example, there will be three planes for the RGB pixel format but only one for the grayscale pixel format. The VideoFrame is immutable, so you cannot get a mutable reference to any of its planes and you cannot modify the picture data. If you need to crate your own frames with your own picture data, you'll have to use VideoFrameMut.

I want to add h264 raw data to Packet, but the Packet don't offer change data length usize.

All packets are immutable. If you'd like to add anything to your packets or create your own packets, you'll have to use PacketMut.

thank you so much for this issue. :)


ShippingAddressCheckoutAction component

 Component
Overview / Summary
Summary description of UI component
This is the first component that will define the ActiveCheckoutAction spec.
The CheckoutActions component will not know anything about this component other than that it fulfills the ActiveCheckoutAction spec and it is necessary to show for fulfillment groups of the "shipping" type. (Other future fulfillment types might be "download" or "pickup", for example, which would not require the component to be shown.)
So what is the ActiveCheckoutAction spec? Any component that wants to be used as an active checkout action must:

Accept a FulfillmentGroup object in a fulfillmentGroup prop. (Expect a shape that matches the GraphQL spec for FulfillmentGroup.)
If FulfillmentGroup.data is not set, show an appropriate form for setting it.
If FulfillmentGroup.data is set, show an appropriate form for editing it.
Have an instance method named renderActionCompleteContent that returns an element to be used as the content prop of the completeStepElement. (See CheckoutAction component.)
Accept an onReadyForSaveChange func prop, which it calls with true or false as the only argument whenever it becomes ready or not ready for the parent to show a "Save and continue" button.
Accept an isSaving prop and disable the form fields and show some "saving" state whenever it's true.
Provide a getFulfillmentData method on the instance, which the parent will call while isSaving is true. This should return a Promise that resolves with the current object to be saved to the data prop of this fulfillment group.

Specifically for this component (this "shipping" one):

(Some of this may required small adjustments to AddressForm component.)
Expect fulfillmentGroup.data to be an object with one prop, shippingAddress
getFulfillmentData will return { address: theAddressObject }, where it will get theAddressObject by calling submit method on the AddressForm component.
Currently, it will always render AddressForm component, passing along the fulfillmentGroup.data.shippingAddress prop as the address of that form. (Note that eventually it will accept an account and render an AddressBook component if the account is provided.)
Disable the form fields whenever the isSaving prop is true
renderActionCompleteContent should return the formatted multi-line shipping address div as per the designs
Call onReadyForSaveChange with true when mounted. This is for future use and does not need to be called again for now.

Where should this component live
This component should be created in the Component Library.
Expected use cases
This component will be used within the CheckoutActions component on the Checkout page.
Images / Designs of UI component in context
These are static images and should not be relied upon as the final version of the designs as they will not get updated when Zeplin is updated.
// Pseudo-markup for the render function
<AddressForm address={this.props.fulfillmentGroup.data.shippingAddress} >

Data
Props
propTypes: {
  fulfillmentGroup: PropTypes.shape({
    data: PropTypes.shape({
      shippingAddress: PropTypes.object
    })
  }).isRequired,
  isSaving: PropTypes.bool,
  onReadyForSaveChange: PropTypes.func
}

Data Fetching
None. All data comes from props.
State Store
It should be unnecessary to store any state in the component. Pass everything through to AddressForm (which wraps a ReactoForm) and let that handle it.
Routing / Query String
Not directly connected to any route or query string.
Render Criteria
Currently will always render a single AddressForm
Breakpoints
N/A No additional UI
Theme
N/A No additional UI
UI States
N/A No additional UI
Tests / Requirements

When fulfillmentGroup.data.shippingAddress prop is set, it should show up for editing.
When first mounted, it should call onReadyForSaveChange prop once with true.
When getFulfillmentData method is called, it should return { address: theAddressObject } with the correct address based on what is on the form, or show field errors if anything is invalid.
When the isSaving prop is true, it should disable the form fields
When renderActionCompleteContent method is called, it should return the formatted multi-line shipping address div as per the designs.

:tada: This issue has been resolved in version 0.23.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Use circular-json to serialize/deserialize objects

I came into this before in one of my projects, this library seems to solve this nicely.

Thank you! I intended to use a library I had seen some time ago that had support for a lot of things, but for now circular-json will do the job.


SPARKC-280: Added FunctionCallRef

Added FunctionCallRefclass as subtype of ColumnRef whose goal is to represent functions selections.
https://datastax-oss.atlassian.net/browse/SPARKC-280

Would be nice if anyone merge this PR!

Looks good! Would be merged?

Nice, I hope this get's merged

I'm also interested in this PR to be merged

Would be great to merge this PR!

Need add some tests.

If Cassandra supports nested UDFs, we need consider it as well.

@alexliu68 Concerning nested UDFs, it has not been checked but I've tested it with built-in functions nested calls such as dateOf(now()) and it works.

I'm +1, just squash it a little bit so we don't have so many commits :) @alexliu68 any other thoughts?

@RussellSpitzer @alexliu68 Squashed as the universe was 13799*10^9 years ago :wink:

Checked with Alex and He is +1 as well, merging Thanks @pfcoperez !


Use backslash instead of forward slash

This runs and passes the rule test with the fixed backslash method
There's a separate pull request to SRL-JavaScript repo to fix the backslash and carriage returns methods

Is it ok? SimpleRegex/SRL-JavaScript#14 depends on it. @KarimGeiger

Sorry, I did miss that. Yes, of course, that's absolutely correct.


Scroll bar is visually bigger than the draggable area

I think it's the opposite way around 😄 but it should be fixed by e69682195e581ef7974916f90054082ba2992332. Thank you for taking the time to raise an issue, please tell me if you still experience this 👍


Format resource log kwargs (#2791)

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

Merged into branches iso4 in adf5e0a348c37d8553fbefef92fcec75c4678c59


Support for Multiple pipelines

Describe the feature:
As per https://www.elastic.co/blog/logstash-multiple-pipelines we can use pipelines.yaml to configure multiple pipe lines in one logstash instance. It would be great to know, if this is already supported or can be incorporated in to the helm chart for logstash.
Describe a specific use case for the feature:
The use case for me, is to configure multiple inputs and filters. With all the logs been sent to one output (elastic cloud). I am trying to set this up using the helm chart and finding it complex to achieve.
Any help, will be greatly appreciated!

I'm also interested in this feature 👋

I assume you can achieve this by using logstashPipeline

I assume you can achieve this by using logstashPipeline

This can be used to define different pipelines which will create new files in /usr/share/logstash/pipeline/. However to make sure this becomes effective you still need to update pipelines.yml with the pointers to these new pipeline files, this does happen by default.

+1

You can configure multiple pipelines as follows:
  logstashConfig:
    pipelines.yml: |
      - pipeline.id: beats-server
        path.config: "/usr/share/logstash/pipeline/beat-server.conf"
      - pipeline.id: weblog-processing
        path.config: "/usr/share/logstash/pipeline/weblog-processing.conf"
      - pipeline.id: syslog-processing
        path.config: "/usr/share/logstash/pipeline/syslog-processing.conf"
      - pipeline.id: fallback-processing
        path.config: "/usr/share/logstash/pipeline/fallback-processing.conf"

  # Allows you to add any pipeline files in /usr/share/logstash/pipeline/
  logstashPipeline:
    beat-server.conf: |
      input {
        beats {
          port => 5044
        }
      }
      output {
          if [type] == apache {
            pipeline { send_to => weblogs }
          } else if [type] == system {
            pipeline { send_to => syslog }
          } else {
            pipeline { send_to => fallback }
          }
      }
    weblog-processing.conf: |
      input { pipeline { address => weblogs } }
      filter {
         json {
           source => "message"
         }
      }
      output {
        elasticsearch { hosts => ["http://elasticsearch:9200"] }
      }
    syslog-processing.conf: |
      input { pipeline { address => syslog } }
      filter {
         json {
           source => "message"
         }
      }
      output {
        elasticsearch { hosts => ["http://elasticsearch:9200"] }
      }

    fallback-processing.conf: |
      input { pipeline { address => fallback } }
      output { elasticsearch { hosts => ["http://elasticsearch:9200"] } }

This issue seems duplicate of https://github.com/elastic/helm-charts/issues/746

Thanks!
On Mon, Mar 7, 2022 at 3:35 AM Vishrant Gupta @.***>
wrote:

This issue seems duplicate of #746
https://github.com/elastic/helm-charts/issues/746
—
Reply to this email directly, view it on GitHub
https://github.com/elastic/helm-charts/issues/1282#issuecomment-1060102957,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AG5CDS3B74YF3MX6LWEMSB3U6VMNTANCNFSM5AAOETZA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you commented.Message ID:
@.***>


rename pubkeys_to_unref

Problem
recently we changed to unref shrinking and packing pubkeys after we have committed to shrink/pack
Summary of Changes
rename to match
Fixes #

sorry - accidentally force pushed an unrelated change


Wrapper gems may need to wrap multiple underlying APIs

An example is monitoring dashboard, which is a separate api (with a separate version) from the monitoring API, but really shouldn't be. We are going to use a single wrapper for both, which means we need to make sure we can provide factory methods for both.

This is turning out to be a pain, the root of which is that a microgenerator is designed to be used for exactly one API. We're going to do this in synth for now (for Monitoring)

We'll need a more general solution for this at some point. Looks like we're going to have another case of this with Cloud Workflows.

Found a solution involving using the OwlBot postprocessor to assemble a compound wrapper from multiple generated wrappers.


StreamingAead and RustCrypto aead::stream module

FYI, there's an open PR to add a stream module to the RustCrypto aead crate which StreamingAead could potentially benefit from:
https://github.com/RustCrypto/traits/pull/436
In particular I think it'd be nice if rage and tink-rust could potentially share code, particularly around things like async and/or parallel stream readers/writers.
Anyway, heads up we're working on some common abstractions for this sort of thing and would love your input, in particular if you think it would be helpful for things like StreamingAead, and if you have any concerns about the proposed design.
I think age and Tink (in all forms) might also use a common "flavor" of STREAM, although I haven't confirmed that.
Sidebar: STREAM isn't actually OAE2, but rather "nonce-based OAE" (nOAE). CHAIN is required for OAE2. (Edit: I now see the noncebased streaming module, never mind)

I'd be very happy if tink-rust could defer the cryptographic heavy lifting to another (RustCrypto) crate for StreamingAead, same as it does for ≈ all the other primitives!
However, (as you say) it would depend on everything needing/using the exact same variants, and I've not yet looked into the details either.  (To put it another way: I'd like the Tink cross-language tests to keep passing.)
BTW, did you see https://eprint.iacr.org/2020/1019.pdf?  The intro includes a helpful description of Tink's adaptation of STREAM.

Upon examining Tink it appears to use the original Rogaway paper definition of STREAM, which is definitely something worth supporting.
I can and should add support for it to https://github.com/RustCrypto/traits/pull/436, which otherwise implements a slightly different version with a small optimization/ergonomics improvement, but that's why it defines the StreamPrimitive trait to allow different "flavors" of STREAM which can enable higher-level things like parallel and/or async encryptors/decryptors to be generic over STREAM "flavors".

BTW, did you see https://eprint.iacr.org/2020/1019.pdf? The intro includes a helpful description of Tink's adaptation of STREAM.

Nice writeup, thanks!
It appears Tink operates at a much higher level and defines its own STREAM framing, in addition to specifying STREAM "ciphersuites" which use HKDF to derive a STREAM-specific key.
That's all well and good and for the best. That said, the traits and implementations thereof in RustCrypto/traits#436 are much, much lower-level and I think should fit within Tink's framework just fine.


[Event Request] codeunit 6620 "Copy Document Mgt." - OnAfterCopySalesDocForCrMemoCancelling

Could you please add the following event?
procedure CopySalesDocForCrMemoCancelling(FromDocNo: Code[20]; var ToSalesHeader: Record "Sales Header")
begin
    CopyJobData := true;
    SkipWarningNotification := true;
    InsertCancellationLine := true;
    OnBeforeCopySalesDocForCrMemoCancelling(ToSalesHeader, FromDocNo, CopyJobData);

    CopySalesDoc("Sales Document Type From"::"Posted Credit Memo", FromDocNo, ToSalesHeader);
    InsertCancellationLine := false;
    //+EVENT
    OnAfterCopySalesDocForCrMemoCancelling(FromDocNo, IncludeHeader, RecalculateLines, MoveNegLines, CreateToHeader, HideDialog, ExactCostRevMandatory, ApplyFully, SkipTestCreditLimit, SkipCopyFromDescription, ToSalesHeader);
    //+EVENT
end;

[IntegrationEvent(false, false)]
local procedure OnAfterCopySalesDocForCrMemoCancelling(FromDocumentNo: Code[20]; IncludeHeader: Boolean; RecalculateLines: Boolean; MoveNegLines: Boolean; CreateToHeader: Boolean; HideDialog: Boolean; ExactCostRevMandatory: Boolean; ApplyFully: Boolean; SkipTestCreditLimit: Boolean; SkipCopyFromDescription: Boolean; var ToSalesHeader: Record "Sales Header")
begin
end;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 52831.


DendoPort

Hello,
I'm curious because I have no clue what is DendoPort ?
Thnaks

we made up DendoPort. :smile: we added one fake one in case someone might put "full understanding" for all of them without really understanding what the terms meant.
but we've gotten so many questions about it, that I think now we're going to need to release something named DendoPort! :shipit:

Ohhhh youuuuuuu ^_^

Hmm. That makes me to have full understanding about what the DendoPort is..... I think I'll cheat this time and choose "no understanding" instead :D

But… now I've read this, I do have a full understanding of DendoPort!

Oh, Google, you're so Sassy. I put "little understanding" because all I knew was that it didn't exist. :D

Wait, now that I know what a DendoPort is.. should I mark full understanding from now on???


Check links before starting the site

Can we have it where if links are known to be bad, that when you run yarn start to run a site, it fails with a bad links message?

Maybe textlint and friends described in https://github.com/facebook/Docusaurus/issues/210 could fix this?

Probably, correct link is https://github.com/facebook/Docusaurus/pull/302

Oh right. Nice catch. I updated my comment :)

I think linting should be done via user side. It's not nice to crawl & check for external link.

Not saying we shouldn't close this necessarily -- but I think this was in reference to internal links within the docs. To make sure we didn't type anything bad in xxx or something.

I think i missed that. We could file a new issue if needed 😊. Old issue like this usually isnt seen by contributor, so new issue can kinda bump things up

Sure. Let's file a new issue.


getValueOf keyName  filename

{{getValueOf  "key" "fileName"}}
If the file is not present, silently create the file. That is call the API response, write the file.

The std output for this should be silent, otherwise, it risks polluting the terminal.

Handle situations where concurrent threads are writing the same file.
Users should be able to provide the exact or fuzzy path to the value they need.

For example ``{{getValueOf  "staging.auth2.id_token" "client_auth"}}`

Solve the circular dependency

Chat GPT comes to the rescue.

Extract Common Logic:
•	Move shared functionality (SubstituteVariables, ReadYamlForHttpRequest) to a new package (e.g., shared or utils).
•	Ensure yamlParser, envParser, and apiCalls depend on this new package but not on each other.

shared
├── SubstituteVariables
├── ReadYamlForHttpRequest

Use Dependency Injection:
•	Pass the required functionality (e.g., envMap) explicitly to yamlParser or apiCalls, instead of having them directly call envParser functions.
3.	Refactor yamlParser and envParser:
•	Ensure yamlParser doesn’t directly depend on envParser.
•	Replace direct calls with function arguments or interfaces.
Example:

func ReadYamlForHttpRequest(envMap map[string]string) {
    // Logic
}

Ensure apiCalls Doesn’t Call Both:
•	If apiCalls must use both yamlParser and envParser, route calls through a single point, like main.
Decouple Test Imports:
•	Ensure tests (_test.go) don’t import across these modules, as this can create cycles.
Check for Indirect Imports:
•	Use go mod graph to identify indirect imports and reorganize dependencies.


Document that Boolean attributes should never be initialized to true if they should be configurable from markup

Context
This is an area of confusion and we don't have clear documentation on lit.dev relating to this case.
Initializing a boolean attribute to true results in confusing behavior, as you cannot declaratively remove the attribute that has been defaulted to true from markup.
Proposal
Add a warning or note to https://lit.dev/docs/templates/expressions/#boolean-attribute-expressions stating that boolean attributes should never be default initialized to true.
References
This has been discussed in the past:

Kevin's comment: https://github.com/Polymer/polymer/issues/1812#issuecomment-112226630
Link to polymer documentation that explains the same issue: https://polymer-library.polymer-project.org/2.0/docs/devguide/properties#configuring-boolean-properties

Out of scope of this issue, but maybe this can be caught by the analyzer

This just came up in a chat conversation today, as well. I think it's really more apropos to the Reactive properties section, because it's really about the attribute API of a given component. We don't really talk much about API patterns at the moment.


[Issue]: 6.3.0 source archive was modified after release

Problem Description
Hi,
Our user detected that rocm-6.3.0.tar.gz archive changed the checksum.
On further investigation comparing to https://github.com/ROCm/Tensile/commits/rocm-6.3.0 I see that 2 different archives https://github.com/ROCmSoftwarePlatform/Tensile/archive/rocm-6.3.0.tar.gz were released:

On Dec  7 downloaded archive had size 12724464 bytes
On Dec 17 downloaded archive has size 12724004 bytes and contains 3 extra commits https://github.com/ROCm/Tensile/commit/5838cf77c4554fcdd18fe633027f4c5d69c2f656 https://github.com/ROCm/Tensile/commit/000e50346a9d8e3f56631d09ecac916dad4bf068 https://github.com/ROCm/Tensile/commit/aca95d1743c243dd0dd0c8b924608bc915ce1ae7

Since source code archives are checksummed, distributed across mirrors of many distributions, and provide specific functionality (which was changed in these 3 commits), could you please release a patch release (with a common release procedure, so that maintainers are notified about these changes) next time instead of reattaching an existing tag to a different commit? Thanks!
Operating System
Gentoo
CPU

GPU

ROCm Version
ROCm 6.3.0
ROCm Component
No response
Steps to Reproduce
No response
(Optional for Linux users) Output of /opt/rocm/bin/rocminfo --support
No response
Additional Information
No response

Hi @AngryLoki. Internal ticket has been created to assist with your issue. Thanks!

@AngryLoki Thanks for your issue. I am the one who promoted those commits to the ROCm 6.3.0 release and want to confirm that this is very much a one-off update that we had to weigh the trade-offs for. In this case, those three commits were included downstream in the 6.3.0 release of rocBLAS, so we had to reconcile the releases. Since patch releases are also cadenced in the ROCm stack, I couldn't just issue a patch release. This type of update is highly atypical and wasn't made without consideration, we apologize for any impact it had on your users. Going forward, our staging and release branches will be updated properly and you shouldn't see this type of problem again.

Thank you for response!
Closing as issue requires no action since 6.3.1 release.


Add kustomize 2.0.1

Does this fit in the main bucket or should I try the extras bucket?

Yup, most of the CLI tools go in the main bucket. :smile:👍