Should a handler also receive sub-events when using dynamism?

Consider:
@connect('childen.*.mouse_down')
def _handle_child_clck(self, *events):
     for ev in events:
           ...

The handler will probably use ev.source to get the corresponding child and then do something with it. However, this handler will also get an event when the children property changes. Therefore it likely needs a if ev.type == 'mouse_down', but this might be confusing.
On the other hand, it would make sense for this handler:
@connect('childen.*.count')
def _update_total_count(self, *events):
    self.total_count = sum([child.count for chuld in children])

... which can probably use @connect('children', 'childen.*.count') in that case.
cc @Korijn

BTW: this behavior probably stems from the "reactive" model that used signals instead of events.

I think the distinction lies in the fact that we're subscribing to a property in one case (so we're probably defining a computed value over the set of properties) and we're listening to an interaction event in the other where the collection of emitters isn't relevant.
@connect('children.*.count')
def _update_total_count(self, *events):
    self.total_count = sum([child.count for child in children])

If children changes, it makes sense that this handler is called, since the collection of count properties we're subscribed to changes:
@connect('children.*.mouse_down')
def _handle_child_clck(self, *events):
     for ev in events:
           ...

However, in this case, we're subscribed to a collection of mouse_down event emitters. Our handler is not a "computed value", but an interaction handler. We don't care about the collection of event handlers, we only care about the events as they are raised.

Yes, but changing the behavior based on whether the event corresponds to a property or not seems like it will lead to even more confusion.
I think I like the idea that you only get events for the latest element in a 'x.y.actual_event'. It's easy and explicit to add an extra event to @connect(). The downside is that in a case like calculating the total count, one might forget to do that. My feeling is that the advantages outweigh this downside though. WDYT?

Explicit > implicit, so I would agree with your preference in this case.

Thinking about this some more; changing a collection of event emitters like mouse_down doesn't alter the aggregated set of values, changing a collection of properties does. Is that really so counter-intuitive? I'm trying to think of a use case where changing the behaviour for props-or-not would actually e confusing.

Well, there are cases where you connect to some_collection.*.some_prop, and handle each event separately, using e.g. ev.source. If this handler would receive also events for changes in some_collection, you'd need to apply the same if ev.type == .. that annoyed us :)  And it would be strange (I think) if it occurred here and not for regular events. In other words, I feel uncomfortable treating events differently based on whether they correspond to a property.

Closed by #130


Added more options: debounce, enterOnSpace, allowNotSelectedItems

Hi,
Added some more options I needed:

debounce - Let the user specify the throttling debounce time in msec
enterOnSpace - treat space key like enter (more intuitive especially when combined with allowNotSelectedItems below)
allowNotSelectedItems - Allow selecting items that are not in the list (for letting the user entering new tags for example)
Added clear function to reset values/texts

If interested in these changes I will make required changes to the README,
Thx.

Debounce option will be very appreciable


drivers: sensor: a01nyub: added driver

Added a driver for the DFRobot A01NYUB distance sensor. This sensor sends its readings via UART at 9600 baud. This driver uses interrupts to read the data from the sensor.

@nashif , @galak : bringing this PR back to the top of your inbox now that the merge window has reopened.  Please let me know if any further edits are required.


Run iOS example error

Hi, i want to use this lib, but when i try to run example in iOS i can't
I follow steps in README.md but i catch this error: "Module 'FBSDKCoreKit' not found".
Do exists any additional step not listeted on the README.md?

Hi, i want to use this lib, but when i try to run example in iOS i can't
I follow steps in README.md but i catch this error: "Module 'FBSDKCoreKit' not found".
Do exists any additional step not listeted on the README.md?

Try this:

Navigate to ../ios/Pods/FBSDKLoginKit/FBSDKLoginKit/FBSDKLoginKit/

Open FBSDKLoginButton.h

Find this if-else code:
#if defined BUCK || defined FBSDKCOCOAPODS || defined __cplusplus
#import <FBSDKCoreKit/FBSDKCoreKit.h>
#else
@import FBSDKCoreKit;
#endif

Comment it all but the line#import <FBSDKCoreKit/FBSDKCoreKit.h>

Make sure it looks like this:

Clean and Build

I found another solution here: https://github.com/facebook/facebook-ios-sdk/issues/1102#issuecomment-551872120
But i tested your solution and it worked too
Thanks

I found another solution here: facebook/facebook-ios-sdk#1102 (comment)
But i tested your solution and it worked too
Thanks

Awesome! You're welcome


feat: add support for private docker registries

Summary
This PR adds the ability to specify the username and password to use when authenticating against a registry. It does this by adding two new flags:

--username, -u
--password, -p

In addition, the --content-path short name has been updated to be -c (from -p as that seems more fitting for --password).
Review Notes

This currently only supports writing your username/password to the console. Its fine to have this as is but we should also come up with a better way of using the docker config so that users can do this more securely locally. This is likely a good follow-up.
There is the ability for us to add another flag that specifies what server to use but it felt superfluous as it defaults to wherever the image is stored. I'd be happy to update it if we want that.
I did not add tests here as the bloat for testing private registries would delay this feature. I'd prefer get this through and worry about that complex testing logic later.

Closes #1

For some reason the test status is hung up -- I will manually merge

Thanks for the PR!


feat: On a knowledge panel page, try to use the group title (eg: Additives)

Will fix #2076
https://user-images.githubusercontent.com/246838/171613834-35e60c88-be64-4193-8b33-13f9c43c8fec.mp4

Little conflict to fix

Fixed 👍


Remove has draft collection

We recently discussed the removal of these collections that only hold boolean values.
While starting to work on https://github.com/Expensify/App/issues/7948 I wanted to start with fixing these drafts to help clean things up before getting into the meat of the issue.
Details
This PR removes the old Onyx collection for reportHasDraft_ and move the information to a hasDraft property on each report.
Fixed Issues
Related to https://github.com/Expensify/App/issues/7948
Tests
Covered by unit tests

[ ] Verify that no errors appear in the JS console

QA Steps

Open a chat
Start writing a comment
Verify the edit/pencil icon appears in the LHN for the active report
While still having a draft comment, switch to another report
Start writing a comment on the new report
Verify that both reports have the edit/pencil icon showing, since they have drafts

Screenshots

Web

Mobile Web

Desktop

iOS

Android

all my commits are unsigned... great

Closing this PR in favor of https://github.com/Expensify/App/pull/10532 due to unsigned commits. I also removed the migration.


Nuxt 3 support

Hi!
Apparently, this module doesn't work with Nuxt 3 yet. When I add it to nuxt.config.ts, the server returns 500 and throws the following error:
__vite_ssr_import_1__.default.component is not a function
  at $id_4811d1b0 (file://./.nuxt/dist/server/server.mjs:5390:31)
  at async __instantiateModule__ (file://./.nuxt/dist/server/server.mjs:8182:3)

Are there plans to update the module for Nuxt 3?

$ nuxi prepare

 ERROR  Cannot destructure property 'nuxt' of 'this' as it is undefined.
  at module.exports (node_modules/@nuxtjs/amp/lib/module.js:20:11)

Any news about Nuxt 3 support?

Thanks for the issue guys, will move the discussion to this issue to track: https://github.com/nuxt-community/amp-module/issues/273


Bug Report: when i run "lime test windows or

Please check for duplicates, similar issues or closed issues with the same problem, as well performing simple troubleshooting steps (such as deleting the export folder if it's an issue with compiling, reinstalling Kade Engine) before submitting an issue.
If you are playing a downloaded version of the game, what operating system are you using?
Windows (x86), Windows (x86_64), Linux, or macOS? Specify below.
Windows (`x86)
What version of the game are you using? Look in the bottom left corner of the main menu.
1.5.4
Have you identified any steps to reproduce the bug? If so, please describe them below. Use images if possible
No
Please describe your issue. Provide extensive detail and images if possible.

Well, every single time i run the command "lime test windows" or "lime test windows -debug" it says this: Error: Pointer.cpp
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30037\include\yvals.h(12): fatal error C1083: Unable to open include file: 'crtdbg.h': No such file or directory.

Have a great day and the person that solves me this crap will be on the credits of my mod

I think u didn't install all the Microsoft Visual 2019 individual components or one of them didn't install properly.
I exactly don't know what is missing here but I'm sure that it's related to Microsoft Visual 2019 since you can build the html5 version.
**Possible solution: I think you should reinstall Microsoft Visual 2019 with all of the individual components for windows/mac/Linux (whatever u are on) mentioned here. **

I tried everything you said but still dosen't work and also i cannot download (lime rebuild extension-webm windows) so now i think that is relationed with the problem

@HePpYPro what version of Haxe you are using? Bcz the latest version of haxe have some issues with kade engine..

@LK-Lilon i'm using the 4.1.5 but i think when you run the command haxelib update flixel it updates haxe to 4.2.1/ the lastest version.

i've tried to do what you told me to do on the 1 message:"I think u didn't install all the Microsoft Visual 2019 individual components or one of them didn't install properly." And i tried to do it again because i didn't knew how to install the components but they are downloading so thank you for resolving tthe problem and this issue, is offically closed
Thx and bye!!


Readme updates #419

Currently 3 main READMEs:

Project README
Android README
Data-Pipeline README

Note: Moved old content into "archived" readmes.
@apike Please review and let me know if you want more content anywhere.

:+1:

Rebased, merged, squashed manually.


The build cfg of common lib

We use sed -i '' 's/^#include <syscall.h>/#include <sys\/syscall.h>/' src/logging.cc to make it work on MacOS.
It's better to add a fix patch on https://github.com/4paradigm/common ?

Now it's a patch file in third-party/patches


Fix DNS Discovery

Description
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Fixes #(issue)
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration.

[ ] Test A
[ ] Test B

Pull Request Test Coverage Report for Build 254017566

8 of 15 (53.33%)  changed or added relevant lines in 3 files are covered.
27 unchanged lines in 4 files lost coverage.
Overall coverage decreased (-0.2%) to 50.676%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

internal/discovery/search-domain-operator/wan.go
5
12
41.67%

Files with Coverage Reduction
New Missed Lines
%

internal/kubernetes/mutation.go
2
96.24%

internal/liqonet/route-operator.go
4
72.81%

pkg/liqonet/route.go
4
0%

pkg/liqonet/route_mock.go
17
50.88%

Totals

Change from base Build 253898806:
-0.2%

Covered Lines:
6748

Relevant Lines:
13316

💛  - Coveralls

/rebase


feat: add query data commitment for height

Overview

Checklist

[ ] New and updated code has appropriate documentation
[ ] New and updated code has new and/or updated testing
[ ] Required CI checks are passing
[ ] Visual proof for any user facing features like CLI or documentation updates
[ ] Linked issues closed with keywords

Codecov Report

Merging #193 (49724b0) into main (d285731) will decrease coverage by 0.03%.
The diff coverage is 45.45%.

@@            Coverage Diff             @@
##             main     #193      +/-   ##
==========================================
- Coverage   47.91%   47.89%   -0.03%
==========================================
  Files          18       18
  Lines        1175     1186      +11
==========================================
+ Hits          563      568       +5
- Misses        548      552       +4
- Partials       64       66       +2

Impacted Files
Coverage Δ

rpc/app_querier.go
49.10% <45.45%> (-0.40%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Wrong link in automatic tweet for collectives of type event

Need to use collective.path instead of collective.slug

@xdamman Which tweet are we talking about here?

The one when there are at least 10 backers.
We should probably simply disable that tweet for events. It doesn’t make much sense.

@xdamman good idea

@znarf @xdamman if this if done we can close this
otherwise please LMK if we wanna do this?

Adjusting the complexity to minimal, based on our new classification.


[Bug]: function keyword suggested annotation context

Description
Consider
import ballerina/module1;

public type AnnotationType record {
    string foo;
    int bar?;
};

public const annotation AnnotationType sourceVarAnnotation1 on source var;

public const annotation sourceVarAnnotation2 on source var;

@<cursor>
int testModuleVar = 12;

At cursor, we suggest the function keyword. It's not relevant to that context. Also double check the completions we provide at annotation context.

Steps to Reproduce
No response
Affected Version(s)
No response
OS, DB, other environment details and versions
No response
Related area
-> Editor
Related issue(s) (optional)
No response
Suggested label(s) (optional)
No response
Suggested assignee(s) (optional)
No response

Closing this as a low-priority task with the Icebox label might reopen in the future.


(needs research) rails / django / flask integration

write a guide for rails folks

I'll be writing a brunch w/ flask blog post, specifically for a microsite build and deployment, using brunch 1.0 and some deployment scripts.

Great! So, flask is done.


Update README.md

Made various corrections to improve reading flow. Added a little reference to myself. ;-)

Thanks Tony :+1:


Minor changes to make it compatible with both WSH and ASP

<script>, even in comments, triggers Active Server Pages error 'ASP 0138', Nested Script Block Error.
Also, using global ← this pattern works on WSH but not on ASP, it's better to just Mustache = {}, since its less typing, works on all platforms and it's the the desired behavior.

Hi @nagaozen, thanks for the PR!
Unfortunately, it's breaking the Travis build: the linter quits. Can you fix it? Cheers!
> eslint mustache.js
mustache.js
  14:12  error  "Mustache" is not defined  no-undef

Fixed with 60c2da80783a7


[Feature Request] Add BasicChatMods Compatibility to Fade In

Hello!
First of all: Thank you so much for your addon. I really love it!
I'm not sure if that's a thing on LS: Glass' or BasicChatMods' site but there's currently some unbeautiful behavior between fading in new messages and chat formatting provided by BasicChatMods.
Example:
https://streamable.com/9hacot
It seems like formatting is applied after the fade in animation has finished.
Thanks in advance :)

Hi :>
This behaviour is expected due to how chat addons work, we all independently hook up to the same stuff and then process it on our end. That's why this kind of desyncs happen. I'll look into what BCM is doing and if it's possible to tap into it without too much pain in my butt on my end, but I also have plans for my own text processing eventually, but they aren't a high prio for me atm.

As expected funkydude and his addons, it's pretty straightforward. I'll try some stuff out later.

I lied, after checking that stuff our closer, none of his functions are actually exposed, so it's impossible for me to hook up to it.

But there's a workaround for that, I think...

K, this should do the trick, I changed where I'm pulling the data from, so it should be more compatible with text processing done by other chat addons 😊


Test caching implementation with real world pipeline

As caching is integrated and test tests pass it is important we do some real work testing to see if it improves things.

Depends on #379

Depends on BD2KGenomics/toil-scripts#33

@benedictpaten, @jvivian, do we still want to do this now or should this wait until @arkal's caching improvements in #586?

Would still be good to test the current implementation, which is useful if
tuned correctly. Given @arkal's timeline, we may have to use the current
aching implementation in the toil scaled runs.
On Thu, Dec 3, 2015 at 2:48 PM, Hannes Schmidt<EMAIL_ADDRESS>wrote:

@benedictpaten https://github.com/benedictpaten, @jvivian
https://github.com/jvivian, do we still want to do this now or should
this wait until @arkal https://github.com/arkal's caching improvements
in #586 https://github.com/BD2KGenomics/toil/issues/586?
—
Reply to this email directly or view it on GitHub
https://github.com/BD2KGenomics/toil/issues/440#issuecomment-161813490.
--
You received this message because you are subscribed to the Google Groups
"cgloud-jenkins" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to<EMAIL_ADDRESS>To post to this group, send email to<EMAIL_ADDRESS>To view this discussion on the web visit
https://groups.google.com/d/msgid/cgloud-jenkins/BD2KGenomics/toil/issues/440/161813490%40github.com
https://groups.google.com/d/msgid/cgloud-jenkins/BD2KGenomics/toil/issues/440/161813490%40github.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

@arkal tested caching on ProTECT pipeline and results went into Toil documentation for paper.


CUDA fails to lower vector.transfer_write to NVVM

With #13747  MiniLM fails to lower to NVVM. Specifically the issue is caused by the following dispatch
hal.executable private @repro {
hal.executable.variant public @cuda_nvptx_fb, target = <"cuda", "cuda-nvptx-fb", {target_arch = "sm_80"}> {
  hal.executable.export public @predict_dispatch_7_generic_384x128_f32 ordinal(0) layout(#hal.pipeline.layout<push_constants = 0, sets = [<0, bindings = [<0, storage_buffer, ReadOnly>, <1, storage_buffer>, <2, storage_buffer>]>]>) {
  ^bb0(%arg0: !hal.device):
    %x, %y, %z = flow.dispatch.workgroup_count_from_slice
    hal.return %x, %y, %z : index, index, index
  }
  builtin.module {
    func.func @predict_dispatch_7_generic_384x128_f32() {
      %c512 = arith.constant 512 : index
      %c787456 = arith.constant 787456 : index
      %c984064 = arith.constant 984064 : index
      %cst = arith.constant 0.000000e+00 : f32
      %0 = hal.interface.binding.subspan set(0) binding(0) type(storage_buffer) alignment(64) offset(%c512) flags(ReadOnly) : !flow.dispatch.tensor<readonly:tensor<128x384xf32>>
      %1 = hal.interface.binding.subspan set(0) binding(1) type(storage_buffer) alignment(64) offset(%c787456) : !flow.dispatch.tensor<writeonly:tensor<128x384xf32>>
      %2 = hal.interface.binding.subspan set(0) binding(2) type(storage_buffer) alignment(64) offset(%c984064) : !flow.dispatch.tensor<writeonly:tensor<384x128xf32>>
      %3 = flow.dispatch.tensor.load %0, offsets = [0, 0], sizes = [128, 384], strides = [1, 1] : !flow.dispatch.tensor<readonly:tensor<128x384xf32>> -> tensor<128x384xf32>
      %4 = tensor.empty() : tensor<384x128xf32>
      %5 = tensor.empty() : tensor<128x384xf32>
      %6:2 = linalg.generic {indexing_maps = [affine_map<(d0, d1) -> (d1, d0)>, affine_map<(d0, d1) -> (d1, d0)>, affine_map<(d0, d1) -> (d0, d1)>], iterator_types = ["parallel", "parallel"]} ins(%3 : tensor<128x384xf32>) outs(%5, %4 : tensor<128x384xf32>, tensor<384x128xf32>) {
      ^bb0(%in: f32, %out: f32, %out_0: f32):
        %7 = arith.addf %in, %cst : f32
        linalg.yield %cst, %7 : f32, f32
      } -> (tensor<128x384xf32>, tensor<384x128xf32>)
      flow.dispatch.tensor.store %6#0, %1, offsets = [0, 0], sizes = [128, 384], strides = [1, 1] : tensor<128x384xf32> -> !flow.dispatch.tensor<writeonly:tensor<128x384xf32>>
      flow.dispatch.tensor.store %6#1, %2, offsets = [0, 0], sizes = [384, 128], strides = [1, 1] : tensor<384x128xf32> -> !flow.dispatch.tensor<writeonly:tensor<384x128xf32>>
      return
    }
  }
}
}

To repro run
$ iree-opt --pass-pipeline="builtin.module(hal.executable(hal.executable.variant(iree-llvmgpu-lower-executable-target)))" repro.mlir

The specific issue here is
    %12 = llvm.mlir.constant(0 : index) : i64
    %13 = builtin.unrealized_conversion_cast %12 : i64 to index
    ....
    vector.transfer_write %3, %182[%13, %13] : vector<4xf32>, memref<4x1xf32, strided<[384, 1], offset: ?>>

That vector.transfer_write somehow doesnt get lowered to NVVM, which causes the issue.

@KoolJBlack do you think you could take a look at this?

I can potentially take a look tomorrow after another few runs of tuning. Will update then.

@MaheshRavishankar Routing this back to you as Kojo is leaving for vacation.

Ok, downgrading this to P1... I need this to land my PR, so maybe I can get to it...

Actually my repro instructions were wrong. To repro use
module {
  func.func @test_dispatch_0_generic_384x128_f32() {
    %c99 = arith.constant 99 : index
    %c66 = arith.constant 66 : index
    %c33 = arith.constant 33 : index
    %c384 = arith.constant 384 : index
    %c0 = arith.constant 0 : index
    %cst = arith.constant dense<0.000000e+00> : vector<4x1xf32>
    %cst_0 = arith.constant dense<0.000000e+00> : vector<1x4xf32>
    %c-32 = arith.constant -32 : index
    %c8 = arith.constant 8 : index
    %c-128 = arith.constant -128 : index
    %c-1 = arith.constant -1 : index
    %c4 = arith.constant 4 : index
    %c32 = arith.constant 32 : index
    %cst_1 = arith.constant dense<0.000000e+00> : vector<4xf32>
    %c196608 = arith.constant 196608 : index
    %0 = gpu.thread_id  x
    %1 = gpu.thread_id  y
    %2 = gpu.thread_id  z
    %alloc = memref.alloc() : memref<32x33xf32, #gpu.address_space<workgroup>>
    %3 = hal.interface.binding.subspan set(0) binding(0) type(storage_buffer) alignment(64) offset(%c0) flags(ReadOnly) : memref<128x384xf32>
    memref.assume_alignment %3, 64 : memref<128x384xf32>
    %4 = hal.interface.binding.subspan set(0) binding(1) type(storage_buffer) alignment(64) offset(%c0) : memref<128x384xf32>
    memref.assume_alignment %4, 64 : memref<128x384xf32>
    %workgroup_id_x = hal.interface.workgroup.id[0] : index
    %5 = arith.muli %workgroup_id_x, %c32 : index
    %6 = arith.cmpi slt, %workgroup_id_x, %c0 : index
    %7 = arith.subi %c-1, %workgroup_id_x : index
    %8 = arith.select %6, %7, %workgroup_id_x : index
    %9 = arith.divsi %8, %c4 : index
    %10 = arith.subi %c-1, %9 : index
    %11 = arith.select %6, %10, %9 : index
    %12 = arith.muli %11, %c-128 : index
    %13 = arith.addi %5, %12 : index
    %14 = arith.muli %11, %c32 : index
    %15 = hal.interface.binding.subspan set(0) binding(2) type(storage_buffer) alignment(64) offset(%c196608) : memref<384x128xf32, strided<[128, 1], offset: 49152>>
    memref.assume_alignment %15, 64 : memref<384x128xf32, strided<[128, 1], offset: 49152>>
    gpu.barrier
    %16 = arith.muli %2, %c32 : index
    %17 = arith.addi %1, %16 : index
    %18 = arith.cmpi slt, %0, %c0 : index
    %19 = arith.subi %c-1, %0 : index
    %20 = arith.select %18, %19, %0 : index
    %21 = arith.divsi %20, %c8 : index
    %22 = arith.subi %c-1, %21 : index
    %23 = arith.select %18, %22, %21 : index
    %24 = arith.addi %17, %23 : index
    %25 = arith.muli %0, %c4 : index
    %26 = arith.muli %23, %c-32 : index
    %27 = arith.addi %25, %26 : index
    %28 = arith.addi %13, %24 : index
    %29 = arith.addi %14, %27 : index
    %30 = vector.load %3[%28, %29] : memref<128x384xf32>, vector<4xf32>
    vector.store %30, %alloc[%24, %27] : memref<32x33xf32, #gpu.address_space<workgroup>>, vector<4xf32>
    gpu.barrier
    %base_buffer, %offset, %sizes:2, %strides:2 = memref.extract_strided_metadata %4 : memref<128x384xf32> -> memref<f32>, index, index, index, index, index
    %31 = arith.muli %13, %c384 : index
    %32 = arith.muli %25, %c384 : index
    %33 = arith.addi %31, %32 : index
    %34 = arith.addi %33, %14 : index
    %35 = arith.addi %34, %1 : index
    %reinterpret_cast = memref.reinterpret_cast %base_buffer to offset: [%35], sizes: [4, 1], strides: [384, 1] : memref<f32> to memref<4x1xf32, strided<[384, 1], offset: ?>>
    %36 = arith.muli %25, %c33 : index
    %37 = arith.addi %36, %1 : index
    %reinterpret_cast_2 = memref.reinterpret_cast %alloc to offset: [%37], sizes: [1, 1], strides: [33, 1] : memref<32x33xf32, #gpu.address_space<workgroup>> to memref<1x1xf32, strided<[33, 1], offset: ?>, #gpu.address_space<workgroup>>
    %38 = memref.load %reinterpret_cast_2[%c0, %c0] : memref<1x1xf32, strided<[33, 1], offset: ?>, #gpu.address_space<workgroup>>
    %39 = vector.broadcast %38 : f32 to vector<1xf32>
    %40 = vector.insert %39, %cst [0] : vector<1xf32> into vector<4x1xf32>
    %41 = arith.addi %1, %c33 : index
    %42 = arith.addi %41, %36 : index
    %reinterpret_cast_3 = memref.reinterpret_cast %alloc to offset: [%42], sizes: [1, 1], strides: [33, 1] : memref<32x33xf32, #gpu.address_space<workgroup>> to memref<1x1xf32, strided<[33, 1], offset: ?>, #gpu.address_space<workgroup>>
    %43 = memref.load %reinterpret_cast_3[%c0, %c0] : memref<1x1xf32, strided<[33, 1], offset: ?>, #gpu.address_space<workgroup>>
    %44 = vector.broadcast %43 : f32 to vector<1xf32>
    %45 = vector.insert %44, %40 [1] : vector<1xf32> into vector<4x1xf32>
    %46 = arith.addi %1, %c66 : index
    %47 = arith.addi %46, %36 : index
    %reinterpret_cast_4 = memref.reinterpret_cast %alloc to offset: [%47], sizes: [1, 1], strides: [33, 1] : memref<32x33xf32, #gpu.address_space<workgroup>> to memref<1x1xf32, strided<[33, 1], offset: ?>, #gpu.address_space<workgroup>>
    %48 = memref.load %reinterpret_cast_4[%c0, %c0] : memref<1x1xf32, strided<[33, 1], offset: ?>, #gpu.address_space<workgroup>>
    %49 = vector.broadcast %48 : f32 to vector<1xf32>
    %50 = vector.insert %49, %45 [2] : vector<1xf32> into vector<4x1xf32>
    %51 = arith.addi %1, %c99 : index
    %52 = arith.addi %51, %36 : index
    %reinterpret_cast_5 = memref.reinterpret_cast %alloc to offset: [%52], sizes: [1, 1], strides: [33, 1] : memref<32x33xf32, #gpu.address_space<workgroup>> to memref<1x1xf32, strided<[33, 1], offset: ?>, #gpu.address_space<workgroup>>
    %53 = memref.load %reinterpret_cast_5[%c0, %c0] : memref<1x1xf32, strided<[33, 1], offset: ?>, #gpu.address_space<workgroup>>
    %54 = vector.broadcast %53 : f32 to vector<1xf32>
    %55 = vector.insert %54, %50 [3] : vector<1xf32> into vector<4x1xf32>
    %56 = arith.addf %55, %cst : vector<4x1xf32>
    %57 = vector.extract %56[0, 0] : vector<4x1xf32>
    %58 = vector.insert %57, %cst_0 [0, 0] : f32 into vector<1x4xf32>
    %59 = vector.extract %56[1, 0] : vector<4x1xf32>
    %60 = vector.insert %59, %58 [0, 1] : f32 into vector<1x4xf32>
    %61 = vector.extract %56[2, 0] : vector<4x1xf32>
    %62 = vector.insert %61, %60 [0, 2] : f32 into vector<1x4xf32>
    %63 = vector.extract %56[3, 0] : vector<4x1xf32>
    %64 = vector.insert %63, %62 [0, 3] : f32 into vector<1x4xf32>
    vector.transfer_write %cst_1, %reinterpret_cast[%c0, %c0] : vector<4xf32>, memref<4x1xf32, strided<[384, 1], offset: ?>>
    %65 = vector.extract %64[0] : vector<1x4xf32>
    %66 = arith.addi %14, %1 : index
    %67 = arith.addi %13, %25 : index
    vector.store %65, %15[%66, %67] : memref<384x128xf32, strided<[128, 1], offset: 49152>>, vector<4xf32>
    return
  }

iree-opt --iree-convert-to-nvvm repro.mlir

This does not fail as such, but leaves a builtin.unrealized_conversion_cast which results an error later in the compilation (which is another error, these should be marked as illegal to catch the error here.)

A smaller repro
func.func @small_repro(%2 : vector<4xf32>, %12: index, %140 : memref<4x1xf32, strided<[384, 1], offset: ?>>) {
  vector.transfer_write %2, %140[%12, %12] : vector<4xf32>, memref<4x1xf32, strided<[384, 1], offset: ?>>
  return
}

Running
iree-opt --iree-convert-to-nvvm --debug small_repro.mlir

shows
Trying to match "(anonymous namespace)::TransferWriteToVectorStoreLowering"
mlir-asm-printer: Verifying operation: func.func
    ** Failure : out of bounds dim: vector.transfer_write %arg0, %arg2[%arg1, %arg1] : vector<4xf32>, memref<4x1xf32, strided<[384, 1], offset: ?>>
"(anonymous namespace)::TransferWriteToVectorStoreLowering" result 0
  } -> FAILURE : pattern failed to match
} -> FAILURE : no matched legalization pattern

I think I know the issue. Looking into fixing it.

Adding some more notes. @KoolJBlack and I have been looking at the issue here. I think it comes down to an error in --iree-codegen-gpu-vectorization pass. It is introducing this operation
   %16 = vector.transfer_write %cst_0, %extracted_slice_2[%c0, %c0] {in_bounds = [true, false]} : vector<1x4xf32>, tensor<4x1xf32>

which seems like a strange operation The vector type and tensor type seems mismatched, and IIUC this would require a permutation map to be present...
THis is the IR before this pass
unc.func @predict_dispatch_7_generic_384x128_f32() {
  %c512 = arith.constant 512 : index
  %c787456 = arith.constant 787456 : index
  %c984064 = arith.constant 984064 : index
  %cst = arith.constant 0.000000e+00 : f32
  %0 = hal.interface.binding.subspan set(0) binding(0) type(storage_buffer) alignment(64) offset(%c512) flags(ReadOnly) : !flow.dispatch.tensor<readonly:tensor<128x384xf32>>
  %1 = hal.interface.binding.subspan set(0) binding(1) type(storage_buffer) alignment(64) offset(%c787456) : !flow.dispatch.tensor<writeonly:tensor<128x384xf32>>
  %workgroup_id_x = hal.interface.workgroup.id[0] : index
  %2 = affine.apply affine_map<()[s0] -> (s0 * 32 - (s0 floordiv 4) * 128)>()[%workgroup_id_x]
  %3 = affine.apply affine_map<()[s0] -> ((s0 floordiv 4) * 32)>()[%workgroup_id_x]
  %4 = flow.dispatch.tensor.load %1, offsets = [%2, %3], sizes = [32, 32], strides = [1, 1] : !flow.dispatch.tensor<writeonly:tensor<128x384xf32>> -> tensor<32x32xf32>
  %5 = hal.interface.binding.subspan set(0) binding(2) type(storage_buffer) alignment(64) offset(%c984064) : !flow.dispatch.tensor<writeonly:tensor<384x128xf32>>
  %6 = flow.dispatch.tensor.load %5, offsets = [%3, %2], sizes = [32, 32], strides = [1, 1] : !flow.dispatch.tensor<writeonly:tensor<384x128xf32>> -> tensor<32x32xf32>
  %7 = flow.dispatch.tensor.load %0, offsets = [%2, %3], sizes = [32, 32], strides = [1, 1] : !flow.dispatch.tensor<readonly:tensor<128x384xf32>> -> tensor<32x32xf32>
  %8 = bufferization.alloc_tensor() copy(%7) {bufferization.escape = [false]} : tensor<32x32xf32>
  %9:2 = scf.forall (%arg0, %arg1) in (32, 8) shared_outs(%arg2 = %4, %arg3 = %6) -> (tensor<32x32xf32>, tensor<32x32xf32>) {
    %10 = affine.apply affine_map<(d0) -> (d0 * 4)>(%arg1)
    %11 = affine.apply affine_map<(d0) -> (d0 * 4)>(%arg1)
    %12 = affine.apply affine_map<(d0) -> (d0 * 4)>(%arg1)
    %extracted_slice = tensor.extract_slice %8[%10, %arg0] [4, 1] [1, 1] : tensor<32x32xf32> to tensor<4x1xf32>
    %extracted_slice_0 = tensor.extract_slice %arg2[%11, %arg0] [4, 1] [1, 1] : tensor<32x32xf32> to tensor<4x1xf32>
    %extracted_slice_1 = tensor.extract_slice %arg3[%arg0, %12] [1, 4] [1, 1] : tensor<32x32xf32> to tensor<1x4xf32>
    %13:2 = linalg.generic {indexing_maps = [affine_map<(d0, d1) -> (d1, d0)>, affine_map<(d0, d1) -> (d1, d0)>, affine_map<(d0, d1) -> (d0, d1)>], iterator_types = ["parallel", "parallel"]} ins(%extracted_slice : tensor<4x1xf32>) outs(%extracted_slice_0, %extracted_slice_1 : tensor<4x1xf32>, tensor<1x4xf\
32>) attrs =  {__internal_linalg_transform__ = "workgroup_k_tiled", lowering_config = #iree_codegen.lowering_config<tile_sizes = [[32, 32]]>} {
    ^bb0(%in: f32, %out: f32, %out_2: f32):
      %16 = arith.addf %in, %cst : f32
      linalg.yield %cst, %16 : f32, f32
    } -> (tensor<4x1xf32>, tensor<1x4xf32>)
    %14 = affine.apply affine_map<(d0) -> (d0 * 4)>(%arg1)
    %15 = affine.apply affine_map<(d0) -> (d0 * 4)>(%arg1)
    scf.forall.in_parallel {
      tensor.parallel_insert_slice %13#0 into %arg2[%14, %arg0] [4, 1] [1, 1] : tensor<4x1xf32> into tensor<32x32xf32>
      tensor.parallel_insert_slice %13#1 into %arg3[%arg0, %15] [1, 4] [1, 1] : tensor<1x4xf32> into tensor<32x32xf32>
    }
  } {mapping = [#gpu.thread<y>, #gpu.thread<x>]}
  flow.dispatch.tensor.store %9#0, %1, offsets = [%2, %3], sizes = [32, 32], strides = [1, 1] : tensor<32x32xf32> -> !flow.dispatch.tensor<writeonly:tensor<128x384xf32>>
  flow.dispatch.tensor.store %9#1, %5, offsets = [%3, %2], sizes = [32, 32], strides = [1, 1] : tensor<32x32xf32> -> !flow.dispatch.tensor<writeonly:tensor<384x128xf32>>
  return
}

Running
iree-opt --iree-codegen-gpu-vectorization <repro> --debug

shows this being generated by vectorization
ImplicitTypeIDRegistry::lookupOrInsert(mlir::vector::detail::TransferWriteOpGenericAdaptorBase::Properties)
    ** Insert  : 'vector.transfer_write'(0x557ae6f02f80)
[linalg-vectorization] Trying to mask: mlir-asm-printer: Verifying operation: func.func
%17 = vector.transfer_write %cst_7, %extracted_slice_0[%c0_6, %c0_6] {permutation_map = affine_map<(d0, d1) -> (d1, d0)>} : vector<4x1xf32>, tensor<4x1xf32>

I think the types and permutation_map here are off. Also it seems like masking seems to be kicking in even though I tried setting masking off....
Ill try to work around this error. The fix doesnt seem simple. Maybe @dcaballe or @antiagainst have more info on this.

The problem occurs during the vectorization of the linalg.generic. Here is a full dump of lowering to NVVM: lower-to-nvvm-dump. I'll highlight key points..
This is the isolated linalg generic (from Mahesh's first comment) where we start:
        %6:2 = linalg.generic {indexing_maps = [affine_map<(d0, d1) -> (d1, d0)>, affine_map<(d0, d1) -> (d1, d0)>, affine_map<(d0, d1) -> (d0, d1)>], iterator_types = ["parallel", "parallel"]} ins(%3 : tensor<128x384xf32>) outs(%5, %4 : tensor<128x384xf32>, tensor<384x128xf32>) {
        ^bb0(%in: f32, %out: f32, %out_0: f32):
            %7 = arith.addf %in, %cst : f32
            linalg.yield %cst, %7 : f32, f32
        } -> (tensor<128x384xf32>, tensor<384x128xf32>)

The linalg has 3 operands. Their shapes and affine maps:  ins: <128x384xf32>/<(d0, d1) -> (d1, d0)> and outs: <128x384xf32>/<(d0, d1) -> (d1, d0)> , <384x128xf32>/<(d0, d1) -> (d0, d1)>.  The tile size is [32,32] and workgroup size is [32, 8, 1].
Note:  The first input and first output are permuted. This relevant below.
After GPUTensorTile, right before GPUVectorization, we have tiled the workload to threads, each thread gets 4 elements.
    %13:2 = linalg.generic {indexing_maps = [affine_map<(d0, d1) -> (d1, d0)>, affine_map<(d0, d1) -> (d1, d0)>, affine_map<(d0, d1) -> (d0, d1)>], iterator_types = ["parallel", "parallel"]} ins(%extracted_slice : tensor<4x1xf32>) outs(%extracted_slice_0, %extracted_slice_1 : tensor<4x1xf32>, tensor<1x4xf32>) attrs =  {__internal_linalg_transform__ = "workgroup_k_tiled", lowering_config = #iree_codegen.lowering_config<tile_sizes = [[32, 32]]>} {
    ^bb0(%in: f32, %out: f32, %out_2: f32):
      %16 = arith.addf %in, %cst : f32
      linalg.yield %cst, %16 : f32, f32
    } -> (tensor<4x1xf32>, tensor<1x4xf32>)

When applying the LinalgVectorizationPattern to the linalg.generic , there is an eventually call to vectorizeLinalgYield() for linalg.yield %cst, %16 : f32, f32 which will propagate to the vector.transfer_writes wijth buildVectorWrite().
When generating these writes, the code uses the permutation maps from the linalg.generic for each transfer write. This permutes the first transfer write (second write is identity map, so unaffected):
ImplicitTypeIDRegistry::lookupOrInsert(mlir::vector::detail::TransferWriteOpGenericAdaptorBase::Properties)
    ** Insert  : 'vector.transfer_write'(0x55e164f11ca0)
checkpoint 1: mlir-asm-printer: Verifying operation: func.func
%17 = vector.transfer_write %cst_7, %extracted_slice_0[%c0_6, %c0_6] {permutation_map = affine_map<(d0, d1) -> (d1, d0)>} : vector<4x1xf32>, tensor<4x1xf32>

The result (after canonicalization) is a transfer write of <1x4> data into a <4x1> vector.
My guess: this should have stayed <4x1> write since the destination vector, derived from the DpsInitOperand, is a <4x1> (from tiling) which follows through to the subsequent parallel.insert_slice.  I cannot follow as to why indexing maps for the generic loops are also applied to the subsequent writes which aren't tied to that loop indexing. Perhaps this logic should be evaluated? @dcaballe authored this vectorization.

The instruction in the debug snippet looks ok to me. There is a permutation map that is swapping the dimensions, which is what we need for that store, right? Am I missing something? Do you know where the permutation map is removed?
Trying to mask doesn't mean that is masking the op. I don't see any mask for that write.

Could you share full dumps of the vectorization pass and the canonicalization that simplifies the transfer_write?

The instruction in the debug snippet looks ok to me. There is a permutation map that is swapping the dimensions, which is what we need for that store, right? Am I missing something? Do you know where the permutation map is removed?

I am confused. The permutation map is affine_map<(d0, d1) -> (d1, d0)> and is reading from a tensor<4x1xf32> and returning a vector<4x1xf32>. Given the permutation map my expectation was that the returned vector would be of type vector<1x4xf32>?

Trying to mask doesn't mean that is masking the op. I don't see any mask for that write.

Yeah, but the debug spew is confusing I guess.

Could you share full dumps of the vectorization pass and the canonicalization that simplifies the transfer_write?

Here is the full log https://gist.github.com/MaheshRavishankar/31b3b12d350e0989258424432bfd772c

Could you share full dumps of the vectorization pass and the canonicalization that simplifies the transfer_write?

Dump from just GPUVectorization pass :https://gist.github.com/KoolJBlack/3f86f786dce0a6422093da09a625fc81
Created with:
$IREE_BUILD/tools/iree-opt \
    --iree-codegen-gpu-vectorization \
    --debug \
    vectorize_input.mlir \
    2> vectorize_debug.mlir \
    1> vectorize_output.mlir

%17 = vector.transfer_write %cst_7, %extracted_slice_0[%c0_6, %c0_6] {permutation_map = affine_map<(d0, d1) -> (d1, d0)>} : vector<4x1xf32>, tensor<4x1xf32>
This is a store so the map is applied to the vector before the write into memory. This is, vector<4x1xf32> -> vector<1x4xf32>, which is then stored into tensor<vector<4x1xf32> so... yeah, the shapes are wrong :)
Let me take a look.

Running to a meeting. Could you please try this?
diff --git a/mlir/lib/Dialect/Linalg/Transforms/Vectorization.cpp b/mlir/lib/Dialect/Linalg/Transforms/Vectorization.cpp
index bbcde44f0861..2d24088ec885 100644
--- a/mlir/lib/Dialect/Linalg/Transforms/Vectorization.cpp
+++ b/mlir/lib/Dialect/Linalg/Transforms/Vectorization.cpp
@@ -606,7 +606,7 @@ static Value buildVectorWrite(RewriterBase &rewriter, Value value,
   auto linalgOp = cast<LinalgOp>(outputOperand->getOwner());
   AffineMap opOperandMap = linalgOp.getMatchingIndexingMap(outputOperand);
   auto vectorType = state.getCanonicalVecType(
-      getElementTypeOrSelf(outputOperand->get().getType()), opOperandMap);
+      getElementTypeOrSelf(outputOperand->get().getType()));

   Operation *write;
   if (vectorType.getRank() > 0) {

Running to a meeting. Could you please try this?
diff --git a/mlir/lib/Dialect/Linalg/Transforms/Vectorization.cpp b/mlir/lib/Dialect/Linalg/Transforms/Vectorization.cpp
index bbcde44f0861..2d24088ec885 100644
--- a/mlir/lib/Dialect/Linalg/Transforms/Vectorization.cpp
+++ b/mlir/lib/Dialect/Linalg/Transforms/Vectorization.cpp
@@ -606,7 +606,7 @@ static Value buildVectorWrite(RewriterBase &rewriter, Value value,
   auto linalgOp = cast<LinalgOp>(outputOperand->getOwner());
   AffineMap opOperandMap = linalgOp.getMatchingIndexingMap(outputOperand);
   auto vectorType = state.getCanonicalVecType(
-      getElementTypeOrSelf(outputOperand->get().getType()), opOperandMap);
+      getElementTypeOrSelf(outputOperand->get().getType()));

   Operation *write;
   if (vectorType.getRank() > 0) {

Definitely fixes the strange vector.transfer_write issue... the full model from which I found this segfaults though... Might be an unrelated issue, but the issue tracked in this bug seems to be fixed by this.

Definitely fixes the strange vector.transfer_write issue... the full model from which I found this segfaults though... Might be an unrelated issue, but the issue tracked in this bug seems to be fixed by this.

Ok, in that case, should I turn this over to @dcaballe to implement his fix?
Mahesh, is more analysis needed here or are you taking a look at the new segfault?

Definitely fixes the strange vector.transfer_write issue... the full model from which I found this segfaults though... Might be an unrelated issue, but the issue tracked in this bug seems to be fixed by this.

Ok, in that case, should I turn this over to @dcaballe to implement his fix?

@dcaballe with your patch, I get a segfault somewhere else, but it seems related to your patch
hal.executable.variant public @cuda_nvptx_fb, target = <"cuda", "cuda-nvptx-fb", {target_arch = "sm_80"}> {
  hal.executable.export public @predict_dispatch_2_generic_128x384_f32 ordinal(0) layout(#hal.pipeline.layout<push_constants = 2, sets = [<0, bindings = [<0, storage_buffer, ReadOnly>, <1, storage_buffer>]>]>) {
  ^bb0(%arg0: !hal.device):
    %x, %y, %z = flow.dispatch.workgroup_count_from_slice
    hal.return %x, %y, %z : index, index, index
  }
  builtin.module {
    func.func @predict_dispatch_2_generic_128x384_f32() {
      %cst = arith.constant 3.840000e+02 : f32
      %cst_0 = arith.constant -0.000000e+00 : f32
      %0 = hal.interface.constant.load[0] : i32
      %1 = hal.interface.constant.load[1] : i32
      %2 = arith.index_castui %0 {stream.alignment = 512 : index, stream.values = [0 : index, 512 : index]} : i32 to index
      %3 = arith.index_castui %1 {stream.alignment = 512 : index, stream.values = [196608 : index, 197120 : index]} : i32 to index
      %4 = hal.interface.binding.subspan set(0) binding(0) type(storage_buffer) alignment(64) offset(%2) flags(ReadOnly) : !flow.dispatch.tensor<readonly:tensor<128x384xf32>>
      %5 = hal.interface.binding.subspan set(0) binding(1) type(storage_buffer) alignment(64) offset(%3) : !flow.dispatch.tensor<writeonly:tensor<128xf32>>
      %6 = flow.dispatch.tensor.load %4, offsets = [0, 0], sizes = [128, 384], strides = [1, 1] : !flow.dispatch.tensor<readonly:tensor<128x384xf32>> -> tensor<128x384xf32>
      %7 = tensor.empty() : tensor<128xf32>
      %8 = linalg.fill ins(%cst_0 : f32) outs(%7 : tensor<128xf32>) -> tensor<128xf32>
      %9 = linalg.generic {indexing_maps = [affine_map<(d0, d1) -> (d0, d1)>, affine_map<(d0, d1) -> (d0)>], iterator_types = ["parallel", "reduction"]} ins(%6 : tensor<128x384xf32>) outs(%8 : tensor<128xf32>) {
      ^bb0(%in: f32, %out: f32):
        %11 = arith.addf %out, %in : f32
        linalg.yield %11 : f32
      } -> tensor<128xf32>
      %10 = linalg.generic {indexing_maps = [affine_map<(d0) -> (d0)>, affine_map<(d0) -> (d0)>], iterator_types = ["parallel"]} ins(%9 : tensor<128xf32>) outs(%7 : tensor<128xf32>) {
      ^bb0(%in: f32, %out: f32):
        %11 = arith.divf %in, %cst : f32
        linalg.yield %11 : f32
      } -> tensor<128xf32>
      flow.dispatch.tensor.store %10, %5, offsets = [0], sizes = [128], strides = [1] : tensor<128xf32> -> !flow.dispatch.tensor<writeonly:tensor<128xf32>>
      return
    }
  }
}

With
iree-opt --pass-pipeline="hal.executable(hal.executable.variant(iree-llvmgpu-lower-executable-target))" <repro.mlir>

I get this error
/tmp/e2e-test-artifacts/iree_MiniLML12H384Uncased_d4a10c6d3e8a11d808baf398822ea8b61be07673517ff9be30fbe199b7fdd960.mlir:451:15: error: 'vector.transfer_write' op requires a permutation_map with result dims of the same rank as the vector type
/tmp/e2e-test-artifacts/iree_MiniLML12H384Uncased_d4a10c6d3e8a11d808baf398822ea8b61be07673517ff9be30fbe199b7fdd960.mlir:201:3: note: called from
/tmp/e2e-test-artifacts/iree_MiniLML12H384Uncased_d4a10c6d3e8a11d808baf398822ea8b61be07673517ff9be30fbe199b7fdd960.mlir:451:15: note: see current operation: "vector.transfer_write"(%23, %arg3, %3) <{in_bounds = [true], operand_segment_sizes = array<i32: 1, 1, 1, 0>, permutation_map = affine_map<(d0) -> (d0)>}> : (vector<1x4xf32>, memref<1xf32, strided\
<[96], offset: ?>, #gpu.address_space<workgroup>>, index) -> ()
/tmp/e2e-test-artifacts/iree_MiniLML12H384Uncased_d4a10c6d3e8a11d808baf398822ea8b61be07673517ff9be30fbe199b7fdd960.mlir:454:12: error: failed to post-bufferization passes on module:

Could you give this a try? https://reviews.llvm.org/D153687

Could you give this a try? reviews.llvm.org/D153687

Trying with #13747

That fixes the issue. Thanks!

Fixed by https://reviews.llvm.org/D153687


MWCCARM (DS compiler) memset and memcpy optimisations not applying

This is something of a backend issue
When compiling locally, using the same context and exact same code memset and memcpy inlines and optimises, however on decomp.me, it always calls the functions
You can force it to optimise using __builtin_clear and __memcpy, however, this is somewhat inconveniet.
I have no idea what is triggering the inlining, and I have no idea if this can even be fixed to be honest, but I'm creating the issue just incase it can be

closing this, as I jumped the gun a bit, it's inconsistent even locally, so likely a compiler setting or a specific trigger hasn't been reached

looking more into it, this requires the definitions of memset and memcpy to be in string.h exactly, and with the way the site is setup that's sadly not going to be possible

That's hilarious. Does it work with #line 1 "string.h"?

haven't tried that, I can take a look at it


Line 197 changed to make it work with the latest numpy version

Latest numpy does not handle short hand notation. After making this change, the code works

Looking at the documentation for ndarray.__iadd__ it seems the casting behaviour for x += y is slightly different to x = x + y, which makes me suspect this is the same issue as #5. Can you try pulling in this fix to see if it makes your issue go away?


StdlibUnittest: repair in-process concurrency test execution

The support for running concurrency tests individually with filters
invoked the non-concurrent supporting runOneTest accidentally. Fix
this to us the runOneTestAsync allowing the single async test to be
run in process again.  This is needed for ease of debugging (and in the
case of Windows, the only option for debugging).

Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.

Resolves SR-NNNN.

CC: @etcwilde

@swift-ci please test

Build failed
Swift Test Linux Platform
Git Sha - 7da9f8c02de48f5259de55acceab4e7d8f99e544

@swift-ci please test Linux platform

Build failed
Swift Test Linux Platform
Git Sha - 7da9f8c02de48f5259de55acceab4e7d8f99e544

@swift-ci please smoke test Linux platform

@swift-ci please test Windows platform

@swift-ci please test Linux platform

@swift-ci please test Windows platform


Allow a camera with a RenderTarget::Image to set the mouse position.

Thanks for developing the bevy_mod_picking library!
I am developing a bevy application using post effect in the wasm environment, and I have found a problem where I cannot get the mouse position, which is the starting position of the ray, when the camera that is the picking source has RenderTarget::Image.
For now, this pull request simply allows the mouse position to be set in get_inputs, but should this modification only take effect in wasm builds?
I would be happy to have it merged if this is not a problem.

Thanks for the contribution, I need to think about this some more. FYI, most development efforts are probably best targeted toward the beta branch.

@aevyrie
Hi aevyrie!
I have been able to confirm that there are significant specification changes in the beta branch.
I would like to create a new branch from the beta branch, so I will close this PR for the time being.


[wip] linux: translate config to structured config

Follow up of https://github.com/NixOS/nixpkgs/pull/12158 @copumpkin . I am looking for comments before polishing as compiling kernels is not especially fast here.
I duplicated buildLinux into a buildLinuxExp in order to test while being able to nixos-rebuild.
buildLinuxExp uses a set to describe the kernel CONFIG_* instead of the current string.
The set is then converted into a string so backwards compatibility kinda applies (users can still specify their kernel extraConfig as a string) but it should be deprecated in favor of a set.
Motivation for this change

I want to be able to convert "modules" answer into "yes" and vice-versa
with the current kernel config system, the first defined is taken into account so

extraConfig = ''
OPENVSWITCH y
OPENVSWITCH m
'';

will end up with yes.
Eventually one can hope that enabling CONFIG_XYZ will enable all its
dependencies but that's for another day.
Things done

allows to override the config, aka convert 'yes' into 'modules'  or  vice-versa
One other change I uploaded here (but shouldn't have as it's kind of a separate issue) relates to https://github.com/NixOS/nixpkgs/issues/41103, I would like packages/modules to be able to specify some kernel config.

I build this expression
  linux_test = prev.linux_4_16.override {
    ignoreConfigErrors=true;
    autoModules = false;
    kernelPreferBuiltin = true;

    buildLinux = prev.buildLinuxExp;
  };

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Fits CONTRIBUTING.md.

Success on x86_64-linux (full log)
Attempted: linux
Partial log (click to expand)
/nix/store/si1gisyb8ly0vnrhgdx5qxdzngyvsi5v-linux-4.14.47

Success on aarch64-linux (full log)
Attempted: linux
Partial log (click to expand)
these paths will be fetched (48.28 MiB download, 78.80 MiB unpacked):
  /nix/store/swwnj5b8jfz1bi6fvvfvlcgqwwsbkzni-linux-4.14.47
copying path '/nix/store/swwnj5b8jfz1bi6fvvfvlcgqwwsbkzni-linux-4.14.47' from 'https://cache.nixos.org'...
warning: SQLite database '/nix/var/nix/db/db.sqlite' is busy
/nix/store/swwnj5b8jfz1bi6fvvfvlcgqwwsbkzni-linux-4.14.47

Success on x86_64-linux (full log)
Attempted: linux
Partial log (click to expand)
/nix/store/nn55hl7zxl8cx9xl0bv7ra8jz2bqjczr-linux-4.14.49

Success on aarch64-linux (full log)
Attempted: linux
Partial log (click to expand)
these paths will be fetched (48.27 MiB download, 78.79 MiB unpacked):
  /nix/store/6wpbdldldwn76lxq1m3vjrgp9a15aqxz-linux-4.14.49
copying path '/nix/store/6wpbdldldwn76lxq1m3vjrgp9a15aqxz-linux-4.14.49' from 'https://cache.nixos.org'...
/nix/store/6wpbdldldwn76lxq1m3vjrgp9a15aqxz-linux-4.14.49

I updated the default config so that it reflects exaclty (notwithstanding my mistakes) the current common-config.nix.
When I try to run nox-review wip --against=upstream/master I get this kind of error http://nixpaste.lbr.uno/-fsL_q4k?nix   so I accept any tip on how to tackle this kind of "infinite recursion" problem

Success on x86_64-linux (full log)
Attempted: linux
Partial log (click to expand)
wrong ELF type
wrong ELF type
wrong ELF type
wrong ELF type
wrong ELF type
wrong ELF type
wrong ELF type
wrong ELF type
wrong ELF type
/nix/store/cv3cfq0axhlcqg0khw1lrxddxsg03nyb-linux-4.14.50

Success on aarch64-linux (full log)
Attempted: linux
Partial log (click to expand)
wrong ELF type
wrong ELF type
wrong ELF type
wrong ELF type
wrong ELF type
wrong ELF type
wrong ELF type
wrong ELF type
cannot find section .dynamic
/nix/store/bja0q8gf2bxv798kxmqhjw3sqzlhxadv-linux-4.14.50

Success on x86_64-linux (full log)
Attempted: linux
Partial log (click to expand)
/nix/store/cv3cfq0axhlcqg0khw1lrxddxsg03nyb-linux-4.14.50

I've updated common-config to reflect all the changes since copumpkin PRs and i could compile 4.17. It should be ready for review (apart from the messy history)

Success on aarch64-linux (full log)
Attempted: linux
Partial log (click to expand)
wrong ELF type
wrong ELF type
wrong ELF type
wrong ELF type
wrong ELF type
wrong ELF type
wrong ELF type
wrong ELF type
cannot find section .dynamic
/nix/store/bja0q8gf2bxv798kxmqhjw3sqzlhxadv-linux-4.14.50

Success on aarch64-linux (full log)
Attempted: linux
Partial log (click to expand)
wrong ELF type
wrong ELF type
wrong ELF type
wrong ELF type
wrong ELF type
wrong ELF type
wrong ELF type
wrong ELF type
cannot find section .dynamic
/nix/store/bja0q8gf2bxv798kxmqhjw3sqzlhxadv-linux-4.14.50

Failure on x86_64-linux (full log)
Attempted: linux
Partial log (click to expand)
  CC [M]  drivers/staging/speakup/fakekey.o
  CC [M]  drivers/staging/speakup/main.o
  CC [M]  drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.o
  CC [M]  drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_api_88xx_usb.o
  CC [M]  drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_api_88xx_sdio.o
  CC [M]  drivers/staging/rtl8723bs/os_dep/ioctl_linux.o
  CC [M]  drivers/staging/speakup/keyhelp.o
  CC [M]  drivers/staging/speakup/kobjects.o
building of '/nix/store/24plzvpzg33v84pmfd7miq69imcyd8ff-linux-4.14.50.drv' timed out after 1800 seconds
error: build of '/nix/store/24plzvpzg33v84pmfd7miq69imcyd8ff-linux-4.14.50.drv' failed

What happens to dependencies? If I set module A to "n" but module B to "y" despite B depending on A, > the kernel config will error out, correct?
Is there something simple we can do to detect this? (I can't see a simple way)
This is the current behavior and the PR doesn't change that.
I discovered yesterday https://github.com/ulfalizer/Kconfiglib which might help in that regard at a later date, I am not sure. The kernel has also a script to merge different configs https://github.com/torvalds/linux/blob/master/scripts/kconfig/merge_config.sh, I wonder if this could be used to fix some of our dependencies problem. But I would rather leave this exploration to future PRs.

I noticed some minor differences in the configs, feel free to squash the fixes from https://github.com/NixOS/nixpkgs/compare/master...dezgeg:structured-kernel-conf-fixes?expand=1

wow thanks that's super nice, you caught quite a few ones. I squashed and rebased. I added a commit to remove references to any kernel < 4.4 so that it can be reverted later.
I was able to compile the config for 4.4 and 4.16.

Failure on x86_64-linux (full log)
Attempted: linux
Partial log (click to expand)
  CC [M]  drivers/staging/rtl8192e/rtl8192e/rtl_pm.o
  CC [M]  drivers/video/fbdev/sstfb.o
  CC [M]  drivers/staging/rtl8712/usb_halinit.o
  CC [M]  drivers/staging/rtl8192u/r8190_rtl8256.o
  CC [M]  drivers/staging/rtl8192e/rtl8192e/rtl_ps.o
  CC [M]  drivers/video/fbdev/cirrusfb.o
  CC [M]  drivers/staging/rtl8712/usb_ops.o
  CC [M]  drivers/staging/rtl8192u/r819xU_phy.o
building of '/nix/store/kvi48kp4zzpbaqyvv313kpjygxwc2sra-linux-4.14.51.drv' timed out after 1800 seconds
error: build of '/nix/store/kvi48kp4zzpbaqyvv313kpjygxwc2sra-linux-4.14.51.drv' failed

Success on aarch64-linux (full log)
Attempted: linux
Partial log (click to expand)
wrong ELF type
wrong ELF type
wrong ELF type
wrong ELF type
wrong ELF type
wrong ELF type
wrong ELF type
wrong ELF type
cannot find section .dynamic
/nix/store/qp98m3d4xa1f7x8xbnvwa7wczfbllav7-linux-4.14.51

Failure on x86_64-linux (full log)
Attempted: linux
Partial log (click to expand)
  CC [M]  drivers/usb/storage/isd200.o
  CC [M]  drivers/usb/storage/jumpshot.o
  CC [M]  drivers/usb/storage/karma.o
  CC [M]  drivers/usb/storage/onetouch.o
  CC [M]  drivers/usb/storage/realtek_cr.o
  CC [M]  drivers/usb/storage/sddr09.o
  CC [M]  drivers/usb/storage/sddr55.o
  CC [M]  drivers/usb/storage/shuttle_usbat.o
building of '/nix/store/qq0jx495ka6g8s75h3zn3nhby0gc3nbv-linux-4.14.51.drv' timed out after 1800 seconds
error: build of '/nix/store/qq0jx495ka6g8s75h3zn3nhby0gc3nbv-linux-4.14.51.drv' failed

I verified with scripts that after a minor fix I squashed in there's no change to the effective configs on x86_64, i686, aarch64 and armv7l. So merged.


openzfs-merge.sh: add -p flag - push branch to github

Small change allows to push branch with merged patch to github with less work.

@dinatale2 you're right, but I added this flag to easily push commits which can't be automatically merged (for ex. i made it to use with -g flag). I added comment that the new flag forces it.


Allow PyPI to render the markdown readme

See https://stackoverflow.com/questions/26737222/pypi-description-markdown-doesnt-work

Dude. Can you read my mind? I was doing research on this last night and was going to fix it today.. Thanks so much undu C:f


Make sure AMP is CCPA-ready by January 1st, 2020

This issue was raised by @darobin in https://github.com/ampproject/amphtml/issues/24910. It was subsequently brought to the attention of the AC during its F2F meeting in New York in October 2019.
The issue was immediately brought to the TSC and was assigned to the relevant WGs right away.

It would be great to do a post-mortem of this issue.


When a user starts a feature import task stop other feature imports from happening until that processing is done.

Also make sure that a stale feature import has its status changed to error to prevent a stalled upload forever blocking a new upload.

For LD imports, this is solved with a unique constraint on import request status: https://github.com/Flagsmith/flagsmith/blob/de5cf9db8a97414241e84b5b51853bb77f9e878c/api/integrations/launch_darkly/models.py#L59-L63

Closed by this PR


GPA is not library friendly

GPA usage of CMake is very awkward making it difficult to simply include GPA into an existing large project by setting variables and then calling add_subdirectory. Currently doing so causes the build process to produce binary paths that can't be found.

Yes, this isn't a usage model that we considered.  We'll take a look to see what can be done to make this experience better.

I've just pushed a few changes to the CMake files. WIth these changes, we've been able to include GPA in another project by simply using add_subdirectory. There is still a prerequisite that you'll need to run UpdateCommon.py before doing this.  Can you give the latest sources a try and see if it works better for you? If you still run into problems, we may need more info on exactly how you are using this, and what exact problems you still see.
Thanks!


android version is not work in background

1、why the app signals short tt beep representing recording coordinates and then long tt beep as to sending them to the server only when I open it the first time?
2、I can only hear the long beep when I run it in background ,it shows that it sends no data to server at all.I wonder if sending data when moving ?
backgroundGeolocation.configure(callbackFn, failureFn, {
desiredAccuracy: 10,
stationaryRadius: 20,
distanceFilter: 20,
stopOnTerminate: false, // <-- enable this to clear background location settings when the app terminates
desiredAccuracy: 10,
notificationIconColor: '#4CAF50',
notificationTitle: 'Background tracking',
notificationText: 'ENABLED',
notificationIconLarge: 'icon_large', //filename without extension
notificationIconSmall: 'icon_small', //filename without extension
debug: true, // <-- enable this hear sounds for background-geolocation life-cycle.
locationProvider: backgroundGeolocation.provider.ANDROID_DISTANCE_FILTER_PROVIDER,
interval: 30000, // <!-- poll for position every minute
fastestInterval: 30000,
url: 'http://<IP_ADDRESS>:3000/path',
httpHeaders: {
"X-FOO": "bar"
}
});

Seems as duplicate of #88

After exit stationary region, the plugin is not work?

no it should work fine
only when using the ANDROID_ACTIVITY_PROVIDER

Notice: this issue has been closed because it has been reported for branch 2.x or later. It could be already fixed in v3 or is not relevant anymore. You may reopen this issue if it has been closed in error.


WIP: Fix inability to run old coop replays

Closes #2747
more info in https://github.com/FAForever/downlords-faf-client/issues/2747#issuecomment-1200133251

I need to test that old or current replays with featured mods don't break

But no. They are broken.

Superceded by https://github.com/FAForever/downlords-faf-client/pull/2760


[TypeError: Cannot read property 'Kerberos' of undefined] on server start

[TypeError: Cannot read property 'Kerberos' of undefined]

i have no idea what's generating this error. it doesn't seem to impact the API.

I'm not sure what this library is but I too just started getting this exact same error, and google landed me here. I'm using Koa app, and going through your package.jsons I think mongoose seems to be common in both our apps.

Getting this error using a very simple node app, also using mongoose

@davegri I've also just noticed this in my console, I've just started a new project and literally have nothing but a basic web server. TypeError: Cannot read property 'Kerberos' of undefined

@davegri @laggingreflex @peterbsmith2 I've just disabled Mongoose in my project and i'm no longer seeing the message, as you suggested mongoose seems to be the culprit.

@Colure, yeah it's definitely mongoose, it's related to the mongodb drivers, seems harmless

This is where the error is coming from:
…\mongodb-core\lib\auth\sspi.js:
   25: // Try to grab the Kerberos class
   26  try {
   27:   Kerberos = require_optional('kerberos').Kerberos
   28    // Authentication process for Mongo
   29:   MongoAuthProcess = require_optional('kerberos').processes.MongoAuthProcess
   30  } catch(err) {
   31    console.dir(err)

@davegri @laggingreflex Perhaps it's not as harmless as you think, I myself have very little knowledge on the subject of Kerbos.

Kerberos is a secure method for authenticating a request for a service in a computer network. Kerberos was developed in the Athena Project at the Massachusetts Institute of Technology (MIT).

Just based on the fact it's regarding authentication, I would suggest rolling back a version on production applications, just incase.

The error doesn't exist with mongoose ~4.3.0 So I guess it is some problem with the last release (from yesterday).

I changed my mongoose version from 4.4.2 to 4.4.1 and that removed the error.
Apparently mongoose 4.4.1 depends on mongodb 2.1.4 which depends on kerberos 0.0.18.
mongoose 4.4.2 depends on mongodb 2.1.5 which removes kerberos as a dependency.
So likely mongoose was expecting Kerberos to be there when it no longer is.

This issue is documented at Automattic/mongoose/issues/#3860

fixed in Automattic/mongoose#3861

I just restarted my system and the error went away :)


Concatenating multiple files with sourcemaps

When joining two files that were previously minified with sourcemaps everything almost works perfectly but the trailing sourcemap declarations from the sources, for instance //# sourceMappingURL=maps/script.js.map ends up becoming just // on its own line which throws off the sourcemapping for any files after the first concatenated file.
If I remove the blank comment lines from the output everything seems to click. Is there a reason for not removing the entire sourcemap comment?
Here is the input for instance.
JavaScript 1
//# sourceMappingURL=maps/one.js.map

JavaScript 2
//# sourceMappingURL=maps/two.js.map

Here is what concat is doing.
JavaScript 1
//
JavaScript 2
//
//# sourceMappingURL=maps/script.js.map

Here is what works.
JavaScript 1
JavaScript 2
//# sourceMappingURL=maps/script.js.map

+1  I just ran across the same issue.  I was concatenating multiple CSS files that were already minified and it successfully removed the source map reference but left the "/* */" which threw off the rest of the source maps.
I thought stripBanners would take care of this, but it doesn't.  This bug has always existed as far as I can tell.  I tried with 1.0 and 0.5.1 and 0.5.0.

@leigeber I think I'm having a similar concat problem, breakpoints don't work on the last js file I concat (or maybe more), I tried the proposed fix and didn't have much luck with that as well. I'm still investigating.


Is SQLite supported ?

Hello,
I am trying to setup your appender with a SQLite database.
I have a simple console project created with .NET Core 3.1 with a reference to the Microsoft.EntityFrameworkCore.Sqlite 3.1.8 nuget package.
The configuration file most important rows are as follow:
<appender name="AdoNetAppender" type="MicroKnights.Logging.AdoNetAppender, MicroKnights.Log4NetAdoNetAppender">
    <bufferSize value="100" />
    <connectionType value="Microsoft.Data.Sqlite.SqliteConnection, Microsoft.EntityFrameworkCore.Sqlite, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=adb9793829ddae60" />
    <connectionString value="sqlite" />
    <connectionStringFile value="connectionstrings.json" />
...

and the connectionstrings.json contents:
{
  "connectionstrings": {
    "sqlite": "Data Source=log4net.db;Version=3;",
  }
}

I already have a log4net.db database file with the correct table in it but I am not sure where to place it exactly in the folder structure (I placed it in the same location as log4net.config), also looking at the documentation you provided I see I need a ConnectionStringFile property and the actual json file. Looking at your tests examples I did not see a SQLite example so I just improvised and also I have the same question: where should it be located ? In the same location as the log4net.config ? or in the bin/Debug/bla/bla folder ? (in my tests it is placed in the same location as log4net.config)
Also all files are marked as Always Copy
PS Funny thing is I am not getting any errors or at least I didn't see any... but the table in db file does not get updated
Any help would be appreciated,
Thank you in advance

SQLite is listed as supported from the original library, but i have never tested it.
Can you post your full configuration, and i will do some testing the next could of days :)

I did even better, created the project on github, maybe it will help others:
https://github.com/WarBorg/DotNetCoreLog4NetApplication/tree/main/DotNetCoreLog4NetApplication.Console

So is it working now or?

@microknights nope, same having the problem that the DB is not updated but don't really know how to debug it because I see no errors

ok, i will take a look at your project and post if i find anything.

thank you, maybe you can make a PR on that repo if you manage it to make it work

A PR is ready, only a few fixes in the configuration :)

hello,
thank you, saw the PR, merged it, but still not working :( database is still empty (PS I am using a Mac for development with VS for Mac 2019) don't know if that is of any relevance

also check the DB with "DB Browser for SQLite" just to be sure, was still empty

I have made a PR and an Issue on you repo, lets continue on that issue...
https://github.com/WarBorg/DotNetCoreLog4NetApplication/issues/3

will do, should I close this issue ?

no, if will close it with a final statement on this issue

So, only configuration issues.
And there is a *nix platform error from Log4Net v2.0.10+ (up to currenty v2.0.11). So if you use log4net v2.0.9 to avoid this.


Network issues with the Baxter Research Robot

Hello, since three days ago we are experiencing some difficult-to-reproduce, difficult-to-track network issues with our Baxter.
What happens in practice is that after a while some topics stop being published, and the robot is not responding to even the simplest command (e.g. tuck). Also, rebooting both the Baxter and the machine connected to it does not change much: after 5 minutes the issue reappears.
After hours in trying to understand the reason for this, we discovered that the issue might be related to the rosmaster that is not closing sockets properly, leaving them in CLOSE_WAIT state. Also, when this happens rosmaster starts to use more than 100% of one core on the baxter machine, which seems strange.
The issue seems to be well-known to the ROS community, but although I have seen many issues on that, I don't really understand how to fix the problem.
Some useful links:

https://github.com/ros/ros_comm/issues/495
https://github.com/ros/ros_comm/issues/610
https://github.com/ros/ros_comm/pull/834

Please tell me if I can help you debug it in any way.
@rethink-imcmahon sorry for tagging directly you, but I saw your comment in one of the issues I linked above, and I thought you may have a quick solution to debug the issue.

No worries on tagging me. I have not dug into any of the issues you've called out here, but I have helped many, many Baxter customers properly network their computers to their robots. I would first make sure the networking layer is rock solid - make sure to follow our Networking tutorial, with key points being:

Disable Wireless networking on your Ubuntu workstation
Disable the Ubuntu Firewall: $ sudo ufw disable
Note whether you have two network cards on your Workstation, and how that may affect the ROS traffic
(you'll likely want to make sure everything is working in the simplest configuration first, before adding network complexity)
The best configuration by far is having a router you control connect to the Internet, and put your computer & robot behind that router. This is much easier to debug, with fewer unknowns than most networking configurations:

Thank you @IanTheEngineer for being so quick in your reply. So what we basically had before was a direct connection between the development workstation and the Baxter robot through the second network card the workstation is equipped with.
We proceeded to unplug the Baxter from the workstation and plug it to the router, changed the baxter.sh params and rebooted both the Baxter and the workstation.
It seems that the issue has disappeared, at least from our quick testing. The problem we have now is that the input data network speed is capped at 11MB/s, which renders most of our code unusable. When we were connecting directly to the robot, we had a speed always higher than 50MB/s. Whilst I am aware that a better/faster/newer router would increase the network speed in such a configuration, this does not explain (at least to me) the reason for the problem, and why it appeared only now. What do you think the issue originates from?  From here, it seems that rebooting the machines helps anyway because you cleanup the number of sockets in CLOSE_WAIT state.
Anyway, we will try to keep debugging the issue in both configurations (with or without the router in between the two machines), and we'll let you know. It takes time to reproduce the issue and I am still not sure if the "router fix" helped or not.

Further investigation: we went back to the "direct connection" configuration.
Again, rosmaster usage comes back up to more than 100%, and the issue shows up again even though the number of sockets in CLOSE_WAIT state seems low (about 10). We experience a big number of sockets in TIME_WAIT state, though.
After closing our launch files, what happens is that rosmaster usage stays high for ~5 minutes, until all these sockets exit from their TIME_WAIT state. When this happens, rosmaster usage goes back down to 0.3%, and we regain control over the network and the Baxter.

The number of sockets in TIME_WAIT state keeps increasing over the time after launching our launch file. After 30 seconds usage, it fluctuates around 3000 and it stays there. Closing the launch files starts reducing those sockets until they go back to 0 after ~5 minutes.

It is entirely possible that this CLOSE_WAIT issue is affecting Baxter's roscore. This is really useful debugging info you're collecting here, and I'd recommend adding it to the ticket you've linked so that the ros_comm maintainers have more context for the bug. In the mean time, I'd recommend getting a solid router for around $50 to mitigate the issue.

We'll do that. In the meanwhile, I am not so sure if it's worth upgrading the whole system to kinetic. It seems that ROS support for older versions is not that great, and an upgrade might help.
I am following the issue here: when do you think the QA team will be able to test the Baxter with kinetic? Is there an ETA for that? I would like to stick with the official channels for the baxter robot.

@IanTheEngineer do you have any suggestion about the best router we could by to satisfy our bandwidth hunger? I can obviously look for a router by myself, but maybe Rethink has a list of suggested/recommended hardware in this regard.

@IanTheEngineer we finally bought a new router for our setup.
After quick testing, now the max read/write speeds allowed by our system hover around 100MB/s, that much bigger than our needs and importantly much better than the 11MB/s allowed by our previous router (now the bottleneck is probably the hard drive).
Above all, the problem seems to be gone now, so I am going to close the issue. We will keep testing the new setup in the following weeks, and we'll re-open this issue if needed.
For future reference, here is a link for purchasing the exact model we bought: https://www.amazon.com/dp/B00QGOQ2BA/ref=psdc_300189_t1_B00HEX851C?th=1
Thank you for the support!
Cc @omangin

@IanTheEngineer reopening because what we believe are network issues are still present. We updated the router, I fixed a bug in ros_comm that was causing some issues  (see here), and now I don't have any ROS error I could try to use in order to understand what is going on.
The behavior we have right now is that everything is fine, until at some point one of the following happens:

is not possible to tuck the robot any more
I cannot see images coming from either of the two hands camera
One of the two cameras shuts down, and I am not able to turn it back on again with the provided rosrun baxter_tools camera_control.py -o

The only way I have to fix them is to reboot the robot altogether. FYI:
[baxter - http://baxter.local:11311] scazlab@baxterserver:~/ros_devel_ws$ rosparam get /rethink/software_version
<IP_ADDRESS>

[baxter - http://baxter.local:11311] scazlab@baxterserver:~/ros_baxter_ws/src/baxter (master)$ git describe
v1.2.0

Also, I just reinstalled the baxter workstation from scratch with indigo, and my network setup is the recommended, ie this one:


When will quickwit 0.9 be released?

We are planning to replace es with quickwit and are looking forward to version 0.9！！！

I have been paying attention to Quickwit for more than a year. I have been using ES as a tool for log retrieval and analysis. I found that Quickwit has great advantages in cost and performance, so I want to apply it on a large scale.
I haven't joined discord yet, can you share an invitation code?
Do you have a WeCha Quickwit group for ?

https://discord.gg/E5Hn54jNGP

Get！Thanks！！


deployer: create separate new typer apps under the deployer and update the general structure of the directory

For https://github.com/2i2c-org/infrastructure/issues/2024
What the PR does
This PR refactors the deployer's directory structure and creates new  typer applications under the main deployer app.
The commands that we have, then register under these new applications based on their location in the package.
NOTE: the only new code that this PR adds is related to the creation of these typer apps. Other then this, this mostly is about moving files around, renaming them and extracting functions into their own files. More in the  commits' description.
Benefits
We are now left with a more clear to follow structure of the main deployer directory instead of having an endless number of python files in a big pool.
More, this directory structure maps to the deployer commands, so that it's easier to know where the code that describes a command is.
A note to review more easily
I was very grateful each time @consideRatio split his work into individual logical commits and described what each commit did. That greatly improved my understanding of what the PR did and presented the changes gradually, hence the review was easier <3.
Although I didn't start with this thought in mind because this PR was supposed to be something else and smaller, I did my best to squash the relevant ones together and provide a description for each of them.
So, to review more easily, I suggest going to https://github.com/2i2c-org/infrastructure/pull/3094/commits and look at each commit and its description at a time. Thank you!!!

I love that tests is being renamed to involve health_checks, i consider that to fix https://github.com/2i2c-org/infrastructure/issues/971!

This was part of @yuvipanda's feedback <3 🚀

Thanks @GeorgianaElena! Generally looks good to me, made some minor suggestions.

I've udpated based on your feedback, Yuvi and rebased & fix the conflicts.

@GeorgianaElena maybe you could do a deploy-support and deploy a staging hub before merging though as a precaution, with a health check on the staging before we trigger the full deploy?

Just ran them locally with no issue + a validate command.

I think we should review this further by testing it rather than by further code review. I don't expect this to break things in a way that we don't catch.

Thank you @consideRatio! Merging this now 🚀


Changes to blue boxes on top of sensor view

Add info icon for all the blue boxes:

Info icon opens a popup.
@laurijamsa will provide the text content for popups.
Position 8-10px from the right corner.
Icon size 16px.
Icon svg file in Telegram.

Add subtitles for boxes

"Main Sensors" and "Others"
Add Hide link next to "Others"
Remember later if user has hidden the boxes.

Change sensor name font under the measurement (on blue boxes) to Mulish SemiBold Italic

Move °C, % and other marks higher.

Add min-width for boxes to 200px.

Move all the "Others" (in the picture) here from "More info" on the bottom

Remove the same content from "More info" section

Change Graph title

to "History" and
add "Selected:" text before selected sensor name

The info popups could be toast messages instead of popups. It would also simplify user experience because then manual popup closing would not be needed. Let's try with toasts and we'll see how it goes.

Max width of the boxes should be defined like on the design:

Main Sensors and Other Sensors translations are missing, and the "Other Sensors" could be "Additional Data" (Finnish: Pääanturit and Lisätiedot):

This hoovering helper looks good to me but the same should happen also on the "Zoom (i)" then:

This issue will get some new instructions in near future so let's pause working with it until then.

Todo:
Make 2 sensor reading boxes per row fit on mobile

Also noticed this:

Reduce the line height on "movement counter"

Here are finally preliminary strings for the units:
Temperature

   Tip: You can change the unit in settings. Available units are: Celsius (°C), Fahrenheit (°F) and Kelvin (K).

Humidity

   Tip: You can change the unit in settings. Available units are: Relative (%), absolute (g/m^3) and dew point (°).

Pressure

   Tip: You can change the unit in settings. Available units are: Pascal (Pa), hectopascal (hPa), millimetre of mercury (mmHg) and inch of mercury (inHg).

Movement Counter

   Every time Ruuvi sensor is moved, its internal movement counter is increased.

   Tip: Maximum value of the counter is 255 and when reached, it starts again from zero. When the sensor is rebooted, the counter is also automatically reset to zero.

Battery Voltage

   We recommend replacing the battery when voltage is lower than 2,4 volts in room temperature.

   Tip: When the temperature of the battery goes down, voltage readings also decrease. But this necessarily doesn't mean that the battery would be empty.

Acceleration X Y Z

   Ruuvi sensor's three-dimensional digital accelerometer continuously measures proper acceleration in g (g ≈ 9,81 m/s^2).

   Tip: Acceleration values can tell you orientation of a stationary sensor.

Signal Strength (RSSI)

   Received signal strength is measured by receiver device in decibel milliwatts (dBm). Bigger the number, stronger the received signal.

   Tip: Every 3 dB step doubles the received radio energy. Meaning, for example, -37 dBm is two times stronger than -40 dBm.

Measurement Sequence Number

   When Ruuvi sensor is refreshing its measurements (every ~2,5 seconds), the measurement sequence number is increased. Maximum value of the counter is 16 bits (65536) and when reached, it starts again from zero.

   Tip: When the sensor is rebooting, the counter is automatically reset to zero. By examinating history cycles of the measurement counter, you can see if the sensor has rebooted unintentionally.

Better wording:
You can change the units in
(°F) and Kelvin (K)
(°F) and Kelvin (°K)
volts at room temperature.
voltage readings also decreases. (( omit readings))
battery is nearly depleted.         or nearly exhausted.
measures proper acceleration.        (((( omit proper))))
three-dimensional digital
3-axis (((omit digital)))
measured by receiving  device
larger the number
counter is 65,535 and when reached.  ((((omit bits,  max value is actually 65,535)))
When the sensor is rebooting, the counter is automatically reset to zero
When the sensor resets the counter is set to zero.
rebooted unintentionally.
reset unexpectedly

Will leave this card for Lauri so many things were listed.


Prevent decreasing font size beyond the minimal value

Linux, X11.
Extracted from https://github.com/jwilm/alacritty/pull/949#issuecomment-353494090

I played with holding Ctrl +/- and found a silly issue, posting just in case you can immediately think of a simple fix, otherwise I guess it's not worth looking into:

Hold Ctrl +. The value reaches its maximum value (274 in my case) and stays there, pressing Ctrl + further has no effect. Pressing Ctrl - once reduces font size to 272.
Now hold Ctrl -. The value reaches its minimum value (2 in my case), but further presses of Ctrl - change the value to 2, again and again. If I press Ctrl - 10 times after I already reached the minimal value of 2, then pressing Ctrl + once will have no effect - the font size will stay at 2. I have to press Ctrl + 10 times to compensate for my earlier actions, before further presses of Ctrl + begin to actually increase the font.

I can confirm this too.

I don't believe that #949 fixed this issue:

The issue is with this call to Atlas#insert. If the font size is increased until it is too big to fit into a single atlas, Atlas#insert will always return an Err. This leads to load_glyph recursing infinitely, since inserting the glyph into an Atlas will never succeed.

Thanks @Aaron1011. I reopened the other issue.

@Aaron1011 It does actually fix the issue tho. The issue was never that the glyph was too big for a single atlas. Have you tested it out yourself? With #949 the crash doesn't happen anymore when increasing font size. The problem was that the atlas never changed, so there was never a new atlas that was created.
In theory you could run into problems with glyphs being too big for a single atlas, but I don't think that's even possible to happen because of gpu restrictions. I've played around with it a bit myself and the max font size goes up to a limit and then just stops. The worst thing I was able to reconstruct was that a few glyphs didn't show up anymore because my gpu driver was spouting errors about textures being too big. I don't think fitting a single glyph into an empty atlas has ever been the actual issue. Or can you still reproduce the issue after #949.
I did initially play with changing the recursion strategy, but it turned out for me that after I fixed the obvious problem, all the other issues were resolved too.


features of Version 3

Does version 3 have the features like Reference Line, Multi layout, ... ?

Yes. Not all examples that existed for v3 have been completed for v3. I'll stub out pages for the incomplete ones today so their is less confusion.
Please feel free to contribute/PR a quick example if you find something you'd like to see missing.

@unosbaghaie, the examples have been added as "stubbed out" pages. It should be clearer what you can accomplish in v3, but a demonstration of how to do it may not yet be complete.
For the most part, tools/synchronization function very similarly to how they did in v2. If you're having trouble with a specific tool, please feel free to create a new issue with any questions you have and what you've tried so far.
https://tools.cornerstonejs.org/examples/


go work sync

What is the purpose of the change
This PR is me running go work sync, and when I did that a number of go.mod
and go.sum files were changed.  The repository passes tests, so I have
assumed that this is "a good thing"TM. Please close this if not desired.
Brief Changelog
go work sync
Testing and Verifying
This is a highly trivial change unworthy of a change to the changelog.
Documentation and Release Note

Does this pull request introduce a new feature or user-facing behavior
changes? no
Is a relevant changelog entry added to the Unreleased section in
CHANGELOG.md? yes
How is the feature or change documented? not applicable

changelog reminder ftw

(force pushed to remove two unnecessary commits that should have gone on another branch)

@faddat merged main here and removed changelog entry while doing so because the change is not client facing. Hope you don't mind
Will merge this in as soon as CI passs. Thank you

Actually, it looks like this change has already gotten in with your other PR: https://github.com/osmosis-labs/osmosis/pull/5065
Making this obsolete after merging main. As a result, going to close this. Please let me know if something isn't right here


[tosa] Legalize tf.sin and tf.cos to tosa.table

Moves the existing TFL legalization implementation to a common area so that the same legalization can be used for TF.
Signed-off-by: Luke Hutton<EMAIL_ADDRESS>

Hi @lhutton1 Can you please sign CLA. Thank you!

cc @rsuderman @jpienaar @eric-k256


Add unsplash implementation to list of third party providers

Changes Unknown when pulling 34daf158c5bbfc9a45b7c585297320848380f270 on HughbertD:master into ** on thephpleague:master**.

Changes Unknown when pulling 34daf158c5bbfc9a45b7c585297320848380f270 on HughbertD:master into ** on thephpleague:master**.

Changes Unknown when pulling 34daf158c5bbfc9a45b7c585297320848380f270 on HughbertD:master into ** on thephpleague:master**.


Disable TLS 1.1 and TLS 1.2

We want to disable TLS 1.1 and TLS 1.2 for security reasons
Links:

https://stackoverflow.com/questions/38302683/how-can-i-disable-tlsv1-0-with-spring-boot-and-embedded-tomcat
https://www.baeldung.com/spring-tls-setup

Howto check?
Check TLS version per command line:
No longer wanted
openssl s_client -connect localhost:8443 -tls1
openssl s_client -connect localhost:8443 -tls1_1
Still wanted
openssl s_client -connect localhost:8443 -tls1_2
openssl s_client -connect localhost:8443 -tls1_3


The documentation link is broken

The documentation link is broken right now. (not sure if the problem is with the link or the Boost website...)

Once Boost 1.73.0 is out of beta the links will start working. For the time being you can use the docs for the beta release (they are identical)

@eyalroz Should be working now :)


TransitionToPartner - agile project mgt -> product management

In TransitionToPartner, change
Shift to Agile Project Management
Back to
Shift to Product Management
And specific agile project management under the Bi-Modal governance strategy.
"Product Management" has expectations understood by senior level and is a better expression to use to communicate.

I put @remyb2canada on this one because I'm still unclear on this product management notion and how it will work into the PM stream. So I'm unable to confidently make any actionable items to associate with it


(dynamodb): Rule suppression for DYNAMODB_PITR_ENABLED not working

What is the problem?
The suppression rule for DYNAMODB_PITR_ENABLED is not working as expected.
Reproduction Steps
template.yaml
Resources:
  Table:
    DeletionPolicy: Delete
    UpdateReplacePolicy: Delete
    Type: AWS::DynamoDB::Table
    Metadata:
      guard:
        SuppressedRules:
          - DYNAMODB_PITR_ENABLED
    Properties:
      AttributeDefinitions:
        - { AttributeName: "partition_key", AttributeType: "S" }
      KeySchema:
        - { AttributeName: "partition_key", KeyType: "HASH" }

Rule Set:
Currently using wa-Reliability-Pillar.guard from Release v1.0.2
Command:
 cfn-guard validate -r ~/Downloads/output/wa-Reliability-Pillar.guard -d template.yaml

Result:
cfn-guard validate -r ~/Downloads/output/wa-Reliability-Pillar.guard -d template.yaml
template.yaml Status = FAIL
FAILED rules
wa-Reliability-Pillar.guard/DYNAMODB_PITR_ENABLED                          FAIL
---
Evaluating data template.yaml against rules wa-Reliability-Pillar.guard
Number of non-compliant resources 1
Resource = Table {
  Type      = AWS::DynamoDB::Table
  Rule = DYNAMODB_PITR_ENABLED {
    ALL {
      Check =  %aws_dynamodb_table_resources[*].Properties.PointInTimeRecoverySpecification.PointInTimeRecoveryEnabled EQUALS  true {
        Message {
          Guard Rule Set: wa-Reliability-Pillar
          Controls: REL-9
          Violation: All DynamoDB Tables must have Point-In-Time-Recovery enabled.
          Fix: Set the dynamodb table property PointInTimeRecoverySpecification.PointInTimeRecoveryEnabled to true.
        }
        RequiredPropertyError {
          PropertyPath = /Resources/Table/Properties[L:10,C:6]
          MissingProperty = PointInTimeRecoverySpecification.PointInTimeRecoveryEnabled
          Reason = Could not find key PointInTimeRecoverySpecification inside struct at path /Resources/Table/Properties[L:10,C:6]
          Code:
                8.        SuppressedRules:
                9.          - DYNAMODB_PITR_ENABLED
               10.    Properties:
               11.      AttributeDefinitions:
               12.        - { AttributeName: "partition_key", AttributeType: "S" }
               13.      KeySchema:
        }
      }
    }
  }
}

What did you expect to happen?
I expected the that cfn-guard validate exited cleanly since the rule for DYNAMODB_PITR_ENABLED is Supressed.
What actually happened?
cfn-guard validate evaluated the template as non-compliant
CloudFormation Guard Version
cfn-guard 3.0.1
OS
MacOS
OS Version
Sonoma 14.1.1
Other information
N/A

@plinioh I also encountered the same issue. I believe the problem has been resolved since the conditions have been fixed in the main branch.
https://github.com/aws-cloudformation/aws-guard-rules-registry/blob/main/rules/aws/dynamodb/dynamodb_pitr_enabled.guard#L31-L34
Conditions for SupressedRules are added in main !
let dynamodb_pitr_enabled = Resources.*[ Type == "AWS::DynamoDB::Table"
  Metadata.guard.SuppressedRules not exists or
  Metadata.guard.SuppressedRules.* != "DYNAMODB_PITR_ENABLED"
]


[BOT PR] to update dependencies of istio

This PR will be merged automatically once checks are successful.
none

@istio-testing: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-bookInfoTests-v1alpha3.sh
1b8ad2674aa14e683f8516ad15f0b21d509b044a
link
/test e2e-bookInfo-envoyv2-v1alpha3

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


Mining error

I am getting this red error when I load the mod, regardless of where I place it in the load order:
XML RimWorld.StatDef defines the same field twice: parts.

Field contents: AdvMiningIII1.075AdvMiningIV1.1.

Whole XML:

<StatDef><defName>MiningYield</defName>mining yield<description>The percentage of mined resources a miner will produce.\n\nThis applies to both wall mining and deep drill mining.\nThis doesn't affect the production rate of rock chunks.</description><category>PawnWork</category><defaultBaseValue>1</defaultBaseValue><minValue>0</minValue><maxValue>9999999</maxValue><toStringStyle>PercentZero</toStringStyle><skillNeedFactors>
<skill>Mining</skill><valuesPerLevel>
0.6

0.7

0.8

0.85

0.9

0.925

0.95

0.975

1

1.01

1.02

1.03

1.04

1.05

1.06

1.07

1.08

1.09

1.10

1.12

1.13
</valuesPerLevel>
</skillNeedFactors><capacityFactors>
<capacity>Manipulation</capacity><weight>0.3</weight><max>1</max>

<capacity>Sight</capacity><weight>0.2</weight><max>1</max>
</capacityFactors><parts>
</parts><displayPriorityInCategory>4901</displayPriorityInCategory><parts>
<researchFactors>
<def>AdvMiningIII</def><factor>1.075</factor>

<def>AdvMiningIV</def><factor>1.1</factor>
</researchFactors>
</parts></StatDef>
Verse.Log:Error(String, Boolean)
Verse.DirectXmlToObject:ObjectFromXml(XmlNode, Boolean)
Verse.DirectXmlToObject:ObjectFromXmlReflection(XmlNode, Boolean)
Verse.DirectXmlLoader:DefFromNode(XmlNode, LoadableXmlAsset)
Verse.LoadedModManager:ParseAndProcessXML(XmlDocument, Dictionary`2)
Verse.LoadedModManager:LoadAllActiveMods()
Verse.PlayDataLoader:DoPlayLoad()
Verse.PlayDataLoader:LoadAllPlayData(Boolean)
Verse.<>c:<Start>b__6_1()
Verse.LongEventHandler:RunEventFromAnotherThread(Action)
Verse.<>c:<UpdateCurrentAsynchronousEvent>b__27_0()
System.Threading.ThreadHelper:ThreadStart_Context(Object)
System.Threading.ExecutionContext:RunInternal(ExecutionContext, ContextCallback, Object, Boolean)
System.Threading.ExecutionContext:Run(ExecutionContext, ContextCallback, Object, Boolean)
System.Threading.ExecutionContext:Run(ExecutionContext, ContextCallback, Object)
System.Threading.ThreadHelper:ThreadStart()

Are you using the steam version of the mod, or the release version from here?
If you are using the steam one, can you please take the one from here and check if you can reproduce the issue with that version as well?
If you can reproduce the issue with this release version as well, can you please check if it happens also if only this mod is loaded?
If it doesn't happen when only this mod is loaded, could you try and find out which other mod is interfering with it?

I was originally using the Steam version, but installed the Git version for testing.  Both versions generate the same error.
I stripped it down to Harmony, Core, Royalty and this mod with the same error.  I removed Royalty and also got the same error.  So it definitely seems to be a problem in the mod.  If you're not getting it too, I am at a loss to explain what's happening.
Steps to reproduce: Configure the game to have the 3 or 4 mods I listed above enabled.  Start the game.  When the main menu loads, it will throw up the red error message in the console.
Let me know if there's anything else I can do to help assist in debugging this.  I know you're working for free here and I sincerely appreciate you taking the time to help me figure this out.

Okay, I have the error now. It seems something has changed in the core between 1.1.2570 and 1.1.2598 that is now causing this issue.

Github release done.
The core mod has added a new element in the original xml definition and the patching caused an invalid new structure. Luckily the fix was quite straightforward, and both the mining yield and speed seems to still be working fine.