Include compiler crashes in ICE defintion

This matches the definition used in glacier, which includes exit status
101 without an accompanying diagnostic (such as rust-lang/rust#21599), and when
rustc is killed by a signal (rust-lang/rust#13368)
This also means no processing modes are capturing stdio, but I didn't
remove it as it may be desired for the regex features discussed in #53

I don't think this PR was quite right; it treats error code 101 as a unique identifier for ICE's, but even normal static errors from rustc will produce that same error code, I believe.
This mistake ends up breaking certain uses of --regress=ice, such as one I'm trying to include in my test suite as part of PR #88.
I'm going to revert this PR as part of PR #88 and open an issue to re-add its effects in a manner compatible with --regress=ice

I do see that Glacier is using this same logic (link taken from commit). So either I'm wrong or glacier is wrong. Hmm.

Ah, Glacier invokes rustc directly. So maybe Glacier's logic is correct for direct rustc invocations, but not appropriate for cargo invocations?

Ah yeah sorry I didn't test cargo directly, I was using it with --script rustc -- file and assumed it would be the same


Add Flow declarations

It would be great to have Flow declarations for all the Ramda functions.
http://flowtype.org
Example
declare module R {
  declare function add(a: number, b: number): number;
}

I'm not sure how this would work with currying thou.
Maybe something like this?
declare module R {
  declare function add(a: number, b: number): number;
  declare function add(a: number): (b: number) => number;
}

Currying is a challange in Typescript and probably Flow too. I don't know much about Flow, but you might take a look at this PR of the typescipt-ramda.

If that sample format is representative, and it could be done in an external file, not through internal annotation of the code, I don't have any objections, if someone wants to take it on.  My concern is how it would be kept in sync.  Do you think it could be derived from our sigs?

Yes you can have an external declarations file for Flow.
It would be also good to get the TypeScript definition added to Ramda.
https://github.com/donnut/typescript-ramda
Keeping the two definition files in sync with the code would take some effort.
Deriving from the JSDoc would be the ideal solution. For add it should be pretty simple to create the TypeScript and Flow versions.
/**
* @param {Number} a
* @param {Number} b
* @return {Number}
*/
function add(a, b)

It would be also good to get the TypeScript definition added to Ramda.

Typescript definitions are stored in Definitely Typed, but they are not finished yet. One of the reasons is that Ramda's API is not stable yet.

Deriving from the JSDoc would be the ideal solution.

I've thought of that too, but I don't think it will be easy to build such a parser. JSDoc to Typescript is not always an one-on-one transformation. On the other hand, if you can solve 80% it would save a lot of work.
Once the API is 'frozen' I don't think it is not that much work to maintain it -- you only have to type the new functions.

I will see if I can get a proof of concept working with something like https://github.com/Constellation/doctrine

@DaleJefferson doctrine looks interesting. It would be awesome if that would work. The type definition of Flow and Typescript are quite similar (I just noticed looking at the documentation).

I tried doctrine and you don't seem to get much useful data
{ description: 'Adds two numbers. Equivalent to "a + b" but curried.',
  tags:
   [ { title: 'func', description: null, name: null },
     { title: 'memberOf', description: 'R' },
     { title: 'category', description: 'Math' },
     { title: 'sig', description: 'Number -> Number -> Number' },
     { title: 'param', description: null, type: [Object], name: 'a' },
     { title: 'param', description: null, type: [Object], name: 'b' },
     { title: 'return', description: null, type: [Object] },
     { title: 'see', description: 'R.subtract' },
     { title: 'example',
       description: 'R.add(2, 3);       //=>  5\n     R.add(7)(10);      //=> 17\n/\nfunction add(a, b) { return a + b; };' } ] }

/**
 * Adds two numbers. Equivalent to `a + b` but curried.
 *
 * @func
 * @memberOf R
 * @category Math
 * @sig Number -> Number -> Number
 * @param {Number} a
 * @param {Number} b
 * @return {Number}
 * @see R.subtract
 * @example
 *
 *      R.add(2, 3);       //=>  5
 *      R.add(7)(10);      //=> 17
 */

Maybe it is enough. The text above doesn't show the type of the params, but it is probably hidden in [Object]. Or we can use the signature:
Number -> Number -> Number
All (?) Ramda functions are curried so we can split this signature in:
Number -> (Number -> Number) and Number -> Number -> Number
Using the names of the params this can be translated into
add(a: number): (b: number) => number; and add(a: number, b: number): number;
It gets a bit more difficult with concat. This function concatinates two list of an arbitrary but equal type: [a] -> [a] -> [a]. We can use generics to describe this:
concat<T>(list1: T[], list2: T[]): T[];
concat<T>(list1: T[]): (list2: T[]) => T[];

A string is thought of a list of characters, but because javascript doesn't have that concept we need to repeat the type definition for string:
concat(list1: string, list2: string): string;
concat(list1: string): (list2: string) => string;

This example shows what I meant with automating the type definition generation for 80%. There will always remain the necessity for manual tuning, but then again 80% is a nice big number ;-)

This is what I have so far. (i'm still learning functional programming)
I had to add the function name at the top of the JSDoc
var doctrine = require("doctrine")
var R = require("ramda")

var parsed = doctrine.parse(`
 /**
 * Adds two numbers. Equivalent to "a + b" but curried.
 *
 * @func add
 * @memberOf R
 * @category Math
 * @sig Number -> Number -> Number
 * @param {Number} a
 * @param {Number} b
 * @return {Number}
 * @see R.subtract
 * @example
 *
 *      R.add(2, 3);       //=>  5
 *      R.add(7)(10);      //=> 17
 */
function add(a, b) { return a + b; };
`, { unwrap: true });

function paramMap(paramTag) {
    return {
        name: paramTag.name,
        type: R.toLower(paramTag.type.name)
    }
}

var getTags = R.prop('tags')
var propEqTitle = R.propEq('title')
var findFunctionName = R.compose(R.prop('name'), R.find(propEqTitle('func')), getTags)
var findParams = R.compose(R.map(paramMap), R.filter(propEqTitle('param')), getTags)
var findReturn = R.compose(R.toLower, R.prop('name'), R.prop('type'), R.find(propEqTitle('return')), getTags)

var name = findFunctionName(parsed)
var params = findParams(parsed)
var returnType = findReturn(parsed)

var output = `
declare module R {
  declare function ${name}(${params[0].name}: ${params[0].type}, ${params[1].name}: ${params[1].type}): ${returnType};
}
`

console.log(output)

Output
declare module R {
  declare function add(a: number, b: number): number;
}

Obviously i've hard coded things and not done the currying.

I see what you mean with concat, but as you say anything would be useful.
function concat(list1: any, list2: any): any;

JSDoc supports union types so we could write the doc as
@param {(Array|string)} list1 The first list to merge.

And the generated code would be
concat<T>(list1: T[] | string, list2: T[] | string): T[] | string;

Having the array and string versions separately would offer better accuracy but I doubt we would be able to express in JSDoc that if if list1 is a string, list 2 and the return value should be a string.
Flow and TypeScript support union types.

R.concat does work with mixed types
R.concat("string", ["string", 1, true]) // ["s", "t", "r", "i", "n", "g", "string", 1, true]

So I guess we don't want to use generics, maybe this is good enough.
concat(list1: Array<any> | string, list2: Array<any> | string): Array<any> | string;

R.concat does work with mixed types
R.concat("string", ["string", 1, true]) // ["s", "t", "r", "i", "n", "g", "string", 1, true]

This is an accident of implementation, and not something we'd want to document, I believe.

The string thing is a bit strange, I wonder how many people are relying on such accidents?
For a while I was doing.
R.join("", R.prepend("Hello ", "World")) // "Hello World"
``

I expected prepend to work on strings but it spits out an array and I worked out I could put it back together again with joint to get the desired outcome. I now use concat.

Hmm, i'm not sure that's right either
R.concat(1, "2") // TypeError: can't concat number
R.concat("1", 2) // "12"
R.concat("1", ["2"]) // ["1", "2"]
R.concat({a: 1}, "2") // TypeError: can't concat object
R.concat({a: 1}, ["2"]) // ["2"]

Is there a issue open for concat's accidents?

Is there a issue open for concat's accidents?

See #1246, #1248, and #1272. There are only two supported signatures:
R.concat :: [a] -> [a] -> [a]
R.concat :: String -> String -> String

The function's behaviour is otherwise left undefined.

@DaleJefferson I would stick to the API documentation. The typing is part of the API and Typescript/Flow a developer aid to use Ramda as intended, even if javascript is allowing a sloppier typing.

I think this is more accurate.

concat(list1: Array<any> | string, list2: Array<any> | string): Array<any> | string;
concat(list1: Array<any> | string): (list2: Array<any> | string) => Array<any> | string;

Yes, but in conflict with the API

@donnut Agreed, I was just poking at concat to see what it did

#1275 discusses this issue too

I am curious how currying will work. See discussion here for example: https://github.com/facebook/flow/issues/172

closed for inactivity

See here https://github.com/flowtype/flow-typed

@DaleJefferson Cool. Should we all just start contributing to this repo, rather than ramda itself, then?

They are still setting up the project but I plan to contribute to that repo.

How's that coming along? I'm pretty excited to see some progress has been made already.

It seems like no progress. I haven't found definitions for Ramda in flow-typed

Yes you are right. I failed to find it first time. https://github.com/flowtype/flow-typed/tree/master/definitions/npm/ramda_v0.x.x


Remove use of IPv[4|6]BUF macro from net/slip

Summary
The latest version of netdev.h's IPv4BUF and IPv6BUF work only for net device drivers that use IOBs.  The SLIP net device driver is still a legacy one, using the netdev's d_buf pointer.  Thus, those macros can not be used until slip.c has been modernized.
Also silence compiler warnings about potentially truncated snprintf output.
Impact
Makes SLIP work again.
Testing
Tested with my custom STM32U5 based board.

let use #8344 and close this pr.


CMake: doesn't install anything if -DTWEEDLEDUM_PYBINDS=OFF

Nothing is installed if the CMake flag -DTWEEDLEDUM_PYBINDS=OFF. (i.e. make install does nothing after configuring & building).
I'm not the most well-versed in CMake/C++ library building, but it seems to me that at least the *.so should be installed if the python bindings are not installed.
Relevant code:
https://github.com/boschmitt/tweedledum/blob/1c331a076fa137295193a10e0ed664603ae80c21/CMakeLists.txt#L44-L59

This is due to the fact that, originally, tweedledum was a header-only C++ library. Now, this is not the case anymore; Mainly because to do python bindings I needed a shared library.
I will have a look into this and find the best way to make it available as a C++ library.

Closing b/c after the update to v1.1.0 the *.h files and libtweedledum.a are installed to the output.


Error: Failed to read patrol version. Make sure you have patrol dependency in your pubspec.yaml file

Steps to reproduce

Add latest dependencies (patrol and patrol_filders) in pubspec.yaml
Complete Android and iOS setup
Create folder integration_test
Create file app_test.dart inside integration_test
Create a basic UI test using patrol
Run patrol test -t integration_test/app_test.dart

Actual results
Getting error Error: Failed to read patrol version. Make sure you have patrol dependency in your pubspec.yaml file
Logs

Logs
Unhandled exception:
Error: Failed to read patrol version. Make sure you have patrol dependency in your pubspec.yaml file
#0      throwToolExit (package:patrol_cli/src/base/exceptions.dart:7:3)
#1      CompatibilityChecker.checkVersionsCompatibility.<anonymous closure>.<anonymous closure> (package:patrol_cli/src/compatibility_checker.dart:64:13)
#2      _RootZone.runGuarded (dart:async/zone.dart:1582:10)
#3      _BufferingStreamSubscription._sendDone.sendDone (dart:async/stream_impl.dart:392:13)
#4      _BufferingStreamSubscription._sendDone (dart:async/stream_impl.dart:402:7)
#5      _BufferingStreamSubscription._close (dart:async/stream_impl.dart:291:7)
#6      _SinkTransformerStreamSubscription._close (dart:async/stream_transformers.dart:87:11)
#7      _EventSinkWrapper.close (dart:async/stream_transformers.dart:21:11)
#8      _StringAdapterSink.close (dart:convert/string_conversion.dart:241:11)
#9      _LineSplitterSink.close (dart:convert/line_splitter.dart:141:11)
#10     _SinkTransformerStreamSubscription._handleDone (dart:async/stream_transformers.dart:132:24)
#11     _RootZone.runGuarded (dart:async/zone.dart:1582:10)
#12     _BufferingStreamSubscription._sendDone.sendDone (dart:async/stream_impl.dart:392:13)
#13     _BufferingStreamSubscription._sendDone (dart:async/stream_impl.dart:402:7)
#14     _BufferingStreamSubscription._close (dart:async/stream_impl.dart:291:7)
#15     _SinkTransformerStreamSubscription._close (dart:async/stream_transformers.dart:87:11)
#16     _EventSinkWrapper.close (dart:async/stream_transformers.dart:21:11)
#17     _StringAdapterSink.close (dart:convert/string_conversion.dart:241:11)
#18     _Utf8ConversionSink.close (dart:convert/string_conversion.dart:295:20)
#19     _ConverterStreamEventSink.close (dart:convert/chunked_conversion.dart:78:18)
#20     _SinkTransformerStreamSubscription._handleDone (dart:async/stream_transformers.dart:132:24)
#21     _RootZone.runGuarded (dart:async/zone.dart:1582:10)
#22     _BufferingStreamSubscription._sendDone.sendDone (dart:async/stream_impl.dart:392:13)
#23     _BufferingStreamSubscription._sendDone (dart:async/stream_impl.dart:402:7)
#24     _BufferingStreamSubscription._close (dart:async/stream_impl.dart:291:7)
#25     _SyncStreamControllerDispatch._sendDone (dart:async/stream_controller.dart:792:19)
#26     _StreamController._closeUnchecked (dart:async/stream_controller.dart:647:7)
#27     _StreamController.close (dart:async/stream_controller.dart:640:5)
#28     _Socket._onData (dart:io-patch/socket_patch.dart:2454:21)
#29     _RootZone.runUnaryGuarded (dart:async/zone.dart:1594:10)
#30     _BufferingStreamSubscription._sendData (dart:async/stream_impl.dart:339:11)
#31     _BufferingStreamSubscription._add (dart:async/stream_impl.dart:271:7)
#32     _SyncStreamControllerDispatch._sendData (dart:async/stream_controller.dart:784:19)
#33     _StreamController._add (dart:async/stream_controller.dart:658:7)
#34     _StreamController.add (dart:async/stream_controller.dart:606:5)
#35     new _RawSocket.<anonymous closure> (dart:io-patch/socket_patch.dart:1943:35)
#36     _NativeSocket.issueReadEvent.issue (dart:io-patch/socket_patch.dart:1372:18)
#37     _microtaskLoop (dart:async/schedule_microtask.dart:40:21)
#38     _startMicrotaskLoop (dart:async/schedule_microtask.dart:49:5)
#39     _runPendingImmediateCallback (dart:isolate-patch/isolate_patch.dart:118:13)
#40     _RawReceivePort._handleMessage (dart:isolate-patch/isolate_patch.dart:185:5)

Patrol version
patrol: ^3.5.2
patrol_finders: ^2.0.2
Patrol Doctor output

Patrol Doctor output
Patrol doctor:
Patrol CLI version: 2.6.4
Android:
• Program adb found in /Users/shrijanregmi/Library/Android/sdk/platform-tools//adb
• Env var $ANDROID_HOME set to /Users/shrijanregmi/Library/Android/sdk/:/Users/shrijanregmi/Projects/Flutter/sdk/bin/:/Users/shrijanregmi/fvm/versions/3.13.6/bin/:/Library/Frameworks/Python.framework/Versions/3.12/bin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/Library/Apple/usr/bin:/Users/shrijanregmi/fvm/versions/3.13.6/bin/:/Users/shrijanregmi/google-cloud-sdk/bin:/Users/shrijanregmi/.nvm/versions/node/v18.16.1/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/Users/shrijanregmi/Library/Android/sdk/platform-tools/:/Users/shrijanregmi/Projects/Flutter/sdk/bin/:/Library/Frameworks/Python.framework/Versions/3.12/bin:/Users/shrijanregmi/.pub-cache/bin
iOS / macOS:
• Program xcodebuild found in /usr/bin/xcodebuild
• Program ideviceinstaller found in /opt/homebrew/bin/ideviceinstaller

Flutter Doctor output

Flutter Doctor output
Doctor summary (to see all details, run flutter doctor -v):
[!] Flutter (Channel stable, 3.16.0, on macOS 14.2.1 23C71 darwin-arm64, locale en-NP)
    ! Warning: `flutter` on your path resolves to /Users/shrijanregmi/Projects/Flutter/sdk/bin/flutter, which is not inside your current Flutter SDK checkout at /Users/shrijanregmi/fvm/versions/3.16.0. Consider adding /Users/shrijanregmi/fvm/versions/3.16.0/bin to the front of your path.
    ! Warning: `dart` on your path resolves to /opt/homebrew/Cellar/dart/3.2.6/libexec/bin/dart, which is not inside your current Flutter SDK checkout at /Users/shrijanregmi/fvm/versions/3.16.0. Consider adding /Users/shrijanregmi/fvm/versions/3.16.0/bin to the front of your path.
[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.2)
[✓] Xcode - develop for iOS and macOS (Xcode 15.2)
[✓] Chrome - develop for the web
[✓] Android Studio (version 2022.2)
[✓] VS Code (version 1.86.2)
[✓] Connected device (4 available)
    ! Error: Browsing on the local area network for Shrijan’s iPhone . Ensure the device is unlocked and attached with a cable or associated with the same local area network as this Mac.
      The device must be opted into Developer Mode to connect wirelessly. (code -27)
[✓] Network resources

! Doctor found issues in 1 category.

Hi, could you confirm that you're running patrol test -t integration_test/app_test.dart command inside flutter root directory?

Yes, I can confirm that I am inside flutter root directory.

Hi @shrijanRegmi. Can you please run the flutter --suppress-analytics --no-version-check pub deps --style=list command in your project root directory and paste here the output of this command?


Using the pre-trained models

Hello,
I just wanted to ask if you cant provide some instructions on how to use the pre-trained models on new videos to extract the action units.
I would like to feed in videos and output the action units. do you i need to retrain the model. what kind of format should the model be fed? Is there already a script you used to input video and output the action units?

bump,i knew there is a photo detection demo, but I also want to know how to feed videos.
I look forward to hearing any answer

I'm interested with Videos too

You might want to checkout my repo, I have implemented ME-GraphAU on a video in my project. No changes been made just minor refactor and uses their model to predict the frame when reading the video.
https://github.com/Andreas-UI/ME-GraphAU-Video

Appreciate brother, I’m going to test it soonOn May 2, 2024, at 8:52 PM, Andreas Susanto @.***> wrote:
You might want to checkout my repo, I have implemented ME-GraphAU on a video in my project. No changes been made just minor refactor and uses their model to predict the frame when reading the video.
https://github.com/Andreas-UI/ME-GraphAU-Video
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>


Upgrade the http transport version

Purpose

Describe the problems, issues, or needs driving this feature/fix and include links to related issues.

Fixes #
Approach

Describe how you are implementing the solutions along with the design details.

Samples

Provide high-level details about the samples related to this feature.

Remarks

List any other known issues, related PRs, TODO items, or any other notes related to the PR.

Check List

[ ] Read the Contributing Guide
[ ] Required Balo version update
[ ] Updated Change Log
[ ] Checked Tooling Support (#)
[ ] Added necessary tests

[ ] Unit Tests
[ ] Spec Conformance Tests
[ ] Integration Tests
[ ] Ballerina By Example Tests

[ ] Increased Test Coverage
[ ] Added necessary documentation

[ ] API documentation
[ ] Module documentation in Module.md files
[ ] Ballerina By Examples

Codecov Report

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

@@            Coverage Diff             @@
##           master   #18437      +/-   ##
==========================================
- Coverage   19.91%   15.15%   -4.77%
==========================================
  Files          53       48       -5
  Lines        1376     1254     -122
  Branches      218      197      -21
==========================================
- Hits          274      190      -84
+ Misses       1088     1050      -38
  Partials       14       14

Impacted Files
Coverage Δ

composer/packages/tracing/src/ToolBar.tsx

composer/packages/tracing/src/TraceList.tsx

composer/packages/tracing/src/DetailView.tsx

composer/packages/tracing/src/TraceLogs.tsx

composer/packages/tracing/src/index.ts

Continue to review full report at Codecov.

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


AndroidStudio: Required plugin "ByteCodeViewer" not installed

Android Studio 2.3.3.
I installed the plugin via the Plugin Manager and after a reboot I get the error
Plugin Error
Problems found loading plugins:
Plugin "Bytecode Editor" was not loaded: required plugin "ByteCodeViewer" not installed.

Disable Bytecode Editor
Open plugin manager

The plugin manager only shows the "jclasslib Bytecode viewer" which is not the one needed because the error is still there after I installed this plugin

I'm seeing the same with Android Studio 3.0 beta7

I'm not sure about android studio.  Sorry for inconvenience. This plugin was just a simple thing I did very quickly, so it's crappy. P/Rs are welcomed.

So, I guess it's jetbrains issue bcs I have both dependencies declared explicitly:
    <depends>com.intellij.modules.java</depends>
    <depends>ByteCodeViewer</depends>

If I'm doing smth wrong - please let me know.

Byte Code Viewer is a plugin bundled with IntelliJ IDEA (at least), maybe it is not bundled with Android Studio and is not available through plugin manager.

Guys, guys, sorry about that, I have no capacity ATM to support this plugin.


KAFKA-15454: Add support for OffsetCommit version 9 in admin client

This PR adds support for OffsetCommit version 9 in the admin client. It mainly allows handling 2 new error codes STALE_MEMBER_EPOCH and GROUP_ID_NOT_FOUND  introduced as part of KIP-848.

@vamossagar12 Thanks for the PR. We actually only added GROUP_ID_NOT_FOUND and STALE_MEMBER_EPOCH in version 9 at the moment.

Thanks David. Sorry, I looked at the KIP and not the response schema file. I have updated the PR.


Linux analyzer_benchmark failed: could not resolve packages

This failure happens when running in staging pool.
Latest failed example build: https://ci.chromium.org/p/flutter/builders/prod/Linux analyzer_benchmark/9
 [analyzer_benchmark] [STDOUT] Executing: /opt/s/w/ir/k/flutter/bin/cache/dart-sdk/bin/dart --disable-dart-dev dev/tools/mega_gallery.dart --out=/opt/s/w/ir/tmp/t/mega_gallery in /opt/s/w/ir/k/flutter
 [analyzer_benchmark] [STDOUT] stderr: dev/tools/mega_gallery.dart:166:3: Warning: Operand of null-aware operation '??=' has type 'SourceStats' which excludes null.
 [analyzer_benchmark] [STDOUT] stderr:  - 'SourceStats' is from 'dev/tools/mega_gallery.dart'.
 [analyzer_benchmark] [STDOUT] stderr:   stats ??= SourceStats();
 [analyzer_benchmark] [STDOUT] stderr:   ^
 [analyzer_benchmark] [STDOUT] stderr: Error: Could not resolve the package 'args' in 'package:args/args.dart'.
 [analyzer_benchmark] [STDOUT] stderr: Error: Could not resolve the package 'path' in 'package:path/path.dart'.
 [analyzer_benchmark] [STDOUT] stderr: dev/tools/mega_gallery.dart:9:8: Error: Not found: 'package:args/args.dart'
 [analyzer_benchmark] [STDOUT] stderr: import 'package:args/args.dart';
 [analyzer_benchmark] [STDOUT] stderr:        ^
 [analyzer_benchmark] [STDOUT] stderr: dev/tools/mega_gallery.dart:10:8: Error: Not found: 'package:path/path.dart'
 [analyzer_benchmark] [STDOUT] stderr: import 'package:path/path.dart' as path;
 [analyzer_benchmark] [STDOUT] stderr:        ^

I'll take this one, in fact I already have a fix for it

fixed in https://flutter-review.googlesource.com/c/recipes/+/8900


Run browser tests on forked PRs by a dedicated label

Description of the Change
It is the only way I found to run browser tests on forked PR.
After reviewing code of a forked PR, maintainers can attach a run-browser-test label.
Maintainers should check there is no malicious code to steal our secrets or do something bad on our repository.
This Browser Tests workflow will run based on forked PRs with writing repo and access secrets permissions. So, it can be  dangerous if the forked PR has malicious code.
I've tested pull_request_target event.

When users open a pull request, push, pull_reqeust and pull_request_target  will be run automatically. But pull_request_target: types: [labeled](in this case Browser Tests) will not be run because labeled type.

If maintainers attach a label except run-browser-test label, Browser Tests workflow will be triggered, but it skipped because the label is not run-browser-test. In the above screenshot, pull request safe run workflow is pull_request_target workflow with labeled type.

When maintainers attach the run-browser-test label, Browser Tests workflow will be triggered. In above screenshot, I tested it with safe-to-run label.

After that, when author of the forked PR pushed new commits, only default workflows will. be run.
That means maintainers should remove and re-attache run-browser-test label to run Browser Tests again.
And when the forked PR already has run-browser-test label, Browser Tests workflow will be triggered if maintainers attach a new label except run-browser-test label. We have to be careful with this.
Alternate Designs
We can use workflow_dispatch event. workflow_dispatch is a workflow that we should trigger it manually with PR number.
I think there are some cons.

Process is not convenient. maintainers enter PR number and trigger the workflow manually.
It couldn't be integrated with PR. So, we cannot the result of the workflow in GitHub's checks tab. It is hard to know whether browser tests are successful or fail.

Therefore, I think pull_request_target event with labeled type is better than workflow_dispatch event.
Why should this be in core?
All forked PRs failed because of browser tests.
Applicable issues
close #4553

Coverage remained the same at 94.201% when pulling 5706144cf793c5cd9a876bed8f7f5e9674072f63 on outsideris:forked-pr-browser-test into d7ed5c24c1904a15d9f841149ba0cc5a5c2c2e2b on mochajs:master.

When users open a PR, push, pull_request and pull_request_target will be run automatically.

There shouldn't be any push event for users = forked PRs, right?
Your solution is awkward, but I don't see any alternative way either...
You could remove the run-browser-test label automatically after browser test's completion.
There is a GH action re-run-workflow which:
once-label: When this label is added to a pull request, re-run the workflow once and remove the label again.
What do you think about above GH re-run-workflow?
Or any other app which removes labels (search the marketplace with "remove labels").

There shouldn't be any push event for users = forked PRs, right?

No, it shouldn't be triggered by forked PRs. I just mentioned push, pull_request and pull_request_target  because I want to explain normal workflows like our smoke, lint and tests.

You could remove the run-browser-test label automatically after browser test's completion.

That's a good idea. I will try it.

I used Add Remove Label actions.
It will remove run-browser-test label after browser test workflow whether it succeeds or fails.
And I will more test with real PRs after merging this because there are some limitations outside of this repository.

fixed.
I will merge this to test with real forked PRs.


Error on login

Hi been using this for a few weeks now and had no issues configuring the setup.
However I now have new Home Assistant hardware.
Installed the code through HACS then restarted. Next went into Settings \ Device and Services and added the Integration for Geo Home. Entered in my smartphone app username and password (which is the one I registered my account on) and received this
[%key:common::config_flow::error::unknown%]
Have reset my password and re-logged into the my smartphone app so I know the username \ password combination is correct, tried to install the Integration again but getting the same issue.
I've just checked and the last commit might have broken something by the looks of it bit not sure what.

I've just checked and the last commit has broken something by the looks of it.

I missed a flow - sorry about that. It shoud be fixed now

Removed the repo from HACS rebooted and tried again after adding the integration, still the same. Sorry


proposal: NaN hex value

What version of Go are you using (go version)?

$ go version
go version go1.15.1 darwin/amd64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/andrea/Library/Caches/go-build"
GOENV="/Users/andrea/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/andrea/workspace/TSXor-Go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/andrea/workspace/TSXor-Go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.15.1/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.15.1/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/1q/6z9rflzn1bsb6nlh158wktwh0000gn/T/go-build270156418=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?
I'm writing a porting of a time-series compressor algorithm originally written in C++. Since the input is composed of floating-point values, and since I want to apply bitwise operations over them, I extensively use functions like math.Float64bits() and math.NaN(). During my tests, I notice that the NaN value is equal to 0x7FF8000000000001 whereas the C++ version is equal to 0x7FF8000000000000.
What did you expect to see?
I expected a NaN equal to 0x7FF8000000000000 to allow compatibility with C++ code.
What did you see instead?
At the moment NaN value is equal to 0x7FF8000000000001. See here

Before 6e9506a7b45958665c3f48deecc8555f3ee2c42b, the constants were defined as:
uvnan  = 0x7FF0000000000001
uvinf  = 0x7FF0000000000000

So my guess is that nan was set to ..001 because otherwise it would have been equal to uvinf (and they wanted to avoid that?). But that commit changed uvnan to match gcc c99 value to start with  0x7FF8.. so the final ..1 can be removed I think. Then we would match gcc output of
#include <stdio.h>
#include <math.h>
#include <inttypes.h>
#include <string.h>

int main(void)
{
  double f1 = NAN, f2 = INFINITY;
  uint64_t u; memcpy(&u, &f1, sizeof f1);
  printf("NAN -> %" PRIx64 "\n", u);
  memcpy(&u, &f2, sizeof f2);
  printf("NAN -> %" PRIx64 "\n", u);
}

which is
NAN -> 7ff8000000000000
NAN -> 7ff0000000000000

The question is... would this break existing code?
cc @ianlancetaylor

Before 6e9506a7b45958665c3f48deecc8555f3ee2c42b, the constants were defined as:
uvnan  = 0x7FF0000000000001
uvinf  = 0x7FF0000000000000

So my guess is that nan was set to ..001 because otherwise it would have been equal to uvinf (and they wanted to avoid that?). But that commit changed uvnan to match gcc c99 value to start with  0x7FF8.. so the final ..1 can be removed I think. Then we would match gcc output of
#include <stdio.h>
#include <math.h>
#include <inttypes.h>
#include <string.h>

int main(void)
{
  double f1 = NAN, f2 = INFINITY;
  uint64_t u; memcpy(&u, &f1, sizeof f1);
  printf("NAN -> %" PRIx64 "\n", u);
  memcpy(&u, &f2, sizeof f2);
  printf("NAN -> %" PRIx64 "\n", u);
}

which is
NAN -> 7ff8000000000000
NAN -> 7ff0000000000000

The question is... would this break existing code?
cc @ianlancetaylor

Hi @ALTree 👋
thanks for your reply.
I hope this doesn't affect the delicate parts of the codebase otherwise it might be too difficult to fix 😅

Hi @ALTree 👋
thanks for your reply.
I hope this doesn't affect the delicate parts of the codebase otherwise it might be too difficult to fix 😅

I think the change from 7ff00..001 to 7ff80..001 was to change our NaN from signaling to quiet. In that transition we could have changed to 7ff80..000 instead. We still could, I guess.
I don't think I understand the motivation here, though. There's a risk that we break someone's code. What's the benefit? I don't think "match C++" is enough of a benefit.

I think the change from 7ff00..001 to 7ff80..001 was to change our NaN from signaling to quiet. In that transition we could have changed to 7ff80..000 instead. We still could, I guess.
I don't think I understand the motivation here, though. There's a risk that we break someone's code. What's the benefit? I don't think "match C++" is enough of a benefit.

Hi @randall77 👋
thanks for your reply.
You're absolutely right. But what if every gcc-based language is affected? If so, it could be a problem, I guess.

Hi @randall77 👋
thanks for your reply.
You're absolutely right. But what if every gcc-based language is affected? If so, it could be a problem, I guess.

But what if every gcc-based language is affected?

It probably is. I would think every C-based language (gcc or otherwise) uses the 7ff80..000 NaN.
Probably much more important is to match the platform generated NaN, the one you get when doing 0/0. Unfortunately, that's underspecified, and varies by platform:
package main

import (
	"fmt"
	"math"
)

var x, y float64

func main() {
	fmt.Printf("%x\n", math.Float64bits(x/y))
}

generates
fff8000000000000

on amd64 and
7ff8000000000000

on arm64.
So whether we use 7ff80..000 or 7f80..001, it is still not going to match the result of 0/0 on some platforms.

If so, it could be a problem, I guess.

I still don't understand the problem this is causing.

But what if every gcc-based language is affected?

It probably is. I would think every C-based language (gcc or otherwise) uses the 7ff80..000 NaN.
Probably much more important is to match the platform generated NaN, the one you get when doing 0/0. Unfortunately, that's underspecified, and varies by platform:
package main

import (
	"fmt"
	"math"
)

var x, y float64

func main() {
	fmt.Printf("%x\n", math.Float64bits(x/y))
}

generates
fff8000000000000

on amd64 and
7ff8000000000000

on arm64.
So whether we use 7ff80..000 or 7f80..001, it is still not going to match the result of 0/0 on some platforms.

If so, it could be a problem, I guess.

I still don't understand the problem this is causing.

Wow, I didn't know each platform uses its own NaN. Thanks a lot!
Anyway, in my case, the problem was that the final bit set to 1 varies the compression ratio of my algorithm. I pointed out this issue because maybe in the world someone is affected by the same problem and probably doesn’t know it. Instead now, with an open issue, one can be aware of this inconsistency with respect to C-like languages.

Wow, I didn't know each platform uses its own NaN. Thanks a lot!
Anyway, in my case, the problem was that the final bit set to 1 varies the compression ratio of my algorithm. I pointed out this issue because maybe in the world someone is affected by the same problem and probably doesn’t know it. Instead now, with an open issue, one can be aware of this inconsistency with respect to C-like languages.

So the problem is that you have a unit test that's failing because the compression ratio isn't matching the compression ratio of the "same" data when compressed with your C++ implementation?
I don't think that problem alone is worth changing the value of math.NaN.

So the problem is that you have a unit test that's failing because the compression ratio isn't matching the compression ratio of the "same" data when compressed with your C++ implementation?
I don't think that problem alone is worth changing the value of math.NaN.

If your compressor depends on the payload bits of a NaN, then you really need to specify those bits explicitly in your test cases.

If your compressor depends on the payload bits of a NaN, then you really need to specify those bits explicitly in your test cases.

So the problem is that you have a unit test that's failing because the compression ratio isn't matching the compression ratio of the "same" data when compressed with your C++ implementation?

Yes exactly.
Again, the point of this issue was to let people know about it. If it's not worth the change, for me it's absolutely legitimate to leave it as it is.

So the problem is that you have a unit test that's failing because the compression ratio isn't matching the compression ratio of the "same" data when compressed with your C++ implementation?

Yes exactly.
Again, the point of this issue was to let people know about it. If it's not worth the change, for me it's absolutely legitimate to leave it as it is.

Ok, I'm going to close then. I don't think there's anything worth changing in Go here.

Ok, I'm going to close then. I don't think there's anything worth changing in Go here.


Utilise full screen width

Hi,
Wonderful template! :)
Can I ask how I can make it so it uses the full width or at least something wider?

Right now it looks like this, which is super weird. :D A lot of screen estate is unused. And it does this for all pages. So it's not like it expands when there is enough content.
Thanks! :)

Oh never mind. Content Width 100%. :D

  Your contents go here

html,body{ margin:0; padding:0; height:100%; width:100%; }
#full-size{
  height:100%;
  width:100%;
  overflow:hidden; /* or overflow:auto; if you want scrollbars */
}
(html, body can be set to like.. 95%-99% or some such to account for slight inconsistencies in margins, etc.)
I hope this help ,
Rachel Gomez


Signup Count helper variable

Refs #3899
Create a helper variable to store the Campaign's current Signup count, to avoid running a live SQL count query every time we need it.
Per Hipchat convo with @mshmsh5000 the best solution would be:

Upon campaign signup, increment the count variable for the campaign

Schedule cron to refresh the variable for each campaign 2x a day, in order to fix any potential race conditions that could have borked the calculation

This incrementing / cron job implementation should also done for the Sum Quantity variable in #3899

Could also consider incrementing directly in Redis, since there's a straightforward way to do that. The count could be incremented & referenced in Redis, and occasionally reset from the calculated total, which could be in MySQL.
One benefit from this is that a spike in signups won't cause a bunch of contention as this one row gets locked and written -- those will all be Redis INCR calls, much more scalable.

@aaronschachter Do we need to do this one before #4288 ? That issue is really just for optimizely testing at the moment.

@sbsmith86 responded in this thread https://github.com/DoSomething/dosomething/commit/dcf78e5f1dc363d9251761a60cd0ce623cc2d7e3

OKAY. after much IRL discussion today the goal for this is

Expose an endpoint from the Dashboard get this number DoSomething/dashboards/issues/37
Have a cron job run 1/day to (around noon) to get the updated number
Save that number as a local variable

Sounds gorgeous :+1: :beers:

Leaving this issue open for now.
Currently implemented:

There is a signup count variable on the dosomething_helper_variable page on the campaign template.
That number is pulled from the total web signups
A cron runs every hour to update the number of signups within the past hour.
The number can be overriden manually (to allow for manual imports of mobile signups)

Left to build:
Add a cron that updates this number from the Dosomething/dashboards/issues/37 repo

closing since dashboards have been down for a bit, and with data 2.0, this approach will probably change


Hotfixes 1.0.2

I was testing for first time listbox with many categories. See example in:
https://github.com/qPCR4vir/nana-demo/blob/master/widget_show2.cpp

These fixes have already merged into hot fixes branch


[EPIC] In place migration of oc10 to ocis

In place migration of oc10 to ocis
Milestone issue list: Migration
Scenario
This scenario is based on the one for the data_exporter requirements.
Given an instance at https://demo.owncloud.com where user einstein shared a folder /photos with marie who mounted it as /projects/abc this is the flow that is planned to migrate an instance user by user:

[ ] cover reshares
[ ] cover (re-)shares to groups

0. Prerequisites

[ ] Document how to set up OIDC auth and phoenix for oc10

https://github.com/owncloud/openidconnect openidconnect support for core
https://github.com/owncloud/core/issues/34484 Phoenix integration into core
we assume the oidc idp/iss is https://idp.owncloud.com

1. Set up reverse proxy

make oc10 available at https://oc10.owncloud.com as well
Introduce OCIS as proxy for https://demo.owncloud.com

[ ] add proxy middleware for reva

OCIS is used to forward requests for unmigrated users to the oc10 instance/domain.

it keeps a list of migrated users do decide which requests to forward

Migrated users will be hosted by ocis
2. Migrate groups (optional)
Can be skipped if all groups are maintained in an LDAP server that has been configured for oc10 & ocis

[ ] occ export:groups TODO there is only occ groups:list
[ ] occ import:groups TODO use occ group:add

3. Migrate user by user

in oc10 export user file and share metadata: occ export:user einstein, occ export:user marie, occ export:user richard

will export file and share metadata.

[x] basic data format is in place: see https://github.com/owncloud/data_exporter/issues/77
[ ] share recipient has no mount point information, but we need it to reconstruct the shares. tracked in https://github.com/owncloud/data_exporter/issues/113
the file metadata contains a reference to the share that allows reconstructing the storage and path to the shared file, eg /projects/abc is a reference to type home user einstein and path /photos

nothing is changed in either instance, a reexport can happen at any time
TODO create a milestone in the data exporter for needed changes/fixes for these

[ ] Make file export optional
[ ] drop /files prefix for path in files.jsonl
[ ] export mount points
[ ] reshares are exported with path null
[ ] Add Extended Share attributes

in ocis reva import marie --user-iss https://idp.owncloud.com --user-sub cb1dd81e-6967-44f7-8239-dffbbe319e92

imports the user marie with iss https://idp.owncloud.com and sub cb1dd81e-6967-44f7-8239-dffbbe319e92 into ocis

[ ] create the storage if the user does not exist yet
[ ] add storage registry entry? for now the static registry will use the same storage provider for all the users.

[x] shares to migrated users are recreated as internal shares (for the first user, no shares will be migrated)

[ ] due to path based references we need to have the list of oc10 usernames to ocis sub@iss mappings available to properly rewrite the userid in references

[ ] shares to not migrated users are created as federated shares to the old instance

[ ] with a user id mapping file we can set the permissions in the storage
[ ] implement a handler for the federated sharing api

[ ] needs an auth provider for the federated sharing id

[ ] shares from migrated users are mounted

can be determined if the exported reference can be resolved to an existing file/folder, including the userid mapping

shares from non migrated users are skipped, they will be migrated in the next step
[ ] public shares are recreated with the same token
[ ] import file metadata, WIP PR https://github.com/cs3org/reva/pull/299 needs https://github.com/cs3org/reva/pull/289

Repeat the import and export for as many users as desired

s1: occ migrate:shares marie https://demo.owncloud.com

shares to marie are converted into federated shares to<EMAIL_ADDRESS>
[ ] use a username -> iss & sub mapping file
creating federated shares will send a federated sharing request to ocis... or not because oc10 thinks it is still responsible for both domains.
needs to be done using sql
[ ]  the command needs an API to create shares in OCIS

for shares from/to migrated users, internal shares are set up
for shares from/to non migrated users, federated shares are created.

s1: occ user:delete marie

but without actually deleting files?
mark user as migrated for the proxy

migrate trash in a dedicated step?
migrate versions in a dedicated step?

migrate data (file content)

[ ] data needs to be moved from old ownCloud data directory into new eos layout

no files (files_trashbin, files_versions) folder per user, we need to move files to new user home

to import versions into EOS, see below
to import trash into EOS, see below

owner changes from www-data to the actual user (users must be known to the underlying os, so ACLs can be set up correctly)

proxy

[ ] user by user migration needs to send users to either revad or oc10 apache servers

task for the authentication / reverse proxy, likely a header that is set during login
can we make reva act as a proxy for the old oc10 so we can intercept the traffic and send users to the right instance

would that help with sharing?
would this allow sharding instances

[ ] how do we authenticate users

phoenix supports oidc and oauth2, but no basic auth
revad supports oidc and can use basic auth
since we have to control the users anyway, in order to set ACLs for guest accounts we may have to manage our own ldap server that can then be used to provide users for an oidc capable IdP

[ ] how do we import versions and trash items via the CS3 api?

efforts on https://github.com/owncloud/ocis-migration supercede this issue. See https://owncloud.github.io/ocis/deployment/#migrate-an-existing-owncloud-10

efforts on https://github.com/owncloud/ocis-migration supercede this issue. See https://owncloud.github.io/ocis/deployment/#migrate-an-existing-owncloud-10

Elcin's implementation: https://github.com/esgarov/Daten-Import-in-Ocis


Occlusion culling fixes

Some fixes to the way depth was computed and checked. Should fix cases where small objects at the edges of the viewport would self-occlude. Also changed the ray generation code to be a bit faster.

Thanks!


Add a way of making bodies unmovable by collisions but movable by setting velocity

What I'm trying to do
Here is my understanding of the isStatic property:

isStatic = false
isStatic = true

Movable by Collisions
Yes
No

Movable by Setting Velocity
Yes
No

I want to make my rectangle movable by velocity, but not movable by collisions:

What I'm trying to do

Movable by Collisions
No

Movable by Setting Velocity
Yes

So the isStatic option does not work for my use case.
What I tried

I tried setting density to Infinity, because I thought that it would make nothing be able to move it, but then it still got moved, so it didn't work.
I tried resetting the position of the body on every tick, but that messed up its interaction with other objects that collide with it.
Body.setVelocity() on the static body.

I'd say check out the body manipulation example as hopefully that covers what you need.
Static bodies don't move themselves or respond to collisions in a physically simulated way (so no velocity or force), but you can still move them around manually like in the example by setting their position which from the engine point of view effectively just 'teleports' them even though it appears like motion.

@liabru I am currently setting their position, but I am making a pong game, and I want the ball to spin depending on if the paddle is moving up, down, or not moving. Currently the paddles are static, and the ball isn't. I might be wrong, but I think that if the paddle had a velocity, it would internally affect the way the ball moves.

@ChocolateLoverRaj I resolved this issue in a custom build of the engine by adding an ignoresCollisions property to Body and editing the Resolver module
Specifically, I changed all conditionals that reference the isStatic property to also check for ignoresCollisions. For example, in Resolver.js, you would change if (bodyA.isStatic || bodyB.isStatic) {...} to if (bodyA.isStatic || bodyB.isStatic || bodyA.ignoresCollisions || bodyB.ignoresCollisions) {...} and if (!(bodyA.isStatic || bodyA.isSleeping)) {...} to if (!(bodyA.isStatic || bodyA.isSleeping || bodyA.ignoresCollisions)) {...} (and do that for every single line that uses isStatic, in the entire file)

@japraj can you share the code/fork please?

@ChocolateLoverRaj Sorry I did not post the code because I made a lot of breaking changes to the file (rewrote in typescript with ES6 classes and a new API, and made modifications to support changes in several other modules) so it is not really recognizable or easily usable outside of my codebase

@japraj Oh ok so I should do what you said in https://github.com/liabru/matter-js/issues/1035#issuecomment-908027042 with the latest version for my own use.


rapidjson: fix CVE-2024-38517 and CVE-2024-39684

Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

[x] The toolchain has been rebuilt successfully (or no changes were made to it)
[x] The toolchain/worker package manifests are up-to-date
[x] Any updated packages successfully build (or no packages were changed)
[x] Packages depending on static components modified in this PR (Golang, *-static subpackages, etc.) have had their Release tag incremented.
[x] Package tests (%check section) have been verified with RUN_CHECK=y for existing SPEC files, or added to new SPEC files
[x] All package sources are available
[x] cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json, .github/workflows/cgmanifest.json)
[x] LICENSE-MAP files are up-to-date (./SPECS/LICENSES-AND-NOTICES/data/licenses.json, ./SPECS/LICENSES-AND-NOTICES/LICENSES-MAP.md, ./SPECS/LICENSES-AND-NOTICES/LICENSE-EXCEPTIONS.PHOTON)
[x] All source files have up-to-date hashes in the *.signatures.json files
[x] sudo make go-tidy-all and sudo make go-test-coverage pass
[x] Documentation has been updated to match any changes to the build system
[x] If you are adding/removing a .spec file that has multiple-versions supported, please add @microsoft/cbl-mariner-multi-package-reviewers team as reviewer (Eg. golang has 2 versions 1.18, 1.21+)
[x] Ready to merge

Summary

Fix for high severity CVE-2024038517 and CVE-2024-39684
Change Log

patch file for CVE-2024-38517
nopatch file for CVE-2024-39684 as it is a duplicate of CVE-2024-38517

Does this affect the toolchain?

NO
Links to CVEs

https://nvd.nist.gov/vuln/detail/CVE-2024-38517
https://nvd.nist.gov/vuln/detail/CVE-2024-39684

Test Methodology

Pipeline build id: 607293

Auto cherry-pick results:

main :white_check_mark: -> https://github.com/microsoft/azurelinux/pull/9897

Auto cherry-pick pipeline run -> https://dev.azure.com/mariner-org/mariner/_build/results?buildId=609837&view=results


uart.h: Clarification required on uart_irq_tx_ready uart_irq_rx_ready

This point relates to discussion that happened around https://github.com/zephyrproject-rtos/zephyr/pull/31192.
It appears that there are some uart API clients (in tree: h4.c and more, @jfischer-no may complete the list) that rely on a specific behavior from uart_irq_tx_ready and uart_irq_rx_ready.
The behavior variant, not explicited in uart.h, is that functions return false if matching IRQ are disabled.
It is implemented in MCUX and NRF uart drivers (and now STM32, following merge of #31192, maybe few others), but not in other uart drivers (nuovoton, sam, sam0, ..).
So question is:

Should this behavior be explicit in API and updated in drivers that don't behave this way ?
Should it be reverted and clients fixed ?
Should it be kept optional but made explicit in the API ?

^^ @carlescufi  @jfischer-no @dcpleung

^^ @carlescufi  @jfischer-no @dcpleung

The API does not provide separate callbacks for TX and RX events. Construct like in the example below can be found in several places. Assuming that after uart_irq_tx_disable(ctx->dev);,  uart_irq_tx_ready(ctx->dev) returns false, one can avoid the use of additional controls.
static void uart_callback(const struct device *dev, void *user_data)
{
    ....
	while (uart_irq_update(ctx->dev) && uart_irq_is_pending(ctx->dev)) {
                if (uart_irq_rx_ready(ctx->dev)) {
			foo_handler_rx(ctx);
		}

                if (uart_irq_tx_ready(ctx->dev)) {
			foo_handler_tx(ctx);
		}
	}
    ....
}

drivers/bluetooth/hci/h4.c
subsys/mgmt/osdp/src/osdp.c
subsys/net/lib/openthread/platform/uart.c
https://github.com/zephyrproject-rtos/zephyr/pull/26516/files#diff-a994711763bf9047172526af8656a1817ed7b2191b8e3d5e358527bedff18165R445-R454

The API does not provide separate callbacks for TX and RX events. Construct like in the example below can be found in several places. Assuming that after uart_irq_tx_disable(ctx->dev);,  uart_irq_tx_ready(ctx->dev) returns false, one can avoid the use of additional controls.
static void uart_callback(const struct device *dev, void *user_data)
{
    ....
	while (uart_irq_update(ctx->dev) && uart_irq_is_pending(ctx->dev)) {
                if (uart_irq_rx_ready(ctx->dev)) {
			foo_handler_rx(ctx);
		}

                if (uart_irq_tx_ready(ctx->dev)) {
			foo_handler_tx(ctx);
		}
	}
    ....
}

drivers/bluetooth/hci/h4.c
subsys/mgmt/osdp/src/osdp.c
subsys/net/lib/openthread/platform/uart.c
https://github.com/zephyrproject-rtos/zephyr/pull/26516/files#diff-a994711763bf9047172526af8656a1817ed7b2191b8e3d5e358527bedff18165R445-R454

API meeting 12th January 2021:
No decision taken, but alternatives seem to be:
a) Document that the functions perform a logical AND between the rx/tx flags and the rx/tx IRQ enable flags
b) Do not perform the logical AND above and instead provide the functions below:
bool uart_irq_rx_is_enabled()
bool uart_irq_tx_is_enabled()

a) would probably require no changes to API users in-tree, whereas b) would require some users to perform:
if (uart_irq_tx_ready(h4_dev) && uart_irq_rx_is_enabled(h4_dev)) {

Would very much appreciate @nordic-krch and @Mierunski input on this particular decision.

API meeting 12th January 2021:
No decision taken, but alternatives seem to be:
a) Document that the functions perform a logical AND between the rx/tx flags and the rx/tx IRQ enable flags
b) Do not perform the logical AND above and instead provide the functions below:
bool uart_irq_rx_is_enabled()
bool uart_irq_tx_is_enabled()

a) would probably require no changes to API users in-tree, whereas b) would require some users to perform:
if (uart_irq_tx_ready(h4_dev) && uart_irq_rx_is_enabled(h4_dev)) {

Would very much appreciate @nordic-krch and @Mierunski input on this particular decision.

Note that the existing documentation very clearly states that uart_irq_rx_ready indicates that there is unreceived data pending, which is independent of whether IRQ is still enabled when the function is invoked.  There are use cases where something may disable the interrupt before the handler can be invoked, in which case the additional check would cause uart_irq_rx_ready() to fail to meet its specification (that there's data ready).  Also in that case a separate function to detect IRQ enable state would not help as there's a race condition with the receive buffer check.
I think we need to go back to the time when the additional gate was first added in Nordic and understand why that was done, and figure out whether there's a better way to address it that doesn't change the documented behavior.
I have a list of issues with the UART API that this relates to, along with some draft samples showing how to use the three different UART APIs.  I will try to dust those off which might help clarify questions of how to use the API correctly.

Note that the existing documentation very clearly states that uart_irq_rx_ready indicates that there is unreceived data pending, which is independent of whether IRQ is still enabled when the function is invoked.  There are use cases where something may disable the interrupt before the handler can be invoked, in which case the additional check would cause uart_irq_rx_ready() to fail to meet its specification (that there's data ready).  Also in that case a separate function to detect IRQ enable state would not help as there's a race condition with the receive buffer check.
I think we need to go back to the time when the additional gate was first added in Nordic and understand why that was done, and figure out whether there's a better way to address it that doesn't change the documented behavior.
I have a list of issues with the UART API that this relates to, along with some draft samples showing how to use the three different UART APIs.  I will try to dust those off which might help clarify questions of how to use the API correctly.

As for nordic drivers, uart_irq_rx_ready returns true if there is any pending data, no check for interrupt being enabled.
As for uart_irq_tx_ready, it checks against Tx interrupt being enabled but API states:
@brief Check if UART TX buffer can accept a new char

As it can only be called from uart interrupt context, then it seems ok to not accept new data when interrupt is disabled. Given that uart_irq_tx_disable is also intended to be called from uart interrupt context.

As for nordic drivers, uart_irq_rx_ready returns true if there is any pending data, no check for interrupt being enabled.
As for uart_irq_tx_ready, it checks against Tx interrupt being enabled but API states:
@brief Check if UART TX buffer can accept a new char

As it can only be called from uart interrupt context, then it seems ok to not accept new data when interrupt is disabled. Given that uart_irq_tx_disable is also intended to be called from uart interrupt context.

It is implemented in MCUX and NRF uart drivers (and now STM32, following merge of #31192, maybe few others), but not in other uart drivers (nuovoton, sam, sam0, ..).

@erwango this seems to be inaccurate as per this comment on the RX side. On the TX it is, but see the reasoning for it in the same comment.

It is implemented in MCUX and NRF uart drivers (and now STM32, following merge of #31192, maybe few others), but not in other uart drivers (nuovoton, sam, sam0, ..).

@erwango this seems to be inaccurate as per this comment on the RX side. On the TX it is, but see the reasoning for it in the same comment.

@erwango this seems to be inaccurate as per this comment on the RX side.

Exact. >till stands for uart_mcux.c though.

@erwango this seems to be inaccurate as per this comment on the RX side.

Exact. >till stands for uart_mcux.c though.

@erwango this seems to be inaccurate as per this comment on the RX side.

Exact. >till stands for uart_mcux.c though.

Then this is instead a bug in uart_mcux.c (and now in the ST UART driver?)

@erwango this seems to be inaccurate as per this comment on the RX side.

Exact. >till stands for uart_mcux.c though.

Then this is instead a bug in uart_mcux.c (and now in the ST UART driver?)

@erwango this seems to be inaccurate as per this comment on the RX side.

Exact. >till stands for uart_mcux.c though.

Then this is instead a bug in uart_mcux.c (and now in the ST UART driver?)

ok, will fix STM32 one.
@MaureenHelm can you check uart_mcux.c ?

@erwango this seems to be inaccurate as per this comment on the RX side.

Exact. >till stands for uart_mcux.c though.

Then this is instead a bug in uart_mcux.c (and now in the ST UART driver?)

ok, will fix STM32 one.
@MaureenHelm can you check uart_mcux.c ?

This is now a bug in uart_mcux.c.

This is now a bug in uart_mcux.c.


Websocket scheme behind loadbalancer

https://issues.jboss.org/browse/ERRAI-861

Thank you! Your changes are on master now.


Change web ui to be compatible with Sidekiq 4.2.0

Sidekiq 4.2.0 migrated  its web app from Sinatra to a plain Rack app, so some
tweaks are needed to support both approaches.

Coverage decreased (-0.1%) to 96.452% when pulling 3ce1c0faa360f5ec9e3ae21794dffdaec2c80626 on feature/sidekiq-4.2.0-compat into e0b65583211f26d863409c0589aff5c690937fa2 on master.


Exported SVGs missing rotation

Hi @felixfbecker,
Thanks for this useful library! When converting objects with rotation applied, the resulting SVG does not reflect the rotation. It appears that the SVG elements retain their default orientation despite transformations applied in the source.
I found a comment in the code in this line that might explain this:
https://github.com/felixfbecker/dom-to-svg/blob/208eb3b5d0544f5b48bcc1efe627990278696a41/src/element.ts#L372
Would it be possible to quickly add the rotation?
Many thanks in advance!

@felixfbecker I just stumbled across https://github.com/felixfbecker/dom-to-svg/pull/66 that does seem to fix css transforms like rotations. Shall i open a new PR with just the transformation feature or how would like to handle this?


Add Support for Azure azurerm_virtual_network_peering

Peering of Azure Networks is highly used in Hub/Spoke Concept and Microsoft Cloud Adoption Framework.
So it would be very usefull to include that in the calculation too.
Thanks

Cost details
Paid resource:
azurerm_virtual_network_peering

TF registry: https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/virtual_network_peering

Azure pricing: https://azure.microsoft.com/en-us/pricing/details/virtual-network/

Cost components:

Name
Units
Usage param
Notes

Inbound data transfer
GB
monthly_inbound_data_transfer_gb float

Outbound data transfer
GB
monthly_outbound_data_transfer_gb float

Note for community
Please 👍 if you'd like to upvote this or receive updates.
Add a comment if you'd like to contribute.

@Joerg-L Hi! Thank you for creating the issue!
Our first step is to update the issue description with the details of what Cost Components are related to service. Here's an example how it can look like: https://github.com/infracost/infracost/issues/1038. I'd assume you already have some context around these resources, so maybe you'll be able to add them here. After a quick look into cloud prices and Azure pricing calculator it seems like there are two cost components for Egress and Ingress traffic, and the prices depend if they are within one region or inter-region. Does it sound right to you? This guide can help defining the cost components.
And we also have a dedicated guide how to add new resources: guide.
Please let us know if you need any help with that. We have a community Slack for easier communication. :)

@vdmgolub Hi!
Thanks a lot for your feedback, and sorry for additional work. That's my first request of that kind.
You are completely right with your analysis of the cost components
Cost Components

Inbound data transfer with GB as unit per use
Outbound data transfer with GB as unit per use
Price depends if traffic is within same region or globally (3 zones + gov)

As described in the Hub-and-spoke network topology and the Landing Zone Concept of the Microsoft Cloud Adoption Framework, the usage of vnet peering is highly recommendet and best-practice. Even if that is  "per Use" calculation, having that in minde and plan the costs is really use full.

This is merged to master and will go live with the next release. Big thanks to @sawyerw-mastery for the contribution!

This is now live in the v0.10.8 release. Thanks again @sawyerw-mastery  ❤


fix: better version metadata

Fixes #3363

Still need to update pipelines.

Pull Request Test Coverage Report for Build 625411937

0 of 0   changed or added relevant lines in 0 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage remained the same at 84.933%

Files with Coverage Reduction
New Missed Lines
%

libraries/botbuilder-lg/src/templateExtensions.ts
1
84.48%

Totals

Change from base Build 625219772:
0.0%

Covered Lines:
18638

Relevant Lines:
20913

💛  - Coveralls


python38Packages.simple-salesforce: 1.11.2 -> 1.11.3

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python38Packages.simple-salesforce is: "A very simple Salesforce.com REST API client for Python"
meta.homepage for python38Packages.simple-salesforce is: "https://github.com/simple-salesforce/simple-salesforce"
meta.changelog for python38Packages.simple-salesforce is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS

Warning: a test defined in passthru.tests did not pass

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 1.11.3 with grep in /nix/store/m38h9pafpafzqarsd5avk3cyygdwl1nj-python3.8-simple-salesforce-1.11.3

found 1.11.3 in filename of file in /nix/store/m38h9pafpafzqarsd5avk3cyygdwl1nj-python3.8-simple-salesforce-1.11.3

directory tree listing: https://gist.github.com/9f67530e486346be61ae33e8a1c76669

du listing: https://gist.github.com/743b537828c9f7fb6ba02ead66620127

Rebuild report (if merged into master) (click to expand)

8 total rebuild path(s)

2 package rebuild(s)

2 x86_64-linux rebuild(s)
2 i686-linux rebuild(s)
2 x86_64-darwin rebuild(s)
2 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
python38Packages.simple-salesforce
python39Packages.simple-salesforce

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/m38h9pafpafzqarsd5avk3cyygdwl1nj-python3.8-simple-salesforce-1.11.3 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python38Packages.simple-salesforce https://github.com/r-ryantm/nixpkgs/archive/45ae7294bbbcb6361cebb1f5fa331a3b56e3752e.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/m38h9pafpafzqarsd5avk3cyygdwl1nj-python3.8-simple-salesforce-1.11.3
ls -la /nix/store/m38h9pafpafzqarsd5avk3cyygdwl1nj-python3.8-simple-salesforce-1.11.3/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

2 packages built:

python38Packages.simple-salesforce
python39Packages.simple-salesforce

Maintainer pings
cc @costrouc for testing.

Result of nixpkgs-review pr 134699 at 45ae7294 run on x86_64-linux 1

2 packages built successfully:

python38Packages.simple-salesforce
python39Packages.simple-salesforce

2 suggestions:

warning: unused-argument
Unused argument: isPy27.
Near pkgs/development/python-modules/simple-salesforce/default.nix:7:3:
  |
7 | , isPy27
  |   ^

warning: unused-argument
Unused argument: mock.
Near pkgs/development/python-modules/simple-salesforce/default.nix:6:3:
  |
6 | , mock
  |   ^


BREAD Index: eager loading of translations

Currently
The translation table is queried for each line on BREAD index (for translatable models).
Solution
Eager load translations in VoyagerBreadControlle index() method.

Nice job, thanks!


Order independent diff option

This provides an order independent diff function. However, the diff output is not particularly smart or useful (sorry, I only needed to know if two objects were different, not how).

Please correct code formatting everywhere in your changes, as it totally disregards code conventions already used in a code

@Kamilius - Looks like my IDE went rogue on me when I was merging in conflicts from before. I think I've gotten the styling back in shape - let me know if there's anything else you need.

@jsfuchs build is failing here. Can you repair it?


Add flink-sequence-features example

Thanks for the comments @lindong28. I have updated the PR according to the comments.

Thanks for the update. LGTM.
Can you rebase the PR and re-trigger the CI so that it can pass all tests?


Runtime warning docs

I realized we didn't mention these in the docs at all yet.
These aren't in great shape, but I wanted to put up the raw information in a PR at least.

Does it state somewhere if these warnings are enabled by default? It's not clear to me based on this text.

@arthurevans PTAL


[v3] No built-in solution exists for detecting and redirecting to the user-selected language

Is your feature request related to a problem? Please describe.
In Nextra v2, the built-in nextra/locale can redirect a page to the user-selected language based on the NEXT_LOCALE.
graph TB
  docs["/docs/networking/public"] --> determine(Determine NEXT_LOCALE or by defaultLocale)
  determine -- en-US --> docs_en["/docs/en-US/networking/public"]
  determine -- zh-CN --> docs_zhcn["/docs/zh-CN/networking/public"]
  determine -- zh-TW --> docs_zhtw["/docs/zh-TW/networking/public"]

Additionally, it can redirect to the locale defined as defaultLocale in next.config.js. When users select a language on the documentation site, the subsequent /docs redirects to their preferred option:
graph TB
  docs["/docs"] -- by defaultLocale --> docs_en["/docs/en-US"]
  docs -- by cookie (NEXT_LOCALE) --> docs_zhtw["/docs/zh-TW"]

However, in Nextra v3, there is no official solution to re-implement this behavior. The swr-site example does not support root subpage redirection:
graph LR
  docs["/docs/networking/public"] --> notfound(**404** 😢)

Although swr-site supports root redirection (via redirects), it does not take user preferences into account:
graph LR
  docs["/docs"] -- always --> docs_en["/docs/en-US"]
  docs["/docs"] -.->|if users prefer this, we should redirect to| docs_zh["/docs/zh-TW"]

Describe the solution you'd like
I’m wondering if we can restore nextra/locale or at least provide a solution for it. Otherwise, this would result in significant breaking changes, and I would need to write custom middleware to achieve what Nextra v2 could do.
Describe alternatives you've considered
I write a middleware for my case? 🫠
Additional context
N/A

Can you try to use this middleware from v4? https://github.com/shuding/nextra/blob/v4-v2/examples/swr-site/middleware.ts
If it works in v3 I’ll include it

If it works in v3 I’ll include it

@dimaMachina, using the v4 middleware in v3 indeed worked.
Note however that we also have to copy over the './app/_dictionaries/i18n-config' part.
One bug I noticed (which is also reproducible in v4):

create /en and /zh folders within /pages directory.
edit your NEXT_LOCALE value to en-US or `en1'
run app
access http://localhost:3000/
observe ERR_TOO_MANY_REDIRECTS with Browser URL becoming http://localhost:3000/en-US/en-US/en-US/...

This could break the experience for existing users after a potential migration if you were to rename your locale prefixes.
I can file it separately if needed.

Can you try to use this middleware from v4? v4-v2/examples/swr-site/middleware.ts
If it works in v3 I’ll include it

It works. I also add some modifications to make it aligned to the Nextra v2 behavior (root /docs redirection): https://github.com/zeabur/zeabur/pull/522/commits/a5442c5880b0cb6f6b6928741b16dc31c2ee715c

will be exported in nextra 3.0.11, updated docs https://nextra.site/docs/guide/i18n#automatically-detect-and-redirect-to-user-selected-language-optional
@pan93412 you did an amazing job with mermaid diagrams, would you like to improve i18n docs to describe how redirecting works? Please contribute at https://nextra.site/docs/guide/i18n#automatically-detect-and-redirect-to-user-selected-language-optional 🙏❤


Table primary composite key from Foreign Keys fails in 2.20

When I upgraded from Drift 2.19 to 2.20, I get build errors stemming from code generate for a table which has a primaryKey attribute formed from foreign keys. I have a financial tracker, so I implemented transfers by making them a table that holds a reference to two transaction keys and has a primary key defined by the composite of the two foreign keys.
class TransactionTransfers extends Table {
  @ReferenceName('sourceTxUuid')
  TextColumn get sourceUuid =>
      text().references(Transactions, #uuid, onDelete: KeyAction.cascade)();
  @ReferenceName('destinationTxUuid')
  TextColumn get destinationUuid =>
      text().references(Transactions, #uuid, onDelete: KeyAction.cascade)();

  @override
  Set<Column<Object>>? get primaryKey => {sourceUuid, destinationUuid};
}

class Transactions extends Table {
  TextColumn get uuid => text()();
  DateTimeColumn get date => dateTime()();
  IntColumn get amount => integer()();
  // etc, etc

  @override
  Set<Column>? get primaryKey => {uuid};
}

When I try to build/run I get the following errors:
Got dependencies!
11 packages have newer versions incompatible with dependency constraints.
Try `flutter pub outdated` for more information.

ERROR: lib/database/reckoner_db.g.dart:12599:16: Error: The getter 'sourceUuid' isn't defined for the class 'TransactionTransfer'.
ERROR:  - 'TransactionTransfer' is from 'package:reckoner/model/transaction.dart' ('lib/model/transaction.dart').
ERROR: Try correcting the name to the name of an existing getter, or defining a getter or field named 'sourceUuid'.
ERROR:     if ($_item.sourceUuid == null) return null;
ERROR:                ^^^^^^^^^^
ERROR: lib/database/reckoner_db.g.dart:12601:38: Error: The getter 'sourceUuid' isn't defined for the class 'TransactionTransfer'.
ERROR:  - 'TransactionTransfer' is from 'package:reckoner/model/transaction.dart' ('lib/model/transaction.dart').
ERROR: Try correcting the name to the name of an existing getter, or defining a getter or field named 'sourceUuid'.
ERROR:         .filter((f) => f.uuid($_item.sourceUuid!));
ERROR:                                      ^^^^^^^^^^
ERROR: lib/database/reckoner_db.g.dart:12613:16: Error: The getter 'destinationUuid' isn't defined for the class 'TransactionTransfer'.
ERROR:  - 'TransactionTransfer' is from 'package:reckoner/model/transaction.dart' ('lib/model/transaction.dart').
ERROR: Try correcting the name to the name of an existing getter, or defining a getter or field named 'destinationUuid'.
ERROR:     if ($_item.destinationUuid == null) return null;
ERROR:                ^^^^^^^^^^^^^^^
ERROR: lib/database/reckoner_db.g.dart:12615:38: Error: The getter 'destinationUuid' isn't defined for the class 'TransactionTransfer'.
ERROR:  - 'TransactionTransfer' is from 'package:reckoner/model/transaction.dart' ('lib/model/transaction.dart').
ERROR: Try correcting the name to the name of an existing getter, or defining a getter or field named 'destinationUuid'.
ERROR:         .filter((f) => f.uuid($_item.destinationUuid!));
ERROR:                                      ^^^^^^^^^^^^^^^
ERROR: Target kernel_snapshot_program failed: Exception
Building Linux application...
Build process failed
make: *** [makefile:47: linux] Error 1

If I change the table definition and remove the foreign key references, everything compiles correctly and appears to be working based on my demo dataset.
class TransactionTransfers extends Table {
  @ReferenceName('sourceTxUuid')
  TextColumn get sourceUuid => text()();
  @ReferenceName('destinationTxUuid')
  TextColumn get destinationUuid => text()();

  @override
  Set<Column<Object>>? get primaryKey => {sourceUuid, destinationUuid};
}

What changed to make this setup fail?

Thanks for the report! It's possible that this is a regression in 2.20.0, but I can't reproduce it with the tables you've posted alone. This file generates valid code for me:
import 'package:drift/drift.dart';

part 'repro.g.dart';

class TransactionTransfers extends Table {
  @ReferenceName('sourceTxUuid')
  TextColumn get sourceUuid =>
      text().references(Transactions, #uuid, onDelete: KeyAction.cascade)();
  @ReferenceName('destinationTxUuid')
  TextColumn get destinationUuid =>
      text().references(Transactions, #uuid, onDelete: KeyAction.cascade)();

  @override
  Set<Column<Object>>? get primaryKey => {sourceUuid, destinationUuid};
}

class Transactions extends Table {
  TextColumn get uuid => text()();
  DateTimeColumn get date => dateTime()();
  IntColumn get amount => integer()();
  // etc, etc

  @override
  Set<Column>? get primaryKey => {uuid};
}

@DriftDatabase(tables: [TransactionTransfers, Transactions])
class Database extends _$Database {
  Database(super.e);

  @override
  int get schemaVersion => 1;
}

Are there any other references towards TransactionTransfers that might be causing this?

I'll work on trying to reproduce this with a smaller set of data. It will be a little bit before I have the time to experiment with and create a smaller reproducer.
I encountered this issue on both Mac and Linux with Drift 2.20 for my app Reckoner. I don't have any data type referencing TransferTransactions, but there is a lot of references to various tables from other tables. You can look at the sourc to see my table setup for other red flags. I think I'm doing something a bit unusual where I use inheritance to keep the code DRY and make common functions for similar data types. For example, a table class called TrackedTable (not a database table) which creates uuid text field and overrides the primary key to be the uuid. I used this before you released managers and I've noted that managers don't seem to be generated at all/correctly for my database when I tried to use them.
I'll probably just create a copy with the Reckoner Drift setup and remove things until I don't hit the issue anymore. On the upside, I can continue to build using 2.19 and I already setup my repo to fix my dependencies.

Don't worry about finding a minimal case to reproduce it, I can also look at the entire repository and try to figure it out from there. Do you have a pushed commit somewhere that's pointing towards the state this was in when you ran into the error? Or can I just try to upgrade drift on main to hit this?

It should be just as easy as checking out main and upgrading drift.
If you're cool with running my repo, you would just need to do make upgrade and then make linux. I also have an install script to make sure dependencies are installed for debian based distros (install.sh). Other than the dependencies for SQLCipher, I depend on libjson for secret management and libayatana-appindicator3 for a tray manager. You can build it without the tray manager by removing code depending on tray_manager. It wouldn't be feasible to remove the secret management code without significantly more work.
Shouldn't need to install anything if testing on a mac. I just merged the v2.0.0 changes which add support for mac and iOS.

Hm this is a tricky one. We currently expect the data classes to have getters for columns involved in references (because the reference functionality of the manager operates on resolved data classes, which generally makes things more intuitive for users).
I've fixed it by just adding the missing getters here:
diff --git a/lib/model/transaction.dart b/lib/model/transaction.dart
index 15df54d..085e72a 100644
--- a/lib/model/transaction.dart
+++ b/lib/model/transaction.dart
@@ -148,6 +148,9 @@ class TransactionTransfer extends Common<TransactionTransfer>
         destinationUuid: Value(destination.uuid),
       );

+  String get sourceUuid => source.uuid;
+  String get destinationUuid => destination.uuid;
+
   @override
   Object get key => (source.uuid, destination.uuid);

@simolus3 Is this my fault?

Absolutely not, I was the one adding manager support to custom row classes. I don't think there's a general solution for this, but perhaps we can skip generating references code depending on whether the fields are present on the custom row class. I'll take a look.


nuxt-i18n breaks colors of vuetify 1.2.1

Version
v5.2.1
Reproduction link
https://preview.c9users.io/lowryder/nuxt-vuetify
Steps to reproduce
files: https://preview.c9users.io/lowryder/nuxt-vuetify
code at c9.io: https://ide.c9.io/lowryder/nuxt-vuetify
result: http://nuxt-vuetify-lowryder.c9users.io:8081/

Install nuxt
install vuetify 1.2.1 or "nuxtjs/vuetify"
install "nuxt-i18n": "^5.2.1"

/nuxt.config.js
 modules: [
    '@nuxtjs/vuetify',
    ['nuxt-i18n', {
      // No options
    }]
  ]

What is expected ?
vuetify with normal (color) styling
What is actually happening?
vuetify has no colors

This bug report is available on Nuxt community (#c129)

@oanstein, could this be the same problem as issue 100? If you use the same workaround (seo: false), does it fix your issue?

@adi-zz the workaround (seo: false), does indeed "fix" this issue


(PDB-3518) More specific join for certname->reports

Previously, queries which cross certnames and reports via latest_report_id would
sometimes get a degenerate query plan due to the presence of
idx_certnames_latest_report_id. The planner was led to believe that this index
made starting with a filtered version of the reports table and then joining that
to certnames was a good plan; it is not.
By adding an additional condition to the join which touches the certname table,
we encourage the planner to deal directly with rows which include both report.id
and certname.certname. The most direct way to do this is to scan down certnames
and pull each latest_report using the main report id index. This is the plan it
makes now, and it's a lot faster.

Test PASSed

CLA signed by all contributors.


Build(deps): Bump react-router-dom from 6.11.0 to 6.13.0 (#4906)

Pull request opened by the merge tool on behalf of #4906

Merged in 2daa4511672068e7acf65c0c1c69c1de4986a42f


Modify systems

make system connect to a user instead of a provided email
fix register system and admin templates
change the register system endpoint such that a user must be logged in to create a system
fix systems table in database and endpoints in api/frontend to support this

note: does not use the system class in the frontend/models folder anymore


Question about Loose Track Training Guideline

According to the guidelines, it said "training on additional text is allowed without limits if that text is generated by a model trained following the above restrictions."  I'm curious if I can generate text using the hard prompt template and then combine the prompt and generated output to use as input for training.

Do you mean using a template-based approach to modify the training data we provide, and then adding that to the training set? Depending on the templating procedure, that would probably be fine. Generally, deterministic or heuristic-based approaches for augmenting the data are acceptable for the loose track, so long as the only input to the augmentation system is our training data.

Would human feedback be considered as expert annotations?

It depends on how the human feedback is presented: if it's textual feedback, then this would count toward the 100M word limit in the loose track. If it's number ratings for model outputs, this should be fine. Both of these would only be allowed in the loose track.
Thanks for the questions!

@aaronmueller , are you saying that no data augmentation whatsoever is allowed in the strict tracks? That surprises me, I don't see why modifying the data (without being dependent on outside sources) would not full under the strict regime, as long as we do not add additional data coming from other data sources.

Hi @jumelet! We answered a similar question in the slack, but posting the answer here as well.
If you use only trivial modifications to the existing data that don't rely on human annotations or complex algorithms/heuristics, this would be allowed in the strict track. Something akin to training an LM on the strict data and then using this to generate more data would be allowed, for example, but nothing involving human expertise or non-trivial modifications to the dataset. And, of course, no external data.


Add webserver initialization option

Include an example repo that has a flask webserver setup that generates a site and then uses flask as a webserver that points to the ezcv output.
Needed files

[ ] A standard ezcv project with the output folder being /build
[ ] Routes.py with all the config for proxying /build

[ ] Option to run with continuous regeneration with a watchdog on contents folder

[ ] A requirements.txt folder with everything you need to run the project
[ ] Readme explaning how to run the project and it's options

Cli
Add a flag to the init command to allow for a site to be generated with this config
Extra steps

[ ] Create a repo with the flask + ezcv setup so that people can use github templates to create a new repo instead of just the Cli

Documentation

[ ] Document the CLI init option
[ ] Document the new repo with the added flask option
[ ] Document a way for people to integrate this feature into "standard" ezcv projects

See https://github.com/Descent098/ezcv-http


Selection of source Views and target View

Thanks or the amazing work! My question is regarding the source views and target views used for training and inference. Does the camera trajectory of the scene is assumed to be source view 1 -> target view -> source view 2 (more of an interpolation of two source images). Can the model work for the case of a camera trajectory source view 1 -> source view 2 -> target view (extrapolation), where model needs to also generate new information not present in source view 1 and source view 2? How is the training and inference conducted w.r.t above to cases?

The views are assumed to be source view 1 -> target view -> source view 2. pixelSplat doesn't have a mechanism to hallucinate content that's not observed by at least one source view. In other words, source view 1 -> source view 2 -> target view might work if the target view mostly contains content that's visible in the source views, but isn't expected to work in general. However, adding a generative component to pixelSplat would be an interesting future direction!


Optimations to reduce the total number of keys in the network

What was wrong?
A naive approach to storing the chain history in Alexandria looks like this (as 2020/11/05)

11 million headers
11 million entries in the canonical header index
11 million block bodies

a few million uncles
~1 billion transactions

~1 billion receipts
~1 billion entries in the canonical transaction index

Depending on how you ad these numbers up you get something in the 2-3 billion range for total number of objects that need to be stored and retrievable from the network.
Content retrieval depends on the healthy spread of advertisements.  We can put a reasonably firm upper bound on how many advertisements we can send out per second at 100 which is probably optimistic.  This means that a node that wished to serve all of the content can sent about 8 million per day (100 * 24 * 60 * 60).  That means it'll take about a full year running 24/7 to broadcast everything.
We can also look at this from the view of number of nodes in the network.  If we assume we can bootstrap the network to have somewhere between 1k-100k nodes we can examine what each node on the network will need to store.
How can it be fixed?
We need to optimize the storage scheme to reduce the total number of objects in the network.
Headers
For headers we may be able to group headers by an "epoch" boundary based on block height.  We would pick an epoch size N and then group every N headers together for storage and retrieval.
The primary problem with this scheme is that it makes headers only retrievable if you know the block numbers.  Since the block hash tends to be the canonical way to definitively reference a header, this would make serving eth_getBlockByHash difficult, requiring some sort of secondary index to lookup block numbers by block hash.
It's likely that we need to store headers individually.
Canonical Header Index
The "Canonical Header Index" maps block number to block hash.  Since this index is based on block numbers, it should be easy to group by epochs.  Instead of storing a single entry for each block numbers, we would instead store an entry for each N blocks.
If we used an epoch size of 1000, then retrieving the index entry for height 4567 would mean fetching the index of epoch 5 and digging out the 467th entry from the index.
This would let us reduce 11 million entries down to 11 thousand.
Block Bodies
Block bodies house are uncles and transactions.
We do want uncles and transactions to be individually retrievable.
Simply by grouping these by block we can reduce the 1 billion transactions down to just the 11 million blocks that they are naturally grouped by.  This also works well with eth_getTransactionByBlockHashAndIndex style endpoints which retrieve transactions by their location in the block.
Receipts
Receipts naturally group themselves by blocks as well, letting us reduce the 1 billion receipts down to just the 11 million blocks they are part of.
Canonical Transaction Index
This one is unsolved.  Transactions need to be retrievable by hash.

Ideas that don't seem to work for the canonical transaction index.  The transaction ind
Binary Search from tiered indexes
The idea is to store multiple tiers of indexes, each which allow you to perform a sort of binary search.  We might have an index for each million blocks, and then successively smaller chunks.  To find a the entry for a given transaction hash you would scan the top level indices, and then work down to the lower level more granular indices as you find the index containing the transaction you need.
This approach suffers from a few problems.
First, those hosting the top level indexes would be constantly slammed with requests since every lookup for a transaction would need to hit multiple of those indexes.  This traffic pattern likely doesn't scale.
Second, the top level indexes would be incredibly expensive to build, and prohibitively expensive to verify.  Both processes would require fetching all of the blocks under that index which for the top level ones would mean fetching millions of blocks.
Grouping by truncated hash
We could group them by the first few bytes of the hash and index all of the transactions that start with the same common prefix.
These indexes would be near impossible to build and verify since it would require fetching every single transaction in order to find the ones that share a prefix.  We can potentially mitigate this by building these indexes iteratively, however this does introduce complexity that would be nice to avoid, because it would mean that these indexes would continually change and never be finalized which violates some current invariants with how we treat content.
There is also the problem of picking the prefix size.  Over time the total number of transaction will grow and we would need to adjust the prefix size which would be disruptive and prohibitively difficult to migrate.

Exploring whether it is feasible to do the canonical transaction index without any reduction.
At ~1 billion transactions and a network size between 1k-100k nodes, that means that with the following replication factors we would expect each node in the network to store:

1k
10k
50k
100k

R=1
1M
100k
20k
10k

R=5
5M
500k
100k
50k

R=10
10M
1M
200k
100k

With each advertisement being about 128 bytes we get roughly the following storage sizes

count
size

10k
1.2mb

100k
12mb

1M
120mb

10M
1.2Gb

In order to stick to the desired <1GB per node storage requirement, I believe we can establish an upper bound of about 1M advertisements that each node can store which means that having to store 1 billion transaction index entries and having a health replication factor of 10 or more would mean the network could only be healthy at over 10k nodes which is feasible but far from ideal.

Brainstorming some ideas:

Merry-go-round index population. Building a canonical transaction index (CTI) is difficult because it requires scanning through every block body. If you don't have every block body you must fetch them from the network. Over all nodes, this amounts to a lot of duplicated work. The network could de-duplicate this work by scanning through block bodies and gossiping them around.

Gossip is more efficient because looking up a block body requires one recursive lookup per CTI-serving-node. Gossip allows the block-body-serving-nodes to scan through block bodies at their leisure, putting an overhead on the network which is constant with the number of CTI-serving-nodes. Gaining this benefit does not require any kind of coordination mechanism, each block-body-serving node can scan through at it's own frequency and phase. There's also no need for any intermediate nodes to become involved, this works if each CTI-serving-node tries to find a couple block-body-serving-nodes and asks those nodes to start gossiping to them.

Index siphoning. Since we really don't want CTI-serving-nodes to scan through all blocks themselves they might instead try to bootstrap off of existing CTI-serving-nodes. Don't ask me how the first ones are built, but once they exist they have exactly the information the next generation of CTI-serving-nodes need. We could support the equivalent of a DNS zone transfer. You reach out to a node and tell it the prefix you're interested in and it gives you everything it has on that prefix. Some care will have to be put into preventing this from becoming a DOS vector but worst case this could devolve into the same kind of merry-go-round sync described above: you subscribe to updates from a CTI-serving-node and then populate your index from entries it gives you.

@lithp I may be mis-understanding your post, but I don't see any part that actually reduces the overall cost of the network hosting the CTI.
Here's the best plan I have so far so that maybe we can anchor to something concrete.
For any block B there will be some node that stores the block body, aka the uncle list and transaction list for that block.
Within the block there's some set of transactions T_1, T_2, ..., T_N.  The person hosting the block would publish advertisements for both the block body itself, as well as one CTI entry for every transaction in the block.  The block itself is one unit of content, and the CTI entries are each their own unit of content.  A CTI entry is txn_hash -> (block_hash, txn_idx, inclusion_proof).  The inclusion_proof is against the Header.transactions_trieso that once the user fetches the header and verifies the proof is valid they can know that the transaction is indeed part of the transactions for that block.
Things I understand about this setup:

Total number of CTI entries is O(N) to the total number of historical transactions.
Assuming we can get 10k nodes in the network, each node will end up storing about 120MB worth of advertisements with the vast majority of these being CTI entries.
Verifying a CTI entry involves fetching the corresponding header and validating the inclusion proof against the Header.transactions_trie
Fetching a transaction by hash involves fetching the CTI entry, then fetching the header to verify the CTI entry, then fetching the block body (and verifying it against the header) to retrieve the actual transaction.

This setup is possibly viable, but it means that as much as 99% of the content in the network will be CTI entries and that sucks.

I may be mis-understanding your post, but I don't see any part that actually reduces the overall cost of the network hosting the CTI.

Yes, sorry, I started out trying to answer this question, but I think I forgot what the original question had been while writing this up. The idea with both ideas was to prevent anyone from needing to advertise individual CTI entries. Advertising and storing a billion entries is not going to be fun.
The idea behind both ideas was to prevent anyone from needing to advertise individual CTI entries. Each node which decides it wants to serve CTI entries picks the prefix that they want to serve. They can then make a single advertisement, they only have to advertise that prefix. The problem then becomes how do they build their index, and I was trying to brainstorm ways to solve that problem, it seems like it might be easier than the problem of managing 1B advertisements.

it seems like it might be easier than the problem of managing 1B advertisements.

Yeah, I'm leaning that way more and more.  Advertising 1B things SUCKS because if we can trim that down, we immediately drop 2 orders of magnitude to only being in the 10's of millions.

Skip graph of the transaction hashes would allow for ordered traversal of the transaction keys for building the index.... but that requires the network maintain the skip graph.... which would have 1B entries in it... which would require every one of those entries to be broadcast at some point... but it would not require those to be in the advertisements table....