"Failed to authenticate, have you run firebase login" with gcp_sa_key

Github action sample
- uses: w9jds/setup-firebase@main
  with:
    gcp_sa_key: ${{ secrets.GCP_SA_KEY_BASE64_DEV }}
    project_id: "develop"
  env:
    GOOGLE_APPLICATION_CREDENTIALS: "/opt/gcp_key.json"

Error from workflow run
2024-06-07T15:42:32.7047141Z ##[endgroup]
2024-06-07T15:42:32.7049493Z ##[group]Firebase Authentication
2024-06-07T15:42:32.7053270Z Storing service account key into /opt/gcp_key.json
2024-06-07T15:42:32.7067765Z ##[endgroup]
2024-06-07T15:42:32.7076942Z ##[group]Setup Project
2024-06-07T15:42:32.7102774Z [command]/usr/local/bin/firebase use --add develop

Error: Failed to authenticate, have you run firebase login?
Error: {}

Did you manage to solve it?

I solve without this action, simple:
      - name: Inizialize Node for Firebase SDK
        uses: actions/setup-node@v4
      - name: Inizialize Firebase SDK and execute commands
        run: |
          npm install -g firebase-tools
          echo "$CREDENTIAL_FILE_CONTENT" > "${{ github.workspace }}/gcp_key.json"
          firebase use --add [PROJECT_ID]
          firebase [YOUR_COMMAND]
        env:
          CREDENTIAL_FILE_CONTENT: ${{ secrets.CREDENTIAL_FILE_CONTENT }}
          GOOGLE_APPLICATION_CREDENTIALS: "${{ github.workspace }}/gcp_key.json"


Return solution in functions plotting scenarios

The functions reproducing the plots internally solve the system and then only return the plot.
It would be handy to also have the solution available.
I'm not advancing any strong opinion on how this should happen (e.g. returning the solution together with the plot), but it's currently a waste to solve the system and then drop the solution away after plotting.
In trying to diagnose #67 for example, I would have liked to be easily able to inspect the solution on which the plot is based.

This brings to my mind a related question: should we make available everything that is used to build a figure?
More specifically, for each figure xx should we have, functions variables_xx(), solution_xx(), system_xx() that return, respectively, the variables, solution, and system corresponding to figure xx?

I think so.


add json based user and auth manager

can be used to hold virtual users that are not available in the system

is already in https://github.com/cs3org/reva/commit/346900d76bb76057aa79f29c197a53eab717d670


Can't update state with Immutable.js

I have build react+redux+immutable.js
i'm done change state with event onChange ...but i need autocomplete..so use your module...but when i tried to integration with my apps. state can't update,,,

@ihsansatriawan Could you please provide a repo that demonstrates the issue, and steps to reproduce?


Booleans in form data are being incorrectly encoded in post requests

When sending form data, values which are booleans are encoded as "True" and "False" as opposed to "true" and "false". This is because of the urllib.parse.urlencode function.
Perhaps it is non standard to pass a boolean as form data, but I think this is non obvious to regular users. Maybe it should raise an exception or perform a conversion to lowercase.
Expected Result
>>> data = {"key": True, "key2": "true"}
>>> req = requests.post("http://www.google.com", data=data)
>>> req.request.body
'key=true&key2=true'

Actual Result
>>> data = {"key": True, "key2": "true"}
>>> req = requests.post("http://www.google.com", data=data)
>>> req.request.body
'key=True&key2=true'

Reproduction Steps
Pass a dictionary with a key/value pair with a boolean value to the data param of a post.

In the future, please search closed and open issues before creating new ones that are duplicates. I'm not going to go find the duplicates right now. Given all of the possible representations of "True" on the internet, we can't really just pick one. Further, we rely on the stdlib to provide the serialization for this particular content type so we don't even do this directly. You should be thinking about how you want to pre-process the data you send. Feeding everything into requests and expecting it to magic its way to what you want isn't reasonable.


Add Juno and Juno Connect

[x] Entry is formatted according to the proper template
[x] Contents within each section have been sorted alphabetically.
[x] All relevant App capabilities are listed, with :white_check_mark: (see template)
[x] All available links to the App Store / Github / Testflight / Twitter are included (see template)
[x] The AUTHORS file has been updated

Thank you!


Adding report conversion, collation and sending to distribution list

✨  Draft for now ✨

[x] Adds report conversion from docx to pdf
[x] Adds converted report concatenation
[x] Read dispatch list via school ID, using teacher leader email if no teacher email
[x] Send emails to dispatch list

Closes #34

Wasn't sure how to handle the direct mailing list vs sticking people in CC, so have just avoided the CC list for now

Added in some extra bits, have at it


The new setServerSideOptions is not working

I've upgraded to the latest version of this plugin (v2.3.0) and used the new setServerSideOptions setter, it does not seem to be triggering my cloud function for verifying rewards, it worked before on versions that didn't have setServerSideOptions.
I've also tried v2.1.0 none of them work.
This is the snippet of me trying to do so:
RewardedAd.load(
        adUnitId: AppAdmob.getRewardAdUnitId(unitId),
        request: AdRequest(),
        rewardedAdLoadCallback: RewardedAdLoadCallback(
          onAdLoaded: (ad) {
            final options = ServerSideVerificationOptions(
              userId: _authService.user!.uid,
            );

            ad.setServerSideOptions(options).then((value) {
              ad.show(onUserEarnedReward: (adWithoutView, reward) {
                log("Reward: ${reward.amount}");
              });
            });
          },
          onAdFailedToLoad: (loadAdError) {
            errorMessage = loadAdError.message;
          },
        ),
      );

Also there is no documentation on how to do this on the official docs https://developers.google.com/admob/flutter/quick-start. There's mo SSV section under advanced topics like for the Android/iOS SDKs
Flutter doctor:
[✓] Flutter (Channel stable, 3.3.8, on macOS 12.3 21E230 darwin-x64, locale en-WS)
    • Flutter version 3.3.8 on channel stable at /Users/chinloyal/fvm/versions/stable
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 52b3dc25f6 (2 weeks ago), 2022-11-09 12:09:26 +0800
    • Engine revision 857bd6b74c
    • Dart version 2.18.4
    • DevTools version 2.15.0

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    • Android SDK at /usr/local/share/android-sdk
    • Platform android-33, build-tools 30.0.3
    • ANDROID_SDK_ROOT = /usr/local/share/android-sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jre/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.13+0-b1751.21-8125866)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 13.3)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 13E113
    • CocoaPods version 1.11.3

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

[✓] Android Studio (version 2021.3)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.13+0-b1751.21-8125866)

[✓] VS Code (version 1.70.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.52.0

[✓] Connected device (4 available)
    • SM A207M (mobile)                   • R9AMB21AQZJ                          • android-arm64  • Android 11 (API
      30)
    • iPhone SE (3rd generation) (mobile) • 7186C399-D8F4-4C91-8A7C-154D2B3D86B8 • ios            •
      com.apple.CoreSimulator.SimRuntime.iOS-15-4 (simulator)
    • macOS (desktop)                     • macos                                • darwin-x64     • macOS 12.3 21E230
      darwin-x64
    • Chrome (web)                        • chrome                               • web-javascript • Google Chrome
      107.0.5304.110

[✓] HTTP Host Availability
    • All required HTTP hosts are available

• No issues found!

@chinloyal Can you describe more clearly how it doesn't work?
From my end, I can see the reward info from callback after ads is shown:
I/flutter (14306): Reward: 10 - coins

Using sample code at https://github.com/googleads/googleads-mobile-flutter/tree/main/packages/google_mobile_ads/example and update snippet code as below:

Snippet sample code
void _createRewardedAd() {
    RewardedAd.load(
        adUnitId: Platform.isAndroid
            ? 'ca-app-pub-3940256099942544/5224354917'
            : 'ca-app-pub-3940256099942544/1712485313',
        request: request,
        rewardedAdLoadCallback: RewardedAdLoadCallback(
          onAdLoaded: (RewardedAd ad) {
            print('$ad loaded.');
            _rewardedAd = ad;
            _numRewardedLoadAttempts = 0;

            final options = ServerSideVerificationOptions(
              userId: '_authService.user!.uid',
            );
            ad.setServerSideOptions(options).then((value) {
              ad.show(onUserEarnedReward: (adWithoutView, reward) {
                print("Reward: ${reward.amount} - ${reward.type}");
              });
            });

          },
          onAdFailedToLoad: (LoadAdError error) {
            print('RewardedAd failed to load: $error');
            _rewardedAd = null;
            _numRewardedLoadAttempts += 1;
            if (_numRewardedLoadAttempts < maxFailedLoadAttempts) {
              _createRewardedAd();
            }
          },
        ));
  }

@huycozy Yes the onUserEarnedReward callback gets fired but my firebase cloud function is not being triggered to verify the ad view.
You can see below I've verified that it works on the admob portal:

Also for more context I reward the users using the firebase function in firestore not from the client. But that firebase function is no longer being triggered when I call setServerSideOptions

I've figured out why it's not working. In debug mode I was using the testRewardAdUnitId, instead of the production one. I tested using the production id, and it worked.


[MAINT] Remove redundancy in Abtract Qt Classes

E.g. here https://github.com/mne-tools/mne-python/blob/main/mne/viz/backends/_abstract.py#L491. Why do methods of a Qt abstract object have the name of the object in them? i.e.
toolbar = _QtToolBar(...)
toolbar._tool_bar_add_button(...)

seems very redundant when
toolbar = _QtToolBar(...)
toolbar._add_button(...)

seems like it will do and will be much easier to maintain.
Maybe @larsoner, you have thoughts on this/a good reason for why it is this way?

It seems very not DRY because, for instance, toolbar._tool_bar_add_button is pretty much the same as adding a button for a status bar or a lot of other widgets and they could easily inherit unchanged most of the time or save redundancy by calling super()._add_button first.

Oh I see because you can call self._renderer._layout_add_widget for instance to add a widget to a layout. This seems rather inelegant. I would be in favor of doing something like self._status_bar = self._configure_status_bar() so that the attribute doesn't appear from nowhere and then it's much easier to read and maintain without having to look in the _qt.py classes for what attribute self._configure_status_bar() initializes. What do people think?

Maybe I need to dwell on this and see if I warm up to it, but this method of abstraction in https://github.com/mne-tools/mne-python/pull/10565 seems terribly confusing to me. When you call main_layout = self._renderer._layout_create(orientaton='vertical') you get an object that you have to manage and confusingly pass to the renderer just to add widgets or layouts to it. That seems very inelegant and confusing to me, especially when self._configure_status_bar() doesn't return anything at all and just adds attributes.
I think the best solution is more toward the first one, otherwise it's going to be impossible to keep track of all the attributes that are created behind the scenes in the abstract classes and obviously the layout had to be returned because you can have more than 1 of them. You probably don't want more than one toolbar but to me a toolbar and a status bar are pretty arbitrary distinctions and the more general, powerful abstraction is that of a bar which can be top, bottom or either side and potentially doubled up (I was considering a spectogram bar above the toolbar for a vertical layout).
In summary, a big -1 from me on the direction that this is going although I do think it's salvageable as long as everything gets returned from the abstract classes and then you can interact with abstract object methods that are documented in the abstract class like _AbstractRenderer. That seems like the perfect example of exactly how we want to do things, I'm not sure why things ended up so different and confusing. A lot of it has been merged already in https://github.com/mne-tools/mne-python/blob/main/mne/viz/backends/_notebook.py though but I don't think it's really deployed and used yet in any GUIs so I think now is the crucial time to intervene.

I am wary of a huge refactoring because stuff almost always breaks. But if in the end it makes things more understandable and maintainable, it could be worth it. But the risk of potential additional breakage is high, especially since GUI stuff is very difficult to test with unit tests rather than direct manual interaction / use.
+1 for dwelling on it a bit and waiting -- it's always a challenge to understand someone else's code and why they made some choices. You've already started out thinking "this naming scheme doesn't any sense" but realized quickly why it had to be that way (due to how the subclasses are actually used). Let's hold off on a big refactor until you've used the code a bit and understand it through experience a bit. Especially because...

A lot of it has been merged already in https://github.com/mne-tools/mne-python/blob/main/mne/viz/backends/_notebook.py though but I don't think it's really deployed and used yet in any GUIs so I think now is the crucial time to intervene.

... this whole. abstraction came about precisely because we wanted to use it in Brain so that we could do things equivalently in the notebook and qt backends. So if you continue to look at the code, you should see all of these abstractions in use in Brain already somewhere.
So I would say let's wait until you need something new from the classes, then add it and get it working. Once that's done, if you still think things could be clearer, a refactoring is much more likely to go smoothly because you have direct experience modifying/improving/fixing bugs with the existing structure.

Yeah it's definitely in the coreg GUI, I just wasn't following those changes very closely. I don't get the whole concept of docks and toolbars and status bars being separate, pretty much unrelated entities, they're all things that hang around the sides of an application, why are they all separate? That's one of two main critiques. I know the Qt interface well enough to know that it can be abstracted as a bar so I assume it must be because of needs on the notebook side. The other main one is the different styles of returning objects vs setting attributes. This seems like a big code smell issue to me.

So I would say let's wait until you need something new from the classes, then add it and get it working. Once that's done, if > you still think things could be clearer, a refactoring is much more likely to go smoothly because you have direct experience > modifying/improving/fixing bugs with the existing structure.

The issue with that is that as soon as you stop running things through QMainWindow and run everything through the renderer, then you are either all in on abstraction or have this weird mix of calling abstract classes and also importing Qt objects which also sounds terrible. Since I clearly want/need to change things before using them, I'd have to see how that impacts the coreg GUI in Qt and also in the notebook implementation which is a huge overhead. I know that the PR that was written works, I just think it makes things 10x less elegant and I think harder to maintain down the road. I can move forward with incremental PRs that improve and synchronize across coreg Qt and notebook and ieeg_locate Qt but that will move slowly.

Yeah it's definitely in the coreg GUI

Yes, and Brain. So the iEEG GUI is the one remaining part of MNE-Python proper that doesn't use the Qt/notebook abstraction. (FWIW, I would have pushed for mne-qt-browser to use such an abstraction if possible/reasonable, but it wouldn't be because the underlying display must go through Qt because it's the drawing backend, so there is no real way to abstract it.)

I don't get the whole concept of docks and toolbars and status bars being separate, pretty much unrelated entities, they're all things that hang around the sides of an application, why are they all separate?

I could see it going either way, and really I don't think it makes a huge difference either way, does it? Typically you only create a toolbar (or don't), and a statusbar (or don't). Thinking of these abstractly as "things around the sides" doesn't seem that helpful as an abstraction to actually implement, even if it's true of where they typically are.

I know the Qt interface well enough to know that it can be abstracted as a bar

I guess, but typically in practice they are constructed by end users to direct calls to add/create QToolBar and add/create QStatusBar, not via some abstract class. So I'm not sure that Qt having them under the hood implemented as subclasses of a Bar or something really matters/helps us, does it? If it doesn't help us in some way, then we shouldn't bother implementing that deeper level of abstraction.

then you are either all in on abstraction

Yes this is the maintainable idea I think

Since I clearly want/need to change things before using them, I'd have to see how that impacts the coreg GUI in Qt and also in the notebook implementation which is a huge overhead

Indeed, the price we pay for this abstraction is that, instead of just using Qt directly, we need to create an abstraction for whatever new feature we need. This needs to be implemented and tested both places. To me the tradeoff so far has been worth it to have Notebook + Qt support in Brain and coreg.

I just think it makes things 10x less elegant and I think harder to maintain down the road

Maybe this particular implementation isn't perfect or easily understandable. But in the end it should make things simpler, assuming we want to support both Qt and Notebook in MNE-Python, and if we ever want to support one for any GUI. You understand the abstraction and you get the backend flexibility. The cost is that enhancements to the abstraction require implementation and testing at all levels.
So to me it sounds like you are arguing two points: first is that our abstraction is unclear, or not implemented as cleanly as it could be -- and this is entirely possible. But we've covered that above (sure let's change it, but hopefully later).
The second, though, seems to be that the abstraction is not useful, or that we shouldn't use it for the iEEG GUI. This part I think makes MNE-Python less maintainable in the long run, because instead of having to understand, implement, and test Qt in one place (our abstraction), we have to do so in two places (the iEEG GUI code and our abstraction).

The second, though, seems to be that the abstraction is not useful, or that we shouldn't use it for the iEEG GUI. This part I think makes MNE-Python less maintainable in the long run, because instead of having to understand, implement, and test Qt in one place (our abstraction), we have to do so in two places (the iEEG GUI code and our abstraction).

I think the abstraction is very useful, just think the things that were done for coreg that would apply to the ieeg_locate GUI need major rewrites. I might be wrong but there seems to be a growing consensus from people who did not write the coreg GUI that it's not very intuitive, which, to me means that it's probably good to have some rewriting there anyway. Maybe you could say the same about the ieeg_locate GUI as well but since it's just in Qt, it's much easier to change and doesn't effect the coreg GUI. Maybe the abstraction should mature with Qt and the coreg, ieeg_locate and TFR source viewer that I said I would write for GSoC before being ported to notebook so that the abstraction works for everyone rather than pigeonholing things to how they were done for coreg.

Also is there not a tutorial for the coreg GUI? I see https://mne.tools/dev/auto_tutorials/forward/20_source_alignment.html#defining-the-headmri-trans-using-the-gui but probably it would be nice to add executed code that pops up the GUI. I can open a separate issue.

so that the abstraction works for everyone rather than pigeonholing things to how they were done for coreg.

Hmm... you keep saying "just coreg", so somehow you must have missed the couple of times I've mentioned so far that it's used for Brain, too (and thus stc.plot, etc.). IIRC this is actually where it started, even though that's more a historical point:

Brain: https://github.com/mne-tools/mne-python/pull/6551
Brain: https://github.com/mne-tools/mne-python/pull/7758
Brain: https://github.com/mne-tools/mne-python/pull/8503
And later, coreg ported from traits/traitsui/mayavi to the existing abstraction: https://github.com/mne-tools/mne-python/pull/9689

So the idea has always been IIUC to have this abstraction and use it across MNE-Python wherever possible. Hence why I'm pushing back on the idea of scrapping what we already have and starting from scratch. We already have an abstraction that works decently even if it's not perfect, or ideally implemented. But maybe others have opinions on this point.
FWIW to me the coreg usability is really a separate issue, that has to do with user interactions and the user-facing GUI design and interaction. It seems like your concerns so far are about internal implementation details that are much less user-facing.

I can open a separate issue.

Please search first, I seem to recall that there are already one or two issues about coreg and its usage needing to be documented better

I need to look more into the Brain backend to comment more on that but that seems like it would be a bit easier to test and modify since the GUI is lighter.
The importance of returning the objects for things like status and toolbars is that then they can be modified in inherited objects (i.e. adding items to the toolbar) which seems pretty important. I think that would be one of the main things.

After thinking about it, the main issue comes from the Qt concept of a window vs no window for notebook as Guillaume had mentioned. I still think you need a holder, I'll just have to see how Render implements it. This abstraction should work for GUIs without a 3D component but right now it doesn't because of this issue.

Ok after looking more closely at both the brain and coreg implementations, I think the main issue that is the root cause of this redundancy is that everything is run through the renderer. I think this is hugely limiting not just because it creates inelegant code but also because it limits this abstraction to only apply to GUIs with 3D brains in them. The ieeg_locate GUI original plans did not have a 3D brain and the NutmegTrip GUI does not have a 3D brain so I think there are plenty of use-cases for that. As @larsoner had mentioned is not at all user-facing so the redundancy/inelegance of the code won't show up outside private functions but I still think this is a huge burden on developing new GUIs, especially when reusing parts as in the slice browser abstraction as well as limiting GUIs with this framework to those with 3D brains.
Hopefully the solution is to just make an AbtractApplication/AbstractGUI/AbstractWindow class and just reimplement things more elegantly using the Qt style. I can look into it, not sure if that will work with notebooks per previous comments of Guillaume although the renderer handles windows in this way so maybe it won't be hard at all.

hugely limiting not just because it creates inelegant code but also because it limits this abstraction ... this is a huge burden on developing new GUIs ... Hopefully the solution is to just make an AbtractApplication/AbstractGUI/AbstractWindow class and just reimplement things

@alexrockhill it sounds like your plan here is to start from scratch / start over, is that right? I am pretty opposed to this idea as it loses / discards all the progress we have made so far by testing and using the existing framework over the last year or two.

I think the main issue that is the root cause of this redundancy is that everything is run through the renderer.

A faster and hopefully easier solution (rather than starting an opposing/replacement implementation from scratch) would be the incremental addition of something like use_3d=True:

use_3d=True: a 3D scene use the old code (and window creation, etc.) to get a layout that you can put widgets into.
use_3d=False: a Qt window with just a layout (probably?) and a Notebook (probably?) are created directly by us instead of PyVista / ipyvtk.

So the only new code is really (2). At least conceptually this makes sense. There are probably bigger but still incremental refactorings we could do, too, but I'd probably save that for later.  For one example, we could:

Refactor the 3D plotting stuff out of Renderer
Rename Renderer to a new name like Window, Display, or GUI or something that has no 3D connotation, to make clear it just means "a Qt window or Notebook ipywidgets/layout-capable thing"
Add a way to add a 3D renderer to such a GUI. I think it should be possible in principle with both ipyvtklink and pyvistaqt, but we'd have to check.

But for any refactoring this big or bigger, I think it's critical before deciding what to do or beginning work that we have some visual depiction (ASCII art, graphviz, powerpoint, whatever) of 1) what we have now, and 2) what the proposed change is. I think it will really help guide things here, and seems like necessary due diligence for any larger change.

I think we're actually saying very close to the same thing, and I agree about talking about it more before writing code. Whether it's moving the 3D code out of Renderer or making a new class that handles just the window/scene or whatever you want to call it is a really important step but it's just semantics whether it's moving out of Renderer or making a new class, we're talking about the same thing.
I don't know about making new art or diagrams, I would just propose following more closely to what is done in Qt. I think I need to look into Renderer and the parts that are not 3D and implemented for the notebook backend to know what will work for notebook.
I'm not in favor of a use_3d that just seems like pushing the problem down the road. I don't really want to do a major refactor, I have better uses of my time, but it's possible that the refactor can be done in small steps and not be all that major. I agree with the second half of your last message, that seems like it should be the goal and is hopefully pretty reasonable.

I don't know about making new art or diagrams

It's nothing fancy, probably 10-20 minutes of work (easy) once you understand the actual hierarchy (hard). But understanding the existing hierarchy (the hard part) I think is a prerequisite here...
Here are a couple of simple examples you could work from

ASCII, probably the best example because it actually shows the inheritance: https://github.com/pyvista/pyvistaqt/blob/9334f9d937792cfa1f692e936b35b89a46260851/pyvistaqt/plotting.py#L5-L31

ASCII: https://github.com/mne-tools/mne-python/blob/93359566261be5c3fe7ceef8cb1fefce910cca52/mne/gui/_coreg_gui.py#L9-L32

Or if you prefer being programmatic and letting dot do the laying out for you, you can do what our doc builds do: https://github.com/mne-tools/mne-python/blob/main/doc/sphinxext/flow_diagram.py#L25-L72

Open up powerpoint, make boxes and lines

I really think it would help both the implementation and review stages. (1) and (2) would even be super helpful for maintenance. Just think about how such a thing could have helped you when looking at the code the first time...

::

   _AbstractGUI: The abstract class representing a Qt/notebook instance/window not necessarily 3D
   |-- Slice Browser: The window with panels that can be selected to change a slice and a 3D brain
   |    |--  ieeg_locate: The ieeg location GUI
   |    |   |--  Abstract bars, actions etc.
   |    |--  tfr_stc_viewer: The proposed TFR viewing GUI
   |-- coreg: The coregistration GUI
   |-- stc_viewer: The GUI that is initialized with `mne.viz.Brain.setup_time_viewer`

   _AbstractWindow: The abstract class representing a Qt/notebook instance/window not necessarily 3D
   |-- _AbstractPlayback: Abstraction of playback
   |-- _AbstractKeyPress: Keypress
   |-- _AbstractDialog: Dialog
   |-- _AbstractAction: Action
   |-- _AbstractLayout: Class for grid and ordered layouts
   |    |-- _AbstractDock: An abstract menu bar encompassing what is currently _AbstractToolBar, _AbstractMenuBar, _AbstractStatusBar (redundant)
   |-- _AbstractWidgetList: Controls list of widgets can have widgets added to
   |-- _AbstractWidget: the widgets
   |-- _AbstractMplInterface: mpl interface
   |-- _AbstractMplCanvas: canvas

Okay, I think that was pretty helpful, a lot of it is flat (not inherited) but it's nice to enumerate the functionality. I think the main thing is just making use of the _AbstractWindow that I didn't realize already exists and then having the layouts (toolbar, menu etc.) inherit from the _AbstractLayout. I think it's actually really simple, just 1) use the main window so that nothing has to get passed to the renderer and 2) manage the names of the menus within each gui specific to its use, that way the assembling of the components is done specifically for that GUI's use.

Just a little to do note for fixing this issue, it's not going to be done today but I don't think it's going to take that long actually, mostly just bookkeeping.
Abstract classes that need to be fixed:

[ ] _AbstractToolBar
[ ] _AbstractDock
[ ] _AbstractMenuBar
[ ] _AbstractStatusBar
[ ] _AbstractPlayback
[ ] _AbstractKeyPress
[ ] _AbstractDialog
[ ] _AbstractLayout
[ ] _AbstractWindow

Methods that already inherit so that they are not redundant and so are much easier to use 👍

_AbstractAction
_AbstractWidgetList
_AbstractWidget


Rewrite isolate server to be based on Cloud Endpoints API framework

Goal:
Switch from documentation is 'read the code' to documentation is 'a web page
generated automatically via Cloud Endpoints'.

AI:
- Write new API based on Cloud Endpoints.
- Update clients to use new APIs.
- Roll clients everywhere.
- Wait 1-2 months.
- Delete old API.

References:
https://cloud.google.com/appengine/docs/python/endpoints/
https://developers.google.com/apis-explorer/

Original issue reported on code.google.com by<EMAIL_ADDRESS>on 27 Nov 2014 at 2:51

Blocking: #180

It's done, we need to update the clients.


set readonly property of contentStorageAccount to false

fix a bug in streamAnalytics-2017-04-01-preview
MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Changelog
Please ensure to add changelog with this PR by answering the following questions.

What's the purpose of the update?

[ ] new service onboarding
[ ] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When you are targeting to deploy new service/feature to public regions? Please provide date, or month to public if date is not available yet.
When you expect to publish swagger? Please provide date, or month to public if date is not available yet.
If it's an update to existing version,  please select SDKs of specific language and CLIs that require refresh after swagger is published.

[ ] SDK of .NET (need service team to ensure code readiness)
[ ] SDK of Python
[ ] SDK of Java
[ ] SDK of Js
[ ] SDK of Go
[ ] PowerShell
[ ] CLI
[ ] Terraform
[ ] No, no need to refresh for updates in this PR

Contribution checklist:

[ ] I commit to follow the Breaking Change Policy of “no breaking changes
[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

[ ] Ensure to check this box if one of the following scenarios meet updates in the PR, so that label “WaitForARMFeedback” will be added automatically to involve ARM API Review. Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs, all “removals” and “adding a new property” no more require ARM API review.

Adding new API(s)
Adding a new API version
Adding a new service

[ ] Please ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If there are following updates in the PR, ensure to request an approval from API Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in stable version
[ ] Removing properties in stable version
[ ] Removing API version(s) in stable version
[ ] Updating API in stable version with Breaking Change Validation errors
[ ] Updating API(s) in preview over 1 year

To initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.

/azp run automation - sdk

/azp run

@fengzhou-msft  that change is a bug fix, could you help to check in?
Add @changlong-liu for awareness about readonly attribute changing.

@sunsw1994 does this change have customer impact? If so, it still needs review from breaking change review board.

@sunsw1994 does this change have customer impact? If so, it still needs review from breaking change review board.

It has customer impact, but it's a change for preview version, so I think it doesn't fit any of options of breaking change review checklist.

@akning-ms , could you help to merge this pr ? It's a small bug fix for preview sdk, customers can't change a property because we set it readonly mistakenly.

@akning-ms , could you help to merge this pr ? It's a small bug fix for preview sdk, customers can't change a property because we set it readonly mistakenly.

Is there any SDK released for this api version?

@akning-ms , could you help to merge this pr ? It's a small bug fix for preview sdk, customers can't change a property because we set it readonly mistakenly.

Is there any SDK released for this api version?

I think @sunsw1994 has release some sdk for this api version

according to @zhejun97 , service will GA in 2021.01. and will release python js .net SDK again after this fix. so approved this PR


CHEBI:139388, please CHECK

Hi Adnan,
Please check theacrine, as I need it for a Rhea reaction.
Cheers,
Kristian

Now Checked.


Add Dockerfile for Debian 10 plus changes for Debian 9

Same dependencies for Debian 10 as Ubuntu 20.04

Please advice how I test this. Locally and in CI?

@swift-ci Please test

n

n

CC @shahmishal

@swift-ci test

PASSED_swift-ci_master_debian_10.log
PASSED_swift-ci_master_debian_9.log

-- Looking for os_signpost_interval_begin - not found
CMake Error at /home/build-user/cmake/Modules/FindPackageHandleStandardArgs.cmake:146 (message):
  Could NOT find Python3 (missing: Python3_EXECUTABLE Interpreter)
Call Stack (most recent call first):
  /home/build-user/cmake/Modules/FindPackageHandleStandardArgs.cmake:393 (_FPHSA_FAILURE_MESSAGE)
  /home/build-user/cmake/Modules/FindPython/Support.cmake:2261 (find_package_handle_standard_args)
  /home/build-user/cmake/Modules/FindPython3.cmake:300 (include)
  CMakeLists.txt:711 (find_package)

-- Configuring incomplete, errors occurred!
See also "/home/build-user/build/buildbot_linux/llvm-linux-x86_64/CMakeFiles/CMakeOutput.log".
See also "/home/build-user/build/buildbot_linux/llvm-linux-x86_64/CMakeFiles/CMakeError.log".
Building the standard library for: swift-stdlib-linux-x86_64
Running Swift tests for: check-swift-all-linux-x86_64 check-swift-all-optimize-linux-x86_64
ERROR: command terminated with a non-zero exit status 1, aborting

ERROR: command terminated with a non-zero exit status 1, aborting

Debian 9 is missing python3.

Is debian 9 interesting? I know it's not EOL yet (June 30, 2022).

Sounds good, we can focus on getting Debian 10 configured.

/usr/bin/ld: lib/hwasan/CMakeFiles/RTHwasan_dynamic.x86_64.dir/hwasan.cpp.o: relocation R_X86_64_PC32 against undefined symbol `__ehdr_start' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: nonrepresentable section on output
clang-10: error: linker command failed with exit code 1 (use -v to see invocation)

Debian 10 failure - https://ci.swift.org/job/oss-swift-package-debian-10/2/console

hmm I would love to help, but I am not sure how I can. It is building on x86_64 which I also have..  and still failing..
This is happening in a Debian 10 virtual machine?

I can build on a real machine (but that won't be clean) and in a docker Debian (as clean as you have), but it seems that I am missing a bit of the puzzle.


when raise a subclass of HTTPError,  message field will be a list

when raise a subclass of HTTPError, the message field will be a list, it's different with when you raise a HTTPError directly
this is a demo
I'm not sure it's a bug or feature, but I think it should be consistent
except
{
  "detail": {

  },
  "message": "This pet is missing."
}

current
{
  "detail": {

  },
  "message": [
    "This pet is missing."
  ]
}

Environment:

Python version: 3.9
Flask version: 2.0.2
APIFlask version: 0.11.0

I think this is because you added a comma at the end of the string...
https://github.com/llt22/apiflask-demo/blob/main/main.py#L10

I think this is because you added a comma at the end of the string...
https://github.com/llt22/apiflask-demo/blob/main/main.py#L10

sorry!!!


circle ci broken by latest matplotlib release

the example plot_localizer_surface_analysis fails with matplotlib 3.1
since the latest matplotlib release, setting the aspect of an Axes3d results in
a error, which caused an error in nilearn's plot_surf_stat_map. The problem
has been fixed in nilearn:
https://github.com/nilearn/nilearn/pull/2070
but the fix has not been released yet.
maybe the simplest strategy is to pin the circle ci matplotlib to an older
version until the next nilearn release.

@kchawla-pi do you want to take care  of that ?

Sure. We already fixed this in Nilearn, it is not a difficult thing.
On Wed, Jun 12, 2019, 08:28 bthirion<EMAIL_ADDRESS>wrote:

@kchawla-pi https://github.com/kchawla-pi do you want to take care of
that ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/nistats/nistats/issues/358?email_source=notifications&email_token=AB6SXRHUECYU5ZQ4PQRMAE3P2CJPRA5CNFSM4HXDZ4M2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXPMJCI#issuecomment-501138569,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB6SXRHNVOQYDVKUDCKGAPLP2CJPRANCNFSM4HXDZ4MQ
.

Since the code that has been rendered incompatible is in Nilearn (fixed in master, not release), I have pinned MPL==3.0.3 in CircleCI Config.


Missing call ring when app isn't open on Windows

There is no information of how to make the application ring on Windows when it receives a call when the application is not open. We see Android and iOS have Push Notifications documentation but nothing for Windows.

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

ID: 45723fb2-21e8-8125-5c0d-1a5fba357fe3
Version Independent ID: f8208916-5b63-1379-8197-6dc497af1434
Content: Quickstart - Use the Azure Communication Services Calling SDK - An Azure Communication Services quickstart
Content Source: articles/communication-services/quickstarts/voice-video-calling/calling-client-samples.md
Service: azure-communication-services
GitHub Login: @RinaRish
Microsoft Alias: arturk

Thank you for reaching out. At this time we are reviewing the ask and will provide an update as appropriate

@MhAllan Thanks for the feedback! I have assigned the issue to the content author to review further and update the document as appropriate.

#assign:garchiro7

@MhAllan Thanks for the feedback. Currently, there is no Push Notification functionality available for our Windows SDK.


Fix: a few possible errors in the PlatformHandler.onError method

Information

Type
Breaking change

Fix
No

Fixed: #1812

:tada: This PR is included in version 6.107.4 :tada:
The release is available on:

v6.107.4
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 7.0.0-beta.4 :tada:
The release is available on:

v7.0.0-beta.4
GitHub release

Your semantic-release bot :package::rocket:


More beautiful welcome message

Right now, the "Welcome to WarriorJS" message has a lot of room for improvement:

Ideas and suggestions are welcome!

The only idea I can think of is having the logo in the terminal:

It's got some work to be done before being perfect - mainly on the sword - but it looks better then nothing.
Since we already have getScreenSize(), we can safely output it only when the screen is wide enough.

Here's the actual text for others to improve upon if they wish:
                                    ▁▁▁
                                    ▏●▕
                                    ▔▔▔
                                    ▌ ▐
                                    ▌ ▐
                                   ▂▄█▄▂
                                 ▞▀▀▀ ▀▀▀▚
                                    ● ●
▝█▖        ▗█▘▗▖    █▀▀▀▜▖ █▀▀▀▜▖   ● ●   ▗████▖ █▀▀▀▜▖     █ ▗████▛
 ▝█▖  ▗▖  ▗█▘▗██▖   █    █ █    █   ● ●   █▘  ▝█ █    █     █ █
  ▝█▖▗██▖▗█▘▗█▘▝█▖  █▄▄▄▟▘ █▄▄▄▟▘   ● ●   █    █ █▄▄▄▟▘     █ ▝████▖
   ▝██▘▝██▘▗█▄▄▄▄█▖ █  ▝█▖ █  ▝█▖   ● ●   █▖  ▗█ █  ▝█▖ █   █      █
    ▐▌  ▐▌▗█▘    ▝█▖█   ▝█▖█   ▝█▖  ● ●   ▝████▘ █   ▝█▖▝▙▄▟▘ ▟████▘
                                    ● ●
                                    ● ●
                                    ● ●
                                    ● ●
                                    ▚ ▞
                                     ▀

It doesn't look correct in most text editors, you gotta view it in a terminal for the spacing to line up perfectly.

It's made with mostly unicode bock elements, thought it would look fuller then a bunch of @ symbols.

I made the sword more sword-like when implementing your changes, and it looks nice with the colored sword:

I'm not versed in ASCII art, so instead of a full-fledged logo I've designed this little thing (in ~1min so I'm sure someone can do way better with some work !)  :

Imo this kind of little logo it is closer to the "design" of the game than RascalTwo's proposition.
Else I've got two nice results using this site (TAAG), that could be good for inspiration but I still think a custom message would be better :

Small update to show how it looks ingame :


Rate limit

Hello @rbranson @tsholmes @ndhoule @thehydroimpulse
Here is a first try on the rate implementation for drip.
Right now it is just on the identify call.
Would be glad to have some feedback to see if I’m going on the right
direction.
Also I’m not sure about the re enqueuing mechanics. Any hint would be
welcome.

@tsholmes
Just refactored to use setLimit only on OK status and 429.
Being the last condition checked, reset is set 5 min after from when setLimit is called . This allows tu regularly check the cooldown has been reset and we would not depend of Radom changes from Drip side.
Let me know if some other thing should be changed.

@tsholmes
Just refactored with your suggestions.
Added a few test for limit and setLimit.
Also I commented the random condition in limit.
I think the try turnover is already good with the 5 min interval.
Let me know what you think.

Thanks @tsholmes
Just refactored with your feedbacks.


Have the ability of hidden some command error

What I have:
# go-dcpp/dcping ping "dchub://XXX.ddns.net:6669" --out=xml
2019/03/03 22:18:18 dial tcp <IP_ADDRESS>:6669: connect: connection refused
<Hub Name="" Address="dchub://morrisonhotel.ddns.net:6669" Status="Offline"></Hub>

↑ is it possible to add something (for example a command --quiet) to only show:
# go-dcpp/dcping ping "dchub://XXX.ddns.net:6669" --out=xml
<Hub Name="" Address="dchub://morrisonhotel.ddns.net:6669" Status="Offline"></Hub>

It writes errors on different stream (stderr), so it should be possible to ignore it.

Something like:
go-dcpp/dcping ping "dchub://XXX.ddns.net:6669" --out=xml 2> /dev/null

You can close it, I just have to ignore sterr. Thanks


ImportCommand should use BatchImport

The current ImportCommand implementation does not use BatchImport which is performance-wise suboptimal.

While I agree that this is a desirable optimization, I must nevertheless ask: Have you tried the -t (single transaction) option for the import command?

No updated in #96, that's indeed faster. Should've read the documentation...


Fixed offer card title width

Fixed offer card title width.
Before:

After fixing:

Your solution is good! However, I'm not sure that such a different shift in content on the cards looks good.
A possible solution is to leave space for the second line in advance, but I'm not sure if this is better than the current result.
What do you think?

It's a great proposal. Unfortunately, on the mockup we can see only cards with long titles, so I have no idea, what the designer's vision was about one-line titles. Maybe we could wait for details about the design before changing this look.


Advance expression for AnimationTree doesn't seem to work

Godot version
v4.0.alpha.calinou [caa9ec8ac]
System information
Windows 10, Vulkan
Issue description
I'm using a simple state machine within the AnimationTree

Along with Advance Expressions like (this one is for idle_1 to walking):

However, it simply doesn't trigger the transition
Steps to reproduce

Create a CharacterBody3D
Drop a model with animations (a gltf with a character for example) inside the CharacterBody3D
Add an AnimationTree node, assign it to the AnimationPlayer from your model, enable it and assign the Advance expression base node to be the CharacterBody3D
Create a new Tree Root in your AnimationTree. I used a simple State Machine.
Setup your tree using Advance Expressions. I just created an idle and a walking state, with a transition idle->walking using the expression "velocity.length()>1.0"
Check the results in-game

Minimal reproduction project
TestExpressions.zip

For reference, advance expressions were added in https://github.com/godotengine/godot/pull/61196.
cc @fire

I'll take a look. Is length a const method?

You can set the expression to simply true and it still won't advance if Expression Base Node has been assigned on the transition. But if I clear the Expression Base Node, it does trigger, as long as Advance Expression Base Node is set on the AnimationTree itself.

I also just noticed that which node I assign to Advance Expression Base Node doesn't matter. The expression will always be executed in the context of the AnimationTree node.

any news about this?

Hey, I've created a new pull request #63238 that solves this issue

Nice. I have a theory about the second issue: why not even true works when Expression Base Node is set on the transition itself.
When you set the node property in the inspector on the transition, the editor makes a path that is relative to the scene root.
When you set the corresponding property on the AnimationPlayer you get a path that is relative to the player node.
The path is then used relative to the AnimationTree node with tree_base->get_node_or_null(advance_expression_base_node_path) which is correct in one case but wrong in the other. The expression is then silently ignored if the path can't be resolved.
I assume this happens because AnimationNodeStateMachineTransition is not a node but a resource, and therefore not part of the tree, so the path can't be made relative to it.

I'm not sure how to solve that

Maybe the solution is to take a step back. Should this base node property exist on the individual transitions in the first place? It creates dependencies deep inside a nested resource on the structure of the node tree in which the resource will be used. Doesn't seem like something that should be encouraged.

It seems that the issue is still present in alpha17, no matter the expression you put, even if you write true directly, the transition does not happen.
I don't think attaching a reproduction project is needed because it's simply the same issue as OP - or simply write true in the expression, there's no transition.

@alfredbaudisch Are you setting the Expression Base Node field directly on the transition? There were two parts to this issue. One was fixed and one was not.
IIRC, if you set the expression base node only on the animation tree and not on the transition then it should work now.
That field should be removed from the transition node unless someone can figure out a solution.

Yep, precisely what @permelin said. If you leave the Base Node blank, it will work (and use the animation tree node as the source for the variables).

Are you setting the Expression Base Node field directly on the transition?

That was it, thanks. Confirmed the issue as you said: setting in the animation tree directly made it work, on the other hand the transition base node is ignored.

@akien-mga I was testing and my previous fix does not work if there are autoloaded nodes in the tree, this issue should probably be reopened.

Thanks for testing!

I'm sorry for not testing it in depth to begin with!


[release/1.5] Fix panic in metadata content writer on copy error

The createAndCopy function is only called when nw.w is nil
in order to create a new writer and prepare it. The current code
is attempting to close nw.w when there is a copy error. The
correct behavior would be to close the new writer and not touch nw.w.
Signed-off-by: Derek McGowan<EMAIL_ADDRESS>(cherry picked from commit b9cf0d75a9f4a8a09ab55caa1983a8988ba4834d)
Signed-off-by: Derek McGowan<EMAIL_ADDRESS>

backport of https://github.com/containerd/containerd/pull/6043


Local components inheritance

This topic was discussed a long time ago in #1297, but I want to return to it, because I think many developers will benefit of this feature.
We all try to make apps as modular as possible. Moreover, component approach forces us to make many simple, mostly stateless, components. All these components are set in tree-like hierarchy, that often leads to situation, when some set of components is used in only one branch of this tree. In this case registering components globally is a bad thing, obviously — we should register them globally only if they are truly global, if they are used all over the app. On the other hand registering them locally will lead to code overbloat and repeatings, that rises possibility of errors and makes app support harder.
I'll show a real example, an app I am currently working on (but there are many other cases). structure is cutted just to illustrate the case
app
|-blog
|-projects-registry
|-presentation-builder
|-|-menu
|-|-previews
|-|-|-slides-templates
|-|-editor
|-|-|-slides-templates

So in an app there is a presentation-builder that can be considered a a sort of sub-application (it's a thing like keynote or powerpoint). It consists of various components, but the key here are slides-templates, that are used only in builder, but in various sub-components (in previews, editor and more). There are lots (tens) o templates, but they are never used outside the builder.
Obviously, it is not good to register them globally. It's also obviously that repeated local registration of 10—20—30 components in many places is horrible.
Yes, probably I could collect these components in a single file, that will export an object with them and require this file in several places. With es6 object destruction this can work not bad. In fact, that's the way I am forced to do it now:
// components/slides/index.js
export default {
    'slide-idea': require('./slide-idea.vue'),
    //....
}

// editor.vue
...
<script>
  export default {
    components: {
      ...require('../../components/slides').default
    },
   //...
</script>

But I really don't think that it is a proper solution, it's more like a hack and this will not work in more granular cases.
I also don't think that local components inheritance will break dependency tree's lucidity, especially with vue inspector that could tip you where this component came from.
Maybe this type of components should b registered in other property, not in components, but in something like globalComponents or sharedComponents, this is a thing to think of, but I suggest that this feature will make life easier in many scenarios.

Just to make sure, would this be a correct TLDR; ?

Importing individual components in a large application becomes troublesome and registering them globally may break things. Components defined on a Parent Component should be available from its children components.

@posva well, yes. Maybe even "Component should be optionally available from its children components"

@terion-name Sorry, I had this on hold. I think it's a nice idea. It needs further discussion, though. Let me discuss this with the team and come back with some proposals. IMO having custom *components properties is not ideal. I'd rather have this as the default behaviour for the components properties: components being able to use declared components on parent components.

This was the behavior in a very early version (0.x) but changed to what it is now. The general rule of thumb is:

You should be able to locate the child components used in a component by looking at that component's code.

Implicitly inheriting components, no matter how it is done, does break dependency tree's lucidity, in that when you look at a component's code, you cannot be sure where the child component it used came from.
Explicitly importing child components sure leads to repetition. But in my opinion, contrary to your argument that it "rises possibility of errors and makes app support harder", it makes your code more robust and easier to read/follow/maintain. In fact, your approach of collecting components in a single file is a good middleground and is what I would probably do if I run into similar situations.

Hello, I think this limitation limited a good design pattern.
I have a relatively universal Layout component, but the content is configurable by the components that use the Layout component, eg. component A use Layout and want to configure its content with component B, some other component may use Layout and configure its content with component C, etc.
Should this pattern be supported?
Or is there any solution to replace this design?


Adding release checklist

Initial PR for a release checklist.
Creating PR now to get feedback - let me know any thoughts, or feel free to contribute.
I know this is missing integration testing - if somebody's bored, feel free to add, otherwise I'll get that in soon.

Thank you @jlk for this PR!


GDPR

Feature Request
GDPR information message on login page.
Feature Information:
Can you add the ability to add a GDPR warning with a link to a policies page that we can optionally enable and edit from AMP config, that would appear on the login page the first time people visit similar to the messages you find on most websites.
I am imagining a section within the AMP config menu that relates to the login page, and within this a GDPR enable button, this would then show a few options to include an editable policies section and a setting as to how long before the message will re-appear  to the user.
here is a link to a service that came up with a quick google search that offers information an example of what I mean https://www.cookiebot.com/en/pricing/
My understanding is if the warning and policies aren't there even if people stumble upon the site in error then the site/domain owner can be prosecuted if located within an EU country.
I'm just thinking as an idea to cover one's backside for the EU users
I confirm:

[X] that I have searched for an existing feature request matching the description.

AMP does not use any tracking cookies. Since it doesn't track the user across sites or keep any information that is sent to advertisers or third parties it's already compliant. There is no need for a prompt if you're only using functional cookies for logins.


Generify VisTree

To match the underlying Tree implementation.

Thanks

Could you make a release that includes this fix? Thanks

I've uploaded new snapshot


chore: remove arb-bridge-eth in favour of nitro contracts

util libraries were copied in from the package
others were imported from the new nitro package

rip


Refine the size() calculation of accumulator

Which issue does this PR close?

Closes #5903.
Rationale for this change

From the flame graph generated by
CARGO_PROFILE_RELEASE_DEBUG=true cargo flamegraph --no-inline --freq 500 --bin tpch -- benchmark datafusion --path ./data-parquet/ --format parquet --partitions 1 -q 17 --iterations 10

There are around 4% spent on calling the size() of accumulator, which can be improved.
What changes are included in this PR?

Avoid unnecessary calling of ScalarValue's size().
Avoid duplicated calculation of the initial size of accumulator_set.
Pull out the mode check to the top level to avoid if-else judgement for every group.

After applying this PR, from the flame graph, we can see there's almost no cost on the size() of accumulator. The benchmark result is improved from 11s to 10.5s.

Are these changes tested?

Are there any user-facing changes?

Hi @Dandandan, @alamb, could you help review this PR?

I will try and review this carefully later today

I am trying to clean up outstanding PRs and I came across this one. What shall we do with it @yahoNanJing  -- should we pursue getting it merged?

Since this has been open for more than a year, closing it down. Feel free to reopen if/when you keep working on it.


fix: Roll back onDidConnect hook

initial comment: https://github.com/microsoft/vscode-gradle/issues/1191#issuecomment-1055085709. We'd better refresh the view after re-connecting to the server.
In https://github.com/microsoft/vscode-gradle/issues/903 we just remove this hook for refreshing after the client connected to the server, for a VS Code upstream bug: https://github.com/microsoft/vscode/issues/129019. Now the bug is fixed, and we can consider to rollback this change to see if the issue in #903 will appear again. This change can be kept in pre-release versions for the feedback of developers and users.

Is it working with latest vscode now? Better try it by yourself before merging it.

Is it working with latest vscode now? Better try it by yourself before merging it.

Yeah, I did a test with latest vscode and it works.


✨ feat: implement call function with no return

(Sorry for the continuous posting.)
This PR allows function calls with no return value.
driver.call("hello")
driver.call("print_add", 1, 2)
driver.call("other_any_func", 1, "a", true)

Based on this PR, I think we can soon make a version with a return value.

New features are welcome. Thanks!

Thank you for writing README for this, and new breaking changes!


Is there a way to recover the actual errors after they have been collected with InputErrorRecoverer?

When the parser tries to parse a BibTeX entry that it already has, using the Parser.parse() function, does so using a recoverer.
The exception thrown should include information about why it failed, and, as seen in line 274 of bib.py:
self._fail('repeated entry')

this is programmed. But the recoverer only throws the amount of input errors, not the message. Is there a way to catch this message? It is important to me to be able to know why the exception is being thrown.

I ran into this same issue as well. I think the intended outcome is that the parser skip the repeat and continue, but for me it raises an exception and some .bib files simply can't be parsed for me. Perhaps I'm mistaken, but it doesn't seem like this library is actively maintained, which is too bad, cause the author's criticism of the alternatives is still valid.


⚠ Spryr has degraded performance

In ba44aec, Spryr (https://spryr.com) experienced degraded performance:

HTTP code: 200
Response time: 3182 ms

Resolved: Spryr performance has improved in 30c3b8f after 8 minutes.


Support connect protocol natively (without proxy)

I believe it would make sense for the substreams server to support the Connect protocol natively (without requiring a proxy). I see that there's already https://github.com/streamingfast/dgrpc/tree/develop/server/connect-web ... Let's use that? ;-)

Note that the Connect protocol technically also suports serving the response in JSON directly. That feature would require the server runtime to have access to the full proto schema. Since we are not sending the full .spkg to the server, the DescriptorSet is not part of the request. Therefore, we do not have the necessary information to support this feature. Not sure what to do about that... Either just not support JSON requests (imho reasonable), or change the .blocks grpc method to receive the full package in the request. Alternatively, we can also add a second service method .blocksFromPackage (yikes), that can support JSON and leave the current .blocks method to only support binary requests.

In the case of JSON, the server will send out json-encoded response with base64-encoded "protobuf.Any" bytes for the client to decode. There is no simple way for the server to do the decoding on-the-fly "per request" (the dynamic proto libs are usually set up to have a "global registry", which would cause many headaches).
Correct me if I'm wrong, but I don't think that decoding the app-specific payload server-side is actually needed for a good dev flow, the JS can do it on the browser.
I'm working on this issue right now, we have to change how the substreams apps (tier1 and tier2) are defined, because right now they are attached to firehose and we don't want to connectweb-ify the full firehose stack at the moment.
#morethan5minutes

Re:

I'm working on this issue right now, we have to change how the substreams apps (tier1 and tier2) are defined, because

It will be good to have the "tier2" identified as a separate app anyway.  Right now looking at dashboard can't tell which "app=firehose" is a tier 1 vs tier 2.

Hey @sduchesneau are you still on the toilet?

@sduchesneau completed it!


Air to Water Heat Pump Support

Hi and thank you for the addon.
Finally i am able to control my air to water heat pump but only as a climate, meaning that i can only set mode and target air temprature.
It would be great if i could also set water temperature and also DHW. All these features are availble on app and also on wideq but not on homeassistant.

Can you provide JSON information for your device?

Do you mean from wideq?

No, just following this instruction.

I think i got it
9377afbf-d173-484c-85e9-e9f9d7bed78e.txt

Just wondering how this feature should be managed in HA. Probably it is only possible creating dedicated services? Could you add some screenshot of LG app to have an idea of what could be done,

I have no idea how can this been added to HA but I really appreciate you even thinking about it

Please, clarify me some point:

what are you able to do now with HA? What are you able to control and what not?
what do you mean when yo say these features are available also on wideq. Which wideq version you are referring?

I am able to select heat/cool/auto/off
Temperature sensor always show current room air temperature.
Heat pump is setup to operate based on water temperature and when i turn it on climate entity shows as target the water temperature target but sensor shows room air temperature.
check below

I had used https://github.com/sampsyo/wideq and with ls i could see all sensors.

I do not understand how is possible that you are able to get values using original wideq, this version only support ThinQ1 device and you have ThinQ2 device.
I will try to add few sensors with next release, let's check if this information are available in payload...

You are wright my mistake
i used https://github.com/no2chem/wideq
and this is the output
{   'data': {   'alias': 'Heat '
'Pump',
'appModuleSize': 6780068,
'appModuleUri': 'https://objectcontent.lgthinq.com/2d45fa6d-7ddc-4f23-a73a-6519ce54af13?hdnts=exp=1667806054~hmac=fc0cc0ea4bf5de1e46f21f40ae675577f8389dada138df27e9f43a1e9b38d36b',
'appModuleVer': 14.17,
'appRestartYn': 'Y',
'appType': 'NUTS',
'area': 2282177,
'autoOrderYn': 'N',
'blackboxYn': 'Y',
'combinedProductYn': 'N',
'controllableYn': 'Y',
'countryCode': 'US',
'curOffset': 3,
'curOffsetDisplay': '+03:00',
'deviceCode': 'AI05',
'deviceId': '31bb1bf0-b1e7-17bb-9338-acf1088fa92e',
'deviceState': 'E',
'deviceType': 401,
'drServiceYn': 'N',
'dstOffset': 3,
'dstOffsetDisplay': '+03:00',
'existsEntryPopup': 'N',
'fwInfoList': [   ],
'fwVer': '',
'groupableYn': 'Y',
'guideType': 'TYPE5',
'guideTypeYn': 'Y',
'imageFileName': 'home_appliances_img_boiler.png',
'imageUrl': 'https://objectstore.lgthinq.com/3e4efd50-df2a-4a2f-ab1f-a23b3c69bd43?Expires=1643850013&Signature=CrHXYZQsz7kRL5KZ6F5qqzM0FyY-HT8UZsgg7RO6afBlan9lfFqmDxhNhX-2-rvYF6pijPXtZxOCoSlQkZqQUyIQKOVQ4t8zpQZ~Tn59oJh0ml2uQ~M1ncOlLpcWfkUH7aAXSFkx4nsXTWiA1~IKJlU14L5-XiYwJz3pKXJbpRzbdpOijrzVoQce8ZAADyzxM-3M7jHrAx~7lMCIxW6kZVJYIs9P7jngKOipbLvC-N6BBQBpRRJUjR-t0y4rZmjo8ozZCnwru7U-YC2qT~lK6pEkRmPQ71EDsv9vfNxpwQRyqtNJ8v-aRyuHc0ZpV1OQh39FC~Jb0X7LDJlQbJOs8Q__&Key-Pair-Id=APKAI74R6YENXPGRIWLQ',
'initDevice': False,
'langPackProductTypeUri': 'https://objectcontent.lgthinq.com/e88d10b2-4434-4dd3-87f5-6262ba52add0?hdnts=exp=1684366773~hmac=91bf717ef627802b18db105f704d71fd8d3fbef66ca78acd558d8dbbbf4441e2',
'langPackProductTypeVer': 49.0,
'macAddress': '',
'masterYn': 'Y',
'modelCountryCode': 'WW',
'modelJsonUri': 'https://objectcontent.lgthinq.com/9377afbf-d173-484c-85e9-e9f9d7bed78e?hdnts=exp=1681681327~hmac=209e9633641bcf4255c25725c01d66e3faaa84989ca4111f2d5ce9f55aae3362',
'modelJsonVer': 15.3,
'modelName': 'AWHP_019101_WW',
'modelProtocol': 'STANDARD',
'modemInfo': {   'appVersion': 'clip_hna_v1.9.078',
'modelName': 'AWHP_019101_WW',
'modemType': 'QCOM_QCA4010',
'ruleEngine': 'y'},
'networkType': '02',
'newRegYn': 'N',
'online': True,
'order': 0,
'pccModelYn': 'N',
'platformType': 'thinq2',
'regDt':<PHONE_NUMBER>5453.0,
'regDtUtc': '20210128095453',
'regIndex': 0,
'remoteControlType': 'REMO_CST_WIRED_RS3',
'sdsGuide': '{"deviceCode":"AI04"}',
'smallImageUrl': 'https://objectstore.lgthinq.com/d211574c-171f-4ab5-bf4e-39da49e0f123?Expires=1641524426&Signature=A~nTdONbSQC9yQA81aDyOrEHcf-NJQEM6~pkjOKdiDj49gqVgotgyEfW~rOHCOXFlngRLiLGP48oRT7ywJ6jItsNdhCSxKOh1zZqm4Unw~W6iLF~szVD~6Bj8PyrkNovYCPOWWcORgVR0azz8uM8LOC2bicn5gs4k7qSFyHoPnaYmiHR3XCQeuF7b5Tjpgo2-b5l59OLI-cRu4pFpxfE0i1US7xuZbOq0xhLg5mFEuJ-MUlI04W21HNFWwcm0Pxp5s9dRM4s8mWOXMbHFTp54zaGL9-iJgOfTo4IV31xZZ5myr28ecyJ7~EhhCaBKb6c5OTZCQGQF5b88qv7RfDsIg__&Key-Pair-Id=APKAI74R6YENXPGRIWLQ',
'snapshot': {   'airState.diagCode': 0.0,
'airState.miscFuncState.awhpTempSwitch': 1.0,
'airState.miscFuncState.awhpWaterControl': 0.0,
'airState.miscFuncState.extraOp': 0.0,
'airState.miscFuncState.hotWater': 0.0,
'airState.opMode': 0.0,
'airState.operation': 0.0,
'airState.quality.sensorMon': 0.0,
'airState.tempState.airTempCoolMax': 30.0,
'airState.tempState.airTempCoolMin': 16.0,
'airState.tempState.airTempHeatMax': 30.0,
'airState.tempState.airTempHeatMin': 16.0,
'airState.tempState.current': 24.0,
'airState.tempState.hotWaterCurrent': 21.5,
'airState.tempState.hotWaterTarget': 50.0,
'airState.tempState.hotWaterTempMax': 55.0,
'airState.tempState.hotWaterTempMin': 40.0,
'airState.tempState.inWaterCurrent': 23.5,
'airState.tempState.outWaterCurrent': 24.5,
'airState.tempState.target': 10.0,
'airState.tempState.waterTempCoolMax': 24.0,
'airState.tempState.waterTempCoolMin': 5.0,
'airState.tempState.waterTempHeatMax': 60.0,
'airState.tempState.waterTempHeatMin': 30.0,
'meta': {   'allDeviceInfoUpdate': False,
'messageId': 'uYTgVJDARq6ehXNmVjLMnA'},
'mid': 367967372.0,
'online': True,
'static': {   'countryCode': 'US',
'deviceType': '401'},
'timestamp':<PHONE_NUMBER>851.0},
'softapId': '',
'softapPass': '',
'ssid': 'My '
'Home',
'tclcount': 0,
'tftYn': 'N',
'timezoneCode': 'Europe/Athens',
'timezoneCodeAlias': 'Europe/Athens',
'userNo': 'US2101286532332',
'utcOffset': 2,
'utcOffsetDisplay': '+02:00'}}

Ok, this is useful. To better understand, leaving for the moment hotWater control, what are the values that you would need to be used in the climate control (current, target, men and max) from the list above?
I suppose:

current temperature: airState.tempState.outWaterCurrent'
target temperature: airState.tempState.target
min temperature: airState.tempState.waterTempCoolMin
max temperature; airState.tempState.waterTempHeatMax

I think that yes these seems to be fine

Can you provide feedback using last version of integration?

Everything seems to works fine
i will come back after checking more

Hello,
Some actions that will make exactly the same experience as with LG remote control and app:
When in cool mode set min_temp as “airState.tempState.waterTempCoolMin”
When in cool mode set max_temp as “airState.tempState.waterTempCoolMax”
When in heat mode set min_temp as “airState.tempState.waterTempHeatMin”
When in heat mode set max_temp as “airState.tempState.waterTempHeatMax”
When in auto mode the interface is changing as below with -5 to +5 offset

As I saw 0 is represented with 'airState.tempState.target': 17.0
+3 with 'airState.tempState.target': 20.0
-4 with 'airState.tempState.target': 13.0
Etc
Of course, I don’t know if all this are feasible on integration level.
I believe they are feasible with custom thermostat, but all values must be inserted to home assistant
Finally the also hot water should be added
Regards,
Kostas

I've just integrated an HM161M AWHP.
It would be great to see these sensors and I would also like to include the "quiet mode" option (this is a low power mode which reduces the noise generated by the AWHP - useful at night)


Minor visual improvements

Overview
This task contains a list of minor improvements that can be made to the current implementation to make it more user-friendly.
Subtasks

[x] Change the notice / alert notification to be on top of the header and fade away after a few seconds (or a click from the user). It is currently positioned at the top of the screen but pushes down the rest of the page.
[ ] Improve form errors and implement a foundational framework for all future forms to use. Errors should appear under the concerned field with the input border becoming red. Currently, all errors are displayed at the top of the form which can be confusing for users for some of our long forms.

PR created: https://github.com/codeforamerica/classifyr/pull/75


Operation state for service broker requests

Support for a optional operation field from service brokers, while async provisioning, updating and deleting of services. The operation filed is sent to the broker on last operation invocations.

[X] Provisioning
[x] Updating
[x] De-provisioning

Tracker stories:
https://www.pivotaltracker.com/n/projects/966314/stories/120654839
https://www.pivotaltracker.com/n/projects/966314/stories/120595477
https://www.pivotaltracker.com/n/projects/966314/stories/120595531
Paring with @Dagrol

This has been merged. Please let use know if you see any further issues!


[release-v1.2] Add kafka all manifest

For a more convenient consumption of knative kafka midstream, adding a new eventing-kafka-all.yaml manifest.

/assign @pierDipi

what's the use case?
In upstream we use for the name eventing-kafka.yaml

That folks can just use this single file, instead of a bunch of files. Like RHOSE as midstream users. Mostly for their convenience.
I can change the name

@pierDipi updated

/retest

/retest
On Tue 5. Jul 2022 at 12:06, openshift-ci[bot] @.***>
wrote:

@matzew https://github.com/matzew: The following tests failed, say
/retest to rerun all failed tests or /retest-required to rerun all
mandatory failed tests:
Test name Commit Details Required Rerun command
ci/prow/410-e2e-aws-ocp-410 e6aacc1
https://github.com/openshift-knative/eventing-kafka-broker/commit/e6aacc1001d1079d079dea4ab5ae1ff4c9c84b30
link
https://prow.ci.openshift.org/view/gs/origin-ci-test/pr-logs/pull/openshift-knative_eventing-kafka-broker/322/pull-ci-openshift-knative-eventing-kafka-broker-release-v1.2-410-e2e-aws-ocp-410/1544249169152053248
true /test 410-e2e-aws-ocp-410
ci/prow/49-e2e-aws-ocp-49 e6aacc1
https://github.com/openshift-knative/eventing-kafka-broker/commit/e6aacc1001d1079d079dea4ab5ae1ff4c9c84b30
link
https://prow.ci.openshift.org/view/gs/origin-ci-test/pr-logs/pull/openshift-knative_eventing-kafka-broker/322/pull-ci-openshift-knative-eventing-kafka-broker-release-v1.2-49-e2e-aws-ocp-49/1544249170896883712
true /test 49-e2e-aws-ocp-49
ci/prow/410-reconciler-aws-ocp-410 e6aacc1
https://github.com/openshift-knative/eventing-kafka-broker/commit/e6aacc1001d1079d079dea4ab5ae1ff4c9c84b30
link
https://prow.ci.openshift.org/view/gs/origin-ci-test/pr-logs/pull/openshift-knative_eventing-kafka-broker/322/pull-ci-openshift-knative-eventing-kafka-broker-release-v1.2-410-reconciler-aws-ocp-410/1544260293645832192
true /test 410-reconciler-aws-ocp-410
Full PR test history
https://prow.ci.openshift.org/pr-history?org=openshift-knative&repo=eventing-kafka-broker&pr=322.
Your PR dashboard
https://prow.ci.openshift.org/pr?query=is:pr+state:open+author:matzew.
Instructions for interacting with me using PR comments are available here
https://git.k8s.io/community/contributors/guide/pull-requests.md. If
you have questions or suggestions related to my behavior, please file an
issue against the kubernetes/test-infra
https://github.com/kubernetes/test-infra/issues/new?title=Prow issue:
repository. I understand the commands that are listed here
https://go.k8s.io/bot-commands.
—
Reply to this email directly, view it on GitHub
https://github.com/openshift-knative/eventing-kafka-broker/pull/322#issuecomment-1174875913,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABGPTXRIKPMASSB2VBJN7LVSQCKDANCNFSM52VOVF6Q
.
You are receiving this because you were mentioned.Message ID:
@.***>

--
Sent from Gmail Mobile

/test 410-reconciler-aws-ocp-410

/test 410-reconciler-aws-ocp-410


Update governance.md

Signed-off-by: Vitek Vlcek<EMAIL_ADDRESS>fixed broken links

Signed-off-by: Vitek Vlcek<EMAIL_ADDRESS>

Closing since there isn't a DCO signoff - replaced by https://github.com/zowe/zlc/pull/128


Website is currently down

Description
Hi folks,
The React Native site is currently down and reporting a 521 error.
Is there an ETA when the site will be back up?
Version
N/A
Output of npx react-native info
N/A
Steps to reproduce
Within your browser, go to https://reactnative.dev/
Snack, code example, screenshot, or link to a repository

still down??


feat: add global counters for bytes_read & iops for benchmarking utility

This is a small change and not essential but has been useful for me for benchmarking and it might be nice to have it available.

Codecov Report
Attention: Patch coverage is 50.00000% with 10 lines in your changes missing coverage. Please review.

Project coverage is 79.02%. Comparing base (38a0a92) to head (b3fa19c).
Report is 2 commits behind head on main.

Files with missing lines
Patch %
Lines

rust/lance-io/src/scheduler.rs
25.00%
6 Missing :warning:

rust/lance-core/src/datatypes.rs
66.66%
2 Missing and 2 partials :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3321      +/-   ##
==========================================
+ Coverage   78.97%   79.02%   +0.05%
==========================================
  Files         246      246
  Lines       87628    87643      +15
  Branches    87628    87643      +15
==========================================
+ Hits        69202    69262      +60
+ Misses      15558    15513      -45
  Partials     2868     2868

Flag
Coverage Δ

unittests
79.02% <50.00%> (+0.05%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

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


Add Application.AddLabel method.

Similar to AddEnv, the method makes sure that the Labels map is initialized before adding an item.

As the change looks consistent to what the AddEnv does, in my opinion it would be better to remove the smart setters and initialize the structs inside of the constructor. Examples:

http://stackoverflow.com/questions/4498998/how-to-initialize-members-in-go-struct
http://stackoverflow.com/questions/27553399/golang-how-to-initialize-a-map-field-within-a-struct

In this case I would remove the similar setter and modify NewDockerApplication constructor.
Also it could make sense to remove getters as well since the variables are exported and there's almost no transformation logic (in another PR).
@gambol99 what do you think about it?

To me, it boils down to the question of how DSL-ish go-marathon wants to be: Most application fields come with setters to allow for a fluent usage; however, a few are missed out (like Labels and User). Was this intentional, and if so, what's the criteria under which a setter is added or not? On the contrary, if they were really just overlooked, I'd opt to have the AddLabel convenience setter for consisteny and usability reasons.
Removing existing methods would imply a breaking API change. Does the project follow a particular policy regarding API stability?
@eicca, you mention removing getters too. Which ones do you mean exactly? At least for Env and Labels,  there doesn't seem to be any getters.
Happy to implement whatever approach we decide to take on!

Removing existing methods would imply a breaking API change. Does the project follow a particular policy regarding API stability?

It's a good point. I assume that the project is in early state since we're breaking API almost in every second PR. Maybe we can mention this in the README. I think it will stabilize soon together with Marathon.

@eicca, you mention removing getters too. Which ones do you mean exactly? At least for Env and Labels, there doesn't seem to be any getters.

Oh, I'm sorry, I was wrong, there are only setters of course. I was confused because of the convention https://golang.org/doc/effective_go.html#Getters

To me, it boils down to the question of how DSL-ish go-marathon wants to be: Most application fields come with setters to allow for a fluent usage; however, a few are missed out (like Labels and User). Was this intentional, and if so, what's the criteria under which a setter is added or not? On the contrary, if they were really just overlooked/not implemented yet, I'd opt to have the AddLabel setter for consistency and usability reasons (and support fully DSLifyng the API).

I would ask what @gambol99 thinks about it. In my opinion there's no need for getters or setters if we operate just on golang data structures. As I see it the library has the knowledge of how to communicate with marathon and represent data in the golang + additional helpers related to the marathon knowledge. Also having one way to do the thing might confuse the end user less.

I'm probably somewhat biased on this; as I spent a large amount of time writing ruby :-) ... Admittedly, removing those setters would a pretty big break and given all the fields are exported, as is, the decision is in the hands of the developer as to which they prefer.
   marathon.Application{
		ID: "myapplication",
		CPUs: 0.1,
		Mem: 64,
		Instances: 2,
		Args: []string{"usr/sbin/apache2ctl","-D","FOREGROUND"},
		Env: map[string]string{
			"NAME" : "frontend_http",
			"SERVICE_80_NAME" : "test_http",
		},
		RequirePorts: true,
		Type: "DOCKER",
		Container: &marathon.Docker{
			Image:  "apache",
			Network:      "BRIDGE",
			PortMappings: []marathon.PortMapping{
				{
					Protocol: "TCP",
					ContainerPort: 80,
				},
				{
					Protocol: "TCP",
					ContainerPort: 443,
				},
			},
		},
		HealthChecks: []marathon.HealthCheck{
			{
				Protocol:               "HTTP",
				Path:                   "/health",
				GracePeriodSeconds:     30,
				IntervalSeconds:        10,
				MaxConsecutiveFailures: 3,
				TimeoutSeconds:         5,
			},
		},
	}

        app := marathon.NewDockerApplication()
	app.Name(applicationName).CPU(0.1).Memory(64).Count(2)
	app.Arg("/usr/sbin/apache2ctl").Arg("-D").Arg("FOREGROUND")
	app.AddEnv("NAME", "frontend_http").AddEnv("SERVICE_80_NAME", "test_http")
	app.RequirePorts = true
	app.Container.Docker.Container("apache").Expose(80).Expose(443)
	app.CheckHTTP("/heath", 80, 5)

@gambol99 I see the point now. In this example the DSL way looks much better.
Sorry for bringing confusion :)

LGTM

I am with @gambol99 regarding the value of the DSL allowing for concise definitions of Marathon applications; his example makes this pretty clear in my opinion. (Although it's somewhat biased towards the case where the DSL shines, which is creating the fairly complex Docker application and using mostly default parameters.)
On the other hand, I agree with @eicca that having two ways to define applications is a bit confusing on first sight. I personally had to do some code-digging initially to understand that the DSL is "just" for convenience reasons. My plan is to follow up with a PR against the README file to add some clarification in this regards.
Overall, I'm in favor of the DSL approach though due to the level of verbosity required for explicit struct initialization and the cases where the DSL enables multiple initializations under the hood (as in a Docker application).
I forgot to extend the README file by an example of the new AddLabel method, so I just re-pushed onto by branch. Is there further need for (design) discussions, or do we think the PR is now good to merge?

:+1:


Implement _check

Fix for repetition of code in src/calculator.js file by utilizing the export._check() function.

Yaay!!!
Thanks a lot for the comments and guide. I found it pretty helpful finding my way around :)

Great job @caspero-62!! Now go find something else to contribute to!


Conformer v2

Flipped convolution module and self-attention, and removed relative positional encoding.

Codecov Report

Merging #254 (e9ebf28) into master (39aa18d) will decrease coverage by 0.31%.
The diff coverage is 24.09%.

@@            Coverage Diff             @@
##           master     #254      +/-   ##
==========================================
- Coverage   64.59%   64.28%   -0.32%
==========================================
  Files          84       85       +1
  Lines       10209    10289      +80
==========================================
+ Hits         6595     6614      +19
- Misses       3614     3675      +61

Impacted Files
Coverage Δ

neural_sp/bin/args_asr.py
97.42% <ø> (ø)

...l_sp/models/seq2seq/encoders/conformer_block_v2.py
20.00% <20.00%> (ø)

neural_sp/models/seq2seq/encoders/conformer.py
84.05% <62.50%> (-0.32%)
:arrow_down:

Continue to review full report at Codecov.

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

Codecov Report

Merging #254 (e9ebf28) into master (39aa18d) will decrease coverage by 0.31%.
The diff coverage is 24.09%.

@@            Coverage Diff             @@
##           master     #254      +/-   ##
==========================================
- Coverage   64.59%   64.28%   -0.32%
==========================================
  Files          84       85       +1
  Lines       10209    10289      +80
==========================================
+ Hits         6595     6614      +19
- Misses       3614     3675      +61

Impacted Files
Coverage Δ

neural_sp/bin/args_asr.py
97.42% <ø> (ø)

...l_sp/models/seq2seq/encoders/conformer_block_v2.py
20.00% <20.00%> (ø)

neural_sp/models/seq2seq/encoders/conformer.py
84.05% <62.50%> (-0.32%)
:arrow_down:

Continue to review full report at Codecov.

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


Discussion: Should we automatically set Locale in settings?

Currently, a fresh install of the app does not have an automatically set Locale in settings:

I came across this when running Mock Bot and testing locale. In the screencap below, the first response from the bot is when Locale wasn't set, and the second is after I set en-US.

In Web Chat, we currently set the default as 'en-US'. Is this something we would want to do with Emulator?

(Composer.js in Web Chat)

Hmm, we actually used to have this as the default because it was the default value in V3. I can't remember if we changed that behavior for a specific reason though.

I believe this is only used by webchat and webchat defaults to en-us So a null field in the UI actually triggers a default value in webchat to en-us.

Wouldn't the bot be able to respond with  en-US in the first query above if that were the case?

This was fixed with #1329


Drop RV and make it experimental (and optional)

Get rid of RV for CPU backend and make it an experimental CPU backend besides the default one.
This will simplify deployment, build and many more. The current performance of RV left much to be desired anyway.

This is done with the most recent updates in development and 0cff450


Update dependency gdata-vaas to v5

This PR contains the following updates:

Package
Type
Update
Change

gdata-vaas
dependencies
major
5.0.1 -> 5.0.2

Release Notes

GDATASoftwareAG/vaas
v5.0.2
Compare Source
v5.0.1
Compare Source
v4.2.4
Compare Source
v4.2.3
Compare Source

Configuration
:date: Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.
:recycle: Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
:no_bell: Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

Edited/Blocked Notification
Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.
You can manually request rebase by checking the rebase/retry box above.
:warning: Warning: custom changes will be lost.


move snackbar alert component so it shows in center just below the top menu bar

not necessarily in the midlle, but to a better spot, suggestions welcome.

closed, solved in the feedback rework issue.


Lwm2m swmgmt rebase

@JoshuaJeyaraj FYI. This is only the rebase ... I have not tested it

Tested by joshua


add coredao chain

[x] At least one AMM on your chain with a daily volume over $100k. Do you include it in your PR?   :

https://icecreamswap.com
https://lfgswap.finance/
https://archerswap.finance/
https://shadowswap.xyz/

[x] Your chain logo : https://assets.ayobandung.com/crop/0x0:0x0/750x500/webp/photo/2023/04/01/core-dao-twitter-010423-3761029689.jpg

[x] Your native token logo ; https://assets.ayobandung.com/crop/0x0:0x0/750x500/webp/photo/2023/04/01/core-dao-twitter-010423-3761029689.jpg

[x] Blockexplorer : https://scan.coredao.org

[x] High-performance RPC endpoint:
https://rpc.coredao.org
https://rpc-core.icecreamswap.com

Check for the following before your new AMM submission:

[x]Do you have a daily trading volume over $20k? Yes
[x]Does "type" at AMM config match your code base? Yes

We also need the following:

[x]Your AMM logo. Please add a link to your logo or attach it to a new issue in this repo.
icecreasmswap logo: https://icecreamswap.com/images/icecream.png
archerswap logo: https://s2.coinmarketcap.com/static/img/coins/200x200/24176.png

@sneg55
@VitalyVakhteev
@evahteev
Can someone please review this PR?

@coffeecryptoindo We are currently deployed on stage and testing, thanks.

nice

@evahteev any update?


Feature Request: Linux/Mac Support

Current library comes co-packaged with only the Windows NL5 DLLs.  Ideally, the Linux and Mac versions would be included too and the correct DLL loaded depending on OS.

Closed by PR #5


feat: Return the nodes that failed to be scheduled back to the scheduler

What type of PR is this?
feat: Return the nodes that failed to be scheduled back to the scheduler
/kind feature

What this PR does / why we need it:
According to the KEP requirements, nodes that cannot be scheduled should be returned to the scheduler.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
When there is no node in the cluster that meets the scheduling requirements, HAMi currently does not return any information to the scheduler, which does not meet the KEP specifications. According to the KEP requirements, the information of nodes that do not meet the requirements and the errors should be returned to the scheduler.
Does this PR introduce a user-facing change?:

/lgtm


WolvenKit.Installer version <IP_ADDRESS>

[ ] Have you signed the Contributor License Agreement?
[ ] Have you checked that there aren't other open pull requests for the same manifest update/change?
[ ] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[ ] Does your manifest conform to the 1.2 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

@microsoft-github-policy-service agree

This has a dependency on WindowsAppRuntime
2022-11-16 09:35:50.237 [CORE] Deployment operation #0: Windows cannot install package 26499Wolvenkit.WolvenKit.Installer_<IP_ADDRESS>_x64__str4xaare4n04 because this package depends on a framework that could not be found. Provide the framework "Microsoft.WindowsAppRuntime.1.2-preview1" published by "CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US", with neutral or x64 processor architecture and minimum version 2000.609.1413.0, along with this package to install. The frameworks with name "Microsoft.WindowsAppRuntime.1.2-preview1" currently installed are: {}
2022-11-16 09:35:50.237 [FAIL] D:\a\_work\1\s\external\pkg\src\AppInstallerCommonCore\Deployment.cpp(159)\WindowsPackageManager.dll!00007FFE0AEB990F: (caller: 00007FFE0AE2FA5E) Exception(1) tid(1ab8) 80073CF3 Package failed updates, dependency or conflict validation.

@msftbot dependencies