Only one channel is working

Hey there,
I got a little problem with my audio-output.
The problem is, that only one channel is working, the other one is not playing anything at all.
I already tried to play musik from a normal aux to chinch and there it is working properly.
Could you tell me how i fix the problem, please. Thank you anyway!!

I have no idea what scenario you talk about.

What sketch are you using ?
What is your hardware ?
Assuming that you try a A2DP Sink with I2S most likely you did not connect the pins properly!


Fixed spelling errors

This PR does not change code so no tests are required. Thanks for your hard work :)

Thanks! :)


set properties as virtual

Allows for easy overriding of defaults if complex workflow for detecting machine based settings are required

Goo to go. had to manual merge. nailed the landing but not sure I went about it correctly.


Request for compatibility/feature

This other mod https://steamcommunity.com/sharedfiles/filedetails/?id=2615407383 changes the readout to count the materials in blueprints and frames to deduct the requested amount form the stocks count.
Could you look into making your mod available for such a patch or maybe just incorporating the function?

Sure, I could look into it.

Changes made on their end already


Add support for specifying volume efficiency features for ONTAP backends

ONTAP's storage efficiency features are applied, in an automatic manner, unevenly across the platforms.  For example, as of ONTAP 9.2, AFF systems will have inline deduplication, compression, and compaction enabled for all volumes by default.  However, non-AFF systems do not have this same configuration.
Additionally, for non-AFF systems, without expressly enabling volume efficiency, no efficiency is realized.
At a minimum, it would be ideal to be able to specify the following storage efficiency features for volumes provisioned to ONTAP backends:

Enable/disable efficiency, i.e. the equivalent of volume efficiency on|off
The name of the efficiency policy to use
Compression inline and/or post-process
Deduplication inline and/or post-process
Compaction

For AFF systems, being able to specify cross-volume deduplication inline and/or post-process would also be ideal.
Andrew

+1 My customers would love to be able to use this as well. ONTAP Select is a case where those are not enabled by default. So having the possibility to tune this is a requirement.

+1 Looking to roll out Trident to our production cluster and need a way to enable dedup

+1 We would like to leverage storage efficiency from config as well for FAS

We would also love to be able to turn on deduplication with OpenShift & Trident.


Remove destroy hook

TODO:
Add note in migration guide after #10010 is merged that has setup for migration guide

Seems package-lock.json has been (partially) removed, will fix

Migration guide needs a rebase it seems

@kurkle @LeeLenaleee fyi
Chart.js(feat-side-effects-false)$ npx eslint karma.conf.cjs

/Users/dangreen/github/Chart.js/karma.conf.cjs
  9:15  error  Multiple spaces found before '='       no-multi-spaces
  9:26  error  ES2020 'import()' syntax is forbidden  es/no-dynamic-import

✖ 2 problems (2 errors, 0 warnings)
  1 error and 0 warnings potentially fixable with the `--fix` option.

Interesting ci did not fail on it, will look at it later

@dangreen I don't seen ti get the error when runnning npm run lint-js so I guess your way of running eslint might take another config file

@LeeLenaleee run directly npx eslint karma.conf.cjs


TS2322 one-liner return fails to identify the correct returned type

Bug Report

🔎 Search Terms

is:issue is:open TS2322 return reduce
🕗 Version & Regression Information

I tried the playground > 4.5, "production" is tested with 4.4
⏯ Playground Link

type AddressObj = {
    regionCode: string;
}

type Location = {
    address: AddressObj;
};

export function sameCountry(items: Location[]): boolean {
    return items.reduce((prev, curr) => {
        return prev && items[0].address.regionCode === curr.address.regionCode
    }, true)
}

Playground Link
💻 Code

// We can quickly address your report if:
//  - The code sample is short. Nearly all TypeScript bugs can be demonstrated in 20-30 lines of code!
//  - It doesn't use external libraries. These are often issues with the type definitions rather than TypeScript bugs.
//  - The incorrectness of the behavior is readily apparent from reading the sample.
// Reports are slower to investigate if:
//  - We have to pare too much extraneous code.
//  - We have to clone a large repo and validate that the problem isn't elsewhere.
//  - The sample is confusing or doesn't clearly demonstrate what's wrong.

🙁 Actual behavior

Type 'Location' is not assignable to type 'boolean'.
No overload matches this call.
  Overload 1 of 3, '(callbackfn: (previousValue: Location, currentValue: Location, currentIndex: number, array: Location[]) => Location, initialValue: Location): Location', gave the following error.
    Argument of type '(prev: true, curr: Location) => boolean' is not assignable to parameter of type '(previousValue: Location, currentValue: Location, currentIndex: number, array: Location[]) => Location'.
      Types of parameters 'prev' and 'previousValue' are incompatible.
        Type 'Location' is not assignable to type 'true'.
  Overload 2 of 3, '(callbackfn: (previousValue: true, currentValue: Location, currentIndex: number, array: Location[]) => true, initialValue: true): true', gave the following error.
    Argument of type '(prev: true, curr: Location) => boolean' is not assignable to parameter of type '(previousValue: true, currentValue: Location, currentIndex: number, array: Location[]) => true'.
      Type 'boolean' is not assignable to type 'true'.

🙂 Expected behavior

Nothing, since splitting to declaration/assignment and return fixes the problem automagically

Duplicate of #41702.
Workarounds: true as boolean or reduce<boolean>(...)

Thank you for the quick response AND the condensed workarounds 😀


Correctly indent function return types on new lines

There are two commits in this PR. The first fixes the incorrect return type indentation discussed in #4373. The second simplifies the logic of the code ambient to the fix to try lower the number of branches and amount of work needed to reason about what is happening. The biggest change w.r.t. the latter commit is that we can think about indentation of the return type only when the return type should be on its own newline; otherwise, there is no reason to indent it.
There is a blocker that need to be discussed before this could be landed:

[ ] (cc @topecongiro) that this change is the indented behavior for a return type when the indent style is block

To expand on this, visual indent styles would have the return type inline with the parameter indent:
fn lorem(ipsum: usize,
         dolor: usize,
         sit: usize,
         amet: usize,
         consectetur: usize,
         adipiscing: usize,
         elit: usize)
         -> usize {
}

I think this is a reasonable difference between visual and block indent, but we need to confirm this.

tangent: in the process, I discovered what I think is another bug w.r.t. fn signature indentation with the visual indent style. Under this mode, a code would format as
    fn foo(
        )
        -> BoxFuture<'static,
                     Result<Box<dyn dirents_sink::Sealed>,
                            Status,
                            BoxFuture<'static, Result<Box<dyn dirents_sink::Sealed>, Status>>>>;

but I think the desired formatting is more like
    fn foo() -> BoxFuture<'static,
                          Result<Box<dyn dirents_sink::Sealed>,
                                 Status,
                                 BoxFuture<'static, Result<Box<dyn dirents_sink::Sealed>, Status>>>>;

However, this is a rather esoteric case that I don't think should be prioritized until more users begin submitting reports of it in real cases.

I think the function formatting function as a whole could use some refactoring for better reasoning and less branches; currently it is exceptionally large and difficult to understand.

I think the function formatting function as a whole could use some refactoring for better reasoning and less branches; currently it is exceptionally large and difficult to understand.

It's a bit of an exercise trying to keep mental map of that one isn't it :smile: I'm inclined to agree, though I do think we'd want to have some bench marks should it become a major refactor (which I suspect it would). Although it's been a while, there have been some perf issues with rustfmt in the past, so it'd be great to have that insight alongside the functional validation from the testing.

To expand on this, visual indent styles would have the return type inline with the parameter indent:
fn lorem(ipsum: usize,
         dolor: usize,
         sit: usize,
         amet: usize,
         consectetur: usize,
         adipiscing: usize,
         elit: usize)
         -> usize {
}

Are you asking if this is the correct/desired formatting with Visual indent style or saying the changes here modify the Visual formatting from X to this?
Not sure if my Visual indent_style mental formatter is accurate, but I believe the above formatting is how rustfmt already would format that fn with Visual style, so my guess is that your question is the former?

Are you asking if this is the correct/desired formatting with Visual indent style or saying the changes here modify the Visual formatting from X to this?

My question is whether the changes to the block indentation are correct, because this change would mean the newline return type indentation is different from how it would be in a visual indent style. Which I think is reasonable and makes sense to me, but would like some external validation.

Going to close given the age and 2.0 branch target, as we're not actively developing for 2.0 any more


remove input

vectorvictor is too annoying to keep around.

sorry about that.

@willkg what about it was too annoying? did someone say "surely" a lot?

I've been meaning to remove that, but it comes up rarely in channels I'm in so I keep forgetting.

Yeah, the "surely" thing was kind of irritating. Plus #input is half bots. Plus when I tried to kick vectorvictor off, it hopped back on immediately. There isn't any way to invite/uninvite it. It's lacking some helpful commands.

Yeah. I actually didn’t realize it would rejoin… it’s a pretty simple bot
and has no state storage at all, so it doesn’t do the invite/kick thing.
Thanks for the feedback.


Server Crash after update to the newest verison

Forge server
AdvancedRocketry-1.10.2-1.2.0
LibVulpes-1.10.2-0.2.3-universal
crash report

figures, serverside issue. investigating


MacOS dist packaging should have separate name

Building with the dist packaging support in develop creates the application with a name in the pattern of name-darwin-amd64.app. This is far from practical as nobody would want their distribution binary have *-darwin-amd64 in their name when it shows up in launchpad.
I suggest that a flag is provided -appName that lets the user set the application name in the MacOS packaging. My app would then be called Sparta.app instead of sparta-darwin-amd64.app.

Agreed, it is a good point.
Modified the output to not contain the OS and Arch info and store them under a dedicated folder like:
fyne-cross
│   ├── bin
│   │   ├── darwin-amd64
│   │   │   └── Sparta
│   │   ├── linux-amd64
│   │   │   └── Sparta
│   │   └── windows-amd64
│   │       └── Sparta.exe
│   ├── dist
│   │   ├── darwin-amd64
│   │   │   └── Sparta.app
│   │   ├── linux-amd64
│   │   │   └── Sparta.tar.gz
│   │   └── windows-amd64
│   │       └── Sparta.exe

in this way we'd use the --output flag to specify the app name.
Please note that the fix also remove the need to specify the --dist flag, by default now fyne-cross will generate also the dist packages :)

Thanks for the quick fix. I have tested it and it seems to work great :+1:


Sort button in queues pages doesn't work

After clicking this button, there is no effect
Only the cpu and memory buttons are normal.

Will check that later, seems that the allocated resoures are showed dynamically so the codes just covered the fixed resource like cpu/memory，and other resources are not considered yet.


Updated for blog page converter

Please always provide the GitHub issue(s) your PR is for, as well as test URLs where your change can be observed (before and after):
Fix #140
Test URLs:

Before: https://main--danaher-ls-aem--hlxsites.hlx.page/
After: https://140-blog-page-converter--danaher-ls-aem--hlxsites.hlx.page/

@rgravitvl - The title, description, imageAlt and LinkPath fields were missing for createImage function.
Do we really not needed for this Blog page Or we considering only image for now?


map.addEventListener(plugin.google.maps.event.MAP_READY, function(){}) doesn't work in the success callback of http request

Mine is an angular based cordova app where I initialize the map view and wait for it in a controller. It works fine, when I do this:
app.controller('eventDataCTRL', ['$scope', '$location', 'eventFactory', '$http', function($scope, $location, eventFactory, $http){
  $scope.eventFactory = eventFactory;
  var div = document.getElementById("map_canvas");
  // Initialize the map view
  map = plugin.google.maps.Map.getMap(div);
  // Wait until the map is ready status.
  map.addEventListener(plugin.google.maps.event.MAP_READY, onMapReady([42.3601, -71.0589]));
  $http({
    method: 'POST',
    url: "https://xyz.com/",
    headers: {
      'Content-Type': 'application/json'
    },
    data: JSON.stringify({uri:eventFactory.event_url[0]})
  }).then(function successCallback(response) {

    }, function errorCallback(response) {
  });

But what I want is send coordinates which I get from this endpoint, or more specifically for any location (lat, long) I want. so this doesn't work:
app.controller('eventDataCTRL', ['$scope', '$location', 'eventFactory', '$http', function($scope, $location, eventFactory, $http){
  $scope.eventFactory = eventFactory;
  var div = document.getElementById("map_canvas");
  // Initialize the map view
  map = plugin.google.maps.Map.getMap(div);
  // Wait until the map is ready status.

  $http({
    method: 'POST',
    url: "https://xyz.com/",
    headers: {
      'Content-Type': 'application/json'
    },
    data: JSON.stringify({uri:eventFactory.event_url[0]})
  }).then(function successCallback(response) {
     map.addEventListener(plugin.google.maps.event.MAP_READY, onMapReady([42.3601, -71.0589]));
    }, function errorCallback(response) {
  });

For the sake of privacy I replaced the http request url with a random url.
Any help would be greatly appreciated.

Unfortunately, without sharing your code with me, I can not help you at all.
Please share your project files on github.

https://github.com/kanalasumant/test_events
Kindly look into the js/main.js and also read my comments above. Thank you!

Could you tell me how I can build your project?

Hey thanks again for helping on this. this is a new repository where the full cordova repo is available at https://github.com/kanalasumant/erwerwer to be run using cordova run. I personally haven't setup an emulator and it's tough to set it up properly on my machine with the documentation in cordova not being clear, so I generate an apk and run it on my phone. If something goes wrong, I can send you my apk file to your email address. Thank you.

Thank you for waiting. I reviewed your code, and this code is strange.
  map = plugin.google.maps.Map.getMap(div);
  // Wait until the map is ready status.
  $http({
    method: 'POST',
    url: "https://fair-events.herokuapp.com/api/parseLatAndLongWeather/",
    headers: {
      'Content-Type': 'application/json'
    },
    data: JSON.stringify({uri:eventFactory.event_url[0]})
  }).then(function successCallback(response) {
      document.getElementById('weather').style.visibility = "visible";
      $scope.url=response.data.info;
      $scope.lat_long=response.data.position;
      $scope.$apply();
      map.addEventListener(plugin.google.maps.event.MAP_READY, onMapReady([42.3601, -71.0589]));
    }, function errorCallback(response) {
  });

After the creating a map instance, the map fires MAP_READY event when it is ready.
You need to add the event listener before the event is fired.
But during the time, you do $http(...). That's why you miss the event.
So you should do like this.
  map = plugin.google.maps.Map.getMap(div);
  // Wait until the map is ready status.
  map.addEventListener(plugin.google.maps.event.MAP_READY, function() {

    $http({
      method: 'POST',
      url: "https://fair-events.herokuapp.com/api/parseLatAndLongWeather/",
      headers: {
        'Content-Type': 'application/json'
      },
      data: JSON.stringify({uri:eventFactory.event_url[0]})
    }).then(function successCallback(response) {
        document.getElementById('weather').style.visibility = "visible";
        $scope.url=response.data.info;
        $scope.lat_long=response.data.position;
        $scope.$apply();
        onMapReady([42.3601, -71.0589]);
      }, function errorCallback(response) {
    });
  });

Thank you so much, but this should resolve the issue as seen in the gif you put up, but weirdly isn't working on my phone when I updated the code the way you described as above. That is strange! If you dont' mind can you once more look at the main.js file in the repository I updated for the updated code. I did exactly as you said. Maybe the android OS version might differ the code written. Can you describe which android os you're running it on and if possible can you send the updated file if possible to my email id. this is my email<EMAIL_ADDRESS>

I'm very close to getting this issue fixed. I cannot appreciate the time you put into this.!

You should invite me to your project repository.

Done. Thanks

Thank you.  I will puah the code later.

ping

Sorry, must be apk caching issues. But I'll confirm it today evening, and we could close this issue. I cannot thank you enough for your help @wf9a5m75

Ok, sounds good. Thank you for using this plugin.

By the way, I appreciate if you support for this project.
This is not mandatory asking.
I just always ask when I debug for other person project because I spend my private time.
This is $5 donation link at paypal
When you donate some amount to the project, please include your issue number in your name.

I will certainly donate to this wonderful and simple to use plugin you created.

Thank you for your donation!


A few questions about Jumi Actor implementation patterns

I'm creating an issue because there is no mailing list to discuss implementation questions--feel free to close this out if this isn't the appropriate channel.
I have a few questions around Actor APIs and implementations and appropriate use of jumi-actors in that context.

As far as I know, it is commonplace to include actor refs in messages passed to actors so they can communicate with other actors as continuations. In jumi-actors, I would have an ActorRef argument in one of the actor interfaces to do that. Now, if an Actor wants to pass itself as the continuation to another actor (to wait for a response to its request), how would you accomplish that, i.e. how do you obtain a self-reference from within an Actor interface impl? Or do you suggest to simply pass Actor refs to Actor constructors and hold strong references throughout the life time of an actor? How would you avoid cycles?
I noticed that in the Pi example, Actors use both ActorThread and the executor directly to spawn other Actors. Isn't exposing the scheduling mechanism (the Executor in this case) a smell, since it ties the Actor to a particular low level implementation for the concurrent computation?
What happens if you try to spawn more ActorThreads than the underlying thread pool provides threads? Since ActorThreads are basically message loopers and loop forever until they receive an interrupt, I suppose any actor thread created will wait in the Executor task queue forever? Have you thought about this case?

Thanks!

This channel is good for discussions, or you can also use the parent project's mailing list if you like: https://groups.google.com/forum/#!forum/jumi-test-runner

To obtain a self-reference, you would give the actor a reference to the ActorThread where that actor is running, after which it can call ActorThread.bindActor on itself. See for example https://github.com/orfjackal/jumi/blob/v0.5.437/jumi-core/src/main/java/fi/jumi/core/suite/SuiteRunner.java#L79

It uses Executor in order to execute the workers in parallel. An ActorThread is guaranteed to be backed by a single thread which never changes. This is a deliberate design decision in order to give the programmer full control of in which thread things are executed, because this was developed for the needs of the Jumi Test Runner. Many other actor libraries take a different approach.

The backing Executor must create new threads instead of waiting for existing threads to stop. In practise you always must use Executors.newCachedThreadPool() or a similar pool. MultiThreadedActors could have been implemented so that it takes a ThreadFactory instead of Executor, but I considered executors more convenient to use because of their shutdown operations.

Thanks for getting back to me.

To obtain a self-reference, you would give the actor a reference to the ActorThread where that actor is running, after which it can call ActorThread.bindActor

Ah ok--so are you saying calling bindActor multiple times is a safe thing to do? Since other actors might need a reference to the actor, I would end up calling it twice: once "outside" the Actor class, and once more inside the actor when it needs to pass itself to another actor as a continuation.

The backing Executor must create new threads instead of waiting for existing threads to stop. In practise you always must use Executors.newCachedThreadPool() or a similar pool.

So there is a chance that if an Actor blocks / hangs, I will end up creating an unbounded number of threads? I'm just cautious around this as I was planning to use the library on Android/mobile where resources are more constrained (I would usually never create an unbounded thread pool)

Yes, just call bindActor as many times as you wish. It just instantiates a dynamic proxy and a couple cheap objects which wrap a strong reference to the actual actor object and its actor thread.
A new thread is started only when you call Actors.startActorThread(), so you are in full control of how many threads there are. So it is perfect for mobile use. ;)

Great, thanks for clarifying!


[VSCode] [UX] Prompt to create new project in new window or existing window in VSCode plugin

Description:
Upon creating a new project, ask the user whether to open the newly created project in a new window or in an existing window rather than opening in the same window without preserving the previous state
Labels
Type/UX

https://github.com/wso2/ballerina-integrator/pull/620


Introspecting ScrollView and iOS 17

I am currently using Introspect 0.2.3 and it works fine on iOS 15 / 16.
When I tested on iOS 17 beta 3, I don't get the callback with the UIScrollView anymore.
So I tried upgrading to SwiftUIIntrospect 0.9.0 and getting the ScrollView works fine here also on iOS 17, but the View that's behind the ScrollView became un-tappable / doesn't react on tap events anymore. I am blindly guessing the View for Introspection might be blocking those events.
As a workaround, I added my own version of introspectScrollView and downgraded back to 0.2.3, using selector: TargetViewSelector.siblingContainingOrAncestor only on iOS 17 (not sure if that's the best way, but it works):
public func introspectScrollView2(customize: @escaping (UIScrollView) -> ()) -> some View {
        if #available(iOS 17, *) {
            return introspect(selector: TargetViewSelector.siblingContainingOrAncestor, customize: customize)
        } else {
            return introspect(selector: TargetViewSelector.siblingOfTypeOrAncestor, customize: customize)
        }
    }

Please use the new SwiftUIIntrospect module. The old Introspect module is unstable, deprecated, and will be effectively removed this autumn.
https://github.com/siteline/SwiftUI-Introspect#scrollview

@davdroman Thanks for your reply; I tried the new module, and introspection started working on iOS 17 again, but then the View that's behind the ScrollView became un-tappable / doesn't react on tap events anymore; so I resorted to the old version because I had fully working solution already for that :) Any hints how I can help to get the tap events issue fixed?

import SwiftUI
import SwiftUIIntrospect
import MapKit

struct ContentView: View {
    @State private var region = MKCoordinateRegion(center: CLLocationCoordinate2D(latitude: 51.5, longitude: -0.1), span: MKCoordinateSpan(latitudeDelta: 0.5, longitudeDelta: 0.5))

    var body: some View {
        ZStack {
            Map(coordinateRegion: $region)
                .ignoresSafeArea()

            Spacer()
                .frame(maxWidth: .infinity)
                .overlay(self.bottomDrawerScrollView, alignment: .top)
        }
    }

    @ViewBuilder var bottomDrawerScrollView : some View {
        ScrollView([.vertical]) {
            Text("Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum Lorem Ipsum ")
        }
        .offset(x: 0, y: 400)
        .introspect(.scrollView, on: .iOS(.v15, .v16, .v17)) { scrollView in
            scrollView.backgroundColor = .yellow
        }
    }

}

Without the .introspect, you can pan the map, with the .introspect, you can not pan it around anymore. I don't remember why I used that quirky Spacer overlay :)

Thank you! I’ll investigate this later today as I’m currently AFK.

@ralfebert thank you for your patience and for the code sample. I was able to pinpoint the issue and the fix is now available in 0.9.1.

I ended up having to revert my apps to use the old version of introspect and the snippet in the first comment due to bugs with the current scrollview implementation.

@jbromberg would you be able to open a new issue explaining what the bugs you've encountered look like? With the upcoming 1.0 release, Introspect will no longer be part of this repo so it's worth fixing any bugs in SwiftUIIntrospect going forward.

@davdroman just opened issue #356. Seems to be the main bug I was encountering.


Do not aggressively exclude while dealing with java projects

cc: @heubeck
https://github.com/CycloneDX/cdxgen/pull/1202#issuecomment-2202139821
!hasAnyProjectType will aggressively check and exclude any type based on project alias. However, in this case we only need to check a specific filter list. Over time, we can come up with a better utils function that deals with this, but for now such a condition does the job.
Our new bom diff tool can be used to check for differences.
pip install custom-json-diff
cjd -i ~/Downloads/sbom.json ~/Downloads/sbom-2.json -o diff.json -x "components.[].description,components.[].publisher,components.[].author,components.[].scope,components.[].type" bom-diff --components-only --allow-new-data

Looks like js packages are not collected from that test project. Investigating.

With the latest commit, only three differences are reported by cjd.
diff.html.txt
diff.json
sbom.json

@heubeck Ready for your retests.

@heubeck Ready for your retests.

works again, thx @prabhu !


Inlining CSS and JS in HTML does not work

Describe the bug
I am attempting to migrate my project from Parcel to Vite.
My project is a single-page application.
For easy deployment and fast startup, my project is designed to ship as a single .html file with all JS and CSS inlined in the HTML page.
The problems described here pertain to the production build for an index.html like the following:
<!DOCTYPE html>
<html lang="en">
  <head>
    <style>
      @import './style.scss';
    </style>
  </head>
  <body>
    <script type="module">
      import '/main.js';
    </script>
  </body>
</html>

1. @import from .scss files in <style> tags doesn't work
With Parcel, I was able to achieve this with an inline @import for the CSS:
Note that I'm attempting to use SASS here.
Unfortunately, this does not seem to work in Vite, where the inline <style> tag appears to be handled without any module processing, based on the file extension. (?)
The resulting output from this example is e.g.:
<style>
  @use "app";
</style>

So the .scss file does not get processed.
Things I've tried that didn't work:

👎 @import url('./style.scss') (same)
👎 <style type="sass"> (same)
👎 <style lang="sass"> (probably only works for Vue)

My current workaround is to use an external CSS file.
2. import from <script> tags doesn't work as expected
Having used an inline <script type="module">, I would expect the code within that tag to get bundled an inlined, as I was able to do with Parcel.
Instead, the inline script tag is removed from <body>, and an external script tag is inserted into <head> - this will execute before the DOM is ready, will block the page from rendering, and so on.
There is no workaround for this one - I will get an external .js file no matter what.
Summary
I wanted one HTML file, but I'm getting 3 separate assets (HTML, CSS, JS) instead.
What happens at development time isn't important, but it doesn't look like the production build I wanted is currently possible with Vite?
Reproduction
https://stackblitz.com/edit/vitejs-vite-gv7uz4?file=index.html
System Info
System:
    OS: Linux 5.10 Ubuntu 16.04.7 LTS (Xenial Xerus)
    CPU: (8) x64 Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz
    Memory: 4.85 GB / 6.13 GB
    Container: Yes
    Shell: 4.3.48 - /bin/bash
  Binaries:
    Node: 16.14.2 - ~/.nvm/versions/node/v16.14.2/bin/node
    Yarn: 1.22.4 - ~/.npm-global/bin/yarn
    npm: 8.5.5 - ~/.npm-global/bin/npm
  npmPackages:
    vite: ^2.9.9 => 2.9.9

Used Package Manager
npm
Logs
(reproduction provided above - let me know if you need this.)
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/core instead.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

https://stackblitz.com/edit/vitejs-vite-z1wwd1?file=style.scss maybe @use no support. After replace @use to @import it seems work well

@poyoho I think that is handled as css because changing the content of _app.scss to below will break it.
$c: red;

#app {
  font-family: Avenir, Helvetica, Arial, sans-serif;
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
  text-align: center;
  color: $c;
  margin-top: 60px;
}

I think html tag is not support css preprocessor. so can't not handle scss.
<style>
    @import './style.scss';
</style>

And now the syntax is not supported. so even setting <style lang="scss"> it no work.

Yes, it's probably a feature request.
It seemed like a bug to me at the time, I guess, because I was expecting inline sources would just be treated as logical files (same as any other assets) which is how it appears to work in Parcel?
Note that I'm not suggesting support for something like <style lang="scss"> - I don't think there's any "correct" way to inline anything other than ES scripts/modules and CSS in HTML, so that's not really what I'm trying to suggest.
I find Vue's idea of using the lang attribute a bit peculiar, as this clashes with the global lang attribute. Using the type attribute on <style> isn't much better, as this attribute actually existed historically, and is deprecated.
None of these approaches are valid HTML - and that's fine for e.g. Vue or Svelte, because these template languages are supersets of HTML - but for a standard index.html as Vite uses, I don't think we should (or need to) support other languages like SASS or TS being inlined at all? It would likely add confusion, and most likely wouldn't get IDE support, or pass an HTML linter, etc.
If standard JS import and CSS @import worked and resolved external resources the way imports normally do with a bundler, using SASS or TS (or anything else) that way is not a problem - so that's probably the cleanest and simplest approach?
Something like <link rel="stylesheet" href="./style.scss"> or <script src="./script.ts"> "just works" - JS import and CSS @import works inside those assets, so it would seem natural to expect these would "just work" when used in inline <script> and <style> as well.
I think, basically, Parcel nailed this? Probably no reason to invent something clever. 🙂

Right! I think your point is better. I will modify it later. Thank you.

Is this working? or still pending?

For reference, a commit from 2020 prevents non-module inline script to be extracted to separate JS files, but it would be nice to allow for more.
I have a small inline async module script (<script type="module" async>) that I’d like to run as soon as possible, awaiting for other assets to load, but it gets extracted to the main bundle and end up running too late. My only solution for now is to use it as non-module <script>.

+1 for the ability to inline a less file and have it go through postcss as well.
<style>
@import url("./variables.less");
</style>

Where in this case variables.less exports less variables to css custom properties. I'm sure there are other use-cases?

I also stumbled upon this behavior. Also .css inlined by an import in the index.html is not getting minified.


"odo config set" doesn't validate port values and thus "odo describe" panics

/kind bug

What versions of software are you using?

Actual behavior
odo describe panics because odo config set doesn't perform a check for ports provided by the user
Expected behavior
odo should validate that provided value for ports follow <port>/<protocol> format and the values are valid.
Any logs, error output, etc?

/approve @dev-gaur

I tried reproducing this issue but could not.
After a discussion with @dharmit , I found out that this has been partially fixed by #3224 and the rest of the problem that still persists is depicted in #3229.
Nevertheless, I feel that there should be proper validation for config parameters provided by user via odo config set param value command, which is currently absent right now : https://github.com/openshift/odo/blob/master/pkg/odo/cli/config/set.go#L62 .
Therefore, to add validations, I've created #3259 .


Add information about missing connections when merging paths

This PR proposes a fix for #581 based on this comment by Robin.

Thanks for creating this PR. Since you are a first time contributor, and I don't know if you already did this, but could you send us a signed CLA via email?

but could you send us a signed CLA via email?

Yes, already done. We should make this somehow better transparent. I'm currently thinking about dropping the requirement of such a CLA and instead sign every commit and have a "first contribution commit" which adds the nick name or something into the contributor file. Like the linux kernel community is doing this.

We should make this somehow better transparent. I'm currently thinking about dropping the requirement of such a CLA and instead sign every commit and have a "first contribution commit" which adds the nick name or something into the contributor file. Like the linux kernel community is doing this.

I like the way Google is handling their CLAs. They have a bot, not sure if they use this opensource clabot. But maybe we should discuss this somewhere else :).

Thank you for the feedback!
I've adjusted the code accordingly and refactored recurring string values into constants.

Wouldn't it be more useful to see all problems? I'm thinking about a compiler only showing one error each time I start a compilation...

We can print all but it should not be required for the implementation to do this, e.g. if the first problem is reported we can stop wasting CPU resources to calculate further.

What about this PR? As @boldtrn already stated we have to be strict here with regards to the changed JSON output.
What do you think about this:

I would like to propose that we use the same JSON format that we currently use for the Matrix API


Traccar 3.8 release when?

hello Anton
as the title suggest, when do you plan to release Traccar 3.8?

Hopefully in a couple of weeks.

Thanks for your answer.


Move implementation directories

core_impl  -> impl_core
core_impl_java -> impl
core_impl_android -> impl_lite
Also updated settings and all/build, removed stale build and readme files.

Coverage remained the same at 80.19% when pulling 2e47dbfb5dd7bf9acd4d966812145d0255158b1c on songy23:move into 4833413b2a0e4fa6e4d4b7279f0b28e7e3479a56 on census-instrumentation:master.

Codecov Report

Merging #786 into master will decrease coverage by 0.02%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##             master    #786      +/-   ##
===========================================
- Coverage     78.23%   78.2%   -0.03%
  Complexity      835     835
===========================================
  Files           152     152
  Lines          3685    3685
  Branches        349     349
===========================================
- Hits           2883    2882       -1
  Misses          730     730
- Partials         72      73       +1

Impacted Files
Coverage Δ
Complexity Δ

.../io/opencensus/implcore/stats/ViewManagerImpl.java
100% <ø> (ø)
3 <0> (?)

.../opencensus/implcore/stats/MeasureMapInternal.java
88% <ø> (ø)
3 <0> (?)

.../opencensus/implcore/stats/MutableAggregation.java
98.92% <ø> (ø)
1 <0> (?)

...encensus/implcore/tags/CurrentTagContextUtils.java
87.5% <ø> (ø)
2 <0> (?)

...n/java/io/opencensus/implcore/tags/TaggerImpl.java
100% <ø> (ø)
21 <0> (?)

.../opencensus/implcore/tags/CurrentTaggingState.java
100% <ø> (ø)
3 <0> (?)

...ava/io/opencensus/implcore/stats/StatsManager.java
100% <ø> (ø)
4 <0> (?)

...pencensus/impllite/tags/TagsComponentImplLite.java
100% <ø> (ø)
1 <0> (?)

...a/io/opencensus/implcore/tags/TagContextUtils.java
66.66% <ø> (ø)
1 <0> (?)

...pencensus/implcore/tags/TagsComponentImplBase.java
100% <ø> (ø)
5 <0> (?)

... and 16 more

Continue to review full report at Codecov.

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

Hold off merging this PR until we made the minor release.

Coverage remained the same at 80.19% when pulling<PHONE_NUMBER>5b785bfba9b038e00d433e2d08c8b4 on songy23:move into 4833413b2a0e4fa6e4d4b7279f0b28e7e3479a56 on census-instrumentation:master.

Why is this not ready to merge? Am I missing something? We want this code to be released in 0.9 so has to be moved before we cut the branch for 0.9.

@bogdandrutu I thought we were going to do a minor API release before 0.9.0, to release the setState/getState API changes first. Do we want to release the impl in that minor release? Or we will just release everything in 0.9.0?

Coverage increased (+0.05%) to 81.158% when pulling b26535ba9f6ef3b1abb98132897d7eaf58e676b7 on songy23:move into 6fe9afd81e65230806d0f0d13bf75b233893beb8 on census-instrumentation:master.

Everything goes to 0.9.0.

Yes, the implementation should be released in 0.9, but there are still a few major issues/PRs left before it is ready (#761, #790, and #792).

SGTM, I'll rebase and merge this PR as soon as #790 and #792 (and potential PR for #761) are merged.

git is good at dealing with code move, so you can merge it right now. The rebase should just work fine.

I see, merging this now


Docs suggests Table#import(), but the method wasn't implemented

copying an internally-reported issue here,

https://cloud.google.com/nodejs/docs/reference/bigquery/1.0.x/Table
"it is highly recommended that you load data into BigQuery using Table#import instead."
I don't see import() defined anywhere?

Is this a documentation error, or a missing feature?

cc @stephenplusplus

Probably a typo for load https://cloud.google.com/nodejs/docs/reference/bigquery/1.0.x/Table#load

There's also a reference to import() here: https://cloud.google.com/functions/docs/tutorials/sendgrid#importing_data_into_bigquery

Thanks I will refresh the docs.


Typing hints should be in a different color from other code

Environment data

VS Code version: 1.33.1
Extension version (available under the Extensions sidebar): 2019.4.12954
OS and version: MacOS Mojave 10.14
Python version: 3.7.3
Type of virtual environment used: virtualenv
Relevant/affected Python packages and their versions: N/A

Expected behaviour
Typing hints should be displayed in a distinct color to separate them from other code.
Actual behaviour
Variable name, typing hint and followup statement are all in the same color.
E.g., the line below up to 'origin' is in the same color. That makes it harder to see at once where is a typing hint, where a variable name is defined and where is an actual code.
  remote: pygit2.Remote = gitrepo.remotes['origin']

Syntax highlithing and colors is not a feature that's supported nor provided by the python extension.
Please report issues upstream on Magic Python (this is indirectly is used by VSC)


values is message preview could not be selected and copied

Issue submitter TODO list

[X] I've searched for an already existing issues here
[X] I'm running a supported version of the application which is listed here and the feature is not present there

Is your proposal related to a problem?
When message preview is expanded it shows message key, values and headers. If user wants to copy something from message values text box they can't because text is not selectable.
Please make text selectable so users can select and copy it.
Describe the feature you're interested in
Please make text selectable so users can select and copy it.
Describe alternatives you've considered
No response
Version you're running
v0.6.1
Additional context
No response

looks like duplicate of #3686


Remove obsolete/temporary Go-related feature flags

Now that Dependabot always runs go mod tidy, and now that it always runs go mod vendor for repositories with vendored dependencies [1], we no longer need the temporary options that we introduced for conditionally running these commands (https://github.com/dependabot/dependabot-core/pull/2597 and #2596).
This pull request addresses this change by:

Removing the tidy feature flag from Dependabot::GoModules::FileUpdater. You'll still see the tidy option in Dependabot::GoModules::FileUpdater::GoModUpdater. That's because Dependabot::GoModules::FileUpdater checks creates a placeholder Git repository if we don't have a local clone of the repository.

If we're using a placeholder, we don't want to perform a tidy, so we set the tidy option to false for the GoModUpdater.
If we have a real clone of the repository, we can safely tidy, so we set the tidy option to true for the GoModUpdater.

Removing the vendor feature flag from Dependabot::GoModules::FileUpdater. You'll still see the vendor option in Dependabot::GoModules::FileUpdater::GoModUpdater. That's because Dependabot::GoModules::FileUpdater checks for the presence of vendor/modules.txt.

If present, it sets the vendor option to true in Dependabot::GoModules::FileUpdater::GoModUpdater.
If absent, it sets the option to false.

[1] https://github.blog/changelog/2020-10-19-dependabot-go-mod-tidy-and-vendor-support/

Is there value in keeping these options available, but changing their defaults to true? I can see the YAGNI argument, but some edge case may not want this?

I imagine there's nonzero value in keeping these options available, but I'd argue that there's also nonzero cost to keeping them. Given the cost of maintaining code, I'd personally encourage us to remove these options unless A) we have a concrete benefit in mind, and B) that benefit clearly justifies the cost of maintaining the additional complexity.
What do you think?

What do you think?

YAGNI, ⚰

Thanks so much for the thoughtful review, @thepwagner! :zap:


All variable not interpreted

When All is the default value, everything is fine.
When all is send a URL query parameter, it is not interpreted in Warp10 query

Fixed by #32


Get Full Kubernetai Zone Lists

This changes the AutoPath func to use the zone list for each stanza to build the search path.

@Rigdon, have you had a chance to come back to this PR?

/integration

/integration

:( the tests were just flaking before... but as of about 30 minutes ago they are totally hosed.  Looking into it...  Never had so many different problems at the same time with this.  I'm guessing someone did some changes/updates on the test server.

/integration

OK - looks as if some one added overly aggressive "log rotation" to the CI log output, which was deleting the log viewer.html.  I restored it for now ... need to track down what is deleting directory.

/integration-cipr64

/integration-cipr64

/integration

/integration-cipr64

@chrisohaver are these tests still flaky or these real failures now?

Im not sure.  When you test these cases by hand, to they work?

Would be good to add some unit tests for AutoPath, until I get the integration tests mystery solved...


Improve setup

It moves commands to bin/setup
Do not generate react with production config
More typo fixes and better format for copying config

looks good to me - @smnkrt could you please merge master here to se if it works correctly?


CORS in Flutter web when calling edge-functions

Describe the bug
While debugging in Flutter Web, calling edge functions will get CORS error, but when I do the http post myself, it is OK. I already did this in edge functions.
Screenshots

when do the http post my self, it worked:

Version (please complete the following information):

1.4.0

@westlinkin
The cause is most likely not on the client library, but on the source code of the edge functions. Could you share your edge functions source code?

@dshukertjr  thanks, here is the edge function, I removed some sensitive data:
// Follow this setup guide to integrate the Deno language server with your editor:
// https://deno.land/manual/getting_started/setup_your_environment
// This enables autocomplete, go to definition, etc.

import { serve } from<EMAIL_ADDRESS>import { createClient, SupabaseClient } from 'https://esm.sh/@supabase/supabase-js@2'

const corsHeaders = {
  'Access-Control-Allow-Origin': '*',
  'Access-Control-Allow-Headers': 'authorization, x-client-info, apikey',
}

console.log('Function "xxx" up and running!')

serve(async (req) => {
  // This is needed if you're planning to invoke your function from a browser.
  if (req.method === 'OPTIONS') {
    return new Response('ok', { headers: corsHeaders })
  }

  try {
    // Create a Supabase client with the Auth context of the logged in user.
    const supabase = createClient(
      'https://abc.supabase.co',
      'eyJ...',
      { global: { headers: { Authorization: req.headers.get('Authorization')! } } }
    )

    const {
      data: { user },
    } = await supabase.auth.getUser()

    if (user == null) {
      return new Response('',
        {
          headers: { ...corsHeaders, 'Content-Type': 'application/json; charset=utf-8' },
          status: 403,
        })
    }

    const { name } = await req.json()

    const data = {
      message: `Hello ${name}!`,
    }

    return new Response(
      JSON.stringify(data),
      { headers: { "Content-Type": "application/json" } },
    )

  } catch (e) {
    return new Response(JSON.stringify({ error: e.message }),
      {
        headers: { ...corsHeaders, 'Content-Type': 'application/json; charset=utf-8' },
        status: 500,
      })
  }
})

The same function, use it by  Supabase.instance.client.functions.invoke('function-name', body: {'name': 'Hello'}); , get CORS. call it by plain http post method, it works fine. (only Flutter Web)
Thanks in advance

@westlinkin
Is the issue happening, because the content-type header is not listed in the allowed headers? Could you update your corsHeaders like this and retry it?
const corsHeaders = {
  'Access-Control-Allow-Origin': '*',
  'Access-Control-Allow-Headers': 'authorization, x-client-info, apikey, content-type',
}

@dshukertjr Thanks, the error still occurs after I added content-type

@westlinkin Could you literally copy and paste the code here and see if it runs without any errors?

@dshukertjr Sorry, it works. I mistakenly put 'Access-Control-Allow-Origin': '*', into header when invoke function, once it is removed, the edge function went through.
Thanks for your time.

@westlinkin Glad to hear that it's working fine now!


DS-3575: Rename misguiding find method in ResourcePolicyService

https://jira.duraspace.org/browse/DS-3575

@tdonohue good catch. Thanks. I removed the comment and left the annotation.

@tdonohue do you give me an official +1? I would like to see this getting merged.

@pnbecker : yes, a 👍 is a +1 ;)  Feel free to merge & cherry-pick to master. I meant to do this today, but didn't get to it. I'll do it tomorrow if you don't get to it first


Fails to create Service Connection

Describe the bug
When running the Azure DevOps generator, it fails with the below error.
To reproduce
Run the Azure DevOps generator.
Expected behaviour
Service Connection to be created.
Screenshots
Error: Unable to find service connection type 'powerplatform-spn' using authentication scheme 'None'.
    at RestClient.<anonymous> (C:\code\capgemini\powerapps-project-template\node_modules\typed-rest-client\RestClient.js:200:31)
    at Generator.next (<anonymous>)
    at fulfilled (C:\code\capgemini\powerapps-project-template\node_modules\typed-rest-client\RestClient.js:6:58)
    at processTicksAndRejections (internal/process/task_queues.js:93:5) {
  statusCode: 400,
  result: {
    '$id': '1',
    innerException: null,
    message: "Unable to find service connection type 'powerplatform-spn' using authentication scheme 'None'.",
    typeName: 'Microsoft.VisualStudio.Services.ServiceEndpoints.WebApi.ServiceEndpointException, Microsoft.VisualStudio.Services.ServiceEndpoints.WebApi',
    typeKey: 'ServiceEndpointException',
    errorCode: 0,
    eventId: 3000
  }
}

Environment (please complete the following information):

yo version
generator-powerapps-project version
Power Apps CLI version
Power Apps environment version

Additional context
Add any other context about the problem here.

This was because the extension installation (microsoft-IsvExpTools.PowerPlatform-BuildTools) was still ongoing. Some wait time needs to be added after the installation.


Fix compilation using clang on macOS

Fixes #2 by changing code that uses c++11 specific features.

I've installed pytrec_eval with this fix applied on macOS and CentOS. While it seems to compile now, the tests no longer run and I'm getting a "Segmentation fault" on both platforms.
Could you please take another look?


feature/OKN-2163

added modifier data to json, also removed alert variant and replaced it with a modifier

naaaaaais


Repo split

Summary
It has been proposed that we split the ibc-rs monorepo into two repos - one for the proto & module crates and the other for the relayer crate (and its associated crates).
Additionally, the relayer code must not depend on the ibc crate to have clear boundaries/separation and allow the modules to evolve independently.
Problem Statement
The monorepo approach is restrictive and becoming difficult to maintain. (See https://github.com/informalsystems/ibc-rs/discussions/1437#discussioncomment-1458578)
Moreover, having the relayer crate depend on the ibc crate makes it difficult to modify one without touching the other, and have resulted in code bloat and unclear boundaries - for e.g. the modules code contains relayer specific code.
Proposal
Using the ideas described in https://github.com/informalsystems/ibc-rs/issues/2541 and https://github.com/informalsystems/ibc-rs/discussions/1437, the repo hosting the relayer crates (the relayer repo) would look like so ->
<relayer>
├── CHANGELOG.md
├── CONTRIBUTING.md
├── Cargo.lock
├── Cargo.toml
│
├── crates
│	├── ibc-relayer
│	├── ibc-relayer-cli
│	├── ibc-relayer-rest
│	├── ibc-telemetry
│	└── ibc-chain-registry
│
├── etc...

And the modules repo would look like so ->
<modules>
├── CHANGELOG.md
├── CONTRIBUTING.md
├── Cargo.toml
│
├── crates
│	├── ibc
│	└── proto
│		├── ibc-proto
│		└── ibc-proto-compiler
│
├── etc...

Acceptance Criteria
The ibc-rs repo is split into two repos as proposed above, ideally preserving history.

For Admin Use

[ ] Not duplicate issue
[ ] Appropriate labels applied
[ ] Appropriate milestone (priority) applied
[ ] Appropriate contributors tagged
[ ] Contributor assigned/self-assigned

I think the history should be preserved unchanged in both repositories after the split (without making it an official fork on GitHub). The repo size of 39 MB is not something I would worry about.
This way, anybody with an outstanding branch can rebase or merge against either or both the new repositories.

I would also take exception to ibc-proto-compiler and move it under tools, like in tendermint-rs.

I think the history should be preserved unchanged in both repositories after the split (without making it an official fork on GitHub).

With my current proposal, the history will be preserved unchanged for the relayer repo. The module repo will also preserve the history but only for the modules, proto & proto-compiler crates, because we're using git-filter-repo. I like to use git-filter-repo for the modules repo because it reduces the repo size to ~8.5MB, the history is cleaner and a rebase should still be possible in most cases. Here's what the resulting module repo history would look like -> https://github.com/hu55a1n1/ibc-rust/commits/master

I would also take exception to ibc-proto-compiler and move it under tools, like in tendermint-rs.

Do you mean we move the ibc-proto-compiler to crates/tools/ibc-proto-compiler or tools/ibc-proto-compiler?

Do you mean we move the ibc-proto-compiler to crates/tools/ibc-proto-compiler or tools/ibc-proto-compiler?

To tools/ibc-proto-compiler. Also, all library crates would be on the same level under crates.
The logic here is that all production code is hosted under crates, and everything auxiliary that is used to build or maintain the production code goes under tools.
In tendermint-rs, tools is also an independent Cargo workspace with its own Cargo.lock that is version-controlled; I think it makes sense particularly for ibc-proto-compiler, which needs a reproducibility anchor for the code that is emitted for ibc-proto.

Two minor thoughts:

I think we should use ibc-rs for the modules, and have a statement in the README that redirects to the hermes repo and explains the transition that happened. In the long run, we'll be happy to have "the correct name" for the repo
Wouldn't it be better to have proto be its own repository? I find it cleaner for people who look for "ibc-rs" to just fall right on the "handlers repo" rather than a monorepo that also includes a proto repo.

Wouldn't it be better to have proto be its own repository?

I'm generally against splitting crates that are tightly coupled, like handlers and ibc-proto need to be. This leads to increased developer logistics when changes are introduced. Having to synchronize a change across two repositories (ibc-rs and hermes) is already a burden, but at least there are good reasons for this split, including the tentative idea to get rid of code reuse between modules and hermes.

As discussed with Philippe and Romain, we decided to keep the proto crates in a different repository for now since both the relayer and modules depend on the raw types with each repo having it's own version(s) of the domain types.
We seem to have consensus on 'hermes' as the relayer repo's name, but we're still undecided on the modules repo's name as that topic seems more nuanced than expected. ibc-rs seems like the favourite (followed by ibc-rust) but we first need to answer the following questions before we can take a decision on this ->

What happens when someone pushes to a remote that has been renamed?
What if the remote's old name has been reused?
Are there long-lived forks/branches of hermes? (looks like there are ~5 projects that have recently updated forks)
Name of forks wont change, so could this be a problem?
What about links to ibc-rs in external repos?

An alternative is to create a repo cosmos/ibc-rs to host the modules in Rust. Context I can provide here to inform the decision is that this alternative would work towards incentivizing external contribution to modules, especially since that part of our work is more outside oriented. Drawback is we lose the "Informal brand".
I think hosting the Hermes repo under informalsystems/hermes (renamed and redirected automatically from informalsystems/ibc-rs) makes a lot of sense and I have no input there.

Yeah let's re-use that repo 👍🏻

While we're at it, we should use this opportunity to rename the default branch from master to main as per the new Git conventions: https://github.com/github/renaming

I would use this event to break out gm from under IBC so it can start becoming its own tool.

I would use this event to break out gm from under IBC so it can start becoming its own tool.

Might also be a good idea to rename from gm = "gaia manager" to something more broad, e.g., "local ibc/interchain testnet manager" or something along those lines. Not sure what acronym would that yield, lite comes to mind.

Good idea but when we use the tool it's gm for example: gm start. Are you suggesting to change that as well?
Adding @greg-szabo

Good idea but when we use the tool it's gm for example: gm start. Are you suggesting to change that as well?
Adding @greg-szabo

Yes, basically rename the binary. @harveenSingh can you please create a separate issue in the gm repo to track renaming gm and continue this discussion? Thanks!
Curious what @greg-szabo thinks about renaming gm.
I will close this as the repo split is done.


Updated package versions and added native types

Updated PHP version to 8 as this currently the supported version https://www.php.net/supported-versions.php;
Added native PHP versions;
Updated package versions. Should fix #7;
Added GitHub dependabot and workflows. Should fix #6;
Added gitattributes to minimize distributed code size;
Removed composer.lock as it isn't really needed for packages;

This should be a 2.0 update. This is also required before https://github.com/Autodesk-Forge/forge-php-client can be updated

Any chance of getting this approved? That Guzzle 6 dependency is really starting to hurt.

Yeah I can look into that.  Sorry it has been a while since I've checked
this.
On Tue, Jul 23, 2024, 11:15 PM KieranMDolan @.***>
wrote:

Any chance of getting this approved? That Guzzle 6 dependency is really
starting to hurt.
—
Reply to this email directly, view it on GitHub
https://github.com/Autodesk-Forge/core-php-client/pull/8#issuecomment-2246781148,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAN4MAJA43KVYOVLTXSIRXTZN4L35AVCNFSM6AAAAABLLSZKWWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENBWG44DCMJUHA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


Sahar/samples ovep escalation

Draft PR to update the samples

Is there a way, the user will be notified that his sample is falling back to MLAS even though he tried to run it on OpenVINO-EP.
If it is falling back to MLAS, the output window also should correctly show that the device_type is MLAS and not OpenVINO-EP device which user tried to ran at the first place.

Is there a way, the user will be notified that his sample is falling back to MLAS even though he tried to run it on OpenVINO-EP. If it is falling back to MLAS, the output window also should correctly show that the device_type is MLAS and not OpenVINO-EP device which user tried to ran at the first place.

We will have to put some change in code to know if we are doing subgraph partitioning, it is currently not there


Move protocol-base to common folder.

Checkout #6073 and #6167 for more context.
While the protocol-base contains some definitions that should should move to protocol-def, it still holds some implementations (e.g., Quorum) that are shared between client and server for protocol specific guarantees. The question is: should we move protocol-base to common folder (along with protocol-def) or we have a better alternative?

@curtisman @anthony-murphy

I was thinking about this, and i'm not sure protocol-base belongs in a separate layer. As it doesn't have any requirements beyond any other dds, and the interface is fixed via the protocol definitions change. There may be value is decoupling server and client, but that would require more than just protocol-base given the routerlicious driver reuses a bunch of the server's code

I think there is a difference between other service packages used by client (e.g., services client) and protocol-base. Other service packages contains utils and libraries that both client and service share (e.g., shared rest client code).
Protocol-base contains code that affects data and protocol. For example, quourm code that runs in scribe and client. It also contains some shared summary creation code. So this package is much more vulnerable for accidental breaking changes, and moving it will make the upcoming changes more deliberate IMO.

i don't disagree, but it's really no different than any other dds if you consider the server just another client. i don't see unique challenges here, and there is a cost associated with moving it. this is very different than our definitions which break compatibility between layers of the stack if they are changed.

The difference with any other DDS is, service takes a dependency on this DDS for booting up. Especially now that client will start writing quorum for push and push will have to start their service based on that.
I am not sure what additional cost you are referring to with this move.

Also I feel like we are talking about different types of compatibility. For protocol-base, I am not concerned about interface compatibility. We can move most of those to protocol-def anyway. I am mostly concerned about summary data compatibility and want us to be more deliberate before changing.

Can we get a resolution on this? @SamBroner reminded me that we also have "gitresources" package which defines storage specific interfaces. I think we should move that one as well. If reusing common seems awkward, we can move all three into a top level protocol folder.


Android: add bootstrap build support and fix tests

With this pull, I got SPM built natively on Android and all the tests passing with the Nov. 8 source snapshot from the master branch.

@swift-ci smoke test

I've been backporting this pull and the previous #2396 to the latest Swift 5.1.2 release, only had to make some small tweaks to account for the older toolchain symlinks and cherry-picked two commits from master, which got all the SPM 5.1.2 tests passing natively on Android.
You may want to consider cherry-picking those two commits back to the swift-5.1-branch, to help those porting SPM from the latest source releases, say 5.1.3 next. One commit was caea53a, which I only needed because I enable and run those filesystem tests on Android in my previous pull. Since that changes the implementation of chmod and the test is normally gated, not a big deal if you don't.
The other commit, b876852, would be useful for anyone running the tests and hitting those hardcoded triples for linux x86_64, say if someone was porting SPM to linux ARM. Since it only fixes tests, no risk for the 5.1 branch.

5.1 branch is generally not open to take commits. You could nominate changes for the monthly Linux releases but I am not sure what's the process for that. cc @weissi

OK, I'm not sure what the process, just a suggestion based on what commits helped me when porting SPM 5.1.2 to run natively on Android.
Anyway, thanks for merging.


Square bracket numbers (lines of asm) doesn't correspond with what is actually generated

I'm confused by the [##] when listing functions to generate assembly for. Here is some sample output:
$ cargo asm --lib
    Finished `release` profile [optimized] target(s) in 0.00s

Try one of those by name or a sequence number
0 "func0" [51]
1 "func1" [56]
2 "func2" [60]

$ cargo asm --lib 0 | wc
    Finished `release` profile [optimized] target(s) in 0.00s
     26      73     400

$ cargo asm --lib 1 | wc
    Finished `release` profile [optimized] target(s) in 0.00s
     26      75     410

$ cargo asm --lib 2 | wc
    Finished `release` profile [optimized] target(s) in 0.00s
     25      66     373

Why does the summary list 51, 56 and 60 lines of assembly, while the actual assembly displayed is 26, 26, and 25?
The first list of numbers differs from the second. Additionally, the first list is increasing, while the second list is actually decreasing. func2 in the summary has the most number of lines, while the actual displayed assembly has the least number of lines.

They are calculated from the actual lines llvm produces. Those lines contain a bunch of redundant things that cargo-show-asm strips - labels that aren't used (pass -K to see those) and some of the debug info - location directives, etc. You can pass -vvv to see everything.
I could make it so numbers correspond to what the size that will be printed, but removing redundant labels is not linear in cost and  can slow things down if your file is super chonky.
Main goal for those numbers is to get you a high level overview where most of the code is and to indicate that there can be several functions with the same name.


[libjpeg] requires debug postfix due to cmakes FindJPEG

#6656
also removed the renaming in the static case. I'll expect some regressions in projects not using cmake

keep the renaming, otherwise i think you are breaking QT and all related ports...

6650 will also break Qt5 (zlib rename).
Can't wait until Qt switches to cmake.

Did you see any problem with it? Otherwise the good ol' rule of don't modify what's not broken is a golden rule :)

I like to minimize code and I will probably refactor the qt portfile a little bit. Too much copy and paste

Can't wait until Qt switches to cmake.

november 2020.
It could be a blink or a slow agony, in the meantime...

Please study #5608 before touching symbols related to the path of the libraries. Much blood was wasted along the road before fixing those subtle problems

@cenit I did not touch any how that. I just removed the 3 configure function calls and made them one.
hmm should probably use a find_library call to actually find the library paths and figure out if the windows build can also use full paths.

CURRENT_INSTALLED_DIR is now VCPKG_RELEASE_LIBDIR, that what I meant. If it works, sure. Just check it, I remember that it had been difficult to find the proper combination to build it and export it correctly (export in this case means producing a valid package recyclable as a nuget package for example on another computer....)

Here are some regressions from the current CI system:

x64-windows-static
test
notes

libfreenect2
Fail
Regression

butteraugli
Fail
Regression

arm64-windows
test
notes

podofo
Fail
Regression

failureLogs.zip

Any progress?

@JackBoosY I will close this since it requires another solution (see https://github.com/microsoft/vcpkg/pull/6658#discussion_r353601512)


koalixcrm.org demo is down

http://www.koalix.org/ is inaccessible when viewed from the Chrome web-browser, with the message "ERR_CONNECTION_REFUSED".

hello salian
Yes sorry this is a known issue. I was shutting down the server but we will soon publish a new demo based on heroku

@scaphilo,  can't wait to check that demo out! Thanks! :)

fixed :-)

Where is the link @scaphilo ?

Hallo, thank you for the input
I am sorry, the demo will be up again in a few days. I am currently working on an automated deployment process to ensure these kind of issues do not appear anymore


Merge con el pull request del profesor

Codecov Report

Merging #91 into master will increase coverage by 1.71%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##             master      #91      +/-   ##
============================================
+ Coverage     84.00%   85.71%   +1.71%
- Complexity      151      159       +8
============================================
  Files            39       39
  Lines           350      350
  Branches         24       24
============================================
+ Hits            294      300       +6
+ Misses           43       37       -6
  Partials         13       13

Impacted Files
Coverage Δ
Complexity Δ

src/main/java/edu/fiuba/algo3/model/Game.java
93.87% <100.00%> (+2.04%)
22.00 <0.00> (+2.00)

src/main/java/edu/fiuba/algo3/model/Player.java
85.00% <100.00%> (-10.00%)
8.00 <1.00> (-1.00)

.../java/edu/fiuba/algo3/constants/AugmenterType.java
68.75% <0.00%> (-6.25%)
3.00% <0.00%> (-1.00%)

...iuba/algo3/engine/questions/TrueFalseQuestion.java
100.00% <0.00%> (+8.33%)
7.00% <0.00%> (+1.00%)

...engine/questions/TrueFalseWithPenaltyQuestion.java
100.00% <0.00%> (+8.33%)
7.00% <0.00%> (+1.00%)

...ngine/questions/MultipleChoicePartialQuestion.java
100.00% <0.00%> (+10.00%)
6.00% <0.00%> (+1.00%)

...e/questions/MultipleChoiceWithPenaltyQuestion.java
100.00% <0.00%> (+10.00%)
6.00% <0.00%> (+1.00%)

...ba/algo3/engine/questions/GroupChoiceQuestion.java
100.00% <0.00%> (+11.11%)
6.00% <0.00%> (+1.00%)

...a/algo3/engine/score/augmenters/TwoMultiplier.java
100.00% <0.00%> (+16.66%)
5.00% <0.00%> (+1.00%)

... and 2 more

Continue to review full report at Codecov.

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


When Normalising data, Log errors we encounter

Noting that such logging should make it easy to refer back to the raw data the logging is about.

Suggestion:

Add to pipeline mechanism a way that each pipe can return a list of errors, each error being a dictionary that can have multiple keys but should at least have a message key which is a human readable message.
Add to raw_data table, a column normalisation_errors
The pipe runner will get the errors from each pipe, attach the name of the pipe to the error and save them all in that new column
When we get new raw data, all normalisation columns and data is cleared, including these errors. This ensure we re-normalise and remove data that is out of date

This means

It's so easy to see the raw data the error applies to, it's in the same row
Errors can be logged even if no normalised data is produced
Use of a dict allows various bits of meta data to be attached eg maybe a date value that isn't parsable could have a key saying in which field in the raw data the error occured
But requiring a message key makes it easy to list the key messages to a user

Sounds good to me

Also, if whole pipe crashes, log that using this mechanism and make sure other pipes carry on

 When normalising, how to log errors properly

Chatted to @rhiaro - we want normalisation_errors column on both raw_data and normalised_data table to cover both

an error that means that nothing can be produced - so attach to raw_data
an error where some normalised data can be produced but there was problems - so attach to normalised_data

Done for normalised_data, now for raw_data

Done for raw_data where an actual crash happens.
It would be good if a pipe could explicetly pass out error objects to - there is a TODO in src/lib/pipeline.js

If one pipe fails  on something it doesn't necessarily mean all pipes will fail, and one pipe doesn't know how the others will fare. So we'd need to be very selective with passing errors in a pipe back to raw_data. An option might be to wait til the end of the pipeline, and if there are no normalised events generated, add a note in raw_data errors about that, but it wouldn't be very specific. Just like "All pipes were unable to generate events".

Just like "All pipes were unable to generate events".

At the moment you can check for that by looking for raw_data rows with normalised=TRUE but with no normalised_rows for that raw_data


Why do we have redundant charts for Prometheus components?

I would like to understand the purpose of having redundant charts in the stable directory.
We already have a Prometheus chart, which can enable a user to turn ON/OFF AlertManager, PushGateway, KubestateMetrics and Node Exporter.
Then what is the purpose to create separate charts for all these components again? Like a separate standalone Node Exporter, PushGateway charts...? Why do we need separate charts? what advantage do we get?
I would also like to know the benefit of using either the giant chart/standalone chart from the community. Which one is recommended for Production grade systems?
Thanks,
Teja

The prometheus-node-exporter, kube-state-metrics, grafana charts are used by the prometheus-operator chart. You could use the prometheus-pushgateway chart if required to connect prometheus-operator as well.
We are using prometheus-operator as opposed to the prometheus chart as it makes managing multiple separate instances of prometheus running in the same cluster easier.

Hi Vasily Sliouniaev,
Thanks for the answer. I am already using "Prometheus" but why should one need to use this "Prometheus Operator"? What advantages do we have with it? Is there page/link which guides a newbie?
Thanks,
Teja


Set "charger max ampere"

Hi,
I'm using the Integration with my Skoda Octavia RS iV and I would like to control the charging power via HA.
The PHEV does only have 2 options: Maximum Load = ~3,5 kW and Reduced= ~1,5kW, which can be controlled by the Skoda Connect App. In this Integration I can only see the State in "Charger max ampere" but I'm not able to change it.
Is there any way to do it?

You can use the service call skodaconnect.set_charger_max_current to set the max amps.

Thanks a lot!

I'm getting an error trying to set the reduced charging on my Enyaq:

websocket_api script: Error executing script. Unexpected error for call_service at pos 1: Invalid or no response Traceback (most recent call last):   File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 447, in _async_step     await getattr(self, handler)()   File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 680, in _async_call_service_step     await service_task   File "/usr/src/homeassistant/homeassistant/core.py", line 1713, in async_call     task.result()   File "/usr/src/homeassistant/homeassistant/core.py", line 1750, in _execute_service     await cast(Callable[[ServiceCall], Awaitable[None]], handler.job.target)(   File "/config/custom_components/skodaconnect/__init__.py", line 374, in set_current     if await car.set_charger_current(current) is True:   File "/usr/local/lib/python3.10/site-packages/skodaconnect/vehicle.py", line 380, in set_charger_current     return await self.set_charger(data)   File "/usr/local/lib/python3.10/site-packages/skodaconnect/vehicle.py", line 430, in set_charger     response = await self._connection.setCharging(self.vin, data)   File "/usr/local/lib/python3.10/site-packages/skodaconnect/connection.py", line 1530, in setCharging     return await self._setSkodaAPI('charging', vin, json = data)   File "/usr/local/lib/python3.10/site-packages/skodaconnect/connection.py", line 1510, in _setSkodaAPI     raise SkodaException('Invalid or no response') skodaconnect.exceptions.SkodaException: Invalid or no response
Tried multiple times, with a reboot, and all other functions works. for example setting to 80% or 100% charging.
Running version 1.0.69 of the Skoda Connect

According to the readme the enyaq doesn't support setting amps for the max current setting.
So I guess you'd have to set it as a string to either "Maximum" or "Reduced" and not as a number.

Charger maximum current (1-16 tested OK for Superb iV, Enyaq limited to "Maximum"/"Reduced")

In the doc it also says: 252 = Reduced, 254 = Maximum.
And I'm trying to set it to 252 witch should be reduced, as it only accepts int value..

@dwapps In the doc it also says: 252 = Reduced, 254 = Maximum.
And I'm trying to set it to 252 witch should be reduced, as it only accepts int value..

Integer values only works for cars other than Enyaq. For Enyaq use Reduced or Maximum as value.
If it still doesn't it's because of server side issues.

@Farfar
Ah.. The GUI won't let me parse a string, but using the yaml editor it works flawless :)


Code owners need Write permissions

see: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners

Coverage remained the same at 100.0% when pulling 9d02cfca9489f93d24a9ec5736781455b2659be9 on write_perm into 03428ed375c718120208c19dd3cfcfe84f48ea10 on main.


Use a larger default h2 connection window

The default connection window (65535) is fairly small and limited in the
context of many applications.
grpc-go, for instance, uses a larger default value of 1048560 (slightly
less than 1MB). We now use this same default.
Fixes #638

we may not want to merge this with the patch in Cargo.toml

grpc-go, for instance, uses a larger default value of 1048560 (slightly
less than 1MB). We now use this same default.

How did you find this out? I cannot it in the source code and in fact when I looked at the source code it looks like it is 65535 in grpc-go master as of today: https://github.com/grpc/grpc-go/blob/f72b28a6d170d0938afd483331ba4e5d733785ae/transport/control.go#L34-L36
I read some of the grpc-go discussion regarding optimizing the connection window size in and a lot of it was driven by the desire to send very large messages, O(~1MB), over a high-latency connection (from Google's Austrailia data centers to to other continents w/ > ~100ms latency. That doesn't seem to fit the current expectations of Conduit workloads, which are expected to be primarily on low-latency networks. That's not to say I'm against this change, but I think we need more justification than "grpc-go does it."
Downsides of a very large window I see are:

Hugely increased memory usage per connection. If this is the default configuration we won't be able to reasonably claim to consume less than 10MB of RSS. Basically we'd have to take the memory utilization numbers out of the marketing, but that's one of the best numbers we have.
Everything that bufferbloat causes. In particular this seems like it will interfere badly with load balancing for short messages since messages will get queued. e.g. ~1,000 1kb messages could be stuck in the buffer. In reality if hundreds of messages have been buffered we probably need to switch to a different server. That is, this seems like it has bad interactions with load balancing. (grpc-go doesn't do load balancing by default so it doesn't matter for them.)

Also, should we only be doing this for gRPC and not all h2 connections?
In the end grpc-go implemented a dynamic mechanism which is exactly what I think we will eventually need to. The question is what's a better interim default, small or huge or somewhere in the middle?
What benchmark are we using to measure this?

How did you find this out? I cannot it in the source code and in fact when I looked at the source code it looks like it is 65535 in grpc-go master as of today

This is used to configure the stream window size, but not the connection window size.
And so, this doesn't quite cause the buffer bloat one might expect, since stream windows are still limited. So the effect of this change mostly benefits use cases with concurrent streams.
I knew to look at this from working on Linkerd...  I discovered grpc-go's behavior by looking at tshark output -- a connection window update is sent by grpc-go peers at initialization.
in reality, as you mention, grpc-go uses 'bdp' to discover connection window settings dynamically.
having done the work to upgrade h2 to use these new settings, i see an improvement, but only a minor one.
On my laptop, running tests with 10 concurrent streams on a single connection, sending 100000 requests, each with a ~50000B response payload:
master runs at about 1800rps / 90MBps
:; release/darwin/strest-grpc-client -totalRequests 100000 -streams 10 -lengthPercentiles '1=50000,100=50000' -address localhost:4143
2018-03-29T00:14:05Z 786.2MB  16646/0 10s L:   0 [ 10  25 ]  333 J:   0   0
2018-03-29T00:14:15Z 844.0MB  17891/0 10s L:   0 [  9  18 ]  134 J:   0   0
2018-03-29T00:14:25Z 932.1MB  19751/0 10s L:   0 [  8  14 ]  122 J:   0   0
2018-03-29T00:14:35Z 831.6MB  17609/0 10s L:   0 [  9  19 ]  182 J:   0   0
2018-03-29T00:14:45Z 888.2MB  18805/0 10s L:   0 [  8  17 ]  153 J:   0   0
2018-03-29T00:14:55Z 437.8MB   9298/0 10s L:   0 [  9  19 ]   58 J:   0   0
{
  "good": 100000,
  "bad": 0,
  "bytes":<PHONE_NUMBER>,
  "latency": {
    "50": 4,
    "95": 9,
    "99": 18,
    "999": 333
  },
  "jitter": {
    "50": 0,
    "95": 0,
    "99": 0,
    "999": 0
  }
}

on this branch, we see modest improvements (notably: better tail latencies)
:; release/darwin/strest-grpc-client -totalRequests 100000 -streams 10 -lengthPercentiles '1=50000,100=50000' -address localhost:4143
2018-03-29T00:15:56Z 926.7MB  19668/0 10s L:   0 [  7  12 ]   55 J:   0   0
2018-03-29T00:16:06Z 844.0MB  17877/0 10s L:   0 [  9  16 ]   70 J:   0   0
2018-03-29T00:16:16Z 929.4MB  19676/0 10s L:   0 [  8  11 ]   26 J:   0   0
2018-03-29T00:16:26Z 740.2MB  15657/0 10s L:   0 [ 11  23 ]   55 J:   0   0
2018-03-29T00:16:36Z 894.6MB  18955/0 10s L:   0 [  8  12 ]   30 J:   0   0
2018-03-29T00:16:46Z 385.7MB   8167/0 10s L:   0 [  8  13 ]   23 J:   0   0
{
  "good": 100000,
  "bad": 0,
  "bytes":<PHONE_NUMBER>,
  "latency": {
    "50": 4,
    "95": 8,
    "99": 15,
    "999": 70
  },
  "jitter": {
    "50": 0,
    "95": 0,
    "99": 0,
    "999": 0
  }
}

This is used to configure the stream window size, but not the connection window size.

There used to be an initial connection window size variable, but it was removed in https://github.com/grpc/grpc-go/commit/d69dedd8b711c7d9875e0b9bf6c5c606a5a2f0cc#diff-f89d2e7360aeaf72f07c56cdfd03b00cL34
So, I think this variable is both the initial stream window size and initial connection window size. See: https://github.com/grpc/grpc-go/commit/d69dedd8b711c7d9875e0b9bf6c5c606a5a2f0cc#diff-3081f1aaaf958d7d5e00ccec7a62ea6fR197
The setting for the initial connection window size used to be 1024 * 1024 but that was reverted Mar 25, 2015, IIUC:
https://github.com/grpc/grpc-go/commit/310d8c389b1626a05ce048f4b7c3106e12af7fb7
Let me know if I'm misunderstanding something.

@briansmith interestingly, i still see this behavior in strest-grpc, which uses [grpc-go 1.7.3] (https://github.com/BuoyantIO/strest-grpc/blob/master/Gopkg.toml#L48-L50) (released Dec 5 1017).  So, we're missing part of the picture.

Note that grpc-go transports support a server and client InitialConnWindowSize -- we don't configure this anywhere explicitly in strest...

Ah hah! it turns out that i've been running an ancient version of strest.  Now that I've updated, I no longer see these window updates from grpc-go.  Craziness resolved.
I think we should discard this for now and revisit later if needed.


⚠ Bofrost.lu has degraded performance

In 9fafd1c, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 935 ms

Resolved: Bofrost.lu performance has improved in 407e03c after 22 minutes.


Override apache thrift to fix builds

git.apache.org/thrift.git doesn't work anymore, repo has been migrated to github.com/apache/thrift so forcing an override to that.

/lgtm

/hold

/hold cancel

/hold
Since we merge in @cblecker PR this can be closed.

fixed by #24
/close


[qa] Imported BaseSerializer

Imported BaseSerializer from https://github.com/openwisp/openwisp-utils/pull/13/ and removed validate method in serializers.py. Anything more I need to do?
closes #53

Pull Request Test Coverage Report for Build 170

5 of 8 (62.5%)  changed or added relevant lines in 1 file are covered.
2 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-1.1%) to 98.894%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

django_ipam/api/serializers.py
5
8
62.5%

Files with Coverage Reduction
New Missed Lines
%

django_ipam/base/models.py
2
98.33%

Totals

Change from base Build 166:
-1.1%

Covered Lines:
447

Relevant Lines:
452

💛  - Coveralls

Pull Request Test Coverage Report for Build 170

5 of 8 (62.5%)  changed or added relevant lines in 1 file are covered.
2 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-1.1%) to 98.894%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

django_ipam/api/serializers.py
5
8
62.5%

Files with Coverage Reduction
New Missed Lines
%

django_ipam/base/models.py
2
98.33%

Totals

Change from base Build 166:
-1.1%

Covered Lines:
447

Relevant Lines:
452

💛  - Coveralls

Any help on how to get the coverage back to 100% again? :/

Now I am getting an error in the travis build. Can someone help me to fix that error and give me some instructions on how to further proceed? Thanks. I'm relatively new to coverage things with python...

After a loooong tiring day, I managed to do it. Please let me know of other things that I need to fix or improvements that I need to do.

I'm still not really understanding what to do... Could you guide me a little more please?

So... as far as I understood, all the files in django-ipam remains the same. Just in django_ipam/api/serializers.py, we pass ValidatedModelSerializer as the parameter then remove validate methods from other serializers files. So to start with, how do I import that from openwisp-utils?
Let me know if my understanding is correct.

I don't know if I did it correctly this time. Please let me know...

I didn't know that's all that needed to be done. Also, I was trying to keep the first line of the commit message short so as that it is readable without expanding. It's sure better now though


Fix magboots not needing a grid to work

About the PR

fixes #29029
keeps the old behavior as a boolean because that's kino.
Media

[x] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Breaking changes

Changelog

:cl:

fix: Magboots no longer work when off-grid.

ok this bug is actually really nifty so im proposing a t3 tech
AntiAnti Gravity boots
magboots that work off-grid. They're battery powered and last for a few minutes.
if you add these i will insta merge.

AntiAnti Gravity boots
Just call them Suspense Boots or Grav Boots

ok this bug is actually really nifty so im proposing a t3 tech
noob i did first :trollface: https://github.com/space-wizards/space-station-14/issues/29029#issuecomment-2169396362


More Mux pattern options (SHIFTREG_ABC_BIN_DE)?

The precompiled binary seems to work for my esp8266 with pxmatrix, however the mux pattern appears to be wrong. It should be set to   SHIFTREG_ABC_BIN_DE for my panel. I am so far unable to rebuild with arduino or platformio. Is there a way to add this mux pattern setting via webbrowser without rebuilding? Thanks

I just ended up editing the config directly in the pxmatrix lib header

Not sure why two of the mux patterns aren't available from the dashboard, but presumably it's just a few lines of JS and C++ to fix.

Yeah it should be an easy enough addition. I tried editing the settings.vue, but had trouble rebuilding the dashboard, so I just renamed the patterns in the pxmatrix lib. I have a weird display evidently. Thanks for your work.


Patch 8

test

Hey @Yong-il-PallyCon! If you could remember to point your local PRs at your local repo instead of our master, that would be awesome. Thanks!


fix: preserve compiler error

What I did

fixes: #26
How I did it
raise specific err for compiler err in compile spot
leave install error to installs spots
take err data is preserved
How to verify it
Checklist

[ ] Passes all linting checks (pre-commit and CI jobs)
[ ] New test cases have been added and are passing
[ ] Documentation has been updated
[ ] PR title follows Conventional Commit standard (will be automatically included in the changelog)

I just tried to compile some garbage, it seems to work better now:
ERROR: (VyperCompileError) vyper.exceptions.StructureException: Unsupported syntax for module namespace: Expr
  contract "/var/folders/hg/17b1zhsn1n3d8b4rgh6ntt_w0000gn/T/vyper-ajp3wgog.vy", line 1:0
  ---> 1 asdfasdfasdf
  -------^
       2

[15687] Failed to execute script vyper_compile

[15687] Failed to execute script vyper_compile

^ Not exactly sure where the [15687] Failed to execute script vyper_compile comes from though

I think this is pyinstaller? maybe

Would be nice to add a few test cases

Totally agree! Thanks. They are added now.


Fix bug in compaction props

Fixes an issue with the deprecated tserver.compaction.major.thread.files.open.max property.
If the open.max property was set, the replacement property tserver.compaction.major.service.default.planner.opts.maxOpen would not be used and any user-defined compaction service would also only use the old open.max property value.
The cause was an error in the getFullyQualifiedOption of CompactionPlannerInitParams.
This has now been fixed and a test included to reproduce the problematic behavior.
a268958ddf411e460e85b9eb2cf71ab5fee5a4cd will fail the tests, and 4042529ac0491f0d25b7dc0f6cc89d547a1245cc includes the one line fix.

Switching this to draft until the proper changes are made for the defaultCompactionService behaviors

Removed some earlier changes and added test case for the default compaction service to ensure that user set properties correctly overrode default values.
Now this PR does not change the property lookup logic in the DefaultCompactionPlanner. It does replace a hardcoded maxOpen value with a default value reference,

I reverted this in d4a7a8984305306f3f0a4c594f64634cd65114a9 in favor of #4117, which keeps all the changes in this #4092 but uses SiteConfiguration instead of ConfigurationCopy to test overrides of system defaults, but without #4112 (which is OBE without the changes to ConfigurationCopy).


Initial stab at collaboratless comment filter

First stab at solving https://github.com/probot/stale/issues/147 I guess we can thank Stale for constantly poking me about this issue I raised years ago.
I've not actually run this yet to check it works or written any tests, I wanted to check two things first.

Is this actually a feature that we should add to probot? The issue suggests it's a feature some people desire, I've no idea how many people use stale though so I've no idea if it'll be worth maintaing this extra option.
Is this approach reasonable? I expect some change suggestions (especially to my rubbish naming) but it's worth disscussing the general approach of the code. The one problem I forsee is that this requires interrogating every issue for it's comments every time stale runs. This could potentially add a heavy load to Stale and it's understandable if we don't want to manage it. On the other hand, stale isn't something that needs to run "quickly" so maybe this is okay.

What do we think?

How ironic ^_^

I believe this is still relevant, and would love some feedback if possible. It looks like the project is being left in an as-is state though. Given that I'll let this tick through once more on the off chance this comes back into a maintained state, assuming it doesn't I'll let stale do it's thing.


Remove space from Community Metrics pre-commit job name

Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

It will help us expedite review of your Pull Request if you tag someone (e.g. @username) to look at it.


formatting/printing vector of quantities results in compile time error

Not sure if It's this library bug or fmt, but trying to print vector of quantity results in compile time error.
Problem reproduced in compiler explorer:
https://godbolt.org/z/7v5jjh9Gs
Problematic code:
#include <mp-units/systems/si/si.h>
#include <vector>
#include "fmt/ranges.h"
#include "mp-units/format.h"
#include "fmt/format.h"

using namespace mp_units::si::unit_symbols;

int main()
{
    using Time = mp_units::quantity<mp_units::isq::time[mp_units::si::second]>;
    Time time = 1 * s;
    fmt::println("{}",time);
    std::vector<Time> vec{time,time};
    fmt::println("{}",vec);
}

@WBurzynski, thanks for reporting! This seems to be related to #503. I actually started to work on this issue during the weekend, and it hopefully will be fixed soon.

Some time ago there was this issue in fmt: https://github.com/fmtlib/fmt/issues/2754 where const qualifiers were added to some functions. I suspect that either somewhere in fmt another const is missing or in auto format(const quantity& q, FormatContext& ctx) const quantity is too restrictive.

No, the problem is that the member function format() should be const qualified, but it isn't. It was changed while fmt was standardized.


Handle AAE files in osxphotos import

but it doesn't seem to generate the AAE file

Not every photo will have one of these. They're only generated when there are non-destructive edits performed in Photos and then not even all the time. Still a bit of a mystery to me. If you drag a file and it's AAE into Photos, Photos will import it along with the adjustments and recreate the adjustments. I've not yet figured out how to do this programmatically so osxphotos import will not yet import these.
Originally posted by @RhetTbull in https://github.com/RhetTbull/osxphotos/discussions/1267#discussioncomment-8915309

This works. AAE file must be imported in same call to import_photos:
>>> import photoscript
>>> pl = photoscript.PhotosLibrary()
>>> pl.import_photos(["/Users/rhet/Desktop/export/wedding.jpg", "/Users/rhet/Desktop/export/wedding.aae"])
[<photoscript.Photo object at 0x10baead50>]


Maybe a mistake in the current code.

Dear authors:
Thanks for your interesting and inspirational work! But  I think there may be a minor mistake in the provided codes. In the file embedding_lorenz.py, the following codes are included
        # Test accuracy of one time-step
        for i in range(xInput.size(1)):
            xInput0 = xInput[:,i].to(device)
            g0 = self.embedding_model.embed(xInput0)
            yPred0 = self.embedding_model.recover(g0)
            yPred[:,i] = yPred0.squeeze().detach()

        test_loss = mseLoss(yTarget, yPred)

I think it should be
        # Test accuracy of one time-step
        for i in range(xInput.size(1)):
            xInput0 = xInput[:,i].to(device)
            g0 = self.embedding_model.embed(xInput0)
            g0 = self.embedding_model.koopmanOperation(g0)
            yPred0 = self.embedding_model.recover(g0)
            yPred[:,i] = yPred0.squeeze().detach()

        test_loss = mseLoss(yTarget, yPred)

for its practical effect.

I agree. I have the same comment


Fix width on FunctionController property_name

Before: Text descriptions for buttons (FunctionController) were being truncated unnecessarily to the same width as other Controllers that must share real estate with input elements.
This PR sets the css width for FunctionController elements to 100%.  I've added to example.html in case it's useful.
Before:

After:

@googlebot I signed it!

@mrdoob -- might you let me know how to move this forward (or decide it's not wanted?).  Many thanks!