Fix IPV6 inbound traffic mangling on iptables

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: douglas-reid
Assign the PR to them by writing /assign @douglas-reid in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

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

@myidpt: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e.sh
737456a63c0f018eec21c24476d4fb2335910dcc
link
/test istio-pilot-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@myidpt: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e.sh
737456a63c0f018eec21c24476d4fb2335910dcc
link
/test istio-pilot-e2e

prow/e2e-bookInfoTests.sh
737456a63c0f018eec21c24476d4fb2335910dcc
link
/test e2e-bookInfo

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@myidpt: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e.sh
737456a63c0f018eec21c24476d4fb2335910dcc
link
/test istio-pilot-e2e

prow/e2e-bookInfoTests.sh
737456a63c0f018eec21c24476d4fb2335910dcc
link
/test e2e-bookInfo

prow/istio-pilot-e2e-envoyv2-v1alpha3.sh
737456a63c0f018eec21c24476d4fb2335910dcc
link
/test istio-pilot-e2e-envoyv2-v1alpha3

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@myidpt: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e.sh
737456a63c0f018eec21c24476d4fb2335910dcc
link
/test istio-pilot-e2e

prow/e2e-bookInfoTests.sh
737456a63c0f018eec21c24476d4fb2335910dcc
link
/test e2e-bookInfo

prow/istio-pilot-e2e-envoyv2-v1alpha3.sh
737456a63c0f018eec21c24476d4fb2335910dcc
link
/test istio-pilot-e2e-envoyv2-v1alpha3

prow/e2e-simpleTests.sh
737456a63c0f018eec21c24476d4fb2335910dcc
link
/test e2e-simple

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


Corrected the import command in readme

What is the purpose of this change? What does it change?
Corrected the incorrectly mentioned oc import to oc import-image in the custom builder readme section
Was the change discussed in an issue?
No
How to test changes?
No need to test the changes

LGTM!

(this PR is also a good test to see if the docs sync)

docs change, test are failing for other reasons


Resolving #2571 UI: Added preventing page zoom change.

Sequel of https://github.com/webaverse/app/pull/2706
Meta & CSS params added to prevent zoom by pitch on touchpad.
JS code to prevent zoom by pitch on Mac touchpad [only this can prevent zooming on mac from my experiments].

no obvious code issues, can be moved to manual QA

@avaer using the wheel event seems to be the preferred way to address this for apple devices
https://bugs.webkit.org/show_bug.cgi?id=145214
and webkit has explicitly disabled user-scalable=no
https://webkit.org/blog/7367/new-interaction-behaviors-in-ios-10/

using the wheel event seems to be the preferred way to address this for apple devices

Does it require locking the event to the main thread for all browsers?

using the wheel event seems to be the preferred way to address this for apple devices

Does it require locking the event to the main thread for all browsers?

Can you explain ? this is not a complex operation in any way and won't be blocking anything.

Can you explain ? this is not a complex operation in any way and won't be blocking anything.

passive: false changes when and how the event is handled (it will block the frame loop).

Can you explain ? this is not a complex operation in any way and won't be blocking anything.

passive: false changes when and how the event is handled (it will block the frame loop).

without 'passtive: false' it won't work. it's the way it works.
no not-passive - no fix.

Ok, I guess we can't fix this in that case.


BaseCameraLogic unhandled nullpointer exception on Android

I put the GoogleMaps view in a page, which works correctly on normal behaviour.
However, when this page gets opened, and the back button is pressed immediately after opening this page (so the GoogleMaps view isn't fully rendered yet) the app crashes with the following stacktrace:
09-06 12:50:37.602 I/MonoDroid(20835): UNHANDLED EXCEPTION: 09-06 12:50:37.616 D/Mono    (20835): [0x8027f920] hill climbing, change max number of threads 5 09-06 12:50:37.644 I/MonoDroid(20835): System.NullReferenceException: Object reference not set to an instance of an object. 09-06 12:50:37.644 I/MonoDroid(20835):   at Xamarin.Forms.GoogleMaps.Logics.BaseCameraLogic1[TNativeMap].Register (Xamarin.Forms.GoogleMaps.Map map, TNativeMap nativeMap) [0x00021] in <7082e972b6b544548493ccf32d1392ba>:0
09-06 12:50:37.644 I/MonoDroid(20835):   at Xamarin.Forms.GoogleMaps.Android.MapRenderer+d__20.MoveNext () [0x00351] in <33f480a5aa3448b39a955c15f6587f42>:0
09-06 12:50:37.644 I/MonoDroid(20835): --- End of stack trace from previous location where exception was thrown ---
09-06 12:50:37.644 I/MonoDroid(20835):   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000c] in <3fd174ff54b146228c505f23cf75ce71>:0
09-06 12:50:37.644 I/MonoDroid(20835):   at System.Runtime.CompilerServices.AsyncMethodBuilderCore+<>c.b__6_0 (System.Object state) [0x00000] in <3fd174ff54b146228c505f23cf75ce71>:0
09-06 12:50:37.644 I/MonoDroid(20835):   at Android.App.SyncContext+<>c__DisplayClass2_0.b__0 () [0x00000] in :0
09-06 12:50:37.644 I/MonoDroid(20835):   at Java.Lang.Thread+RunnableImplementor.Run () [0x00008] in :0
09-06 12:50:37.644 I/MonoDroid(20835):   at Java.Lang.IRunnableInvoker.n_Run (System.IntPtr jnienv, System.IntPtr native__this) [0x00008] in :0
09-06 12:50:37.644 I/MonoDroid(20835):   at (wrapper dynamic-method) System.Object:2c372093-ec2c-4298-96ca-2e6a00e5ed04 (intptr,intptr)
09-06 12:50:37.654 W/art     (20835): JNI RegisterNativeMethods: attempt to register 0 native methods for android.runtime.JavaProxyThrowable
09-06 12:50:37.659 D/Mono    (20835): DllImport searching in: '__Internal' ('(null)').
09-06 12:50:37.659 D/Mono    (20835): Searching for 'java_interop_jnienv_throw'.
09-06 12:50:37.659 D/Mono    (20835): Probing 'java_interop_jnienv_throw'.
09-06 12:50:37.659 D/Mono    (20835): Found as 'java_interop_jnienv_throw'.
09-06 12:50:38.535 E/mono    (20835):
09-06 12:50:38.535 E/mono    (20835): Unhandled Exception:
09-06 12:50:38.535 E/mono    (20835): System.NullReferenceException: Object reference not set to an instance of an object.
09-06 12:50:38.535 E/mono-rt (20835): [ERROR] FATAL UNHANDLED EXCEPTION: System.NullReferenceException: Object reference not set to an instance of an object.
`

It is difficult to reproduce it for me.
Can you make sample app for reproduce?

Maybe same as #352 and fixed it.


Consider assignments in ng-repeat expressions

This patch takes expressions like the following into account:
dir-paginate="item in filteredItems = (items | myFilter:searchValue | itemsPerPage:10)"

Without the fix the parenthesis at the end gets removed creating an invalid expression.

Hi,
Somehow this PR got lost on me. Sorry for the lack of response. Did you happen to run it through the unit tests to see if it breaks anything?

No problem ;)
Yes, the karma tests are still passing.

With this fix something like this:
dir-paginate="item in items | itemsPerPage: vml.getPageSize()"

not working.

@Karql thanks for the report. Just made a fix that sorts this issue out. Will be publishing a new package release soon.


"Stop writing due to not yet connected to Stream Manager." in local mode

Any help are appreciated.
I run example in local mode, my environment is

jdk 7
redhat 5.7
24 cpu core/ 96 g memory

My operation follow http://twitter.github.io/heron/docs/getting-started/

install client/tool/core
start example
start tracker/ui

I didn't modify any configuration
then check the example's log, every container/excutor/log just show
[2016-05-26 16:07:13 +0800] com.twitter.heron.network.StreamManagerClient INFO:  Stop writing due to not yet connected to Stream Manager.
[2016-05-26 16:07:13 +0800] com.twitter.heron.network.StreamManagerClient INFO:  Stop reading due to not yet connected to Stream Manager.
[2016-05-26 16:07:13 +0800] com.twitter.heron.network.StreamManagerClient INFO:  Stop writing due to not yet connected to Stream Manager.
[2016-05-26 16:07:13 +0800] com.twitter.heron.network.StreamManagerClient INFO:  Stop reading due to not yet connected to Stream Manager.

You probably need rebuild it on centos (there is a building guide) then try deploying to rh.

Rebuild the source code is no problem.
But another question,  must Heron run on JDK8?

Short answer: yes.
Full answer:  We specified building heron with JAVA8 (so you have to run with JAVA8) due to twitter internal concerns. But heron is wirtten using only JAVA7 features, so people can build it with JAVA7 and run with JAVA7.

To be precise -

Building Heron requires Java JDK8
For writing topologies and running them - JDK7 is sufficient.


Crash when using OpenSplice and selecting a wrong topic

When using OpenSplice as DDS implementation RViz crashes as soon as one selects a topic containing an invalid message type.
E.g. it crashes when selecting the /clock topic in the Marker Display.
The issue seems to be located in OpenSplice itself (according to the log output).
However, we should probably catch this error in RViz.

the https://github.com/ros2/rmw_opensplice repository was archived, this issue is outdated


Does one need to reset Metrics during the end of epoch in Lightning 1.0.3

❓ Questions and Help
Before asking:

What is your question?
Given the new metrics in 1.0.0 and later (which I really like!), I have three accuracy metrics for training, validation and test initialized in __init__ function. Do I need to reset them at the end of training and validation epoch given they will be used multiple times?
Code

What have you tried?
What's your environment?

OS: [e.g. iOS, Linux, Win]
Packaging [e.g. pip, conda]
Version [e.g. <IP_ADDRESS>]

Depends on how you are using the metrics. In general if the .compute()method is called the internal state is reset. This means that if you call .compute() in the end off the epoch you should be fine. If you are using metrics in combination with self.log, then setting on_epoch=True will also internally call . compute() at the end of the epoch.

@SkafteNicki Thanks for the information. This has been very useful.

I'd like to get the validation accuracy over the entire validation data and I have seen some strange results on it with DDP. I want to make sure I am doing the right thing with metrics with DDP. Below is my psedu-code:
def __init__(self):
    self.val_acc = Accuracy(compute_on_step=False)

def validation_step(self, batch, batch_idx):
      input, y = batch[0], batch[1]
      logits = self(input)
      _, pred = torch.max(logits, dim=1)
     self.val_acc.update(pred, y)
     self.log('val_acc', self.val_acc, on_step=False, on_epoch=True)

Could someone tell if this implementation is to give me validation accuracy for the entire validation data? Thanks.

Yes that is the correct way.
Could you explain the strange results you are seeing in ddp mode?

I am facing similar issues with ddp. When computing F1 using Fbeta, if I use ddp, the results are not the same as running them in dp (in a single machine). To compare I use the same saved checkpoint. In my case the metric is computed in test_step_end:
def test_step_end(self, test_step_outputs):
def test_step_end(self, test_step_outputs):
    self.fbeta_test(test_step_outputs['y_hat'], test_step_outputs['y'])

without logging. And then in test_epoch_end:
def test_epoch_end(self, outputs: list):
    fbeta_test = self.fbeta_test.compute()

So I am not sure if in ddp is just averaging the metric across ranks instead of computing the metric over the whole dataset. It is worth saying that when computing the metric on test_epoch_end, the value fbeta_test it's the same across ranks. With dp the result is .5670 and with ddp it returns .6154. Running it on a single gpu with no dp returns the same value as dp (.5670), which I assume is the correct one.

@SkafteNicki  I am trying a new model with PyTorch Lightning and also with the new metrics in 1.0.3. The strange metric results in DDP may or may not be related to the new metrics. That's why I'd like to make sure I am doing the right thing with the new metrics. This helps me debug any issue that might be related to the new model. Thanks.

Thanks @LittlePea13 and @junwen-austin for both getting back to me.
It seems to me that there may be a problem with how metrics are aggregated in ddp mode. I will try to identify the issue and get back to you.

No problem @SkafteNicki. Let me know if I can help in any way, I tried to debug a bit but didn't get very far, I am quite new to ddp. And thanks for your work :)

@LittlePea13 could you try setting the dist_sync_on_step to Trueand see if it solved the problem?
If so then it have something to do with how buffer metric states.

@SkafteNicki I just tried and the result was still the same by declaring the metric as:
self.fbeta_test = Fbeta(num_classes=1, dist_sync_on_step = True)

Depends on how you are using the metrics. In general if the .compute()method is called the internal state is reset. This means that if you call .compute() in the end off the epoch you should be fine. If you are using metrics in combination with self.log, then setting on_epoch=True will also internally call . compute() at the end of the epoch.

Overwriting on_epoch_end allows computing metrics using all data, but there is no way to log those results (or even use it for model selection. It's because log_train_epoch_end_metrics is called right after the loop through batches and before on_epoch_end.
https://github.com/PyTorchLightning/pytorch-lightning/blob/b50dd12332bf83209d9535c8516486edc1a6b252/pytorch_lightning/trainer/training_loop.py#L608-L613

@hoanghng instead of using on_epoch_end could you use training_epoch_end? That should work with logging.

@SkafteNicki Thanks a lot. It works like a charm.

@SkafteNicki @hoanghng I feel like I missed something. Are you referring to metrics in ddp? I am using the *_epoch_end methods but still see different results with ddp.

@LittlePea13 this was just a question about which model methods that actually support logging

Metrics are not reset automatically on epoch end in DDP for me.
In LitModule init() I initialize MSE metric:
 self.train_mse = pl.metrics.MeanSquaredError()
Then in training step:
mse = self.train_mse.update(pred, target)
self.log('train_mse', self.train_mse, on_step=False, on_epoch=True)

In addition I print the mse of each batch manually.
By comparing both methods it seems that the logged MSE is an average of all epochs so far.
PL v1.0.7
pytorch v1.6.0

@itsikad I can confirm that it is not being reset correctly.
Could you open up a new issue, where you reproduce using boringmodel?

@SkafteNicki  is the reset not correct in DDP mode for all class metrics or just for this MSE? If this is for all, could one manually reset the metrics after compute() method at the end of the epoch to fix it for the time being? Thanks.

@SkafteNicki Done #4806

@junwen-austin I have really not investigated this enough yet, so I don't know how deep the rabbit hole goes. I suspect it is the same for all other metrics. Until solved, just call self.metric.reset() in training_epoch_end(). Let's keep further discussion in the new issue.

@itsikad @SkafteNicki  I took itskikad's colab notebook and made the following changes:
def training_step(self, batch, batch_idx):
        output = self.layer(batch)
        loss = self.loss(batch, output)
        self.metric.update(output, torch.ones_like(output))
        return {"loss": loss, "batch_mse": loss}

def training_epoch_end(self, outputs) -> None:
        avg_mse = self.metric.compute()
        self.log('mse', avg_mse, on_step=False, on_epoch=True)

        print(f'Sum squared error: {avg_mse}, Total samples: {self.metric.total}')

and now it works. Here is the link: https://colab.research.google.com/drive/1-NJKZ1hiXVCCirN7xsLmswf-zEyxVQIU?usp=sharing
essentially what I did is to update the metric in the train_step and then at the end of an epoch call compute explicitly and get the value of the metric and then pass on the value to the log. This might be a temp solution.

@junwen-austin
It works since you explicitly call .compute() (as I mention #4806). However, according to the documentation, it is unnecessary with self.log(...,on_epoch=True)


Brew audit --strict --online wget hangs with curl active

Please always follow these steps:

[x] Confirmed this is a problem with running a brew command and not brew installing or the post-install behaviour of one or more formulae? If it's a formulae-specific problem please file this issue at https://github.com/Homebrew/homebrew-core/issues/new
[x] Ran brew update and retried your prior step?
[x] Ran brew doctor, fixed all issues and retried your prior step?
[x] Ran brew config and brew doctor and included their output with your issue?

Please note we will close your issue without comment if you delete or do not fill out the issue checklist and provide ALL the requested information.
To help us debug your issue please explain:

What you were trying to do (and why)
What happened (include command output)
What you expected to happen
Step-by-step reproduction instructions (by running brew commands)

I was just learning about developing on homebrew and decided to run brew audit --strict --online wget on curl. This hung so I tried brew audit --strict --online curl, and no hang.  I expected it not to hang. (Reasonable I think). I let it run for 45 minutes, but no output was shown.
I am running macOS High Sierra 17A315i
Output of brew doctor and brew config:
Stevens-MacBook-Pro:~ steven$ brew doctor Please note that these warnings are just used to help the Homebrew maintainers with debugging if you file an issue. If everything you use Homebrew for is working fine: please don't worry and just ignore them. Thanks!
Warning: You are using macOS 10.13.
We do not provide support for this pre-release version.
You may encounter build failures or other breakages.
Please create pull-requests instead of filing issues.
Warning: Ruby version 2.3.3 is unsupported on 10.13. Homebrew
is developed and tested on Ruby 2.0, and may not work correctly
on other Rubies. Patches are accepted as long as they don't cause breakage
on supported Rubies.

Warning: Homebrew's sbin was not found in your PATH but you have installed
formulae that put executables in /usr/local/sbin.
Consider setting the PATH for example like so
  echo 'export PATH="/usr/local/sbin:$PATH"' >> ~/.bash_profile

Stevens-MacBook-Pro:~ steven$ brew config
HOMEBREW_VERSION: 1.3.0-31-g441bd37
ORIGIN: https://github.com/Homebrew/brew
HEAD: 441bd37fd03d3300c655eea1d206644a2718dce2
Last commit: 7 hours ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: 8a27cc46ba590d2db3771924b6e4dd0e1f4e23f8
Core tap last commit: 6 hours ago
HOMEBREW_PREFIX: /usr/local
HOMEBREW_REPOSITORY: /usr/local/Homebrew
HOMEBREW_CELLAR: /usr/local/Cellar
HOMEBREW_BOTTLE_DOMAIN: https://homebrew.bintray.com
CPU: octa-core 64-bit haswell
Homebrew Ruby: 2.3.3 => /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/bin/ruby
Clang: 9.0 build 900
Git: 2.14.0 => /usr/local/bin/git
Perl: /usr/bin/perl
Python: /usr/local/opt/python/libexec/bin/python => /usr/local/Cellar/python/2.7.13_1/Frameworks/Python.framework/Versions/2.7/bin/python2.7
Ruby: /usr/bin/ruby => /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/bin/ruby
Java: 1.8.0_144, 1.6.0_65-b14-468
macOS: 10.13-x86_64
Xcode: 9.0
CLT: <IP_ADDRESS>.1.1500650180
X11: N/A

What about with no --online? Do you have HOMEBREW_GITHUB_API_TOKEN set? If not, please set one and try again. Thanks!

With no --online it prints a blank line in ~9 seconds.
Stevens-MacBook-Pro:homebrew-cask steven$ time brew audit --strict wget

real	0m9.522s
user	0m5.288s
sys	0m1.574s
Stevens-MacBook-Pro:homebrew-cask steven$ time brew audit --strict curl

real	0m7.847s
user	0m3.141s
sys	0m1.390s

With --online I rantime brew audit --strict --online curl for a time of ~10 seconds
Stevens-MacBook-Pro:homebrew-cask steven$ time brew audit --strict --online curl

real	0m10.712s
user	0m3.568s
sys	0m1.560s

Tried brew audit --strict --online wget and it works today, any changes in brew:master?

No changes. It seems likely you tripped GitHub's rate limit and it was waiting for that to time out.


Why do we need idl files?

It doesn't look as there is any IPC going on, so interfaces could be done as well in c++, right? It's quite a pain to work, especially rebuild, with idl.

That's just how c++/WinRT works. In some future, we imagine shipping the TerminalControl as a nuget package that anyone could use to embed in their application. In that hypothetical future, c++/WinRT is going to be incredibly helpful to us, for enabling us to easily create C# projections of our types. So someone could write a C# application that uses the terminal, without needing a crazy Pinvoke projection.
By making the boundaries between our libraries well-defined in idl, that means that it's extra easy for someone else to swap out an implementation with one written in another language. For example, maybe someone in their hypothetical terminal application wants to create their own connection type, that they've written in C#. By defining the interface in idl, it makes it possible for us to consume the code they authored easily.
Much of the XAML code is pretty heavily dependent up on working with c++winrt anyways, so we need idl files to author XAML-y types even if we're not doing any IPCs.

So, just to speed up developement, could we convert these idls that are not XAML related to c++? They'd be pure virutal classes (interfaces), with a note that they might become idl one day, when that's actualy needed. Maybe also enforce a rule that these files can only expose winrt types (e.g. hstring instead of std::string).
Working with idls is far more painful than with c++, but I don't know if it's the right way to fix that.

I don't know why we'd do that. Seems to me like it'd be more work to convert the classes to pure c++ types, then back to winrt types than the productivity lost due to dealing with idl files.
What in particular about working with idl's is so painful? I'm sure @Scottj1s, @LarryOsterman and @kennykerr would be super interested.
I'll admit that I only started working with c++winrt and idl's just about a year ago, and while I'm not good at it now, I'm certainly a lot better than I used to be. It's one of those tech stacks that as you learn it, it'll be just as easy as working with pure c++.

Yea, syntax-wise they're very nice and clean. And they're based on C#, that I like a lot.
I ment the integration and build process:

When the file is changed (physically changed, like added a space), I have to delete some folders, usually Generated Files and obj, but this doesn't work all the time. And if it does, the build is much longer than it would be for c++. Alternatively I can rebuild whole solution.
Intelisense works only when these files are changed, but not always. Sometimes it happend that certain names were highlighted red even after rebuild for a while.
If there is an error across c++ and idl, it's hardly possible to deduct that error from the error message(s) the VS gives (not that they're particuarly clean in c++). They go into autogenerated files and something like base.h.
Debugging across the idl <-> c++ boundary is also not so fun, as you have go across few frames of autogenerated thunk-mess code. Same goes to stacktrace.

But since you seem not to have problems with this, I might be missing something.

FIrst off: Thank you for the comment about the syntax - I worked hard to make it clean and straightforward :).
Mike also left out one really important aspect of IDL (well, he touched on it, but I think it needs amplifying): C++ doesn't define a mechanism for stable binary contracts across binaries.
That means that if your component is built of multiple binaries (DLLs (or shared objects if you're a *nix person), you need to define an interoperability pattern for your DLLs. It turns out that this is true for ALL the interfaces into and out of a DLL: The only native language that has a standardized pattern is C, and C doesn't support modern constructs like C++ classes, which is a huge implementation barrier.
And before you ask: Nope, C++ doesn't have any cross binary interoperable construct. It's true that by convention, most of the existing C++ compilers use similar calling conventions, but it's not guaranteed by the standard - it's just because the compiler vendors decided to choose the same binary contract. This is especially true when you deal with C++ constructs like exceptions - there is no stable binary contract for exceptions, even across different versions of the same compiler. So whenever an exception is thrown within a DLL, it must be caught within the DLL and turned into some construct which is stable across binaries (like an HRESULT or status code). This is also why marking a function "noexcept" causes the C++ runtime to abort() your process if an exception crosses a DLL boundary.
By careful design, the binary contract defined by IDL's is based on C structures containing pointers to functions and that binary contract IS stable over both time and across compiler versions (because the C standard lays out rules of how structs are laid out and the calling convention of the processor define how parameters to functions are laid out. And because it's C, tricky constructs like "this" aren't an issue).
So if your component has ANY DLLs, it becomes incredibly helpful to define your types in terms of COM/WinRT classes - that allows you to keep the C++ features most developers desire and still have binary interoperability.
And of course, WinRT enables cross language projections (as Mike mentioned above). That means that you can write console apps in C# as well as C++.
Ok, enough ranting about stability of binary contracts (you can tell it's a subject I care about a lot :)). Now to your other issues...
It appears that many/most of your issues are related to the fact that VS doesn't really treat IDL (and the C++/WinRT authoring experience) as a first class citizen, especially as compared to C++ or C#. I know that the C++/WinRT team has been working tirelessly with the VS team to improve the authoring experience, @Scottj1s is the primary author of that experience and may have more information.

So, do we need dlls, now?
(And isn't it that c++ doesn't define abi only beyond the things shared with C?)

"Do we need DLLs now"? That depends on how much pain and suffering you want to inflict on your customers. Let me tell you a little story about what happens without DLLs. It's ancient history, so I think I can tell it now (there are countless other examples of this, especially in the *nix/OSS world btw).
About a decade ago, Microsoft was informed of a rather nasty security vulnerability in some code. Normally this isn't a huge deal. We recompile the offending binary with the fix for the security vulnerability, drop it onto Windows Update and we're good to go. But this vulnerability was different. It was in a template library which Microsoft shipped for more than a decade before anyone noticed the vulnerability.
And that template library was embedded in literally hundreds of thousands of customer applications. ALL of which had to be either patched or blacklisted before we could be confident that the vulnerability was fixed. Just finding and fixing the vulnerable Microsoft applications took years and was a huge effort. Fortunately the finder was patient and understood the magnitude of the problem and we were able to apply appropriate mitigations. But it was a massive undertaking.
shared objects provide an extremely convenient servicing boundary - if there's a bug/vulnerability in a DLL/so, you can recompile the DLL and push it out via your platform's servicing mechanisms. Now they're not perfect - last weeks hubub about VLC is a great example of how not correctly servicing bugs can wreak havoc on customers. And if you want a really fun time, look up libpng or openssl security vulnerability to see what happens when a security vulnerability is found in a component distributed as a lib embedded in a binary (it's not pretty because every component which included the vulnerable code needs to be patched).
So sure, the terminal team could have decided to ship their code simply as OSS and compile their code directly into customer applications (there's a tricky bit here because they'd have to figure out how to get their code compiling with every possible customer compiler and build environment choice, but it's solvable - OSS projects have done this for years). But for servicing reasons alone, shared objects are a huge win for customer reliability.
And you're right - C++ does define a standardized binary contract. But it happens to only cover the constructs that C++ shares with C. So you're still limited to C constructs if you want interoperability.
Btw, the interoperability story is even worse if you distribute your code via a lib. There is no guarantee of interoperabilty between different versions of the same compiler, much less between different compilers (compiler authors attempt to maintain binary compatibility across time, but they DO break their internal contracts on occasion (simple example:  changing name decoration algorithms breaks interoperability, even if it doesn't break the binary contract).

Yes, of course, I know the story about shared vs static vs code libraries (I guess).
But my point is that the terminal is now in alpha stage. If someone want's to try it he is best of building it himself, and eventually, there are preview releases on windows store (and I'm not sure which way to acquire it is actually more challenging :P). So just for the time no one outside the terminal's development team is using this code (and that's probably quite a long time) or using different compiler versions or even shipping the application with a proclamation that it won't break anything, we could theoretically move things around to allow easier and quicker development, especially in the prototyping phase where interfaces like idl often changes, which goes to things above. That's why I said now.
Also I'm glad to hear the VS team is working on better integration with idl's.

I'm not on the Terminal team (heck, I'm no longer in Windows for that matter), so I cannot speak for them and their architecture. However IMHO it's far better to build your design up-front to meet the long-term goals of the feature rather than add those architectural changes in later.
And I'm not sure it's a correct statement that "the VS team is working on better integration with IDLs". What I said was that the C++/WinRT team is working with the VS team to improve the integration. Not quite the same thing.

@mcpiroman Jumping in with a few thoughts re. some of the points you raise above:

"If someone want's to try it [they are] best off building it [themselves]"

Not true - if someone is interested in just using the Terminal, it's likely best that they install the preview builds from the Store. This way they'll automatically receive updates every time we push a new build. Note: We'll be pushing builds more often and more regularly - we'll post an update on this news shortly.

"or using different compiler versions"
The Terminal is not a stand-alone project. It shares many of its core components with Windows' Console and the code-base also includes the command-line plumbing that's built into Windows itself. Thus, we don't have the luxury of arbitrarily choosing which compiler to use. Nor would we even if we could - doing so would likely introduce many unknown and undiscovered issues that are hard to find and likely harder to fix.

Alas, the C++ standards deliberately avoid defining the mechanics of ABI/calling-convention/exception-passing/etc. While this has allowed great flexibility for individual compiler/tooling creators/vendors, it has resulted in many inconsistencies and incompatibilities between different C++ implementations. And because of the latter, we end up with IDL being required to describe classes and types in a manner that can be serialized into C in order to provide some amount of smooth projection/interop between C++ implementations, and other platforms, languages, and tools like .NETetc.
Until there's a universally adopted standard for a C++ runtime, we'll have to use IDL to ensure that we can interop with C++ from other languages and platforms, and using C++ code built using other toolchains.
Closing this issue for now as there's no further action to take here.


[pt-br] Add docs/tasks/configure-pod-container/create-hostprocess-pod.md

/remove-lifecycle stale

/assign
/cc

/lifecycle rotten

/remove-lifecycle rotten

/retitle [pt-br] Add docs/tasks/configure-pod-container/create-hostprocess-pod.md

/cc @MrErlison @edsoncelio
Could you please provide a second review?

/cc
/label tide/merge-method-squash

Hi @stormqueen1990
Could you check status of this PR?
Do we require additional reviews, or should we consider this PR as stale?

Hi @stormqueen1990 Could you check status of this PR? Do we require additional reviews, or should we consider this PR as stale?

Hi there, @seokho-son! I'll take a look. This one slipped under my radar 😅

/cc

Hi there, @DonatoHorn!
Thanks for your work in this translation!
Apologies for not getting back to this PR earlier. I took a look, and it appears the content is already outdated. Because of that, I will be closing this PR, but feel free to update the content and reopen it, or create a separate PR with the updated content.
/close


[RaisedButton] fullWidth fix

The display-inline block wrapper doesn't adapt to the child element's width if it was defined in percentage, because the child element would recognize the width based on the wrapper element.
Fixes #4226

It works well! Thanks.

@leonuh thanks for contributing.


RFD: Automating Workflow for Docker Requirement Fixes

Currently, the docker-requirements / update (pull_request) workflow is configured to be triggered manually. When activated, it opens a separate PR to fix Docker requirements. While this ensures updates are controlled, it requires manual intervention, which can delay necessary fixes.
Maybe we can configure the workflow to be automatically triggered on every push to the main branch, creating a PR if Docker requirements need fixing. cc: @pmeier

Maybe we can configure the workflow to be automatically triggered on every push to the main branch, creating a PR if Docker requirements need fixing.

You have my +1 for this, I'd be happy to configure it however we decide.

Two comments from my side:

I'm ok with running this on main, but in that case we should disable the old triggers. It makes little sense to run this on a PR. Whether it comes out red or green, it will be re-run after merge anyway and thus the information gain is minimal.
We might need some logic to figure out how to ping on the PR. It should be the person who merged the PR and potentially the author of the PR as well. I think we need to hit the GH API for that.

But in any case, I think we can move forward @arjxn-py!


Sql Server state component error:  Dapr.Actors.ActorMethodInvocationException

Issue Description
I am trying to replace the redis store by azure sql server. The target table is created successfuly but whenever I try to create a proxy actor I get this error when trying to execute a method
Unhandled exception. Dapr.Actors.ActorMethodInvocationException: Remote Actor Method Exception
---> Dapr.Actors.DaprException: not found
at Dapr.Actors.DaprHttpInteractor.SendAsyncHandleUnsuccessfulResponse(Func1 requestFunc, String relativeUri, String requestId, CancellationToken cancellationToken) at Dapr.Actors.DaprHttpInteractor.SendAsync(Func1 requestFunc, String relativeUri, String requestId, CancellationToken cancellationToken)
at Dapr.Actors.DaprHttpInteractor.GetStateAsync(String actorType, String actorId, String keyName, CancellationToken cancellationToken)
at Dapr.Actors.Runtime.DaprStateProvider.ContainsStateAsync(String actorType, String actorId, String stateName, CancellationToken cancellationToken)

Actual Behavior
Receiving a Remoted Actor Method not found
If I swap sqlstate.yaml with redis state.yaml everything works fine again
LOGS:
== DAPR == time="2020-02-21T12:14:57+01:00" level=info msg="starting Dapr Runtime -- version 0.4.0 -- commit v0.3.0-rc.0-73-ga1e270f-dirty"

== DAPR == time="2020-02-21T12:14:57+01:00" level=info msg="log level set to: info"

== DAPR == time="2020-02-21T12:14:57+01:00" level=info msg="standalone mode configured"

== DAPR == time="2020-02-21T12:14:57+01:00" level=info msg="dapr id: lande_actor"

== DAPR == time="2020-02-21T12:14:57+01:00" level=info msg="mTLS is disabled.   Status: Running. Init Elapsed 4775.6745ms"

Sql state store definition file:
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
name: statestore
spec:
type: state.sqlserver
metadata:
- name: connectionString
  value: server=server.database.windows.net;user id=dwlab;password=pass!;port=1433;database=db1;
- name: tableName
  value: dapr
- name: actorStateStore
  value: "true"

The error coming from Dapr is probably different than the one surfaced by the dotnet SDK here.
Can you add the --log-level debug flag to dapr run and see if there's any suspicious messages showing?

Hello @yaron2. First of all, congrats for your amazing work. I'm very hyped with Dapr!
Executing using:
dapr run --port 3500 --app-id lande_actor --app-port 5000 --log-level debug dotnet run
Shows errors:
== DAPR == time="2020-02-21T12:19:48+01:00" level=debug msg="error establishing client to placement service: rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing dial tcp [::1]:6050: connectex: No connection could be made because the target machine actively refused it.\""

== DAPR == time="2020-02-21T12:19:51+01:00" level=debug msg="error establishing client to placement service: rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing dial tcp [::1]:6050: connectex: No connection could be made because the target machine actively refused it.\""

== DAPR == time="2020-02-21T12:19:53+01:00" level=debug msg="error establishing client to placement service: rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing dial tcp [::1]:6050: connectex: No connection could be made because the target machine actively refused it.\""

Thanks @yaron2, first of all congrats for your great work.
 HTTP Port: 3500. gRPC Port: 27772
You're up and running!    Status: Running.
Lets try and get the actual error from Dapr by invoking the actor over HTTP instead of going through the SDK.
Issue the next call to Dapr via HTTP:
Method: POST
Url: http://localhost:3500/v1.0/actors/MyActor/123/<MethodNameOnYourActor>
Body:

Sorry, forgot to mention I already tried that:
POST: http://<IP_ADDRESS>:3500/v1.0/actors/MyActor/1/method/GetDataAsync
{
    "errorCode": "ERR_ACTOR_INVOKE_METHOD",
    "message": "error from actor service: Dapr.Actors.DaprException: not found\r\n   at Dapr.Actors.DaprHttpInteractor.SendAsyncHandleUnsuccessfulResponse(Func`1 requestFunc, String relativeUri, String requestId, CancellationToken cancellationToken)\r\n   at Dapr.Actors.DaprHttpInteractor.SendAsync(Func`1 requestFunc, String relativeUri, String requestId, CancellationToken cancellationToken)\r\n   at Dapr.Actors.DaprHttpInteractor.GetStateAsync(String actorType, String actorId, String keyName, CancellationToken cancellationToken)\r\n   at Dapr.Actors.Runtime.DaprStateProvider.TryLoadStateAsync[T](String actorType, String actorId, String stateName, CancellationToken cancellationToken)\r\n   at Dapr.Actors.Runtime.ActorStateManager.TryGetStateAsync[T](String stateName, CancellationToken cancellationToken)\r\n   at Dapr.Actors.Runtime.ActorStateManager.GetStateAsync[T](String stateName, CancellationToken cancellationToken)\r\n   at CallSite.Target(Closure , CallSite , Object )\r\n   at System.Dynamic.UpdateDelegates.UpdateAndExecuteVoid1[T0](CallSite site, T0 arg0)\r\n   at Dapr.Actors.Runtime.ActorManager.<>c__DisplayClass15_0.<<DispatchWithoutRemotingAsync>g__RequestFunc|0>d.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n   at Dapr.Actors.Runtime.ActorManager.DispatchInternalAsync[T](ActorId actorId, ActorMethodContext actorMethodContext, Func`3 actorFunc, CancellationToken cancellationToken)\r\n   at Dapr.Actors.Runtime.ActorManager.DispatchInternalAsync[T](ActorId actorId, ActorMethodContext actorMethodContext, Func`3 actorFunc, CancellationToken cancellationToken)\r\n   at Dapr.Actors.Runtime.ActorManager.DispatchWithoutRemotingAsync(ActorId actorId, String actorMethodName, Stream requestBodyStream, Stream responseBodyStream, CancellationToken cancellationToken)\r\n   at Dapr.Actors.AspNetCore.RouterBuilderExtensions.<>c.<<AddActorMethodRoute>b__3_0>d.MoveNext()"
}

Great. Try this next:
Method: 'GET'
Url: 'http://localhost:3500/v1.0/actors/MyActor/123/state/`

In that case, the key should be the one used in the GetDataAsync method on the actor.

It will be familiar to you as it's the key from the tutorial:
        public async Task<string> SetDataAsync(MyData data)
        {
            await StateManager.SetStateAsync<MyData>("my_data", data);
            return "Success";
        }

        public Task<MyData> GetDataAsync()
        {
            // Gets state from the state store.
            return this.StateManager.GetStateAsync<MyData>("my_data");
        }

GET http://<IP_ADDRESS>:3500/v1.0/actors/MyActor/1/state/my_data
Response:
{
    "errorCode": "ERR_ACTOR_STATE_GET",
    "message": "not found"
}

Good job!
We now know it's coming from here:
https://github.com/dapr/components-contrib/blob/5b75f4d0fbc6cee6b8ef2576abd203eb826e8032/state/sqlserver/sqlserver.go#L440

Are you able to save state?

SetDataAsync is the method triggering the exception in the first place:
Starting execution!
Creating proxy
Sending data
Unhandled exception. Dapr.Actors.ActorMethodInvocationException: Remote Actor Method Exception
 ---> Dapr.Actors.DaprException: not found
   at Dapr.Actors.DaprHttpInteractor.SendAsyncHandleUnsuccessfulResponse(Func`1 requestFunc, String relativeUri, String requestId, CancellationToken cancellationToken)

Ok so we really need to try and save the data with HTTP, because if the data fails to get written than its normal for the not found error to return

Method: POST
Url: http://localhost:3500/v1.0/actors/MyActor/1/state/my_data
Body: "{\"name\":\"test\"}"

POST http://localhost:3500/v1.0/actors/MyActor/1/state/my_data
Status Code: 201 created
GET http://localhost:3500/v1.0/actors/MyActor/1/state/my_data
Status Code: 200
Data is succesfully stored in Sql Server:

And if you use the C# SDK now to Get the state?

Working!. So it looks like when there is not state initialized the sql server state crashes using the SDK

Can you try to use the C# SDK to invoke an actor with a new ID?

It'll probably fail.. just want to make sure.

Exactly. Crash again. GetStateAsync is failing
Unhandled exception. Dapr.Actors.ActorMethodInvocationException: Remote Actor Method Exception
 ---> Dapr.Actors.DaprException: not found
   at Dapr.Actors.DaprHttpInteractor.SendAsyncHandleUnsuccessfulResponse(Func`1 requestFunc, String relativeUri, String requestId, CancellationToken cancellationToken)
   at Dapr.Actors.DaprHttpInteractor.SendAsync(Func`1 requestFunc, String relativeUri, String requestId, CancellationToken cancellationToken)
   at Dapr.Actors.DaprHttpInteractor.GetStateAsync(String actorType, String actorId, String keyName, CancellationToken cancellationToken)
   at Dapr.Actors.Runtime.DaprStateProvider.ContainsStateAsync(String actorType, String actorId, String stateName, CancellationToken cancellationToken)
   at Dapr.Actors.Runtime.ActorStateManager.SetStateAsync[T](String stateName, T value, CancellationToken cancellationToken)
   at MyActorService.MyActor.SetDataAsync(MyData data) in C:\source\labs\dapr\dotnet\MyActorService\MyActor.cs:line 31
   at Dapr.Actors.Builder.ActorMethodDispatcherBase.<>c__DisplayClass14_0`1.<ContinueWithResult>b__0(Task`1 t)
   at System.Threading.Tasks.ContinuationResultTaskFromResultTask`2.InnerInvoke()
   at System.Threading.Tasks.Task.<>c.<.cctor>b__274_0(Object obj)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location where exception was thrown ---
   at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot, Thread threadPoolThread)
--- End of stack trace from previous location where exception was thrown ---
   at Dapr.Actors.Runtime.ActorManager.<>c__DisplayClass14_0.<<DispatchWithRemotingAsync>g__RequestFunc|0>d.MoveNext()
   --- End of inner exception stack trace ---
   at Dapr.Actors.DaprHttpInteractor.InvokeActorMethodWithRemotingAsync(ActorMessageSerializersManager serializersManager, IActorRequestMessage remotingRequestRequestMessage, CancellationToken cancellationToken)
   at Dapr.Actors.Communication.Client.ActorRemotingClient.InvokeAsync(IActorRequestMessage remotingRequestMessage, String methodName, CancellationToken cancellationToken)
   at Dapr.Actors.Client.ActorProxy.InvokeAsync(Int32 interfaceId, Int32 methodId, String methodName, IActorRequestMessageBody requestMsgBodyValue, CancellationToken cancellationToken)
   at Dapr.Actors.Client.ActorProxy.ContinueWithResult[TRetval](Int32 interfaceId, Int32 methodId, Task`1 task)
   at MyActorClient.Program.Main(String[] args) in C:\source\labs\dapr\dotnet\MyActorClient\Program.cs:line 25
   at MyActorClient.Program.<Main>(String[] args)

Ok I see why this is happening. The SQL Server implementation treats a non-existing key as an error, but it shouldn't. It should return an empty response.
We'll fix that sooner rather than later.
Thanks a lot for helping debug this.

You are welcome @yaron2 . Thanks for your support


update README to have installation info (moving build instructions to a separate file)

Compilation instructions don't need to be on the front page — people who just want to try jxl will generally just want to get a cjxl/djxl they can run. This puts the compilation instructions in a separate file (BUILDING.md) and puts some installation info on the front page, including a bunch of badges for the more popular linux distros and some pointers for MacOS and Windows.

There are two more files, namely ./plugins/gdk-pixbuf/README.md and ./plugins/mime/README.md That have links to the #installing section of the old README.md, which need to be changed to the #installing section of BUILD.md

Updated.


Print block type rejection

Currently the print block accepts multiple variable type inputs and running the program with some of these types connected causes unusual and hard to diagnose error problems.
The print block should only except 'Number' 'Vector' and 'String' type inputs currently to avoid problem programs

@dube1503 I think booleans should also be included in the accepted inputs. You are allowed to print the value of a boolean variable in glowscript and python


[REQ] remove .net

Acknowledgement of preliminary instructions

[X] I have read and acknowledged the preliminary instructions.

What idea do you have?
please remove .net asking thing i cant download it please make bloxstrap from something else plss

You need to install it. No way around it.

You need to install it. No way around it.

you cant make it without .net?


Exceptions in DSpace 7 REST API do not produce log entries in the DSpace log files

Describe the bug
When an exception is thrown in the DSpace 7 REST API and it traverses to the DSpaceApiExceptionControllerAdvice, it will not produce a log entry in the DSpace logs by default. For example, when an UnprocessableEntityException is thrown due to a POST request on an Item, there will be no trace of this in the logs.
To Reproduce

Perform a request that's sure to throw an Exception (For example creating an EPerson with RegistrationData which contains an already in use email)
Verify that you get an error in your REST Response that shows a 400 Bad Request
Verify that you do not see any log entries for this Exception in the DSpace logs

Expected behavior
We should expect a log to show in the DSpace logs describing what went wrong at that given time. This will be useful for when REST Requests go south and we want to later identify what went wrong or what the culprit was.

@Raf-atmire : I'd recommend we not log all exceptions that occur in the REST API, as doing so could quickly fill up your logs with invalid requests. It also would allow for a strange sort of "attack" where someone could simply make the same invalid request over and over again against your REST API until the logs filled up all your available storage and the site crashes or becomes unresponsive.
Currently, the approach in DSpaceApiExceptionControllerAdvice is to only log 500 errors (Internal Server Error), as you can see right here: https://github.com/DSpace/DSpace/blob/main/dspace-server-webapp/src/main/java/org/dspace/app/rest/exception/DSpaceApiExceptionControllerAdvice.java#L179
I'm OK with us logging some additional exception types, but I'd hesitate to log anything that is an invalid syntax error or similar.   So, I'd hesitate to log most 4xx errors, as they can easily fill up the logs with useless information.  That said, I'm not against making exceptions for specific scenarios. We'd just need to discuss which scenarios really should be logged.

Log at different levels, perhaps?  5xx = ERROR, 4xx = WARN, with possible exceptions like 422 = ERROR.  Then you can control whether you monitor lesser issues, and turn them on and off as needed.

@mwoodiupui : Good point. That seems like an approach to consider.  I think we'd want to ensure any 4xx which are deemed WARN do not log the full stacktrace by default (as it's useless for many 4xx exceptions, as they are often a syntax error from the client). But, I'm fine with a single line WARN for most 4xx requests.

I'm going to move this into Beta 5, since we likely need some improvements here for 7.0 final.  I'd recommend we go with the approach laid out by @mwoodiupui with some minor tweaks:

5xx should be logged as ERROR with full stack trace (I think this is already implemented, as 500 seems to be the only 5xx error we currently throw from the REST API)
4xx should be logged as WARN with no stack trace (exceptions can be made for some specific messages if we feel a stacktrace is needed, or an ERROR is more appropriate, but those need to be discussed further).

Flagging this as needs an estimate.

It can be implemented as a simple set of rules, e.g. the 5xx=ERROR etc as Tim suggested. I'd expect that to require 2 hours of work since no ITs are necessary
A more advanced solution would be to make it configurable which error codes are logged, at what level, with or without stack trace. I'd expect that to require 4 hours of work.
We can implement either solution, whatever the preference is

@benbosman : Sounds good. I'd recommend we go with the simple (2hr) approach for now.  If we find that is somehow limiting, we can enhance it later. So, for now, I think it's fine to mostly just make 5xx=ERROR (with stacktrace) and 4xx=WARN (no stacktrace).  If there are other specific responses where we feel a stacktrace is necessary (maybe 422), then those should be returned as ERROR as well.
Assigning back to you for your team to work on.

As discussed today, the upcoming PR for this ticket can be assigned to @abollini and @tdonohue


Clicking on a cluster on the map should zoom in on it

Is your feature request related to a problem? Please describe.
When I'm on the map and click on a cluster, I expect to zoom in on that. As an example, if I go on http://localhost:9000/testumgebung/de/locations/ in a laptop browser, I see a cluster of three locations in Berlin. When I click on that "3", nothing happens. It should instead center that spot and zoom in. Same goes for native.
Describe the solution you'd like
I want the map to center on the cluster and zoom in (at least a little, doesn't have to be enough to open up the cluster).
Describe alternatives you've considered
We could leave it like it is but it's not what other maps do, so users probably expect a zoom.

hey @LeandraH can i work on this issue, could please assign this to me ?

That's awesome, thank you!

Hey @nikhilgarg26, how's it going with this? Do you have any questions that we can maybe help you with?

Hey @nikhilgarg26, are you still working on this? If not, I'd remove you as the assignee so that someone else can have a go but thanks for having a go at it!


Suppot for SPV_QCOM_image_processing2

It's still hit a bunch of formatting issues in the tests.

Fixed the formatting issues in test/val/val_image_test.cpp

Smoketest is due to older headers.


IMAGE SHIFT when rendered on canvas ...  GMAPS to CANVAS ( html2canvas 1.0.0-alpha.12 )

I have random offset IMAGE SHIFT when rendered on canvas ...  GMAPS to CANVAS
VER: html2canvas 1.0.0-alpha.12
Examples try to do it with move map before and not move map after load

https://codepen.io/den_tss/pen/zJYVKb
2)
https://jsfiddle.net/denis_miroshnikov_ts/4tgcveyh/34/
FF and Chrome same result
How I can resolve this ?
TNX
Denis

@DenisKS This is a widely known issue and has solutions found

@DenisKS This is a widely known issue and has solutions found:
https://github.com/niklasvh/html2canvas/issues/1568

Try to Use this FIX but for me it's not work FF and Chrome same result :
fix try 1:  https://jsfiddle.net/denis_miroshnikov_ts/erjvu371/3/
help me please , I think i not do something..

You were using an old fix. Here you go:
https://jsfiddle.net/hfsde0xp/


Scripts to load XML blobs into a database

I created a set of Powershell and SQL scripts to create and load a normalized schema for the old XML files. The script also attempts to fix som inconsistencies found in the XML blobs.
https://twitter.com/way0utwest/status/1631005943881437184?s=46&t=TKWjqfcQDan_udm8Vd0fRw
Thanks for your all your work with SQL Saturdays, Steve!

Thanks for the help here with some ETL.


chore: bump lnurl-rs

New lnurl-rs pins transitivie dep to avoid breakage.
To make it work, we need to update reqwest as well.

This is the backport, no? I didn't try automatic backport, as we did a lot of sorting of deps on master, so I doubt it would work.

we did a lot of sorting of deps on master, so I doubt it would work

Sg! Send it!


disable login and register with email

for now, we decided only to support login with GitHub ( in the future we can implement another git like GitLab. )

We have to delete all the Auth Files, not only disable, i dont want dead code in the codebase !

you can check this pull request to understand better what you need to change.
#11
also if you want more information i made a video about this issue : how to contribute on CodeReviewPals.com

Delete all Auth stuff from breeze, and views

Assign this to me to please 🙂

Do u start something ?

I made a pull request. Please let me know if it meets your expectations and if not, what should I have done differently. Thank you.


Compliance Report | Government Analyst can't access main Compliance Reporting page in Nav bar |1|

Issue:
Dev Environment (v1.5.2): the government analyst role cannot see the Compliance Reporting link in the main nav bar.

A permission issue?

https://trello.com/c/JGiXWsXw/1988-compliance-report-government-analyst-cant-access-main-compliance-reporting-page-in-nav-bar-1

 Compliance Report | Government Analyst can't access main Compliance Reporting page in Nav bar |1|

resolved in sprint vulcan


Remove unnecessary copies in the Rust interface

At some point, the data that was received was copied; either when receiving or when unpacking a nested message.
In this latter point (since encryption/decryption can happen in-place), that was unfortunate. But even in other scenarios not needlessly duplicating the payload data (which after all might be large) is a good idea.

Note: since this PR touches a lot of things, the individual commits separate out the various changes in a better way.


[Content] Migrate topic pages

[ ] add article feed

Still WIP, EN and BR topic pages done.

DE, ES, FR, IT, JP, and KO topics pages done.


ERR Capabilities for vscode.markdown.preview.editor already set

Had a markdown file open (not as preview, but source) and "Save workspace as..." which enters a workspace without reloading the window which restarts the extension host:
ERR Capabilities for vscode.markdown.preview.editor already set: Error: Capabilities for vscode.markdown.preview.editor already set
    at CustomEditorService.registerCustomEditorCapabilities (file:///Users/bpasero/Development/Microsoft/monaco/out/vs/workbench/contrib/customEditor/browser/customEditors.js:193:27)
    at MainThreadWebviews.registerEditorProvider (file:///Users/bpasero/Development/Microsoft/monaco/out/vs/workbench/api/browser/mainThreadWebview.js:234:59)
    at MainThreadWebviews.$registerTextEditorProvider (file:///Users/bpasero/Development/Microsoft/monaco/out/vs/workbench/api/browser/mainThreadWebview.js:223:22)
    at RPCProtocol._doInvokeHandler (file:///Users/bpasero/Development/Microsoft/monaco/out/vs/workbench/services/extensions/common/rpcProtocol.js:336:31)
    at RPCProtocol._invokeHandler (file:///Users/bpasero/Development/Microsoft/monaco/out/vs/workbench/services/extensions/common/rpcProtocol.js:321:49)
    at RPCProtocol._receiveRequest (file:///Users/bpasero/Development/Microsoft/monaco/out/vs/workbench/services/extensions/common/rpcProtocol.js:248:36)
    at RPCProtocol._receiveOneMessage (file:///Users/bpasero/Development/Microsoft/monaco/out/vs/workbench/services/extensions/common/rpcProtocol.js:176:30)
    at file:///Users/bpasero/Development/Microsoft/monaco/out/vs/workbench/services/extensions/common/rpcProtocol.js:66:56
    at Emitter.fire (file:///Users/bpasero/Development/Microsoft/monaco/out/vs/base/common/event.js:457:42)
    at BufferedEmitter.fire (file:///Users/bpasero/Development/Microsoft/monaco/out/vs/base/parts/ipc/common/ipc.net.js:362:35)
    at PersistentProtocol._receiveMessage (file:///Users/bpasero/Development/Microsoft/monaco/out/vs/base/parts/ipc/common/ipc.net.js:581:37)
    at file:///Users/bpasero/Development/Microsoft/monaco/out/vs/base/parts/ipc/common/ipc.net.js:455:83
    at Emitter.fire (file:///Users/bpasero/Development/Microsoft/monaco/out/vs/base/common/event.js:457:42)
    at ProtocolReader.acceptChunk (file:///Users/bpasero/Development/Microsoft/monaco/out/vs/base/parts/ipc/common/ipc.net.js:188:37)
    at file:///Users/bpasero/Development/Microsoft/monaco/out/vs/base/parts/ipc/common/ipc.net.js:157:61
    at Socket.listener (file:///Users/bpasero/Development/Microsoft/monaco/out/vs/base/parts/ipc/node/ipc.net.js:17:40)
    at Socket.emit (events.js:203:13)
    at addChunk (_stream_readable.js:295:12)
    at readableAddChunk (_stream_readable.js:276:11)
    at Socket.Readable.push (_stream_readable.js:210:10)
    at Pipe.onStreamRead (internal/stream_base_commons.js:166:17)

Duplicate of #99053


Hubot hear and multiple dispatch

Overview
This PR uses Hubot's hear() function to listen in on channels and match against regexes dynamically loaded from StackStorm.
Example
An action alias that can match multiple times in a message
---
name: "jira_get_issue"
pack: "jira"
action_ref: "jira.get_issue"
description: "Get a blurb from a Jira issue."
formats:
  - display: "jira issue <issue key>"
    representation:
      - "jira i(?:ssue)? (?P<issue_key>[A-Z][A-Z0-9]+-[0-9]+)"
  - display: "<issue key>"
    representation:
      - (?:^|\b)(?P<issue_key>[A-Z][A-Z0-9]+-[0-9]+)(?:\b|$)
    # Pass "global" flag to XRegExp so regex can match multiple times per message
    regex_flags: g

This action alias allows hubot to match a Jira issue key multiple times in one message, so the following Slack message would dispatch multiple times to StackStorm:

Hey, I started working on SERVICEDESK-1234, but I got blocked by INFRASTRUCTURE-4321. I'm switching over to working on SERVICEDESK-1235 instead.

Specifically, with this change, Hubot would dispatch three different times to StackStorm:

Once for the issue key SERVICEDESK-1234
Once for the issue key INFRASTRUCTURE-4321
Once for the issue key SERVICEDESK-1235

The regex_flags key is exposed to hubot-stackstorm through StackStorm's API, so H-S can compile the regular expression with the appropriate flags.
Extensibility
Our current actions simply respond with a blob of the the issue description in Slack, saving our users a round trip to Jira (which could itself include a login) to read the issue. However, the exact action is not limited to this.
Because StackStorm exposes the YAML root keys over its API, hubot-stackstorm can pick up keys that were not initially exposed, such as the regex_flags key. This key allows pack developers to specify the flags with which the representation regex should be compiled. By passing the g flag, the regex is compiled to match the message multiple times, and each match then gets dispatched to StackStorm. Other regex flags can also be passed to XRegExp using this mechanism.
Finally, with all of that plumbing in place, I have H-S pull the action aliases and use Hubot's hear() function so chat bots can respond to appropriate messages even if they were not @mentioned directly.
Additional Considerations
I changed the regex engine from Node.js' default regex engine to the XRegExp engine. The original Javascript regex engine does not support named group captures at all, but Python's standard re module does. When pack authors specify named groups using Python's extension syntax (eg: (?P<group_name>...)), the native Javascript regex engine barfs on the Python-specific named group capture. The XRegExp package properly interprets the Python named capture group syntax, which allows named capture groups in the compiled regex. XRegExp is a wrapper around the built-in Javascript regex engine (it does a little bookkeeping to pair up a numbered capture group with a named capture group), so its both backwards compatible from a matching/calling perspective and from a performance perspective. By using XRegExp, we avoid having to remove or convert Python's named capture group syntax, so the Python-compatible regex that pack authors are already comfortable writing can also automatically be used in Hubot.
Tests
I have added tests for lib/command_factory.js, but I found it difficult to add automated tests scripts/stackstorm.js. I have tested it manually by deploying this code to our dev StackStorm server and running messages into it via Slack.
If you have any testing suggestions for me I am very interested.
Coverage
According to the coverage report, the tests I added to tests/test-command-factory.js have covered 100% of the code I changed in lib/command_factory.js.
Motivation
This PR sets the stage for some of our changes to the StackStorm Jira pack. We are working on upstreaming those changes as well, once these changes are put into place.
Our final intent is to have a JiraBot listen in on the channel, and when anybody mentions a Jira issue (without necessarily @-mentioning the bot directly), the JiraBot pulls the issue summary from Jira and dumps it into the channel (with pretty formatting, of course, once #147 is merged in).
Final Notes
This is some of the first in-depth Javascript I have written, so if I am not following coding conventions, or if there are better ways to implement things, please let me know.
Also, I have not tested this on anything other than Mac OS X with Node.js v8.4.0.
As always, I'm happy to answer any questions or respond to any comments, criticisms, or discussion. Thanks!

Working on fixing these failures today.

Added polyfils for Node.js v0.12 and io.js.

Since we now install Node.js v6.0 by default, maybe we should just update our travis config here, and drop older Node.js versions, and io.js?
Save others some pain with dealing with this kind of fix.

First thank you for this contribution :+1:
Now to add some context and figure out how we can integrate this change.
A while ago we have started to move away from the "fat / smart client" approach (regexes and other logic is encoded in the client) to moving all the alias matching and executing functionality to the server side (API). Client / adapter should only be responsible for authenticating and formatting messages for the medium in question and nothing else.
This approach has many benefits, but the most important ones is that the clients are very simply (dumb) wrappers around APIs which makes them much easier (and cheaper in terms of resources) to maintain and it also makes it much easier and faster to develop adapters for other chat systems.
The server side change has already been made (https://github.com/StackStorm/st2/pull/3773) and client side (hubot) change was on our TODO in the near future.
In short - with the new approach, the client will send every chat line to the new "match and execute" StackStorm API and listen for the response. We are aware of the potential performance overhead of this approach, but it's still much better than current approach which is very hard and expensive to maintain, tests, etc. (we basically have duplicated / same logic on the client and server).
And as far as the performance overhead goes, it's not bad unless you have 100s of messages per-second in your channel, but in that case you should probably invite bot to a different channel with less traffic and existing approach would be slow in such scenario as well.
We should figure out how and if we can integrate those changes in the new future approach.

@LindsayHill I'd prefer to adjust the Travis config in a different PR, just to keep the scope of this PR more narrow.

@Kami I didn't realize that API endpoint existed - I'll re-implement this in ST2 proper (I like coding in Python more anyway).
The way this PR implements matching is:
loop through all non-global alias regexes
    if one matches -> dispatch to ST2 -> stop searching for additional aliases
    if none match ->
        loop through all global alias regexes
            if one matches ->
                loop through all matches of that alias -> dispatch each match to ST2
                -> stop searching for additional aliases
        if none match -> error out

Do those semantics sound reasonable to implement in ST2? I can go into more detail about our motivations if necessary.

@ahubl-mz Yeah that sounds reasonable to me.
And yeah, since the match will now happen server-side we should try to be careful and make it as efficient and fast as possible (ideally, complexity should be o(o) where n is number of aliases in the system).

I've taken a look at reimplementing this within StackStorm, and I need some guidance.
In ActionAliasExecutionController.match_and_execute (see st2api/controllers/v1/aliasexecution.py), it returns the result of self.post(...) on line 93. The post() function returns a Response object with a status and a dictionary of result data.
This is problematic because I will need to call post() multiple times in match_and_execute, and there's no good way to maintain reverse compatibility with the existing API that way.
So my options are:

Modify match_and_execute() to return a single result with a list of dictionaries of result data from the (potentially) multiple executions, breaking the current API.
Add another endpoint (probably something like multiple_match_and_execute) and migrate clients to it.
Bump the API version and extend the match_and_execute() function as intended without breaking the existing API. Clients can migrate at their leisure.

Which option would you like me to take?

Also, about algorithmic complexity - this is another problem. If you take a look at the match_command_to_alias function in st2common/util/actionalias_matching.py, it matches commands in O(n2) time:

I think I can work around this by querying the database in a more complex way to only return display dictionaries that contain a regex_flags key whose value contains g which will avoid the outer loop in that function.

@ahubl-mz AFAIK, we don't really have any official consumers of that API endpoint yet, so option 1) is not too bad.
The plan was to add the endpoint first, then migrate the clients (notably hubot-stackstorm) to it in the near future :)
Or perhaps, if we can re-use most of the code and avoid duplication, adding another endpoint "multiple_match_and_execute" works as well.
As far as algorithmic complexity goes - yeah I noticed that while working on it recently, so if you could simplify it, that would be great :)

I will be doing option 1 then, since it (presumably/hopefully) won't break anything major.
My current plan for reducing the algorithmic complexity of the logic is to query Mongo with something like:
cursor = db.inventory.find({"formats": SON([("regex_flags", "g")])}, {"formats.display": 1})

That will allow me to remove one of the nested for loops, but I'm afraid I might simply be hiding the for loop in the query. However, implementing it that way will allow me to cache the results (if I get that working). ¯\_(ツ)_/¯

@ahubl-mz Sounds good and keep us posted and ping us when st2 pr is ready :)

ST2 PR has been submitted for internal legal review. I should have a PR for you by (hopefully early) next week.

Now that StackStorm/st2/pull/3884 is merged, I'll rewrite this to use the new aliasexecution/match_and_execute endpoint and submit a different PR.

Okay, so now that the match_and_execute endpoint on StackStorm can execute an action multiple times, we can rewrite hubot-stackstorm to use that endpoints exclusively.
That means that we don't have to use .respond() anymore, we don't have to query, load, or match against regular expressions in Hubot.
Really, stackstorm.js will basically look like:
var sendAck = function (match) {
  // ...
}

forwardToMatchAndExecute(msg) {
  // ...
}

robot.hear(/.*/, function (msg) {
  matches = forwardToMatchAndExecute(msg);

  _.each(matches, sendAck);
});

Which is much, much simpler.

Yep and I think it should work quite well unless you have a channel with tons of messages per second.
Because of that, it's also important to scope bot hear to a single channel now that every line is sent to the API.


Deploy with ConfigMap fails when it has the same name with the app - disallowed label 'kapp.k14s.io/is-app'

What steps did you take:
Tried to deploy this example https://github.com/vmware-tanzu/carvel-kapp/blob/develop/examples/simple-app-example/config-2.yml
Ran : kapp deploy -a simple-app -f examples/simple-app-example/config-2.yml
What happened:
Received the following error:
kapp: Error: Disallowed labels errors:
- Resource 'configmap/simple-app (v1) namespace: default' has a disallowed label 'kapp.k14s.io/is-app'

What did you expect:
I would expect the application deployed successfully.
Anything else you would like to add:
If the app name is changed or the ConfigMap name is changed then it works (the point is that they should be different, otherwise it won't work)
Environment:

kapp version (use kapp --version):

kapp --version
kapp version 0.46.0

Succeeded

OS (e.g. from /etc/os-release): macOS Monterey, Version 12.3.1
Kubernetes version (use kubectl version)

kubectl version
Client Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.1", GitCommit:"86ec240af8cbd1b60bcc4c03c20da9b98005b92e", GitTreeState:"clean", BuildDate:"2021-12-16T11:33:37Z", GoVersion:"go1.17.5", Compiler:"gc", Platform:"darwin/arm64"}
Server Version: version.Info{Major:"1", Minor:"22+", GitVersion:"v1.22.6-3+7e02437f65494f", GitCommit:"7e02437f65494f7bd0fd255e6996ce6c773993cf", GitTreeState:"clean", BuildDate:"2022-01-26T22:09:00Z", GoVersion:"go1.16.13", Compiler:"gc", Platform:"linux/arm64"}

Vote on this request
This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.
👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"
We are also happy to receive and review Pull Requests if you want to help working on this issue.

Duplicate of #146.
PR has been merged with a fix and hopefully this will be present in the next version.


Do not downgrade to the version on the network share if they don't match

The script will downgrade an install of Azure Connected Machine Agent to the network share version, preventing updates from taking place.
This could re-open security vulnerabilities per bug report.

Fixes #37

This change is probably fine, though do note that our agent doesn't allow for downgrades. The only way to install an earlier version of our agent is by completely uninstalling the current newer version

@justinytchen Indeed - what I am warning you about is that the script, as it stands, does attempt to downgrade an later version to whatever is distributed in the deployment share.
The pull request I have created resolves this issue - the script will not attempt to (re)install over the top if the installed version > the deployment script version.

I have a second point...
If a higher version is already installed and therefore doesn't match, the Network Shared download will occur, generating unnecessary traffic. This is because when proceeding with the installation, it will verify that the version present on the server is newer than the one being installed.
In a recent case, we had over 200 servers downloading the approximately 90MB agent every moment, as they all had the latest version of the Arc agent which had updated automatically. I had to include this change in my script so that the download only occurs when needed.
I recommend including this pull request to optimize the agent download only when necessary.


Support numpy arrays in DVC.results() and DVC.params()

Numpy Arrays are very common results and potentially parameters.
Currently they have to be converted with np.ndarry.tolist() manually.
This could be automated.
Possible implementations

convert them to lists
allow custom result types, that use e.g., np.save and np.load instead of json files.

This might also be handy in case of pd.DataFrames or tf.Tensors

It might be handy to put these definitions in a dedicated file that can be easily extended.


Bug: Both MuxVideo and MuxPlayer Throwing TS Errors for Either controls or nohotkeys in React (Next.js)

Is there an existing issue for this?

[X] I have searched the existing issues

Which Mux Elements/Packages does this apply to? Select all that apply
mux-video-react, mux-player-react
Which browsers are you using?
Chrome, Safari
Which operating systems are you using?
macOS
Description
Hello, I'm creating a simple React component for a background video that has to have controls disabled, along with being muted, looped, autoplayed, and having hotkeys disabled.
However, when trying to use the controls attribute <MuxPlayer /> or the nohotkeys attribute in <MuxPlayer />(both imported using npm install @mux/mux-video-react@latest and npm install @mux/mux-player-react@latest), I run into TS2322 errors, essentially saying that the props aren't valid (either nohotkeys or controls, not both, just one for each respective element).
Reduced test case
No response
Steps to reproduce
Step 1: Install latest versions of both MuxVideo and MuxPlayer for React. Note, I'm using Next.js 13.2, but still using the pages directory (no React Server Components).

Step 2: Here are the components for both MuxVideo and MuxPlayer:
MuxVideo:
import MuxVideo from '@mux/mux-video-react';

export default function BackgroundVideo() {
    return (

            <MuxVideo
                autoPlay="muted"
                nohotkeys {/*<— nohotkeys throws a TS Error using MuxVideo*/}
                muted
                loop
                streamType="on-demand"
                controls
                src="ID"
                className="absolute top-0 left-0 w-full h-full object-cover pointer-events-none"
            />

    );
};

MuxPlayer:
import MuxPlayer from '@mux/mux-player-react';

export default function BackgroundVideo() {
    return (

            <MuxPlayer
                autoPlay="muted"
                nohotkeys
                muted
                loop
                streamType="on-demand"
                controls {/*<— controls throws a TS Error using MuxVideo whether using just controls, controls="false", or controls={false}*/}
                src="ID"
                className="absolute top-0 left-0 w-full h-full object-cover pointer-events-none"
            />

    );
};

The type errors should appear on your editor (I'm using WebStorm).
Current Behavior
Using MuxVideo, the error returned is essentially saying that the nohotkeys prop doesn't exist:

TS2322: Type '{ autoPlay: "muted"; muted: true; nohotkeys: true; loop: true; streamType: "on-demand"; controls: true; src: string; className: string; }' is not assignable to type 'IntrinsicAttributes & Pick<Partial, "key" | "height" | "playsInline" | "poster" | "width" | "disablePictureInPicture" | "disableRemotePlayback" | ... 263 more ... | keyof MuxMediaPropTypes> & RefAttributes<...>'.   Property 'nohotkeys' does not exist on type 'IntrinsicAttributes & Pick<Partial, "key" | "height" | "playsInline" | "poster" | "width" | "disablePictureInPicture" | "disableRemotePlayback" | ... 263 more ... | keyof MuxMediaPropTypes> & RefAttributes<...>'.

Using MuxPlayer, the error returned is essentially saying that the controls prop doesn't exist:

TS2322: Type '{ autoPlay: string; muted: true; nohotkeys: true; loop: true; streamType: "on-demand"; controls: true; src: string; className: string; }' is not assignable to type 'IntrinsicAttributes & Omit<MuxPlayerProps, "playerSoftwareVersion" | "playerSoftwareName"> & RefAttributes'.   Property 'controls' does not exist on type 'IntrinsicAttributes & Omit<MuxPlayerProps, "playerSoftwareVersion" | "playerSoftwareName"> & RefAttributes'.

Expected Behavior
Both nohotkeys and controls should work as expected when using either element without any type errors.
Errors
No response
What version of the package are you using?
v1.8.0

Hey @ricardonunez0 . These typescript errors are because each React component in question does not have the property, i.e.:

MuxVideo doesn't have a nohotkeys property (since it doesn't have a "full fledged UI" and simply uses the built in native <video> controls.
MuxPlayer doesn't have a controls property (since it does have a "full fledged UI" and doesn't rely on the built in native <video> controls.

Check out our docs for these here:

MuxVideo github README
MuxPlayer API Reference
Mux Docs for Mux Player

Also, if you have any proposed updates to the docs that would have helped you avoid this confusion, we definitely would love the feedback. Feel free to open a docs request if you do!


Error on non existing val_unseen split for LLaVA

Hello, thank you for your great work!
While trying to reproduce the results of your work I am facing a small error here.
It looks like the error is coming from non existing key values of 'val_unseen' from the LLaVA split.
When I check config.LLaVA.SPLIT.keys(), the only dictionary key values that exist is 'train'.
Could you help me out with this?
Are any files missing from the repository that are required to run this properly?
Thank you so much for your time!

In our project, we did not perform validation for LLaVA. When creating the dataloader, the construction of the val dataset for llava will be skipped. https://github.com/zd11024/NaviLLM/blob/e4f2bf118604d9dc30e34b40931288ec555a8b72/tasks/loaders.py#L24-L27

Sorry I forgot to mention which file I was running.
To give you more context of my problem:
I got the error above while running sh scripts/pretrain.sh.
The error is brought up in the process of initializing val dataloaders.
When I check the dataset_list values in the process, it has "r2r, reverie, cvdn, soon, scanqa, llava".
llava only having the 'train' value in the dictionary key is raising the error.

Thanks for your feedback!  This is because test_datasets was not specified during pretraining. You can simply set test_datasets as CVDN SOON R2R REVERIE ScanQA or modify loader.py to skip the construction for the LLaVA's val loader. Here I suggest you directly run the script multi_wo_pretrain.sh, because we did not observe significant improvement after pretraining and it can greatly reduce the training time.

Okay got it!
I wanted to understand if it's an abnormal error or not and where it's coming from.
Seems like I have a clear understanding.
Thank you so much for your quick replies. Appreciate it! :)


Add Firestore operator-specific query methods

WhereEqual, WhereLessThan etc.

(And initially make the general purpose Where method internal, with an eye to possibly making it public again later.)


#143

Added Spring Boot DevTools as a live reload option #143

I am sorry, but this is not what issue #143 is about.


Using reduction variable causes misaligned write with CUDA target?

Minimal working example (adapted from page 9 of the official cheat sheet to make it compile):
#include <algorithm>
#include <assert.h>

#include <CL/sycl.hpp>

using namespace cl::sycl;

int main() {
  queue myQueue;
  buffer<int> valuesBuf{1024};
  { // Initialize buffer on the host with 0, 1, 2, 3, ..., 1023
    host_accessor a{valuesBuf};
    std::iota(a.get_pointer(), a.get_pointer() + 1024, 0);
  }
  // Buffers with just 1 element to get the reduction results
  int sumResult = 0;
  buffer<int> sumBuf{&sumResult, 1};
  int maxResult = 0;
  buffer<int> maxBuf{&maxResult, 1};
  myQueue.submit(
      [&](handler &cgh) { // Input values to reductions are standard accessors
        auto inputValues = valuesBuf.get_access<access_mode::read>(
            cgh); // Create temporary objects describing variables with
        // reduction semantics
        accessor sumAccessor = sumBuf.get_access<access::mode::read_write>(cgh);
        accessor maxAccessor = maxBuf.get_access<access::mode::read_write>(cgh);
        auto sumReduction = reduction(sumAccessor, plus<int>());
        auto maxReduction = reduction(
            maxAccessor,
            maximum<int>()); // parallel_for performs two reduction operations
        // For each reduction variable, the implementation:
        // - Creates a corresponding reducer
        // - Passes a reference to the reducer to the lambda as a parameter
        cgh.parallel_for(range<1>{1024}, sumReduction, maxReduction,
                         [=](id<1> idx, auto &sum, auto &max) {
                           // plus<>() corresponds to += operator, so sum can be
                           // updated via += or combine()
                           sum += inputValues[idx];
                           // maximum<>() has no shorthand operator, so max
                           // can only be updated via combine()
                           max.combine(inputValues[idx]);
                         });
      });
  // sumBuf and maxBuf contain the reduction results once
  // the kernel completes
  assert(maxBuf.get_host_access()[0] == 1023 &&
         sumBuf.get_host_access()[0] == 523776);
}

When this is compiled (with /opt/hipSYCL/bin/syclcc -Wall -Wextra -Wpedantic -O3 -std=c++17 -g --hipsycl-gpu-arch=sm_50 --cuda-path=/usr/local/cuda -L/usr/local/cuda/lib64 rtest.cpp -o rtest) and run under cuda-memcheck, things don't look so good.
========= CUDA-MEMCHECK
[hipSYCL Warning] dag_direct_scheduler: Detected a requirement that is neither of discard access mode (SYCL 1.2.1) nor noinit property (SYCL 2020) that accesses uninitialized data. Consider changing to discard/noinit. Optimizing potential data transfers away.
[hipSYCL Warning] buffer_memory_requirement: Could not find embedded pointer in kernel blob for this requirement; do you have unnecessary accessors that are unused in your kernel?
[hipSYCL Warning] buffer_memory_requirement: Could not find embedded pointer in kernel blob for this requirement; do you have unnecessary accessors that are unused in your kernel?
========= Invalid __global__ write of size 4
=========     at 0x00000428 in /opt/hipSYCL/bin/../include/hipSYCL/glue/cuda/../generic/hiplike/hiplike_reducer.hpp:76:__hipsycl_kernel__ZTSZZZN7hipsycl4glue23hiplike_kernel_launcherILNS_2rt10backend_idE0ENS2_10cuda_queueEE4bindI24__hipsycl_unnamed_kernelLNS2_11kernel_typeE1ELi1EZZ4mainENKUlRNS_4sycl7handlerEE21_7clESB_EUlNS9_2idILi1EEERT_RT0_E35_26JNS9_6detail29accessor_reduction_descriptorINS9_8accessorIiLi1ELNS9_11access_modeE2ELNS9_6targetE0ELNS9_6access11placeholderE0EEENS9_4plusIiEEEENSL_ISR_NS9_7maximumIiEEEEEEEvNSD_IXT1_EEENS9_5rangeIXT1_EEES10_mT2_DpT3_ENKUlPNS2_8dag_nodeEE605_16clES15_ENKUlDpT_E646_41clIJNS0_16hiplike_dispatch28hiplike_reduction_descriptorISU_NS1B_15reduction_stageILi1EEEEENS1C_ISX_S1E_EEEEEDaS18_EUliDpRS17_E744_44
=========     by thread (0,0,0) in block (0,0,0)
=========     Address 0x6a06ab1205f6b4d3 is misaligned
=========     Saved host backtrace up to driver entry point at kernel launch time
=========     Host Frame:/lib/libcuda.so.1 (cuLaunchKernel + 0x2b8) [0x223718]
=========     Host Frame:/usr/local/cuda/lib64/libcudart.so.10.0 [0x1a23d]
=========     Host Frame:/usr/local/cuda/lib64/libcudart.so.10.0 [0x1a2c7]
=========     Host Frame:/usr/local/cuda/lib64/libcudart.so.10.0 (cudaLaunchKernel + 0x225) [0x4e3c5]
=========     Host Frame:./rtest [0xc17f]
=========     Host Frame:./rtest [0x1dced]
=========     Host Frame:/opt/hipSYCL/bin/../lib/hipSYCL/librt-backend-cuda.so (_ZN7hipsycl2rt10cuda_queue13submit_kernelERKNS0_16kernel_operationESt10shared_ptrINS0_8dag_nodeEE + 0x9e) [0x1252e]
=========     Host Frame:/opt/hipSYCL/bin/../lib/libhipSYCL-rt.so [0x20f82]
=========     Host Frame:/opt/hipSYCL/bin/../lib/libhipSYCL-rt.so (_ZN7hipsycl2rt16kernel_operation8dispatchEPNS0_20operation_dispatcherESt10shared_ptrINS0_8dag_nodeEE + 0x56) [0x35886]
=========     Host Frame:/opt/hipSYCL/bin/../lib/libhipSYCL-rt.so (_ZN7hipsycl2rt20multi_queue_executor15submit_directlyESt10shared_ptrINS0_8dag_nodeEEPNS0_9operationERKSt6vectorIS4_SaIS4_EE + 0x10b6) [0x200e6]
=========     Host Frame:/opt/hipSYCL/bin/../lib/libhipSYCL-rt.so [0x2cca9]
=========     Host Frame:/opt/hipSYCL/bin/../lib/libhipSYCL-rt.so (_ZN7hipsycl2rt20dag_direct_scheduler6submitESt10shared_ptrINS0_8dag_nodeEE + 0xd3c) [0x281fc]
=========     Host Frame:/opt/hipSYCL/bin/../lib/libhipSYCL-rt.so [0x30094]
=========     Host Frame:/opt/hipSYCL/bin/../lib/libhipSYCL-rt.so (_ZN7hipsycl2rt13worker_thread4workEv + 0x244) [0x32b44]
=========     Host Frame:/lib/libstdc++.so.6 [0xcfbc4]
=========     Host Frame:/lib/libpthread.so.0 [0x9299]
=========     Host Frame:/lib/libc.so.6 (clone + 0x43) [0xff053]
=========
========= Program hit cudaErrorLaunchFailure (error 4) due to "unspecified launch failure" on CUDA API call to cudaMemcpyAsync.
=========     Saved host backtrace up to driver entry point at error
=========     Host Frame:/lib/libcuda.so.1 [0x37b2c3]
=========     Host Frame:/opt/hipSYCL/bin/../lib/hipSYCL/librt-backend-cuda.so [0x76703]
=========     Host Frame:/opt/hipSYCL/bin/../lib/hipSYCL/librt-backend-cuda.so (_ZN7hipsycl2rt10cuda_queue13submit_memcpyERKNS0_16memcpy_operationESt10shared_ptrINS0_8dag_nodeEE + 0x2ad) [0x11c4d]
=========     Host Frame:/opt/hipSYCL/bin/../lib/libhipSYCL-rt.so [0x210d2]
=========     Host Frame:/opt/hipSYCL/bin/../lib/libhipSYCL-rt.so (_ZN7hipsycl2rt16memcpy_operation8dispatchEPNS0_20operation_dispatcherESt10shared_ptrINS0_8dag_nodeEE + 0x57) [0x1b8f7]
=========     Host Frame:/opt/hipSYCL/bin/../lib/libhipSYCL-rt.so (_ZN7hipsycl2rt20multi_queue_executor15submit_directlyESt10shared_ptrINS0_8dag_nodeEEPNS0_9operationERKSt6vectorIS4_SaIS4_EE + 0x10b6) [0x200e6]
=========     Host Frame:/opt/hipSYCL/bin/../lib/libhipSYCL-rt.so [0x2cca9]
=========     Host Frame:/opt/hipSYCL/bin/../lib/libhipSYCL-rt.so [0x2d53d]
=========     Host Frame:/opt/hipSYCL/bin/../lib/libhipSYCL-rt.so [0x2ad63]
=========     Host Frame:/opt/hipSYCL/bin/../lib/libhipSYCL-rt.so (_ZN7hipsycl2rt20dag_direct_scheduler6submitESt10shared_ptrINS0_8dag_nodeEE + 0xb19) [0x27fd9]
=========     Host Frame:/opt/hipSYCL/bin/../lib/libhipSYCL-rt.so [0x30094]
=========     Host Frame:/opt/hipSYCL/bin/../lib/libhipSYCL-rt.so (_ZN7hipsycl2rt13worker_thread4workEv + 0x244) [0x32b44]
=========     Host Frame:/lib/libstdc++.so.6 [0xcfbc4]
=========     Host Frame:/lib/libpthread.so.0 [0x9299]
=========     Host Frame:/lib/libc.so.6 (clone + 0x43) [0xff053]
=========
[hipSYCL Error] from /home/kozet/gwaith/uofl-bioinformatics/gpgpu/hipSYCL/src/runtime/cuda/cuda_queue.cpp:221 @ submit_memcpy(): cuda_queue: Couldn't submit memcpy (error code = CUDA:4)
========= Program hit cudaErrorLaunchFailure (error 4) due to "unspecified launch failure" on CUDA API call to cudaEventQuery.
=========     Saved host backtrace up to driver entry point at error
=========     Host Frame:/lib/libcuda.so.1 [0x37b2c3]
=========     Host Frame:/opt/hipSYCL/bin/../lib/hipSYCL/librt-backend-cuda.so [0x6c9de]
=========     Host Frame:/opt/hipSYCL/bin/../lib/hipSYCL/librt-backend-cuda.so (_ZNK7hipsycl2rt15cuda_node_event11is_completeEv + 0x2b) [0xf81b]
=========     Host Frame:/opt/hipSYCL/bin/../lib/libhipSYCL-rt.so (_ZNK7hipsycl2rt8dag_node11is_completeEv + 0x48) [0x22998]
=========     Host Frame:/opt/hipSYCL/bin/../lib/libhipSYCL-rt.so (_ZN7hipsycl2rt17dag_submitted_ops22update_with_submissionESt10shared_ptrINS0_8dag_nodeEE + 0x4dd) [0x30b5d]
=========     Host Frame:/opt/hipSYCL/bin/../lib/libhipSYCL-rt.so (_ZN7hipsycl2rt11dag_manager22register_submitted_opsESt10shared_ptrINS0_8dag_nodeEE + 0x4e) [0x2f90e]
=========     Host Frame:/opt/hipSYCL/bin/../lib/libhipSYCL-rt.so (_ZN7hipsycl2rt20dag_direct_scheduler6submitESt10shared_ptrINS0_8dag_nodeEE + 0xe20) [0x282e0]
=========     Host Frame:/opt/hipSYCL/bin/../lib/libhipSYCL-rt.so [0x30094]
=========     Host Frame:/opt/hipSYCL/bin/../lib/libhipSYCL-rt.so (_ZN7hipsycl2rt13worker_thread4workEv + 0x244) [0x32b44]
=========     Host Frame:/lib/libstdc++.so.6 [0xcfbc4]
=========     Host Frame:/lib/libpthread.so.0 [0x9299]
=========     Host Frame:/lib/libc.so.6 (clone + 0x43) [0xff053]
=========
========= Program hit cudaErrorLaunchFailure (error 4) due to "unspecified launch failure" on CUDA API call to cudaEventSynchronize.
=========     Saved host backtrace up to driver entry point at error
=========     Host Frame:/lib/libcuda.so.1 [0x37b2c3]
=========     Host Frame:/opt/hipSYCL/bin/../lib/hipSYCL/librt-backend-cuda.so [0x6c83e]
=========     Host Frame:/opt/hipSYCL/bin/../lib/hipSYCL/librt-backend-cuda.so (_ZN7hipsycl2rt15cuda_node_event4waitEv + 0x2b) [0xfd6b]
=========     Host Frame:/opt/hipSYCL/bin/../lib/libhipSYCL-rt.so (_ZN7hipsycl2rt20dag_multi_node_event4waitEv + 0x29) [0x24a69]
=========     Host Frame:/opt/hipSYCL/bin/../lib/libhipSYCL-rt.so (_ZNK7hipsycl2rt8dag_node4waitEv + 0x22) [0x23ee2]
=========     Host Frame:./rtest [0x1919b]
=========     Host Frame:./rtest [0x18862]
=========     Host Frame:./rtest [0xfec6]
=========     Host Frame:./rtest [0x699c]
=========     Host Frame:/lib/libc.so.6 (__libc_start_main + 0xd5) [0x27b25]
=========     Host Frame:./rtest [0x570e]
=========
[hipSYCL Error] from /home/kozet/gwaith/uofl-bioinformatics/gpgpu/hipSYCL/src/runtime/cuda/cuda_event.cpp:55 @ is_complete(): cuda_node_event: Couldn't query event status (error code = CUDA:4)
[hipSYCL Error] from /home/kozet/gwaith/uofl-bioinformatics/gpgpu/hipSYCL/src/runtime/cuda/cuda_event.cpp:66 @ wait(): cuda_node_event: cudaEventSynchronize() failed (error code = CUDA:4)
rtest: rtest.cpp:47: int main(): Assertion `maxBuf.get_host_access()[0] == 1023 && sumBuf.get_host_access()[0] == 523776' failed.
========= Error: process didn't terminate successfully
========= No CUDA-MEMCHECK results found

Is this a genuine bug with reduction variables or am I doing something wrong?

Thanks for reporting, it seems that #499 has introduced a regression that broke reductions with accessors. You can try reductions on top of USM pointers as a workaround. We will fix ASAP.

Fix in PR #528
This PR also adds a test case based on this code pattern where I have removed some things that are not necessary, such as the initialization of the buffers with a pointer.


[BUG] - Table Sort Headers flicker when switching between light and dark theme

NextUI Version
2.3.6
Describe the bug
When switching between light and dark theme, the headers flicker as seen in the video add.
https://github.com/user-attachments/assets/1ddafe95-22df-4a35-ab2a-101f3d14ea25
Your Example Website or App
No response
Steps to Reproduce the Bug or Issue

Use NextUi Table.
Choose a column to be sortable.
Switch themes using a theme switcher that works on the whole UI.

Expected behavior
I expect the theme to smoothly change as all the other themes change.
Screenshots or Videos
https://github.com/user-attachments/assets/cd0b88fb-d638-4300-b5fa-853077e20e3c
Operating System Version
macOS
Browser
Chrome

I couldn't reproduce the issue. Please provide a sandbox.


Automatically re-compile sources when template file is updated.

Just to know: Did "Automatically re-compile sources when template file is updated" feature remove since the 0.2 Sailfish version? I couldn't find it. And if yes, why was removed, and are any plans to come back?

That has been removed from README.md because the sentence is misleading. I used the expression to mean "cargo build command will re-compile sources after updating the template file", but it also might be interpreted as "sailfish will re-run cargo build command immediately after saving template file".


Playground displays misleading linker errors

When using the Langium Playground, you're really only editing a grammar and seeing how it parses a sample input into an AST - the linking stage doesn't seem relevant. But linker errors are displayed, which as someone experimenting with Langium for the first time was very confusing until I realised what was happening.
I spent over an hour trying to understand why my grammar and content were producing errors, including diving into the XText docs. I nearly gave up on Langium as it just seemed broken, even in very simple scenarios. It turns out these errors just aren't resolvable in the Playground, because you're only working on the grammar and not doing anything related to resolution or scope.
The Playground is very likely to be used by people trying out Langium for the first time, and displaying these errors is very likely to lead to frustration and people giving up.
Steps To Reproduce

Load the Playground at https://langium.org/playground/
Put the following into the Grammar pane:

grammar MyLang

entry Model:
    body+=Statement+;

Statement: 'const' assignment=ConstantAssignment ';';
ConstantAssignment: name=ID '=' value=Expression;
Expression: value=NUMBER | reference=[ConstantAssignment];

hidden terminal WS: /\s+/;
terminal ID: /[_a-zA-Z][\w_]*/;
terminal NUMBER returns number: /[0-9]+(\.[0-9]*)?/;

Put the following into the Content pane:

const n=5;
const y=n;

The current behavior

The expected behavior
No error should be displayed - the grammar is valid and has been successfully parsed into an AST. The reference hasn't been resolved, but we don't expect it to be - you can't write linker code in the playground, so many valid examples will result in errors.

Thank you for the discussion @Rophuine, though I'm not sure I can agree with this. You're completely right in the regard that the inability to write custom scoping code will lead to unintended error messages about unresolved cross references and is actually something we're investigating how to address. Maybe @Lotes can chime in on that. However, IMO at this point you'd be past using the playground as a means to develop/iterate your language. I think it's fairly valuable to have the full cross reference support in there, including error messages in case the linking failed.
@spoenemann Do you have an opinion on this?

Idea: enable to switch linking errors on/off. They're useful even in the playground sometimes to demonstrate how the default scoping/linking works and e.g. how renaming a symbol without the automatic rename feature breaks the reference. But I'd be ok with turning that switch off by default.

The playground will get an update soon (waiting for some depending PRs). The perfect opportunity for me to add such a switch.

A warning sounds perfect, especially with some explanation. I wasted quite a lot of time in the playground thinking that Langium just wasn't processing a perfectly valid grammar before I realised that it was actually a scope error - I nearly assumed the parsing was just broken and moved on to other options. I'm glad I persevered because Langium has been great!
Having a warning that pointed me to a custom scope provider as a possible solution would have been a much better experience as a beginner!


Enhance terminal dashboard

Terminal dashboard could use some upgrades.

[x] Better error handling
[ ] Task expanded view
[ ] Worker list
[ ] Worker expanded view
[ ] Pass golint

[ ] task cancel

For better error handling, in particular it would be great if the dashboard didn't crash when I kill the funnel server.

Better error handling came in https://github.com/ohsu-comp-bio/funnel/pull/174


Bing Layer Deprecated

in the current example we are importing the BingLayer, now you have src but I assume we should be doing import {BingLayer} from "react-leaflet-bing-v2; But I am getting BingLayer deprecated. Could you updated your example or give us guidance on the proper way to implement your example?
Thank you in advance

yes in your project you have to import { BingLayer } from 'react-leaflet-bing-v2' and it will work.


Bump meshcat server version

Incorporates fix to BufferGeometryUtils from meshcat.

This change is

Should this bump the version too?

I'll bump the version after #56 , no need to do it here. Thanks for the update!