OPT 125 - IREE Compilation Failure

What happened?
Compilation fails with :
opt-125M.fp32.torch-onnx.mlir:234:12: note: see current operation:
%72:2 = "tm_tensor.scan"(%64, %71, %57) <{dimension = 1 : i64, inclusive = true, operandSegmentSizes = array<i32: 1, 2>}> ({
^bb0(%arg1: i64, %arg2: i64):
  %151 = "arith.addi"(%arg1, %arg2) <{overflowFlags = #arith.overflow<none>}> : (i64, i64) -> i64
  "tm_tensor.yield"(%151) : (i64) -> ()
}) : (tensor<1x6xi64>, tensor<1x6xi64>, tensor<1xi64>) -> (tensor<1x6xi64>, tensor<1xi64>)
<unknown>:0: error: 'arith.constant' op operation destroyed but still has uses
<unknown>:0: note: see current operation: %0 = "arith.constant"() <{value = 192 : index}> : () -> index
<unknown>:0: note: - use: "hal.command_buffer.push_descriptor_set"(<<NULL VALUE>>, <<UNKNOWN SSA VALUE>>, <<UNKNOWN SSA VALUE>>, <<UNKNOWN SSA VALUE>>, <<NULL VALUE>>, <<UNKNOWN SSA VALUE>>, <<UNKNOWN SSA VALUE>>) : (<<NULL TYPE>>, !hal.pipeline_layout, index, index, <<NULL TYPE>>, index, index) -> ()

LLVM ERROR: operation destroyed but still has uses
Please report issues to https://github.com/openxla/iree/issues and include the crash backtrace.
Stack dump:
0.      Program arguments: ../iree-build/tools/iree-compile --iree-input-type=none --iree-vm-bytecode-module-output-format=flatbuffer-binary --iree-hal-target-backends=llvm-cpu --iree-util-zero-fill-elided-attrs /Users/phaneeshbarwaria/Downloads/opt-125M.fp32.linalg.mlir -o opt_debug.vmfb
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
0  libIREECompiler.dylib    0x000000011de078ac llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 56
1  libIREECompiler.dylib    0x000000011de05e30 llvm::sys::RunSignalHandlers() + 112
2  libIREECompiler.dylib    0x000000011de07f18 SignalHandler(int) + 304
3  libsystem_platform.dylib 0x000000018b85fa24 _sigtramp + 56
4  libsystem_pthread.dylib  0x000000018b830cc0 pthread_kill + 288
5  libsystem_c.dylib        0x000000018b740a40 abort + 180
6  libIREECompiler.dylib    0x000000011dd75ee4 llvm::report_fatal_error(llvm::Twine const&, bool) + 440
7  libIREECompiler.dylib    0x000000011dd75d2c llvm::report_fatal_error(llvm::Twine const&, bool) + 0
8  libIREECompiler.dylib    0x000000011def5d70 mlir::Operation::~Operation() + 532
9  libIREECompiler.dylib    0x000000011def6910 llvm::ilist_traits<mlir::Operation>::deleteNode(mlir::Operation*) + 72
10 libIREECompiler.dylib    0x000000011de4d5f0 mlir::Block::clear() + 100
11 libIREECompiler.dylib    0x000000011de4d400 mlir::Block::~Block() + 72
12 libIREECompiler.dylib    0x000000011df0760c mlir::Region::~Region() + 136
13 libIREECompiler.dylib    0x000000011def5c90 mlir::Operation::~Operation() + 308
14 libIREECompiler.dylib    0x000000011def6910 llvm::ilist_traits<mlir::Operation>::deleteNode(mlir::Operation*) + 72
15 libIREECompiler.dylib    0x000000011de4d5f0 mlir::Block::clear() + 100
16 libIREECompiler.dylib    0x000000011de4d400 mlir::Block::~Block() + 72
17 libIREECompiler.dylib    0x000000011df0760c mlir::Region::~Region() + 136
18 libIREECompiler.dylib    0x000000011def5c90 mlir::Operation::~Operation() + 308
19 libIREECompiler.dylib    0x000000011def6a40 mlir::Operation::erase() + 100
20 libIREECompiler.dylib    0x000000011dd130ac ireeCompilerInvocationDestroy + 40
21 libIREECompiler.dylib    0x000000011df5a2f0 mlir::iree_compiler::runIreecMain(int, char**)::$_0::operator()(iree_compiler_source_t*) const + 784
22 libIREECompiler.dylib    0x000000011df599ec mlir::iree_compiler::runIreecMain(int, char**) + 6312
23 dyld                     0x000000018b4b50e0 start + 2360

command - iree-compile --iree-input-type=none --iree-vm-bytecode-module-output-format=flatbuffer-binary --iree-hal-target-backends=llvm-cpu --iree-util-zero-fill-elided-attrs opt-125M.fp32.linalg.mlir -o opt_debug.vmfb
IR - opt-125M.fp32.linalg.mlir
(uploaded as .txt)
Steps to reproduce your issue

Go to '...'
Click on '....'
Scroll down to '....'
See error

What component(s) does this issue relate to?
No response
Version information
No response
Additional context
No response

I can't round-trip this file - is it intentional that you're leaving in unconverted types?
/home/gaurav/MLIRepos/SHARK-TestSuite/e2eshark/test-run/pytorch/models/opt-125M/opt-125M.fp32.torch-onnx.mlir:1:1: error: mixture of input types not yet implemented, set '--iree-input-type=[type]' explicitly instead of using 'auto' or audit the input program to understand why dialects are mixed (detected: 'onnx' 'tm_tensor')

I can't round-trip this file - is it intentional that you're leaving in unconverted ops?
/home/gaurav/MLIRepos/SHARK-TestSuite/e2eshark/test-run/pytorch/models/opt-125M/opt-125M.fp32.torch-onnx.mlir:1:1: error: mixture of input types not yet implemented, set '--iree-input-type=[type]' explicitly instead of using 'auto' or audit the input program to understand why dialects are mixed (detected: 'onnx' 'tm_tensor')

(no valid file should require ---iree-input-type=none)

A file that has already been converted to linalg should be fine with --iree-input-type=none.
Interesting... the 'onnx' input type is coming from the metadata that is left on this op after conversion:
func.func @main_graph(%arg0: tensor<1x6xi64> loc("/home/gaurav/MLIRepos/SHARK-TestSuite/e2eshark/test-run/pytorch/models/opt-125M/opt-125M.fp32.torch-onnx.mlir":2:25)) -> (tensor<1x6x768xf32>, tensor<1x12x6x64xf32>, tensor<1x12x6x64xf32>, tensor<1x12x6x64xf32>, tensor<1x12x6x64xf32>, tensor<1x12x6x64xf32>, tensor<1x12x6x64xf32>, tensor<1x12x6x64xf32>, tensor<1x12x6x64xf32>, tensor<1x12x6x64xf32>, tensor<1x12x6x64xf32>, tensor<1x12x6x64xf32>, tensor<1x12x6x64xf32>, tensor<1x12x6x64xf32>, tensor<1x12x6x64xf32>, tensor<1x12x6x64xf32>, tensor<1x12x6x64xf32>, tensor<1x12x6x64xf32>, tensor<1x12x6x64xf32>, tensor<1x12x6x64xf32>, tensor<1x12x6x64xf32>, tensor<1x12x6x64xf32>, tensor<1x12x6x64xf32>, tensor<1x12x6x64xf32>, tensor<1x12x6x64xf32>) attributes {torch.onnx_meta.ir_version = 8 : si64, torch.onnx_meta.opset_version = 17 : si64, torch.onnx_meta.producer_name = "pytorch", torch.onnx_meta.producer_version = "2.3.0"} {
Input conversion should probably remove that metadata after it is done with it.
'tm_tensor' is coming from
%33:2 = tm_tensor.scan dimension(1) inclusive(true) ins(%cst_2 : tensor<1x6xi64>) outs(%30, %32 : tensor<1x6xi64>, tensor<1xi64>) {
    ^bb0(%arg1: i64 loc("/home/gaurav/MLIRepos/SHARK-TestSuite/e2eshark/test-run/pytorch/models/opt-125M/opt-125M.fp32.torch-onnx.mlir":234:12), %arg2: i64 loc("/home/gaurav/MLIRepos/SHARK-TestSuite/e2eshark/test-run/pytorch/models/opt-125M/opt-125M.fp32.torch-onnx.mlir":234:12)):
      %845 = arith.addi %arg1, %arg2 : i64 loc(#loc15)
      tm_tensor.yield %845 : i64 loc(#loc15)
    } -> tensor<1x6xi64>, tensor<1xi64> loc(#loc15)
    %34 = linalg.generic {indexing_maps = [#map8, #map8, #map], iterator_types = ["parallel", "parallel"]} ins(%33#0, %cst_2 : tensor<1x6xi64>, tensor<1x6xi64>) outs(%29 : tensor<1x6xi64>) {

Looks like that scan op remains after input conversion (maybe one of the ops that got pushed too far down the compilation stack as a special case).

yeah, onnx should strip it's junk before it makes its way into IREE - would be good to file that issue
this is definitely an issue with tm_tensor.scan surviving all the way through the pipeline:
    %8 = stream.tensor.export %4 : tensor<1x6xi64> in !stream.resource<external>{%c48} -> tensor<1x6xi64>
    %9 = stream.tensor.export %5 : tensor<1x6xi64> in !stream.resource<external>{%c48} -> tensor<1x6xi64>
    %10:2 = tm_tensor.scan dimension(1) inclusive(true) ins(%8 : tensor<1x6xi64>) outs(%9, %6 : tensor<1x6xi64>, tensor<1xi64>) {
    ^bb0(%arg1: i64, %arg2: i64):
      %51 = arith.addi %arg1, %arg2 : i64
      tm_tensor.yield %51 : i64
    } -> tensor<1x6xi64>, tensor<1xi64>
    %11 = stream.tensor.import %10#0 : tensor<1x6xi64> -> tensor<1x6xi64> in !stream.resource<external>{%c48}
    %result_0, %result_timepoint_1 = stream.resource.alloca uninitialized await(%_constant__timepoint) => !stream.resource<external>{%c18432} => !stream.timepoint
    %result_2, %result_timepoint_3 = stream.resource.alloca uninitialized await(%_constant__timepoint) => !stream.resource<transient>{%c21504} => !stream.timepoint
    %result_4, %result_timepoint_5 = stream.resource.alloca uninitialized await(%_constant__timepoint) => !stream.resource<transient>{%c67584} => !stream.timepoint
    %12 = stream.timepoint.join max(%result_timepo

I get
/home/gaurav/MLIRepos/SHARK-TestSuite/e2eshark/test-run/pytorch/models/opt-125M/opt-125M.fp32.torch-onnx.mlir:234:12: error: failed to legalize operation 'tm_tensor.scan' that was explicitly marked illegal

in my build (with consteval off, because elided attrs can't be constevaled - so may be a different place than the original report but same root cause)
make sure tm_tensor.scan gets converted and don't pass the input-type=none flag.

Does this work with --input-type=tm_tensor?

--input-type=tm_tensor?

Yup! Just tried that, got a vmfb checking if that works
Thanks

Update:
iree-run-module just crashes
iree-build/tools/iree-run-module --module=opt_debug_ne.vmfb --input="1x6xsi64=[1 2 3 4 5 6]"
EXEC @main_graph
zsh: abort      ../iree-build/tools/iree-run-module --module=opt_debug_ne.vmfb

if you think your input program is correct you'll want to file a new issue relating to incorrect code generation of the op


Mention badges in package list PR template and docs

That’s where we’ve got package authors’ attention.

I believe this is done, closing.


Guild.timeout doesn't work

Summary
Guild.timeout(Member) is not working
Reproduction Steps

get member from guild object
run timeout by Guild.timeout()

Minimal Reproducible Code
member = guild.get_member(123456789012345678)
await guild.timeout(user=member, seconds=10, reason="some reason")

Expected Results
This should put user in timeout.
Actual Results
It actually returns
disnake.errors.HTTPException: 400 Bad Request (error code: 50035): Invalid Form Body
In user_id: Value "member's name" is not snowflake.

Intents
disnake.Intents.all()
System Information
Windows Server 2019, 64-bit
Python 3.9.7
disnake @ latest commit in master
Checklist

[X] I have searched the open issues for duplicates.
[X] I have shown the entire traceback, if possible.
[X] I have removed my token from display, if visible.

Additional Context
It actually works when use
await guild.timeout(user=123456789012345678)

I think #219 can fix this.

Yes, #219 fixes this, my bad

Should be fixed now, thanks for the report.


Fix crash in PINProgressiveImage

[CIFilter outputImage] can return nil, [CIContext createCGImage:fromRect:] requires a non-nil CIImage as input.

Looks good!


Update AWS SDK to v2

currently using v1.11.x, and it would be nice to update the SDK to the latest as part of the recent changes to copy from/to stmts. However the update to v2 is not feasible for now due to: https://github.com/aws/aws-sdk-java-v2/issues/52
We do use withForceGlobalBucketAccessEnabled instead of asking the users to provide the region.

However the update to v2 is not feasible for now due to: https://github.com/aws/aws-sdk-java-v2/issues/52

The linked issue has been closed:

This feature has been released in 2.20.99. You can enable it by setting crossRegionAccessEnabled to true on the S3 client builder.

S3AsyncClient client = S3AsyncClient.builder()
                                    .crossRegionAccessEnabled(true)
                                    .build();

This may be something to do during feature freeze


Added german translation

🚀 Description
This PR adds the german translation
📦 Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

✅ Checklist

[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.

Thank you so much @MDXDave


TOU 'type' field

https://www.pivotaltracker.com/story/show/146719817

added new 'type' field to Tou object

value must be one of:

website terms of use
subject website consent
stored website consent form
privacy policy

added migration for 'type' field

existing Tous are assigned default value of 'website terms of use'

added new field to Tou creations in test_tou
modified /tou/accepted POST logic to use 'type' response value if present, or else default to 'website terms of use'

Please don't merge yet - waiting to hear if current type defaulting logic in /tou/accepted/ POST is correct, or if we should change to always expect a 'type' value in the response json

Hello @OptimusRhine! Thanks for updating the PR.

In the file portal/migrations/versions/5d7a1030065e_.py, following are the PEP8 issues :

Line 13:1: E402 module level import not at top of file
Line 14:1: E402 module level import not at top of file
Line 15:1: E402 module level import not at top of file
Line 20:17: E101 indentation contains mixed spaces and tabs
Line 20:17: W191 indentation contains tabs
Line 20:20: E128 continuation line under-indented for visual indent
Line 21:17: E101 indentation contains mixed spaces and tabs
Line 21:17: W191 indentation contains tabs
Line 21:20: E128 continuation line under-indented for visual indent
Line 23:1: E302 expected 2 blank lines, found 1


Fluor does not work with Logitech Craft

Connect Logitech Craft keyboard
Install Logitech Options software.
Switch to an application where the function keys are activated.
Function keys still have the default behaviour

Fluor doesn't support non-Apple keyboards. Sorry.


fix for a potential nil pointer issue

This fix is included in the below backports for v1.1.3 and v1.2.3
https://github.com/longhorn/longhorn-manager/pull/1137
https://github.com/longhorn/longhorn-manager/pull/1138

LGTM. BTW, is there a ticket tracking this issue? If NO, we will directly merge it.

No ticket for this, since it's just a straightforward dev fix :)


error

{
"readyState": 4,
"responseText": "403 Forbidden",
"status": 403,
"statusText": "error"
}
this type why given

Hi @Anil9080,
please check this https://github.com/judge0/ide/issues/46#issuecomment-658234842
BR,
Herman

Which line impliment
On Fri, Sep 25, 2020, 16:05 Herman Zvonimir Došilović <
<EMAIL_ADDRESS>wrote:

Closed #55 https://github.com/judge0/ide/issues/55.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/judge0/ide/issues/55#event-3807104931, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALX2ZG7F33EZUCMJVOJKP3TSHRW7TANCNFSM4RWVWCYA
.


Opening options menu shows a black box for an instant before the menu window loads.

reeeeeally picky, this one.

No, not picky at all. Other menus don't do that, it's completely unnecessary. I'll fix it. :-)

Done, and enabled Instant Advice option.


tinacms package readme uses dated API

Summary
The readme for the tinacms package uses an outdated API: https://github.com/tinacms/tinacms/tree/main/packages/tinacms
It references functions like LocalClient (which is no longer called directly), useGraphqlForms
It also has some mistakes, like tina being added as a dev dependency in the installation
This readme is what shows up for our npm package, so it may cause confusion.
https://www.npmjs.com/package/tinacms

For now we'll update README.md files to point to Tina.io


STACK ERROR

dump status failed. maybe the process is not executing a php script
当启动时候报错
php版本PHP 5.5.28

命名就是一个php进程

#46


Unit tests link in readme 404s

The readme says:

Unit tests run via mocha.

which links to http://visionmedia.github.io/mocha which shows github.io's default 404 error page.

The README has been updated and this is no longer an issue


Unable to add a new friend if delete all before

Hi! Thanks for nice example! But i was found a error when try to test this example in my browser.

Open localhost:3000
Add a friend
DELETE ALL FRIENDS
Add new friend
Add another friend and will a little fail. New friend name just replace exists that added before!
I don't know why it doing, and hope if you have time then you will fix it.

+1

+1, same here


Implement source root abstraction

rust-analyzer needs to work with many Cargo packages simultaneously. Each packages may live in a separate dir, the might not be a common directory.
We need a data structure which can describe, compactly, which file belongs to each package.
Here's the sketch of the API:
/// Describes a tree of files on the file system
struct SourceRootSpeck {
     path_filter: Box<Fn(&Path) -> bool>, // typically `path.extension() == "rs"`, but should allow for gitignore, etc
    root: PathBuf,
}

/// A collection of source roots. Roots can intersect, so we need to be able to find the closest root for a given file.
struct Roots {
    roots: Vec<SourceRootSpeck>
}

impl Roots {
    /// Returns source root index for the path & relative path withing the root
    fn root_for(&self, path: &Path) -> Option<(usize, RelativePathBuf)>;
    /// Scans the file system an returns contents of all roots.
    fn scan(&self) -> Vec<SourceRootContents>;
}

/// This is the data used by analysis.
/// It contains only platform-independent relative paths.
struct SourceRootContents {
    files: HashMap<FileId, String>,
    paths: HashMap<FileId, RelativePathBuf>,
}

SourceRootContext should also subsume FileResolver.


Merge code-splitting-{import,require}

Implements and fixes #992.

Let's go for it. Funnily we got 3 PR's on this file within 16 hours.

@simon04 hahaha yea I was thinking the same thing, plus I'm working on another PR to resolve npm run test issues (#1041) which will touch this file as well 😆 .


New feature provided

Please answer these questions before submitting pull request

Why submit this pull request?

[ ] Bug fix

[ ] New feature provided

[ ] Improve performance

Related issues

Bug fix

Bug description.

How to fix?

New feature or improvement

Describe the details and related test reports.

df


Include ports in example URLs

Describe the Change You Would Like
Everywhere that we document example URLs for services that require ports, we should include the default port. This is
at least an issue for service-url for the pcp transport. We should audit and make sure we update any other examples like that.

This is also a problem in the bolt_shim module's instructions on connecting Bolt to PE.


[iOS] Crash in Value.cpp line 34 -  facebook::react::Value::toJSONString(unsigned int) const

Is this a bug report?
Yes
Have you read the Contributing Guidelines?
Yes
Environment
Environment:
OS:  macOS Sierra 10.12.6
Node:  8.5.0
Yarn:  1.0.1
npm:  5.3.0
Watchman:  4.6.0
Xcode:  Xcode 9.0 Build version 9A235
Android Studio:  2.3 AI-162.4069837
Packages: (wanted => installed)
react: 16.0.0-alpha.12 => 16.0.0-alpha.12
react-native: 0.48.3 => 0.48.3
Target Platform: iOS
Crash
Hi, we're getting a crash on iOS in the internals of React Native. I haven't been able to reproduce, but you can find the Crashlytics stack trace here : http://crashes.to/s/d52d9bce313

Crashed: com.facebook.react.JavaScript
EXC_BREAKPOINT 0x0000000186892ae8
--

12 Truckfly                       0x10072d4fc facebook::react::Value::toJSONString(unsigned int) const (Value.cpp:34)
13 Truckfly                       0x100753fa0 facebook::react::JSCExecutor::flushQueueImmediate(facebook::react::Value&&) (memory:4050)
14 Truckfly                       0x1007544a0 facebook::react::JSCExecutor::nativeFlushQueueImmediate(unsigned long, OpaqueJSValue const* const*) (JSCExecutor.cpp:588)
15 Truckfly                       0x100754c78 OpaqueJSValue const* (*facebook::react::(anonymous namespace)::exceptionWrapMethod<&(facebook::react::JSCExecutor::nativeFlushQueueImmediate(unsigned long, OpaqueJSValue const* const*))>())(OpaqueJSContext const*, OpaqueJSValue*, OpaqueJSValue*, unsigned long, OpaqueJSValue const* const*, OpaqueJSValue const**)::funcWrapper::call(OpaqueJSContext const*, OpaqueJSValue*, OpaqueJSValue*, unsigned long, OpaqueJSValue const* const*, OpaqueJSValue const**) (JSCExecutor.cpp:64)

Crashed: com.facebook.react.JavaScript
0  JavaScriptCore                 0x186892ae8 bmalloc::Heap::allocateLarge(std::__1::lock_guard&, unsigned long, unsigned long) + 24
1  JavaScriptCore                 0x186892adc bmalloc::Heap::allocateLarge(std::__1::lock_guard&, unsigned long, unsigned long) + 12
2  JavaScriptCore                 0x186890a1c bmalloc::Allocator::allocateLarge(unsigned long) + 92
3  JavaScriptCore                 0x185eeab88 WTF::StringImpl::createUninitialized(unsigned int, unsigned short*&) + 64
4  JavaScriptCore                 0x185eeaa40 WTF::StringBuilder::allocateBufferUpConvert(unsigned char const*, unsigned int) + 48
5  JavaScriptCore                 0x18687d58c WTF::StringBuilder::appendQuotedJSONString(WTF::String const&) + 160
6  JavaScriptCore                 0x18660f0c0 JSC::Stringifier::appendStringifiedValue(WTF::StringBuilder&, JSC::JSValue, JSC::Stringifier::Holder const&, JSC::PropertyNameForFunctionCall const&) + 1624
7  JavaScriptCore                 0x186610914 JSC::Stringifier::Holder::appendNextProperty(JSC::Stringifier&, WTF::StringBuilder&) + 3048
8  JavaScriptCore                 0x18660f594 JSC::Stringifier::appendStringifiedValue(WTF::StringBuilder&, JSC::JSValue, JSC::Stringifier::Holder const&, JSC::PropertyNameForFunctionCall const&) + 2860
9  JavaScriptCore                 0x18660e884 JSC::Stringifier::stringify(JSC::Handle) + 268
10 JavaScriptCore                 0x186613168 JSC::JSONStringify(JSC::ExecState*, JSC::JSValue, unsigned int) + 272
11 JavaScriptCore                 0x186657704 JSValueCreateJSONString + 180
12 Truckfly                       0x10072d4fc facebook::react::Value::toJSONString(unsigned int) const (Value.cpp:34)
13 Truckfly                       0x100753fa0 facebook::react::JSCExecutor::flushQueueImmediate(facebook::react::Value&&) (memory:4050)
14 Truckfly                       0x1007544a0 facebook::react::JSCExecutor::nativeFlushQueueImmediate(unsigned long, OpaqueJSValue const* const*) (JSCExecutor.cpp:588)
15 Truckfly                       0x100754c78 OpaqueJSValue const* (*facebook::react::(anonymous namespace)::exceptionWrapMethod<&(facebook::react::JSCExecutor::nativeFlushQueueImmediate(unsigned long, OpaqueJSValue const* const*))>())(OpaqueJSContext const*, OpaqueJSValue*, OpaqueJSValue*, unsigned long, OpaqueJSValue const* const*, OpaqueJSValue const**)::funcWrapper::call(OpaqueJSContext const*, OpaqueJSValue*, OpaqueJSValue*, unsigned long, OpaqueJSValue const* const*, OpaqueJSValue const**) (JSCExecutor.cpp:64)
16 JavaScriptCore                 0x1865becac long long JSC::APICallbackFunction::call(JSC::ExecState*) + 456
17 JavaScriptCore                 0x185f12270 JSC::LLInt::setUpCall(JSC::ExecState*, JSC::Instruction*, JSC::CodeSpecializationKind, JSC::JSValue, JSC::LLIntCallLinkInfo*) + 456
18 JavaScriptCore                 0x1866a65c0 llint_entry + 26416
19 JavaScriptCore                 0x1866a656c llint_entry + 26332
20 JavaScriptCore                 0x1866a656c llint_entry + 26332
21 JavaScriptCore                 0x1866a65d0 llint_entry + 26432
22 JavaScriptCore                 0x1866a656c llint_entry + 26332
23 JavaScriptCore                 0x1866a656c llint_entry + 26332
24 JavaScriptCore                 0x1866a6904 llint_entry + 27252
25 JavaScriptCore                 0x1866a656c llint_entry + 26332
26 JavaScriptCore                 0x1866a65d0 llint_entry + 26432
27 JavaScriptCore                 0x1866a656c llint_entry + 26332
28 JavaScriptCore                 0x1866a65d0 llint_entry + 26432
29 JavaScriptCore                 0x1866a656c llint_entry + 26332
30 JavaScriptCore                 0x1866a65d0 llint_entry + 26432
31 JavaScriptCore                 0x1866a65d0 llint_entry + 26432
32 JavaScriptCore                 0x1866a656c llint_entry + 26332
33 JavaScriptCore                 0x1866a656c llint_entry + 26332
34 JavaScriptCore                 0x1866a6904 llint_entry + 27252
35 JavaScriptCore                 0x1866a65d0 llint_entry + 26432
36 JavaScriptCore                 0x1866a656c llint_entry + 26332
37 JavaScriptCore                 0x1866a656c llint_entry + 26332
38 JavaScriptCore                 0x1866a656c llint_entry + 26332
39 JavaScriptCore                 0x1866a656c llint_entry + 26332
40 JavaScriptCore                 0x1866a656c llint_entry + 26332
41 JavaScriptCore                 0x1866a656c llint_entry + 26332
42 JavaScriptCore                 0x1866a656c llint_entry + 26332
43 JavaScriptCore                 0x1866a6a10 llint_entry + 27520
44 JavaScriptCore                 0x1866a65d0 llint_entry + 26432
45 JavaScriptCore                 0x1866a656c llint_entry + 26332
46 JavaScriptCore                 0x1866a6a10 llint_entry + 27520
47 JavaScriptCore                 0x1866a656c llint_entry + 26332
48 JavaScriptCore                 0x1866a65d0 llint_entry + 26432
49 JavaScriptCore                 0x1866a656c llint_entry + 26332
50 JavaScriptCore                 0x18669fcc8 vmEntryToJavaScript + 264
51 JavaScriptCore                 0x186589710 JSC::JITCode::execute(JSC::VM*, JSC::ProtoCallFrame*) + 164
52 JavaScriptCore                 0x185f16610 JSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 416
53 JavaScriptCore                 0x18622273c JSC::profiledCall(JSC::ExecState*, JSC::ProfilingReason, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) + 164
54 JavaScriptCore                 0x185f16384 JSObjectCallAsFunction + 636
55 Truckfly                       0x10072e364 facebook::react::Object::callAsFunction(OpaqueJSValue*, int, OpaqueJSValue const* const*) const (Value.cpp:189)
56 Truckfly                       0x100753860 facebook::react::JSCExecutor::callFunction(std::__1::basic_string, std::__1::allocator > const&, std::__1::basic_string, std::__1::allocator > const&, folly::dynamic const&) (Value.h:46)
57 Truckfly                       0x100752d90 std::__1::function::operator()(facebook::react::JSExecutor*) const (functional:1817)
58 Truckfly                       0x1006e1294 facebook::react::tryAndReturnError(std::__1::function const&) (RCTCxxUtils.mm:97)
59 Truckfly                       0x1006da8c0 facebook::react::RCTMessageThread::tryFunc(std::__1::function const&) (RCTMessageThread.mm:62)
60 CoreFoundation                 0x181fb130c __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 20
61 CoreFoundation                 0x181fb0b28 __CFRunLoopDoBlocks + 288
62 CoreFoundation                 0x181faee1c __CFRunLoopRun + 1884
63 CoreFoundation                 0x181ededa4 CFRunLoopRunSpecific + 424
64 Truckfly                       0x1006b9f78 -[RCTCxxBridge runJSRunLoop] (RCTCxxBridge.mm:220)
65 Foundation                     0x182af7318 __NSThread__start__ + 996
66 libsystem_pthread.dylib        0x1810c568c _pthread_body + 240
67 libsystem_pthread.dylib        0x1810c559c _pthread_body + 282
68 libsystem_pthread.dylib        0x1810c2cb4 thread_start + 4

Does anyone see the same crash?

I've seen the same crash on crashlytics

Did any of ya'll come up with a workaround for this? We're seeing this error log pretty consistently in production, and users confirm it results in a crash, but we're not able to recreate it on our own.

Any fix for this yet?

has a workaround been found yet?

+1 seeing the same behavior

I’ve been seeing these occasionally, too. No idea what causes it.

Has anyone found a fix for this yet?

I get about a thousand of these daily.  Could really use assistance in a work around or fix. The crash reports aren't helpful at identifying the cause.

@facebook-github-bot label iOS

+1 same error
One thing that's consistent: OS Version: iPhone OS 11.0.3 (15A432)
Can someone share their package.json or list of dependencies?
Want to check if there is any common package that could be leading to this.

@robwalkerco any progress? Are you able to replicate it? The stack trace isn't very helpful :/

@cosmith my finding were that the error happened when trying to store large json data to AsyncStorage on iOS. My example was a json string 52000000 characters long.
I ended up getting around this issue by using realm as a storage engine for redux-persist, and also by splitting the reducer for that data into 16 separate reducers that are combined by a selector so I can easily use the data.
I put the details in this answer in stack overflow - https://stackoverflow.com/a/48582319/3672622

@robwalkerco But I ain't using AsyncStorage :|

@princenaman perhaps there is somewhere else in your code that’s transferring a large bit of data across the JavaScript bridge? That’s where I guess the crash is happening.
Or perhaps some other package you are using that’s using AsyncStorage behind the scenes?

The largest data that I am transferring is a JSON string about 5000 characters long.
Will check my packages though.

Thanks @robwalkerco. Did the crash always happen with your ~50Mb JSON string, or occasionally? Looking back at my crashes in production, some occurrences could have been coincident with writing 1-3Mb JSON strings to AsyncStorage, but (a) probably not all occurrences, (b) the app has likely written larger JSON strings a number of times without seeing this crash.
Either way, I'm now instrumenting these calls to AsyncStorage with the size of the JSON string, so I'll know if it crashes in SetItem() and what the size of the string was.
Incidentally, my Crashlytics reports all put the available RAM at < 10% on these crashes. For an iPad 2 I think that's less than 50Mb free. Make a few copies of the string, maybe the memory usage report over-reported free memory...it's conceivable this is a memory problem. I'd love to test this hypothesis too, but RN doesn't have a hook for receiving low memory warnings though, right?

@pjktk2 when I managed to replicate the crash (more by chance than anything) it was only happening when storing a large json string, and was happening consistently with that json (at least on my phone)
I’ve not looked at memory availability, but will check our error reporting for any clues there.
Sounds like you are well ahead of me in terms to tracking this bug down, so I will be interested to hear your findings!

@pjktk2 I think your right about the memory issue. All the crashes happened when there was less than 5% RAM available on the device.

+1 on this, in the latest version of our app the stack trace changed to bmalloc::Heap::allocateLarge

Any tips on reducing memory usage with RN?

Can it be because I am storing data in Realm?

This issue was introduced for us when upgrading from BatchedBridge to CxxBridge (react native's C++ bridge), which was made the default in react-native v0.45.0. We see thousands of crashes a day for about 6-7% of our users.
I was able to replicate the crash by sending a large string (~100,000,000 characters long) to a custom NativeModule function that does nothing. The CxxBridge just isn't able to handle passing a string that large from JS to Native. It could be memory related, but doesn't happen when using BatchedBridge instead of CxxBridge.
This definitely isn't limited to AsyncStorage, and could happen with any package or code that sends a large string across the bridge. If you're using redux-persist, persisting less data or blacklisting large reducers would fix the issue for now. Ideally the bridge would be able to handle larger strings...

I’ll double check next week, but I was able to replicate this issue in the latest version of react native. It was introduced in react native v0.45.0. I think it would be better to keep this particular issue open as it has a lot of context.

Just a follow up to @cosmith asking about reducing memory usage vis a vis workarounds:
A few days ago I had a 100% reproducible case with this bug and I used the "opportunity" to clean up a bit of memory usage. I was storing a 6Mb string on a single AsyncStorage.setItem(). I profiled the app and found that memory usage spiked 8-10x that amount (i.e. 50-65Mb) when accessing that item. That spike was what caused the crash, every time.
Some of the spike be due to my post-processing code, but I think a lot was due to the string being copied and re-copied on its way through native code. In this case, I chopped up the item into many smaller parts (using the same JS post-processing code!) and the spike disappeared.
Interestingly, while my crude performance testing on the iOS simulator showed a performance hit of 4x, running on a device in production I couldn’t see a noticeable performance difference. Note that the performance tests on a real device were (a) stopwatch and not instrumented counters, and (b) done in a warm-cache environment, not cold-cache. YMMV.
This may or may not be helpful to you, but if you can avoid passing large strings though setItem/getItem, even if it involves slicing them up and re-composing them, it might help.

Hi @pjktk2, thanks for the followup. I was also able to make this crash disappear by saving the big blob of data that I had to the filesystem instead of AsyncStorage.

I can reproduce this crash in my project 100%, every time I try to use 'console.tron.log'(the log helper of reactotron-react-native) to output the params of an event(like onBlur of TextInput),the app will crash after a few seconds without any response, maybe this is useful for locating the issue.
<TextInput                 onBlur={(e)=>{                     console.tron.log('blur',e);                  }}

@cosmith If you don't mind me asking, how did you achieve this? I'm serialising a 9MB object structure to JSON and writing it to disk with rn-fetch-blob, but it seems to crash quite often.

I opened a new issue since the crash is still happening on the latest version of react-native. If anyone wants to chime in there, feel free :)


Display image message appears two times

Description
The fsleyes line at the end appears two times:
julien-macbook:~/temp/20210313-ibrahim $ sct_deepseg -i dwi_1500_orient_b0_mean_orient-wrong.nii.gz -task seg_mice_gm-wm_dwi

--
Spinal Cord Toolbox (git-jca/3284-deepseg-qform-60ea08c9d664cf403f2982f8f5c8ae1cc5d704a3*)

sct_deepseg -i dwi_1500_orient_b0_mean_orient-wrong.nii.gz -task seg_mice_gm-wm_dwi
--

Model model_seg_mice_gm-wm_dwi_unet2d-multichannel-softseg is not installed. Installing it now...

INSTALLING MODEL: model_seg_mice_gm-wm_dwi_unet2d-multichannel-softseg
Trying URL: https://github.com/ivadomed/model_seg_mice_gm-wm_dwi_unet2d-multichannel-softseg/archive/r20210220.zip
Downloading: model_seg_mice_gm-wm_dwi_unet2d-multichannel-softseg-r20210220.zip
Status: 72.9MB [00:14, 5.11MB/s]
Creating temporary folder (/var/folders/s8/4qnm5q1n261ch35b5kkclsb00000gn/T/sct-20210316100812.234262-9fb_mu70)
Unzip data to: /var/folders/s8/4qnm5q1n261ch35b5kkclsb00000gn/T/sct-20210316100812.234262-9fb_mu70
Removing temporary folders...

WARNING: fname_roi has not been specified, then the entire volume is processed.

Loaded 512 axial slices.

Done! To view results, type:
fsleyes dwi_1500_orient_b0_mean_orient-wrong.nii.gz -cm greyscale dwi_1500_orient_b0_mean_orient-wrong_gmseg_manual.nii.gz -cm red -a 70.0 &

Done! To view results, type:
fsleyes dwi_1500_orient_b0_mean_orient-wrong.nii.gz -cm greyscale dwi_1500_orient_b0_mean_orient-wrong_wmseg_manual.nii.gz -cm red -a 70.0 &

Could you share your input file dwi_1500_orient_b0_mean_orient-wrong.nii.gz please?

you can reproduce using sct_testing_data

I couldn't reproduce with sct_testing_data so I am wondering if it has something to do with the input data.
$  sct_deepseg -i dwi_mean.nii.gz -task seg_mice_gm-wm_dwi

--
Spinal Cord Toolbox (git-jca/3284-deepseg-qform-c465f5e042723e76dff203f151ee8603fa10ee2b*)

sct_deepseg -i dwi_mean.nii.gz -task seg_mice_gm-wm_dwi
--

WARNING: fname_roi has not been specified, then the entire volume is processed.

Loaded 5 axial slices.

Done! To view results, type:
fsleyes dwi_mean.nii.gz -cm greyscale dwi_mean_gmseg_manual.nii.gz -cm red -a 70.0 &

Here:
julien-macbook:~/sct_testing_data/t2 $ sct_deepseg -i t2.nii.gz -task seg_mice_gm-wm_dwi

--
Spinal Cord Toolbox (git-3301-qc-entry-for-moco-functions-f4a00235f72d141c83af131a9faf53b117b7aa36)

sct_deepseg -i t2.nii.gz -task seg_mice_gm-wm_dwi
--

WARNING: fname_roi has not been specified, then the entire volume is processed.

Loaded 55 axial slices.

Done! To view results, type:
fsleyes t2.nii.gz -cm greyscale t2_gmseg_manual.nii.gz -cm red -a 70.0 &

Done! To view results, type:
fsleyes t2.nii.gz -cm greyscale t2_wmseg_manual.nii.gz -cm red -a 70.0 &

But this is using another git commit, so I am trying now with the latest git master version...

⚠ False alarm! the fsleyes message is not the same, but shows two different outputs... my bad. However, we should probably change the output display because it is confusing. I'll change the message.
@Drulex another weird thing is that you do not have the same output as me. Can you try with the latest master?

On a fresh install:
$  sct_deepseg -i t2.nii.gz -task seg_mice_gm-wm_dwi

--
Spinal Cord Toolbox (git-master-4fd149d7d381c834e79dfdf8c0116b97aaef2fb7*)

sct_deepseg -i t2.nii.gz -task seg_mice_gm-wm_dwi
--

Model model_seg_mice_gm-wm_dwi_unet2d-multichannel-softseg is not installed. Installing it now...

INSTALLING MODEL: model_seg_mice_gm-wm_dwi_unet2d-multichannel-softseg
Trying URL: https://github.com/ivadomed/model_seg_mice_gm-wm_dwi_unet2d-multichannel-softseg/archive/r20210220.zip
Downloading: model_seg_mice_gm-wm_dwi_unet2d-multichannel-softseg-r20210220.zip
Status: 72.9MB [00:22, 3.20MB/s]
Creating temporary folder (/tmp/sct-20210323104426.342042-ac9uwk8d)
Unzip data to: /tmp/sct-20210323104426.342042-ac9uwk8d
Removing temporary folders...

WARNING: fname_roi has not been specified, then the entire volume is processed.

Loaded 55 axial slices.

Done! To view results, type:
fsleyes t2.nii.gz -cm greyscale t2_gmseg_manual.nii.gz -cm red -a 70.0 &

Done! To view results, type:
fsleyes t2.nii.gz -cm greyscale t2_wmseg_manual.nii.gz -cm red -a 70.0 &


Document BUILDKITE_STEP_ID

🥫

Actually this is incorrect…
steps:
  - command: echo specs
    id: specs

results in:
BUILDKITE_JOB_ID="80818485-83fb-4cc0-afaf-85719f5a934b"
BUILDKITE_STEP_ID="5726eaa1-b695-4698-95f4-3375971a54b0"
BUILDKITE_STEP_KEY="specs"

We should probably document these separately. Will open a new PR!


serverOnly return type should consider parameters of the passed function

Which project does this relate to?
Start
Describe the bug
serverOnly does not return the correct type.
As of v1.82.4, serverOnly is declared like this.
export declare function serverOnly<T>(value: () => T): () => T | undefined;

This means that when I have a serverOnly function like this:
import { serverOnly } from "@tanstack/start";

export const getPokemon = serverOnly(async (pokemon: string) => {
  return await fetch(`https://pokeapi.co/api/v2/pokemon/${pokemon}`).then(res => res.json());
});

getPokemon is inferred to have the type () => Promise<any> | undefined, which means passing the pokemon parameter leads to a typescript error
export const Route = createRootRoute({
  beforeLoad: async () => {
    const pokemon = await getPokemon("ditto");
                                     // ^ Expected 0 arguments, but got 1. (2554)
    return {pokemon}
  },
  component: RootComponent,
});

Alternative method
You can wrap the anonymous function inside another anonymous function to get the correct return type
import { serverOnly } from "@tanstack/start";

// Notice () => async () => {}
export const getPokemon = serverOnly(() => async (pokemon: string) => {
  return await fetch(`https://pokeapi.co/api/v2/pokemon/${pokemon}`).then(res => res.json());
});

But you will have to "unwrap" once
export const Route = createRootRoute({
  beforeLoad: async () => {
    const pokemon = await getPokemon?.()("ditto");
    return { pokemon };
  },
  component: RootComponent,
});

Your Example Website or App
https://stackblitz.com/edit/github-avg9mj-9r1rad?file=app%2Froutes%2F__root.tsx
Steps to Reproduce the Bug or Issue

Go to __root.tsx
Observe that I can't pass "ditto" as an argument to getPokemon, even if the function passed to serverOnly has a parameter of type string

Expected behavior
getPokemon should be inferred as (pokemon: string) => Promise<any> | undefined
Screenshots or Videos
No response
Platform

OS: Windows
Browser: Microsoft Edge
Version: Version 131.0.2903.51 (Official build) (64-bit)

Additional context
No response

fix released in https://github.com/TanStack/router/releases/tag/v1.87.1


2553: Add Accessibility Role to components

Short description
For better accessibility: the role should be set.
Proposed changes

Replaced accessibilityRole with role
ThemedSearchBar.tsx has search bar with role ="searchbox" instead of  role ="search"

Side effects
None.
Resolved issues

Fixes: #2553

Is this ready for review or still a draft?

Is this ready for review or still a draft?

The replacing part is done but I need to look for any other component that needs Role tag.
When it's ready I will click Ready for review

Thanks for this PR!
I just found https://www.npmjs.com/package/eslint-plugin-react-native-a11y and I think we should employ it to avoid forgetting this in the future. I just installed it and it seems like the role is still missing in 5 cases (at least I am getting a linting error). Could you perhaps check out #2913 and merge this if you think this makes sense?
Sadly these rules seem to not work together with styled-components/custom components. Therefore it would be nice to add a required property role to base/Pressable to also fix future problems. Thank you!

I decided not to proceed with installing "eslint-plugin-react-native-a11y" because styled-components didn't work properly with it. also we rarely used vanilla React Native components without styled-components.


Make iframes able to be in blogs

Blogs should have embedded content since this is common for users to see in blogs and enriches the user experience.
Challenge
ReactMarkdown does not natively support usage of HTML element.  All elements will be treated as Markdown.

Solution
https://stackoverflow.com/a/70548866/8278075
Use rehype as a plugin for ReactMarkdown:
<ReactMarkdown
          components={ReactMarkdownRules()}
          rehypePlugins={[rehypeRaw] as any}
        >
          {markdownBody}
</ReactMarkdown>

You would add a blog entry in the Markdown file:
   <div
     style="padding-bottom:56.25%; position:relative; display:block; width: 100%"
   >
     <iframe
       width="100%"
       height="100%"
       src="https://youtu.be/j5a0jTc9S10?si=eGX-bRyQGBp4cAed"
       frameborder="0"
       allowfullscreen=""
       style="position:absolute; top:0; left: 0"
     >
     </iframe>
   </div>

All iframes must be responsive as we intend for users to mostly view site on mobile.


[Bug][Go SDK]: Silent Dataflow failure upon glibc library mismatch

What happened?
Hi Apache Beam team,
I've recently identified an issue with using the Beam Go SDK with Google's Dataflow. I've already filed a bug report with Google, but I wanted to report it here as well in case there's something to be done in the SDK side.
I'll paste the contents of my liked bug report below:

Recently, I encountered an issue where I was unable to run any Dataflow pipeline using the Go language SDK. Previously I'd only used Python with Dataflow. I used the wordcount.go example pipeline as my test case. I followed the deployment instructions on the Dataflow site and didn't do anything fancy.
Upon deploying the pipeline, the Dataflow console reported that the workers had started successfully and that everything was running fine. Despite this, the pipeline never made any progress whatsoever.
I noticed some errors at the logs when looking at Stackdriver with these filters:
resource.type="dataflow_step"
resource.labels.job_id="2022-11-30_13_25_07-7319605715258819834"

The most concerning log entries were the following:
"ContainerStatus from runtime service failed" err="rpc error: code = Unknown desc = Error: No such container: 1dd1f5aed1062c9fa85e1437dcbb915a8e3844a5a8de66982aaf4c1471dc492e" containerID="1dd1f5aed1062c9fa85e1437dcbb915a8e3844a5a8de66982aaf4c1471dc492e"
"getPodContainerStatuses for pod failed" err="rpc error: code = Unknown desc = Error: No such container: 1dd1f5aed1062c9fa85e1437dcbb915a8e3844a5a8de66982aaf4c1471dc492e" pod="default/df-matthew-test-golang-v3-11301257-l37l-harness-6jnd"
"Error syncing pod, skipping" err="failed to \"StartContainer\" for \"sdk-0-0\" with CrashLoopBackOff: \"back-off 10s restarting failed container=sdk-0-0 pod=df-matthew-test-golang-v3-11301257-l37l-harness-6jnd_default(57e4bc85cfdd8d814463331df622de1a)\"" pod="default/df-matthew-test-golang-v3-11301257-l37l-harness-6jnd" podUID=57e4bc85cfdd8d814463331df622de1a
"Error syncing pod, skipping" err="failed to \"StartContainer\" for \"sdk-0-0\" with CrashLoopBackOff: \"back-off 20s restarting failed container=sdk-0-0 pod=df-matthew-test-golang-v3-11301257-l37l-harness-6jnd_default(57e4bc85cfdd8d814463331df622de1a)\"" pod="default/df-matthew-test-golang-v3-11301257-l37l-harness-6jnd" podUID=57e4bc85cfdd8d814463331df622de1a
"Error syncing pod, skipping" err="failed to \"StartContainer\" for \"sdk-0-0\" with CrashLoopBackOff: \"back-off 20s restarting failed container=sdk-0-0 pod=df-matthew-test-golang-v3-11301257-l37l-harness-6jnd_default(57e4bc85cfdd8d814463331df622de1a)\"" pod="default/df-matthew-test-golang-v3-11301257-l37l-harness-6jnd" podUID=57e4bc85cfdd8d814463331df622de1a

I was stuck here for awhile, not understanding what was going wrong which could explain these Kubernetes errors. After staring at the logs for several hours, I came across these log messages, which were not marked as errors:
2022/12/01 00:40:02 Provision info:
pipeline_options:{fields:{key:"beam:option:go_options:v1" value:{struct_value:{fields:...blah..blah}}}}
2022/12/01 00:40:02 Initializing Go harness: /opt/apache/beam/boot --logging_endpoint=localhost:12370 --control_endpoint=localhost:12371 --artifact_endpoint=localhost:12372 --provision_endpoint=localhost:12373 --semi_persist_dir=/var/opt/google --id=sdk-0-0
/bin/worker: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /bin/worker)
/bin/worker: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /bin/worker)
2022/12/01 00:40:02 User program exited: exit status 1
ignoring event map[container:cc38c9371adfcaff693d3b7bb1791111f7793f6d875eea6e756bb0254433b09e module:libcontainerd namespace:moby topic:/tasks/delete type:*events.TaskDelete]

Not being an expert on the internals of Dataflow, I didn't know if this was a real error or one of the many benign errors that appear in the Dataflow logs. But I figured that I would assume that these errors were the errors causing my issues, and see if I could quash them.
My development machine has glibc 2.36 installed, and the apache/beam_go_sdk:2.43.0 docker image has glibc 2.31 installed. Instead of downgrading my glibc version, I did some googling, and found that I could disable Go's dynamic linking by exporting CGO_ENABLED=0 before deploying the pipeline with go run. This fixed the issue with my pipeline immediately.
I'm fairly new to Go, so I can't say with any certainty that dynamic linking should be disabled by default on all Dataflow Go pipelines, but it is something worth considering. Alternatively, it would be EXTREMELY helpful if Dataflow would have reported this error more clearly in the first place. I don't think that mismatched glibc versions are a particularly rare occurrence, and this subtle error is a huge barrier to entry when using Go with Dataflow.

Issue Priority
Priority: 2
Issue Component
Component: sdk-go

@lostluck

Note that I've just added detailed instructions on reproducing this issue to the linked bug report.

Issue: #25314 is also noting this particular problem with the boot loaders.

Some thoughts:

In boot.go we only have stdout and stderr but no application level information regarding the severity of the logs. So basically, we don't know what severity of stderr should be - it could contain the root cause for failure (i.e. process termination) but it could also contain warnings and random diagnostic output as per POSIX standard.
One way to do this is to send stderr as ERROR or FATAL if the process crashed, and INFO otherwise, although I don't love this.
We also lose some context in boot.go - things bundle_id and transform_id that could tell you where the error happened.

See https://github.com/cozos/beam/pull/3/files for first attempt

@cozos Sorry for not seeing that sooner.
That attempt would work, but it makes every SDK depend on a Go SDK specific harness detail. Those are best kept isolated. The boot container doesn't need anything nearly as involved to log over the FnAPI, so it can be simpler in order to keep it debuggable.

Also the boot.go will never have any meaningful associated bundle_id and transform_id since those require a live pipeline execution, and those ids are only meaningful to the runner that generated them.

The logging here should no longer be silent due to that previous fix. I beleive that did make it into 2.47.0, releasing soon.
We likely don't want to require users to have CGO disabled, but that would also prevent issues like this I think?
I'm less well versed in that. But I would love that verification so we can put that advice in the cross-compile documentation, or perhaps make the "autobuild and submit" binary mode set that too (though I beleive any env variables would also normally be propagated, so we'd want to respect that setting.)
The linker error is a real issue, and how to resolve it might not be obvious to users. Ideally we have the boot loader additional log when this kind of error is detected, the CGO workaround (if verified) , or point to instructions (on the cross-comp page) on how fix the issue.

Thanks so much!

Looks like this never got closed because of how GitHub parses the "fixes" string in PR descriptions. Fixed by #26035


\x00 breaks copy-paste

Steps to reproduce:

input ("\x00")
click "copy result"

Expected behaviour: whole string is copied
Actual behaviour: only (" is copied. Everything else is not copied as it is after the \x00
EDIT: this happens in Firefox, but not in Chrome

Closing, because it turns out it's actually an issue with Firefox


refactor containerized microshift build

This PR standarizes the build flow for make microshift target so that the containerized microshift binary and the binary produced by the containerized build are known to be identical.  This is accomplished by first building the binary in the build container, copying it to the runnable image, and then copying it to the host.
Contingent on #115, as that defines a stable container runtime env.

/lgtm


Caching fix

Allow setting to false scrollEnabled and zoomEnabled when not using cached view

@jrichardlai hey, sorry, could you resolve the conflict? I had changes that handles the wrong behavior of scrollEnabled and zoomEnabled

@ivanfoong will do! :)
Sent from my iPhone

On May 15, 2016, at 10:56 PM, ivanfoong<EMAIL_ADDRESS>wrote:
@jrichardlai hey, sorry, could you resolve the conflict? I had changes that handles the wrong behavior of scrollEnabled and zoomEnabled
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

we dont need this one then


Danger breaks when files are moved

Report
What did you do?
I moved a file: https://github.com/SwiftWeekly/swiftweekly.github.io/pull/89/commits/f51ce4759205e31699f59ba6aebfcc2249f88016
What did you expect to happen?
I expected Danger to not attempt to lint the file at its previous location, but rather lint it at its new location.
What happened instead?
💥. Danger tried to lint the file at its old location, causing the following failure:
/home/travis/build/SwiftWeekly/swiftweekly.github.io/vendor/bundle/ruby/2.1.0/gems/danger-prose-2.0.3/lib/danger_plugin.rb:63:in `block (2 levels) in lint_files':  (Danger::DSLError)
[!] Invalid `Dangerfile` file: undefined method `[]' for nil:NilClass. Updating the Danger gem might fix the issue. Your Danger version: 3.2.1, latest Danger version: 3.2.2
 #  from Dangerfile:2
 #  -------------------------------------------
 #  # Look for prose issues
 >  prose.lint_files
 #
 #  -------------------------------------------
	from /home/travis/build/SwiftWeekly/swiftweekly.github.io/vendor/bundle/ruby/2.1.0/gems/danger-prose-2.0.3/lib/danger_plugin.rb:63:in `select'
	from /home/travis/build/SwiftWeekly/swiftweekly.github.io/vendor/bundle/ruby/2.1.0/gems/danger-prose-2.0.3/lib/danger_plugin.rb:63:in `block in lint_files'
	from /home/travis/build/SwiftWeekly/swiftweekly.github.io/vendor/bundle/ruby/2.1.0/gems/danger-prose-2.0.3/lib/danger_plugin.rb:179:in `with_proselint_disabled'
	from /home/travis/build/SwiftWeekly/swiftweekly.github.io/vendor/bundle/ruby/2.1.0/gems/danger-prose-2.0.3/lib/danger_plugin.rb:60:in `lint_files'
	from Dangerfile:2:in `block in parse'
	from /home/travis/build/SwiftWeekly/swiftweekly.github.io/vendor/bundle/ruby/2.1.0/gems/danger-3.2.1/lib/danger/danger_core/dangerfile.rb:194:in `eval'
	from /home/travis/build/SwiftWeekly/swiftweekly.github.io/vendor/bundle/ruby/2.1.0/gems/danger-3.2.1/lib/danger/danger_core/dangerfile.rb:194:in `block in parse'
	from /home/travis/build/SwiftWeekly/swiftweekly.github.io/vendor/bundle/ruby/2.1.0/gems/danger-3.2.1/lib/danger/danger_core/dangerfile.rb:190:in `instance_eval'
	from /home/travis/build/SwiftWeekly/swiftweekly.github.io/vendor/bundle/ruby/2.1.0/gems/danger-3.2.1/lib/danger/danger_core/dangerfile.rb:190:in `parse'
	from /home/travis/build/SwiftWeekly/swiftweekly.github.io/vendor/bundle/ruby/2.1.0/gems/danger-3.2.1/lib/danger/danger_core/executor.rb:46:in `run'
	from /home/travis/build/SwiftWeekly/swiftweekly.github.io/vendor/bundle/ruby/2.1.0/gems/danger-3.2.1/lib/danger/commands/runner.rb:56:in `run'
	from /home/travis/build/SwiftWeekly/swiftweekly.github.io/vendor/bundle/ruby/2.1.0/gems/claide-1.0.0/lib/claide/command.rb:334:in `run'
	from /home/travis/build/SwiftWeekly/swiftweekly.github.io/vendor/bundle/ruby/2.1.0/gems/danger-3.2.1/bin/danger:5:in `<top (required)>'
	from /home/travis/build/SwiftWeekly/swiftweekly.github.io/vendor/bundle/ruby/2.1.0/bin/danger:23:in `load'
	from /home/travis/build/SwiftWeekly/swiftweekly.github.io/vendor/bundle/ruby/2.1.0/bin/danger:23:in `<main>'

Your Environment

Which CI are you running on?

Travis, though I don't think that's related. Here's the failing build: https://travis-ci.org/SwiftWeekly/swiftweekly.github.io/builds/160181293

Are you running the latest version of Danger?

Running 3.2.1, but looking at the diff between that and master, nothing that's landed since would have fixed this.

Log looks like a bug in https://github.com/dbgrandi/danger-prose.

Need to figure out how to remove the deleted file from here.

The root cause is that there is no diff (@git.diff is nil), so these methods are failing:

nice find, that's really interesting!

Should be easy to write a test for at least

More cases: https://travis-ci.org/danger/danger/builds/160615933 from #558.

A test case I've been working with:
        it "handles moving a file correctly" do
          run_in_repo_with_diff do |git|
            `mv file1 file2`
            `git add .`
            `git checkout -b new-branch-2 --quiet`
            `git commit -m "moved file"`

            # now check the changes for the moved file
            diff = git.diff("new-branch")
            stats = diff.stats
            # allow(@repo).to receive(:diff).and_return(diff)

            require 'pry'
            binding.pry

            expect(@dsl.modified_files).to eq([])
          end

This is tricky, because it is literally git which gives us the "bad" details, I wonder if we need to do a pre-parse of the stats dictionary to ensure that all files exist, and if they don't to chuck them in removed files

Our code actually works:
context "SwiftWeekly/swiftweekly.github.io #89" do
  def reproduce_pull_request_89(dir, spec_root)
    Dir.chdir dir do
      # create SwiftWeekly/swiftweekly.github.io master
      `git init`
      `echo "swiftweekly.github.io" > README.md`
      `mkdir _drafts _posts`
      `git add .`
      `git commit -m "Init master"`

      # Create 2016-09-15-issue-38.md
      `git checkout -b jp-issue-38 --quiet`
      IO.write("_drafts/2016-09-15-issue-38.md", "init 2016-09-15-issue-38.md")
      `git add _drafts/2016-09-15-issue-38.md`
      `git commit -m "flesh out issue 38 based on suggestions from #75, #79"`

      # Update 2016-09-15-issue-38.md
      IO.write("_drafts/2016-09-15-issue-38.md", "update 2016-09-15-issue-38.md")
      `git add _drafts/2016-09-15-issue-38.md`
      `git commit -m "address first round of review feedback"`

      # Move 2016-09-15-issue-38.md from _drafts/ to _posts/
      `git mv _drafts/2016-09-15-issue-38.md _posts/2016-09-15-issue-38.md`
      `git add .`
      `git commit -m "move issue 38 to _posts"`
    end
  end

  it "handles moved file correctly" do
    require "danger/core_ext/file_list"
    require "danger/scm_source/git_repo"

    spec_root = Dir.pwd

    Dir.mktmpdir do |dir|
      Dir.chdir dir do
        reproduce_pull_request_89(dir, spec_root)

        git = Danger::GitRepo.new
        git.diff_for_folder(".", from: "master", to: "jp-issue-38")

        added_files = Danger::FileList.new(git.diff.select { |diff| diff.type == "new" }.map(&:path))

        expect(added_files).to eq ["_posts/2016-09-15-issue-38.md"]
      end
    end
  end
end

I think we missed to do git.diff_for_folder(".", from: "master", to: "jp-issue-38") somewhere.


BT HI KIT (Health Indicators) Release 23.12 Operations View Acceptance Criteria

Release 23.12 KIT Operations View

[ ] Quick Setup Guide and Deployment Scripts in Repository

Documentation for the operations view must be available in Eclipse Tractus-X as MD files.
A reference implementation must be deployable via versioned and released HelmCharts with ArgoCD and as local deployment. In addition, a quick setup guide must be provided.

Quick Setup Guides
Deployment Scripts (e.g. local, helm charts, terraform)

Best Practice:

eclipse tractusx-docs-artefacts
How-to-create-a-KIT-website

Artifact Repository:

eclipse-tractusx

Contacts:

Responsible: PO/BO (from relevant Domain)
Responsible for Process: PO / BO (from relevant Domain)
Consult: KIT-CONTACT1, KIT-CONTACT2 + System Team
Review by: PCA/BDA

In Release 24.03 only a preview of the BT HI Kit without a "Operation View" will be published.

version 0.0.1 -> Preview (N/A)


Nav 183 make viewer app responsive

Hacky workarounds, but should do the job for this project.

Thanks @clukas1, nice work!
Unfortunately, sometimes the map doesn't display, such as when routing from Wädenswil to Gurten Kulm:

And the map:

Other routes work fine. Maybe it has something to do with connections that consist of many legs?

Another example:

Thanks @clukas1, nice work!
Unfortunately, sometimes the map doesn't display, such as when routing from Wädenswil to Gurten Kulm:
Other routes work fine. Maybe it has something to do with connections that consist of many legs?

Thanks for finding this issue, this was due to a syntax error caused by my 6' Walk strings, which resulted in bindPopup('6' Walk'); --> syntax error.
fixed in 4279c84

Thanks @clukas1!
Now it works for most cases, but there are still some cases where the map fails to load:

Connection:

Map:

@munterfi thanks for the comprehensive testing.
Looks like it was the same issue ' (single quotes) in text. This time french name Flon, pl. de l'Europe. I've now added an escape string method to hopefully prevent all cases now. (55e526c)

Thanks @clukas1, looks good to merge.


[BUG] CSS background-image property is not rendering remote URL

Checklist before submitting an issue

[X] I have searched through the existing closed and open issues for eww and made sure this is not a duplicate
[X] I have specifically verified that this bug is not a common user error
[X] I am providing as much relevant information as I am able to in this bug report (Minimal config to reproduce the issue for example, if applicable)

Description of the bug
I'm trying to render a background image with a remote source in a box widget. I followed this: https://github.com/elkowar/eww/issues/487 and I only get results if I use a local image. If I specify a URL, nothing is rendered.
Reproducing the issue
  (box
      :style "background-image: url('${img_var}');"
      (label :text "My text here)
  )

If img_var is a local path, the image is rendered. If it's a URL, nothing is rendered.
Expected behaviour
I expect the image to be rendered irrespective of the path being local or remote
Additional context
No response

Seems to work perfectly fine for me. Please make sure that your URL is actually valid and the image is reachable.
I'll close this for now as I can't reproduce, but If you have a minimal config example that demonstrates the issue reproducably, I'll be happy to look into it again!

Please try this config
(defvar img_var "https://images.unsplash.com/photo-1507315991476-aece7be22af9?ixlib=rb-4.0.3&ixid=MnwxMjA3fDB8MHxwcm9maWxlLXBhZ2V8Nnx8fGVufDB8fHx8&auto=format&fit=crop&w=500&q=60")

(defwindow bar
  :monitor 0
  :windowtype "dock"
  :geometry (geometry :x "0%"
                      :y "0%"
                      :width "90%"
                      :height "20%"
                      :anchor "top center")
  :reserve (struts :side "top" :distance "4%")
  (box
      :style "background-image: url('${img_var}'); background-size: cover;"
  )
)

That's what I get with the config.
In my usecase, i'm trying to use album covers from spotify via playerctl. I tried checking with other players and I can get the thumbnail if i'm playing a video from youtube in firefox. I'm not sure what's happening. Seems like it happens by chance. I haven't managed to get any spotify image working though.

It works for firefox youtube videos, because firefox downloads the thumbnails into a local cache folder:


Swap scss-lint for stylelint

scss-lint has been deprecated.

The test failure is unrelated to these changes; this is fine to be merged without that getting resolved.


enable queues of size=0 which only do callbacks

Add support for Queues used by depthai-core to have size=0 and therefore only call callbacks.

minor optimize LockingQueue
fixes luxonis/depthai-core#366

I've been using this for about a week; size=0 works well in my app.
Passes test+examples, though they don't actively test size=0.

I force pushed the requested changes. Would you start CI?


Dropdown | Keyboard controls aren't correct

Current: Currently, pressing tab focuses the dropdown, then pressing tab again opens the options, and then again steps through the options, then leaves the dropdown without closing it.
Expected: Tabbing should continue focusing the dropdown, but pressing it again should move to the next form control. Only pressing up/down/enter should open the dropdown, and only up/down should move through the option list. Once the focus has left the dropdown, it should close automatically.

@ericbaumann  I don't have permission to assign to myself. Can you assign this task to me, please?

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Unable to donate via Ko Fi

Not an issue with MonoSketch itself (great app by the way) but I just tried to make a donation via Ko Fi but I get the error "Your account cannot currently make live charges." which after a quick search I think may be your Stripe payment details are set up incorrectly?
This is a similar issue I found https://github.com/jeffshee/hidamari/issues/60
All the best,
Ross

Thank you so much for your support. I really appreciate that!
Let me see how to fix this issue.

Sorry for keeping this issue so long, the KoFi is working now. I just tested

It's a little bit weird to donate myself 😄
Thank you very much for your support.
Have a nice day to you!


Divide by zero when path included in WHERE clause

Hello. Thanks for maintaining this project. It's remarkably useful.
I've discovered an issue when attempting to use the path "column" in a where clause that causes a divide by zero thread panic.
I was able to re-produce this issue on both a CentOS 7 machine, as well as Pop_OS! 20.04.
Query:
RUST_BACKTRACE=1 fselect name, size where path like '\*kccg/react-ui/\*.js'

Backtrace:
thread 'main' panicked at 'attempt to divide by zero', /home/garrettmills/.cargo/registry/src/github.com-1ecc6299db9ec823/fselect-0.6.10/src/operators.rs:92:37
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:78
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:59
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1076
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1537
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:62
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:198
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:217
  10: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:526
  11: rust_begin_unwind
             at src/libstd/panicking.rs:437
  12: core::panicking::panic_fmt
             at src/libcore/panicking.rs:85
  13: core::panicking::panic
             at src/libcore/panicking.rs:50
  14: fselect::operators::ArithmeticOp::calc
  15: fselect::searcher::Searcher::get_column_expr_value
  16: fselect::searcher::Searcher::get_column_expr_value
  17: fselect::searcher::Searcher::get_column_expr_value
  18: fselect::searcher::Searcher::conforms
  19: fselect::searcher::Searcher::check_file
  20: fselect::searcher::Searcher::visit_dir
  21: fselect::searcher::Searcher::list_search_results
  22: fselect::main
  23: std::rt::lang_start::{{closure}}
  24: std::rt::lang_start_internal::{{closure}}
             at src/libstd/rt.rs:52
  25: std::panicking::try::do_call
             at src/libstd/panicking.rs:348
  26: std::panicking::try
             at src/libstd/panicking.rs:325
  27: std::panic::catch_unwind
             at src/libstd/panic.rs:394
  28: std::rt::lang_start_internal
             at src/libstd/rt.rs:51
  29: main
  30: __libc_start_main
  31: _start
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Other queries work fine (using the name, size, &c "columns" in a WHERE clause). Appears to be an issue with path in particular.

I'm using fselect version 0.6.10, installed via cargo.

Thank you very much for reporting the issue! It really helped me to adjust some heuristics in the lexer to make such cases work, not crash. Master branch has been updated, so this fix will make it to 0.7.0 release soon.
After the update, I'd like to suggest using operator eq or simply =, and removing unneeded escape backslashes, as they don't escape here anything actually, but frustrate fselect, e.g.:
fselect name, size where path eq '*kccg/react-ui/*.js'
Operator like works as in SQL here, so it expects its own glob style:
fselect name, size where path like '%kccg/react-ui/%.js'


ci: testing deployment preview

Dummy change to test and experiment with the deployment preview
@kellnerd feel free to try it out too 😄

/deploy-preview

/deploy-preview please. And don't forget the emojis!


External payload storage is not reducing the workflow & task size

Describe the bug
I recently migrated from 2.x version and bumped into this bug on 3.6 (and even in the main branch). I had to implement a workaround to make this functionality work for our product.
When the payload size crosses the threshold value, the affected task and workflow input/output data are uploaded successfully to the S3 bucket. But when the object is converted to JSON to store in the DB, that big JSON is still there. It results in data crossing the MySQL threshold to store. Even though we are using MySQL, but this issue is valid for all data stores.
I believe the code issue is below in both TaskModel and WorkflowModel classes. As the inputPayload is populated with the large data, inputData field returned after Jackson's Object to JSON conversion will still have the data.
public Map<String, Object> getInputData() {
        return externalInputPayloadStoragePath != null ? inputPayload : inputData;
    }

    public Map<String, Object> getOutputData() {
        return externalOutputPayloadStoragePath != null ? outputPayload : outputData;
    }

Details
Conductor version: 3.6
Persistence implementation: MySQL
To Reproduce
Steps to reproduce the behavior:

Have a workflow with large data set. Even a single node with large input can be used to reproduce
Run the flow
The data is uploaded to S3 bucket. externalInputPayloadStoragePath, externalOutputPayloadStoragePath for TaskModel and WorkflowModel populates correctly.
The database save will either fail (depending on the size of the large data) or it will succeed. But the JSON will still be big. That is the large fields will still be in the object.

Expected behavior
The data should store in the DB after setting the large data set the field to an empty map.
Additional context
Add any other context about the problem here.

@devinderpal Thanks for reporting this. We are working on a fix. It should be out in the next version.

Great!
Sent from my iPhone

On Apr 11, 2022, at 6:54 PM, Aravindan Ramkumar @.***> wrote:

@devinderpal Thanks for reporting this. We are working on a fix. It should be out in the next version.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.

v3.7.2 contains the fix.


Font size doesn't affect forward/back arrows nor command-palette

For the back/forward arrows, QToolButton::setIconSize() can set the size of it. When QToolButton is displaying an arrow, the font size does not affect the size of the arrow.


[Feature Request] Check if hoster is supported without doing any requests, list regex

[v] I'm reporting a feature request
[v] I've verified that I'm running yt-dlp version 2021.08.02
[v] I've searched the bugtracker for similar feature requests including closed ones

I just found yt-dlp and I'm very happy to see that some of my feature requests (like info if a video is embeddable) I did at original youtube-dl already got merged in this project which got basically ignored by them.
Another one I though about a while ago is to check if a URL is supported by the program without doing an (unnecessary) request to the hoster, or an option to list all regex to do the check by a wrapper. The way I'm doing it for now (I'm new to python)
I would like to see something like this implemented in yt-dlp.

https://github.com/ytdl-org/youtube-dl#how-can-i-detect-whether-a-given-url-is-supported-by-youtube-dl

That does a request though. So I'm basically requesting to include the regex in --list-extractors.

It is not possible to detect whether a URL is supported or not. That's because youtube-dl contains a generic extractor which matches all URLs. You may be tempted to disable, exclude, or remove the generic extractor, but the generic extractor not only allows users to extract videos from lots of websites that embed a video from another service, but may also be used to extract video from a service that it's hosting itself. Therefore, we neither recommend nor support disabling, excluding, or removing the generic extractor.

You may think that you can just skip the GenericIE, but it does more work than what u'd think such as fixing URLs, handling redirects, finding html5 videos, downloading direct manifests etc
Also, just checking VALID_URL is not always sufficient to check if a url is supported. If you are sure you want to skip Generic, here's how u'd check support
from yt_dlp.extractors import gen_extractor_classes

for ie in gen_extractor_classes():
    ie_key = ie.ie_key()
    if ie_key == 'Generic':
        continue
    if not ie.suitable(url):
        continue
    if not ie.working():
       print(f'Supported by {ie_key}, but marked as broken')
    else:
        print(f'Supported by {ie_key}')
    break
else:
    print('Unsupported')

Thanks, but I just realized that's not even what I wanted.

Same thing. Once you have an ie_key that is suitable, you can just check it against your whitelist

hey @kr4ssi, you didnt reply
If this does solve your issue, please close. Otherwise let me know why it doesn't

Closed due to inactivity